كيف تجعل Fable أرخص من Opus: إعادة صياغة هيكل تكلفة العملاء باستخدام التفويض

فابل مثل مدير يملك عقلية مهندس معماري مُخضرم: يُنجز التسليم مبكرًا، يكتب المواصفات بوضوح، ويقلّل من التدخل اليدوي المباشر. أما أوبس فيشبه مديرًا دقيقًا يقود متدرّبًا في تفاصيل التنفيذ الدقيقة. تستند هذه المقالة إلى مقال من Joon Lee X، وتفكك هيكل التكلفة الكامن وراء العمل عبر 3,000 جلسة تقييم.
(ملخّص سابق: أطلقت Anthropic "Claude for Small Business" مستهدفة أتمتة أعمال الذكاء الاصطناعي لدى الشركات الصغيرة والمتوسطة، لمساعدتك على تسريع إصدار الفواتير وحساب الرواتب..)
(إضافة إلى الخلفية: تشترط Anthropic التحقق عبر KYC بالاسم الحقيقي! ستحتاج بعض وظائف Claude إلى رفع مستندات إثبات الهوية، ما يوسّع ضغوط الامتثال)

فهرس المحتويات

Toggle

• المقدمة
• إعداد التجربة
• تكلفة وكيل واحد
• المدير الدقيق مع متدرّب vs المدير مع مهندس معماري مُخضرم
• ما بعد التسليم
• عندما لا يساعد التفويض
• الخلاصة

استبدلنا Opus 4.8 بـ Fable 5، لكن فواتير Devin انخفضت بدلًا من أن ترتفع.

تكلفة Fable 5 لكل توكن هي ضعف تكلفة Opus 4.8. لكن عندما استخدمنا بنية Fusion الجديدة، وشغّلنا النموذجين معًا على FrontierCode 1.1، صار Fable أرخص فعلًا. ليس أمرًا مفاجئًا أن درجاته أيضًا كانت أعلى. ستشرح هذه المقالة لماذا، وماذا يعني ذلك بالنسبة لـ "تسعير العمل الوكيلي".

المقدمة

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

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

لكن عندما يقوم نموذج القيادة بإسناد معظم العمل للخارج، هل تظل قيمة السعر لكل توكن التي يتقاضاها نموذج القيادة هي التي تتحكم في إجمالي الفاتورة؟ تكلفة Fable 5 لكل توكن أعلى بمرتين من Opus 4.8، لذا من المنطقي أن يصبح الوكيل الذي تقوده Fable أغلى. ولإيجاد الإجابة، أجرينا 3,000 جلسة تقييم على FrontierCode 1.1، عبر أربعة إعدادات: عندما تجلس Fable وOpus كل منهما على كرسي القيادة، ومع كل واحدة منهما، في حال وجود/غياب مساعد رخيص بالضبط.

النتائج في التشغيل الخالص (pure runs) جاءت كما تتوقع تمامًا: تفوقت نقاط Fable على Opus (60.8 مقابل 55.4)، وكانت التكلفة أيضًا أعلى. نموذج أفضل يعني فاتورة أكبر.

لكن مع وجود مساعد، تصبح الأمور أكثر إثارة للاهتمام.

عند تثبيت نفس المساعد، انعكس ترتيب التكلفة: Fable + المساعد كانت أرخص من Opus + المساعد (1.86 دولار مقابل 2.04 دولار)، ومع ذلك كانت الدرجات أعلى (60.7 مقابل 54.6). وبالمقارنة مع Fable الخالص، فإن Fable + المساعد خفّض التكلفة بنسبة 54% تقريبًا، بينما لم تتغير النتيجة إلا قليلًا.

| الإعداد | | --- | | الدرجة | | متوسط تكلفة كل تنفيذ | | --- | --- | | Fable 5(low)+ المساعد | 60.7 | $1.86 | | Opus 4.8(medium)+ المساعد | 54.6 | $2.04 | | Fable 5(low) | 60.8 | $4.03 | | Opus 4.8(medium) | 55.4 | $3.06 |

