موشيه سامبول، نائب رئيس حلول العملاء في لايتران – سلسلة المقابلات

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

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

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

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

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

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

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

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

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

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

هذا هو المكان الذي يصبح فيه التوجيه التحفيزي ضروريًا. يمكن أن يبقى التفكير الوكيل احتماليًا، ولكن النقاط التفتيش حول أفعالها لا يمكن أن تكون.对于 وكيل يشارك في تدفق هندسي، يتطلب ذلك خطوة تحقق تتحقق من الفرضية التالية المُفترَضة للوكيل ضد واقع الإنتاج، chứ không phải مجرد تخمين احتمالي آخر. يجب أن يرى ما ستكون نتيجة ذلك القرار، ويقره فقط بمجرد أن يحدد أن الإجراء آمن.

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

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

يشير ذلك إلى تحول أكثر جوهرية، وهو شيء نتحدث عنه باستمرار في لايتران أثناء مساعدة العملاء في بناء автоматиات وكلاء لمنظماتهم الهندسية. تحتاج الفرق إلى إعادة بناء تدفق الوكيل نفسه ووضع بوابات على أفعال الوكيل، لضمان أن استخدام الوكيل للأدوات خاضع للإشراف والتدقيق والمراجعة. تقديم حلقة تغذية راجعة قوية للوكيل – بما في ذلك رؤية وقت التشغيل الحية – يركز سياقه على ما يحدث الآن بالفعل. هذا الوصول هو ما يسمح للوكيل بتحقق قرارات التصميم الخاصة به وتحليل السبب الجذري وتوصيات التخفيف من الأخطاء ضد واقع الإنتاج بدلاً من ضد افتراضات dựa على تحليل ثابت للرمز أو تелеметري قديمة.

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

لماذا يؤدي بعض الوكلاء أداء جيدًا خلال الاختبارات المراقبة ولكن يبدأون في إنتاج نتائج غير متسقة أو غير كاملة أو خادعة عند التعرض للمستخدمين الحقيقيين، والبيانات المتغيرة، والأدوات الخارجية، والبيئات الإنتاجية المعقدة؟

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

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

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

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

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

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

هذا الفرق هو خاص الأهمية لتشخيص فشل الشفرة التي ينتجها الوكيل، لأن هذه غالبًا ما تكون صامتة. يمكن لوكيل أن يختار الأداة الخاطئة، أو يمرر الحجة الخاطئة، أو يتصرف على افتراض قديم، ولا يزال يكمل مهمته دون أن يُفعّل أي خطأ. فشل مثل هذا لن يظهر في تелеметري ثابتة، لأن لا أحد знаى مسبقًا أن يstrument عليه. السلوك غير المتوقع يتطلب تحقيقًا ديناميكيًا مباشرًا على النظام التشغيلي، بوضع أدوات جديدة بالضبط حيث انحرف نموذج الوكيل عن الواقع، بدلاً من الاعتماد على ما تم تسجيله بالفعل.

هذا هو ما يجعل سياق التشغيل الديناميكي طبقة التحقق الطبيعية للقرارات التي ينتجها الذكاء الاصطناعي في الهندسة.

كيف يمكن لبروتوكول سياق النموذج (MCP) وطبقات التكامل المماثلة أن تسمح لوكلاء الترميز بالتعلم من سلوك التنفيذ الحقيقي دون منحهم وصولًا زائدًا أو غير آمن إلى أنظمة الإنتاج؟

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

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

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

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

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

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

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

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

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

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

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

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