Моше Самбол, віце-президент з питань рішень для клієнтів у Lightrun – Інтерв’ю серія

Моше Самбол, віце-президент з питань рішень для клієнтів у Lightrun – має понад два десятиліття досвіду у сфері розробки програмного забезпечення, архітектури, інфраструктури хмарних обчислень та технічного лідерства. До того, як приєднатися до Lightrun у 2022 році, він провів майже десятиліття в Google, де займав різні керівні посади, включаючи посаду менеджера з питань інженерії клієнтів, допомагаючи організаціям впроваджувати та масштабувати технології Google Cloud. Раніше в своїй кар’єрі Самбол займав інженерні та керівні посади у компанії Oracle, Sun Microsystems, BMC Software та JPMorgan Chase. У Lightrun він спочатку керував глобальною інженерією рішень, а потім став віце-президентом з питань рішень для клієнтів, де він зосереджується на допомозі клієнтам у впровадженні технології Runtime Insights компанії та переводі її можливостей у вимірювані бізнесові та продуктивні вигоди для розробників.

Lightrun – це платформа інженерної надійності, заснована на штучному інтелекті, розроблена для надання розробникам та агентам штучного інтелекту прямого доступу до інформації про те, як програмне забезпечення поводиться під час виконання. Її технологія може динамічно захоплювати журнали, знімки, метрики, траси, значення змінних та контекст виконання з живих застосунків без потреби у змінах коду або повторному розгортанні. Компанія все більше розширює цю інформацію про час виконання до розробки програмного забезпечення з допомогою штучного інтелекту через Lightrun MCP, який використовує Протокол контексту моделі для надання кодувальним асистентам та інструментам агентів живого контексту застосування замість сприйняття лише статичного вихідного коду. Це дозволяє системам штучного інтелекту розслідувати проблеми у виробництві, перевірити гіпотези проти фактичної поведінки виконання та підтримувати аналіз кореневих причин, одночасно впроваджуючи корпоративні засоби контролю, такі як рольовий доступ та редагування чутливих даних.

Ваша кар’єра охоплює практичну розробку програмного забезпечення та архітектуру, інженерію клієнтів у Google, глобальну інженерію рішень та зараз рішення для клієнтів у Lightrun. Як це поєднання будівництва програмного забезпечення та безпосередньої роботи з клієнтами підприємства сформувало ваше розуміння того, що відрізняє вражаючу демонстрацію агента штучного інтелекту від системи, якій можна довіряти у виробництві?

Є велика різниця між демонстрацією того, що може зробити агент штучного інтелекту, та доведенням того, що його можна довіряти в середовищі підприємства. Це відбувається тому, що агенти є лише однією частиною системи, готової до виробництва. Фреймворк навколо нього є рівноцінним. Він повинен забезпечувати доступ з мінімальними привілеями, моніторинг діяльності, збереження аудитної траси, запобігання неприпустимо ризикованим діям та залучення людини, коли це необхідно.

Системи агентів мають суттєві відмінності від традиційного програмного забезпечення, оскільки розробники не вказують точно, як система буде працювати. Ми встановлюємо мету, надаємо інструменти та керівництво, а модель визначає, як продовжити. Ця гнучкість є потужною, але вона також робить поведінку системи важче передбачити.

Для підприємств, особливо тих, що діють у регульованих галузях, робочі процеси виробництва, які зазвичай працюють або займають непередбачувану кількість часу для завершення, є недопустимими. Виробничі середовища містять чутливі дані, вихідний код та інтелектуальну власність, тому організації повинні бути здатні запобігти агентам розкривати цю інформацію або приймати творчі, але неприпустимі шляхи для досягнення своїх цілей. Це стає дедалі важливішим, оскільки кожен тиждень приносить новий приклад системи штучного інтелекту, яка, у своїй спробі досягти мети, виявляється вразливою до або спричиняє експлойт безпеки.

Більшість лідерів, з якими я розмовляю, все ще оцінюють агентів так само, як нового співробітника: за можливостями, судженням та виходами. Реальне питання полягає не в тому, чи достатньо розумний агент. А у тому, чи система навколо нього може впіймати та стримувати моменти, коли він не є таким.

