Шахар Азулай, генеральный директор и соучредитель компании groundcover.

Шахар Азулай, Генеральный директор и соучредитель groundcover — опытный руководитель в сфере исследований и разработок. Шахар обладает обширным опытом в области кибербезопасности и машинного обучения, работая руководителем в таких компаниях, как Apple, DayTwo и Cymotive Technologies. Много лет Шахар проработал в киберподразделении канцелярии премьер-министра Израиля и имеет три степени: по физике, электротехнике и информатике, полученные в Технионе (Израильский технологический институт) и Тель-Авивском университете. Шахар стремится использовать полученные в ходе этого богатого технологического опыта знания и применять их в современной облачной среде в наиболее эффективной и инновационной форме, чтобы сделать мир разработки лучше.

почвопокровное Это облачная платформа мониторинга, разработанная для обеспечения инженерным командам полной видимости своих систем в режиме реального времени без сложностей и затрат, присущих традиционным инструментам мониторинга. Созданная на основе технологии eBPF, она собирает и сопоставляет журналы, метрики, трассировки и события в облачных средах и средах Kubernetes без изменений кода, что позволяет быстрее выявлять первопричины и получать более четкое представление о системе. Платформа делает акцент на предсказуемом ценообразовании, гибком развертывании, которое хранит данные в облаке клиента, и сквозном мониторинге, охватывающем инфраструктуру, приложения и современные рабочие нагрузки на основе ИИ.

Оглядываясь на свой путь — от руководства группами исследований и разработок в области кибербезопасности в канцелярии премьер-министра Израиля до управления инициативами в области машинного обучения в Apple — какой опыт в конечном итоге подтолкнул вас к созданию groundcover, и когда вы впервые осознали пробел в наблюдаемости современных систем искусственного интеллекта?

Идея создания Groundcover возникла во время моей работы в Apple и DayTwo. Даже с огромными бюджетами мы стояли перед выбором: либо платить целое состояние за ведение логов, либо проводить выборочные исследования и действовать вслепую. Тогда мы искали технологию, которая решила бы эту проблему. Когда мы столкнулись с Extended Berkeley Packet Filter (eBPF), стало ясно, что это изменит всё. eBPF позволяет нам видеть всё, что происходит в ядре, не полагаясь на изменения в приложениях. Я не мог понять, почему инструменты мониторинга не используют это преимущество. Проблема с ИИ стала очевидной позже. Когда наша платформа Kubernetes достигла зрелости, мы увидели, как клиенты спешат внедрять GenAI, рассматривая LLM как чёрные ящики. Они знали, что модель реагирует, но не понимали, почему она ведёт себя непредсказуемо или почему резко возрастают затраты. Мы поняли, что агентные рабочие процессы — это просто сложные, недетерминированные микросервисы, которым необходима та же самая прозрачность без участия пользователя, которую мы уже создали.

Как ваш опыт в области кибербезопасности, встроенных систем и исследований и разработок в сфере машинного обучения повлиял на концепцию groundcover, и с какими трудностями вы столкнулись на начальном этапе создания компании, ориентированной на обеспечение наблюдаемости для приложений, управляемых LLM и агентными системами?

Мой опыт в сфере кибербезопасности сформировал ДНК компании. В мире разведки предполагается, что вы не контролируете приложение. Именно поэтому для мониторинга наземного покрытия не требуется инструментарий. По опыту знаю, что просьба к разработчикам изменить код — самый быстрый способ заблокировать внедрение. Самой сложной проблемой на начальном этапе работы с мониторингом LLM была конфиденциальность. Наблюдаемость для ИИ позволяет фиксировать запросы, которые могут содержать конфиденциальную личную информацию или IP-адрес. Мой опыт показал, что предприятия не захотят, чтобы эти данные покидали их среду. Именно поэтому мы создали нашу облачную архитектуру, позволяющую нам обеспечивать глубокую видимость поведения агентов, сохраняя при этом все данные внутри собственной среды клиента.

