لقد كان من الرائع رؤية المجتمع وهو يتعمق في MiniMax M2 الجديد، حيث سلط الكثيرون الضوء على مهاراته الرائعة في المهام الوكيلة المعقدة. وهذا أمر مثير بشكل خاص بالنسبة لي، حيث كان عملي يتركز على الجزء المتعلق بمحاذاة الوكلاء في مرحلة ما بعد التدريب. في هذا المنشور، أود أن أشارك بعض الأفكار والدروس الأساسية التي تعلمناها خلال هذه العملية.
مشكلة محاذاة الوكيل الحقيقي: معايير أم واقع؟
إذا كنت قد عملت مع LLM Agents، فقد شعرت بهذا الألم: يمكن أن يبدو النموذج نفسه رائعًا في إطار واحد وعديم الفائدة في إطار آخر. قد يسحق الوكيل لوحة صدارة استخدام الأداة ولكنه يفشل بشكل مذهل في مهمة بسيطة في العالم الحقيقي. تعد هذه الفجوة بين الأداء المعياري وسهولة الاستخدام العملي واحدة من أكبر التحديات في هذا المجال.
عندما قمنا بتصميم M2، كنا نعلم أنه يتعين علينا معالجة هذه المشكلة بشكل مباشر. وقد قادنا هذا إلى هدفين أساسيين، ومتضاربين في بعض الأحيان:
- التفوق على المعايير مفتوحة المصدر. تعتبر المعايير ضرورية لقياس القدرات “الخالصة”. على سبيل المثال، يقوم معيار مثل BrowseComp باختبار مهارات البحث المتطورة. في حين أن المستخدمين نادرًا ما يطرحون سؤالًا مفتعلًا مثل، “ابحث عن الورقة التي يكون فيها الحرف الثالث من اسم المؤلف التاسع هو “x”، فإن النموذج الذي يمكنه حل هذا السؤال يثبت أنه يتمتع بقدرات أساسية قوية.
- تعميم بقوة على العالم الحقيقي. هذا هو الجزء الأصعب والأكثر أهمية. يجب أن يؤدي الوكيل الرائع أداءً موثوقًا عبر الأدوات غير المألوفة، وIDEs/CLIs، وسقالات الوكيل، وإعدادات المستخدم. لا يمكن أن يكون مهرًا ذا خدعة واحدة؛ يحتاج إلى تعميم.
إذن، مع من نتحالف؟ الجواب هو على حد سواء. نحن نتوافق مع المعايير لبناء المهارات، ولكن يجب علينا في النهاية أن نتوافق مع المستخدم من خلال ضمان فعالية هذه المهارات في كل مكان.
على الرغم من أن طرق تحقيق المعايير تعتبر موضوعًا عميقًا ليوم آخر، إلا أنني أريد التركيز على الهدف الثاني الأكثر صعوبة: كيف ندرب عميلاً للعمل في البرية؟
الحاجة إلى التفكير المتداخل
في وقت مبكر من المشروع، اصطدمنا بجدار محبط. كان أداء الوكيل غير متسق، وواجهنا صعوبة في تشخيص السبب. بعد العديد من المناقشات، خاصة مع البروفيسور @Junxian He و@Wenhu Chen، توصلنا إلى أول استنتاج رئيسي لنا: الوكلاء يحتاجون إلى تفكير متداخل.
وهذا يعني أن المونولوج الداخلي للوكيل – “تفكيره” – يمكن ويجب أن يحدث في أي وقت أثناء المهمة، وليس مرة واحدة فقط في البداية مثل نموذج التفكير القياسي. هذا التصميم مهم لسببين:
- الحفاظ على التركيز على المهام طويلة المدى. مهام الوكيل المعقدة لها سياقات طويلة للغاية. لا تكفي عملية تفكير واحدة في البداية للحفاظ على متابعة التعليمات وتماسكها.
- التكيف مع الاضطرابات الخارجية. هذا هو الفرق الحاسم. تقدم مهام الوكيل اضطرابات مستمرة وغير متوقعة من العالم الخارجي (أي مخرجات الأداة). يجب أن يكون النموذج قويًا بما يكفي للتعامل مع هذه الاضطرابات وتشخيص الأخطاء واستخراج المعلومات المفيدة. تسمح عملية “التفكير” للنموذج بإعادة التقييم والتكيف بشكل مستمر مع المعلومات الجديدة من البيئة.
أصبح هذا المبدأ حجر الزاوية في فعالية M2.
نصيحة احترافية لمستخدمي M2: نظرًا لأن M2 يعتمد على التفكير المتداخل، فإن سياقه هو ذاكرته. للحصول على أفضل أداء، يجب عليك الاحتفاظ بسجل الجلسة بالكامل، بما في ذلك خطوات التفكير. لقد لاحظنا أن الكثير من تعليقات المجتمع حول فجوات الأداء تنبع من تجاهل هذا السياق الحيوي عن طريق الخطأ، وهو ممارسة شائعة مع نماذج تفكير أبسط.
التعميم الحقيقي يدور حول الاضطراب
كانت نظريتنا الأولية بسيطة: قياس الأداة هو تعميم للوكيل.
لقد بدأنا بمجموعة بسيطة من الأدوات (مترجم لغة Python، ومحرك بحث، ومتصفح) لبناء خط أساسي لقدرة استدعاء الأدوات. كانت خارطة الطريق واضحة: زيادة عدد الأدوات وتنوعها، ومن الطبيعي أن تتبع ذلك قدرة العميل على التعميم على الأدوات غير المرئية.
في البداية، نجح هذا. ارتفعت درجاتنا المعيارية إلى مستويات محترمة. ولكن عندما تعمقنا أكثر، أدركنا أننا كنا نحل المشكلة الخاطئة. لقد نجح النموذج في الاختبارات، ولكن إذا قمنا بتغيير البيئة ولو بشكل طفيف – مثل التبديل إلى إطار عمل سقالات مختلف – فسوف ينخفض أداءه. كنا لا نزال بعيدين عن هدفنا المتمثل في نموذج “مفيد عمليا”.
أدى هذا إلى إدراكنا الثاني والأكثر عمقًا: لا يقتصر تعميم الوكلاء على التكيف مع الأدوات الجديدة فحسب؛ يتعلق الأمر بالتكيف مع الاضطرابات عبر المساحة التشغيلية للنموذج بالكامل.
يبدو هذا مجردًا، لذا دعونا نقسمه. فكر في كل ما يمكن أن يتغير في مهمة وكيل واحدة:
- ال معلومات الأداة ومجموعة الأدوات المتاحة.
- ال موجه النظام تحديد شخصية الوكيل وقواعده.
- ال موجه المستخدم وهدفها المحدد .
- ال بيئة نفسها (الملفات وقواعد التعليمات البرمجية وواجهات برمجة التطبيقات).
- ال ردود الأداة عاد في كل خطوة. تناول نهجنا القديم “تحجيم الأداة” العنصر الأول فقط. لقد تجاهلت الاضطرابات في جميع الأجزاء الأخرى من العملية. مسلحًا بهذا الفهم الجديد، قام فريقنا ببناء خط بيانات شامل مصمم من أجل تعميم المسار الكامل. البيانات التي تولدها تدرب النموذج ليكون مستقرًا ضد الاضطرابات في كل خطوة. وكانت النتائج مشجعة بشكل لا يصدق. في الاختبارات الداخلية، قمنا بإلقاء سقالات غامضة ذات “بداية باردة” على M2 – وهي أطر عمل بالكاد أخذناها في الاعتبار – وتجاوز أداؤها توقعاتنا. تم تعميم قدرات استدعاء الأدوات ومتابعة التعليمات بشكل جميل.
ما هي الخطوة التالية؟
لقد علمنا عملنا على M2 قدرًا هائلاً عن العوامل والتعميم والبيانات، ولكنه فتح أسئلة أكثر مما أجاب. العديد من أفكارنا لا تزال على السبورة. وفي الأشهر المقبلة، سنستكشف هذه الحدود بشكل أكثر عمقًا، ولا يمكننا الانتظار لنقدم لك الجيل التالي من النماذج القوية والمفيدة حقًا.
المشاركة
- استخدم النموذج: نأمل مخلصين أن تضع M2 على المحك. يمكنك الوصول إليه من خلال قنواتنا الرسمية أو العثور على النسخة مفتوحة المصدر لإجراء بحثك الخاص.
- انضم إلى فريقنا: إذا كانت هذه هي أنواع التحديات التي تثير اهتمامك، فنحن نقوم بالتوظيف. نحن نبحث دائمًا عن الأشخاص المتحمسين للانضمام إلينا في مهمة بناء AGI. من فضلك أرسل لنا سيرتك الذاتية!
