Мониторинг ИИ‑агентов в продакшене: как «измерить радиацию» и не упустить деградацию

В эпоху активного внедрения искусственного интеллекта в продакшен‑средах появляются ИИ‑агенты, в которых LLM выполняет главную управляющую роль. Привычные подходы к наблюдаемости (observability) здесь работают не в полной мере: традиционные метрики и методы мониторинга не всегда позволяют вовремя заметить деградацию качества или сбои в работе таких систем.

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

Радиоактивность и ИИ‑агенты: метафора, которая многое объясняет

В 1896 году французский физик Анри Беккерель исследовал фосфоресценцию: он заворачивал фотопластинку в чёрную бумагу, клал сверху соль урана и ожидал, что солнечный свет «зарядит» соль, а та — засветит пластину. Из‑за дождливой погоды эксперимент пришлось отложить — конструкцию положили в ящик стола. Когда Беккерель проявил пластину, следы оказались яркими и чёткими, хотя уран лежал в темноте. Так было открыто явление радиоактивности.

ИИ‑агент — это приложение, в котором LLM отдана главная управляющая роль: что делать дальше, как это делать и когда закончить.

Не стоит путать агентов с:

• приложениями одного промпта: LLM в них выполняет одну утилитарную задачу — например, суммаризацию или классификацию интента. Это интеграция с LLM, а не агент.

• workflow: это жёстко заданный граф выполнения процесса, в котором разработчик заранее продумал весь flow. Это автоматизация, а не агент в строгом смысле.

Настоящий агент состоит из:

• LLM — «мозг» агента;
• оркестратор — логика, которая передаёт данные в модель и обрабатывает вывод;
• инструменты — «руки» агента: внешние API, CLI, функции ОС;
• данные — регламенты, корпоративная база знаний и т.  д.;
• контекстное окно — текущая «память» агента;
• шлюзы — прослойки для безопасности, аналитики, мониторинга и ограничения частоты запросов.

ИИ‑агент — это прежде всего инженерная задача, а не проявление «магии» машинного обучения. По мере усложнения архитектуры агента иллюзия «магии ИИ» исчезает: каждый элемент системы требует решения конкретных инженерных задач, и для этого вовсе не обязательно быть ML-экспертом.

Среди таких ключевых задач:

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

Таким образом, ИИ‑агент можно воспринимать как своеобразный, пусть и нетипичный, сервис — а развёртывание подобных сервисов в продакшен‑среде многим разработчикам и инженерам уже хорошо знакомо.

Observability ИИ‑агентов: в чём отличие

Observability ИИ-агентов (или LLM observability) — это мера того, насколько хорошо мы понимаем внутреннее состояние агента по его внешним проявлениям. Для классической инфраструктуры есть отработанные практики (метрики RED и USE, Golden Signals), но при переходе к ИИ‑агентам традиционные подходы начинают работать иначе. Или не работают вовсе.

Есть как минимум три особенности observability ИИ‑агентов.

Большие тексты — ключевая информация для дебага

Системные промпты, сообщения пользователей, ответы модели — это теперь основной материал для отладки. Это переворачивает привычный подход с ног на голову:

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

Логика агента становится недетерминированной: количество сценариев работы неподвластно нашему пониманию, поведение зависит от контекста в момент выполнения. Мы уже не знаем заранее, что именно сделает агент при запуске.

Ключевой сигнал — трейсы, а не логи

На первый взгляд кажется, что логи подходят лучше. Но если записывать в них всё нужное — промпты, ответы модели, вызовы инструментов с параметрами, — получается «месиво огромных JSON», которое невозможно анализировать при инциденте.

Логи для агентов проблемны: размер записей неадекватно большой, а хранилища разрозненны — агент пишет одной командой, бэкенды инструментов — другой, логи лежат в разных местах. Кроме того, агент сам решает, какие инструменты вызвать, и заранее неизвестно, в каких системах искать логи.

Трейсы выигрывают по трём причинам:

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

Метрики стали сложнее интерпретировать

Метрики по-прежнему нужны, но с ними не всё так просто. Для инфраструктуры есть устоявшиеся наборы метрик с документацией, а для агентов приходится выстраивать систему с нуля.

Какие метрики бывают у агентов

Есть три основных вида:

• Инфраструктурные: Latency, Time to First Token (TTFT), Traffic, Errors.
• Поведенческие: количество шагов для решения задачи, попадание в циклы, распределение вызовов инструментов.
• Экономические: расход входящих и исходящих токенов, их стоимость, стоимость на задачу (не на запрос, а на полное решение).

С метриками существует две сложности:

• Метрики зависят от типа задачи. Допустим, для одной задачи агенту нужно пять шагов, а для другой — 25. Если скидывать всё в одну кучу, метрики могут показывать ерунду. Решение: «корзинка» с типом задачи (отдельные для лёгких, средних и сложных или специфичных для домена).
• Ошибки стали семантическими. Агент может отвечать быстро и без ошибок инфраструктуры, но выдавать неточный, токсичный или просто ответ не по теме, но при этом по базовым метрикам всё «зелёное».

Evals: оценка качества работы агента

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

