Шахар Азулай, генеральний директор і співзасновник groundcover

Шахар Азулай, генеральний директор і співзасновник groundcover – серійний лідер у сфері досліджень та розробок. Шахар має досвід роботи у сфері кібербезпеки та машинного навчання, працював у компаніях such as Apple, DayTwo, і Cymotive Technologies. Шахар багато років працював у відділі кібербезпеки офісу прем’єр-міністра Ізраїлю та має три ступені у сфері фізики, електротехніки та комп’ютерних наук у Technion Israel Institute of Technology та Тель-Авівському університеті. Шахар прагне використовувати технологічні знання з цього багатого досвіду та застосовувати їх до сучасної хмарної битви у найінноваційнішій формі, щоб зробити світ розробників кращим.

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

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

Спонука до заснування groundcover виникла під час моєї роботи у Apple та DayTwo. Навіть з великими бюджетами, ми були змушені вибирати між тим, щоб платити велику суму за реєстрацію всього або вибирати вибірково та літати сліпо. Тоді ми шукали технологію, яка б розв’язала цю проблему. Як тільки ми зустрілися з розширеною Berkeley Packet Filter (eBPF), стало зрозуміло, що це змінить все. eBPF дозволяє нам бачити все, що відбувається у ядрі, без залежності від змін у програмі. Я не міг зрозуміти, чому інструменти спостережливості не використовують цю технологію. Пробіл у спостережливості для AI став зрозумілим пізніше. Як тільки наша платформа Kubernetes дозріла, ми побачили, як клієнти поспішно впроваджують розгортання GenAI, одночасно вважаючи LLM за чорні скриньки. Вони знали, що модель реагує, але не знали, чому вона поводиться непередбачувано чи чому витрати стрімко зростають. Ми зрозуміли, що агентські робочі процеси просто складні, ненадійні мікросервіси, яким потрібна така ж бездоганна видимість, яку ми вже побудували.

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

Мій досвід у сфері кібербезпеки сформував ДНК компанії. У світі розвідки ви припускаєте, що не контролюєте програму. Такий підхід є причиною, чому groundcover не потребує інструментування. Я знаю з досвіду, що прохання розробників змінити код – це найшвидший спосіб блокувати прийняття. Найважчою першою трудністю при моніторингу LLM було питання приватності. Спостережливість для AI захоплює запити, які можуть містити чутливу особисту інформацію чи інтелектуальну власність. Мій досвід зробив очевидним, що підприємства не хочуть, щоб ці дані залишали їхнє середовище. Тому ми побудували свою архітектуру у хмарі, що дозволяє нам забезпечувати глибоку видимість поведінки агентів, зберігаючи всі дані всередині середовища клієнта.

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

Спостережливість LLM – це практика інструментування та моніторингу продукційних систем, які використовують великі мовні моделі, щоб захопити повний контекст кожного висновку: запит, контекст, завершення, використання токенів, затримку, помилки, метадані моделі та, ідеально, зворотний зв’язок чи сигнали якості. Замість того, щоб питати лише “Чи працює сервіс та чи швидкий?”, або “Чи вийшла ця запит помилка?”, спостережливість LLM допомагає відповісти на питання типу “Чому цей конкретний запит успішно пройшов чи провалився?”, “Що насправді відбулося всередині цього багатоступенного робочого процесу?” та “Як зміни у запитах, контексті чи версіях моделі впливають на витрати, затримку та якість виходу?” Це дуже відрізняється від традиційного моніторингу чи класичного моніторингу машинного навчання. Застарілі підходи налаштовані для детермінованих систем, інфраструктурних метрик та статичних порогів. Застосунки LLM є ненадійними, відкритими та високо залежними від контексту. Успіх часто є семантичним та суб’єктивним, а не просто кодом стану 200 чи 500. Це означає, що потрібно відстежувати входи та виходи, розуміти виклики інструментів та кроки відновлення, оцінювати відповіді на речі типу галюцинацій чи порушень політики, та з’єднувати витрати токенів та затримку з оточуючою програмою та інфраструктурою.

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

LLM-драйвені системи вводять кілька труднощів, які розкривають обмеження традиційних інструментів:

