AWS توضّح كيف تُخفي دقة بحث بنسبة 100% إخفاق وكيل الذكاء الاصطناعي

وكيلكم يجيب بثقة عن أسئلة الموظفين، ويرفق الروابط، ويجتاز فحص البحث. هل يمكن إطلاقه؟ في مثال AWS حصلت المقاطع التي عُثر عليها على دقة 100% وفق أحد المقاييس، لكن لم تكن بينها المعلومات المطلوبة للسؤال عن الإجازة المرضية. وبعد تعديل الموجِّه صارت الإجابة أسوأ. الدرس العملي: قبل إجراء التعديل التالي على التعليمات، تحقّقوا أولًا مما إذا كانت الإجابة موجودة في المستندات أصلًا.

وصفت AWS هذه الحالة في مادة عن دورة حياة تطوير الوكلاء (Agent Development Lifecycle أو Agent DLC). وهو نهج في تطوير الوكلاء يحدد فيه الفريق مسبقًا شروط القبول، ويفحص كل تغيير، ويعيد المشكلات المكتشفة أثناء التشغيل إلى مجموعة الفحوصات. وقيمته للمطوّر تكمن في طريقة محددة لمعرفة أي مكوّن يحتاج إلى إصلاح.

لماذا لم تكن نسبة 100% في التقرير كافية

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

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

في السؤال الإشكالي بلغت هذه الدقة 100%، وحصة الحقائق المفيدة داخل المادة التي عُثر عليها 9%، وتغطية الأسئلة الفرعية 0%. ثم فحص المؤلفون المستندات المصدرية: لم تكن في المجموعة فعلًا سياسة مستقلة للإجازات المرضية.

غيّر الفريق الموجِّه النظامي فقط: طلب الاعتماد الصارم على المصادر، وتجاهل ما لا حاجة إليه، والإجابة عن صلب السؤال. وفي السؤال عن تقييم الموظفين ارتفعت نسبة العبارات المؤكَّدة من 83% إلى 87%. أما في السؤال عن الإجازة المرضية فقد انخفضت من 39% إلى 31%. فالتعليمات لا تستطيع إضافة معلومات غير موجودة. وكان الإجراء التالي المطلوب هو إضافة مستندات إلى القاعدة والتحقق من البحث.

ما الذي ينبغي فحصه قبل الإصدار

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

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

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

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

أين تنتهي استنتاجات التجربة

حتى التقييم المرتفع للتأكيد بالمصادر لا يضمن إجابة مقبولة. ففي إحدى الحالات زعم الوكيل أنه يعرف وسيلة التواصل المفضلة لدى المستخدم. ولم يكن لديه ملف شخصي للمستخدم: فقد جمع النموذج معلومات من مستندات مختلفة وقدّمها على أنها حقيقة شخصية. وحصلت الإجابة على 90% في التأكيد بالمصادر، ولذلك تحتاج مثل هذه الاختلاقات إلى فحص منفصل.

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

الخطوة العملية للفريق هي أخذ الإخفاقات الفعلية لوكيله وإضافتها إلى مجموعة الفحص. وفي كل حالة يُحدَّد هل كانت المصادر كافية، وهل استُخدمت الأدوات بشكل صحيح، وهل ظهرت معلومات مختلَقة. ثم يُصلَح السبب الذي تأكد وتُكرَّر التشغيلات. ويُستحسن تشغيل الفحوصات وفق جدول زمني أيضًا: فقد يتغير نموذج خارجي أو واجهة API أو قاعدة معرفة دون أي تعديل (commit) في مستودعكم.