الـ evals لوكلاء الذكاء الاصطناعي: كيف تعرف أنه يعمل قبل أن يخبرك عميل

في كل مشروع وكيل لحظة متوقعة. يعدّل أحدهم سطرًا في التعليمات، ويجرّب ثلاثة أمثلة يدويًا، فيرى إجابات أفضل، فيُطلِق التعديل. وبعد أسبوعين تصل شكوى عن حالة كانت تعمل على ما يرام.

يحدث ذلك لأنه لم تكن هناك وسيلة لمعرفة أن التعديل كسر شيئًا آخر. والـ eval هو تحديدًا تلك الوسيلة.

ما هو، ببساطة

مجموعة التقييم قائمة حالات. لكل حالة مُدخل — رسالة عميل حقيقية، مستند حقيقي — ومعيار لما يُعدّ معالجة صحيحة لها. تُشغَّل المجموعة كاملة على الوكيل فيعود إليك رقم: كم حالة نجحت.

هذا كل شيء. أما التعقيد فيأتي لاحقًا؛ و80% من القيمة في امتلاك الرقم نفسه.

بلا الرقم، يكون الحديث عن الجودة: «جرّبته وصار أفضل». ومعه: «انتقلنا من 71 من 100 إلى 84، والثلاث عشرة التي كسبناها كلها استفسارات فوترة». الحديث الثاني يمكن أن تجريه مع عميل. الأول لا.

لماذا لا تحتاج البرمجيات العادية إلى هذا

دالة تجمع رقمين لها اختبار: يدخل 2 و3، ويخرج 5. إما 5 وإما لا، وإن كانت 5 فهي 5 دائمًا.

أما وكيل يُسأل «هل شُحن طلب الصناديق؟» فيمكنه الرد بعدد لا نهائي من الطرق الصحيحة وعدد لا نهائي من الطرق الخاطئة، ويمكن أن يعطي للسؤال نفسه مرتين إجابتين مختلفتين كلتاهما جيدة. لا توجد مساواة تُقارن بها.

لذلك تغيّر السؤال. بدل «هل المخرج هو هذا بالضبط؟»، تسأل:

• هل استدعى الأداة الصحيحة بالمعاملات الصحيحة؟
• هل تطابق القيمة التي أوردها ما في النظام المرجعي؟
• هل صعّد إلى شخص حين كان ينبغي ذلك؟
• هل امتنع عن اختلاق المعلومات حين لم تكن لديه؟

الثلاثة الأولى يمكن التحقق منها بالشيفرة. والرابع يحتاج إلى حكم، وهنا يدخل النموذج الحَكَم.

كيف تُبنى فعلًا

الحالات تأتي من العمل، لا من الخيال

هذا أكثر خطأ نراه. يجلس أحدهم ليكتب حالات اختبار فيُنتج خمسين سؤالًا مرتّبًا سليم الصياغة تتوفر فيه كل المعلومات اللازمة من الرسالة الأولى.

الرسائل الحقيقية لا تشبه ذلك في شيء. فيها أخطاء إملائية، ورسائل صوتية مفرَّغة، وثلاثة أسئلة في رسالة واحدة، و«ألو؟» وحيدة عند الحادية عشرة ليلًا، ولقطات شاشة بدل أرقام الطلبات.

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

التوزيع أهم من الحجم

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

وإلى جانب التوزيع الطبيعي، خصّص حصة لما يكسر النظام:

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

وهذه الفئة الأخيرة هي الأكثر غيابًا والأسرع تحوّلًا إلى مشكلة علنية.

كيف تُستخدم

تعمل المجموعة وحدها، عند كل تغيير، قبل النشر. وإذا انخفضت النتيجة، لا يُنشر التغيير.

وبعد ذلك تهمّ ثلاثة أرقام، ويُستحسن إبقاؤها منفصلة:

الأول يخبرك إن كان النظام قد تحسّن. والثاني هو ما يهمّ العمل: وكيل بنسبة نجاح 95% لكنه يصعّد 60% من الحالات لا يكاد يحلّ شيئًا. والثالث يرصد الانزياح — نموذج حدّثه المزوّد، أو كتالوج تغيّر — حين لا يكون أحد قد مسّ شيئًا.

الدورة التي تجعلها تستحق

المجموعة ليست مُخرَجًا يُسلَّم. إنها كائن حي:

1. تفشل حالة في التشغيل الفعلي.
2. تدخل تلك الحالة إلى المجموعة مع إجابتها الصحيحة مكتوبة إلى جانبها.
3. يُصلَح النظام حتى تنجح الحالة.
4. تبقى الحالة إلى الأبد كاختبار انحدار.

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

وهي أيضًا، بصياغة أخرى، سبب أن النسخة الثانية من أي وكيل أفضل بكثير من الأولى، وسبب أن تبديل المورّد في منتصف الطريق يكلّف أكثر مما يبدو.

الحد الأدنى، إن لم تفعل سوى شيء واحد

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

ذلك الرقم، مقارنًا بنفسه بعد شهر، سيخبرك عن نظامك أكثر مما تخبرك به أي لوحة مؤشرات يعرضها عليك مورّد.