نجحت تجربة أجراها مطور مستقل باستخدام ثلاثة نماذج من Claude في خفض تكاليف الـ API الشهرية بنسبة 35% وتقليل متوسط زمن استجابة المهام من 42 ثانية إلى 27 ثانية. ومن خلال توجيه المهام البسيطة ومنخفضة الغموض إلى نموذج Haiku الرخيص، والمهام الروتينية إلى Sonnet، وحجز نموذج Opus الثقيل للمشكلات عالية المخاطر، أثبت المؤلف أن عادة "استخدام أفضل نموذج لكل شيء" هي عادة مكلفة.
لماذا كان التوجيه مهماً
يدير المؤلف وكيل برمجة ذاتي (autonomous coding agent) يتلقى تدفقاً مستمراً من مهام التطوير — مثل إصلاحات الـ lint، وإضافة الميزات، والمراجعات الأمنية، وجلسات تصحيح الأخطاء العميقة. لعدة أشهر، كان الوكيل يرسل كل طلب إلى Opus، وهو أقوى نماذج Claude، بافتراض أن الجودة العالية ستتفوق دائماً على السعر. وبما أن Opus يتطلب سعراً مرتفعاً لكل توكن (token)، فقد تضخمت الفاتورة دون رقابة.
عندما أدخل المؤلف نظام توجيه متعدد المستويات، انخفض الإنفاق إلى 65% من مستواه الأصلي، وانخفض استخدام Opus إلى 11% فقط من إجمالي المهام.
كيف يعمل النظام ثلاثي المستويات
يعتمد منطق التوجيه على الغموض، وليس على عدد أسطر الكود التي تمسها المهمة. وقد حدد المؤلف ثلاث فئات:
- Haiku – مهام منخفضة الغموض ومحددة النتائج (deterministic). أمثلة: إصلاح تحذيرات الـ lint، إعادة تسمية المتغيرات، تلخيص ملفات السجلات (log files). عادة ما تكون الإجابة الصحيحة سطراً واحداً من الكود أو النص.
- Sonnet – المحرك الأساسي الافتراضي. يتولى تنفيذ الميزات، وإصلاح الأخطاء الروتينية، وعمليات إعادة الهيكلة (refactors) القياسية حيث تكون المشكلة واضحة ولكن الحل قد يتطلب عدة خطوات.
- Opus – مهام عالية المخاطر وعالية الغموض. مثل قرارات البنية التحتية (Architecture)، أو التدقيق الأمني، أو جلسات تصحيح الأخطاء المعقدة، أو أي مهمة يكون فيها المسار الصحيح غير واضح وقد يؤدي أي خطأ فيها إلى تعطيل عملية البناء (pipeline).
يقوم جدول بحث ثابت بربط كل طلب وارد بالنموذج المناسب بناءً على هذه القواعد. جرب المؤلف نموذجاً "ذكياً" يقرر المستوى أثناء التشغيل، لكن استهلاك التوكنات الإضافي محا أي توفير. غطت القواعد الثابتة البسيطة حوالي 80% من عبء العمل وحافظت على النظام رخيصاً وقابلاً للتنبؤ.
شبكة أمان التصعيد
لا تزال النماذج الرخيصة ترتكب أخطاء. ولمنع استجابة خاطئة من Haiku أو Sonnet من تعطيل عملية البناء، يقوم النظام بتصعيد الطلب بعد فشلين، وترقيته إلى المستوى التالي. تلتقط شبكة الأمان هذه الأخطاء مبكراً وتحافظ على سير عملية البناء بسلاسة دون تدخل يدوي.
أرقام تتحدث عن نفسها
بعد أربعة أسابيع من تشغيل الموجه متعدد المستويات، سجل المؤلف هذه التغييرات:
- الإنفاق على الـ API انخفض إلى 65% من التكلفة الأصلية (تخفيض بنسبة 35%).
- متوسط وقت الإنجاز انخفض من 42 ثانية إلى 27 ثانية.
- استخدام Opus تقلص من معالجة كل طلب إلى 11% فقط من إجمالي المهام.
تظهر هذه الأرقام أن معظم أعمال التطوير يمكن تفويضها إلى نماذج أرخص دون انخفاض ملحوظ في الجودة، بينما لا تزال المشكلات الأكثر صعوبة تستفيد من نافذة السياق (context window) الأكبر في Opus.
دروس للمطورين الآخرين
- ابدأ بالنماذج الأقل، لا الأعلى. معظم مهام البرمجة اليومية لا تحتاج إلى أقوى نموذج. جعل Sonnet هو الخيار الافتراضي للمهام الغامضة وفر أموالاً أكثر مما لو تم تمرير كل شيء عبر Haiku.
- قِس الصعوبة، لا الحجم. قد يكون إصلاح حالة تسابق (race condition) في سطر واحد أصعب من إعادة هيكلة ملف كامل. قم بالتوجيه بناءً على مدى غموض الحل، وليس بناءً على عدد الأسطر التي تم تغييرها.
- راقب معدل التصعيد. يشير ارتفاع عدد عمليات التصعيد إلى أن القواعد الثابتة لم تعد تتوافق مع عبء العمل. قم بتعديل الفئات قبل أن تبدأ النماذج الرخيصة في التسبب في المزيد من حالات فشل عملية البناء.
إن حجز النموذج الأكثر تكلفة للمشكلات الأكثر صعوبة وترك النماذج الأرخص تتولى الباقي يحافظ على سرعة وتكلفة تطوير البرمجيات المدعوم بالذكاء الاصطناعي. تكمن الميزة الحقيقية في استراتيجية توجيه منضبطة تطابق الأداة المناسبة للمهمة المناسبة.