المحتويات
لقد ربطت نظامًا متعدد الوكلاء، وزوّدته بالأدوات، وشغّلته عبر Agent SDK—فكيف تقيس ما إذا كان الوكيل يؤدي مهمته فعلًا؟ بالنسبة لمخرَج واحد، يمكنك تسجيله عبر تقييمات الذكاء الاصطناعي. لكن الوكيل يخطط عبر خطوات كثيرة، ويستدعي أدوات، ويتصرف بحالة (state). وحتى لو بدت الجملة الأخيرة صحيحة، فقد يكون عبر جسرًا خطيرًا في الطريق. هنا تتصدّر agent evals المشهد.
يعرض هذا المقال، استنادًا إلى المعلومات الرسمية، ما هي agent evals، وكيف تختلف عن تقييمات الـ LLM، وماذا نقيس (5 أبعاد)، وكيف نُقيّم (3 مُقيّمين)، والمزالق الخاصة بها، وسير العمل العملي مع المعايير القياسية. النقاط الأساسية أولًا. ① تقيس agent evals ليس فقط «المخرَج النهائي» بل «trajectory» الأفعال. ② توصي Anthropic بتقييم النتيجة (الحالة النهائية) لا المسار—لأن التحقق الحرفي من الخطوات هشّ. ③ ابدأ بمجموعة تقييم صغيرة من 20–50 مهمة مستخلصة من إخفاقات حقيقية، وشغّل تقييمًا آليًا.
قِس «الإجابة النهائية» و«الطريق الذي سُلِك» معًا
— تقييمات المخرَج لا تكفي؛ الوكلاء متعددو الخطوات، يستخدمون الأدوات، ولهم حالة
توصي Anthropic بـتقييم النتيجة لا المسار—لكن المسار يخبرك لماذا أخفق. استخدم كليهما، كلٌّ في موضعه.
1. ما هي Agent Evals؟
Agent evals هي عملية القياس المنهجي لما إذا كان «الوكيل»—الذي يستخدم الأدوات ويتخذ خطوات متعددة للوصول إلى هدف—قادرًا فعلًا على إنجاز مهامه. إنها تطور لـتقييمات الـ LLM التي تحكم على جودة موجِّه واحد؛ إذ يتوسع الهدف من «مخرَج واحد» إلى «سلسلة من الأفعال».
لماذا يهم ذلك: في دليلها حول agent evals، تشير Anthropic إلى أن «بناء التقييمات يزداد صعوبة كلما طال انتظارك. في البداية، تُترجَم متطلبات المنتج طبيعيًا إلى حالات اختبار»، وتوصي بأن «20–50 مهمة بسيطة مستخلصة من إخفاقات حقيقية بدايةٌ ممتازة». بعبارة أخرى، تحوّل agent evals «يبدو أنه يعمل» إلى أرقام قابلة لإعادة الإنتاج. ويقترن هذا بـقابلية المراقبة في الذكاء الاصطناعي (مراقبة التشغيل)—فالآثار (traces) التي تراقبها تصبح مادةً للتقييم.
2. لماذا تختلف عن تقييمات الـ LLM (المخرَج مقابل trajectory)
تقييمات الـ LLM التقليدية تسجّل في جوهرها «مدخل → مخرَج واحد». لكن الوكيل يخطط، ويستدعي الأدوات، وينظر في النتائج، ويقرر الخطوة التالية، ويحدّث الحالة. لذا فإن النظر إلى المخرَج النهائي وحده لا يكفي. وتقول Google كذلك إنه «لا يكفي مجرد فحص المخرجات؛ علينا فهم «لماذا» وراء أفعال الوكيل»، وتقسّم التقييم إلى عائلتين: «الاستجابة النهائية» و«trajectory». وتقول Microsoft أيضًا إن عليك «تقييم ليس فقط المخرَج النهائي، بل أيضًا جودة وكفاءة كل خطوة»، مقسّمةً ذلك إلى تقييم على مستوى النظام (من البداية إلى النهاية) وعلى مستوى العملية (خطوة بخطوة).
💡 الفكرة الجوهرية: قد تُخفي «الإجابة النهائية الصحيحة» عمليةً معطوبة. وعلى العكس، قد تكون الإجابة صحيحة لكنها بُلِغت بـالحظ أو الصدفة أو اختصارٍ خطير. لذلك بالنسبة للوكلاء، تنظر إلى «النتيجة» و«العملية» معًا. ولأساسيات تقييم المخرَج الواحد و LLM-as-judge، راجع مقال تقييمات الذكاء الاصطناعي.
3. ماذا نقيس: 5 أبعاد
إليك خمس عدسات شائعة الاستخدام لتقييم الوكلاء.
هل بلغ الهدف؟ احكم بـالحالة النهائية—ما إذا كان الحجز موجودًا في الـ DB—لا بـالتصريح اللفظي «لقد حجزتُه».
هل اتخذ خطوات معقولة؟ هل استخدم الأدوات الصحيحة بـالترتيب والعدد الصحيحين؟ وهل كانت هناك التفافات بلا جدوى أو تحركات خطيرة؟
هل اختار الأداة الصحيحة ومرّر الوسائط الصحيحة؟ افحص أسماء الدوال وأنواع الوسائط وقيمها (واكتشف الاستدعاءات غير الضرورية).
كم عدد الخطوات والرموز (tokens) والدولارات والثواني؟ الإجابة الصحيحة غير عملية إذا تضخمت التكلفة. وتحتاج إلى الربط بالمقاييس المُراقَبة.
هل المخرَج ذو صلة ودقيق وكامل؟ سجّل المحتوى المفتوح بـLLM-as-judge أو بمعيار تقييم (rubric).
ملاحظة: 4. الكفاءة (الرموز، التكلفة، زمن الاستجابة) ليست مُقَنَّنة رسميًا كـ«مقياس تقييم» لدى أي مورّد بعينه؛ ففي الممارسة تكون غالبًا إشارات قابلية المراقبة مُدخَلة في التقييم. ومع ذلك، فهي بُعد جوهري لـإيقاف وكيلٍ يدور في حلقة ويفلت من السيطرة.
4. كيف نُقيّم: 3 مُقيّمين و«النتيجة مقابل المسار»
هناك على نطاق واسع ثلاثة أنواع من المُقيّمين. وعلى نهج Anthropic، لكلٍّ منها مفاضلاته.
| المُقيّم | نقاط القوة | نقاط الضعف |
|---|---|---|
| الكود (برمجي) | سريع، رخيص، موضوعي، قابل لإعادة الإنتاج | هشّ أمام التنويعات الصحيحة / البدائل |
| LLM-as-judge (نموذج) | مرن، قابل للتوسّع، يلتقط الفروق الدقيقة | غير حتمي، أغلى ثمنًا، يحتاج إلى المعايرة مع البشر |
| البشر | المعيار الذهبي للجودة | مكلف، بطيء (تجنّبه إن أمكن) |
الخطة المعيارية: قيّم ما يمكنك بالكود، وسلّم الأجزاء الذاتية المفتوحة فقط إلى نموذج مختلف بصفته LLM-as-judge، واستعن بالبشر للفحوص العَيِّنية في النقاط الرئيسية. أما تصميم LLM-as-judge (معايير التقييم التفصيلية، المخرجات المنفصلة، تحيّز المُقيّم) فمشروح بعمق في مقال تقييمات الـ LLM.
«مطابقة المسار» الحرفية هشّة
إذًا كيف تُقيّم المسار؟ هنا تتبنى Anthropic موقفًا حازمًا: «ثمة غريزة شائعة للتحقق من أن الوكلاء اتّبعوا خطوات محددة جدًا مثل تسلسل استدعاءات أدوات بالترتيب الصحيح. لقد وجدنا هذا النهج صارمًا أكثر مما ينبغي ويؤدي إلى اختبارات هشّة بإفراط، إذ يجد الوكلاء بانتظام مقاربات صحيحة لم يتوقعها مصممو التقييم. ولكي لا نعاقب الإبداع بلا داعٍ، غالبًا ما يكون من الأفضل تقييم ما أنتجه الوكيل، لا المسار الذي سلكه». ففي حجز رحلة طيران مثلًا، تقيس ما إذا كان الحجز موجودًا فعلًا في قاعدة بيانات SQL الخاصة بالبيئة بصفته الحالة النهائية—لا التصريح اللفظي «لقد حجزتُه».
في المقابل، تقدّم Google و Microsoft درجات لمطابقة المسار (مطابق تمامًا / بالترتيب / بأي ترتيب، إلخ) بصفتها مقاييس رسمية. والاثنان غير متناقضين—تقييمات المسار جيدة في تشخيص «لماذا أخفق»، وتقييمات النتيجة تتجنّب معاقبة الإبداع الصحيح. وفي الممارسة، الحل الوسط الواقعي هو تجنّب المطابقة التامة الصارمة والتخفيف إلى فحص فعلٍ رئيسي: «هل استُدعِيت الأدوات الحرجة؟»
5. مشكلات تخص Agent Evals وحدها
تحمل agent evals صعوبات لا يحملها تقييم المخرَج الواحد.
- اللاحتمية (المدخل نفسه يسلك مسارات مختلفة): نجاح واحد لا يعني أنه يتكرر. تحتاج إلى مقاييس موثوقية مثل ما إذا كان ينجح عبر كل التشغيلات k (pass^k). تذكر ورقة τ-bench أن «النماذج تتدهور بشكل كبير مع زيادة k، كاشفةً عن عدم موثوقيتها» (الأرقام مرتبطة بلحظة زمنية محددة).
- الأخطاء المتراكمة: إذا نجحت خطوة واحدة باحتمال p، فإن t خطوة تنجح تقريبًا بـ pt. كلما طالت السلسلة، أسرع انهيارها—ولهذا ينخفض النجاح بحدة في المهام طويلة الأفق.
- اختراق المكافأة / التلاعب بالمواصفات: سلوك يُرضي نصّ المُقيّم الحرفي دون تحقيق الهدف الحقيقي. في مثال DeepMind، وضع ذراع روبوت نفسه بين الكاميرا والجسم، خادعًا المُقيّمين ليظنوا أنه أمسك بالغرض بينما لم يفعل. والتقاط «يبدو صحيحًا لكن المسار خطير» يتطلب تقييم المسار والآثار الجانبية.
- تقادم مجموعات التقييم / التلوث: عندما يتسرب معيار قياسي إلى بيانات التدريب (التلوث)، تتوقف الدرجات عن عكس القدرة الحقيقية. عليك أن تواصل تحديث تقييمات الانحدار (regression evals) مع نضج الوكيل.
مشكلة «المسار الخطير» متصلة بـحواجز حماية الذكاء الاصطناعي. فالتقييم الذي ينظر إلى الإجابة النهائية وحدها يمرّ بهذه الفِخاخ مرور الكرام.
6. سير العمل والمعايير القياسية
بالاستناد إلى توصيات Anthropic، سير العمل بسيط.
- ابنِ بحجم صغير، من إخفاقات حقيقية: لست بحاجة إلى المئات. حوّل 20–50 إخفاقًا وقع في الإنتاج إلى حالات اختبار.
- شغّل التقييم الآلي: الكود أولًا، و LLM-as-judge فقط للأجزاء المفتوحة. أعطِ الأولوية للكمّ على الجودة المُقيّمة يدويًا.
- افصل بين نوعين: تقييمات القدرة (في ماذا يبرع؟) وتقييمات الانحدار (هل ما زال يقدر على ما كان يقدر عليه؟).
- ضعه على دورة حياة: ① تقييمات آلية قبل الإطلاق (مدمجة في CI) → ② مراقبة الإنتاج → ③ اختبار A/B → ④ ملاحظات المستخدمين ومراجعة الآثار، طبقةً فوق طبقة.
- اكتبها مبكرًا: بناء التقييمات يزداد صعوبة كلما طال انتظارك.
كما أن المعايير القياسية للوكلاء المعروفة مراجع مفيدة لبناء تقييماتك الخاصة (المفتاح هو قراءة «ما الذي يقيسه كلٌّ منها»؛ والدرجات تتغير حسب النموذج والإصدار، فلا تأخذها على ظاهرها).
| المعيار القياسي | ما الذي يقيسه |
|---|---|
| SWE-bench / Verified | حلّ مشكلات GitHub الحقيقية برقعة (patch)، مُقيّمة نجاح/إخفاق عبر مجموعة الاختبارات (قائمة على التنفيذ) |
| τ-bench / τ²-bench | حوار متعدد الأدوار أداة×مستخدم في البيع بالتجزئة والطيران، إلخ + الالتزام بالسياسات؛ مُقيّم على الحالة النهائية للـ DB |
| WebArena | إتمام مهام التشغيل الذاتي للويب على نسخ واقعية لمواقع |
| GAIA | مهام المساعد العام السهلة على البشر والصعبة على الذكاء الاصطناعي (الاستدلال + الأدوات + التصفح) |
| OSWorld | استخدام الحاسوب لتشغيل واجهة رسومية على نظام تشغيل حقيقي، مُقيّم على أساس التنفيذ |
| BFCL | دقة استدعاء الدوال/الأدوات (أسماء الدوال، بنية الوسائط، القابلية للتنفيذ) |
أما من حيث الأدوات، فإن LangSmith و Braintrust و DeepEval و Arize Phoenix تدعم تقييم المسار واستدعاء الأدوات. ومعظمها يبني على الآثار، مُسجّلًا على مستوى الخطوة والتشغيلة ومجموعة البيانات. ولاحظ أن Claude Managed Agents تأتي مزوّدة بـتقييم قائم على النتائج—حيث يقيّم مُقيّمٌ منفصل وفق معيار التقييم الخاص بك—مدمجًا.
الخلاصة
Agent evals هي عملية قياس ما إذا كان وكيلٌ يستخدم الأدوات ومتعدد الخطوات قادرًا فعلًا على إنجاز مهامه. وبخلاف تقييمات الـ LLM التي تنظر إلى مخرَج واحد، فهي تفحص «الإجابة النهائية (النتيجة)» و«الطريق الذي سُلِك (المسار)» معًا. والأبعاد هي ① النتيجة ② المسار ③ استخدام الأدوات ④ الكفاءة ⑤ الجودة النهائية. قيّم بـالكود ← LLM-as-judge ← البشر، وتوصي Anthropic بـ«قيّم النتيجة (الحالة النهائية)، لا المسار» (التحقق الحرفي من الخطوات هشّ).
المزالق الخاصة هي اللاحتمية (pass^k)، والأخطاء المتراكمة، واختراق المكافأة، وتقادم مجموعات التقييم. وفي الممارسة، الخطة المعيارية هي البدء صغيرًا بـ 20–50 حالة من إخفاقات حقيقية، وتشغيل التقييم الآلي في CI، وفصل تقييمات القدرة والانحدار، وكتابتها مبكرًا. ذات صلة: تقييمات الذكاء الاصطناعي، وقابلية المراقبة، وكيفية بناء نظام متعدد الوكلاء، وManaged Agents.
الأسئلة الشائعة
س. ما هي agent evals؟
ج. عملية القياس المنهجي لما إذا كان وكيلٌ يستخدم الأدوات ومتعدد الخطوات قادرًا فعلًا على إنجاز مهامه. إنها تطور لـتقييمات الـ LLM التي تسجّل موجِّهًا واحدًا؛ إذ يتوسع الهدف من «مخرَج واحد» إلى «سلسلة من الأفعال». والسمة المميزة هي النظر ليس فقط إلى الإجابة النهائية بل إلى المسار الذي أوصل إليها (أي الأدوات استُدعِيت، وكيف).
س. كيف تختلف عن تقييمات الـ LLM المعتادة؟
ج. في ما إذا كنت تنظر إلى «مخرَج» أم «سلسلة من الأفعال». ولأن الوكيل يخطط، ويستدعي الأدوات، ويحدّث الحالة، فإن المخرَج النهائي وحده لا يكفي. فقد تُخفي إجابةٌ صحيحة عمليةً معطوبة، وقد تكون إجابةٌ صحيحة قد بُلِغت عبر اختصارٍ خطير. لذا تُقيّم النتيجة (الحالة النهائية) والمسار (العملية) معًا.
س. ماذا ينبغي أن أقيس؟
ج. الأبعاد الخمسة الشائعة: ① النتيجة (نجاح المهمة = هل تطابق الحالة النهائية الهدف؟) ② المسار (خطوات معقولة؟) ③ صحة استخدام الأدوات (الأداة الصحيحة، الوسائط الصحيحة؟) ④ الكفاءة (الخطوات، الرموز، التكلفة، زمن الاستجابة) ⑤ جودة الاستجابة النهائية (ذات صلة، دقيقة، كاملة؟). ويُدخِل البُعد الرابع إشارات قابلية المراقبة، وهو مهم لإيقاف الانفلات.
س. هل ينبغي أن أفحص المسار (الخطوات) للمطابقة التامة؟
ج. لا—المطابقة التامة الصارمة تميل إلى الهشاشة. توصي Anthropic بـ: «التحقق من أن استدعاءات الأدوات اتّبعت الترتيب الصحيح صارمٌ وهشٌّ أكثر مما ينبغي؛ فالوكلاء يجدون بدائل صحيحة، لذا من الأفضل تقييم النتيجة، لا المسار». وفي الممارسة، تجنّب المطابقة التامة وخفّف إلى فحص فعلٍ رئيسي: «هل استُدعِيت الأدوات الحرجة؟» ومع ذلك، فالمسار مفيد لتشخيص لماذا أخفق، فاستخدم كلًّا حيث يناسب.
س. كيف أبدأ؟
ج. ابدأ بـتحويل 20–50 إخفاقًا في الإنتاج إلى حالات اختبار. كما تقول Anthropic، «لست بحاجة إلى المئات؛ 20–50 مهمة بسيطة مستخلصة من إخفاقات حقيقية بدايةٌ ممتازة». قيّم آليًا—الكود لما يستطيع الكود قياسه، و LLM-as-judge بنموذج منفصل فقط للأجزاء المفتوحة—وضعه في CI لالتقاط الانحدارات. افصل تقييمات القدرة (في ماذا يبرع) عن تقييمات الانحدار (الحفاظ على ما نجح)، واكتب تقييماتك مبكرًا.
