عدّلتَ تعليمات مساعد الدعم الفني ليصبح أكثر لطفًا، وجرّبته على ثلاثة أسئلة فأعجبك. بعد أسبوع اكتشفت أنه صار يعتذر بإسهاب ثم ينسى أن يطلب رقم العقد، فتضاعفت المحادثات التي تنتهي عند موظف بشري. لم يكن التعديل سيّئًا في ذاته؛ المشكلة أنك لم تقِس.
التقييم المنهجي (Evals) هو للذكاء الاصطناعي ما الاختبارات الآلية للبرمجيات: مجموعة ثابتة من الحالات تُشغَّل بعد كل تغيير، فتعرف بالأرقام هل تحسّن النظام أم تراجع، وأين.
لماذا لا يكفي «جرّبته وكان جيدًا»؟#
التقييم بالانطباع
- خمسة أسئلة تخطر ببالك، وغالبًا هي الأسهل.
- تحكم بالمزاج، وتتذكّر النجاحات أكثر من الإخفاقات.
- لا تعرف ما الذي انكسر بعد التعديل.
- قرار تغيير النموذج مبني على إحساس.
التقييم المنهجي
- مجموعة حالات ثابتة تمثّل الواقع، بما فيه الحالات الصعبة.
- معيار مكتوب يطبَّق بالطريقة نفسها كل مرة.
- مقارنة قبل وبعد لكل تعديل: ما تحسّن وما تراجع.
- قرار تغيير النموذج مبني على أرقام وتكلفة.
الخطوة الأولى: مجموعة الحالات الذهبية#
مثالنا مساعد دعم فني لشركة إنترنت منزلي: يشخّص الأعطال الشائعة، ويجيب عن الباقات والفواتير، ويحوّل إلى فنّي عند الحاجة. مجموعة الحالات لا تُخترع من الخيال؛ تُستخرج من سجلّ المحادثات الحقيقية ثم تُكمَّل بما ينقص.
الحالات الشائعة
الأسئلة الأكثر تكرارًا فعلًا: الإنترنت بطيء، والراوتر يومض بالأحمر، وموعد الفاتورة، وتغيير الباقة.
الحالات الحدّية
سؤال مركّب، أو عميل لا يعرف اسم المشكلة، أو بيانات ناقصة، أو لهجة عامية ثقيلة، أو رسالة طويلة مشوّشة.
ما يجب رفضه أو تحويله
طلب استرداد مبلغ، أو شكوى قانونية، أو عميل غاضب يطلب مديرًا، أو سؤال خارج نطاق الشركة تمامًا.
الحالات العدائية
محاولة إقناع المساعد بمنح خصم، أو استخراج تعليماته، أو انتحال صفة موظف.
لكل حالة سجلّ واحد: المدخل، والسلوك المتوقّع (لا نص إجابة حرفي بالضرورة)، والفئة، ودرجة الأهمية.
{"id": "net-017", "category": "تشخيص", "priority": "high",
"input": "النت فاصل من الصبح واللمبة الحمرا منورة في الراوتر",
"expected": {
"must": ["يسأل عن رقم العقد أو رقم الخط", "يطلب إعادة تشغيل الراوتر بخطوات مرقمة", "يعرض فتح بلاغ عطل إن استمر الضوء الأحمر"],
"must_not": ["يعد بموعد إصلاح محدد", "يطلب كلمة مرور الحساب"],
"handoff": false
}}ثلاث طبقات تقييم#
الطبقات
أرخص وأدق ما يمكن فحصه بالكود دون أي نموذج:
- هل المخرج JSON صالح بالحقول المطلوبة؟
- هل ذُكر رقم هاتف الدعم الصحيح لا رقمًا مخترعًا؟
- هل الطول ضمن الحد؟
- هل ظهرت كلمة ممنوعة («مضمون 100٪»، أو «خلال ساعة»)؟
- هل اتُّخذ قرار التحويل الصحيح (handoff = true/false)؟
استخدمها أولًا دائمًا؛ فهي لا تخطئ ولا تكلّف شيئًا.
لما لا يُفحص بالكود: هل الإجابة مفيدة؟ هل النبرة مناسبة؟ هل تابعت الخطوات بترتيب منطقي؟ هنا يقيّم نموذج آخر الإجابة وفق معيار مكتوب بدقّة، لا بسؤال عام «هل الإجابة جيدة؟».
القاعدة الذهبية: حوّل كل حكم إلى أسئلة نعم/لا محدّدة، واطلب التعليل قبل الحكم.
عيّنة دورية (مثلًا عشرون محادثة أسبوعيًّا) يراجعها شخص يعرف العمل، وتُقارن أحكامه بأحكام النموذج الحَكَم. إن اختلفا كثيرًا فالمعيار أو الحَكَم يحتاج إصلاحًا، لا المساعد.
الإنسان هو المرجع الذي يُعاير به الحَكَم، لا العكس.
معيار التقييم وأمر الحَكَم#
أنت مقيّم جودة لمساعد دعم فني لشركة إنترنت منزلي. ستتلقّى: رسالة العميل، وإجابة المساعد، والسلوك المتوقّع.
قيّم الإجابة على المعايير التالية، كلٌّ منها بنعم أو لا:
A. هل طلب المساعد المعلومة اللازمة للتشخيص (رقم العقد أو الخط) إن لم تكن موجودة؟
B. هل خطوات الحل مرقّمة وقابلة للتنفيذ من عميل غير تقني؟
C. هل التزم بكل بنود "must"؟
D. هل تجنّب كل بنود "must_not"؟
E. هل اتّخذ قرار التحويل إلى موظف كما هو متوقّع؟
F. هل النبرة مهذّبة ومختصرة دون اعتذار مكرّر؟
لكل معيار: اكتب جملة تعليل واحدة من نص الإجابة نفسه، ثم الحكم.
لا تُكافئ الإجابة الأطول لطولها. لا تفترض معلومات غير مكتوبة.
أخرج النتيجة بصيغة JSON فقط:
{"A": {"reason": "...", "pass": true}, ..., "overall_pass": true}
حيث overall_pass = true فقط إذا نجحت C وD وE جميعًا.لاحظ أن الحكم النهائي مبني على قاعدة صريحة (C وD وE إلزامية)، لا على انطباع الحَكَم العام.
أخطاء الحَكَم التي تخدعك#
| الانحياز | ما يحدث | العلاج |
|---|---|---|
| انحياز الطول | يفضّل الإجابات الأطول حتى لو كانت أسوأ | نصّ صريح على عدم مكافأة الطول، ومعيار «مختصرة» |
| انحياز الموضع | عند المقارنة بين إجابتين يفضّل الأولى | قارن مرتين مع تبديل الترتيب، واعتمد الحكم المتّفق |
| انحياز الذات | يفضّل أسلوب النموذج من عائلته | استخدم حَكَمًا من عائلة مختلفة عن النموذج المقيَّم |
| التساهل | يمنح «نجح» لما هو قريب من الصواب | أسئلة نعم/لا محدّدة بدل درجات من عشرة |
| الغموض | يفسّر المعيار على هواه | أمثلة قليلة لنجاح وفشل كل معيار داخل الأمر |
اختبار الانحدار: الطقس الذي يحميك#
كل تغيير، مهما صغر، يمرّ على المجموعة نفسها قبل النشر:
ثبّت خط الأساس
شغّل المجموعة على النسخة الحالية، وسجّل نسبة النجاح لكل فئة، والتكلفة، وزمن الاستجابة.
طبّق التغيير
تعديل التعليمات، أو تغيير النموذج، أو إضافة أداة، أو تحديث مستندات المعرفة.
أعد التشغيل وقارن حالةً حالة
لا يكفي الرقم الإجمالي. ارتفاع النجاح من 82٪ إلى 85٪ قد يخفي انهيار فئة «ما يجب تحويله» من 95٪ إلى 70٪، وهي الأخطر.
قرّر بقاعدة مكتوبة مسبقًا
مثلًا: لا نشر إن تراجعت أي حالة عالية الأهمية، أو تراجعت أي فئة أكثر من نقطتين.
أضف ما تعلّمته
كل إخفاق جديد في الإنتاج يصبح حالة في المجموعة.
الأدوات#
- جدول بيانات: بداية ممتازة فعلًا؛ عمود للمدخل، وعمود للمتوقّع، وعمود للناتج، وعمود للحكم.
- promptfoo: أداة مفتوحة المصدر تشغّل الحالات على عدّة أوامر ونماذج وتعرض المقارنة، وتدعم الفحوص الآلية والحَكَم معًا.
- سجلّات الإنتاج: مصدر الحالات الجديدة؛ احتفظ بالمحادثات مع مراعاة الخصوصية وحذف البيانات الشخصية قبل استخدامها في الاختبار.
ما الذي تسلّمه للعميل؟#
حين تبني مساعدًا لجهة ما، سلّم معه تقرير تقييم: عدد الحالات وفئاتها، ونسبة النجاح لكل فئة، وأمثلة للإخفاقات المتبقّية وكيف تُدار (تحويل إلى موظف)، وخطة المراقبة بعد الإطلاق. هذا التقرير يرفع قيمة عملك ويحميك: الاتفاق يصبح على أرقام، لا على انطباعات. وللبناء عليه اقرأ كيف تسعّر خدمات الذكاء الاصطناعي.
اختبر فهمك
عدّلت التعليمات فارتفعت نسبة النجاح الإجمالية من 82٪ إلى 85٪. هل تنشر؟
التحسّن الإجمالي قد يخفي تراجعًا خطيرًا في فئة حسّاسة.
اختبر فهمك
أيّ هذه يُفحص بالكود دون حاجة إلى نموذج حَكَم؟
ما يمكن فحصه بالكود يُفحص بالكود أولًا: أدق وأرخص.
اختبر فهمك
لاحظت أن الحَكَم يفضّل دائمًا الإجابة المعروضة أولًا. ما العلاج؟
هذا انحياز الموضع، ويُعالج بتبديل الترتيب لا بإلغاء الحَكَم.