بقلم: نور | محررة الأبحاث والدراسات · صوت تحريري بإشراف بشري
حين تبني نظام توجيه نماذج داخل وكيل ذكاء اصطناعي، يبدو الأمر بسيطاً: أرسل الطلبات السهلة إلى النماذج الرخيصة، واحتفظ بالقوية للمهام الصعبة. تُضيف مُصنِّفاً أو قاعدة بسيطة، تنخفض التكاليف، ويبقى الأداء كما هو. إلا أن فريق IBM Research يصف هذه القناعة بأنها وهم، ويقدّم دليلاً تجريبياً مفصّلاً على سبب انهيارها في ثلاثة محاور.
المحور الأول هو التكلفة الحقيقية. الحدس يقول إن GPT-4.1 أرخص من Claude Sonnet 4.6 لأن سعر التوكن لديه أقل على المدخلات والمخرجات. لكن عند تشغيل 417 مهمة على اختبار AppWorld باستخدام وكيل CodeAct، جاءت النتائج معكوسة تماماً (وفقاً لـ IBM Research): كلّف Sonnet إجمالاً 79 دولاراً بمعدل 0.19 دولار للمهمة، فيما بلغت تكلفة GPT-4.1 ضعف ذلك تقريباً بـ 155 دولاراً أي 0.37 دولار للمهمة. والأغرب أن Sonnet يحتاج نحو ثلاثة أضعاف خطوات الاستدلال لإتمام المهمة ذاتها.
السبب هو التخزين المؤقت (Caching) — وهو متغير تتجاهله معظم نقاشات التوجيه كلياً. الأحمال الوكيلة تعيد استخدام أجزاء كبيرة من السياق عبر الخطوات، وحين ترتفع معدلات إصابة الكاش، تنخفض تكلفة المدخلات الفعلية بشكل حاد. سعر قراءة الكاش المنخفض لدى Sonnet جعله يستفيد من هذا النمط أكثر من غيره، لدرجة تفوق فيها على التسعير الأساسي الأعلى وعدد الخطوات الأكبر. الخلاصة العملية: لا يمكنك تقدير التكلفة الحقيقية من بطاقة الأسعار وحدها — هي دالة مركّبة من النموذج وطبيعة الحمل والبنية التحتية للخدمة.
المحور الثاني هو تقدير الصعوبة. الاستراتيجية الشائعة هي قياس صعوبة المهمة وتوجيه الصعبة منها إلى النماذج الأقوى. منطقي، لكنه ينكسر من ناحيتين. أولاً، الصعوبة غالباً غير مرئية وقت التوجيه: طلب “لخّص هذا العقد” يبدو تافهاً، لكنه قد يُطلق استرجاعاً، وفحوصات امتثال، واستدعاءات أدوات، وجولات متعددة من التحسين. في المقابل، استفسار تقني معقد قد يعالجه نموذج صغير متخصص بكفاءة عالية. ثانياً، حتى لو أمكن تقدير الصعوبة بدقة مثالية، فهي إشارة واحدة وسط إشارات متعددة. في بيئات المؤسسات، يتقاطع التوجيه مع اشتراطات الامتثال، وقواعد إقامة البيانات، وقيود الخصوصية، وقوائم النماذج المعتمدة. مهمة قد تذهب مثالياً إلى نموذج معين لكنها مقيّدة بالحوكمة، والنظام يجب أن يُدير ذلك بصمت.
المحور الثالث هو زمن الاستجابة. البديهي أن النماذج الأصغر أسرع، لكن ما يختبره المستخدم فعلياً يتحكم فيه أكثر من ذلك: توجيه الطلب نفسه يُضيف تأخيراً، وظروف البنية التحتية — نوع العتاد، دفء الكاش، ازدحام النقطة النهائية — كثيراً ما تطغى على مزايا حجم النموذج. والأهم: التوجيه مرة واحدة لكل مهمة يُضيف حِملاً هامشياً، لكن التوجيه عند كل خطوة — الذي يمنحك مرونة التكيّف في منتصف التنفيذ — يُضاعف نقاط القرار ويرفع التعقيد التشغيلي بصورة مركّبة.
IBM Research”>أمام هذه التحديات، غيّر الفريق إطاره الذهني بالكامل: بدلاً من سؤال “أي نموذج هو الأفضل لهذه المهمة؟”، صاغوا المشكلة كمسألة تحسين متعددة الأبعاد تُوازن التكلفة والجودة وزمن الاستجابة في آنٍ واحد، مع إبقاء الموجّه نفسه خفيفاً بما يكفي ألا يصبح عنق الزجاجة. النتائج على AppWorld توضح الفرق (وفقاً لـ IBM Research):
- التهيئة الأولى (محسَّنة لزمن الاستجابة): دقة 84% بتكلفة 93 دولاراً وزمن استجابة 83 ثانية — أي توفير 21% في التكلفة و9% في زمن الاستجابة مقارنةً بتشغيل Claude Opus منفرداً، مقابل تراجع محدود 4% فقط في الدقة.
- التهيئة الثانية (محسَّنة للتكلفة): تدفع التكلفة إلى أدنى مستوياتها، مع الاحتفاظ بدقة معقولة في حالات الاستخدام الأقل حساسية للجودة.
- خفة الموجّه نفسه: تبلغ تكلفة خوارزمية التحسين نحو 6 ميلي ثانية و2 كيلوبايت من الذاكرة لكل مهمة — مما يجعلها عملياً غير مرئية في خط التنفيذ.
ما يكشفه هذا العمل ليس تقنية توجيه جديدة بقدر ما هو تصحيح لأطر التفكير الشائعة. موجّه الصعوبة التقليدي (المعين الفيروزي في الرسم) يصل إلى دقة مماثلة لكن عند تكلفة أعلى، لأنه لا يستكشف الفضاء الكامل من نقاط التشغيل الممكنة. النماذج مجرد متغير واحد — مهم، لكنه ضمن منظومة تشمل سلوك الكاش، وحالة البنية التحتية، وقيود الامتثال، وأنماط الحمل. حين يعمل التوجيه بشكل صحيح، نادراً ما يكون السبب أنه وجد “أفضل نموذج” للمهمة — بل لأنه وجد نقطة التشغيل المثلى للنظام بأكمله.
إذا كنت تبني توجيهاً في أنظمتك الوكيلة الآن، فالسؤال الحقيقي ليس “أي نموذج أختار؟” بل “ما هي محاور التفاضل التي يجب أن أُحسّنها معاً؟” — وهذا يستدعي قياس تكاليف الكاش الفعلية على حمولتك تحديداً، وليس الاعتماد على بطاقات الأسعار المنشورة. يعد الفريق بنشر تفاصيل تقنية إضافية في منشور لاحق.
