Мониторинг AI-агента: что логировать и на что ставить алерты

Классический сервис падает громко: пятисотки, стектрейсы, красный дашборд. AI-агент ломается иначе — он продолжает отвечать, но отвечает не то. Модель уводит в галлюцинацию, вызов инструмента возвращает пустоту, а цепочка рассуждений тихо съедает в пять раз больше токенов, чем вчера. Обычный мониторинг это не ловит: HTTP-код 200, латентность в норме, счёт за месяц вырос вдвое. Ниже — что именно снимать с агента¹ и на какие пороги вешать алерты, чтобы узнавать о проблеме до пользователя, а не от него.

Три слоя, которые нужно наблюдать

У агента есть три уровня, и каждый ломается по-своему. Инфраструктурный слой — это привычные латентность, ошибки, доступность API модели. Слой самой модели — токены, стоимость, доля отказов и таймаутов от провайдера. И прикладной слой — качество ответа, корректность вызова инструментов, длина и стоимость цепочки рассуждений. Мониторинг только первого слоя даёт ложное чувство контроля.

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

Что логировать по каждому запросу

Минимальный набор полей, который стоит писать в трейс на каждый прогон агента:

• trace_id и span-и — сквозной идентификатор запроса и отдельные шаги внутри (вызов модели, вызов инструмента, ретрай). Без этого разбор инцидента превращается в чтение сплошного лога.
• Токены — отдельно input и output, по каждому вызову модели. Именно рост input-токенов чаще всего и раздувает счёт: контекст пухнет незаметно.
• Стоимость запроса — считается из токенов и тарифа модели, полезно видеть её в деньгах, а не в абстрактных единицах.
• Латентность по шагам — сколько заняла модель, сколько инструмент, сколько ретраи. Общая цифра прячет узкое место.
• Вызовы инструментов — какие вызваны, с какими аргументами, что вернули, была ли ошибка парсинга аргументов.
• Финальный статус — дал агент ответ, ушёл в отказ, упёрся в лимит шагов или в таймаут.

Не логируйте персональные данные пользователей в открытом виде и не тяните полные промпты в систему, где к ним имеет доступ вся команда. Это одновременно вопрос приватности и вопрос размера хранилища.

Метрики и пороги алертов

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

Почему абсолютные пороги подводят

Порог «алерт, если латентность больше 10 секунд» бесполезен, если у вас агент с планировщиком и пятью вызовами инструментов, где 10 секунд — норма. И он же пропустит деградацию простого агента, для которого нормой была секунда. Работают процентили (p95, p99) и отклонение от скользящей базовой линии. Абсолютные лимиты оставьте для денег: дневной и месячный потолок расходов — это как раз тот случай, где жёсткая цифра оправдана.

Как измерять качество, а не только работоспособность

Самое сложное — оценка того, хорош ли ответ. Тремя способами, обычно в комбинации:

1. Офлайн на золотом наборе. Держите набор эталонных запросов с ожидаемым поведением и прогоняйте его при каждом изменении промпта или смене модели. Это ловит регрессии до продакшена.
2. LLM-as-judge. Другая модель оценивает ответ по критериям (релевантность, отсутствие выдумок, следование инструкции). Дёшево и масштабируемо, но у судьи есть свои систематические ошибки — калибруйте его на размеченной выборке.
3. Обратная связь пользователя. Палец вверх/вниз, доля переспросов, доля обращений в поддержку после ответа агента. Самый честный сигнал, но приходит с задержкой и на малом трафике шумит.

Ни один из трёх не заменяет остальные. Золотой набор не знает о новых пользовательских формулировках, судья не ловит фактические ошибки в узкой предметке, а лайки собираются медленно.

Инструменты: что стоит посмотреть

Специализированных платформ для наблюдаемости LLM за последние два года стало много — LangSmith, Langfuse, Arize Phoenix, Helicone и другие. Часть из них построена вокруг стандарта OpenTelemetry, что позволяет складывать трейсы агента туда же, куда идёт остальная телеметрия сервиса. Конкретные тарифы и наличие облачной или self-hosted версии сверяйте на официальных страницах: цены и лимиты бесплатных планов у этих продуктов меняются часто. Если у вас уже развёрнут стек Prometheus + Grafana, базовые метрики (токены, стоимость, латентность, доля ошибок) можно снимать в него, а трейсинг цепочек добавить отдельным инструментом.

Кому это пригодится, а кому нет

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

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

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

¹ AI-агент — программа на основе языковой модели, которая не просто отвечает текстом, а самостоятельно выбирает и вызывает внешние инструменты (поиск, API, код), выстраивает многошаговую цепочку действий и решает, когда задача выполнена. Именно эта автономность и делает мониторинг сложнее, чем у обычного чат-бота.