اختبر وكيل AI بالنتيجة لا بكلامه: الحجز الوهمي قد يبدو ناجحًا

ابدأ تقييم الوكيل بتحديد ما يجب أن يتغير في بيئة الاختبار، ثم افحص ذلك التغير بمعزل عن رده للمستخدم. في مثال تعرضه مراجعة Anthropic الهندسية، قد يقول وكيل حجز الرحلات إن الحجز اكتمل، بينما يُحسم نجاح المهمة بوجود حجز في قاعدة بيانات البيئة.

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

عرّف النجاح من الحالة التي يتركها الوكيل

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

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

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

ابنِ مجموعة بيانات فيها نجاح وتعذر وامتناع

كل صف في المجموعة مهمة مستقلة لها مدخلات ثابتة وبيئة تبدأ من حالة معروفة. القالب التالي مثال افتراضي لصف حجز؛ أسماء الرحلات والأدوات فيه قيم توضيحية، ويستبدل بها الفريق قيم منتجه الفعلية:

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

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

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

وزّع التصحيح بين قواعد حتمية وحكم لغوي ومراجعة بشرية

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

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

المصحح النموذجي يفيد عندما يتطلب الحكم فهم الرد: هل أوضح سبب التعذر؟ وهل نقل حالة الأداة من دون اختلاق تأكيد؟ أعطه طلب المستخدم ونتائج الأدوات اللازمة للحكم، ومعيارًا مكتوبًا، وخيار «لا يمكن الحكم» عندما تنقصه المعلومات. لا تسمح لدرجة صياغة الرد بأن تمحو فشل فحص الحالة النهائية.

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

قارن الإصدارات على المهام والبيئة نفسيهما

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

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

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

اقرأ أيضًا:

• لا تقس نجاح AI بالساعات الموفرة وحدها: اختبر السرعة والجودة والجهد
• OpenAI تكشف ستة انحرافات: وكيل نشر ملفًا عامًا كي يستشهد به
• هل تنقل عملك إلى AWS السعودية؟ اختبر أربعة عوامل قبل ديسمبر