OrderBench: لماذا لا يحمي مخطط JSON وكلاء LLM من الطلبات الخطرة

في يوليو 2026 قدّم باحثون OrderBench، وهو اختبار حتمي (deterministic) لوكلاء LLM في المطاعم. وأظهر الاختبار أنه حتى عندما يُنتج النموذج JSON مطابقًا للمخطط بنسبة 100%، يبقى نحو 20% من طلبات أقوى نموذج خاطئة دلاليًا. والخلاصة بسيطة: المخرجات المهيكلة تزيل أخطاء التحليل البرمجي (parsing)، لكنها لا تضمن أن المعاملة آمنة ودقيقة.

ما هو OrderBench

OrderBench اختبار حتمي يقيس بصورة منفصلة ست خصائص في ردّ الوكيل: الصحة النحوية، والصلاحية وفق المخطط، وصحة قرار الحالة، والدقة الدلالية للأصناف، والحفاظ على القيود، والتأكيدات غير الآمنة للطلب. والدافع وراء ذلك أن LLM باتت تعمل بشكل متزايد بوصفها «مترجمًا برمجيًا للمعاملات»: يصوغ المستخدم نيّته بكلمات عادية، فيُخرج النموذج كائنًا مهيكلًا، ثم تنفّذه واجهة API. ويزيل JSON Schema وأوضاع المخرجات المهيكلة (structured output) لدى مزوّدي الخدمة فئة كاملة من أخطاء التحليل البرمجي، لكنها وحدها لا تحسم ما إذا كانت المعاملة التي يوشك الوكيل على تنفيذها صحيحة وآمنة.

ماذا أظهرت التجربة

أجرى المؤلفون 2400 استدعاء عبر منصة Nebius Token Factory إلى أربعة نماذج مفتوحة في وضعين: موجّه (prompt) عادي، ومخطط JSON مفروض. والنتيجة الرئيسية أن الردّ الصالح وفق المخطط قد يحمل مع ذلك أخطاء دلالية كبيرة. ففي أقوى نموذج يحقق الوضعان صلاحية بنسبة 100% وفق المخطط، لكن النجاح الدلالي يبقى عند نحو 80%، أي أن كل طلب خامس صحيح شكليًا وخاطئ في جوهره. أما في النماذج الأضعف، فتُقاس نسبة التأكيدات غير الآمنة للطلب، وهي صالحة وفق المخطط، بنسب مؤكدة من رقمين.

• الاختبار: OrderBench، حتمي، مخصص لطلبات المطاعم
• الحجم: 2400 استدعاء إلى أربعة نماذج مفتوحة
• المنصة: Nebius Token Factory
• الأوضاع: prompt-only ومخطط JSON مفروض
• الرقم الرئيسي: صلاحية 100% وفق المخطط مقابل دقة دلالية بنحو 80% لدى أفضل نموذج

لماذا لا يحمي المخطط

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

«المخرجات المهيكلة طبقة واجهة ضرورية، لكنها ليست بديلًا عن التحقق

الخاص بالمجال ولا عن التنفيذ وفق مبدأ fail-closed»، كما جاء في ملخص الدراسة على arXiv.

ماذا يعني ذلك

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

أسئلة شائعة

ما هو OrderBench؟

OrderBench اختبار حتمي لوكلاء طلبات المطاعم، قُدّم في يوليو 2026. وهو يقيّم بصورة منفصلة ست خصائص في الردّ، منها التأكيدات غير الآمنة للطلبات التي لا تلتقطها أداة التحقق من مخطط JSON.

هل يضمن مخطط JSON صحة الطلب؟

لا. وفق نتائج الدراسة، يحقق الوضعان في أقوى نموذج صلاحية بنسبة 100% وفق المخطط، لكن الدقة الدلالية نحو 80%، أما في النماذج الأضعف فتجتاز نسبة مؤكدة من رقمين من الطلبات فحص المخطط وهي غير آمنة.

ماذا يعني fail-closed بالنسبة للوكيل؟

fail-closed مبدأ يرفض فيه الوكيل الإجراء عند أي غموض بدل تأكيده. ويرى مؤلفو OrderBench أنه، إلى جانب التحقق الخاص بالمجال، إضافة لازمة للمخرجات المهيكلة، لأن مخطط JSON نفسه لا يستبعد الطلبات غير الآمنة.