تستهدف واجهة قرارات الجديدة من OpenAI جزءاً من برمجيات الذكاء الاصطناعي نادراً ما يظهر في عروض الإطلاق: الخيار الصغير الذي يُتخذ بين خطوتين أكبر.

صورة تحريرية تقنية تعرض سير عمل تجريديًا لتوجيه قرارات الذكاء الاصطناعي على شاشة.

هل ينبغي توجيه طلب الدعم هذا إلى قسم الفوترة أم إلى الدعم التقني؟ هل الوثيقة مكتملة بما يكفي للانتقال إلى سير العمل التالي؟ هل يبدو أمر shell المُولَّد آمناً للتنفيذ تلقائياً؟ هل ينبغي للمساعد الصوتي أن يطلب توضيحاً، أم يحوّل المحادثة، أم يواصلها؟

من السهل وصف هذه القرارات، لكن تنفيذها بصورة سيئة مكلف. فإذا اتخذ التطبيق قراراً واحداً مع كل رسالة أو وثيقة أو معاملة أو نتيجة أداة واردة، تراكم زمن الاستجابة. كما تتراكم تكلفة تمرير كل سؤال عبر نموذج عام الغرض. وقد يؤدي تصنيف خاطئ إلى إرسال العمل إلى قائمة الانتظار غير الصحيحة، أو كشف معلومات للمشغّل الخطأ، أو تفعيل إجراء كان ينبغي أن ينتظر المراجعة.

أتاحت OpenAI واجهة قرارات عموماً في 22 أكتوبر 2026. وهي تعمل على GPT-6 Luna وتعيد إجابات مُنمَّطة بدلاً من فقرة: احتمالاً، أو خياراً من مجموعة محددة مسبقاً، أو درجة وفق مقياس مُرتَّب. وتقول OpenAI إن نقطة النهاية مصممة للإجابة عن هذه الأسئلة المحددة بما يصل إلى عشرة أضعاف سرعة استخدام GPT-6 Luna عبر واجهة Responses API. وتحدد الشركة سعراً قدره 0.10 دولار لكل مليون رمز إدخال، من دون رسوم على رموز الإخراج لهذه النقطة.

هذا المزيج يجعل واجهة القرارات مثيرة للاهتمام للفرق التي تبني منتجات ذكاء اصطناعي بالفعل. لكنها أقل إثارة للاهتمام كبديل عن مساعد عام. السؤال المفيد ليس ما إذا كان النموذج قادراً على الاستدلال، بل ما إذا كان الفريق يستطيع تعريف قرار ضيق بما يكفي لقياسه، ووضع عتبة معقولة حوله، وإبقاء الإجراء الناتج ضمن سير عمل مضبوط.

ما الذي تعيده الواجهة فعلياً

تقبل نقطة النهاية أدلة مشتركة وسؤالاً واحداً أو أكثر. وقد تكون الأدلة نصاً، أو محادثة مرتبة تتضمن استدعاءات الأدوات ومخرجاتها، أو صوراً، أو JSON منظماً. ولكل سؤال نوع واسم وتعليمات، وعند الاقتضاء، مجموعة من الخيارات المسموح بها أو مستويات الدرجات المرتبة.

يقدّر predicate ما إذا كان الشرط صحيحاً، ويعيد احتمالاً بين صفر وواحد. ويناسب ذلك أسئلة مثل: «هل تصف هذه التذكرة عملية خصم مكررة تدعمها سجلات الطلب؟» أو «هل تُظهر هذه الصورة ضرراً واضحاً؟»

يختار choice قيمة واحدة من مجموعة محددة مسبقاً. وقد يتيح نظام توجيه خيارات مثل billing وtechnical_support وaccount_access وhuman_review. ويمكن لتطبيق صوتي أن يختار continue أو clarify أو transfer أو end_call.

يقيّم score المدخل وفق مستويات مرتبة، مثل شدة منخفضة ومتوسطة وعالية. وتتضمن الاستجابة احتمالات المستويات ومتوسطاً مرجحاً بالاحتمالات. وقد يقع هذا المتوسط بين مستويين، وهو أمر مفيد للترتيب لكنه خطر إذا تعامل المطوّر معه باعتباره قياساً بالغ الدقة بطريقة سحرية.