У ИИ-агентов этот подход ломается: логикой управляет модель (недетерминированность), а агенты «ломаются тихо и уверенно» — инфраструктурные метрики могут быть «зелёными» даже при неверном ответе.

Offline evals

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

• ответ на том же языке, что и запрос пользователя;
• использование правильных инструментов;
• вежливость и тон общения;
• корректность логики в трейсе — как агент дошёл до результата.

Online evals

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

LLM as a Judge

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

Пирамида зрелости: с чего начать

Уровень 0: логи

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

Уровень 1: OpenTelemetry + привычные инструменты

Подключите автоинструментацию OpenTelemetry к существующему стеку (Grafana, Jaeger и т. д.). Из коробки получите базовые логи, трейсы и метрики. Для каждого фреймворка есть свои OTel-библиотеки.

Важный нюанс: в свежих версиях OTel-библиотек по умолчанию отключён трекинг больших текстов. Без ручного включения трейсы теряют основную ценность — включите его.

Уровень 2: специализированные инструменты

Например, LangFuse — опенсорс-платформа для мониторинга агентов: трейсы, evals, версионирование промптов, хорошая визуализация. Есть облачная версия и self-hosted.

Уровень 3: Yandex Monium

Yandex Monium — observability-платформа от Yandex Cloud. Ключевая возможность для мониторинга ИИ-агентов в Yandex Monium — визуализация трейсов с фокусом на большие тексты:

• история сообщений, входные/выходные параметры инструментов, их описания — всё наглядно, а не «простыня JSON»;
• для суперпользователей — все спаны и атрибуты в первозданном виде;
• готов принимать трейсы из облака — не нужно ничего разворачивать, можно отправлять прямо с ноутбука.

Работать с функциональностью можно двумя способами:

• В интерфейсе Yandex Monium — полный observability-контур: детальный разбор трейсов, спанов и атрибутов.

  Как начать: создайте сервисный аккаунт в Yandex Cloud и назначьте ему роли для сбора телеметрии. Настройте отправку метрик или логов через OpenTelemetry и анализируйте данные в интерфейсе Yandex Monium.

  Подробнее о начале работы читайте в документации.

• В Yandex AI Studio — прямо в интерфейсе создания и отладки агентов. Трейсы показывают цепочку действий агента и контекст каждого шага (системные промпты, ответы модели, запросы и ответы инструментов). Это помогает находить неочевидные проблемы: неверные ответы, бесконечные циклы вызовов и другие показатели, которые не ловят классические метрики.

  Как начать: в Yandex AI Studio откройте вкладку «Логирование» и подключите отслеживание трейсов моделей и агентов. Просматривать трейсы можно в карточках агентов (иконка мониторинга и отладки внизу) или во вкладке «Логирование».

Ключевые выводы

Работа с ИИ‑агентами требует особого подхода к observability. Ниже — основные выводы, которые помогут выстроить эффективную систему мониторинга и её отладки:

• Большие тексты (промпты, ответы, контекст) — ключевая информация для дебага ИИ‑агентов.
• Трейсы — основной сигнал для анализа.
• Метрики важны, но их сложнее интерпретировать: нужна сегментация по типу задачи и понимание семантических ошибок.
• Для оценки качества нужны evals — подход, непривычный для DevOps/SRE‑инженеров, но необходимый.
• Специализированные инструменты уже существуют: LangFuse, Yandex Monium. Стандарт де‑факто — OpenTelemetry.

Частые вопросы

Какие метрики сигнализируют о деградации агента?

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

Может ли ИИ‑агент мониторить другого ИИ‑агента?

Подход LLM as a Judge по сути близок к идее мониторинга одного ИИ‑агента другим. С одной стороны, технически это вполне возможно. С другой — существует риск умножения ошибки: например, если первый агент галлюцинировал, то второй может выдать некорректную оценку на основе искажённых данных. Возникает дополнительный аспект для размышлений: кто в итоге будет мониторить самого агента мониторинга и сколько ресурсов, в том числе финансовых, потребует такая схема?

Подходят ли OSS‑инструменты (OTel, Prometheus^®, Jaeger) для мониторинга ИИ‑агентов?

OpenTelemetry отлично подходит в качестве стандарта сбора данных. Но у связки с Jaeger есть недостаток: в нём сложно анализировать данные из‑за громоздких JSON‑выводов. Ещё одна сложность — разработчики SDK нередко отстают от актуальных конвенций OpenTelemetry примерно на год. Prometheus^® хорошо подходит для работы с метриками. LangFuse зарекомендовал себя как удобный инструмент для работы с трейсами. А Yandex Monium лучше всего подходит для визуализации трейсов ИИ‑агентов — он даёт более наглядное представление данных по сравнению с другими решениями.

Существует стандартизация метрик моделей?

Да, стандартизация есть. Сейчас доминирующим стандартом стал OpenTelemetry с собственной конвенцией для observability ИИ и LLM: он определяет, какие атрибуты следует записывать и как правильно организовать мониторинг. Ещё полгода назад существовало несколько конкурирующих конвенций, но сейчас можно уверенно ориентироваться на OpenTelemetry — это повышает вероятность того, что разные инструменты будут корректно взаимодействовать между собой и работать адекватно.