Багато підприємств спочатку вважали, що будівництво агента штучного інтелекту в основному полягало у написанні ефективного запиту. Що організації недооцінили щодо інженерних, архітектурних та операційних вимог до агентів, готових до виробництва?

Я думаю, що найбільше недооцінення було майже наївною вірою у силу штучного інтелекту для вирішення будь-якого виклику, якщо тільки йому надати добре написаний запит, актуальний контекст та відповідні інструменти. Команди підключили свій LLM до коду, документації, квитків та історичної телеметрії, а потім очікували, що він виведе правильне рішення.

Що вони не побудували, так це модель верифікації для кожного кроку висновку штучного інтелекту. Однією з великих сильних сторін штучного інтелекту є те, що він використовує ймовірнісне висновування, знаходить і приймає один із багатьох можливих шляхів для досягнення мети. У складних, взаємопов’язаних виробничих середовищах ця сила вводить серйозний ризик: одне рішення може спровокувати подальші регресії, тихі відмови або іншу непередбачувану поведінку, яка загрожує оперативній стійкості системи.

Це місце, де детерміністичне керування стає життєво важливим. Висновування агента може залишатися ймовірнісним, але контрольні точки навколо його дій не можуть бути такими. Для агента, який бере участь у інженерному робочому процесі, це вимагає кроку верифікації, який перевіряє його гіпотезу про наступну дію проти реальності виробництва, детерміністичної брами, а не ще однієї ймовірнісної здогадки. Йому потрібно побачити, яку буде наслідком цього рішення, та схвалити його лише після того, як він визначить, що дія безпечна.

Оглянувшись на першу хвилю внутрішньо розроблених агентів підприємства, які архітектурні помилки ви бачите найчастіше, та які проблеми можна виправити інкрементально, а не вимагають повної перебудови?

Основна проблема, до якої я постійно повертаюсь, полягає у верифікації. Агенти можуть стати чорними скриньками: вони збирають інформацію з різних джерел, а потім приймають рішення, які здаються розумними у принципі, але можуть бути неадекватними для реальності складного виробничого середовища.

Це вказує на більш фундаментальну зміну, і це щось, про що ми постійно говоримо в Lightrun, коли допомагаємо клієнтам будувати агентські автоматизації для своїх інженерних організацій. Команди потрібно перебудувати сам агентський потік та поставити ворота на дії агента, щоб забезпечити, щоб його використання інструментів було підконтрольним, аудитом та переглядом. Надання агенту сильного зворотного зв’язку – включаючи живу спостережливість часу виконання – фокусує його контекст на тому, що зараз відбувається. Цей доступ дозволяє агенту верифікувати свої власні рішення про проектування, аналіз кореневих причин та рекомендації щодо пом’якшення помилок проти реальності виробництва, а не проти припущень, заснованих на статичному аналізі коду чи старої телеметрії.

Драматична перебудова не єдина опція. Що можна зробити інкрементально, і це не революційне, але це життєво важливо, інвестувати в навички, які керують поведінкою агента. Старанно створені та оцінені навички штовхають агента у напрямку детерміністичного робочого процесу. Команди не потрібно перебудовувати всю систему, щоб отримати цю вигоду. Вони повинні ставити до проекту навички з такою ж суворістю, яку вони дали б будь-якій іншій частині логіки виробництва.

Чому деякі агенти працюють добре під час контрольованих тестів, але починають виробляти несумісні, неповні або вводять в оману результати, коли їх піддають дії реальних користувачів, змінних даних, зовнішніх інструментів та складних виробничих середовищ?

Контрольовані тести усувають більшу частину варіативності, яка визначатиме реальність виробництва, з якою штучний інтелект повинен зіткнутися. Дані відібрані, поведінка інструментів передбачувана, дозволи відомі, а ми покриваємо шлях, який ми передбачили. Коли ви випускаєте агента на взаємодію з реальними користувачами та їхніми ефектами у живих системах, ви не порівнюєте подібне з подібним.

