لماذا اتجهت IBM أصلاً نحو الوكلاء
نادراً ما يشتري العميل المؤسسي نموذجاً من أجل عروض توضيحية جميلة. إنه يحتاج إلى أن يقوم البرنامج بشيء ما: تصنيف التذاكر، ومطابقة الفواتير، واستدعاء واجهات API الداخلية، وكتابة ملخصات للمستندات. وهذه هي بالضبط النيش الذي تشغله المنطقية الوكيلية — حين لا يكتفي النموذج بالإجابة عن سؤال، بل يقرر بنفسه أي أداة يستدعيها بعد ذلك.
Granite 4.2 في هذه القصة ليس «نموذجاً كبيراً آخر»، بل محاولة من IBM لاستكمال خط منتجاتها بحيث يعمل بثقة متساوية في السحابة وداخل البيئة المغلقة للعميل. والرهان هنا على مزيج من ثلاثة أشياء: أوزان مفتوحة، ومتطلبات متواضعة من العتاد، وسلوك متوقع عند استدعاء الدوال الخارجية.
ما الذي تمثله عائلة Granite أصلاً
تدير IBM عائلة من النماذج المفتوحة تحت الاسم الجامع Granite منذ سنوات عدة. وقد تشكلت خلال هذه الفترة فلسفة واضحة المعالم: تُصدر النماذج بأحجام متعددة، وتستهدف في المقام الأول البرمجة، والعمل مع الجداول، واستخراج البيانات من المستندات، والسيناريوهات المؤسسية، لا التنافس في اختبارات الدردشة العامة.
الأحجام لها أهمية
يُبنى خط المنتجات على شكل سلّم — من الخيارات الصغيرة جداً التي تتسع على بطاقة رسومات واحدة أو حتى تعمل على المعالج، وصولاً إلى نماذج الفئة المتوسطة. والفكرة أن يكون بالإمكان اختيار الحجم الأدنى الكافي لكل مهمة. فبالنسبة لوكيل يقوم أساساً بتوجيه الطلبات واستدعاء الدوال، غالباً ما يكون النموذج العملاق مفرطاً: فهو أغلى في الاستدلال وأبطأ في الاستجابة.
معمارية هجينة
في الفرع الرابع من العائلة انتقلت IBM إلى مخطط هجين، حيث تُبنى بعض الطبقات على Mamba وبعضها على الانتباه الكلاسيكي للمحوّل. والمكسب العملي هنا عادي: تُعالَج السياقات الطويلة بتكلفة أقل، وتُستهلك الذاكرة باقتصاد أكبر، وتكون الإنتاجية على العتاد نفسه أعلى. وهذا أمر بالغ الأهمية للسيناريوهات الوكيلية، لأن السياق يُحمَّل باستمرار بنتائج استدعاءات الأدوات ومقتطفات المستندات وسجل الخطوات.
ترخيص بلا مفاجآت
تُوزَّع نماذج Granite بموجب ترخيص Apache 2.0. وبالنسبة للمستشار القانوني المؤسسي هذا خبر ممل، وهو بالضبط خبر جيد: يمكن التدريب الإضافي، والتضمين في منتج تجاري، والنشر داخل المحيط المؤسسي، دون تقديم تقارير إلى المورّد عن حجم أرباح المنتج.
الحجة الرئيسية: يمكن الاحتفاظ به عندك
واجهات API السحابية مريحة بالضبط إلى اللحظة التي تخضع فيها البيانات لقيود تنظيمية. فالبنك أو العيادة أو المنشأة الصناعية أو الجهة الحكومية كثيراً ما لا تستطيع فعلياً إرسال بعض المستندات إلى الخارج. وهنا يبدأ الحديث عن «العتاد الخاص».
ما يلزم فعلاً للتشغيل
الأمر الأساسي هنا ليس المسرّعات الفائقة، بل الحد الأدنى المعقول. تُشغَّل الإصدارات الصغيرة من Granite على بطاقة رسومات استهلاكية واحدة، أو في حاوية على خادم بلا GPU، أو على حاسوب محمول للمطوّر. أما الأحجام المتوسطة فتتطلب عدة بطاقات أو تكميماً. ويجري التشغيل عادة عبر أدوات قياسية مثل vLLM أو Ollama، ما يزيل مشكلة الارتباط بحزمة تقنية حصرية من المورّد.
الأمان والقابلية للتنبؤ
الطبقة الثانية من الحجة هي التحكم. فحين يعيش النموذج داخل محيطك، تقرر أنت ما السجلات التي تُكتب، وما البيانات التي تدخل في prompt، وما يُخزَّن مؤقتاً وكيف وكم من الوقت يُحفظ. وهذا مهم بشكل خاص للوكلاء: فهم قادرون على تنفيذ إجراءات، لا مجرد توليد نص، ويُستحسن تمرير كل إجراء من هذا القبيل عبر قواعدك الخاصة ومراجعتك.
وتبيع IBM هنا ليس النموذج فحسب، بل أيضاً البنية المحيطة: منصة watsonx، ومجموعة نماذج «حرّاس» لتصفية المحتوى غير المرغوب فيه، وأدوات التدريب الإضافي على بياناتك الخاصة. والنموذج في هذا المخطط تفصيل، وإن كان تفصيلاً مركزياً.
كيف يبدو السيناريو الوكيلي عملياً
فكرة الوكيل بسيطة: يتلقى النموذج مهمة، ويقرر ما البيانات التي تنقصه، ويستدعي الأداة اللازمة، ويقرأ الرد ويواصل حتى يصل إلى النتيجة. والفرق بين «مجرد دردشة» والوكيل هو وجود حلقة وصلاحيات.
الأدوار النموذجية التي تُصمَّم لها هذه النماذج:
- الموجِّه. يحلل الطلب الوارد ويقرر أي سيناريو يُحال إليه.
- المستخرِج. يستخرج الحقول من الفواتير والعقود وكشوف الحسابات ويضعها في بنية.
- المنفِّذ. يستدعي واجهات API للأنظمة الداخلية: ينشئ طلباً، ويحدّث حالة، ويرسل بريداً.
- المراجِع. يفحص نتيجة الخطوة السابقة ويقرر ما إذا كان يمكن قبولها.
النموذج الصغير في كل خطوة من هذه الخطوات غالباً أكثر جدوى من نموذج كبير واحد: أرخص، وأسرع، وأسهل في الاختبار، والأهم أنه أسهل في الاستبدال إذا لم يعد مستوى الجودة مقبولاً.
ما الذي يجب النظر إليه وأين القيود
النماذج المفتوحة ليست حبة سحرية، والحديث الصادق عن القيود أنفع من التسويق.
الحجم مقابل جودة الاستدلال
النماذج الصغيرة اقتصادية، لكنها لا تزال أدنى من الكبيرة في المهام المعقدة متعددة الخطوات. وعادة ما يُبحث عن الحل الوسط معمارياً: توزيع الأدوار بين عدة نماذج صغيرة، وإضافة فحوصات حتمية على الكود، وإبقاء حق القرار النهائي للبشر.
المنظومة المحيطة
الأوزان المفتوحة تعني أن النموذج ينتقل بسهولة بين الأطر — من LangChain إلى منسّقات مكتوبة يدوياً. والوجه الآخر: الحلول الجاهزة «الجاهزة للاستخدام» لقطاع معين أقل مما هو متاح لدى المنصات المملوكة، وجزء من عمل التكامل يقع على عاتق فريق العميل.
العتاد وتكلفة الملكية
العتاد الخاص لا يعني التوفير في API فحسب، بل أيضاً نفقات رأسمالية وكهرباء وتبريداً وأشخاصاً يخدمون كل ذلك. وبالنسبة لشركة صغيرة ستكون السحابة دائماً تقريباً أرخص؛ أما للشركة الكبيرة ذات البيانات الحساسة فالعكس، وهذه العتبة تتزحزح بحسب الأحجام.
تقييم الجودة
الفخ الرئيسي هو قياس الوكيل باختبارات عامة. فالوكيل العامل يُختبر على سيناريوهاته الخاصة: مجموعة مهام حقيقية بإجابة صحيحة معروفة، ومقاومته للبيانات الدخيلة، وسلوكه حين تُعيد الأداة المستدعاة خطأ. وبدون مجموعة كهذه، يبقى أي رقم من ملاحظة الإصدار مجرد رقم من ملاحظة الإصدار.
ما الذي يترتب على ذلك
تبدو استجابة IBM للحظة الراهنة في السوق منطقية. فبينما يسعى البعض وراء الجودة القصوى في السحابة، يسدّ آخرون النيش الذي يكون فيه التحكم والسعر لكل رمز وإمكانية نشر كل شيء داخل المحيط أهم. أوزان مفتوحة، زائد متطلبات متواضعة من الموارد، زائد تركيز على استدعاء الأدوات — هذه بالضبط هي الحزمة التي يحتاجها العميل المؤسسي الذي تعب من التفاوض على إرسال البيانات إلى الخارج.
والسؤال الرئيسي ليس ما إذا كانت النسخة الجديدة ستتفوق على الرواد في الاختبارات العامة. السؤال هو ما إذا كان لدى الفريق الانضباط الكافي لبناء محيط وكيلي سليم حول النموذج: بصلاحيات محدودة، ومراجعة، واختبارات، وتراجع واضح. فإن كان الأمر كذلك — يصبح الاحتفاظ بمثل هذا الوكيل على عتادك الخاص استراتيجية عملية تماماً، لا حلاً وسطاً.
