الوكيل الذكي الذي يكتفي بالدردشة يحمل مخاطر ضئيلة، لأن الإجابة الخاطئة يمكن ببساطة طلبها مرة أخرى. أما حين يستطيع الوكيل استدعاء الأدوات، فقد يعني الخطأ بريدًا أُرسل أو دفعة نُقلت، ويبدو الحل المعتاد، وهو وضع نموذج ثانٍ أمامه للتحقق من الأول، أشبه بتعيين متدرب لمراقبة متدرب آخر.
توضح حالة بسيطة هذه المشكلة. يُحتسب على عميل رسوم مرتين عن عملية شراء بقيمة 12 دولارًا، فيطلب من وكيل ذكي استرداد المبلغ. يختار الوكيل الأداة الصحيحة والعميل الصحيح، لكنه يُعد مبلغًا قدره 120,000 سنت بدلًا من 1,200 سنت لكل رسم. معرّف العميل صالح، والقيمة عدد صحيح، والمخطط يقبلها، فلا يبدو أن هناك خللًا. المبلغ مختل بمقدار مئة ضعف، وهو خطأ يظهر عادة عند تحويل الدولارات إلى سنتات مرتين. سقف بسيط قدره 500 دولار كان سيوقف نسخة 1,200 دولار، لكنه لن يوقف خطأ 120 دولارًا الذي يبقى عشرة أضعاف ما وافق عليه العميل.
قادت هذه الفجوة الكاتب إلى نموذج Jev من شركة Type Safe AI، الذي أُطلق في 15 سبتمبر بوصفه أول ما تسميه الشركة نماذج النظام الأول (System One Models). وهو حاليًا في مرحلة الوصول المبكر. لا يولّد النموذج نصًا، بل يأخذ حالة التطبيق وسؤالًا محدد النطاق ويعيد إجابة احتمالية مُصنَّفة، وهي مهمة تختلف عن نموذج الدردشة المعتاد. ومن استخداماته المعلنة حواجز الحماية للمدخلات والمخرجات.
يلاحظ الكاتب أن التحقق من المخطط يعالج الأخطاء البنيوية لا الدلالية، مثل إرسال بريد إلى المستلم الخطأ مع صلاحية العنوانين. وقد يناسب نموذج كـ Jev أن يكون طبقة قرار في نظام الوكلاء، غير أن المقال يركز على موضع هذه الطبقة وعلى القرارات التي لا ينبغي الوثوق بها فيها، لا على نتائج اختبارات الأداء.
المصدر: Towards Data Science · لخّصه HeadlinesBriefing