Джефф Шампейн, технический директор Cribl – Интервью

Джефф Шампейн, технический директор 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, что дает вам уникальный взгляд на корпоративные данные, наблюдаемость и инфраструктуру за несколько технологических циклов. С этой точки зрения, что действительно отличается в проблеме наблюдаемости, созданной агентными ИИ?

В наблюдаемости приложений мы всегда имели дело с сложными, ветвящимися путями выполнения, отслеживая запросы через микросервисы и коррелируя журналы в распределенных системах. В операциях безопасности мы решали проблемы с высоким объемом, разнообразными источниками данных для обнаружения угроз в системах, которые, хотя и сложны, но ведут себя в основном предсказуемым образом. Агентный ИИ не изобретает эти проблемы заново; он взрывает их одновременно.

Агенты цепочат решения, вызывают внешние инструменты и порождают подагентов динамически способами, которые не предопределены на этапе написания. Граф выполнения не только сложен, но и может быть совершенно khácным каждый раз, и объем телеметрии, необходимой для реконструкции того, что фактически произошло, растет экспоненциально с каждым переходом. Сбор всей необходимой телеметрии для того, чтобы сделать агентные системы наблюдаемыми, должен быть одновременно простым для инструментирования и экономически эффективным для эксплуатации в масштабе. В противном случае предприятия будут делать тот же компромисс, который они всегда делали, и уменьшат видимость, чтобы контролировать затраты – именно в тот момент, когда не следует терять бдительность.

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

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

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

Агент сделал именно то, что ему было сказано; данные, которым он доверял, были просто устаревшими.

Почему традиционные инструменты наблюдаемости часто недостаточны для мониторинга агентных систем ИИ?

Во-первых, они были построены вокруг жестких, проприетарных схем и предсказуемых форм данных. Следы агентов не соответствуют этим ожиданиям – они объемны, высоко переменны по структуре и включают типы данных, такие как полный текст подсказки, цепочки рассуждений модели и полезные данные вызовов инструментов, которые традиционные инструменты не были разработаны для ингеста без значительной работы по трансформации. Открытые стандарты, такие как семантические конвенции GenAI OpenTelemetry, появляются для решения этой проблемы, но многие платформы наследия не были построены для использования их.

Во-вторых, уравнение масштаба и стоимости быстро разрушается. Один агент, обрабатывающий рабочие нагрузки производства, может сгенерировать больше телеметрии за час, чем весь стек приложений произвел за день, и большинство традиционных платформ взимают плату за объем ингеста и хранения. Это создает невозможный компромисс – либо инструментируйте все и столкнитесь с бешеными затратами, либо уменьшите видимость в системах, где вам это нужно больше всего.

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

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

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

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

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

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

Другие сигналы MELT не исчезают; метрики использования токенов и задержки имеют значение для стоимости и производительности, и журналы из систем вниз по потоку остаются необходимыми. Но следы – это то, что делает поведение агентов читаемым в масштабе.

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

Большинство галлюцинаций в производстве не являются неудачами модели; они являются операционными неудачами в маскировке. Плохое извлечение возвращает устаревший или неполный контекст, и модель заполняет пробел чем-то, что звучит правдоподобно. Сломанная интеграция означает, что агент никогда не получил данных, которые ему нужны для правильного рассуждения в первую очередь. Отсутствие контекста из-за неудачи работы ETL выглядит как галлюцинация, но на самом деле это проблема инфраструктуры.

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

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

Основой все еще является MELT, но подотчетность агентных систем требует наложения рамки оценки на традиционную телеметрию. Метрики, события и журналы раскрывают неудачи инфраструктуры и сломанные интеграции, которые могут испортить поведение агента, прежде чем модель ответит; следы дают вам цепочку рассуждений, чтобы понять, почему он пришел к определенному ответу. Но ни один из них не говорит вам, был ли ответ фактически правильным, и именно здесь оценка LLM-as-judge заполняет пробел. Те же возможности ИИ, которые управляют агентами, могут быть использованы для оценки их, оценивая выходы для точности, обоснованности и завершения задачи в масштабе, который человеческий процесс проверки не может сравниться.

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

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

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

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

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

Самая распространенная ошибка, которую я вижу, заключается в том, что они тянутся за существующими премиальными платформами наблюдаемости для сбора следов агентов, не подумав о последствиях для затрат. Следы агентов большие, переменные и объемные способами, которыми традиционная телеметрия приложений не является, и большинство премиальных платформ взимают плату за ингест и хранение. Счет может стать серьезной проблемой, прежде чем команды даже осознают, что происходит, и типичная реакция – уменьшить то, что они собирают. Результат – худшее из обоих миров: высокая стоимость и неполная видимость.

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

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

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

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

Основная причина, по которой агенты будут нуждаться в этом виде надзора неограниченно долго, заключается в том, что они являются недетерминированными по конструкции, их поведение возникает во время выполнения, и их эффективная способность растет каждый раз, когда вы подключаете новый инструмент. Статическая сертификация до развертывания не может покрыть систему, чья поверхность действия меняется с каждой интеграцией. Агенты будут работать в определенных границах доверия, и эти границы будут расширяться со временем, поскольку инфраструктура наблюдаемости, политики и оценки созревает. Границы сами по себе никогда не исчезнут, и это не состояние неудачи. Это то, как работает каждая значимая автономная система в мире. Спасибо за отличное интервью, читателям, которые хотят узнать больше, следует посетить Cribl.