نموذج تشغيل الذكاء الاصطناعي: من التجارب إلى التبنّي المؤسسي

لماذا لا تتوسع تجارب الذكاء الاصطناعي من تلقاء نفسها؟

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

في منصة DILA كان التحول بالتوقف عن بناء كل تطبيق على حدة وتجميع مكوّنات موحّدة وخاضعة للحوكمة بدلًا من ذلك.

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

ما الذي يتضمنه نموذج تشغيل الذكاء الاصطناعي فعليًا؟

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

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

ما الذي يتغير في كل مرحلة من مراحل النضج؟

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

كيف تبني المنصة وقواعدها معًا؟

لا تُعاد استخدام القدرات المشتركة في معالجة الوثائق والاسترجاع والتقييم والأمن إلا إذا وثقت بها الفرق. وتأتي الثقة من حوكمة تُحدَّد مع المنصة لا بعدها. فإذا تأخرت القواعد، تكون كل فرقة قد اتخذت خياراتها، وتصبح المنصة خيارًا إضافيًا لا المسار الافتراضي.

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

ماذا قسنا في منصة DILA؟

DILA جهة عامة تتبع مصالح رئيس الوزراء. الأرقام التالية مأخوذة من دراسة الحالة المنشورة، وأوردها كما وردت دون تعميمها على سياقات أخرى. ويجدر الانتباه إلى أنها تجمع بين مؤشرات السرعة والكلفة وإعادة الاستخدام ومؤشرات جودة الاسترجاع، فالتسريع وحده لا يكفي إن لم تُقِس الجودة بالصرامة نفسها.

• أصبح إنشاء المحتوى أسرع بنسبة 70%.
• انخفض زمن تسليم تطبيق RAG بنسبة 60%، من 10 أسابيع إلى 4.
• أُعيد استخدام 75% من القدرات التقنية المشتركة بين التطبيقات.
• انخفضت كلفة كل طلب ذكاء اصطناعي بنسبة 30% عبر التحسين وإعادة الاستخدام.
• انخفض زمن تنفيذ النماذج الأولية لمسارات العمل الوكيلة بنسبة 50%.
• سجّلت سلسلة RAG نتيجة 0.94 في الأمانة، و0.91 في ملاءمة الإجابة، و0.89 في دقة السياق، و0.92 في استرجاع السياق، مع تغطية 85% من سيناريوهات RAG ذات الأولوية.

لماذا يُعدّ التبنّي مسألة بشر؟

المنصة التي لا يعرف أحد استخدامها كلفة. والتدريب جزء من نموذج التشغيل: في Devoteam درّب برنامج LEAP، الذي يقوده فريق من خمسة أشخاص، أكثر من 1,500 متخصص على الذكاء الاصطناعي التوليدي والوكيل وRAG، ووصلت NOVA إلى 800 موظف في مجموعة تضم أكثر من 10,000 مستشار في 25 دولة.

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

ما أكثر الأخطاء شيوعًا عند التوسع في الذكاء الاصطناعي؟

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

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

كيف تحكم وكلاء يتصرفون ولا يكتفون بالإجابة؟

وللوكلاء الذين يتصرفون ينطبق المنطق نفسه على الرقابة. فالوكيل الذي يستطيع استدعاء الأدوات يحتاج إلى حدود تُفحص في كل مرة لا عند التصميم فقط. يستكشف TrustRail، وهو مستودع عام، السياسات والموافقات البشرية والإيصالات الموقّعة: يسجّل لكل عملية محمية أي وكيل طلبها ومن أذن بها وما الحدود المطبقة وما الأدلة التي تدعم النتيجة. ويعمل في بيئات تجريب اصطناعية، فهو دراسة تصميم لا ادعاء استخدام في الإنتاج.

ويطبّق إطار agentic-sdlc الفكرة نفسها على وكلاء البرمجة تحت اسم الاستقلالية المكتسبة: يحصل الوكيل على حرية أكبر حيث تستطيع الفحوص الآلية إثبات عمله، ويفقدها حيث لا تستطيع. وهو إطار عمل لم تتحقق منه دراسة مستقلة، وأقدّمه على هذا الأساس. ولذلك أنصح بقراءة هذه الأعمال بوصفها نقاط انطلاق للنقاش مع الفرق، لا وصفات جاهزة تُطبَّق كما هي.