يمكن لنقطة النهاية طرح ما يصل إلى 400 سؤال في الطلب الواحد، بعدما كان الحد 200 سؤال خلال المرحلة التجريبية العامة. وهذا مهم عندما يمكن تقييم سمات مستقلة كثيرة بالاستناد إلى الأدلة نفسها. لكنه لا يعني أن القرارات التابعة ينبغي جمعها معاً. فإذا كان لا ينبغي طرح السؤال الثاني إلا بعد الإجابة عن السؤال الأول، فإن فصل الطلبات يجعل تدفق التحكم أسهل في الفحص والاختبار.

يمثل الإخراج المُنمَّط للواجهة الفارق الأساسي في المنتج. يمكن توجيه نموذج عام لإعادة JSON، لكن يظل على المطوّر التحقق من ذلك الإخراج ومعالجة القيم غير الصحيحة أو الملتبسة. أما واجهة القرارات فتقيّد مساحة الإجابة على مستوى الواجهة البرمجية. وهذا يقلل عمل التحليل، لكنه لا يجعل الحكم الأساسي صحيحاً.

أين تلائم تطبيقاً حقيقياً

أقوى حالات الاستخدام هي القرارات المتكررة ذات مجموعة إجابات محددة وخطوة تالية واضحة. فكّر في نقطة النهاية باعتبارها طبقة حكم سريعة داخل برنامج قائم، لا موظفاً مستقلاً.

يمكن لسير عمل خاص بالوثائق استخدامها لتحديد ما إذا كانت شهادة مرفوعة تتضمن الحقول المطلوبة، وتحديد فئة الوثيقة، وتوجيه العنصر إلى قائمة الانتظار المناسبة. وقد يظل استخراج البيانات من الوثيقة بحاجة إلى نظام منفصل. أما واجهة القرارات فتجيب عن السؤال الأضيق: ما الذي ينبغي أن يحدث تالياً؟

يمكن لنظام دعم تصنيف تذكرة، وتقدير درجة الاستعجال، وتحديد ما إذا كانت رسالة العميل تتضمن معلومات كافية لإرسال رد أولي. وقد تُرسل النتيجة منخفضة الثقة إلى قائمة انتظار بشرية بدلاً من استخدامها لإرسال إجابة تلقائية.

يمكن لنظام تنسيق الوكلاء استخدام سؤال ذي خيارات لاختيار الأداة التالية من مجموعة صغيرة خضعت للمراجعة. فقد يُوجَّه الطلب الوارد، مثلًا، إلى أداة بحث، أو خدمة للاستعلام عن حساب، أو وظيفة للجدولة، أو خطوة لطلب التوضيح. يختار النموذج أحد هذه الخيارات، بينما تظل مسؤولية الصلاحيات والتحقق من الوسائط وحدود المعدل والتنفيذ على عاتق التطبيق.

وقد تستخدم منظومة أمنية أو تشغيلية هذه الواجهة لتقييم إجراء مقترح قبل تنفيذه. وتذكر OpenAI أن Datadog تستخدم نقطة النهاية لتقييم أوامر Shell التي ينشئها الوكيل قبل المعالجة الذاتية. قد يكون هذا النمط مفيدًا، لكن لا ينبغي اعتباره حدًا أمنيًا مكتملًا. فالدرجة التي ينتجها النموذج يمكن أن تضيف إشارة للمراجعة، لكنها لا تحل محل قوائم السماح بالأوامر، أو العزل، أو التحقق من الهوية، أو تقييد نظام الملفات، أو سياسة الموافقة.

وتناسب تطبيقات الصوت هذه الواجهة أيضًا، لأن بطء القرار ملحوظ للشخص الذي يتحدث. إذ تتكامل Decisions حاليًا أصلًا مع GPT-Live، ويمكن تشغيلها عند وصول نصوص الإدخال أو الإخراج. وقد يقرر التطبيق ما إذا كان على المساعد طلب توضيح، أو تحويل المكالمة، أو تحديث حالة التفاعل. وتقول OpenAI إن Speak خفّضت، في الاختبارات، الزمن اللازم للوصول إلى الإجراء التالي من 1.4 ثانية إلى 0.13 ثانية عبر هذا التكامل. هذه نتيجة أبلغ بها المورّد، وليست ضمانًا لكل منظومة صوتية، لكنها توضح سبب أهمية نقطة نهاية متخصصة في حلقة تفاعلية أكثر من أهميتها في عملية دفعية.

