كيف تبني إطاراً قابلاً لإعادة الاستخدام لتقييم وكلاء الذكاء الاصطناعي

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

من تقييمات معزولة إلى أدوات مشتركة

بدأت فرق Elastic بإنشاء مجموعات بيانات ومقيّمين وعمليات تتبع منفصلة لكل وكيل. ففي حالة وكيل اكتشاف الهجمات، تضمنت الاختبارات سيناريوهات هجومية وسليمة صاغها محللون وباحثون أمنيون، مع مقاييس مثل الدقة والاستدعاء، وصحة الحقائق، والتشابه، وتصنيف تكتيكات MITRE. أما روبوتات المحادثة المعتمدة على بيانات المؤسسة فكانت تختبر أسئلة واسترجاعاً من الوثائق، مع التركيز على ملاءمة الإجابة واكتمالها وصحة معرفات المنتجات وصياغة استعلامات ES|QL.

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

التتبع شرط لفهم سبب الفشل

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

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

لماذا لا يكفي LLM-as-a-judge؟

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

لذلك جمعت Elastic بين LLM-as-a-judge وتقييمات حتمية قائمة على القواعد والبرمجة. تفحص هذه التقييمات بناء JSON أو YAML، وصحة الصياغة، ووجود الكيانات المطلوبة، وقابلية تنفيذ الشيفرة أو الاستعلام، إضافة إلى مقاييس مثل الدقة والاستدعاء وصحة الحقائق. هذا الدمج يقلل تكلفة التقييم وسرعته في الحالات التي تملك إجابة واضحة، ويترك الحكم الدلالي للمهام التي يصعب اختزالها إلى قواعد.

ما الذي لا يمكن تعميمه؟

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

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

ما الذي يتغير عملياً للفرق؟

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

كما نقلت Elastic بعض أدوات التقييم من Python إلى TypeScript لمطابقة كود الإنتاج المكتوب بـTypeScript واستخدام Playwright وأداة داخلية مخصصة تسمى Scout. لا تعني هذه الخطوة أن نقل كل تقييمات علم البيانات مطلوب، بل تعكس حاجة محددة إلى تقليل الفجوة بين ما يختبره الفريق وما ينفذه النظام فعلياً. الخلاصة العملية هي أن الإطار المشترك يمكنه توحيد المخطط، والتشغيل، والمقاييس العامة، لكنه لا يستطيع أن يحل محل خبرة المجال أو الحكم على ما يجب اعتباره نجاحاً وفشلاً.