Raft توضّح كيف يمكن للشركات تقييم وكلاء الذكاء الاصطناعي قبل إطلاقهم في سير العمل

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

لماذا لا تكفي الثقة؟

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

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

كيف نبني eval set

نقطة الانطلاق هي مجموعة ground truth set: مجموعة من الحالات الواقعية أو القريبة جداً من الواقع، ترتبط فيها المدخلات بالنتيجة المتوقعة. وعادةً تُجمع هذه المجموعة من مهام سابقة عالجها الفريق يدوياً. ويشدد المقال بشكل خاص على أن evals لا تحتاج إلى آلاف الأمثلة كما في حالة الضبط الدقيق (fine-tuning). الأهم أن تكون كل حالة لا لبس فيها: أي أن يجيب خبيران مستقلان بالطريقة نفسها عن سؤال ما إذا اجتاز الوكيل الاختبار أم لا.

تتكوّن eval set النموذجية من عدة طبقات:

• مهام ذات مدخلات محددة ومعيار نجاح
• تشغيل تجريبي للوكيل مع نتيجة نهائية
• مقيِّم واحد أو أكثر (graders) لجوانب الجودة المختلفة
• سجل بالخطوات (transcript): استدعاءات الأدوات والإجراءات الوسيطة ومنطق المسار

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

يمكن المزج بين ثلاثة أساليب في عمليات التحقق نفسها. تناسب المقيِّمات الحتمية (deterministic graders) الحالات التي تهم فيها إشارات دقيقة، مثل مبلغ الاسترجاع أو استدعاء الأداة المطلوبة. وتفيد LLM-judges في تقييم النبرة واكتمال الإجابة ووضوحها. أما البشر فهم ضروريون في البداية لجمع البيانات المرجعية ومعايرة المقيِّمين الآليين، وإلا بدأ النظام سريعاً بقياس ما هو مريح، لا ما يهم الأعمال فعلاً.

ما المقاييس التي ينبغي متابعتها؟

يركّز المقال بشكل خاص على أن الأنظمة الوكيلية غير حتمية (non-deterministic). ولهذا فإن الفحص الصارم لكل خطوة بلا جدوى: فالنتيجة الجيدة نفسها يمكن بلوغها عبر مسارات مختلفة. لكن المسار يبقى مهماً مع ذلك، لأنه يستهلك الوقت والرموز (tokens) والوصول إلى الأدوات، وقد ينتهك السياسات الداخلية. ينبغي أن يجيب eval جيد عن سؤالين في آن واحد: هل النتيجة النهائية صحيحة، وهل كان المسار إليها معقولاً.

نسبة نجاح 95% تبدو رائعة، إلى أن تتركّز الأخطاء في false positives.

ولهذا بالذات لا تكفي نسبة النجاح (pass rate) وحدها. فبالنسبة إلى القرارات الثنائية يفيد النظر في confusion matrix وprecision وrecall وF1، لأن أنواع الأخطاء المختلفة تكلّف الأعمال بصورة مختلفة. فالوكيل الذي يوافق على الاسترجاع بسهولة مفرطة يخلق فئة من المخاطر، والوكيل الذي يرفض بشكل جماعي طلبات مشروعة يخلق فئة مختلفة تماماً.

إضافة إلى ذلك، يذكّر المؤلفون بالفخاخ المعتادة: قانون جودهارت (Goodhart's law)، وتقادم eval-set، ووهم لوحة المؤشرات «الخضراء»، حين يبدو المقياس طبيعياً بينما تتزايد شكاوى المستخدمين الفعلية.

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

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