البنية العملية: النموذج، والعتبة، والإجراء

يتطلب التنفيذ الموثوق ثلاث طبقات منفصلة.

الطبقة الأولى هي السؤال. ينبغي أن يصف أدلة قابلة للملاحظة وأن يميّز بين الإجابات المتقاربة. عبارة «هل هذا جيد؟» ليست سؤالًا صالحًا للإنتاج. أما «هل تحتوي الرسالة على طلب لإلغاء اشتراك مدفوع، لا على طلب للحصول على معلومات عن الأسعار؟» فهي أقرب بكثير إلى ذلك.

الطبقة الثانية هي السياسة التي تفسّر الإجابة. فاحتمال قدره 0.82 لا يعني أن على التطبيق اتخاذ إجراء. يجب أن يقرر الفريق ما إذا كانت قيمة 0.82 كافية للتوجيه التلقائي، وما إذا كانت 0.55 تستدعي المراجعة، وما إذا كانت فئات معينة تتطلب دائمًا تدخل شخص، بصرف النظر عن درجة الثقة.

أما الطبقة الثالثة فهي الإجراء. لا ينبغي منح النموذج صلاحيات واسعة لمجرد أنه أعاد خيارًا صالحًا. على التطبيق أن يربط القيمة المسموح بها بوظيفة معروفة، وأن يرفض أي قيمة خارج هذا الربط. وينبغي أن تتطلب العمليات الحساسة تفويضًا مستقلًا، وتأكيدًا بشريًا عند الاقتضاء.

ويجعل هذا الفصل عملية التقييم ممكنة أيضًا. إذ تستطيع الفرق تغيير العتبة من دون إعادة كتابة الموجّه. ويمكنها مقارنة قرارات النموذج بأمثلة موسومة، وقياس الإيجابيات الكاذبة والسلبيات الكاذبة وفق تكلفة كل خطأ. فلا ينبغي لمرشح الاحتيال، وموجّه الدعم، وقائمة انتظار الإشراف على المحتوى أن تستخدم العتبة نفسها لمجرد أنها تعتمد على الواجهة البرمجية ذاتها.

وتشير إرشادات OpenAI للمطورين إلى نقطة مماثلة: استخدم أمثلة موسومة من التطبيق لتحديد العتبات. وقد يسهل تجاهل هذه النصيحة لأن نقطة النهاية تعيد احتمالات وقيم ثقة تبدو كمية. لكن هذه الأرقام لا تكون مفيدة للترتيب والتوجيه إلا بعد معايرتها على بيانات المؤسسة نفسها.

تصميم الموجّه هو الآن تصميم للسياسة

يظل القرار الضيق معتمدًا بدرجة كبيرة على الأدلة والتعليمات المقدمة إليه. يجب أن يحدد الموجّه ما يُعد دليلًا داعمًا، وما ينبغي فعله عند غياب الدليل، وكيفية التمييز بين حالة حدودية وأخرى واضحة.

لنفترض أن فريقًا يريد توجيه الفواتير. قد يطلب سؤال ضعيف من النموذج أن «يختار القسم المناسب». أما سؤال صالح للإنتاج فسوف يحدد الأقسام المتاحة، والحقول التي تميز كل قسم، ومعنى المستند غير المكتمل، والقاعدة التي تحكم الإشارات المتعارضة. وقد يتضمن أيضًا خيارًا صريحًا هو human_review بدلًا من إجبار النموذج على اختيار قائمة أعمال عندما يكون الإدخال ملتبسًا.

ينبغي أن تغطي الأمثلة الحالات العادية وحالات الفشل. أدرج رسائل قصيرة وطويلة، ولغات مختلطة إذا كان المنتج يقبلها، وسجلات متناقضة، وحقولًا مفقودة، وJSON غير صالح، ومحاولات لحقن تعليمات داخل الأدلة. فالأدلة بيانات، ولا ينبغي السماح لها بإعادة كتابة سياسة القرار.

