يكشف اختبار مرجعي جديد لـ 12 من واجهات برمجة تطبيقات النماذج اللغوية الكبيرة (LLM APIs) أن كل خدمة تقريبًا تعيد تنسيق JSON يطابق المخطط (schema) المطلوب، ولكن هناك أقلية كبيرة تخرج قيمًا خاطئة واقعيًا. وتتراوح تكلفة الرموز (tokens) لنفس المخطط من بضع عشرات من الرموز إلى ما يقرب من خمسة آلاف رمز. لم يعد بإمكان المطورين الذين يبنون مسارات الاستخراج أو الوكلاء المعتمدين على البيانات الوثوق بعبارة "صحة المخطط" كمؤشر على "الصحة".

لماذا يهم هذا الاختبار

تروج شركات توفير واجهات برمجة التطبيقات لـ "المخرجات المهيكلة" (structured output) كوسيلة للقضاء على أخطاء التحليل (parsing). الوعد بسيط: أعطِ النموذج مخطط JSON، وسيقوم بملء الحقول دون الحاجة إلى كتابة كود معالجة لاحقة هش. ومن الناحية العملية، تعتمد العديد من أنظمة الإنتاج بالفعل على هذا الضمان لتجنب الانهيارات والحفاظ على نظافة مسارات التحليلات اللاحقة. وعندما يكون هذا الضمان صحيحًا جزئيًا فقط، تتسلل الأخطاء البرمجية بصمت، وتخرج حسابات التكلفة القائمة على استخدام الرموز عن المسار الصحيح تمامًا.

الأخبار الجيدة: المخططات تُفرض الآن في الغالب

  • أنتجت معظم النماذج في مجموعة الاختبار JSON اجتاز فاحصًا صارمًا.
  • فك التشفير المقيد (Constrained decoding) – النماذج التي تقيد فك التشفير بالمخطط لا يمكنها إصدار أحرف عشوائية، لذا فإن الحمولات المشوهة أصبحت منقرضة عمليًا.
  • معدلات أخطاء التحليل – لم يعد المطورون بحاجة إلى تغليف كل استدعاء بكتل try-catch لتجنب فشل بناء جملة JSON.

الأخبار السيئة: الصحة ≠ الدقة

الشكل الصحيح لا يضمن القيمة الصحيحة. أربعة من النماذج الاثني عشر — وهي DeepSeek V4 و Qwen و GLM-5.2 (الآخران يظهران تحت اسمين مختلفين في التقرير) — أنتجت JSON منسقًا بشكل مثالي ولكنه احتوى على أرقام خاطئة عندما تم تفعيل وضع "التفكير" (أو سلسلة الأفكار - chain-of-thought).

  • في نموذج Qwen، انتقل استخراج حسابي بسيط من إجابة واحدة صحيحة من أصل 16 مع تفعيل الاستنتاج إلى 8 إجابات صحيحة من أصل 8 عند تعطيل الاستنتاج.
  • أظهر DeepSeek V4 Pro تباينًا مماثلاً: ارتفعت دقة الاستخراج من 1/8 إلى 7/8 بمجرد أن توقف النموذج عن محاولة شرح خطواته.

تتداخل خطوة الاستنتاج الإضافية مع فك التشفير المقيد، مما يسمح للنموذج بالانزلاق نحو الهلوسة مع الاستمرار في احترام الأقواس الخارجية.

الجانب القبيح: مفاجآت تكلفة الرموز والمعلمات المتجاهلة

  • تنسيق استجابة Claude – عند الوصول إليه من خلال نقاط نهاية متوافقة مع OpenAI، تجاهل Claude تمامًا علامة response_format ، حيث كانت المخرجات المتوافقة مع المخطط بنسبة 0%. يدعم النموذج الاستدعاءات المهيكلة، ولكن فقط عبر واجهة استدعاء الأدوات (tool-call) الأصلية الخاصة بـ Anthropic.
  • تضخم رموز المخطط – مخطط متواضع بحجم 12 كيلوبايت يكلف 30 رمزًا في DeepSeek، ومع ذلك استهلكت نفس الحمولة 4,959 رمزًا في Claude.
  • عدم اتساق الفواتير – يحسب بعض الموردين المخطط كجزء من المطالبة (prompt)، ويفرضون رسومًا على كل رمز يستهلكه؛ بينما يعامله آخرون كطبقة إضافية مجانية. وعند العمل على نطاق واسع، يمكن أن تتجاوز فاتورة المخطط تكلفة المحتوى الذي ولده النموذج.

ما يجب على المطورين فعله الآن

  1. تحقق من القيم، وليس فقط الأشكال – لن يكتشف فاحص المخطط الإجابة الرقمية غير الصحيحة حتى لو كانت تتوافق مع النوع المتوقع. أضف فحوصات خاصة بالمجال (النطاق، الوحدة، الاتساق بين الحقول).
  2. أوقف تشغيل سلسلة الأفكار (chain-of-thought) لعمليات الاستخراج في DeepSeek و Qwen و GLM عندما تحتاج إلى ملء حقول موثوق. خطوة الاستنتاج الإضافية اختيارية وليست مطلوبة للدقة.
  3. دقق في استخدام الرموز – سجل عدد الرموز التي يستهلكها كل طلب، بما في ذلك جزء المخطط، وقارن الفواتير بين الموردين قبل الالتزام بعمليات نشر واسعة النطاق.
  4. اختبر قابلية النقل – المخطط الذي يعمل على OpenAI قد يتم تجاهله بصمت في Gemini أو Claude. قم بإجراء فحص سريع للتأكد من السلامة على كل منصة مستهدفة قبل إرسال الكود.

وجهة نظر معارضة من الموردين

يجادل بعض الموردين بأن وضع "التفكير" هو خيار للمطور مخصص للمهام التي يفوق فيها الشرح أهمية دقة الاستخراج المجردة. يتجاهل Claude علامة response_format ويقترح استخدام استدعاءات الأدوات الأصلية لـ Anthropic بدلاً من ذلك. هذه التفسيرات صحيحة تقنيًا، لكنها تنقل العبء إلى المطورين لمعرفة أي وضع يجب اختياره وكيفية وضع ميزانية لرسوم الرموز المخفية.

الخلاصة

لم يعد مخطط JSON شبكة أمان؛ إنه مجرد شكل. تأكد من أن البيانات الموجودة بداخله تطابق الواقع، وراقب تكاليف الرموز المخفية، وتذكر أن "تفكير" النموذج يمكن أن يفسد حتى المخرجات التي تبدو الأكثر نظافة.