Как вы определяете наблюдаемость LLM, и чем она отличается от традиционного мониторинга или мониторинга ML?

Наблюдаемость больших языковых моделей (LLM) — это практика инструментирования и мониторинга производственных систем, использующих большие языковые модели, позволяющая фиксировать полный контекст каждого вывода: подсказку, контекст, завершение, использование токенов, задержку, ошибки, метаданные модели и, в идеале, обратную связь или сигналы качества. Вместо того чтобы спрашивать только «Работает ли сервис быстро?» или «Вышел ли этот запрос с ошибкой?», наблюдаемость LLM помогает ответить на такие вопросы, как «Почему этот конкретный запрос был успешным или неудачным?», «Что на самом деле произошло внутри этого многоэтапного рабочего процесса?» и «Как изменения подсказок, контекста или версий модели влияют на стоимость, задержку и качество выходных данных?». Это сильно отличается от традиционного мониторинга или даже классического мониторинга машинного обучения. Традиционные подходы настроены на детерминированные системы, метрики инфраструктуры и статические пороговые значения. Приложения LLM являются недетерминированными, открытыми и сильно зависят от контекста. Успех часто является семантическим и субъективным, а не просто кодом состояния 200 или 500. Это означает, что вам необходимо отслеживать входные и выходные данные, понимать вызовы инструментов и этапы получения информации, оценивать реакцию на такие вещи, как галлюцинации или нарушения политики, а также связывать затраты и задержки на уровне токенов с окружающим приложением и инфраструктурой.

Какие проблемы создают приложения на основе LLM, из-за которых традиционные инструменты мониторинга оказываются недостаточными?

Системы, использующие технологию LLM, создают ряд проблем, которые выявляют ограничения традиционных инструментов:

• Сложные, многоэтапные рабочие процессы – Мы перешли от простых потоков «вызов модели, получение ответа» к многоэтапным агентам, многоступенчатым конвейерам, расширенному поиску и использованию инструментов. Скрытый сбой на любом из этих этапов, таких как поиск, обогащение, встраивание, вызов инструмента или вызов модели, может нарушить весь процесс. Традиционный мониторинг обычно не дает полного, трассировочного представления этих цепочек, включая запросы и ответы.
• Быстро развивающиеся системы искусственного интеллекта – Команды добавляют новые модели, инструменты и поставщиков с невиданной ранее скоростью. Во многих компаниях никто не может с уверенностью сказать, какие модели находятся в эксплуатации в данный момент. Классическая система мониторинга обычно предполагает наличие времени для внедрения SDK, повторного развертывания и тщательной проверки измеряемых данных. Это просто не соответствует скорости внедрения ИИ.
• Экономика на основе токенов и квоты – Ценообразование и ограничения скорости привязаны к токенам и длине контекста, которые часто контролируются разработчиками, подсказками или поведением пользователя, а не централизованным управлением. Традиционные инструменты не предназначены для того, чтобы показывать, «кто сколько токенов потратил на какой модели, для какого рабочего процесса, с какой задержкой».
• Семантическая корректность вместо бинарного успеха – LLM может вернуть код 200 и при этом галлюцинировать, отклоняться от заданного запроса или нарушать правила. Традиционные инструменты считают это успехом. Вам необходима наблюдаемость, которая позволит выявлять запросы и ответы, предоставляя достаточно контекста для анализа поведения и, со временем, внедрения автоматизированных проверок качества.
• Конфиденциальные входные данные, передаваемые третьим сторонам. – LLM-системы предлагают пользователям обмениваться крайне конфиденциальной информацией через интерфейсы, похожие на чат. Теперь вы несёте ответственность за эти данные, за то, где они хранятся, и за то, какие поставщики их видят. Традиционные системы мониторинга на основе SaaS, которые передают всю телеметрию третьей стороне, часто неприемлемы для таких задач.

Всё это означает, что системам LLM требуется наблюдаемость, учитывающая возможности ИИ, обладающая богатым контекстом и гораздо меньшей зависимостью от ручной настройки, чем те инструменты, которые большинство команд используют сегодня.

