Verified Tool Calls Improve LLM Agent Reliability Under Non-Atomic Failures

تخيل أنك قبطان سفينة فضائية، ولكن بدلاً من قيادة السفية بنفسك، أنت تتحدث إلى روبوت مساعد ذكي ومحب للدردشة. مهمتك هي إعطاء الروبوت تعليمات، مثل "شغّل المحرك" أو "أرسل إشارة استغاثة". في عالم الذكاء الاصطناوي، تُسمى هذه الروبوتات الوكلاء اللغويين الكبيرين (LLM agents)، وتُسمى الأشياء التي يتفاعلون معها الأدوات (tools) (مثل البرامج الحاسوبية أو قواعد البيانات). لفترة طويلة، افترض العلماء أنه عندما يطلب الروبوت من الأداة القيام بشيء ما، فإن الأداة ستقول فوراً: "تم!" أو "عذراً، فشلت العملية!". كان الأمر يشبه لعبة تنس طاولة مثالية حيث تعود الكرة دائماً على الفور.

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

المشكلة: لغز "هل نجح الأمر؟"

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

لكن أنظمة الكمبيوتر الحقيقية تشبه مكتب بريد مزدحم. أحياناً يتم تسليم الرسالة، ولكن إيصال "تم التسليم" يضيع في البريد. وأحياناً تصل الرسالة، لكن الشخص الذي يفحص صندوق البريد لم يرها بعد (تأخير). وأحياناً يتم تسليم الرسالة بشكل جزئي فقط. في الورقة البحثية، أطلق المؤلفون على هذه الحالات اسم الإخفاقات غير الذرية (non-atomic failures). كلمة "ذرية" تعني أن الشيء يحدث دفعة واحدة، مثل مفتاح الضوء الذي يُغلق أو يُفتح. أما "غير ذرية" فتعني أنها عملية فوضوية، تتضمن تأخيرات وخطوات جزئية.

عندما يواجه وكيل الذكاء الاصطناعي هذه الفوضى، فإنه غالباً ما يصاب بالذعر. إذا أرسل أمراً ولم يتلقَّ رداً (انتهاء المهلة)، فإنه يفكر: "أوه لا، لم ينجح الأمر!" ثم يحاول مرة أخرى. ولكن إذا كان الأمر الأول قد نجح بالفعل، فإن الوكيل يتسبب للتو في إنشاء نسخة مكررة. تخيل أنك تطلب بيتزا، ولم تتلقَ رداً من المتجر، فتقوم بالاتصال بهم خمس مرات. الآن لديك خمس بيتزا بدلاً من واحدة. في العالم الرقمي، قد يعني هذا إرسال خمس رسائل بريد إلكتروني غاضبة لعميل أو خصم المبلغ من بطاقة الائتمان خمس مرات.

الحل: "الغلاف" الذي يتحقق أولاً

لإصلاح ذلك، بنى المؤلفون "غلافاً" بسيطاً وخفيف الوزن (طبقة أمان) حول الأدوات التي يستخدمها الوكلاء. وقد أطلقوا عليه اسم نظام التحقق قبل إعادة المحاولة (verify-before-retry).

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

1. الطريقة القديمة (إعادة المحاولة الساذجة): تطرق المسمار. لا تسمع صوت "خبطة"، فتظن أنك أخطأت الهدف. تطرق مرة أخرى. ثم مرة أخرى. ينتهي بك الأمر بثقب ضخم ومُدمر في الحائط لأنك استمررت في الطرق رغم أن الصورة كانت معلقة بالفعل.
2. الطريقة الجديدة (التحقق قبل إعادة المحاولة): تطرق المسمار. لا تسمع صوت "خبطة". بدلاً من الطرق فوراً مرة أخرى، تنظر إلى الحائط. تتحقق: "هل الصورة معلقة؟"
   • إذا كانت الصورة هناك، تتوقف. لا تطرق مرة أخرى.
   • إذا لم تكن الصورة موجودة، حينها فقط تطرق المسمار مرة أخرى.

يضيف هذا الغلاف ثلاث قواعد ذكية لسلوك الوكيل:

1. الفصل بين الإشارة والواقع: مجرد عدم تلقيك رسالة "نجاح" لا يعني أن الإجراء قد فشل.
2. التحقق قبل إعادة المحاولة: قبل أن يحاول الوكيل تنفيذ أمر ما مرة أخرى، يجب عليه أولاً التحقق من الحالة الفعلية للعالم (النتيجة النهائية أو الـ postcondition) ليرى ما إذا كانت المهمة قد اكتملت بالفعل.
3. استخدام "مفتاح سحري" (Idempotency): إذا اضطر الوكيل لإعادة المحاولة، فإنه يستخدم "مفتاحاً سحرياً" (مفتاح التكرار أو Idempotency key). هذا يخبر نظام الكمبيوتر: "مهلاً، أنا أحاول هذا الأمر مرة أخرى، ولكنه هو الطلب نفسه بالضبط. إذا كنت قد نفذته بالفعل، فتجاهل هذا الطلب الثاني".

ما وجدوه: أخطاء أقل، ونفس مستوى النجاح

اختبر الباحثون هذه الفكرة في بيئة محاكاة حيث تعمدوا إفساد الأشياء ليروا كيف ستكون ردة فعل الوكلاء. أنشأوا مهمتين رئيسيتين:

• تفعيل عميل: إنشاء حساب مستخدم وإرسال رسالة ترحيب واحدة بالضبط.
• تسجيل فاتورة: تحديث فاتورة وتحديدها كمدفوعة.

قاموا بحقن أنواع مختلفة من "سوء الحظ" في النظام، مثل مهلات الشبكة، وتأخر التحديثات، والإخفاقات الجزئية. وقارنوا بين طريقة "إعادة المحاولة فقط" وطريقة "التحقق أولاً" الجديدة.

كانت النتائج واضحة ومثيرة للإعجاب:

• الإجراءات المكررة: كانت الطريقة القديمة كارثية عندما تسوء الأمور. في مهمة "تفعيل العميل"، عندما كانت حالات الفشل متكررة، أرسل الوكيل القديم رسائل ترحيب مكررة بنسبة 72% من الوقت. أما وكيل "التحقق قبل إعادة المحاولة" الجديد فقد خفض هذه النسبة إلى 20% فقط. وفي مهمة "تسجيل الفاتورة"، أنشأ الوكيل القديم سجلات مكررة بنسبة 76% في حالات الفشل العالية، بينما انخفضت هذه النسبة لدى الوكيل الجديد إلى 20% (بعد أن كانت 0% عند الفشل المنخفض و16% عند الفشل المتوسط).
• نجاح المهمة: لم يكتفِ الأسلوب الجديد بمنع الأخطاء فحسب، بل ساعد الوكلاء أيضاً على إتمام مهامهم بشكل أفضل. بالنسبة لمهمة العميل، حقق الوكيل الجديد نجاحاً بنسبة 100%، حتى عندما كان النظام معطلاً. بينما انخفض معدل نجاح الوكيل القديم إلى 64% عندما تصبح الأمور فوضوية. وبالنسبة لمهمة الفاتورة، كان المستوى الأساسي قوياً بالفعل (بتحقيق 100% عند الفشل المنخفض و96% عند الفشل العالي)، لكن الغلاف الجديد ضمن نسبة نجاح 100% حتى عند أعلى مستويات الفشل، محافظاً على الموثوقية حيث انخفض المستوى الأساسي قليلاً.

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

لماذا هذا مهم؟

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

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