Джефф Шампань, Філд CTO в Cribl – Серія інтерв’ю

Джефф Шампань, Філд CTO в Cribl, має глибокий досвід у сфері спостережуваності, корпоративних даних, стратегії продукту та технічної архітектури. До того, як він приєднався до Cribl, він обіймав посаду директора з управління продуктом у Databricks і понад сім років працював у Splunk на керівних посадах у сфері продукту, архітектури та глобальної інженерії систем. Його досвід також включає керівництво архітектурою систем у BNY ConvergEx, інженерну роботу у Premier Technology Solutions та керівництво інженерами у Assist-2-Sell, що дає йому широкий погляд на те, як підприємства збирають, керують, аналізують та діють на операційні дані у великому масштабі.

Cribl – це корпоративна компанія з телебачення, що спеціалізується на допомозі командам IT, безпеки, SRE та DevOps у зборі, обробці, маршрутизації, збереженні та аналізі даних спостережуваності та безпеки без блокування в одному постачальнику. Компанія позиціонує себе як “Платформа штучного інтелекту для телебачення”, з продуктами такими як Cribl Stream для збору, зменшення, збагачення та маршрутизації телебачення в реальному часі; Cribl Edge для збору телебачення з кінцевих точок без залежності від постачальника; Cribl Search для пошуку даних на місці; та Cribl Lake для зберігання. Її ширша мета – дати підприємствам більше контролю, гнучкості та ефективності при зростанні обсягів телебачення та вимог штучного інтелекту до чистіших та більш доступних даних.

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

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

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

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

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

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

Агент зробив саме те, що йому було сказано; дані, яким він довіряв, просто застаріли.

Чому традиційні інструменти спостережуваності часто недостатні для моніторингу агентних штучних інтелектних систем?

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

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

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

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

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

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

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

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

Інші сигнали MELT не зникають; метрики використання токенів та затримки мають значення для витрат та продуктивності, а журнали з нижніх систем залишаються важливими. Але траси – це те, що робить поведінку агентів зрозумілою у великому масштабі.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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