وكيلك نجح في المهمّة مرّة — هل سينجح تاني؟ قياس ثبات الوكلاء خطوة بخطوة

المستوى: متقدّم — يفترض إلمامًا بمفاهيم الوكلاء (AI Agents) ومقاييس تقييم النماذج.
وقت القراءة: نحو 10 دقائق.
هتحتاج: وصولًا لمستودع مفتوح المصدر على GitHub، وإلمامًا ببايثون لتشغيل الأمثلة.

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

معظم اختبارات الأداء المرجعية (Benchmarks) تخفي هذا التذبذب خلف متوسّط واحد. على اختبار AppWorld، نجح وكيل ReAct يستخدم GPT-4.1 في 77.4% من التشغيلات عبر خمس محاولات متكرّرة. لكنه نجح في كل المحاولات الخمس لـ53.0% فقط من المهامّ — فجوة اتّساق (Consistency Gap) مقدارها 24.4 نقطة مئوية.

المقياس اللي شبه محدّش بيبلّغ عنه

التقييم القياسي للوكلاء بيبلّغ عن مقياس Mean@k: شغّل الاختبار k مرّات، واحسب متوسّط معدّل النجاح. غالبًا k=3، وأحيانًا 1 بس. ده الرقم اللي بيظهر على كل لوحة صدارة، وده معنى «دقّة 77%» عمليًا.

Mean@k بيجاوب على سؤال «قدّ إيه هذا الوكيل جيّد، في المتوسّط؟». لكنه ما بيجاوبش على السؤال اللي بيهمّ المستخدم الحقيقي: هل هيفضل جيّدًا لو سألت نفس السؤال بالظبط تاني؟ عشان تجاوب على السؤال ده، محتاج مقياس Pass^k: نسبة المهامّ اللي الوكيل بينجح فيها في كل المحاولات الـk.

تنبيه: Pass^k مش Pass@k. المقياس المألوف Pass@k متفائل — بيسأل هل نجحت محاولة واحدة على الأقلّ من k، وهو السؤال الصحيح لمّا تقدر تتحقّق وتعيد المحاولة. Pass^k هو انعكاسه المتشائم: كل محاولة لازم تنجح. نفس الحروف، سؤال معاكس تمامًا. والعلاقة الثابتة دايمًا: Pass^k ≤ Mean@k ≤ Pass@k.

ليه الوكلاء بيتذبذبوا؟

كل مرّة يقرّر فيها وكيل شيئًا — أي واجهة برمجية يستدعي، أي معامل يمرّر، هل يعيد المحاولة — القرار ده بيخرج من توزيع احتمالي على الرموز التالية. المهمّ هو شكل التوزيع. توزيع حادّ بيضع معظم كتلته على رمز واحد، فنفس الاختيار بيطلع تكرارًا بعد تكرار. توزيع مسطّح بيوزّع كتلة متقاربة على عدّة رموز شبه متعادلة، ومين هيفوز قريب من رمية عملة.

الشكل ده بيحدّد قدّ إيه من الضجيج محتاج عشان يغيّر النتيجة. التوزيعات الحادّة مرنة؛ التوزيعات المسطّحة عرضة للتقلّب مع أي دفعة بسيطة. ولأن المسار الكامل للوكيل بيسلسل عشرات القرارات، احتمال صغير للتقلّب في كل خطوة بيتراكم ليصبح احتمالًا كبيرًا إن تشغيلة ما تسير بشكل مختلف. من هنا بتيجي فجوة الـ24 نقطة.

الخطوات: التشخيص ثم الإصلاح

إرشادات الاتّساق (Consistency Guidelines) بتيجي من خطّ أنابيب بمرحلتين، بيندمج مع آلية ALTK-Evolve الموجودة أصلًا:

