أن تعرف مدى جودة نظام الذكاء الاصطناعي لديك فعلاً
يقيس تقييم الذكاء الاصطناعي جودة الميزة التي يقودها نموذج لغوي على حالات تمثل الاستخدام الحقيقي، وتواصل المراقبة القياس بعد الإطلاق. نبني مجموعة البيانات، ونحدد مع خبرائك معنى الإجابة الصحيحة، ونصنّف طرق فشل النظام، ونؤتمت حساب النتائج، ونربط ذلك كله بعملية الإصدار لديك وبسجلات التشغيل الفعلي.
يناسب هذا الفرق التي لديها مساعد أو وكيل أو ميزة لاستخراج البيانات تبدو ناجحة ولا تستطيع إثبات ذلك، والفرق التي تخشى تغيير التعليمات أو النموذج لأن أحداً لا يعرف ما الذي قد يتعطل. والتقييم ليس تدقيقاً يُجرى مرة واحدة، بل يصبح جزءاً من طريقة تطوير المنتج، شأنه شأن الاختبارات المؤتمتة في البرمجيات المعتادة.
مجموعة بيانات التقييم
نجمع أمثلة من محادثات ومستندات وتذاكر حقيقية، تغطي الحالات الشائعة والنادرة ومواضع المشكلات المعروفة، ولكل منها نتيجة متوقعة يتفق عليها خبراؤك.
تصنيف الأخطاء
نفرز الأخطاء في أنواع مسماة، مثل المعلومات المختلقة، أو إخفاق الاسترجاع، أو سوء استخدام الأدوات، أو ضعف الأسلوب، فيتجه الجهد إلى ما يكلفك أكثر.
طرق حساب النتائج
نختار لكل مهمة فحوصاً مطابقة، أو فحوصاً قائمة على قواعد، أو معايير مكتوبة يصححها نموذج. ونتحقق من أدوات التصحيح نفسها بمقارنتها بالحكم البشري قبل الاعتماد على درجاتها.
بوابات الإصدار
يمر كل تغيير في التعليمات أو النموذج أو الأدوات أو مصادر البيانات على مجموعة التقييم، ولا يمضي الإصدار إلا حين يبلغ الحدود المتفق عليها.
المراقبة أثناء التشغيل
نأخذ عينات من الاستخدام الفعلي ونقيّمها، مع لوحات للجودة وحالات الامتناع وزمن الاستجابة والتكلفة، وتنبيهات حين يخرج أي منها عن نطاقه المعتاد.
حلقة المراجعة البشرية
يصنّف المراجعون عينة من المخرجات الحقيقية في أداة بسيطة، وتُضاف الأخطاء المؤكدة إلى مجموعة البيانات، فيُختبر الخطأ نفسه في كل مرة لاحقة.
ما تتسلمه منا
- مجموعة بيانات تقييم مصنَّفة
- معايير جودة مكتوبة
- تصنيف للأخطاء مع أعدادها
- مسار مؤتمت لحساب النتائج
- بوابة إصدار ضمن مسار التطوير لديك
- لوحات مراقبة وتنبيهات
- أداة مراجعة للخبراء
- تقرير خط الأساس وإرشادات
طريقة عملنا
- 01
تعريف الجودة
نكتب مع المسؤولين عن النتيجة شكل النتيجة الصحيحة والمقبولة وغير المقبولة في كل مهمة، ونحسم الخلافات بأمثلة حقيقية.
- 02
بناء مجموعة البيانات
نجمع حالات تمثل الواقع ونصنّفها، ونتأكد من اتفاق الخبراء فيما بينهم على التصنيفات، ونعزل جزءاً لا يُستخدم في الضبط أبداً.
- 03
أتمتة حساب النتائج
ننفذ أدوات التصحيح ونقارنها بالتقييمات البشرية إلى أن تتقارب النتائج بما يكفي للوثوق بها، ثم نضمّها إلى مسار التطوير، فينتج كل تغيير تقريراً.
- 04
المراقبة أثناء التشغيل
نفعّل العينات واللوحات والتنبيهات على الاستخدام الفعلي، ونتفق مع فريقك على روتين للمراجعة، ويحدد تقرير خط الأساس الأول الأرقام التي يجب أن تتجاوزها الإصدارات التالية.
التقنيات التي نستخدمها
| المجال | التقنيات |
|---|---|
| التقييم | Promptfoo، Ragas، DeepEval، أدوات تصحيح مخصصة |
| رصد الأداء | Langfuse، LangSmith، Arize Phoenix، OpenTelemetry |
| مسارات المعالجة | Python، GitHub Actions، Pytest، dbt |
| التقارير | Grafana، Metabase، Datadog، Label Studio |
ميزة الذكاء الاصطناعي تعمل، لكنك لا تستطيع إثبات ذلك
كان العرض التوضيحي مقنعاً، ويبدو معظم المستخدمين راضين، لكن لا أحد يستطيع ذكر رقم للدقة، والشكاوى تصل في صورة حكايات متفرقة، وكل تغيير في التعليمات قفزة في المجهول. ما تريده أرقام، وأنواع أخطاء معروفة، وتحذير حين تتراجع الجودة.
- مساعدو الدعم والمبيعات
- مسارات استخراج البيانات من المستندات
- أنظمة الاسترجاع والبحث
- وكلاء ينفذون إجراءات
- ميزات في قطاعات خاضعة للتنظيم
- فرق تبدّل مزوّدي النماذج
أسئلة شائعة
كم مثالاً تحتاج إليه مجموعة التقييم؟
في البداية، أقل مما تخشاه معظم الفرق، ثم أكثر كلما نضج المنتج. فالمجموعة الصغيرة المختارة بعناية، التي تغطي المهام الرئيسية والحالات المعروفة بمشكلاتها، تكشف بالفعل معظم التراجعات في الجودة. وتنمو مع كل خطأ مؤكد من التشغيل الفعلي. والتغطية أهم من الحجم، لذلك نقارن المجموعة بمزيج الطلبات الحقيقي، ولا نلهث وراء رقم لامع.
هل يمكن أن يصحح نموذج مخرجات نموذج آخر بدقة يُعتمد عليها؟
في كثير من المعايير نعم، بشرط التحقق من المصحح. نكتب معايير واضحة، ونطلب من أشخاص تقييم عينة، ونقارن درجات المصحح بدرجاتهم. وحيث يكون الاتفاق عالياً، يمكن تشغيله على نطاق واسع. وحيث لا يكون كذلك، نحسّن المعايير أو نبقي شخصاً في ذلك الجزء من الحلقة. فالمصحح الذي لم يُتحقق منه يعطي أرقاماً واثقة لا تعني الكثير.
ماذا ينبغي أن نراقب بعد إطلاق الميزة؟
الجودة في عينات المخرجات، ومعدل الامتناع والتصعيد، وزمن الاستجابة، والتكلفة لكل طلب، وأخطاء الأدوات، وآراء المستخدمين. ونراقب المدخلات أيضاً، لأن تحولاً فيما يسأل عنه الناس كثيراً ما يفسر تراجع الجودة قبل أي تغيير في الشيفرة. ونضبط التنبيهات على الاتجاهات، لا على إجابات سيئة منفردة، فيصل التحذير إلى الفريق دون أن يغرقه.
هل تقيّمون أنظمة بناها فريق آخر؟
نعم. فالتقييم مستقل إلى حد كبير عن طريقة بناء النظام. نحتاج إلى الوصول إلى مدخلاته ومخرجاته، ويفضل أيضاً إلى السجلات والتعليمات، وإلى وقت مع من يستطيعون الحكم على صحة النتائج. وكثيراً ما يفيد التقييم الخارجي تحديداً لأن من بنوا النظام أقرب إلى المنتج من أن يروا أخطاءه الشائعة بوضوح.
كيف يساعد التقييم حين نغيّر النماذج؟
يحوّل قراراً محفوفاً بالمخاطر إلى قرار مبني على القياس. فمع وجود مجموعة بيانات وأدوات تصحيح، يمكن تشغيل نموذج جديد أو أرخص على الحالات نفسها ومقارنته في الجودة والسرعة والتكلفة خلال يوم واحد. ومن دونها يُحكم على التبديل ببضع تجارب يدوية، وتظهر التراجعات لاحقاً عبر المستخدمين. ويوقف المزوّدون النماذج بانتظام، لذلك يعود السؤال دائماً.