OrderBench: почему JSON-схема не спасает LLM-агентов от опасных заказов

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

ما هو OrderBench

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

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

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

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

لماذا لا يُنقذ المخطط الموقف

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

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

الخاص بالمجال (domain verification) والتنفيذ القائم على مبدأ fail-closed"، بحسب ما جاء في ملخص الدراسة على arXiv.

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

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

أسئلة شائعة

ما هو OrderBench?

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

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

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

ماذا يعني مبدأ fail-closed بالنسبة للوكيل?

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