تثبت النتائج أن "تكلفة التوكن أعلى بمرتين" ليست رقمًا تقرأه بشكل صحيح. تكلفة وكيل واحد لا تعتمد أساسًا على السعر لكل توكن بقدر ما تعتمد على: كم مرة يمر نموذج القيادة بالجولات، وكم قدر من السياق يجرّه معه، والأهم—ما الذي يقرّر نموذج القيادة "ألا" يفعله بنفسه. الخلاف يعود إلى أسلوب الإدارة: Opus يتصرف كمدير دقيق يقود متدرّبًا؛ بينما Fable يتصرف كمدير مع مهندس معماري قادر.

إعداد التجربة

لنراجع بسرعة كيف تعمل بنية المساعد في Fusion. يمتلك وكيل القيادة كامل جلسة العمل: يتحدث مع المستخدم، يخطط، يراجع العمل، ثم يقدّم(commit). كما يوجد لديه وكيل مساعد فرعي مقيم (دائم) مخصص لإسناد المهام. يكتب نموذج القيادة موجز تسليم مكتوبًا بلغة واضحة؛ ثم يقوم وكيل فرعي يقوده نموذج أرخص بكثير بالتنفيذ داخل سياقه الخاص وإرجاع النتيجة. يراجع نموذج القيادة النتيجة ويقرر ما الذي سيحدث بعد ذلك.

للتحقق إلى أين تتجه التكلفة، قمنا بأمرين. أولًا، حللنا كل نداء LLM في جميع 3,000 جلسة عمل: أي نموذج كان يتحدث، وما الأدوات التي استدعاها، وكم عدد التوكنات التي قرأها/كتبها، وكم تكلف كل مرة في الاستدعاء. ثانيًا، اخترنا 40 مهمة للملاحظة القريبة: تلك التي كانت فيها Fable أرخص بوضوح، وتلك التي كانت فيها Opus أرخص بوضوح، ومجموعة أخرى عشوائية من منطقة وسط. لكل مهمة، قارنا تنفيذ Fable القيادي مع تنفيذ Opus القيادي جنبًا إلى جنب، وفحصنا مساراتهما لنلاحظ أين ذهبت الأموال.

تكلفة وكيل واحد

فيما يلي كيفية توزيع التكلفة بين نموذج القيادة والمساعد في تجاربنا:

| | | --- | | القيادة $ | | المساعد $ | | التكلفة الإجمالية لكل مرة $ | | متوسط عدد جولات القيادة لكل مرة | | توكنات الإدخال للقيادة (متراكمة) | | --- | --- | --- | --- | --- | | Fable + المساعد | $1.28 | $0.58 | $1.86 | 11.5 | 545k tok | | Opus + المساعد | $1.73 | $0.31 | $2.04 | 26.5 | 1,679k tok |

أنفقت Fable أموالًا على المساعد أكثر من Opus—بزيادة 0.27 دولار لكل تنفيذ. لكن أنفقت على نفسها أقل بمقدار 0.45 دولار. عدد جولات القيادة لكل مرة في Fable هو 11.5 مقابل 26.5 في Opus؛ وعدد توكنات الإخراج التي يولّدها Fable هو فقط ثلث ما يولده Opus (6.1k مقابل 19.0k)، كما أن استهلاك توكنات الإدخال لدى Fable هو أيضًا ثلث. Fable أغلى بوضوح لكل توكن، لكنها تتفوق عبر إدارة السياق وعدد الجولات.

تأتي وفورات توكن لدى Fable من أنها تتجنب العمل بطريقة أكثر مباشرة. واللافت أنها في 81% من حالات التنفيذ التي تقودها Fable، لم يقم نموذج القيادة مطلقًا بأي عملية تعديل برمجية من البداية حتى النهاية. أما بالنسبة لـ Opus، فهذه النسبة تبلغ 24% فقط. وفي 13% من حالات التنفيذ التي تقودها Fable، لم يقم نموذج القيادة أصلًا بقراءة أي ملف من مستودع repo بنفسه.

المدير الدقيق مع متدرّب vs المدير مع مهندس معماري مُخضرم

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

