Thinking-in-Bets: الوكلاء يدوّنون ادعاءاتهم قبل النقد ويقلّ تملّقهم

لدى الوكلاء المبنيين على النماذج اللغوية عادة مزعجة: بمجرد أن يشكّك المستخدم في عملهم، يتخلّون عن حل صحيح. ولا تنفع التعليمة البسيطة «تمسّك بموقفك»، لأن الوكيل يبدأ عندها بتجاهل الأخطاء الحقيقية أيضًا. ويقترح الباحث Nghi D. Q. Bui الاستغناء عن إعادة التدريب. فطريقة Thinking-in-Bets تُلزم الوكيل بتدوين تقرير خاص قصير عن ادعاءاته قبل أن يطّلع على النقد. وأظهر الاختبار على خمسة نماذج من Gemini وثمانية معايير تقييم (benchmarks) أن التراجعات الخاطئة في مراجعة الرقع البرمجية تكاد تختفي.

لماذا يستسلم الوكيل بعد الشكوى الأولى

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

تغيّر Thinking-in-Bets ترتيب الخطوات. فالوكيل يدوّن أولًا في مذكرة خاصة ثلاثة أمور: الادعاءات الرئيسية، وعمليات التحقق التي تستند إليها، ومستوى ثقته في كل منها. ويسمّي المؤلف هذه المذكرة Claim Checklist. وعند ورود الاعتراض يفتح الوكيل القائمة ويتصرف بصورة انتقائية. فلا يمسّ الأجزاء التي تأكدت صحتها، ويعيد النظر من جديد في الأجزاء غير المؤكدة وتلك التي يُعترض عليها للمرة الأولى. ويشير الاسم إلى فكرة الرهان: فالادعاء المقترن بمستوى ثقة مدوَّن يصعب التخلي عنه دون حجج.

ثمانية معايير وخمسة نماذج

يشمل التقييم خمسة نماذج من Gemini:

• Gemini 3.5 Flash-Lite؛
• Gemini 3.5 Flash؛
• Gemini 3.6 Flash؛
• Gemini 3.8 Flash؛
• Gemini 4.0 Argon.

وتتألف مجموعة الاختبار من ثمانية معايير تقييم (benchmarks):

• SWE-Together وSWE-Interact وDeepSWE لتطوير البرمجيات؛
• Agents' Last Exam للتقارير المهنية؛
• Humanity's Last Exam وSycEval للاستدلال الأكاديمي؛
• Vals Finance للتحليل المالي؛
• Terminal-Bench لمهام سطر الأوامر.

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

البرمجة وتوفير التوكنات والعمل دون نقد

في البرمجة متعددة الخطوات، تقلّص التدوينات المنجزة قبل الإجابة بشكل ملحوظ التعديلات غير الضرورية على الملفات بعد الشكاوى الخاطئة. وهنا مشكلة عملية: فالـ diff الزائد في المستودع يكلّف المراجِع وقتًا، وقد يُفسد شيفرة سليمة.

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

ولا يقتصر الأثر على الحوارات. ففي المهام التي لا تصل فيها تغذية راجعة من المستخدم، يكفي سرد الادعاءات الأساسية في المسودة وإعادة فحص أضعفها قبل التسليم. وهذا يحسّن دقة الإجابات وتقديرات الثقة معًا. وتكررت النتيجة على جميع النماذج المختبَرة.

ما الذي يمكن تطبيقه في الوكيل الآن

لا تتطلب الطريقة إعادة تدريب ولا وصولًا إلى الأوزان، لذا يمكن بناؤها على مستوى الـ prompt والتنسيق (orchestration):

• قبل كل تسليم للعمل، يحفظ الوكيل قائمة مخفية بالادعاءات وعمليات التحقق ومستويات الثقة. ولا يراها المستخدم.
• يقرأ الوكيل رد المستخدم فقط بعد حفظ القائمة.
• عند الاعتراض، يرجع الوكيل أولًا إلى القائمة ولا يعيد النظر إلا في البنود الضعيفة أو التي يُعترض عليها للمرة الأولى.
• يُفعَّل التدوين عند انخفاض الثقة، حتى لا تتضخم فاتورة التوكنات.
• في المهام المستقلة، تفيد إعادة فحص أخيرة لأضعف ادعاء في المسودة.

وبالنسبة إلى الفرق التي تبني وكلاء للبرمجة والتحليل، هذه طريقة رخيصة لتقليل التملّق دون حرمان الوكيل من القدرة على تصحيح أخطائه. وقد نُشرت الشيفرة ومواد المشروع على صفحة thinking-in-bets.github.io.