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

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

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

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

Стимул к основанию groundcover возник из моего опыта в Apple и DayTwo. Даже с огромными бюджетами мы были вынуждены выбирать между оплатой огромной суммы за регистрацию всего или выборочным контролем и полетом вслепую. В то время мы искали технологию, которая бы решила эту проблему. Как только мы столкнулись с расширенным беркли-пакетным фильтром (eBPF), стало ясно, что это изменит все. eBPF позволяет нам видеть все, что происходит в ядре, не полагаясь на изменения приложений. Я не мог понять, почему инструменты наблюдения не используют эту возможность. Пробел в ИИ стал ясен позже. Как только наша платформа Kubernetes созрела, мы увидели, что клиенты спешат в развертывания GenAI, обращаясь с большими языковыми моделями как с черными ящиками. Они знали, что модель реагирует, но не знали, почему она ведет себя непредсказуемо или почему затраты взрывоопасны. Мы поняли, что агентские рабочие процессы просто являются сложными, неопределенными микросервисами, которым необходима та же видимость без прикосновения, которую мы уже построили.

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

Мой опыт в области кибербезопасности сформировал ДНК компании. В мире разведки вы предполагаете, что не контролируете приложение. Этот подход является причиной, по которой groundcover не требует инструментирования. Я знаю из опыта, что просьба к разработчикам изменить код – это самый быстрый способ заблокировать принятие. Самой сложной ранней проблемой при мониторинге ИИ было обеспечение конфиденциальности. Наблюдение за ИИ захватывает подсказки, которые могут содержать чувствительную личную информацию или интеллектуальную собственность. Мой опыт сделал очевидным, что предприятия не хотят, чтобы эти данные покидали их среду. Вот почему мы построили свою архитектуру в облаке, позволяющую нам предоставлять глубокую видимость поведения агентов, сохраняя все данные внутри среды клиента.

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

Наблюдение за ИИ – это практика инструментирования и мониторинга систем производства, которые используют большие языковые модели, чтобы захватить полный контекст каждого вывода: подсказку, контекст, завершение, использование токенов, задержку, ошибки, метаданные модели и, идеально, обратную связь или сигналы качества вниз по потоку. Вместо того, чтобы спрашивать только “Служба ли активна и быстра?” или “Эта ли просьба завершилась ошибкой?”, наблюдение за ИИ помогает вам ответить на вопросы, такие как “Почему эта конкретная просьба завершилась успешно или неудачно?”, “Что на самом деле произошло внутри этого многоступенчатого рабочего процесса?” и “Как изменения подсказок, контекста или версий моделей влияют на стоимость, задержку и качество вывода?” Это очень отличается от традиционного мониторинга или даже классического мониторинга машинного обучения. Наследственные подходы настроены на детерминированные системы, метрики инфраструктуры и статические пороги. Приложения ИИ являются неопределенными, открытыми и сильно зависящими от контекста. Успех часто является семантическим и субъективным, а не просто кодом состояния 200 или 500. Это означает, что вам необходимо отслеживать входные и выходные данные, понимать вызовы инструментов и шаги извлечения, оценивать ответы на такие вещи, как галлюцинации или нарушения политики, и связывать затраты и задержки на уровне токенов обратно с окружающим приложением и инфраструктурой.

Какие проблемы системы, управляемые ИИ, вводят, что делает традиционные инструменты наблюдения недостаточными?

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

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

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

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

Есть несколько категорий сигналов, которые имеют большое значение на практике:

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

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

Использование токенов и факторы стоимости

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

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

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

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

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

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

• Метрики CPU, памяти и сети контейнеров для служб, оркестрирующих вызовы ИИ.
• Связанные журналы, которые описывают, что пыталось сделать приложение.

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

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

Беззвучные неудачи в системах ИИ обычно происходят, когда все кажется “зеленым” на уровне инфраструктуры, но фактическое поведение дрейфует. Наблюдение помогает несколькими способами:

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

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

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

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

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

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

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

Развертывания ИИ вводят некоторые уникальные риски данных:

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

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

• Мы используем модель “принеси свое облако”, где полный бэкенд наблюдения работает внутри вашей учетной записи облака, в подучетной записи, как полностью управляемая плоскость данных. Плоскость управления, которая масштабирует и управляет ею, запускается нами, но мы не получаем доступ, не храним и не обрабатываем ваши данные телометрии.
• Поскольку мы можем безопасно захватить полезные нагрузки в вашей собственной среде, вы можете наблюдать подсказки, ответы и рабочие процессы без того, чтобы эти данные покидали ваше облако. Нет хранения третьей стороны трасс ИИ и нет дополнительного выхода данных, о котором нужно беспокоиться.
• С этой видимостью вы можете увидеть, кто загружает что и куда оно течет, обнаружить неожиданное использование чувствительных данных и обеспечить соблюдение политики вокруг того, какие модели и регионы разрешены.

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

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

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

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

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

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

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

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

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

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

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

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