لماذا يفشل وكلاء الذكاء الاصطناعي في الإنتاج: ما الذي يتكون منه نظام LLM الناضج في الشركة

يمكن لوكيل الذكاء الاصطناعي أن يترك انطباعاً رائعاً في العرض التوضيحي—إجابات واثقة وتعليمات منفذة وعدم وجود أخطاء صارخة في الأفق. لكن بمجرد دخوله عملية عمل حقيقية، تتغير الصورة: يختلط الوكيل في السياق ويقدم إجابات غير ذات صلة و"يهلس" حقائق ويفشل في التعامل مع الحالات الحدية. الفجوة بين العرض التوضيحي والإنتاج هي أحد أكثر المسائل إيلاماً التي تواجهها الفريق عند محاولة تطبيق الذكاء الاصطناعي في شركاتهم.

السبب في هذه الفجوة يكاد لا يكون في النموذج نفسه. نموذج اللغة الكبير المأخوذ بمعزل عن غيره هو أداة قوية لكنها عمياء: لا تعرف شيئاً عن السياق التجاري أو قيود الشركة أو ما حدث قبل ساعة في الأنظمة ذات الصلة. يعمل العرض التوضيحي لأن شخصاً ما اختار بعناية السياق الصحيح والبيانات الضرورية وصاغ الطلب بعناية.

في الواقع لا يوجد مثل هذا التعديل اليدوي—والنموذج يعمل بعمى. نظام اللغة الكبير الناضج في الشركة هو تجميع عدة مكونات إلزامية يعتبر كل منها حرجاً. الأول هو السياق: البيانات الذاتية ذات الصلة والمستندات وسجل التفاعلات وسياسات الشركة التي يتلقاها النموذج في لحظة الطلب من خلال RAG أو الحقن المباشر.

بدون هذا حتى النموذج الأكثر تقدماً سيجيب خارج الهدف. الثاني هو مقاييس الجودة: بدون القياسات لا يمكن فهم ما إذا تحسنت الأمور بعد تغيير موجه أو تحديث نموذج. الفريق الذي لا يقيس يعمل ببساطة بعمى.

الثالث هو حواجز الحماية والآليات الوقائية: يجب أن يعرف النموذج ما لا يمكنه القيام به والنبرة المقبولة والبيانات التي لا يمكن نقلها للخارج. الرابع هو التكاملات الآمنة: الاتصال بـ APIs الداخلية وقواعد البيانات بمستويات الوصول المناسبة وتسجيل كل استدعاء. الخامس والأكثر تقليلاً من الأهمية هو دور الإنسان المحدد بوضوح في العملية: فهم حيث يتصرف الوكيل بشكل مستقل وحيث تكون هناك حاجة لمراجعة يدوية أو تأكيد.

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

هنا تنكسر الأنظمة التي تفتقر إلى البنية الداخلية والآليات الوقائية. مسألة منفصلة وغالباً ما تكون مهملة هي المراقبة والقابلية للإدارة. تعرف معظم فريق الهندسة كيفية مراقبة الكود العادي: المقاييس والسجلات والتنبيهات الحدية.

مع أنظمة اللغة الكبير هذا أصعب بشكل أساسي لأن "صحة" الإجابة أمر ذاتي ويعتمد على السياق. هنا تساعد مجموعات التقييم (evals)—أمثلة منتقاة خصيصاً مع المخرجات المتوقعة المعروفة والمقارنة التلقائية مع الإجابات المرجعية وقضاة اللغة الكبير المنفصلون الذين يقيمون جودة إجابات النظام الرئيسي وفقاً لمعايير معينة. كل هذه البنية التحتية يجب أن تُبنى عمداً وليس شيء يُرجى منه أن النموذج "سيكتشفه بنفسه".

جانب آخر قلل من تقديره هو التحكم بالإصدارات وإدارة التغييرات. في التطوير العادي هناك git و CI/CD واختبارات قبل النشر. في أنظمة اللغة الكبير تحتاج إلى التحكم بإصدارات الموجهات وقوالب السياق وتكوينات RAG والمؤشرات المتجهة.

تغيير الموجه هو في الواقع إصدار ويجب معاملته وفقاً لذلك: مع الاختبار على البيانات الحقيقية ومراجعة تأثير السلوك على النظام والقدرة على الرجوع. بدون هذا يمكن لكل "تحسين" أن يصبح مصدراً للانحدارات غير المتوقعة. لا ينتمي مستقبل الذكاء الاصطناعي للشركات إلى الشركة التي تنشر النموذج الأقوى أولاً.

إنه ينتمي إلى الشركة التي تبني أكثر نظام ذكاء اصطناعي قابلية للإدارة وقابلية القياس والأمان. تصبح النماذج أرخص كل ربع سنة—إنها بالفعل سلعة. تكمن الميزة التنافسية في كيفية قدرة الشركة على دمجها في عملياتها والتحكم في الجودة والتوسع بدون فقدان الموثوقية.