LegalOn تخفّض نفقات Codex اليومية بنسبة 65% دون التضحية بالسرعة

خفّضت LegalOn نفقات Codex اليومية التقديرية بنسبة 65% دون أن تخسر شيئًا من سرعة التطوير. هذا ما أوردته مدونة OpenAI. يرد في عنوان المادة «النصف»، لكن الرقم الفعلي أعلى: فإذا انخفضت النفقات بنسبة 65%، فإن الشركة تدفع الآن نحو 35% من المبلغ السابق، أي أقل بنحو 2,9 مرة تقريبًا.

ما الذي فعلته الشركة تحديدًا

يذكر الوصف المختصر المنشور أسلوبين. الأول: طابقت LegalOn بين المهام والخيارات Astra وSol وLuna. الثاني: أدارت الشركة الميزانيات بصورة استراتيجية. أما ما تعنيه الأسماء Astra وSol وLuna (نماذج مختلفة أم أوضاع تشغيل أم تهيئات) وكيف تختلف في السعر والقدرات، فلا يوضحه المقطع المتاح. لذلك لن نخمّن.

لكن المنطق واضح ومألوف لكل من يدفع مقابل الرموز (tokens). فالعمل الروتيني لا يستدعي تمريره عبر أغلى خيار. يمكن إسناد التعديلات البسيطة وتوليد الشيفرة النمطية وعمليات إعادة الهيكلة الصغيرة إلى مستوى أرخص، وترك القرارات المعمارية المعقدة وسياق تصحيح الأخطاء المتشابك للخيار الأغلى والأقوى.

الأرقام والحقائق الرئيسية

• انخفاض نفقات Codex اليومية التقديرية: 65%.
• سرعة التطوير: حُفظت، ولا توجد بيانات كمية في المصدر.
• الخيارات الثلاثة المستخدمة: Astra وSol وLuna.
• النهج: اختيار الخيار المناسب لنوع المهمة، إلى جانب إدارة الميزانيات.
• نوع المقياس: النفقات اليومية التقديرية تحديدًا، وليست فواتير مؤكدة عن فترة معينة.

أين يستدعي الرقم الحذر

كلمة «التقديرية» مهمة هنا. فهذا حساب تقديري لا رقم نهائي من المحاسبة، ويتوقف الكثير على أساس المقارنة المختار. إذا كانت جميع الطلبات تمر سابقًا عبر أغلى خيار، فإن توفير 65% يبدو واقعيًا بل متواضعًا. أما إذا كان الأساس نظامًا محسّنًا جزئيًا من قبل، فالنتيجة أبرز.

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

وأخيرًا، حجم المبلغ غير معروف: فنسبة 65% من مبلغ صغير تختلف عن 65% من ميزانية فريق كبيرة.

ما الذي يمكن تطبيقه عمليًا

يمكن الاستفادة من هذه التجربة حتى دون الاطلاع على تفاصيل LegalOn.

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

تُظهر حالة LegalOn أن نفقات البرمجة بالذكاء الاصطناعي قابلة للإدارة بقدر فواتير الحوسبة السحابية. ولن تتضح الصورة الكاملة إلا حين تظهر التفاصيل: ما هي Astra وSol وLuna، وكيف قيست السرعة.