Какие сигналы или метрики наиболее важны для понимания производительности и качества систем LLM, включая задержку, использование токенов и поведение запроса/ответа?

На практике существует несколько категорий сигналов, имеющих большое значение:

Задержка и пропускная способность

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

Факторы, влияющие на использование токенов и их стоимость

• Входные и выходные токены на каждый запрос, с разбивкой по моделям.
• Сводные данные об использовании токенов за определенный период времени по моделям, командам, пользователям и рабочим процессам.
• Размеры контекста для конвейеров с высокой интенсивностью извлечения данных, чтобы вы могли видеть, когда запросы становятся слишком многочисленными.
• Именно это позволяет ответить на вопрос: «Кто на самом деле тратит наш бюджет на ИИ и на что?»

Поведение, реагирующее на действия и реагирующее на них

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

Надежность и ошибки

• Моделируйте конкретные показатели и типы ошибок (ошибки поставщика, тайм-ауты, проблемы с аутентификацией, ошибки квот).
• Сбои в окружающем рабочем процессе, такие как тайм-ауты инструментов или ошибки при извлечении данных, коррелировали с вызовом LLM.

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

• Метрики ЦП, памяти и сети контейнеров для сервисов, организующих ваши вызовы LLM.
• Сопоставленные журналы, описывающие действия, которые пыталось выполнить приложение.

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

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

Скрытые сбои в системах LLM обычно происходят, когда на уровне инфраструктуры все выглядит «хорошо», но фактическое поведение отклоняется от нормы. Наблюдаемость помогает несколькими способами:

• Отслеживание всего рабочего процесса, а не только вызова модели. – Отслеживая весь путь запроса от клиента к сервису, от получения данных до модели и инструментов, можно увидеть, где изменилось поведение. Например, возможно, получение данных стало возвращать меньше документов, или вызов инструмента периодически завершается с ошибкой, и модель работает в режиме импровизации.
• Учитывайте подсказки, контекст и ответы. – Когда вы можете анализировать подсказки и ответы вместе с трассировкой, становится намного проще выявлять случаи, когда новая версия подсказки, новая системная инструкция или новый источник контекста изменили поведение, даже если задержка и частота ошибок остались прежними.
• Фильтрация и сегментация по семантическим условиям – Получив подробные телеметрические данные LLM, вы можете отфильтровать их по таким параметрам, как «вызовы базового класса за одну секунду», «запросы с использованием этого семейства моделей» или «трассировки, включающие этот конкретный маршрут», а затем прочитать подсказки и ответы, чтобы определить, не отклоняется ли модель от нормы или не выдает ли она ложные результаты в конкретном сценарии.
• Оповещения о показателях SLO на уровне бизнеса – Вы можете определить SLO, например, «любой вызов LLM, занимающий более одной секунды, нарушает наше соглашение об уровне обслуживания (SLA) для пользователей», и запускать оповещения при выполнении этих условий. Со временем аналогичные SLO можно привязать к показателям качества или проверкам политик, чтобы получать оповещения не только о сбоях инфраструктуры, но и о снижении качества.

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

Каким образом подход groundcover помогает диагностировать непредсказуемые задержки или неожиданное поведение в многоэтапных рабочих процессах агентов и вызовах инструментов?

groundcover использует подход, разработанный для современных систем искусственного интеллекта. Мы применяем датчик на основе eBPF на уровне ядра для наблюдения за трафиком между микросервисами без изменений кода или повторного развертывания. Как только вы внедряете рабочий процесс LLM, мы можем автоматически обнаруживать эти вызовы. Если вы завтра начнете использовать новую модель, такую ​​как Anthropic, OpenAI или Bedrock, groundcover автоматически перехватит этот трафик. Это дает вам:

