عمليات إعادة المحاولة المحدودة لاستدعاءات أدوات الوكيل
لم تكن أسوأ حادثة تسبب فيها الوكيل الخاص بنا هي إجابة خاطئة، بل كانت حلقة مفرغة (loop).
فشل استدعاء أداة ما. حاول الوكيل الإعادة. فشلت المحاولة مرة أخرى. استمر الوكيل في المحاولة. استهلك ذلك الكثير من الـ tokens وضرب الـ API الخاص بنا مئات المرات في دقيقة واحدة.
فعل الوكيل ما أمرناه به. لقد أخبرناه بأن يعيد المحاولة إذا فشلت أداة ما، لكننا نسينا أن نخبره متى يتوقف.
عمليات إعادة المحاولة مفيدة للأخطاء المؤقتة. المشكلة هي أن الوكلاء لا يستطيعون التمييز بين الخطأ المؤقت والخطأ الدائم. وبدون قيود، يستمر الوكيل في إعادة محاولة استدعاء معطل حتى يتوقف شيء ما عن العمل.
تستخدم الأكواد التقليدية حدوداً لإعادة المحاولة. أما استدعاءات أدوات الوكيل فقد نقلت هذا القرار إلى منطق النموذج (model reasoning). وهذا جعل الحلقة المفرغة غير مرئية وغير محدودة.
قمنا بإصلاح ذلك عن طريق إضافة ميزانيتين خارج النموذج:
• سقف لكل استدعاء: تحصل أداة معينة على عدد محدد من المحاولات. إذا فشلت، يجب على الوكيل تجربة مسار مختلف. • ميزانية لكل جلسة: للمهمة بأكملها حد أقصى لإجمالي استدعاءات الأدوات. إذا وصل الوكيل إلى هذا الحد، فإنه يتوقف ويطلب المساعدة.
الحد في حد ذاته ليس هو الحل. ما يحدث بعد الوصول إلى الحد هو المهم.
إذا توقفت ببساطة، سيعلق الوكيل. بدلاً من ذلك، نعطي الوكيل رسالة واضحة؛ نخبره بأن الاستدعاء قد فشل وأنه يجب ألا يعيد المحاولة. هذا يحول الحلقة المفرغة إلى قرار. وعادةً ما يختار الوكيل بعد ذلك نهجاً جديداً.
منذ أن أضفنا هذا، اختفت حلقات سوء استخدام الأدوات تقريباً. وعندما تحدث، يتم تصعيدها بشكل منظم بدلاً من التسبب في فواتير API ضخمة.
العثور على الحد المناسب أمر صعب. فالحد الضيق يقتل المهام الطويلة، والحد الواسع يسمح بحلقات مكلفة. لقد وضعنا حدودنا بناءً على طول المهام عند المئين الخامس والتسعين (95th percentile).
هل لديك طريقة أفضل لضبط هذه الميزانيات؟ أخبرني في التعليقات.
Optional learning community: https://t.me/GyaanSetuAi