لماذا تفشل وكلاء الذكاء الاصطناعي في بيئة الإنتاج: مما يتكوّن نظام LLM ناضج داخل الشركة

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

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

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

الثاني هو مقاييس الجودة: فبلا قياس لا يمكن معرفة هل تحسّن الأداء بعد كل تعديل في الـprompt أو تحديث للنموذج. والفرق التي لا تقيس تعمل ببساطة دون رؤية. الثالث هو القيود والحواجز الوقائية: يجب أن يعرف النموذج ما لا يحق له فعله، وما النبرة المقبولة، وما البيانات التي لا يجوز إرسالها إلى الخارج.

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

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

ثمة مسألة منفصلة كثيرًا ما تُهمَل، وهي المراقبة وقابلية التحكم. فمعظم الفرق الهندسية تجيد مراقبة الشيفرة التقليدية: مقاييس وسجلات وتنبيهات عند تجاوز العتبات. أما مع أنظمة LLM فالأمر أصعب جوهريًا، لأن «صحة» الإجابة مسألة ذاتية تعتمد على السياق. وتساعد هنا مجموعات التقييم (evals)، وهي أمثلة مختارة خصيصًا بمخرجات متوقعة معروفة، مع مقارنة آلية بالإجابات المرجعية، ومع نماذج LLM تعمل كحَكَم مستقل يقيّم جودة إجابات النظام الرئيسي وفق معايير محددة. كل هذا بنية تحتية ينبغي بناؤها عن قصد، لا الاتكال على أن النموذج «سيتدبّر أمره بنفسه».

جانب آخر لا يُعطى حقّه هو إدارة الإصدارات والتغييرات. ففي التطوير التقليدي هناك git وCI/CD واختبارات قبل النشر. أما في أنظمة LLM فيجب إدارة إصدارات الـprompts وقوالب السياق وإعدادات RAG والفهارس المتجهية. فتغيير الـprompt هو في الواقع إصدار جديد، ويجب التعامل معه على هذا الأساس: اختبار على بيانات حقيقية، وتدقيق في أثره على سلوك النظام، وإمكانية التراجع عنه. وبدون ذلك قد يتحول كل «تحسين» إلى مصدر لتراجعات غير متوقعة.

لن يكون مستقبل الذكاء الاصطناعي المؤسسي للشركة التي تسبق غيرها في اعتماد أقوى نموذج. بل سيكون للشركة التي تبني نظام ذكاء اصطناعي هو الأكثر قابلية للتحكم والقياس والأمان. فالنماذج تزداد رخصًا مع كل ربع سنة، وقد باتت سلعة عادية (commodity). أما الميزة التنافسية فتكمن في قدرة الشركة على دمجها في عملياتها، ومراقبة الجودة، والتوسّع دون التضحية بالموثوقية.