• Складні багатоступеневі робочі процеси – Ми перейшли від простих “виклик моделі, отримання відповіді” до багатотурних агентів, багатоступеневих конвеєрів, генерації з підтримкою відновлення та використання інструментів. Немає жодної відмови в будь-якому з цих кроків, наприклад під час відновлення, збагачення, вкладення, виклику інструменту чи виклику моделі, може зруйнувати весь досвід. Традиційний моніторинг зазвичай не надає повної, трасової видимості цих ланцюгів з включеними запитами та відповідями.
• Швидко еволюючі AI-стеки – Команди постійно додають нові моделі, інструменти та постачальників у темпі, якого вони ніколи не бачили раніше. У багатьох компаніях ніхто не може впевнено перелічити, які моделі зараз у виробництві. Класична спостережливість зазвичай припускає, що у вас є час для інструментування SDK, повторного розгортання та ретельного кураторства того, що ви вимірюєте. Це просто не справляється з тим, як швидко приймається AI.
• Токенна економіка та квоти – Ціни та ліміти швидкості пов’язані з токенами та довжиною контексту, які часто контролюються розробниками, запитами чи поведінкою користувача, а не центральними операціями. Традиційні інструменти не побудовані для показу “хто згорів скільки токенів на якій моделі, для якого робочого процесу, з якою затримкою”.
• Семантична коректність замість бінарного успіху – LLM може повернути 200 і все ж таки галюцинувати, відхилятися від вашого запиту чи порушувати політику. Традиційні інструменти бачать це як успіх. Вам потрібна спостережливість, яка може підняти запити та відповіді та надати достатній контекст для інспекції поведінки та, з часом, підключити автоматичні перевірки якості.
• Чутливі дані вводу, що течуть до третіх сторін – LLM запрошують користувачів поділитися дуже чутливою інформацією через інтерфейси типу чату та AI-підтримувані інтерфейси. Тепер ви відповідаєте за ці дані, де вони зберігаються та які постачальники бачать їх. Конвенційна SaaS-орієнтована спостережливість, яка відправляє всю телометрію до третього боку, часто є недопустимою для цих робочих навантажень.

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

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

Є кілька категорій сигналів, які мають велике значення на практиці:

Затримка та пропускна здатність

• Затримка від початку до кінця для кожного запиту, включаючи час моделі та час оточуючої програми.
• Хвостова затримка (P90, P95, P99) для кожної моделі та робочого процесу.
• Пропускна здатність за моделлю, маршрутом та сервісом, щоб ви знали, де дійсно йде навантаження.

Витрати токенів та драйвери витрат

• Вхідні та вихідні токени за запит, розбиті за моделлю.
• Агреговане використання токенів за часом за моделлю, командою, користувачем та робочим процесом.
• Розміри контексту для конвеєрів із відновленням, щоб ви могли побачити, коли запити вибухають.
• Це дозволяє вам відповісти на питання “Хто дійсно витрачає наш бюджет AI та на що?”

Поведінка запиту та відповіді

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

Надійність та помилки

• Специфічні для моделі ставки помилок та типи (помилки постачальника, часові помилки, проблеми з автентифікацією, помилки квот).
• Помилки у оточуючому робочому процесі, наприклад часові помилки інструментів чи помилки відновлення, корельовані з викликом LLM.

Класичний контекст інфраструктури

• Метрики CPU, пам’яті та мережі контейнерів для сервісів, які оркеструють ваші виклики LLM.
• Корельовані журнали, які описують, що програма намагалася зробити.

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

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

Тихі відмови в системах LLM зазвичай відбуваються, коли все виглядає “зеленим” на рівні інфраструктури, але фактична поведінка дрейфує. Спостережливість допомагає кількома способами:

• Трасування повного робочого процесу, а не лише виклику моделі – Захопивши весь шлях запиту від клієнта до сервісу до відновлення до моделі до інструментів, ви можете побачити, де змінилася поведінка. Наприклад, можливо відновлення почало повертати менше документів, або виклик інструменту періодично виконується, а модель імпровізує.
• Збереження запитів, контексту та відповідей у полі зору – Коли ви можете інспектувати запити та відповіді поряд з трасами, стає набагато легше помітити випадки, коли нова версія запиту, нова система інструкцій чи нове джерело контексту змінили поведінку, навіть якщо затримка та ставка помилок залишилися такими ж.
• Фільтрація та нарізка на семантичних умовах – Як тільки у вас є багата телометрія LLM, ви можете фільтрувати вниз до речей типу “виклики bedrock понад одну секунду”, “запити, що використовують цю сім’ю моделей”, або “траси, що включають цей конкретний маршрут”, потім читайте запити та відповіді, щоб побачити, чи дрейфує чи галюцинує модель у конкретному сценарії.
• Сповіщення про рівні обслуговування бізнесу – Ви можете визначити рівні обслуговування типу “будь-який виклик LLM понад одну секунду порушує нашу користувацьку угоду про рівень обслуговування” та сповіщати, коли ці умови виконуються. З часом подібні рівні обслуговування можуть бути пов’язані з метриками якості чи перевірками політики, щоб сповіщати, коли якість погіршується, а не лише коли інфраструктура виходить з ладу.

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

Як підхід groundcover підтримує діагностику непередбачуваної затримки чи несподіваної поведінки у багатоступеневих агентських робочих процесах та викликах інструментів?

groundcover застосовує підхід, розроблений для сучасних систем AI. Ми використовуємо сенсор на рівні ядра на основі eBPF для спостереження за трафіком через мікросервіси без змін у коді чи повторного розгортання. Як тільки ви вводите робочий процес LLM, ми можемо автоматично виявити ці виклики. Якщо ви починаєте використовувати нову модель, наприклад Anthropic, OpenAI чи Bedrock, завтра, groundcover захоплює цей трафік автоматично. Це дає вам:

