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

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

لماذا هناك ندرة في الثقة

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

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

إذا اضطررت إلى التحقق من كل إجراء يدويًا، فإن قيمة الأتمتة تختفي بسرعة. لذلك، تعمل evals هنا ليس كتحليل إضافي، بل كآلية أساسية للموافقة على عمل الوكيل.

كيفية بناء مجموعة eval

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

• مهام ببيانات إدخال محددة ومعايير النجاح
• عمليات اختبار الوكيل مع النتائج النهائية
• مُقيّم واحد أو أكثر لجوانب الجودة المختلفة
• نسخة من الخطوات: استدعاءات الأدوات والإجراءات الوسيطة ومنطق التوجيه

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

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

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

أي المقاييس يجب مراقبتها

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

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

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

ماذا يعني هذا

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