1. الكشف — محلّل الاتّساق (Consistency Analyzer). بمسار مسجَّل واحد فقط، المحلّل بيعيد تشغيل كل خطوة قرار عبر إعادة أخذ عيّنات مضبوطة، قائسًا قدّ إيه مخرَج النموذج بيتغيّر فعليًا عند النقطة دي. عمليًا، ده استدعاء نموذج إضافي واحد لكل خطوة قرار، بيحصل مرّة واحدة دون اتّصال، باستخدام معامل أخذ العيّنات لسحب k استجابة دفعة واحدة (k=5 افتراضيًا) — إعادة تشغيل ضدّ السياق المسجَّل أصلًا، مش استدعاءات أدوات جديدة، ولا تشغيلًا كاملًا ثانيًا للمهمّة. النتيجة درجة اتّساق لكل خطوة قرار، مسجَّلة في بطاقة تقييم تحدّد بالضبط أي القرارات معرَّضة للتقلّب في التشغيلة التالية.
2. التوليد — إرشادات موجَّهة. كل خطوة مُعلَّمة بتتحوّل لمرشَّح إرشاد اتّساق بصيغة ALTK-Evolve القياسية، عشان تندمج في خطّ التخزين والاسترجاع الموجود. مثال حقيقي، مولَّد من GPT-4.1 من مسار مهمّة AppWorld «كم نشاطًا موجود في قائمة أمنياتي حسب ملاحظتي على SimpleNote؟»:

   [Guideline 1] When counting checkbox-style markers in note content,
   use a line-anchored regex match rather than a plain substring count —
   note titles often repeat the marker symbol in a legend line.
   
   [Guideline 2] Always verify search results for note queries by
   checking for multiple matches and confirming the correct note
   before proceeding.

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

النتائج

على اختبار AppWorld test_normal (168 مهمّة) بوكيل ReAct على GPT-4.1، فجوة الاتّساق انخفضت تقريبًا للنصف: Pass^5 الإجمالي ارتفع من 53.0% إلى 69.0%، بينما Mean@5 ارتفع من 77.4% إلى 81.0% — تضييق الفجوة بين «يبدو قادرًا» و«يمكن الاعتماد عليه» من 24.4 نقطة إلى 12.0 نقطة فقط. قرابة ثلث المهامّ اللي كانت غير متّسقة سابقًا صارت مهامّ ينجح فيها الوكيل في كل تشغيلة على الإطلاق. Mean@5 ما نزلش أبدًا في أي مستوى صعوبة — شرط أساسي وضعه الباحثون، لأن نظامًا يرفع الاتّساق على حساب الدقّة المتوسّطة يكون قد نقل عدم الموثوقية فقط، لا أصلحها.

والإرشادات بتعمّم: مطبَّقة على مهمّة مختلفة لكن مرتبطة في نفس سيناريو AppWorld، لسّه بترفع Pass^5 بمقدار 13.0 نقطة — أقلّ بـ3 نقاط فقط من رقم المهمّة نفسها، ما يشير إلى أن الإرشاد ملتقط لنمط قابل للتعميم، لا مجرّد ترقيع لمسار واحد بعينه.

جرّب بنفسك

1. افتح مستودع ALTK-Evolve مفتوح المصدر على GitHub — صار يتضمّن محلّل الاتّساق وتوليد إرشادات الاتّساق المستخدَمَين في هذه التجارب.
2. سجّل مسارًا واحدًا لوكيلك على مهمّة حقيقية من مهامّك.
3. شغّل محلّل الاتّساق عليه — استدعاء نموذج إضافي واحد لكل خطوة قرار، بلا حاجة لمقيِّم ولا إعادة تشغيل حيّة، ما يخلّيه صالحًا للاستخدام على حركة إنتاج فعلية لا يمكنك عادةً إعادة تشغيلها من الصفر ولو مرّة واحدة.
4. راجع بطاقة التقييم الناتجة، وطبّق الإرشادات المولَّدة على نفس السياق.
5. قارن Pass^k قبل الإصلاح وبعده على 5 تشغيلات متكرّرة لنفس المهمّة.

الدرس العملي الأهمّ لو بتشحن وكيلًا: بلّغ عن Pass^k جنب Mean@k. المتوسّطات ما تقدرش تميّز بين وكيل موثوق ووكيل محظوظ، وحتى k=3 هيكشف فجوة ما كنتش تعرف بوجودها. وتوقّع أن تتّسع الفجوة مع صعوبة المهمّة، وما تلجأش لنموذج أكبر كحلّ أوّل — الاتّساق محور مستقلّ عن القدرة، والنموذج الأقوى بيرفع Mean@k من غير ما يقلّل فجوة الاتّساق بالضرورة.

المصادر: Hugging Face — 2026-09-15