بالنسبة إلى القرارات المتعلقة بالصور، حدّد ما يستطيع النموذج رؤيته فعليًا وما لا يستطيع إثباته. فقد تُظهر الصورة انبعاجًا، لكنها لا تثبت سبب الضرر. وقد تعرض لقطة الشاشة رسالة خطأ، لكنها لا تثبت اختراق الحساب. ينبغي أن يعكس نطاق الإجابات هذا الفرق.

عندما تشترك عدة أسئلة في المستند المصدر نفسه أو في المحادثة نفسها، ضع المواد القابلة لإعادة الاستخدام في الإدخال المشترك، وغيّر تعليمات السؤال بحسب الحاجة. تدعم الواجهة التخزين المؤقت للمطالبات لهذا النمط. وتوضح الوثائق أن البادئة القابلة لإعادة الاستخدام يجب أن تحتوي على 1,024 رمزًا على الأقل، وأن الإدخال المخزّن مؤقتًا يحصل على سعر مخفّض. يمكن للتخزين المؤقت خفض التكلفة وزمن الاستجابة، لكنه يعني أيضًا أن على المطورين فهم حدود الذاكرة المؤقتة وتجنّب وضع مواد خاصة بالمتصل أو حساسة في بادئة قد يُعاد استخدامها في سياق غير صحيح.

التكلفة منخفضة، لكن حجم الاستخدام يغيّر الحسابات

السعر المنشور لـ Decisions هو 0.10 دولار لكل مليون رمز إدخال غير مخزّن مؤقتًا، بينما يُسعّر الإدخال المخزّن مؤقتًا بـ0.01 دولار لكل مليون رمز. ولا تُفرض رسوم على رموز الإخراج في هذه الواجهة. للوهلة الأولى، يجعل ذلك كثيرًا من مهام التوجيه شبه مجانية.

لكن الفاتورة الفعلية تعتمد على مقدار الأدلة المرسلة مع كل سؤال. فقد يكون مستند سياسة متكرر، أو سجل محادثة، أو مخرجات أداة أكبر بكثير من التعليمات نفسها. وإرسال السياق الكبير نفسه بصورة منفصلة لكل قرار يهزم الغرض من مصنّف صغير. يفيد التخزين المؤقت عندما تكون البادئة مستقرة، لكن عمليات كتابة الذاكرة المؤقتة والمعالجة الإقليمية قد تضيفان تكلفة.

ينبغي للفرق قياس التكلفة لكل مهمة أعمال مكتملة، لا لكل استدعاء للواجهة. فإذا رفض المصنّف عنصرًا وأرسله إلى قائمة انتظار يدوية، فقد يكون استدعاء النموذج رخيصًا، بينما تصبح العملية الكاملة أبطأ. وإذا أنشأ مسار تلقائي إجراءً لاحقًا غير صحيح، فقد تتجاوز تكلفة التصحيح بكثير فاتورة الرموز.

يمكن للواجهة طرح أسئلة مستقلة كثيرة في طلب واحد. وقد يقلل ذلك من النفقات العامة للطلبات، لكنه لا ينبغي أن يتحول إلى ذريعة لطرح كل سؤال يمكن تصوره عن كل عنصر. فالأسئلة الإضافية تزيد التعقيد، وتصعّب التقييم، وقد تشجع الفرق على التصرف بناءً على درجات لم يتحقق أحد من صلاحيتها.

يسجّل الاختبار التجريبي المعقول، على الأقل، عدد رموز الإدخال، ومعدل إصابة الذاكرة المؤقتة، والمئينات الخاصة بزمن الاستجابة، وتوزيع الإجابات، ومعدل المراجعة، ومعدل التصحيح، والوقت اللازم لإكمال المهمة لاحقًا. وفي المنتجات التفاعلية، يكون زمن الاستجابة عند المئين 95 أهم من المتوسط. أما في قوائم الانتظار الخلفية، فقد يكون معدل الإنجاز وعبء المراجعين أكثر أهمية.

الخصوصية والضوابط الإقليمية

تدعم الواجهة إقامة الاستدلال في الولايات المتحدة وأوروبا، وتقول OpenAI إن الاحتفاظ الصفري بالبيانات متاح للعملاء المؤهلين. كما تسرد وثائق المطورين دعم HIPAA للعملاء المؤهلين، وتوضح توافر Private Link. هذه ضوابط مفيدة، لكن على المؤسسة التي تنشر النظام التحقق من الأهلية والعقود وإعدادات الواجهة وقيود الميزات.

