كيف تقيّم أداء شات بوت الذكاء الاصطناعي في شركتك؟ دليل عملي للتقييم (Evaluation)

لماذا تقييم الشات بوت ليس رفاهية؟

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

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

الخطوة صفر: عرّف معنى «النجاح» في حالتك

قبل أي مقياس، أجب على هذا: ما المهمة التي يُفترض أن ينجزها البوت؟ بوت الدعم الفني نجاحه = حلّ المشكلة أو تحويلها للجهة الصحيحة. بوت المبيعات نجاحه = تأهيل العميل وجمع البيانات الصحيحة. البوت الداخلي للموظفين نجاحه = إجابة دقيقة مستندة إلى سياساتكم. اربط التقييم بهدف العمل، لا بانطباع «الإجابة تبدو حلوة».

ابنِ «مجموعة اختبار ذهبية» (Golden Dataset)

أساس أي تقييم جاد هو مجموعة أمثلة ثابتة تختبر عليها البوت في كل مرة. اجمعها من ثلاثة مصادر:

• أسئلة حقيقية من سجلّات محادثات فعلية (بعد إخفاء البيانات الشخصية).
• حالات حدّية: أسئلة غامضة أو ناقصة أو خارج النطاق أو بلهجات مختلفة.
• حالات عدائية: محاولات استدراج البوت لتجاوز قيوده أو تسريب معلومات.

ابدأ بـ50–100 مثال تغطّي أهم السيناريوهات بدل آلاف الأمثلة العشوائية. ولكل مثال، حدّد قدر الإمكان الإجابة المرجعية أو المعيار الذي يجعل الإجابة «صحيحة».

ماذا تقيس بالضبط؟ الأبعاد الأساسية

«الجودة» كلمة فضفاضة، ففكّكها إلى أبعاد قابلة للقياس:

• إنجاز المهمة (Task Success): هل حقق المستخدم هدفه فعلاً؟ أهم مقياس وأقربه لقيمة العمل.
• الاستناد ومنع الهلوسة (Faithfulness): في الأنظمة المعتمدة على مصادرك (RAG)، هل الإجابة مبنية على المستندات المسترجَعة فقط، أم أن البوت اخترع معلومة؟
• الصلة بالسؤال (Relevancy): هل الإجابة تخاطب سؤال المستخدم فعلاً أم تدور حول الموضوع؟
• جودة الاسترجاع (Retrieval): في أنظمة RAG، هل جلب النظام المقاطع الصحيحة من قاعدة المعرفة؟ (دقّة السياق واسترجاعه). أغلب أخطاء RAG سببها استرجاع سيّئ لا النموذج نفسه.
• الصحة (Correctness): مدى مطابقة الإجابة لمرجع معروف.
• الأمان والالتزام: هل يرفض الطلبات الخطرة؟ هل يحمي البيانات الشخصية؟ هل يلتزم بنبرة العلامة وسياساتها؟ وهل يصمد أمام محاولات الالتفاف (jailbreak)؟
• الكلفة وزمن الاستجابة: إجابة ممتازة تأتي في 30 ثانية أو بتكلفة عالية لكل محادثة قد تكون فاشلة تجارياً. قِس عدد التوكنز والزمن دائماً.

طرق التقييم الثلاث

1. التقييم البشري: المعيار الذهبي للجودة، لكنه بطيء ومكلف ولا يتوسّع. استخدمه لبناء مرجعك ولمعايرة الطرق الآلية.
2. نموذج كحَكَم (LLM-as-a-Judge): تستخدم نموذجاً قوياً ليقيّم إجابات البوت وفق معيار واضح (rubric) أو بمقارنة إجابتين. سريع وقابل للتوسّع، وهو اليوم الأكثر شيوعاً — بشرط أن تعايره مقابل حكم بشري وتنتبه لتحيّزاته (مثل تفضيل الإجابة الأطول).
3. المقاييس الآلية المرجعية: مثل التطابق التام للأسئلة محددة الإجابة، أو تشابه المعاني عبر التضمين (embeddings). رخيصة وفورية، لكنها محدودة مع الإجابات المفتوحة.

الواقع العملي: امزج الثلاثة. مقاييس آلية سريعة كحارس أول، ونموذج حَكَم للأبعاد النوعية، ومراجعة بشرية لعيّنة دورية.

تقييم قبل النشر (Offline) وبعده (Online)

التقييم نوعان متكاملان لا غنى عن أيٍّ منهما:

• Offline: تشغّل البوت على مجموعتك الذهبية عند كل تغيير، ويفضّل داخل خط CI/CD بحيث لا يصل أي تحديث للإنتاج إذا انخفضت الدرجات. هذا هو «اختبار الانحدار» الذي يمنعك من كسر ما كان يعمل.
• Online: على مستخدمين حقيقيين — اختبار A/B بين نسختين، وزر تقييم (👍/👎)، ومقاييس حارسة (نسبة التحويل لموظف بشري، إعادة طرح السؤال، التخلي عن المحادثة). راقب الإنتاج باستمرار، لأن سلوك المستخدمين الحقيقي يكشف ما لا تكشفه أي مجموعة اختبار.

خطوات عملية لإطلاق نظام تقييم

1. عرّف 3–5 أبعاد تهمّك فعلاً (مثل: إنجاز المهمة، الاستناد، الأمان).
2. ابنِ مجموعة ذهبية صغيرة لكن ممثّلة (50–100 حالة).
3. اكتب معايير تقييم واضحة (rubric) لكل بُعد: ما الذي يستحق 5 وما الذي يستحق 1.
4. أتمت التشغيل: سكربت يشغّل البوت على المجموعة ويحسب الدرجات (بشري + نموذج حَكَم).
5. أدخله في خط النشر: أي درجة أقل من العتبة = إيقاف النشر.
6. أضف حلقة إنتاج: اجمع تقييمات المستخدمين والحالات الفاشلة، وأضفها لمجموعتك الذهبية باستمرار.

أخطاء شائعة تُفقد التقييم قيمته

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

القيمة ليست في إطلاق بوت يتكلم، بل في امتلاك نظام يخبرك — بالأرقام — هل صار أفضل أم أسوأ بعد كل تغيير.

أدوات تساعدك

هناك أدوات مفتوحة وتجارية تختصر بناء خط التقييم، منها: Ragas وDeepEval لأنظمة RAG، وLangSmith وBraintrust وArize Phoenix للمراقبة والتقييم، وOpenAI Evals وpromptfoo لكتابة الاختبارات. اختر الأداة بحسب منصّتك، لكن تذكّر أن المنهجية أهم من الأداة.

دور أوريجامي

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

المصادر

• ورقة Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena ‏(Zheng et al., 2023)‏: arxiv.org/abs/2306.05685
• توثيق Ragas لمقاييس تقييم RAG ‏(الاستناد والصلة وجودة السياق)‏: docs.ragas.io
• توثيق التقييم في LangSmith: docs.smith.langchain.com
• OpenAI Evals: github.com/openai/evals
• إرشادات Anthropic حول بناء التقييمات: docs.anthropic.com