معظم تجارب الذكاء الاصطناعي، أي النماذج التجريبية (pilots)، لا تفشل لأن الفكرة خاطئة. تفشل لأن أحدًا لم يبنِ ما يسمح لنظام احتمالي بأن يعمل دون إشراف في سير عمل مهم. العرض التجريبي يثبت أن النموذج يستطيع أداء المهمة مرة واحدة. أما الإنتاج فيثبت أنه يستطيع أداءها عشرة آلاف مرة دون أن يلتقط إنسان كل خطأ.
نتعامل مع المسافة بين الاثنين على أنها خمس بوابات. كل بوابة تجيب عن سؤال سيطرحه أحدهم عاجلًا أو آجلًا قبل أن يسمح للنظام بالعمل دون إشراف، وكل واحدة رخيصة إذا بُنيت مبكرًا ومكلفة إذا أُضيفت لاحقًا. إذا تجاوزتم بوابة واحدة تعثّر النموذج التجريبي، وهو لا يتعثر في الهندسة غالبًا، بل في اجتماع المراجعة حين لا يستطيع أحد أن يجيب عن السؤال الذي وُجدت تلك البوابة للإجابة عنه.
البوابات الخمس
| البوابة | السؤال الذي تجيب عنه | كيف يبدو غيابها |
|---|---|---|
| التقييمات | هل هو جيد بما يكفي، وهل حسّنه هذا التعديل؟ | كل إصدار يتحول إلى جدال حول انطباعات |
| قابلية المراقبة | ماذا فعل بالضبط في هذه الحالة؟ | تعرفون بالخطأ من عميل غاضب |
| الضوابط | ما أسوأ ما يمكن أن يفعله؟ | لا يجتاز مراجعة الأمن ولا المراجعة القانونية أبدًا |
| التراجع | ماذا نفعل حين يتغير النموذج من تحتنا؟ | تحديث من المورّد يعطّله بصمت |
| المسؤولية | مَن صاحب هذا الرقم؟ | لجنة توافق عليه ولا أحد يطلقه |
البوابة 1: مجموعة تقييمات تقيس ما يهمّكم فعلًا
مجموعة التقييمات (evals) هي مجموعة ثابتة من حالات حقيقية معروفة النتائج الصحيحة، تُحتسب درجتها آليًا كلما تغيّر أي شيء. ليست فحصًا عشوائيًا، وليست سؤالًا من نوع «هل تبدو هذه المخرجات صحيحة؟»، بل رقم تقارنونه برقم الأسبوع الماضي.
من دونها تصير الجودة مسألة رأي. كل تعديل على التعليمات (prompt) يتحول إلى نقاش، ولا أحد يستطيع أن يقول هل أفاد التعديل، ولا أحد يقبل أن يوقّع على إصدار لا يستطيع قياسه. هذه ليست مشكلة في النموذج، بل غياب للمسطرة. لا يمكنكم إطلاق ما لا تستطيعون قياسه. ولهذا نعدّها البوابة التي تسبق كل البوابات، ولهذا خصّصنا لها مقالًا كاملًا (بالإنجليزية).
تكونون قد اجتزتم هذه البوابة حين تستطيعون تبديل النموذج أو إعادة كتابة التعليمات ثم تعرفون خلال دقائق هل تغيّرت الجودة، وفي أي اتجاه.
البوابة 2: قابلية مراقبة تُظهر ما فعله النظام فعلًا
لا نقصد لوحة متابعة بأرقام إجمالية، بل سجلًّا تفصيليًا لكل تشغيل: في أي تنفيذ بعينه ترون المدخلات، والسياق الذي استرجعه، والأدوات التي استدعاها، وما أعاده، وكم كلّف، وكم استغرق.
الأنظمة الاحتمالية تفشل بصمت. الخلل في برنامج حتمي السلوك يُظهر رسالة خطأ، أما النموذج فيعيد شيئًا خاطئًا قليلًا، بثقة تامة، ويواصل العمل. ومن دون سجلات التتبع (traces) تبقى هذه الأخطاء غير مرئية إلى أن تتراكم فيلاحظها إنسان. وهكذا تكتشف الفرق شهرًا كاملًا من المخرجات الخاطئة من تصعيد واحد في الدعم.
تكونون قد اجتزتم هذه البوابة حين يستطيع أحدكم أن يجيب في أقل من خمس دقائق عن سؤال: «لماذا فعل ذلك، في هذه الحالة تحديدًا، يوم الثلاثاء الماضي؟».
البوابة 3: ضوابط تحصر أسوأ الاحتمالات
قيود صريحة على ما يستطيع الوكيل أن يمسّه، وما يستطيع أن ينفقه، وما يستطيع أن يقوله، ومتى يجب أن يحوّل الحالة إلى موظف. حدود للنطاق مفروضة في الشيفرة، لا جملة في التعليمات ترجو النموذج أن يلتزم.
عند هذه البوابة يتوقف معظم النماذج التجريبية فعلًا، وقلّما تكون الهندسة هي السبب. السبب مراجعة الأمن، والمراجعة القانونية، ونقاش المخاطر الذي لا يُحسم لأن أحدًا لا يستطيع أن يصف حجم الضرر المحتمل في جملة واحدة. الوكيل الذي يتصرف جيدًا «على الأرجح» لا يمكن منحه صلاحية الكتابة في نظام إنتاج، فيبقى عرضًا تجريبيًا إلى الأبد. الحل أن تجعلوا أسوأ الاحتمالات صغيرًا وصريحًا، لا أن تجادلوا بأنه مستبعد.
تكونون قد اجتزتم هذه البوابة حين تستطيعون وصف أسوأ ما يمكن أن يفعله النظام في جملة واحدة، ويكون المسؤول عن ذلك الخطر مرتاحًا له.
البوابة 4: مسار تراجع لحين تتغير الأرض تحتكم
إصدارات نماذج مثبَّتة، وتعليمات وإعدادات محفوظة بإصدارات، وقدرة على العودة عند الطلب إلى حالة معروفة أنها تعمل جيدًا (rollback). النماذج التي تبنون فوقها ليست بنية تحتية مستقرة: المورّدون يوقفون نماذج، ويعيدون ضبطها، ويغيّرون سلوكها وفق جدولهم هم لا جدولكم.
الفرق التي تتجاوز هذه البوابة تكتشف ذلك بالطريقة نفسها كل مرة: شيء ظل يعمل أشهرًا يتراجع أداؤه خلال عطلة نهاية أسبوع، ولا توجد إعدادات سابقة يُرجع إليها لأن الإعدادات الحالية عُدّلت في مكانها. فتتحول العودة إلى استنتاج كل شيء من جديد.
تكونون قد اجتزتم هذه البوابة حين يكون التراجع عملية نشر، لا إعادة بناء.
البوابة 5: مسؤول محدد بالاسم يُحاسَب على المؤشر
شخص واحد. رقم واحد. ليس راعيًا للمشروع، ولا فريق عمل، ولا مورّدًا، بل فرد محدد بالاسم يتأثر عمله بتحرك هذا الرقم أو ثباته.
هذه أقل البوابات تقنية وأكثرها دلالة على النتيجة. اللجان تجيد الموافقة على مشاريع الذكاء الاصطناعي، وهي بحكم تكوينها عاجزة عن إطلاقها: المسؤولية الموزعة على ثمانية أشخاص لا يشعر بها أحد في الساعة 18:00 يوم الخميس حين يحتاج المشروع إلى دفعة أخيرة. نسمّي هذا النمط من الفشل ضريبة اللجنة التوجيهية، وهو أوثق مؤشر نراه على برنامج سيتعثر.
تكونون قد اجتزتم هذه البوابة حين تستطيعون ذكر اسم الشخص والرقم دون الرجوع إلى أي مستند.
لماذا يقع معظم الخلل في أول 90 يومًا؟
يُحسم الفشل عادةً قبل أن ينتبه له أحد بوقت طويل: خلال الربع الأول، في ثلاث خطوات تبدو كلها معقولة في حينها.
الشهر الأول: الاستراتيجية قائمة من حالات الاستخدام. تخرج ورشة عمل بخمسة عشر سير عمل مرشحًا مرتبة بحسب الحماس لها، فيُختار أكثرها إبهارًا بدل أسهلها تنفيذًا. لا أحد يسأل أيّ الخمسة عشر له اليوم تكلفة قابلة للقياس، فلا يبقى رقم يُحاسَب عليه أحد لاحقًا.
الشهر الثاني: لا أحد مسؤول عن المؤشر. للمشروع راعٍ ومورّد ولجنة توجيهية، وهذا ليس كوجود شخص واحد محدد بالاسم يتوقف عمله على تحرك رقم. اللجان تستطيع أن توافق على مشروع ذكاء اصطناعي، لكنها لا تستطيع أن تجعله ينجح. هذه هي ضريبة اللجنة التوجيهية، وهي أوثق ما ينبئ ببرنامج متعثر.
الشهر الثالث: ينجح العرض التجريبي فيعيد تعريف النجاح بهدوء. يعمل في المسار المثالي، ويُعجب به الحاضرون، ويتحول الهدف بصمت من «يعمل في بيئة الإنتاج» إلى «عُرض أمام الحاضرين». من هنا لا يفشل المشروع بقدر ما لا ينتهي أبدًا. ولهذا لا تُحدث 95% من النماذج التجريبية للذكاء الاصطناعي التوليدي في المؤسسات أثرًا قابلًا للقياس في الأرباح والخسائر (MIT Project NANDA, 2025)، وتتوقع Gartner إلغاء أكثر من 40% من مشاريع الذكاء الاصطناعي الوكيلي (agentic AI) قبل نهاية 2027 (Gartner, 2025).
العلاج لا بريق فيه: اختاروا سير عمل واحدًا يكلّف أحدًا مالًا اليوم، وضعوا اسمًا على المؤشر، وعرّفوا «الإنجاز» بأنه العمل دون إشراف في بيئة الإنتاج، لا عرضًا تجريبيًا أبهر الحاضرين. ولهذا تبدأ مشاريعنا بعمل بسعر ثابت هو AI Transformation Sprint ومدته أسبوعان، ينتهي بشيء يعمل فعلًا لا بعرض شرائح. وإذا كنتم في مرحلة أسبق من ذلك، فإن تقييم الجاهزية للذكاء الاصطناعي (بالإنجليزية) نظرة أولى أقل تكلفة.
عند أي بوابة أنتم عالقون؟
النماذج التجريبية المتعثرة تتشابه من الداخل، لكن العَرَض يشير غالبًا إلى بوابة واحدة مفقودة بعينها:
- «نعدّله مرة بعد مرة ولا نعرف هل يتحسّن.» البوابة 1: ليست لديكم مسطرة.
- «يعمل، إلا حين لا يعمل، ولا نستطيع إعادة إنتاج المشكلة.» البوابة 2: ليست لديكم سجلات تتبع.
- «أنهى فريق الهندسة عمله قبل أشهر، وما زال قيد المراجعة.» البوابة 3: لا أحد يستطيع تحديد أسوأ الاحتمالات.
- «كان يعمل ثم تغيّر شيء ما.» البوابة 4: لا توجد حالة سليمة معروفة تعودون إليها.
- «الجميع متفق على أهميته ولا شيء يتحرك.» البوابة 5: لا يوجد شخص واحد مسؤول عن الرقم.
هذا التشخيص أهم مما يبدو، لأن البوابات رخيصة بالترتيب أعلاه ومكلفة خارجه. إضافة التقييمات إلى نظام يعمل في الإنتاج تعني إعادة بناء النتائج المرجعية الصحيحة من حالات لم يسجّلها أحد. وإضافة قابلية المراقبة بعد وقوع خلل تعني التحقيق في شيء لا أثر له لديكم. تكاد كل عمليات الإنقاذ المكلفة لمشاريع الذكاء الاصطناعي التي نُستدعى إليها تكون فريقًا يدفع ثمن الإضافة المتأخرة لبوابة كانت ستكلّف أيامًا في البداية.
لا شيء من هذا غريب. هو الانضباط نفسه الذي حوّل عروض الويب التجريبية إلى برمجيات موثوقة قبل عقد، مطبَّقًا على تقنيات صادف أنها غير حتمية. الشركات العالقة في مرحلة التجريب لا ينقصها الطموح. تنقصها البوابات، وهذا بالضبط ما صُمّم مشروع Gigabit Agents لتركيبه. وإذا كان المتعثر تطبيقًا كاملًا بُني بأدوات الذكاء الاصطناعي لا وكيلًا واحدًا، فإن نقل النموذج الأولي إلى الإنتاج (بالإنجليزية) هو الانضباط نفسه مطبَّقًا على الشيفرة.