Користувачі вводять двозначні запити та виконують паралельні дії, стан системи постійно змінюється, агент часто повинен працювати з частковими даними, а зовнішні інструменти вводять自己的 затримку та режими відмов на додаток до цього. Через те, що модель є ймовірнісною, кожна нова змінна створює ще одне місце, де робочий процес може розходитися або посилювати попередню помилку.

Небезпечна частина полягає в тому, що агент може продовжувати здаватися працездатним, одночасно генеруючи неправильні, але правдоподібні відповіді, побудовані на часткових даних чи припущеннях, заснованих на застарілій інформації. Це саме той випадок, коли агентам виробництва потрібна постійна оцінка, яка продовжує виконуватися після запуску, явне оброблення відсутніх даних та відмов інструментів, а також живе верифікація рішення перед тим, як завершити дію високого впливу.

Lightrun надає велике значення наданню системам штучного інтелекту доступу до контексту часу виконання. Яка інформація надається контекстом часу виконання, яку можуть не надавати традиційні журнали, метрики та траси, і чому ця інформація особливо важлива для діагностики відмов агентів?

Традиційна спостережливість показує зовнішні симптоми поведінки системи, часто агреговані, вибіркові або фільтровані через панелі управління та сповіщення, які спрацьовують на порогах. Вони зазвичай залежать від рішень, прийнятих розробниками на момент написання коду: яка інформація буде цікавою в майбутньому? Що варто реєструвати або вимірювати? Контекст часу виконання відключує видимість від цієї потреби знати заздалегідь, що може бути цікавим, і надає детальні дані, що показують, що відбувається під капотом, і як ми до цього прийшли.

Фактичний розрив полягає у статичних та динамічних даних. Традиційні журнали, метрики та траси є статичними та створюють історичний звіт про те, що відбулося. Контекст часу виконання Lightrun є динамічним. Він надає агенту можливість розмістити нову інструментальність у виконуваному коді на вимогу та спостерігати точні значення змінних, аргументи функцій, стан об’єкта, стек викликів або умови гілок, оскільки вони відбуваються.

Ця відмінність особливо важлива для діагностики відмов у коді, згенерованому агентом, оскільки ці відмови часто є безшумними. Агент може вибрати неправильний інструмент, передати неправильний аргумент або діяти на застарілому припущенні, і все ж завершити свою задачу без спрацьовування жодної помилки. Така помилка не буде показана у статичній телеметрії, оскільки ніхто заздалегідь не знав, для чого інструментувати. Непередбачувана поведінка вимагає динамічного розслідування безпосередньо на живій системі, розміщення нової інструментальності саме там, де модель світу агента розійшлася з реальністю, а не спираючись на те, що вже записувалося.

Це саме те, що робить динамічний контекст часу виконання природним верифікаційним шаром для рішень, згенерованих штучним інтелектом, у сфері інженерії.

Як Протокол контексту моделі (MCP) та подібні шари інтеграції можуть дозволити агентам кодування вивчати реальну поведінку виконання без надання їм надмірного або небезпечного доступу до виробничих систем?

MCP та інші контрольовані засоби доступу до зовнішніх інструментів (наприклад, обгортки CLI) дозволяють агенту викликати конкретну, обмежену можливість, а не отримувати широкий доступ до системи та довіру до його поведінки. Агент, підключений через сервер MCP для контексту часу виконання, може запросити тільки для читання докази, значення змінної, шлях виклику, чи був перевищений поріг, без доступу для запису, без можливості повторного розгортання чогось та без потреби постійних повноважень до основної середовища.

Коли ви перебудовуєте агента першого покоління, як підприємства повинні підходити до дозволів інструментів, пам’яті, витягування даних, оцінки, нагляду людини та процедур відступу як частини однієї цілісної архітектури, а не окремих функцій?

Ви не можете прикріпити ці частини незалежно, оскільки кожна з них змінює інші. Найкращі місця для початку – це фреймворк, упряжка, яка контролює цикл агента, та загальна оркестрація робочого процесу, яка поєднує кілька агентів та інших акторів. Наприклад, для робочого процесу аналізу кореневих причин команди повинні визначити, яке докази потрібні, які системи агент може інспектувати, чи може він опублікувати висновок чи тільки нарисати його, коли людина повинна схвалити наступний крок, та що відбувається, якщо докази часу виконання недоступні.

