OpenAI تطلق Decisions API: قرارات الوكلاء أسرع بما يصل إلى 10 مرات

نقلت OpenAI واجهة Decisions API من البيتا العامة إلى الإتاحة العامة. وهي نقطة نهاية مخصصة تعمل على GPT-6 Luna وتجيب عن أسئلة لها مجموعة إجابات محددة سلفًا، وتفعل ذلك، بحسب الشركة، أسرع بما يصل إلى 10 مرات من Luna نفسه عبر Responses API. السعر: $0.10 لكل مليون رمز إدخال، و$0.01 للرموز المخزنة مؤقتًا، أما رموز الإخراج فلا حاجة لدفع أي مبلغ عنها إطلاقًا.

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

ثلاثة أنواع من الإجابات بدلًا من النص الحر

يصف المطوّر السؤال والإجابات المسموح بها، ويقدّم السياق نصًا أو صورًا أو JSON أصليًا. وتعيد الواجهة أحد ثلاثة أنواع من النتائج:

• predicate: احتمال بين 0 و1 بأن الشرط متحقق، مثل ظهور أضرار على المنتج؛
• choice: أحد الخيارات المُمرَّرة، إضافة إلى الاحتمالات وconfidence. ويناسب الاختيار من قبيل «متابعة / إعادة / استيضاح»؛
• score: تقييم على مقياس مرتب ضمن rubric، مثل شدة الضرر. وتُحسب القيمة بوصفها المتوسط المرجّح بالاحتمالات لمؤشرات المستويات.

ومن هنا تتضح الاقتصاديات. فما دامت النتيجة تُبنى كتوزيع احتمالي على الخيارات المحددة، لا يحتاج النموذج إلى توليد نص، ولا شيء يستدعي دفع رسوم على الإخراج. وكل التكلفة تقع على الإدخال. لنفترض أن مصنِّفًا يتلقى 500 رمز في كل استدعاء. فمليون استدعاء سيكلف $50. وإذا كان 400 رمز منها بادئة قابلة للتخزين المؤقت تضم التعليمات وrubric، فستبلغ الكلفة نحو $14. وهذا حساب تقريبي مبني على الأسعار المنشورة، لكنه يبيّن حجم الفارق.

ما أُضيف منذ البيتا

• تكامل أصلي مع GPT-Live: يُشغَّل القرار بمحفّز في `session.triggers` عند حدث مثل `session.input_transcript.delta`، ويتلقى التطبيق `decision.event`؛
• تخزين مؤقت للـ prompt للسياق المتكرر، مع إدخال قابل للتخزين لمدة 30 دقيقة و12 ساعة؛
• معالجة استدلال (inference) إقليمية في الولايات المتحدة والاتحاد الأوروبي، وZero Data Retention للعملاء المؤهلين؛
• مدخلات JSON أصلية وصور مباشرة داخل تعليمات السؤال؛
• ما يصل إلى 400 سؤال في الطلب الواحد، أي ضعف الحد السابق؛
• طاقة إضافية في عدة مناطق في آسيا لتقليل زمن الاستجابة.

أرقام العملاء

تورد OpenAI خمس حالات استخدام خارجية. وجميعها مأخوذة من تقييمات الشركات نفسها، ولا توجد معايير مستقلة.

• Box: توجيه المستندات، واختيار المسار أسرع بنحو ~5x على 30 شهادة تأمين وبالدقة نفسها التي يحققها Responses API. وتُحال الحالات غير المؤكدة إلى مراجعين بشريين.
• Datadog: تقييم مخاطر أوامر shell التي يولّدها الوكيل قبل تنفيذها. أسرع بـ 40 مرة بحسب p95 من نماذج frontier وبدقة مماثلة، ما أتاح وضع Decisions في المسار الحرج للمعالجة التصحيحية التلقائية.
• Ramp: ربط نفقات الذكاء الاصطناعي بالعمل الفعلي. أسرع بـ 4 مرات وأرخص بنسبة 30% من GPT-6 Luna، دون خسارة في الدقة.
• Sierra: اختيار الإجراء التالي في محادثات العملاء المباشرة. p95 أقل من 280 مللي ثانية، وأسرع بنحو 3 مرات وأرخص بنسبة 90% لكل استدعاء من النهج السابق، ودون تراجع في النتائج التي يحصل عليها العملاء.
• SpeakBox: اختصر التكامل مع GPT-Live الزمن حتى الإجراء التالي من 1.4 ثانية إلى 0.13 ثانية، أي بأكثر من 90%.

وداخل OpenAI، تستخدم فرق dots وPersonal Finance (تصنيف أوصاف المعاملات) وCommunications (وسم المنشورات بحسب الموضوعات وتقييم ما إذا كانت تعزز السرديات الرئيسية أو تنقضها) واجهة API هذه بالفعل.

من أين تبدأ

تُظهر حالة Datadog أين تكون الواجهة أكثر فائدة: فهي طبقة حماية قبل الإجراءات التي لا رجعة فيها للوكيل. فتقييم مخاطر الأمر في أجزاء من الثانية يتيح فحص كل خطوة، لا خطوات منتقاة فحسب. أما نهج Box القائم على إحالة الحالات غير المؤكدة إلى البشر فيعتمد على حقل confidence في إجابة choice.

والترتيب العملي كالتالي. حدّد القرار الذي يتخذه تطبيقك أكثر من غيره. صُغ السؤال ومجموعة مغلقة من الإجابات. اجمع أمثلة من حركة البيانات الفعلية وشغّلها في Decisions Playground على نصوصك أو صورك. قارن النتيجة بالحل الحالي على Responses API من حيث الدقة وp95 والتكلفة. واختر عتبات الاحتمال وconfidence بالاعتماد على بيانات موسومة لا بالتخمين، فعليها يتوقف عدد الحالات التي ستُحال إلى المراجعة اليدوية. وبالنسبة إلى الوكلاء الصوتيين، فالخطوة التالية هي ربط السؤال نفسه كمحفّز في GPT-Live.