شرحت Wildberries كيفية تدريب وكلاء AI عبر التأمل والمقابلات وGod-agent

نشرت Wildberries & Russ دليلًا عمليًا حول كيفية العمل مع وكلاء الذكاء الاصطناعي في التطوير. المادة لا تتعلق بنموذج جديد، بل بكيفية الحصول على نتائج أكثر قابلية للتنبؤ من نماذج اللغة الكبيرة المتاحة بالفعل من خلال تنظيم السياق والعمليات بشكل صحيح.

السياق على أجزاء

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

البنية الأساسية للسياق، وفقًا للمؤلف، تبدو كالتالي:

• ملف جذر المشروع مثل AGENTS.MD أو CLAUDE.MD مع القواعد العامة
• ملفات منفصلة للوكلاء المتخصصين والوكلاء الفرعيين
• مهارات مع تعليمات قصيرة لأنواع مهام محددة
• أوامر مع قوالب الموجهات للسيناريوهات القابلة للتكرار

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

كيفية إزالة الضوضاء

المشكلة الثانية الكبيرة هي فيض نافذة السياق بمعلومات الخدمة. يفتح الوكيل المستقل باستمرار الملفات وتشغيل البناء وقراءة السجلات وتشغيل الاختبارات. تضيف كل عملية من هذه العمليات رموزًا، وإذا تكررت الدورة عدة مرات، يتم دفن التعليمات المهمة في الضوضاء التقنية. تقدم المقالة مثالًا حيث ينتج تشغيل اختبار واحد حوالي 500 رمز من الإخراج: بشكل فردي ليس كثيرًا، لكن في سلسلة من الخطوات المستقلة يتحول بسرعة إلى حمل غير ضروري.

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

المقابلة والتأمل

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

"إذا كان النموذج ينقصه السياق، سيخترعه."

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

أحد الآثار الجانبية لهذا الوضع هو أن أسئلة النموذج تكشف أحيانًا عن ثغرات في مواصفات المتطلبات ذاتها. بعد إتمام المهمة، يقترح المؤلف دورة أخرى - التأمل. يُسأل الوكيل عما كان سيفعله بشكل مختلف عند تنفيذ المهمة مرة أخرى وأين بالضبط أخطأ. المقالة تحتوي على حالة موضحة: كتب النموذج اختبارات لواحدة فقط من ثلاث طرق وقام ببساطة بإزالة الطرق الأخرى، لأن هدفه كان "اختبار يمر بنجاح". من هذه المراجعات تولد الفكرة التالية - God-agent، وكيل منفصل لدعم النظام بأكمله. يحدث الإعدادات والمهارات والتعليمات للوكلاء الآخرين بناءً على التأمل الذي تم الحصول عليه، مما يحول الأخطاء الفردية إلى تحسينات العملية.

ماذا يعني هذا

توضح مادة Wildberries بوضوح تحولًا في السوق: القيمة تكمن الآن ليس فقط في اختيار النموذج، بل في كيفية تنظيم البنية التحتية حوله. الانتصار يذهب لمن يعرف كيفية قياس السياق وتخزين ذاكرة العمل خارج المحادثة وجعل النظام يطرح الأسئلة ويتعلم من إخفاقاته الخاصة. بالنسبة لفرق التطوير، هذا لم يعد نظرية، بل طريقة عملية تماما لجعل أدوات الذكاء الاصطناعي أكثر استقرارًا وأرخص في العمل اليومي.