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

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

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

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

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

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

Мій досвід у кібербезпеці сформував ДНК компанії. У світі розвідки ви вважаєте, що не контролюєте додаток. Саме через такий підхід Groundcover не потребує інструментарію. З досвіду я знаю, що найшвидший спосіб блокувати впровадження — це звернутися до розробників з проханням змінити код. Найскладнішим раннім викликом у моніторингу LLM була конфіденційність. Спостереження для ШІ дозволяє фіксувати запити, які можуть містити конфіденційну особисту інформацію або IP-адресу. Мій досвід чітко показав, що підприємства не хочуть, щоб ці дані залишали їхнє середовище. Саме тому ми створили нашу хмарну архітектуру, яка дозволяє нам забезпечити глибоку видимість поведінки агентів, зберігаючи всі дані у власному середовищі клієнта.

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

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

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

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

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

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

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

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

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

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

Використання токенів та фактори, що впливають на вартість

• Вхідні та вихідні токени на запит, розподілені за моделлю.
• Сукупне використання токенів з плином часу для кожної моделі, команди, користувача та робочого процесу.
• Розміри контексту для конвеєрів з великою кількістю запитів, щоб ви могли бачити, коли запити збільшуються.
• Саме це дозволяє вам відповісти на запитання: «Хто насправді витрачає наш бюджет на штучний інтелект і на що?»

Поведінка з підказками та реакцією

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

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

• Модель специфічних для моделі коефіцієнтів помилок та типів (помилки постачальника, тайм-аути, проблеми з авторизацією, помилки квот).
• Збої в навколишньому робочому процесі, такі як тайм-аути інструментів або помилки отримання, корелювали з викликом LLM.

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

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

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

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

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

• Відстеження повного робочого процесу, а не лише виклику моделі – Фіксуючи весь шлях від клієнта-запиту до сервісу, пошуку, моделі та інструментів, ви можете побачити, де змінилася поведінка. Наприклад, можливо, пошук почав повертати менше документів, або виклик інструменту періодично дає збій, а модель імпровізує.
• Зберігання підказок, контексту та відповідей у ​​голові – Коли ви можете перевіряти запити та відповіді разом зі слідами, стає набагато легше виявляти випадки, коли нова версія запиту, нова системна інструкція або нове джерело контексту змінили поведінку, навіть якщо затримка та коефіцієнти помилок залишилися незмінними.
• Фільтрація та розбивка за семантичними умовами – Щойно у вас буде повноцінна телеметрія LLM, ви можете фільтрувати дані до таких речей, як «базові виклики тривалістю понад одну секунду», «запити з використанням цього сімейства моделей» або «траси, що включають цей конкретний маршрут», а потім прочитати підказки та відповіді, щоб побачити, чи модель дрейфує або галюцинує в певному сценарії.
• Оповіщення щодо SLO на рівні бізнесу – Ви можете визначити SLO, наприклад, «будь-який виклик LLM тривалістю одну секунду порушує нашу угоду про рівень обслуговування (SLA), орієнтовану на користувача», та запускати сповіщення, коли ці умови виконуються. З часом подібні SLO можна пов’язати з оцінками якості або перевірками політик, щоб ви отримували сповіщення про погіршення якості, а не лише про збій інфраструктури.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Розростання моделей та постачальників – Команди постійно тестують нові моделі. Швидко стає незрозуміло, які з них перебувають у виробництві та як вони використовуються.
• Несподівані витрати від використання токенів – Споживання токенів зростає зі збільшенням довжини контексту та складністю робочого процесу. Без прозорості використання токенів для кожної моделі та робочого процесу керувати витратами дуже складно.
• Залежність надійності від зовнішніх постачальників – API, орієнтовані на користувача, стають чутливими до затримки або помилок моделі, що може порушити угоди про рівень обслуговування (SLA), навіть коли основна інфраструктура справна.
• Зростання боргу за інструментарієм – Традиційна спостережуваність передбачає можливість додавання інструментарію за потреби. У швидкозмінних стеках штучного інтелекту розробники рідко мають на це час.

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

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

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

Заглядаючи в майбутнє, як, на вашу думку, розвиватиметься спостережуваність LLM протягом наступних п'яти років, оскільки агентний ШІ, багатомодельна оркестрація та регуляторний тиск прискорюються?

Ми все ще на початку. Протягом наступних п'яти років я очікую кількох значних змін:

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

Коротше кажучи, спостережуваність LLM еволюціонуватиме від «приємно мати інформаційні панелі для ШІ» до центральної нервової системи, яка пов'язує надійність, контроль витрат, управління даними та якість продукту з усім, що організація робить зі ШІ.

Дякую за чудове інтерв’ю, читачі, які хочуть дізнатися більше, повинні відвідати грунтопокривні.