المعالجة الإقليمية ليست استراتيجية خصوصية مكتملة. فما زال على الفريق تحديد ما إذا كان الإدخال يتضمن بيانات شخصية، وما إذا كان إرسال السجل الكامل ضروريًا، والمدة التي تحتفظ فيها سجلات التطبيق بالطلب والاستجابة، ومن يمكنه الاطلاع على تقارير الاستخدام. وينبغي إجراء التنقيح وتقليل البيانات قبل استدعاء النموذج متى كان ذلك عمليًا.

لا تجعل بنية JSON المنظمة المعلومات الحساسة آمنة بحد ذاتها. فسجل العميل الممرر بوصفه input_json يظل بيانات عميل. وتظل الصور حساسة إذا احتوت على وجوه أو عناوين أو معلومات طبية أو شاشات سرية. والسؤال الصحيح ليس ما إذا كانت الواجهة تقبل الصيغة، بل ما إذا كان لدى سير العمل سبب يمكن الدفاع عنه لإرسال تلك المعلومات.

وينطبق الحذر نفسه على التخزين المؤقت للمطالبات. فإعادة استخدام مستند مرجعي ثابت أمر فعال. أما إعادة استخدام بادئة تحتوي على تفاصيل خاصة بعميل واحد عبر طلبات لا صلة بينها فهو خطأ في التصميم. ينبغي أن تكون مفاتيح الذاكرة المؤقتة وحدودها جزءًا من مراجعة تدفق البيانات، لا فكرة لاحقة تُضاف أثناء ضبط الأداء.

ما الذي لا تستبدله Decisions

هذه الواجهة ليست نظامًا عامًا للاستخراج. فإذا كان التطبيق يحتاج إلى كائن غني يحتوي على حقول كثيرة، أو شرح مكتوب، أو مخرجات تتبع مخططًا مخصصًا، فقد تكون Responses API مع Structured Outputs أنسب. وإذا احتاج النموذج إلى طلب أداة مع تمرير وسيطاتها، فقد يكون استدعاء الدوال هو التجريد الأوضح.

ليست محرّكًا للقواعد. تكون القاعدة الحتمية أفضل عندما يمكن التعبير عن الشرط بدقة. فمثلًا، لا ينبغي اعتبار الحساب مؤهلًا لأن نموذجًا يثق بأن رصيد الحساب أقل من حدّ معين. يستطيع التطبيق مقارنة الرصيد مباشرة.

وليست موافقةً على السلامة بحد ذاتها. فالخيار «الآمن» الصادر عن نموذج لا يجيز تنفيذ إجراء لا يمكن التراجع عنه. استخدم الصلاحيات، وقوائم السماح، والعزل، وحدود المعاملات، وخطوات الموافقة، وسجلات التدقيق حول أي شيء يمكنه إنفاق المال، أو تغيير صلاحيات الوصول، أو إرسال رسالة إلى جهة خارجية، أو تعديل بيانات الإنتاج، أو تنفيذ شيفرة.

وليست بديلًا عن المراجعة البشرية في الحالات الملتبسة أو عالية التأثير. صحيح أن الإجابة المهيكلة أسهل في المعالجة من النص الحر، لكن التسلسل المنظم جيدًا قد يجعل حكمًا غير مؤكد يبدو أكثر حسمًا مما هو عليه. ينبغي للنظام الاحتفاظ بدرجة الثقة، ومراجع الأدلة، وسبب تصعيد الحالة.

تجربة صغيرة يمكن أن تنتج أدلة مفيدة

على الفريق الذي يدرس استخدام نقطة النهاية أن يبدأ بقرار متكرر واحد له نتيجة قابلة للقياس أصلًا. لا تبدأ بسير عمل يعتمد نجاحه على خمس استدعاءات للنموذج وعدة نقاط تسليم غير محددة جيدًا.

أولًا، اجمع عينة من المدخلات الحقيقية واطلب من مراجعين مؤهلين وسم الإجراء الصحيح. أبقِ هذه الوسوم منفصلة عن المطالبات المستخدمة في الاختبار. وأدرج الأمثلة الصعبة والحدّية بدل اختيار الحالات الواضحة فقط.

