When Agentic Executions Fail: Detecting and Localizing Runtime Faults from Telemetry
تقدم هذه الورقة AGENTCHAOSBENCH، وهي مجموعة بيانات مرجعية تتكون من 275 مسار تنفيذ وكيل (agentic execution traces) مع حقن أخطاء وقت التشغيل، لتوضيح أن الأساليب الحالية القائمة على النماذج اللغوية الكبيرة (LLM) تعاني في اكتشاف وتحديد مواقع الفشل التشغيلي المتنوع بدقة من خلال بيانات القياس عن بُعد (telemetry) وحدها.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
لم تعد البرمجيات الحديثة مجرد برنامج واحد يعمل على جهاز كمبيوتر، بل أصبحت غالباً فريقاً من وكلاء الذكاء الاصطناي ليعملوا معاً. تخيل قوة عاملة رقمية حيث يقوم وكيل بتخطيط رحلة، وآخر بحجز الرحلات الجوية، وثالث بالتحقق من حالة الطقس، وكلهم يتواصلون مع بعضهم البعض ويستخدمون أدوات خارجية مثل الخرائط أو التقاويم. تعتمد هذه الأنظمة على شبكة معقدة من الاتصالات: الوكلاء يتحدثون مع بعضهم، ويطلبون المشورة من نموذج لغوي كبير، ويستدعون أدوات خارجية للقيام بالعمل، ويتبعون قواعد سلامة صارمة لضمان عدم قول أو فعل شيء ضار. عندما يعمل كل شيء بشكل صحيح، ينتج الفريق إجابة صحيحة. ولكن عندما يحدث خطأ ما، قد تكون الإجابة النهائية خاطئة، أو قد يتوقف النظام ببساطة عن العمل، تاركاً المستخدم دون أي فكرة عن السبب. تكمكمن المشكلة في أن النظر فقط إلى النتيجة النهائية لا يخبرنا شيئاً عن سبب الانهيار. هل فشل النظام لأن الذكاء الاصطناي اتخذ قراراً سيئاً، أم لأن أداة كان يحتاجها كانت بطيئة، أم لأن فحص سلامة تم تجاوزه بالخطأ؟ لإصلاح هذه الأنظمة، يحتاج المهندسون إلى رؤية الرحلة بأكملها، وليس فقط الوجهة.
قام فريق من الباحثين في جامعة تورنتو ببناء أرضية اختبار جديدة للمساعدة في حل هذا الغموض. لقد أنشأوا معياراً قياسياً يسمى "AgentChaosBench"، وهو بمثابة بيئة محكومة لتعطيل فرق الذكاء الاصطناي هذه عن قصد لمعرفة ما إذا كانت أدوات التشخيص يمكنها العثور على المشكلة. أخذ الباحثون خمسة تطبيقات مختلفة من العالم الحقيقي — وهي أنظمة تكتب أكواد SQL، وتصيغ الكتب، وتدير وسائل التواصل الاجتماعي، وتنشئ صفحات الهبوط، وتساعد في عمليات التوظيف — وقاموا بمحاكاة عشر طرق مختلفة يمكن أن تفشل من خلالها. شملت هذه الإخفاقات أدوات رفضت الإجابة، وأدوات استغرقت وقتاً طويلاً للاستجابة، ورسائل ضاعت بين الوكلاء، وقواعد سلامة تم تجاوزها. لكل سيناريو معطل، قاموا أيضاً بتشغيل نسخة مثالية وخالية من الأخطاء من نفس المهمة باستخدام نفس التعليمات الأولية تماماً. سمح هذا الاقتران لهم بمعرفة ما حدث بالضبط وأين حدث. ومن خلال ذلك، أنشأوا مجموعة من 275 سجلاً مفصلاً لهذه الرحلات الرقمية.
كان جوهر عملهم هو معرفة ما إذا كان بإمكان نظام مؤتمت النظر في سجل تنفيذ فاشل وتحديد السبب بشكل صحيح. لقد جردوا البيانات من أي تسميات قد تكشف الإجابة، تاركين فقط البيانات الخام لما حدث: توقيت الاستدعاءات، ومحتوى الرسائل، وحالة كل خطوة. ثم طلبوا من نماذج ذكاء اصطناي متنوعة، تتراوح من النماذج المحلية الصغيرة إلى أقوى النماذج الرائدة المتاحة، أن تعمل كـ "محققين". كان على هذه النماذج قراءة السجل، وتحديد نوع الفشل الذي حدث، وتحديد الجزء المسؤول في النظام بدقة. كما اختبر الباحثون ما إذا كان منح المحقق نسخة من التشغيل المثالي الخالي من الأخطاء للمقارنة به سيساعد في العملية.
أظهرت النتائج أن هذه المهمة أصعب بكثير مما قد يتوقعه المرء. فحتى النماذج الأكثر تقدماً، والتي يمكنها كتابة الشعر وحل الألغاز المنطقية المعقدة، عانت بشكل كبير في تشخيص أعطال وقت التشغيل هذه. فعندما طُلب منها تحديد نوع الفشل من سجل واحد، حصل أفضل نموذج على الإجابة الصحيحة في أقل من 25 بالمائة من المرات. أما بالنسبة للنماذج الأصغر، فقد كانت نسبة النجاح أقل بك even، حيث تراوحت بين 13 إلى 19 بالمائة، وهو ما يكاد لا يتجاوز التخمين العشوائي. كانت المشكلة أكثر صعوبة عندما كان على النماذج الإشارة إلى المكون المحدد الذي فشل؛ حيث تمكنت من تحديد الجزء الصحيح من النظام بنسبة 31 بالمائة فقط تقريباً. وعندما طُلب منها القيام بالأمرين معاً — تسمية نوع الفشل وتحديد موقعه — انخفض معدل النجاح إلى 22 بالمائة فقط لأفضل نموذج.
كشفت الدراسة أن بعض الإخفاقات أسهل في الرصد من غيرها. فالأخطاء التي تنتج إشارات واضحة، مثل أداة تعيد رسالة خطأ صريحة أو أداة استغرقت وقتاً طويلاً جداً للاستجابة، تم تحديدها بشكل متكرر أكثر. ومع ذلك، ظلت الإخفاقات الأكثر خطورة ودقة غير مرئية تقريباً. فعندما يتم تجاوز قاعدة سلامة، مما يسم يسمح لطلب كان ينبغي حظره بالمرور، فشلت النماذج دائماً تقريباً في ملاحظة ذلك. وبالمثل، عندما تكون استجابة الأداة تالفة أو عندما ينفد من النظام مساحة الذاكرة، لم تستطع النماذج التمييز بين هذه المشكلات والسلوك الطبيعي بشكل موثوق. وجد الباحثون أن تقديم نسخة مرجعية مثالية للمقارنة بها ساعد في بعض الحالات، مثل تحديد متى كانت الأداة بطيئة بشكل غير عادي أو عندما حاول النظام استخدام الكثير من الذاكرة. ومع ذلك، لم يساعد هذا التباين في حالات تجاوز السلامة أو البيانات التالفة، لأن المخرجات المعطلة كانت لا تزال تبدو منطقية، وفحص السلامة بدا وكأنه قد اجتاز الاختبار بالفعل.
يوضح هذا العمل أنه بينما بنينا أنظمة متطورة لتنسيق عدة وكلاء ذكاء اصطناي، فإننا لم نبنِ بعد الأدوات اللازمة لفهم سبب فشلها بشكل موثوق. إن الجيل الحالي من نماذج التشخيص، حتى الأكبر والأكثر قدرة منها، لا يمكنه بعد أن يميز باستمرار بين أداة معطلة، أو شبكة بطيئة، أو تخطي فحص سلامة، أو عملية طبيعية. ويخلص الباحثون إلى أن إصلاح هذه الأنظمة سيتطلب أساليب جديدة تتجاوز مجرد طلب قراءة سجل من نموذج لغوي كبير. ويقترحون أن الحلول المستقبلية قد تعتمد على مقارنة التنفيذات الحالية مع التنفيذات الجيدة المعروفة أو تطوير أدوات متخصصة مصممة خصيصاً للبحث عن هذه الأعطال التشغيلية، بدلاً من الاعتماد على الذكاء العام وحده. إن الطريق إلى الأمام يتضمن بناء طرق أفضل لرؤية الشقوق غير المرئية في الآلات الرقمية قبل أن تتسبب في انهيار النظام بأكمله.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.