كتبنا الأسبوع الماضي عن تغذية تيرابايت من سجلات CI إلى نماذج اللغات الكبيرة. معظم الأسئلة لم تكن حول السجلات، بل حول الوكيل: ما هي النماذج، وكيف يتم تنسيقها، وكم تكلف. اليوم، نقوم بتشغيل Opus 4.6 وندفع أقل مما كنا عليه عندما كنا نشغل كل شيء على Sonnet 4.0.
دع الوكيل الرخيص يقرر ما إذا كانت هناك حاجة إلى الوكيل الباهظ الثمن
قمنا بتحليل 4000 فشل في CI الأسبوع الماضي. 818 منها كانت مشاكل جديدة، بينما كانت 3187 مشكلة معروفة. ليس من المنطقي إيقاظ نموذج باهظ الثمن عندما تكون الإجابة في 80% من الحالات ‘it’s a duplicate’.
- استخدمنا Sonnet لتحقيق التوازن بين التكلفة والأداء، لكنه كان باهظ الثمن ولم تكن النتائج جيدة مثل النموذج الحدودي.
- تحولنا إلى ‘triager’ النمط: وكيل هايكو بوظيفة محددة وضيقة للغاية.
الوكيل يخطط، والوكلاء الرخيصون يقومون بالعمل
ينظر Opus إلى ما فشل، ويشكل فرضية، ويفرز عملاء فرعيين من Haiku للقيام بالحفر الفعلي. يتلقى كل وكيل فرعي مطالبة من Opus: ما الذي يجب البحث عنه بالضبط، وكيفية البحث، وما الذي يجب إرجاعه.
قبل بضعة أسابيع، فشلت ثلاث وظائف في Storybook CI في نفس الالتزام، وتعطلت جميعها. بدأ Opus بمطالبة وكيل فرعي بإحضار رسائل الخطأ من خطوة تثبيت pnpm الفاشلة.