مسارات النماذج وقدراتها

نموذج يدعم ميزةً ويرفضها

أرسِل إلى عائلة gpt-6 من OpenAI طلبًا يتضمّن أدوات دالّية على نقطة النهاية التقليدية /v1/chat/completions فيُرفض الطلب رفضًا صريحًا:

400 Bad Request
Function tools with reasoning_effort are not supported.
Use /v1/responses or set reasoning_effort to 'none'.

أرسِل النموذج نفسه والأدوات نفسها والمُوجِّه نفسه إلى /v1/responses فيستجيب بشكل طبيعي — على قناتَي المخرجات المهيكلة كلتيهما، مع جهد استدلال أو بدونه. لم يتغيّر شيء في النموذج. العنوان وحده هو ما تغيّر.

ما المقصود بالمسار

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

لهذا صار تعبير “OpenAI API” ملتبسًا اليوم: فهناك اثنان، يتداخلان، ولا يفرضان القواعد نفسها.

لماذا توجد واجهتا API من الأساس

أخلّت نماذج الاستدلال بنموذج الرسائل. فالاستدلال الداخلي للنموذج ليس رسالة: فهو ليس شيئًا قاله لك، ولا شيئًا قلته له. ولا يملك Chat Completions سوى قائمة من الرسائل، فلا مكان لديه للاستدلال — وما لا يستطيع تمثيله يُسقطه بين الأدوار.

صُمِّم Responses API حول هذه الفجوة تحديدًا. فالاستدلال عنصر أصيل في القائمة المُعادة؛ ويمكن أن يعود مُشفَّرًا ويُعاد تمريره في الدور التالي، فيتابع النموذج من تفكيره ذاته بدلًا من إعادة بنائه.

القدرات تشير إلى اتجاهات مختلفة

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

كيف يقيس Entity Enricher مسارًا

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

يُنفَّذ السلّم كاملًا — قنوات المخرجات المهيكلة، والرؤية، وPDF، والصوت، والبحث على الويب، والاستدلال والتحكم في مستوى جهده لكل طلب — مرة واحدة لكل مسار يمكن للموجِّه اختياره. ولدى كل مزوّد تقريبًا يعني ذلك مسارًا واحدًا، ويكلّف الفحص تمامًا ما كان يكلّفه دائمًا؛ ولا يُقاس مرتين سوى المزوّدين على شاكلة OpenAI، الذين يمكن فعلًا الوصول إليهم بطريقتين.

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

القبول ليس كالفهم

رمز HTTP 200 يثبت أن الطلب قُبِل، لا أن النموذج قرأ المرفق فعلًا — فقد يقبل المزوّد صورةً بكل سهولة ويسلّمها إلى نموذج لا ينظر إليها أبدًا. لذلك فإن كل فحص يحمل حمولةً إنما يحمل حمولةً يمكن التحقق من إجابتها:

الادّعاءات في مقابل القياسات

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

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

قراءتها داخل المنتج

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

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

ماذا يعني هذا لك