جيف شامباني، رئيس قسم التكنولوجيا في شركة Cribl – سلسلة المقابلات

جيف شامباني، رئيس قسم التكنولوجيا في شركة Cribl، يمتلك خبرة عميقة في مجالات المراقبة والبيانات المؤسسية واستراتيجية المنتج والهندسة المعمارية. قبل انضمامه إلى شركة Cribl، شغل منصب مدير إدارة المنتج في شركة Databricks وقضى أكثر من سبع سنوات في شركة Splunk في مناصب هندسية ميدانية وتصميمية وهندسية أنظمة عالمية. وتشمل خلفيته أيضًا قيادة الهندسة الأنظمة في شركة BNY ConvergEx، والعمل الهندسي في شركة Premier Technology Solutions، والقيادة الهندسية المبكرة في شركة Assist-2-Sell، مما يمنحه منظورًا واسعًا حول كيفية جمع الشركات وتنظيم وتحليل البيانات التشغيلية على نطاق واسع.

Cribl هي شركة تكنولوجيا مراقبة المؤسسات تركز على مساعدة فرق تكنولوجيا المعلومات والأمن والهندسة والعمليات على جمع ومراقبة وتخزين وتنقيب البيانات المراقبة والأمن دون الحاجة إلى تكنولوجيا معينة. وتعرف الشركة نفسها بأنها “منصة الذكاء الاصطناعي للمراقبة”، مع منتجات مثل Cribl Stream لمراقبة التكنولوجيا في الوقت الفعلي، وCribl Edge لمراقبة النقاط النهاية، وCribl Search للبحث في البيانات، وCribl Lake لتخزين البيانات. وتهدف المهمة الأوسع إلى منح الشركات مزيدًا من السيطرة والمرونة والكفاءة مع نمو حجم البيانات وتطلب العمليات التي تعتمد على الذكاء الاصطناعي بيانات أكثر نظافة وسهولة الوصول.

لقد عملت في شركات Splunk وDatabricks وCribl، مما يعطيك نظرة نادرة على البيانات المؤسسية والمراقبة والبنية التحتية عبر دورات تكنولوجية متعددة. من هذه النظرة، ما الذي يبدو مختلفًا حقًا حول تحدي المراقبة الذي tạoه الذكاء الاصطناعي العامل؟

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

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

عندما تدمج الشركات وكلاء مستقلين في سير العمل، أين تكون أكبر الفجوات في الرؤية بين ما يُطلب من وكيل القيام به وما يحدث في الواقع عبر الأنظمة الأساسية؟

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

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

قام الوكيل بالضبط بما تم طلبه؛ كانت البيانات التي وثق بها فقط قديمة.

لماذا تكون أدوات المراقبة التقليدية غالبًا غير كافية لمراقبة أنظمة الذكاء الاصطناعي العامل؟

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

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

عندما يفشل وكيل الذكاء الاصطناعي، كيف يمكن للمنظمات تحديد ما إذا كان السبب الجذري هو النموذج أو طبقة الاسترجاع أو اعتماد_API أو مشكلة في الأذونات أو مشكلة في البنية التحتية؟

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

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

ما هي أنواع بيانات المراقبة التي تصبح أكثر أهمية عندما تحاول المنظمات فهم سلوك الوكيل على نطاق واسع؟

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

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

لا تختفي إشارات MELT الأخرى؛ تظل المقاييس على استخدام الرموز والكفاءة مهمة للتكلفة والأداء، وتظل السجلات من الأنظمة الأساسية أساسية. ولكن التتبع هو ما يجعل سلوك الوكيل مفهومًا على نطاق واسع.

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

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

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

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

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

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

ما الدور الذي يمكن أن تلعبه أنابيب المراقبة في مساعدة فرق الأمن والهندسة والبيانات والذكاء الاصطناعي على العمل من منظور مشترك لسلوك الوكيل؟

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

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

ما هي الأخطاء التي ترى الشركات تقوم بها عند محاولة تطبيق ممارسات المراقبة الحالية على تكنولوجيا الذكاء الاصطناعي العامل؟

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

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

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

في المستقبل، هل ستصبح رؤية البنية التحتية شرطًا مسبقًا لتبني الذكاء الاصطناعي للمؤسسات بنفس الطريقة التي أصبحت فيها المراقبة السحابية ضرورية للهجرة السحابية على نطاق واسع؟

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

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

شكرًا على المقابلة الرائعة، يُرجى من القراء الذين يرغبون في التعلم المزيد زيارة Cribl.