• Траси багатоступеневих робочих процесів – Ви бачите повний шлях запиту через сервіси, включаючи використання LLM чи інструменту.
• Глибокий контекст кожного виклику LLM – Кожен виклик включає використану модель, затримку, використання токенів, запити, відповіді та корельовані журнали та метрики інфраструктури.
• Потужна фільтрація на затримку та умови – Наприклад, ви можете фільтрувати всі виклики Claude 3.5, які тривають понад одну секунду, та негайно інспектувати траси, які порушують вашу угоду про рівень обслуговування.
• Сповіщення та панелі керування, пов’язані з поведінкою LLM – Як тільки дані стають доступними, ви можете створювати сповіщення про порушення угод про рівень обслуговування чи будувати панелі керування, які відстежують затримку, пропускну здатність, використання токенів та помилки.

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

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

Розгортання LLM вводять деякі унікальні ризики даних:

• Необмежений вхід користувача – Користувачі можуть вводити дуже чутливу інформацію у чат-інтерфейси та AI-підтримувані інтерфейси. Це може включати особисту інформацію, дані клієнтів чи регульовану інформацію, яку ви ніколи не мали наміру зібрати.
• Постачальники моделей третіх сторін – Як тільки ви надсилаєте ці дані зовнішньому постачальнику LLM, ви відповідаєте за те, куди вони пішли, як вони зберігаються та які субпостачальники залучені. Це має великі наслідки для GDPR, резиденції даних та довіри клієнтів.
• Телеметрія як друга копія чутливих даних – Якщо ваш стек спостережливості відправляє повні вантажі до постачальника SaaS, у вас тепер є друга копія цієї чутливої інформації, яка знаходиться поза вашим середовищем.

Архітектура groundcover розроблена для вирішення саме цих проблем:

• Ми використовуємо модель “приносіть свій хмарний” де повний бекенд спостережливості працює всередині вашого хмарного облікового запису, у підобліковому обліковому записі, як повністю керований план даних. План контролю, який масштабує та керує ним, працює нами, але ми не отримуємо доступу, не зберігаємо та не обробляємо ваші дані телеметрії.
• Оскільки ми можемо безпечно захопити вантажі у вашому власному середовищі, ви можете спостерігати запити, відповіді та робочі процеси без того, щоб ці дані коли-небудь залишали ваш хмарний обліковий запис. Тут немає зовнішнього зберігання ваших трас LLM та жодного додаткового виходу даних, про який потрібно турбуватися.
• З цією видимістю ви можете побачити, хто завантажує що та куди це тече, виявити несподіване використання чутливих даних та примусити дотримуватися політики щодо того, які моделі та регіони дозволені.

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

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

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

• Розсіювання моделей та постачальників – Команди постійно додають нові моделі. Це швидко стає неясним, які моделі зараз у виробництві.
• Витрати-сюрпризи від використання токенів – Витрати токенів зростають з довжиною контексту та складністю робочого процесу. Без видимості використання токенів за моделлю та робочим процесом керування витратами дуже складно.
• Надійність, залежна від зовнішніх постачальників – Користувацькі API стають чутливими до затримки моделі чи помилок, які можуть порушувати угоди про рівень обслуговування, навіть якщо основна інфраструктура здорові.
• Ростучий борг інструментування – Традиційна спостережливість припускає, що ви можете додати інструментування, коли це потрібно. У швидкозмінних стеках AI розробники рідко мають час для цього.

groundcover вирішує ці проблеми, надаючи вам:

• Центральну видимість того, які моделі та постачальники використовуються.
• Панелі керування, які показують затримку, пропускну здатність та використання токенів за часом.
• Кореляцію між поведінкою LLM та сервісами, які залежать від неї
• Сповіщення про порушення угод про рівень обслуговування, керованих AI.

Це робить набагато легше масштабування від “одної крутої функції AI” до “AI вплетена у десятки критичних сервісів” без втрати контролю.

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

Ми все ще на ранній стадії. За наступні п’ять років я очікую кілька великих зрушень:

• Від рівня запиту до рівня агента – Спостережливість розшириться для захоплення послідовностей інструментів, шляхів висновку та логіки повторних спроб, а не лише викликів моделей.
• Багатші семантичні та політичні сигнали – Автоматичні перевірки якості для галюцинацій, проблем безпеки чи порушень політики стануть стандартними метриками.
• Тісніше зв’язування з управлінням та приватністю – Як тільки регулювання зростає, спостережливість також послужить шаром примусу та аудиту для резиденції даних, зберігання та затвердженого використання моделей.
• Оптимізація між моделями та постачальниками – Команди будуть маршрутизувати трафік через моделі динамічно на основі продуктивності та витрат, керованих даними спостережливості у реальному часі.
• Менше ручного інструментування – Техніки типу збору на основі eBPF та автовиявлення стануть стандартними, щоб команди могли інновувати без сповільнення.

Іншими словами, спостережливість LLM буде розвиватися від “гарних панелей для AI” до центральної нервової системи, яка з’єднує надійність, контроль витрат, управління даними та якість продукції через все, що організація робить з AI.

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