عرض الوكيل التجريبي الخاص بك يعمل بنجاح. هذا هو الفخ.
أقوم ببناء وكلاء ذكاء اصطناعي للشركات، وغالبًا ما أرى النمط نفسه يتكرر. يعمل النموذج في العرض التجريبي (demo)، ثم تطلق المنتج، ليفشل بعد ذلك مرة واحدة من كل ثلاث مرات في بيئة الإنتاج (production). ولا أحد يعرف السبب.
الفجوة بين العرض التجريبي وبيئة الإنتاج هي مسألة رياضية. بمجرد أن تفهم الرياضيات، ستغير طريقة بنائك للأنظمة.
إذا كانت كل خطوة في الوكيل الخاص بك موثوقة بنسبة 95%، فقد يبدو ذلك جيدًا. لكن الوكلاء يستخدمون سلاسل من الخطوات. إذا ربطت عشر خطوات معًا، فستنخفض نسبة نجاحك إلى 60%. وإذا استخدمت عشرين خطوة، فستنخفض نسبة نجاحك إلى 36%.
في العمل الفعلي، غالبًا ما تكون معدلات الخطأ في الخطوات تتراوح بين 10% إلى 20%. إذا كان للوكيل ثماني خطوات بموثوقية 85%، فإنه سيفشل في 75% من الحالات.
المشكلة ليست في النموذج، بل في الاحتمالات التراكمية (Compounding probability).
يُظهر العرض التجريبي مسارًا مثاليًا واحدًا (happy path)، حيث يستخدم مدخلات نظيفة وسلاسل قصيرة. أما بيئة الإنتاج فتستخدم بيانات غير منظمة من مئات المستخدمين، وتستخدم سلاسل طويلة تتضمن خطوات خفية.
الفشل في الوكلاء لا يظهر على شكل انهيار للنظام (crash)، بل يظهر على شكل خطأ صامت.
الخطوة الثالثة تقرأ حقلًا بشكل خاطئ، ومع ذلك يظل المخرج يبدو كملف JSON صالح. الخطوة الرابعة تستخدم تلك البيانات الخاطئة في عملية الاستنتاج. ومن الخطوة الخامسة إلى الثامنة، تُبنى الخطوات بناءً على ذلك الخطأ. تكون الإجابة النهائية خاطئة ولكنها تبدو منطقية. ولا يوجد سجل أخطاء (error log) يوضح لك أين حدث الخطأ.
توقف عن القول بأن النموذج قد "هلوس" (hallucinated). النموذج ببساطة نقل البيانات السيئة التي تلقاها. نظامك يفتقر إلى نقطة تفتيش (checkpoint) لاكتشاف الخطأ في الخطوة الثالثة.
توقف عن التعامل مع الوكيل كمجرد أمر (prompt)، وابدأ في التعامل معه كنظام.
اتبع هذه القواعد لبناء وكلاء موثوقين:
احفظ الحالة (state) خارج الوكيل. احتفظ بالحالة في قاعدة بيانات، وليس في المحادثة. إذا فشلت عملية ما في الخطوة السادسة، يمكنك الاستئناف من الخطوة السادسة، ولن تضطر إلى إعادة تشغيل السلسلة بأكملها.
تحقق من البيانات عند الحدود (boundaries). تحقق من كل مدخل ومخرج مقابل مخطط (schema). اكتشف الخطأ في الخطوة التي يحدث فيها؛ فهذا يحول اللغز إلى خطأ يمكن معالجته.
اجعل الآثار الجانبية (side effects) متماثلة (idempotent). يجب عليك إعادة محاولة الخطوات عند فشلها. إذا كانت الخطوة ترسل بريدًا إلكترونيًا أو تخصم مبلغًا من بطاقة ائتمان، فاستخدم مفتاح تماثل (idempotency key). هذا يمنع تكرار الإجراءات أثناء إعادة المحاولة.
استخدم التقييمات (evals) في التكامل المستمر (CI). يتغير سلوك الوكيل مع كل تعديل بسيط. قد يؤدي تغيير الأمر (prompt) إلى إصلاح حالة واحدة ولكنه قد يتسبب في تعطل خمس حالات أخرى. استخدم مجموعة اختبار لاكتشاف هذه التراجعات (regressions) تلقائيًا.
الانتقال من العرض التجريبي إلى منتج حقيقي هو مسألة هندسية. يتعلق الأمر بمعالجة الأخطاء، وإدارة الحالة، وقابلية المراقبة (observability). الأمر لا يتعلق بكتابة أوامر (prompts) أفضل.
إذا تعثر وكيلك في بيئة الإنتاج، فلا تبحث عن نموذج أكبر. ابحث عن الخطوة التي انحرفت فيها السلسلة. اسأل نفسك لماذا لم يكتشف نظامك الخطأ هناك.
Source: https://dev.to/sagar_jain4010/your-agent-demo-works-thats-the-trap-4joc
Optional learning community: https://t.me/GyaanSetuAi