OpenAI تتيح Decisions API للجميع بإجابات مصنّفة أسرع عشر مرات من Responses

أعلنت OpenAI خروج واجهة Decisions API من النسخة التجريبية العامة وإتاحتها للجميع. الواجهة لا تكتب نصاً. تقرأ ما ترسله إليها من نصوص أو صور أو بيانات JSON، ثم تعيد إجابة محددة النوع: احتمالاً لصحة شرط ما، أو خياراً من قائمة مغلقة، أو درجة على سلّم تقييم. وتقول الشركة إنها أسرع بنحو 10 مرات من Responses API (وفقاً لـ OpenAI). هذه أرقام معلنة من الشركة نفسها، ولم يتسنَّ التحقق منها بشكل مستقل، ولا يذكر التوثيق ظروف القياس ولا حجم الطلبات المستخدمة فيه.

الفكرة بسيطة لكنها تمس جزءاً كبيراً من تطبيقات الذكاء الاصطناعي الفعلية. كثير من استدعاءات النماذج اللغوية في الإنتاج لا تهدف إلى توليد نص، بل إلى سؤال من نوع: هل هذه التذكرة شكوى فوترة؟ إلى أي قسم يجب تحويل الطلب؟ ما مدى خطورة هذا البلاغ؟ تقترح OpenAI أن تُستخدم الإجابات لتصنيف المحتوى وتوجيه الطلبات وترتيب أولويات العمل داخل التطبيق، بحسب توثيق الشركة. والطلبات تُرسل إلى POST /v1/decisions باستخدام نموذج gpt-6-luna، وهو النموذج الوحيد المدعوم حالياً. ويمكنك تجربة الأسئلة والمدخلات في Playground قبل كتابة أي سطر برمجي.

منذ إطلاق النسخة التجريبية أضافت OpenAI تسع قدرات، بحسب التوثيق نفسه. أولاها التخزين المؤقت للتعليمات (prompt caching) لإعادة استخدام المدخلات المشتركة بين الطلبات مع خصم على الجزء المخزن. ثم صار ممكناً إرفاق صور داخل تعليمات كل سؤال لمقارنتها بالأدلة المشتركة، وتمرير بيانات JSON مباشرة عبر جزء محتوى من نوع input_json. وارتفع الحد الأقصى إلى 400 سؤال في الطلب الواحد بعد أن كان 200 في النسخة التجريبية (وفقاً لـ OpenAI). وأصبحت الواجهة تقبل روابط صور مستضافة عبر HTTP أو HTTPS إلى جانب روابط base64 المضمنة. وتستطيع أيضاً تقييم سجل محادثة كامل يشمل الرسائل واستدعاءات الدوال والأدوات المخصصة ومخرجاتها. وأضيفت تقارير استخدام على مستوى المؤسسة لتتبع عدد الرموز والطلبات، وتكامل أصيل مع GPT-Live يسمح له باستدعاء Decisions مباشرة أو تشغيل قرار عند وصول نصوص الإدخال أو الإخراج. وآخرها دعم Private Link لإرسال الطلبات عبر اتصال خاص.

يتكون كل طلب من ثلاثة حقول: model وهو النموذج المقيّم، وinput وهو الدليل المشترك بين الأسئلة، سواء كان نصاً واحداً أو مصفوفة مرتبة من الرسائل واستدعاءات الأدوات ومخرجاتها، وquestions وفيه نوع كل سؤال وتعليماته والخيارات أو المستويات المسموح بها. وتعود الاستجابة بمصفوفة answers، وكل إجابة تحمل الاسم الفريد الذي أعطيته لسؤالها. أما أنواع الأسئلة فثلاثة: predicate يتحقق من شرط مثل وجود ضرر ظاهر أو صلة فقرة بسؤال، ويعيد احتمالاً بين 0 و1 (وفقاً لـ OpenAI). وchoice يختار قيمة واحدة من القيم التي حددتها، مثل قسم أو فئة محتوى. وscore يقيّم المدخل على مستويات مرتبة مثل شدة المشكلة، ويعيد المتوسط المرجح بالاحتمالات لأرقام المستويات، لذلك قد تقع النتيجة بين مستويين. النوعان الأخيران يحسبان احتمالات على خيارات منفصلة، والفرق أن choice للفئات التي لا ترتيب بينها كالأقسام، وscore للمستويات المرتبة.

إذا أردت تجربة الواجهة على حالة حقيقية، فهذا التسلسل العملي مبني على أمثلة التوثيق:

