أنثروبيك تطلق Fable 5.2: نتيجة بمستوى Opus مقابل نحو نصف التكلفة لكل مهمة

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

من أين يأتي التوفير

في FrontierCode 2.0 حصل Fable 5.2 بإعداد High على 45.3%، بينما حصل Opus 5.5 بإعداد Max على 45.5%. ويقيّم الاختبار ما إذا كان القائمون على صيانة المستودعات المفتوحة سيقبلون التعديلات التي يقترحها النموذج. وبحسب الشركة، كانت تكلفة المهمة لدى Fable في هذه المقارنة أقل بنحو الضعف. وتبلغ تكلفة واجهة النموذج الجديد البرمجية 8 دولارات لكل مليون رمز إدخال و40 دولارًا لكل مليون رمز إخراج. مصدر الأرقام هو إعلان أنثروبيك.

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

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

كيف تختبر على خلل مألوف

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

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

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

وبالنسبة إلى مدير المنتج، هذه طريقة لاختبار فرضية محددة: هل يمكن خدمة مزيد من الطلبات المعقدة بالميزانية نفسها؟ وبالنسبة إلى المؤسس، هي فرصة لتقدير تكلفة الميزة قبل أن يَعِد المستخدمين بمساعد غير محدود.

أين تنتهي الاستنتاجات المستمدة من الإعلان

تنطوي المقارنة المنشورة على قيد جوهري: النتائج عرضها المورّد نفسه. وقد تختلف مستودعاتك وأدواتك وتعليماتك ومعايير القبول لديك اختلافًا كبيرًا عن ظروف الاختبار. كما أن الفارق بين 45.3% و45.5% لا يثبت وحده تساوي النموذجين في جميع المهام الهندسية.

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

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