الوكيل يفقد البيانات بسبب حجم الجدول لا عدد الردود: 92% من الجولات صحيحة مقابل 46%

يبدو تصميم الوكيل المعتاد بسيطًا: تعيد الأداة جدولًا، فيتلقاه النموذج في سياقه ويعرضه على المستخدم بصياغته، ثم يجيب «من الذاكرة» عن الاستفسارات اللاحقة مثل «أرني فقط الرحلات بعد الساعة 21:00». يبدو ذلك غير ضار، لكن البيانات تفسد هنا تحديدًا. فالبحث حسب الحساب الصحيح، وملف JSON سليم، والمخطط متطابق، ومع ذلك يجد المستخدم في الجدول النهائي سعرًا مختلفًا أو تاريخًا خاطئًا أو رحلة مفقودة. قاس مؤلفو دراسة حديثة على arXiv هذه الظاهرة على وكيل إنتاجي حقيقي. و«الدقة» في العنوان تعني نسبة جولات الحوار التي تطابقت فيها جميع حقول جميع الصفوف مع المرجع. النتيجة الرئيسية: يتحدد تراجع الدقة بحجم الجدول، لا بعدد الردود التي مرّت. وإذا كنت تبني وكلاء، فهذا يؤثر مباشرة في البنية المعمارية وفي فاتورة الرموز (tokens).

ما الذي قارنوه

اعتمد الباحثون على AwardWise، وهو مساعد متعدد الوكلاء للبحث عن تذاكر الطيران بالأميال، مبني على Google Agent Development Kit. يختلف إصداران من النظام في طريقة إيصال البيانات فقط. أما النموذج (Gemini 2.5 Flash) ودرجة الحرارة 0,1 وقيمة top_p البالغة 0,5 والتعليمات ذات الصلة، فكلها متطابقة.

الإصدار الأول، SYNTHESIS، يكرر النمط القياسي في الأطر البرمجية. تدخل القائمة الكاملة للرحلات إلى سياق المخطِّط، فيبني الجدول بنفسه ويجيب بنفسه عن الاستفسارات اللاحقة.

الإصدار الثاني، BYPASS، هو المستخدم في النظام الإنتاجي. تُحفظ السجلات في حالة الجلسة ولا تمر أبدًا عبر توليد النموذج. يقتصر دور النموذج على تحويل طلب المستخدم إلى معاملات للمرشِّح (الفلتر)، وتنفذ التصفية شيفرة حتمية عادية، وتصل الصفوف إلى الواجهة عبر قناة جانبية منفصلة ذات أنواع محددة.

أُجري الاختبار على 24 حوارًا، بواقع 339 جولة خاضعة للتقييم لكل إصدار. جُمّدت مسبقًا ردود المزوّدين: 408 لقطات على 36 مسارًا، وأكبر مخرجات تضم 510 صفوف. المعيار صارم: لا تُعدّ الجولة صحيحة إلا إذا طابقت الحقول المرجع.

ما النتيجة

كانت الجولات الصحيحة كليًا 92,3% في BYPASS و45,7% في SYNTHESIS، أي بفارق قدره +46,6 نقطة مئوية. وعلى ثلاث عائلات من النماذج، بقي الفارق ضمن نطاق من +46,6 إلى +55,8 نقطة.

ثم تبيّن ما الذي يتوقف عليه الإخفاق. غيّر الباحثون حجم الجدول بحسب تواريخ اللقطات، وبحسب بادئات المخرجات نفسها، وبحسب مخطط «المربع اللاتيني» الذي يفصل الحجم عن موضع الجولة في الحوار. وفي كل الحالات ينهار SYNTHESIS مع نمو الجدول، بينما يبقى BYPASS مستقرًا. ويتوقف حد الانهيار على قوة النموذج: عند GPT-4o-mini هو أقل من 10 صفوف، وعند Gemini 2.5 Pro أعلى من ذلك. لكن التجاوز يحافظ على المستوى في النماذج الأربعة التي جرى اختبارها كلها: 140 من 144 تشغيلًا. ويصوغ المؤلفون الخلاصة هكذا: النموذج القوي يشتري حدًّا أعلى، والبنية المعمارية تشتري المناعة.

يرفع استبدال Gemini 2.5 Pro بـ Flash على الحوارات نفسها دقة إعادة السرد من 46% إلى 72%، لكن الجولة تصبح أغلى بنحو 5 أضعاف. إنها طريقة مكلفة لاستئجار الدقة بدلًا من تجنّب فقدانها.

المال والأخطاء والقيود

في BYPASS لا تعتمد تكلفة الجولة ولا زمن الاستجابة على حجم الجدول: نحو $0,012. أما في إعادة السرد فتنمو التكاليف مع السياق. وعند المخرجات التي تزيد على 100 صف، لا تكاد توجد إجابة صحيحة، وتكلّف كل إجابة صحيحة نحو 200 ضعف ما تكلّفه إجابة المسار الالتفافي.

أما فرضية أن الأخطاء تتسارع مع كل جولة، فلم يؤكدها الاختبار المسجَّل مسبقًا. ويرى المؤلفون أن السبب في المنهج: عند هذه النسبة المرتفعة من الإخفاق لا يوجد ما تُقارن به. لكن من الواضح أن الأخطاء تنتقل إلى ما بعدها، فالجدول الفاسد يصبح مدخلًا للجولة التالية. وفي BYPASS تُحسب كل جولة من جديد انطلاقًا من الحالة المحفوظة، ولذلك لا توجد سلسلة كهذه، والنتيجة الصفرية 0/25 تعني فقط أنه لم تُوجد أمثلة مضادة.

والقيود مهمة أيضًا. فهذا نظام واحد في مجال واحد، وأُجريت القياسات الأساسية على Gemini 2.5 Flash، وكُتبت سيناريوهات الحوار استنادًا إلى جلسات ممارس واحد متمرس في السفر بتذاكر award. ولم يُفصَّل المكسب إلى عوامله: فتخزين الحالة والمرشِّح الحتمي والقناة الجانبية قُيّمت معًا.

الخلاصة العملية: كانت القنوات الجانبية مثل LangGraph أو AG-UI تُعتمد عادةً من أجل واجهة يمكن التنبؤ بسلوكها. وتُظهر هذه الدراسة أنها تحمي البيانات أيضًا. فإذا أعادت الأداة عشرات الصفوف، فاحفظها في حالة الجلسة، وأسند التصفية إلى الشيفرة البرمجية، واترك للنموذج مهمة واحدة فقط: تحويل طلب المستخدم إلى معاملات.