فريق Ubicloud يجد أن 2 من كل 25 نداء أداة في vLLM تخرج خاطئة بسبب إعداد افتراضي تغيّر

نشر Jesse Donkervliet وJunhao Li على مدونة Ubicloud في 20 أكتوبر 2026 قياسًا لدقة نداءات الأدوات، أي الـ tool calls، على خادم vLLM. وكانت النتيجة 92% على الإصدار 0.28 مع نموذج Kimi K2.6، أي أن 2 من كل 25 نداء تخرج خاطئة. ولم يكن السبب في النموذج.

فالنموذج يختار الـ tokens بالاحتمالات، ولا يتحقق من الـ schema الخاص بالأداة. فقد يُخرج اسم أداة غير موجودة، أو اسم حقل خاطئًا، ويستقبله الخادم ويمضي.

والحل المعروف لهذه المشكلة هو الـ constrained decoding. فعند كل خطوة توليد، يحجب الخادم الـ tokens غير المسموح بها وفق الـ schema، باستخدام structural tags مولّدة من الـ schema نفسه عبر مكتبة XGrammar. وبذلك لا يستطيع النموذج أن يُخرج نداءً غير صالح من الأساس.

وتروي المقالة كيف ظهر الخلل. كان الفريق يعمل على fork خاص يحقق 100%، ثم عاد إلى النسخة الرسمية من vLLM في الإصدار 0.25، فهبطت الدقة إلى 91%. والسبب أن vLLM غيّر الإعداد الافتراضي، فلم يعد يشغّل الـ constrained decoding إلا إذا طُلب صراحة. أي أن التنفيذ كان سليمًا، والذي تغيّر هو الافتراضي. وحين أعاد الفريق تفعيله وشغّل اختبار K2VV ToolCall مجددًا، عادت الدقة إلى 100%.

وأضاف الإصدار 0.31 من vLLM هذه الميزة كـ flag على مستوى الخادم، ثم أُضيف خيار tool-strict-level للتحكم في درجة التشديد.

وتشير المقالة إلى مشكلات مع نماذج أخرى حين يكون هذا الإعداد مفعّلًا افتراضيًّا، منها gpt-oss-20b وQwen 3.6 وGLM 5.1، لكنها بلاغات من مستخدمين لا قياسات أجراها الفريق.

وبالنسبة للفرق التي تستضيف agents بنفسها، قد تكون نسبة أخطاء في نداءات الأدوات قائمة منذ أشهر بسبب سطر إعدادات. وهو خلل لا يظهر في العرض التجريبي، بل في سجلات الـ production.