لماذا تتوقف مشاريع الذكاء الاصطناعي العامل عند النطاق، وماذا يجب على الشركات إصلاحه أولاً

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

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

في几乎 كل حالة، الجواب ليس هو نفسه النموذج، ولكن حالة البيانات، وطبقة التنسيق، وإطار الحوكمة، والبنية التحتية التقليدية التي لم تتخذ معظم الشركات إجراءات لتحديثها قبل بناء وكلاء ذكاء اصطناعي عليها. حتى يتم解决 تلك الأسس، سيستمر الذكاء الاصطناعي العامل في إنتاج عروض تثير الإعجاب وتنفيذ يخيب الآمال.

بيئة اختبار Concept هي فخ

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

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

وفقًا لتقرير حالة الذكاء الاصطناعي 2025 من شركة ماكينزي، تستخدم 88% من المنظمات الذكاء الاصطناعي في واحد على الأقل من وظائف الأعمال، ومع ذلك،只有 حوالي ثلثهم نجحوا في توسيع نطاقه عبر الشركة. الفجوة بين الاستخدام والتوسيع تبدأ من كيفية قيام الشركات بتحديد نطاق وتقييم تجاربهم. الفرق الذي يوسع بنجاح يعامل تحليل وضع الفشل كمتطلب تصميم. قبل التنفيذ، يبني كتالوجًا لطريقة عمل الوكيل المتوقع أن يفشل وما هو الاستجابة عندما يفعل. يبدو هذا واضحًا. قليل من الشركات تفعل ذلك.

بيانات غير صالحة، وكلاء غير صالحون

تستمر الشركات في السؤال عن سبب عدم أداء وكلائهم بشكل جيد في الإنتاج. الجواب يعود تقريبًا دائمًا إلى البيانات. لم تكن حالة البيانات جاهزة. كانت المصادر متفرقة عبر عشرات الأنظمة التي بنيت في أوقات مختلفة لأغراض مختلفة. كانت التعريفات غير متسقة عبر وحدات الأعمال. لم يكن هناك طبقة семантиكية. لم يكن هناك مصدر وحيد للtruth. كان هناك فقط سنوات من الديون البيانية التي لم يُriorize أي شخص لأن الأنظمة القديمة كانت تعمل جيدًا.

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

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

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

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

ميزة منصة البيانات الموحدة

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

هذا هو السبب في أن منصات البيانات التي تختارها الشركات تهم بشكل كبير لنتائج الذكاء الاصطناعي العامل. يأتي نهج Microsoft Fabric الموحد معًا Lakehouse وبيت البيانات والنموذج الدلالي والأنابيب في بيئة واحدة، مما يعطي الشركات التي تركز على Microsoft (MSFT ) ميزة هيكلية عند الانتقال من التجارب إلى الاستخدام التشغيلي الحقيقي.

تقدم Databricks نفس المبدأ من خلال هندسة Lakehouse وUnity Catalog، مما يعطي فرق البيانات والذكاء الاصطناعي طبقة حوكمة موحدة عبر البيانات المهيكلة وغير المهيكلة مع دمج MLflow لتتبع سلوك النموذج في الإنتاج. يعتمد نهج Snowflake على Cortex AI وربطه الوثيق بين سحابة البيانات والاستدلال الذكاء الاصطناعي، مما يسمح للشركات بتشغيل حمولات عمل الوكيل مباشرة ضد بيانات حية خاضعة للإدارة دون التأخير ومخاطر الاتساق التي تأتي من نقل البيانات بين الأنظمة.

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

الحوكمة قبل، وليس بعد

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

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

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

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

من التجربة إلى الإنتاج: ما يحتاجه الأمر بشكل فعلي

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

بحث ديلوايت حول الذكاء الاصطناعي في الشركات يظهر أن وصول العمال إلى الذكاء الاصطناعي قفز بنسبة 50% في عام 2025 وحده، وسيزداد عدد الشركات التي تدير أكثر من 40% من مشاريع الذكاء الاصطناعي في الإنتاج الكامل بمضاعفة في الستة أشهر القادمة. الشركات التي تفوز الآن ليست تلك التي تملك النماذج الأكثر تقدمًا. بل هي تلك التي بنت البنية التحتية التشغيلية لتشغيل الذكاء الاصطناعي بشكل موثوق به، وفعلت ذلك قبل بناء الوكلاء.

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

حتى يتغير ذلك، ستموت العديد من مشاريع الذكاء الاصطناعي العامل التي ألقت الشركات الموارد فيها، وآملت أن تثمر، على الكرم.