بعد ذلك، اكتب مجموعة إجابات محدودة. أضف human_review عندما يكون عدم اليقين نتيجة مشروعة. حدّد ما الذي تجيزه كل إجابة وما الذي لا تجيزه. إذا تعذّر وصف الإجراء بوضوح، فمن المرجح أن القرار واسع أكثر من اللازم.

ثم اختبر ثلاثة أوضاع تشغيل: التوجيه التلقائي عند تجاوز عتبة مرتفعة، والمراجعة ضمن نطاق متوسط، واللجوء إلى بديل آمن تحت العتبة الأدنى. قارن هذه النتائج بالعملية الحالية. فالتجربة التي تكتفي بالإبلاغ عن دقة النموذج، من دون قياس عبء المراجعين أو الأخطاء اللاحقة، لن تجيب عن السؤال التجاري.

سجّل معلومات كافية لإعادة بناء القرار من دون تخزين بيانات حساسة أكثر من اللازم. دوّن إصدار السؤال، والنموذج، والعتبة، والإجابة، ودرجة الثقة، والإجراء المتخذ، والتصحيح اللاحق. وإذا تغيّرت المطالبة، فتعامل مع التغيير كما تتعامل مع إصدار برمجي، وأعد تشغيل مجموعة التقييم.

وأخيرًا، شغّل نقطة النهاية إلى جانب سير العمل القائم قبل السماح لها بالتحكم في الإجراءات. يمكن لوضع المراقبة الصامتة أن يكشف مواضع اختلاف النموذج مع المشغلين ذوي الخبرة، ومواضع نقص الأدلة، والحالات التي يخفي فيها قرار يبدو بسيطًا سياسةً للاستثناءات.

من ينبغي له تجربتها—ومن ينبغي له الانتظار

تستحق Decisions API الاختبار لدى الفرق التي لديها بالفعل مشكلة ضيقة في التصنيف أو التوجيه أو التقييم أو التصعيد؛ وتستطيع تحديد النتائج المسموح بها؛ ولديها أمثلة موسومة تكفي لتقييم التغييرات. وتبدو واعدة خصوصًا عندما تكون عنق الزجاجة الحالي هو التأخر المتكرر في تفاعل مباشر، أو تكلفة تمرير كل قرار صغير عبر سير عمل توليدي أكبر.

وقد تلائم أيضًا المنتجات التي تحتاج إلى تقييم أسئلة مستقلة متعددة على النص أو الصورة أو السجل المهيكل نفسه. وتحسّن ميزة التخزين المؤقت للمطالبات والضوابط الإقليمية جدوى استخدامها في أعباء العمل ذات السياق المشترك المستقر والمتطلبات الواضحة للبيانات.

على الفرق الانتظار إذا كانت لا تزال تبحث عن حالة استخدام، أو لا تستطيع شرح شكل الإجابة الصحيحة، أو تخطط للسماح لنقطة النهاية باختيار أدوات وإجراءات عشوائية. فسعر الرموز المنخفض لا ينقذ سياسة غير محددة. كما لا ينبغي استخدام الاستجابة السريعة لإخفاء غياب ضوابط التفويض أو المراجعة أو التدقيق.

تكمن الدلالة الأوسع لهذا الإصدار في البنية المعمارية. فتطبيقات الذكاء الاصطناعي تبتعد عن طلب واحد كبير يحاول الفهم واتخاذ القرار والتنفيذ دفعة واحدة. ويفصل النظام الأسهل صيانةً بين هذه المهام: قد يفسر النموذج الأدلة، وقد تختار نقطة نهاية محدودة بين خيارات خضعت للمراجعة، بينما يفرض البرنامج العادي الصلاحيات وينفذ النتيجة.

هذا التقسيم لن يلغي أخطاء النماذج، لكنه يجعل قياسها واحتواءها وتصحيحها أسهل. ولهذا السبب العملي ينبغي لمعظم الفرق اختبار Decisions: ليس لأن كل سير عمل يحتاج إلى نقطة نهاية أخرى للذكاء الاصطناعي، بل لأن بعض أعباء العمل تحتاج إلى طبقة قرار أصغر وأكثر خضوعًا للمساءلة.