أما Opus فعادة ما يفوض متأخرًا—بعد استكشاف وتنفيذ طويلين لوحده؛ وفي ذلك الوقت تكون قرارات التصميم قد حُسمت، والملفات المهمة قد دخلت سياقه، وكانت أعمال التكلفة العالية قد أُنجزت كذلك.

في تنفيذ نموذجي تقوده Fable، تقوم أولًا بعدة خطوات استقصائية على repo، ثم تكتب موجزًا بمستوى مواصفات يَفوّض دورة التنفيذ + الاختبار + lint مرة واحدة بالكامل. بعد ذلك، تقوم عملية git show بمراجعة الـ diff، ثم يحدث التقديم.

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

أحيانًا تكون أول حركة في جلسة العمل التي تقودها Fable هي التسليم. وعلى نفس المهمة، يبدأ النموذجان القياديان بهذه الطريقة:

الإجراء التصحيحي الواضح هو إجبار Opus على التفويض أكثر في الاستكشاف. لكن فرض هذا السلوك غالبًا يضعف الأداء. معرفة متى يمكنك إسناد الاستقصاء بأمان ومتى يجب أن تتولاه بنفسك هي بحد ذاتها نوع من الحكم. النموذج الذي يُجبر على التفويض لا يكتسب ذلك النوع من الحكم تلقائيًا؛ بل سينقل الأشياء التي لا ينبغي تفويضها.

أسلوب إدارة كل نموذج يظهر أيضًا بوضوح في موجزات التسليم نفسها. عندما تفوّض Opus التنفيذ، فهي تصدر أوامر. بينما Fable تكتب وثيقة تصميم:

التفويض لا يغير فقط توزيع التكلفة؛ بل يغيّر جودة العمل. المهمة أعلاه المتعلقة بالتجزئة (hashing) مثال صارخ. مواصفات المهمة تطلب أن تكون دالة التجزئة على طول المؤشر(pointer) محدودة بتعقيد O(1). نفذ Opus ذلك بنفسه، لكنه لم يكتب هذا الشرط في أي مكان. في خطوة ما أثناء العملية، نسي هذا القيد، وسلم تنفيذًا بتعقيد خطي، فحصل على درجة 25. في المقابل، فوضت Fable باستخدام قيود على مستوى أعلى. كان موجزها يقول: "operator() يجب أن يكون على طول المؤشر O(1): لا يجوز إجراء مسح كامل للرموز token." نجح المساعد في التنفيذ وفقًا لذلك وحصد 94 درجة.

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

ما بعد التسليم

النصف الآخر هو ما الذي يفعله نموذج القيادة بما يعود به المساعد. غالبًا ما يقوم النموذجان القياديان بنفس الفحوصات الرخيصة: اتصالاتين أو ثلاثًا لاستدعاء git diff / git show. لكن Opus لا يكتفي بذلك. فهو يسحب ملفات المساعد إلى سياقه بمعدل أعلى بمقدار الضعف، ويُجري حتى 4 مرات من تعديلات التصحيح باستخدام سعر نموذج القيادة. وفي الحالة القصوى، يعيد بالكامل إنجاز المساعد، ويعيد كتابته بنفسه:

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

عندما لا يساعد التفويض

استراتيجية تفويض Fable ليست صالحة لكل شيء؛ فعندما لا توجد أجزاء قابلة للتفويض داخل المهمة، تنهار الفائدة. المهام التالية تبدو صعبة التفكيك:

• مهام قصيرة تتضمن عددًا قليلًا من جولات نموذج القيادة فقط، ولا يوجد "شيء" بين مرحلة "القرار" ومرحلة "التسليم" يمكن تفويضه.
• مهام تصحيح تتبعية/تسلسلية، حيث يكون السبب الجذري سلسلة طويلة من قرارات متتابعة. في هذا النوع، يكون تراكم السياق بحد ذاته هو العمل.

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

في بيئات الإنتاج الرسمية، تتعامل Fusion مع هذه المسألة على مستوى مختلف: يحدد قرار التفويض الأعمال التي تُترك لنموذج مكلف، بينما يحدد التوجيه(routing) هل يجب إشراك النموذج المكلف أم لا.

الخلاصة

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

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