بقلم: نور | محررة الأبحاث والدراسات · صوت تحريري بإشراف بشري
في 11 من أصل 14 نموذجاً لغوياً كبيراً، أثبت استدعاء الأدوات عبر الكود البرمجي (Programmatic Tool Calling) أنه يضاهي أو يتفوق على الطريقة التقليدية القائمة على JSON — هذا ما خلص إليه بحث جديد نشره أربعة باحثين من Ishan Patel وSahil Sen وElias Lumer وVamse Kumar Subbiah على منصة arXiv في أغسطس 2026، ليُعيد طرح سؤال كان يُعدّ محسوماً: هل JSON هو الطريق الوحيد لتسليح النماذج اللغوية بالأدوات الخارجية؟
المشكلة التي يعالجها البحث ليست نظرية. حين تتحول النماذج اللغوية إلى وكلاء فاعلين، فإنها تحتاج إلى استدعاء أدوات خارجية — قواعد بيانات، APIs، خدمات سحابية — وكان الأسلوب السائد يقتضي توليد استدعاءات JSON مهيكلة، وهو نهج يعاني من صلابة بنيوية تجعل تسلسل الأدوات وتشغيلها بالتوازي أمراً معقداً. ما يقترحه البحث بديلاً هو تقديم الأدوات للنموذج كـPython stubs مُصنَّفة الأنواع، بحيث يستدعيها النموذج من خلال كود مباشر، ويتولى النظام تنفيذ هذا الكود وإعادة النتائج في دورة وكيل واحدة.
اعتمد الباحثون على معيار BFCL v4 — Berkeley Function Calling Leaderboard — لقياس الأداء عبر 14 نموذجاً لغوياً من أجيال مختلفة، وهو ما يمنح النتائج مصداقية مقارنةً بالتجارب المعزولة. أبرز ما رصده البحث هو أن عائلة GPT-5 حققت تحسناً بنسبة 10.6% مقارنةً بأسلوب JSON الأساسي (وفقاً للبحث)، وهو رقم لافت لأنه يتجاوز ما يُعزى عادةً لتحسينات هامشية في الضبط الدقيق.
لكن الأرقام الأكثر إثارة تأتي في سيناريوهات الضغط الحقيقية. حين اختُبر الأسلوبان تحت ما يُسميه الباحثون “التوازي المتشعب” (parallel fan-out) — أي تنفيذ استدعاءات متعددة في آنٍ واحد — أبدى الأسلوب البرمجي استقراراً أو تفوقاً في 13 من 14 نموذجاً. والأكثر دلالةً عملياً هو اختبار “تعفّن السياق” (context rot)، وهو ظاهرة تحدث حين يتراكم السياق طويلاً ويبدأ الأداء في الانهيار: JSON تراجع بمتوسط 2.3% في هذه الظروف، بينما ظلّ الأسلوب البرمجي ثابتاً (وفقاً للبحث).
ما يكشفه هذا النمط هو أن المشكلة ليست مجرد اختلاف في صياغة الأوامر. النماذج الأحدث والأكثر قدرةً على الكود تستفيد من التمثيل البرمجي بشكل طبيعي، لأنها تعاملت معه في بيانات التدريب. في المقابل، نموذج واحد فقط من الـ14 أظهر أداءً أفضل مع JSON — وهو ما يُشير إلى أن الاستثناء قائم ومن المرجح أن يرتبط بطبيعة التدريب الخاصة لذلك النموذج.
الدلالة العملية بالنسبة لمن يبني وكلاء ذكاء اصطناعي اليوم واضحة: إن كنتَ تستخدم نموذجاً قادراً على الكود — وهو الحال مع معظم النماذج الكبرى الحالية — فإن تحويل أدواتك إلى Python stubs بدلاً من JSON schemas قد يمنحك تحسيناً مجانياً في الأداء دون أي تدريب إضافي. وهو ما يجعل التساؤل مشروعاً: كم من المشاريع تقيّدت بـJSON لا لأسباب تقنية بل لأنه كان الخيار الافتراضي الأول؟
البحث لا يدّعي أن الأسلوب البرمجي خالٍ من المخاطر؛ فتنفيذ كود مولَّد من نموذج يظل سطح هجوم أوسع من مجرد استدعاء JSON مُقيَّد. لكنه يُثبّت نقطة جوهرية: أداء النموذج يتتبع قدرته العامة عبر الأجيال، وكلما تحسّنت النماذج في الكود، زاد العائد من هذا الأسلوب — وهو ما يجعله مراهنةً طويلة الأجل على اتجاه واضح في تطور النماذج اللغوية.
