وكيل بمرشّح وقناة جانبية يحقق 92,3% من الخطوات الصحيحة تمامًا مقابل 45,7% عند إعادة سرد الجدول

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

في مخطط SYNTHESIS تدخل القائمة الكاملة للصفوف إلى سياق النموذج، فيعيد إنتاج الجدول بنفسه في كل مرة. أما في مخطط BYPASS، المعتمد في بيئة الإنتاج، فتُحفظ السجلات في حالة الجلسة وتصل الصفوف إلى الواجهة دون المرور بالنموذج. المقياس الرئيسي هو نسبة الخطوات التي تصحّ فيها جميع الحقول في جميع الصفوف: 92,3% لـ BYPASS مقابل 45,7% لـ SYNTHESIS.

وبلغ الفارق الزوجي بينهما 46,6 نقطة مئوية. وتتحدد الأخطاء بحجم الجدول في السياق، لا بعدد الخطوات.

ما الذي قورن وكيف

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

في SYNTHESIS، وهو النمط الكلاسيكي في ADK، يعالج النموذج التوضيحات مثل «الرحلات التي تغادر بعد 21:00 فقط» «في ذهنه» ثم يطبع الجدول من جديد. أما في BYPASS فيقتصر دوره على ترجمة طلب المستخدم إلى وسائط لمرشّح حتمي. ويعمل المرشّح على مجموعة السجلات المحفوظة، وتُرسل الصفوف إلى العميل في أحداث مصنّفة النوع بجانب تدفق رموز النموذج، لا عبره. وخطأ ترجمة الطلب إلى وسائط ينتج شريحة بيانات واحدة خاطئة لكنها حقيقية. أما إعادة السرد فتعرّض كل حقل في كل صف في كل خطوة للخطر.

قُيّم 24 حوارًا، بواقع 339 خطوة مقيَّمة لكل شرط. صيغت الحوارات على غرار جلسات ممارس خبير في السفر بالمكافآت (award travel). حُسبت الإجابة المرجعية بواسطة المُقيِّم الإنتاجي للمرشّحات، وجرى التحقق صفًا بصف وحقلًا بحقل، مع تصفير الخطوة عند أي نتيجة خاطئة. تضم المدونة 408 لقطات للنتائج على 36 مسارًا، وأكبر نتيجة تضم 510 صفوف. وعلى ثلاث عائلات من النماذج يتحول هذا الفارق نفسه البالغ 46,6 نقطة مئوية إلى فارق يتراوح بين 46,6 و55,8 نقطة مئوية.

انهيار الدقة بحسب حجم الجدول

لفصل الحجم عن عدد الخطوات، أجرى المؤلفون عدة تجارب. تفاوتت عشرون حوارًا على أربعة مسارات في حجم النتائج. وأعطى «سلّم» من ستة مسارات النموذجَ أول K صفًا من النتيجة نفسها، فبقي المحتوى ثابتًا. وفصل المربع اللاتيني بين الحجم وموضع الصف. في كل تصميم ينهار SYNTHESIS مع نمو الجدول، بينما يبقى BYPASS مستقرًا. أما الجدول الضابط، المطابق بايتًا ببايت للجدول المشكل، فيحافظ على مستواه حتى في الحالات التي سجّل فيها مخطط إعادة السرد صفرًا.

تختلف عتبة الانهيار من نموذج إلى آخر. وعلى أربعة نماذج تتراوح من أقل من 10 صفوف لدى GPT-4o-mini إلى قيم أكبر بوضوح لدى Gemini 2.5 Pro. ويبقى BYPASS مستقرًا على النماذج الأربعة جميعها (140 من 144 تشغيلًا). ويصوغ المؤلفون الخلاصة هكذا: قدرة النموذج تشتري عتبة أعلى، أما المناعة فتمنحها المعمارية وحدها.

كلفة الانهيار والقيود

لا تعتمد تكلفة الخطوة في BYPASS على حجم الجدول، وتبلغ نحو $0,012. أما في SYNTHESIS فعند جداول تتجاوز 100 صف لا تكاد توجد إجابات صحيحة، وتكلّف كل إجابة صحيحة نحو 200 ضعف هذا السعر الثابت. ويرفع استبدال Flash بـ Gemini 2.5 Pro دقة إعادة السرد من 46% إلى 72%، لكن الخطوة تصبح أغلى بنحو خمسة أضعاف. وبحسب تقدير المؤلفين، فإن شراء الدقة من نموذج أكبر بديل مكلف عن التخلي عن إعادة السرد.

لم تتأكد الفرضية المسجّلة مسبقًا عن التراكم الفائق للخطية للأخطاء عبر خطوات الحوار. فالنموذج الصفري يبلغ حد الإشباع حين يكون احتمال الفشل في الخطوة الواحدة مرتفعًا أصلًا. لكن تتبّع القيم أظهر أن الإخفاقات ليست مستقلة: فالنتيجة الفاسدة تصبح مدخلًا للخطوة التالية. أما BYPASS فيعيد حساب الإجابة في كل مرة من الحالة المحفوظة، ولذلك لا مجال هناك لانتشار الخطأ بهذه الطريقة.

وقد حُددت القيود صراحةً أيضًا. فالفارق يعكس الأثر المشترك لثلاثة اختلافات بين المعماريتين، ولم يفصل المؤلفون مساهمة كل منها على حدة. ويتطلب ذلك شروطًا منفصلة، وقد تُركت لعمل مستقبلي. وعملت الشروط الرئيسية على Gemini 2.5 Flash الموروث من تاريخ المنتج، لا لأنه اختير عمدًا. وخلال العمل كشفت القياسات ثمانية عيوب في الإعداد، ثلاثة منها في المرجع الخاص بالمؤلفين، إضافةً إلى تصحيحين في دلالات المرجع وثلاثة أخطاء في بيئة الإنتاج. صُحّح كل ذلك، وجميع الأرقام الرئيسية مستخلصة بعد التصحيحات.

الخلاصة للمطورين: ظهرت القناة الجانبية المصنّفة النوع في LangGraph وAG-UI وVercel Data Parts وGoogle A2UI من أجل عرض متوقَّع للواجهة. وتُظهر هذه الدراسة أنها تحل في الوقت نفسه مسألة الصحة. فإذا كان السياق يضم عشرات الصفوف أو مئاتها، فيجب أن يراها المستخدم دون تشويه. لذلك ينبغي حفظ السجلات في الحالة وتصفيتها بشيفرة حتمية، بدلًا من مطالبة النموذج بإعادة كتابتها من جديد.