1. ابدأ من Playground. جرّب صياغة السؤال قبل الكود. يعرض التوثيق ثلاثة أمثلة: سؤال «هل في هذا المنتج انبعاج؟» على صورة منتج أعاد احتمال 1.00، وسؤال عن نية الإلغاء على رسائل مثل «ألغِ اشتراكي قبل التجديد القادم» أعاد 1.00، وسؤال صلة الإجابة على «هل يمكنني إرجاع منتج بعد 30 يوماً؟» مقابل نص سياسة يقول إن الإرجاع مقبول خلال 30 يوماً من التسليم أعاد 0.90 (بحسب OpenAI).
2. اختر نوع السؤال الصحيح. predicate لأسئلة نعم أو لا، وchoice للتوجيه بين فئات غير مرتبة، وscore للترتيب حسب الشدة أو الأولوية. أعطِ كل سؤال اسماً فريداً لأنه المفتاح الذي ستطابق به الإجابة.
3. مرّر البيانات المهيكلة كما هي. ضع كائن JSON أو مصفوفة في الحقل data داخل جزء input_json في رسالة المستخدم، دون تحويله إلى نص. مثال التوثيق يقيّم تذكرة دعم تقول «أرجو استرداد الرسوم المكررة» مقابل سجل طلب فيه رسمان بقيمة 49 و49، عبر سؤال predicate باسم duplicate_charge (بحسب OpenAI).
4. للصور، صُغ التعليمات بدقة. مثال فحص الضرر يطلب البحث عن «شق أو تمزق أو انبعاج» مع تجاهل الظلال وأي ضرر في التغليف. الصورة تُمرّر كرابط base64 مضمن أو رابط HTTP/HTTPS عام. ويوفر التوثيق الشيفرة بلغات curl وNode.js وPython وGo وJava وRuby.
5. لتقييم محادثة، رتّب العناصر وطابقها. أدرج الرسائل واستدعاءات الأدوات ومخرجاتها بالترتيب، واربط كل مخرج باستدعائه عبر call_id. رسالة المستخدم تقبل النص والصور وJSON، ورسائل developer وsystem تقبل نصاً فقط وتُعامل رسائل system كرسائل developer، ورسائل المساعد تقبل نص الإخراج أو الرفض، ومخرجات الأدوات تقبل النص والصور.
6. تعامل مع الرفض في الكود. كل الأمثلة الرسمية تفحص إن كانت الإجابة من نوع refusal قبل قراءة الاحتمال. لا تفترض أن كل سؤال سيعود برقم.

{
  "model": "gpt-6-luna",
  "input": [{ "role": "user", "content": [
    { "type": "input_text", "text": "Evaluate the ticket using the order evidence." },
    { "type": "input_json", "data": {
      "ticket": { "body": "Please refund the duplicate charge." },
      "order": { "charges": [49, 49] } } } ] }],
  "questions": [{ "type": "predicate", "name": "duplicate_charge",
    "instructions": "Does the ticket describe a duplicate charge supported by the order?" }]
}

هناك فخاخ يذكرها التوثيق ويسهل تجاوزها. مفاتيح مثل role أو image_url داخل data تبقى بيانات عادية، فلن تنشئ رسائل ولن تجلب صوراً. ودعم input_json محصور في دور المستخدم، ولا يغيّر شكل الإجابة. ولا تقبل الواجهة الملفات ولا الصوت ولا مراجع العناصر. والأهم أن Decisions لا تنفذ شيئاً: هي تعيد الإجابة، وتطبيقك هو من يشغّل الإجراء. أما إن كنت تحتاج كائناً يتبع مخطط JSON خاصاً بك، كاستخراج حقول أو كتابة شرح، فالتوصية الرسمية هي Structured Outputs مع Responses API، أو function calling إن أردت أن يطلب النموذج استدعاء أداة بمعاملات.

في تقديرنا، هذه من أكثر إضافات OpenAI عملية هذا العام لمن يبني أنظمة دعم أو مراجعة محتوى أو وكلاء يحتاجون نقاط قرار سريعة، لأنها تحوّل التصنيف من نص حر يحتاج تحليلاً إلى رقم يمكن وضع عتبة عليه. لكن قبل نقل خط إنتاج كامل إليها، انتبه إلى ثلاثة أمور: الاعتماد على نموذج واحد هو gpt-6-luna دون بديل، وغياب أي تسعير صريح في صفحة الدليل باستثناء الإشارة إلى خصم التخزين المؤقت، وعدم وجود بيانات منشورة عن معايرة الاحتمالات. فهل احتمال 0.90 يعني فعلاً صواباً في تسع حالات من عشر؟ هذا ما ستحتاج إلى قياسه على بياناتك قبل أن تبني عليه قراراً آلياً. وتجدر الإشارة إلى أن هذا المقال يستند إلى مصدر وحيد هو توثيق OpenAI الرسمي.

مقالات ذات صلة

اختراق OpenCode يسرّب مفاتيح API ويكشف عجز النماذج المقيدة عن دعم المدافعين

اليوم

OpenAI تتيح Decisions API لجميع العملاء وتدخل سباق نماذج القرار أمام Jev

اليوم

تقرير OpenAI يوثّق تعطيل وكيلين برمجيين مراقبة الانحراف وإنكار أحدهما ذلك

اليوم