تحويل المدخلات إلى قرارات

حوّل النصوص والصور إلى قرارات يستطيع تطبيقك استعمالها.

تقيّم Decisions API النصوص والصور وJSON، وتعيد أجوبة محددة النوع. يمكنك الحصول على احتمال تحقق شرط، أو اختيار من مجموعة ثابتة، أو درجة وفق معايير محددة. يستعمل تطبيقك هذه الأجوبة لتصنيف المحتوى، وتوجيه الطلبات، وترتيب أولوية العمل.

جرّب Decisions API في Playground لتختبر الأسئلة والمدخلات قبل كتابة الكود.

الأسعار والإتاحة

الواجهة متاحة للاستخدام العام، والنموذج المدعوم حاليًّا هو gpt-6-luna. تكلفة المدخلات غير المخزنة مؤقتًا 0.10 دولار لكل مليون رمز. لا تُفرض تكلفة على رموز المخرجات. راجع الأسعار والإتاحة للاطلاع على السعر الحالي.

إعداد مفتاح الخدمة

أنشئ مشروعًا للتجربة وافتح مجلده في المحرر:

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

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

أضف اسم الملف إلى .gitignore حتى لا تنشر المفتاح مع كود المشروع. إذا تسرّب المفتاح، ألغِه من المنصة وأنشئ غيره.

من داخل مجلد المشروع، أضف مكتبة الخدمة ومكتبة تحميل ملف البيئة كما تعلمنا في درس إضافة الحزم:

ضع النسخ الكاملة للدوال التالية بعد هذا الإعداد في decisions_demo.py. حفظ السر منفصلًا يجعل مشاركة الكود وتغيير المفتاح أسهل.

نشغّل الملف داخل بيئة المشروع:

الاختيار من خيارات ثابتة

نبدأ بسؤال يعيد قيمة من خيارات نحددها. نوع السؤال choice يناسب الفئات التي لا يوجد بينها ترتيب عددي: قسم الفوترة ليس «أعلى» من قسم الدعم.

نص: توجيه الطلب إلى الفريق

شكل الاستجابة والجواب

تُرجع المكتبة كائنًا اسمه هنا decision، وفيه model لاسم النموذج، وusage لبيانات الاستهلاك، وanswers لقائمة الأجوبة. نقرأ خصائصه بالنقطة، مثل decision.answers. يوضح هذا المقتطف بصيغة JSON شكل قائمة الأجوبة؛ القيم توضيحية:

السؤال هنا من نوع choice؛ لذلك نتعامل مع جواب اختيار أو رفض. سنستعمل النوعين الآخرين في الأمثلة التالية. مرجع الأجوبة يبين حقول كل نوع.

الدالة كاملة:

لنجرب الطلب ونرى الفريق ودرجة الثقة معًا. أضف الاستدعاء بعد تعريف الدالة، ثم شغّل الملف:

ناتج توضيحي لهذا الطلب:

العنصر الأول هو الفريق المختار، والثاني درجة الثقة باختياره.

تقدير درجة الاستعجال

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

نضيف تعريف السؤال قبل الدالة في الملف نفسه:

نضيف دالة تحوّل الدرجة إلى مستوى استعجال باستعمال عتبتين، ونعالج الرفض بالطريقة السابقة:

نجرب الحالات الثلاث بعد تعريف الدالة:

ناتج توضيحي، بالترتيب نفسه:

أسئلة متعددة على المدخل نفسه

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

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

ثانيًا، نستبدل دالة التوجيه بالدالة التالية. ترسل الأسئلة المعرّفة أعلاه، ثم تجمع الأجوبة في قاموس. مثال التوثيق يستدعي الخدمة؛ قد تختلف قيم الأجوبة، لكن أسماء المفاتيح تبقى نفسها:

ناتج توضيحي للدالة عند وصف عطل يمنع الشراء؛ القيم قد تختلف عند التشغيل:

تفسير الأجوبة واتخاذ الإجراء

أصبحت النتائج جاهزة للاستعمال بأسماء الأسئلة. يقرأ المستدعي الفريق والشدة واحتمال تعطّل الشراء من القاموس، ويتحقق من الرفض قبل استعمال النتيجة.

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