Як тільки цей контракт стає ясним, упряжка та фреймворк забезпечують механізми, за допомогою яких можна забезпечити ці рекомендації. Брами MCP можна використати для обмеження доступу агента до конкретних можливостей, що відповідають його меті. Інструменти можна надати з мінімальними привілеями. Пам’ять можна наглядати, з чутливими даними, які вилучаються детерміністично. Витягування можна спроектувати навколо доказів, необхідних для робочого процесу.

Оцінка, нагляд та процедури відступу потім закривають цикл. Система повинна вимірювати, чи висновки правильні та підтримуються, залучати людину, коли ризик або невизначеність перетинають певний поріг, та зупинятися або відступати до рекомендації тільки для читання, коли вона не може зібрати достатньо доказів. Спільний аудитний запис повинен зв’язувати спрацьовування, дозволи, докази, виклики інструментів, схвалення, дії та результат. Це саме те, що робить ці компоненти однією виробничою архітектурою, а не шістьма окремими функціями.

Які заходи безпеки повинні оточувати агентів, які можуть інспектувати живі застосування або брати участь у роботі інженерів з забезпечення сайту, особливо у регульованих середовищах, де контроль доступу, конфіденційність, аудитованість та оперативна стабільність є критичними?

Це було одним із центральних питань дизайну, коли ми будували Lightrun AI SRE. SRE штучного інтелекту працює близько до деяких з найбільш чутливих систем організації, тому ми спроектували його як привілейованого оперативного актора, а не чат-асистента. Одним із важливих рішень було розділення площі інспекції від площі дії. SRE штучного інтелекту збирає докази через тільки для читання інтеграції та інструментальності часу виконання Lightrun, із доступом, обмеженим ідентифікатором, орендарем, службою та середовищем. Він може інспектувати живе виконання та генерувати відсутні докази, але шар інспекції часу виконання не може змінити стан застосування.

У регульованому середовищі ця межа повинна бути підтримана рольовим доступом, єдиною системою входу, ізоляцією орендаря, редагуванням особистих даних, контролем збереження та аудитною трасою, яка показує, які інструменти та докази підтримували кожен висновок. Нам також потрібні оперативні обмеження щодо того, скільки даних можна зібрати, як часто можна запитувати час виконання, та які дії потребують схвалення. Якщо докази відсутні або висновок не може бути верифікований, SRE штучного інтелекту повинен сказати про це та передати рішення людині, а не діяти так, як ніби він знає більше, ніж насправді.

Як підприємства рухаються далі від експериментальних агентів, які міркування повинні визначати, чи агент дійсно готовий до виробництва, та як ви очікуєте, що відношення між агентами штучного інтелекту та людьми-інженерами буде розвиватися протягом наступних кількох років?

Я би судив про готовність до виробництва за тим, як часто дії агента штучного інтелекту дають бажані результати, його висновки витримують проти того, що було насправді у виробництві, висновки, які не підтримуються, спіймані до дії, та чи агент відмовляється видимо та безпечно, коли докази відсутні. Для агентів інженерії нам слід зосередитися на метриках точності результату, покриття доказів, часу для підтвердження кореневої причини, успішної швидкості відступу та результатів після дії.

За наступні кілька років я очікую, що агенти будуть брати на себе більше збору доказів та першої інспекції, а також нагляду за агентськими робочими процесами та постійного навчання з досвіду та зворотного зв’язку, тоді як інженери встановлюють політику, розв’язують неоднозначність, схвалюють дії високого ризику та керують самозберігаючими агентськими системами. Довіра буде розширюватися робочим процесом за робочим процесом. Агенти, які можуть простежити свої висновки до живих доказів та чітко розкрити те, чого вони не могли верифікувати, заслужать більшу автономію. Ті, які не можуть, залишаться обмеженими вузькими, низькоризикованими завданнями, незалежно від того, наскільки вони звучать плавно.

Дякую за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Lightrun.