كيف تدرب وكيل بنية تحتية للذكاء الاصطناعي على عدم الكذب
DeepSeek
تم بناء وكيل ذكاء اصطناعي للقراءة فقط للتحقيق في حوادث البنية التحتية. في البداية كان يقدم إجابات معقولة ولكن غير مفيدة. حل الفريق المشكلة بنقل نموذج اللغة الكبير (LLM) داخل التطبيق، وإضافة عقود أدوات، وحراس الأدلة، وتخطيط منظم. في آخر تشغيل، اجتاز 44 من أصل 45 سيناريو اختبار.
تم بناء وكيل ذكاء اصطناعي داخلي للقراءة فقط للإجابة على أسئلة البنية التحتية مثل 'لماذا يعيد الخدمة رمز الخطأ 502؟'. استخدم الوكيل لغة Go، دون استخدام LangChain، واستدعى النماذج DeepSeek-V4-Flash و Qwen3.6-27B-FP8 عبر واجهة برمجة تطبيقات متوافقة مع OpenAI. استخدم الإصدار الأول حلقة ReAct مجانية وأنتج إجابات صحيحة شكليًا لكنها مضللة غالبًا. على سبيل المثال، عندما كان سبب خطأ 502 هو حجم رأس الاستجابة المفرط عند الوكيل، استنتج الوكيل 'لا يوجد خطأ على مستوى التطبيق'، متجاهلاً السبب الحقيقي. تم تحديد خمس فئات من الأخطاء: نطاق خاطئ، دلالات زمنية خاطئة، استنتاجات سلبية خاطئة، فقدان الأدلة، وإعادة التخطيط غير المنضبط. كان الحل هو تضمين الوكيل داخل إطار تطبيق صارم. يتم التحكم في استدعاءات الأدوات من خلال عقد موسع يسمى x-agent يحدد الأدلة ونوع المخرجات والحداثة والدلالات السلبية وحالة القراءة فقط. يبني المخطط أولاً أهدافًا (مثل symptom.http_502, route.edge_to_ingress) وشرط إيقاف: يجب حل كل هدف مطلوب أو يكون غير متاح بشكل صريح. يمنع حارس الأدلة المنهي من الاستنتاج قبل تحقيق جميع الأهداف. يتم اختيار الأدوات على مراحل: مرشح السياسة، مرشح معجمي أولي، إعادة ترتيب النماذج (أفضل 8)، ثم بوابة صلة الهدف. للنوايا الخطرة مسارات محددة مسبقًا حتمية. في التقييم النهائي، اجتاز الوكيل 44 من أصل 45 سيناريو (29 من أصل 29 إلزاميًا)، مع تشغيل كل سيناريو مرتين. الاختبار الوحيد الفاشل كان حول تنسيق تقرير السعة الاختياري. يبقى الوكيل للقراءة فقط؛ البشر هم من يقررون التغييرات الإنتاجية.
المصدر: Habr — хаб ИИ —
الأصلي