• Сквозная трассировка многоэтапных рабочих процессов – Вы видите полный путь запроса по различным сервисам, включая места использования LLM или инструмента.
• Подробный контекст каждого звонка в рамках программы LLM – Каждый вызов включает в себя используемую модель, задержку, использование токенов, подсказки, ответы, а также коррелированные журналы и инфраструктурные метрики.
• Мощная фильтрация по задержке и условиям. – Например, вы можете отфильтровать все вызовы Claude 3.5, выполняющиеся более одной секунды, и немедленно проверить трассировки, которые нарушили ваше соглашение об уровне обслуживания (SLA).
• Оповещения и информационные панели, привязанные к поведению LLM. – После получения данных вы можете создавать оповещения о нарушениях SLA или разрабатывать панели мониторинга, отслеживающие задержку, пропускную способность, использование токенов и ошибки.

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

Какие риски в области безопасности данных и соответствия нормативным требованиям вы видите в развертывании LLM, и как мониторинг может помочь снизить эти риски?

Внедрение LLM сопряжено с рядом уникальных рисков, связанных с данными:

• Неограниченный ввод данных пользователем – Пользователи могут вводить в чат-боты и интерфейсы на основе искусственного интеллекта крайне конфиденциальную информацию. Это может включать персональные данные, данные клиентов или информацию, подлежащую регулированию, которую вы никогда не собирались собирать.
• Сторонние поставщики моделей – После отправки этих данных внешнему поставщику услуг LLM вы несете ответственность за то, куда они попали, как хранятся и какие субподрядчики задействованы. Это имеет серьезные последствия для GDPR, места хранения данных и доверия клиентов.
• Телеметрия как вторая копия конфиденциальных данных – Если ваш стек мониторинга отправляет полные данные поставщику SaaS-услуг, у вас появляется еще одна копия этой конфиденциальной информации, находящаяся за пределами вашей среды.

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

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

Иными словами, наблюдаемость становится не только инструментом обеспечения надежности и снижения затрат, но и ключевым элементом контроля конфиденциальности, хранения данных и соответствия нормативным требованиям.

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

Первая интеграция обычно представляет собой одну модель в рамках одного рабочего процесса. На этом этапе все кажется управляемым. Как только команды видят ценность, использование резко возрастает, и возникает ряд проблем:

• Разброс моделей и поставщиков – Команды постоянно тестируют новые модели. Быстро становится непонятно, какие из них находятся в эксплуатации и как они используются.
• Неожиданные затраты, связанные с использованием токенов – Потребление токенов растет с увеличением длительности контекста и сложности рабочего процесса. Без информации об использовании токенов для каждой модели и рабочего процесса управление затратами становится очень сложным.
• Зависимость надежности от внешних поставщиков – Пользовательские API-интерфейсы становятся чувствительными к задержкам или ошибкам модели, что может нарушить соглашения об уровне обслуживания (SLA), даже если основная инфраструктура работает исправно.
• Растущая задолженность по оборудованию – Традиционные методы мониторинга предполагают возможность добавления инструментов мониторинга по мере необходимости. В быстро развивающихся системах искусственного интеллекта у разработчиков редко бывает на это время.

groundcover решает эти проблемы, автоматически обнаруживая трафик ИИ и предоставляя вам следующие данные:

• Централизованная система отображения информации о том, какие модели и поставщики используются.
• Панели мониторинга, отображающие задержку, пропускную способность и использование токенов с течением времени.
• Корреляция между поведением LLM и услугами, которые от него зависят.
• Оповещения о нарушениях SLO, вызванных ИИ.

Это значительно упрощает масштабирование от «одной интересной функции ИИ» до «ИИ интегрирован в десятки критически важных сервисов» без потери контроля.

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

Мы пока находимся на начальном этапе. В течение следующих пяти лет я ожидаю нескольких крупных изменений:

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

Короче говоря, наблюдаемость LLM эволюционирует от «желательных панелей мониторинга для ИИ» до центральной нервной системы, которая связывает надежность, контроль затрат, управление данными и качество продукции во всех аспектах деятельности организации, связанных с ИИ.

Спасибо за отличное интервью, читатели, которые хотят узнать больше, должны посетить почвопокровное.