بقلم: ليلى | محررة أدوات المطورين · صوت تحريري بإشراف بشري
بينما يتسابق الجميع نحو الـ prompt engineering وضبط نماذج اللغة الكبيرة، يقضي بعض مهندسي الذكاء الاصطناعي الأكثر خبرةً معظم وقتهم في بناء نماذج CatBoost وتدريب Isolation Forests — لا لأنهم متأخرون عن ركب التطور، بل لأن المنتجات الاحترافية الحقيقية تحتاج إلى هذا المزيج. فكرة أن نماذج ML الكلاسيكية أصبحت من الماضي مع صعود LLMs هي ببساطة خاطئة، وما يكشفه بناء منصات الذكاء الاصطناعي الوكيلي اليوم هو العكس تماماً.
الوكيل الذكي — أو AI Agent — ليس مجرد LLM يحادثك. هو منظومة تجمع نموذج اللغة بأدوات برمجية متعددة تعمل بحد أدنى من التدخل البشري، حيث يتولى LLM دور الواجهة التي تترجم اللغة الإنسانية إلى أوامر حاسوبية، وتفسّر مخرجات الأدوات، وتقرر متى تستدعي كل أداة. ChatGPT وGemini وClaude تفعل هذا يومياً بربط LLM بأدوات الاسترجاع والبحث والحسابات الرياضية وغيرها. لكن السؤال الذي يغفل عنه كثيرون: لماذا لا تكون نماذج ML الكلاسيكية إحدى هذه الأدوات؟
خذ مثالاً عملياً: وكيل ذكي لتحليل العقارات. تعطيه عنوان عقار، فيستدعي أداة API لاسترجاع تفاصيله، ثم يمرر هذه التفاصيل إلى نموذج regression مدرّب لتوليد تقدير سعري دقيق. يمكن نظرياً أن تطلب من LLM تقدير القيمة مباشرةً — لكن ذلك مغامرة غير محسوبة لستة أسباب جوهرية يجب أن يعرفها كل مطوّر:
- الدقة: LLM يخمّن ولا يحسب. النموذج الكلاسيكي المدرّب جيداً يقوم على أدلة تجريبية، وفارق الدقة بين الاثنين في مهام الأرقام الحرجة كبير جداً لتجاهله في بيئة إنتاجية.
- قابلية التفسير: LLM صندوق أسود — لا تعرف المسار الذي سلكه للوصول إلى إجابته. النموذج الكلاسيكي يتيح تتبع كل قرار أُخذ أثناء الاستدلال، والتحقق منه في مواجهة خبرتك الميدانية.
- التكلفة: تشغيل LLM مكلف بطبيعته (وأسعار التوكن ترتفع عبر قطاع التقنية بأكمله)، ولا تتحكم في تكلفة كل استدعاء. في المقابل، تشغيل classifier أو نموذج regression خفيف جداً حتى عند حجم هائل من الحالات.
- الضبط والتحكم: لا تتحكم في تدريب LLM أو ضبطه إلا إذا أجريت fine-tuning على نموذج أساسي — وهذا يستلزم بيانات أكثر ومهارات أكثر تخصصاً من مجرد تدريب نموذج regression أو classifier، مع بقاء مشكلة التفسيرية قائمة.
- سيادة البيانات: بياناتك قد تغادر بيئتك المحكومة وتصل إلى مزوّد LLM خارجي، وهو خطر امتثالي وأمني لا يمكن تجاهله في القطاعات الحساسة.
- التحكم في البنية التحتية: مع LLM خارجي، أي انقطاع من طرف المزوّد يتحول مباشرةً إلى خطر على استمرارية أعمالك، بينما النموذج الكلاسيكي الذي تديره بنفسك يظل تحت سيطرتك الكاملة.
بناء نماذج كلاسيكية عالية الجودة يتطلب مهارات مختلفة: فهم البيانات بعمق، والاستعداد لهندسة الخصائص بخبرة ميدانية، وامتلاك قدر كافٍ من البيانات والحوسبة. إن كنت تفتقر إلى البيانات المُصنَّفة، سيقتصر خيارك على التعلم غير الإشرافي أو توليد تصنيفاتك الأولية. لكن المنظومة التعليمية حول بناء هذه النماذج وتقييمها ومراقبتها بعد النشر ثرية جداً — أدوات مثل XGBoost وLightGBM وscikit-learn وCatBoost موثقة توثيقاً ممتازاً وتصلح نقطة انطلاق عملية.
أما على مستوى الهندسة المعمارية، فثمة مساران رئيسيان لربط النموذج الكلاسيكي بوكيلك الذكي. الأول هو الاستدعاء المباشر: يمتلك الوكيل النموذج كأداة يستدعيها مباشرةً عند الحاجة، ويولّد inference فورياً بناءً على prompt معين. هنا يجب أن يكون الوكيل قادراً على صياغة طلباته للنموذج بالشكل الصحيح، ومزوّداً بتوثيق واضح لغرض النموذج ومتى يُستدعى ومتى تُستخدم أداة أخرى. الأهم أن مخرجات النموذج يجب أن تكون منظمة بما يسمح للوكيل بتفسيرها — مجرد إعادة رقم احتمالية لا يكفي. من الأساليب المجدية هنا استخدام f-strings لبناء أوصاف نصية تتضمن أهم الخصائص المؤثرة، وقيمة الاحتمالية، وأي سياق يحتاجه الوكيل لإنتاج استجابة مفيدة للمستخدم النهائي.
المسار الثاني هو الوصول عبر قاعدة البيانات: بدلاً من جعل النموذج أداةً مباشرة، يصبح مزوّداً لبيانات السياق. تشغّل النموذج الكلاسيكي كعملية مجدوَلة تحسب استنتاجاتها مسبقاً وتخزّنها في قاعدة البيانات التي يصل إليها الوكيل. هذا النهج مثالي عندما تعمل على مجموعة محدودة من الحالات — مثال: لديك 500 عميل في قاعدة بياناتك، والوكيل يحتاج إلى معلومات صحتهم الائتمانية؛ يمكنك تشغيل نموذج تسجيل ائتماني مسبقاً وتخزين النتائج كي يسترجعها الوكيل في وقت التشغيل. هذا يقلل من الكمون والتكرار بشكل فعلي. الشرط الوحيد: الوكيل يجب أن يكون مدركاً بوجود هذه النتائج في قاعدة البيانات، وإلا لن يستخدمها عند الحاجة — وهذا يتم عادةً ضمن هندسة الـ prompt أو عبر أدوات تتيح للوكيل مراجعة metadata قاعدة البيانات.
نماذج ML الكلاسيكية كانت حافة القدرات عبر صناعات متعددة لأكثر من عقد قبل أن تظهر LLMs على الساحة. هذا الإرث لا يُرمى، بل يُدمج. الذكاء الحقيقي في بناء الأنظمة الوكيلية اليوم يكمن في توزيع الأدوار بذكاء: LLM يتولى الواجهة وتفسير اللغة البشرية وتسلسل استدعاءات الأدوات، والنماذج الكلاسيكية تتولى الحسابات الحرجة التي تتطلب دقةً وتفسيريةً وتحكماً حقيقياً. إن لم تكن قد مارست XGBoost أو LightGBM أو scikit-learn مؤخراً، فهذه لحظة جيدة للعودة إليها — ليس لأنها نوستالجيا، بل لأن الأبحاث الحديثة تؤكد أن الذكاء الاصطناعي الوكيلي يحتاجها أكثر مما ظننا.
