Qwen يختار خطوة واحدة في كل مرة وبيئة التشغيل تتحقق: كيف يعمل وكيل ذكاء اصطناعي خاضع للضبط

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

النموذج يقترح وبيئة التشغيل تقرر

تُسمّى منصة الاختبار Governed Agent Runtime. وهي تحاكي خدمة دفع: الإصدارات والنسخ التشغيلية، والحمل بوحدة الطلبات في الثانية RPS، ومقاييس الخدمات التابعة، وقيود السعة وتحمل الأعطال وفق N-1. ويتولى دور الوكيل نموذج Qwen محلي؛ ويحدد المقال النسخة Qwen3.8:27b Q4_K_M. يختار النموذج الخطوة التالية، بينما تتحكم شيفرة حتمية في جواز العمليات وتنفيذها. وتتحقق هذه الشيفرة من الشروط المسبقة، وتطلب موافقة بشرية قبل أي تغيير في الحالة، وتدير ميزانيات استدعاء النموذج والأدوات.

من التفاصيل المهمة أن بيئة التشغيل تميّز بين حالات يسهل الخلط بينها. «طُلبت 8 نسخ تشغيلية» لا يعني أن 8 نسخ سليمة. و«حُوّلت حركة الطلبات» لا يعني أن الخدمة استعادت عافيتها. و«سُمح بالعملية» لا يعني أنها نُفذت. و«النموذج يعتبر المهمة منتهية» لا يعني أن الحالة النهائية تأكدت.

عندما كانت أداة التقييم هي المسؤولة

في خمسة سيناريوهات من خطوة واحدة، بثلاثة تشغيلات لكل منها، حقق Qwen نتيجة 12 من 15، بينما اجتازت ضوابط بيئة التشغيل 15 من 15. وأخفق السيناريو S12، الخاص بإعداد خطة للتراجع: أضاف النموذج إلى الخطة عتبات مثل «أخطاء 5xx أعلى من 5%» و«اعتبار الخدمة مستعادة عندما تبقى أخطاء 5xx دون 1% لمدة 5 دقائق». لم تكن هذه الأرقام موجودة في سياقه.

بعد إضافة حسابات المنصة إلى السياق — عند 820 RPS لا تكفي ست نسخ تشغيلية، ولا تحقق سبع نسخ شرط N-1، بينما تكفي ثماني نسخ — حصل النموذج مجدداً على تقييم سلبي. قارن الكاتب بين ثلاثة أمور: ما رآه النموذج ضمن المدخلات، وما طالبت به أداة التقييم، وما أجاب به. واتضح أن بعض متطلبات أداة التقييم لم يكن لها أساس في بيانات الإدخال. فأُعيد تصنيف النتيجة من «سلبية» إلى «غير محسومة».

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

خطوة واحدة في كل مرة

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

في السيناريو السلبي، أعادت المنصة النتيجة FAIL عند فحص استعادة الخدمة. وبدلاً من إتمام التراجع، اختار Qwen الأمر STOP، وسجّلت بيئة التشغيل SAFE_FALLBACK، وظلت المثيلات المتدهورة في مكانها.

الدروس المستفادة

أولاً: لا تمنحوا النموذج صلاحية التنفيذ. دعوه يقترح، واتركوا للشيفرة التحقق من الشروط المسبقة والحالة النهائية. ثانياً: افصلوا بين «مطلوب» و«مسموح» و«منفذ» و«مؤكد» بوصفها حالات مختلفة في السجلات وعقود الأدوات. ثالثاً: أداة التقييم نفسها مكوّن قد لا يتسق مع سياق الإدخال. إذا قيّمتم وكيلاً وفق معايير لم يكن بوسعه معرفتها، فأنتم تقيسون آليتكم الخاصة، لا النموذج.

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