Мониторинг LLM и ИИ-агентов: качество, токены, ошибки

Проверено 27 августа 2026 года.

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

Минимальный набор: trace ID, сценарий, версия приложения и промпта, модель, шаги retrieval/LLM/tools, токены, задержка, ошибки, причина fallback, результат проверки качества и итог бизнес-операции. Полные промпты и ответы собирают только при обоснованной цели, с маскированием и сроком хранения.

Коротко: инфраструктурные метрики отвечают «работает ли система», трасса — «что именно произошло», eval и обратная связь — «был ли результат правильным». Алерт нужен, когда ухудшается пользовательский или бизнес-SLO, а не при любом росте числа токенов.

Содержание

Три слоя мониторинга LLM
Что записывать в трассу
Метрики задержки, токенов и стоимости
Как измерять качество ответов
Что мониторить у RAG
Что мониторить у ИИ-агента
Алерты без лишнего шума
Разбор инцидента
Инструменты и архитектура
Приватность трасс
План внедрения
FAQ
Как AI рассвет настраивает наблюдаемость ИИ
Итог

Три слоя мониторинга LLM

1. Сервисный слой

Он похож на обычную observability: число запросов, error rate, rate limits, очередь, доступность провайдера, задержка и насыщение ресурсов. Эти показатели нужны SRE и платформенной команде.

2. Слой выполнения

Trace объединяет все шаги одного пользовательского действия: подготовку промпта, поиск документов, вызовы LLM, парсер, инструменты и fallback. В терминологии LangSmith trace состоит из runs; в OpenTelemetry близкий объект — дерево spans. Название инструмента вторично, если контекст проходит через все сервисы.

3. Слой качества и бизнеса

Здесь фиксируются корректность, полнота, наличие источников, решение эксперта, пользовательская обратная связь и исход процесса: был ли создан правильный заказ, закрыто обращение или предотвращено опасное действие. Этот слой нельзя получить только из токенов и HTTP-кодов.

Слой	Главный вопрос	Примеры сигналов
Сервис	система доступна?	ошибки, p95 latency, 429, очередь
Выполнение	что сделал агент?	spans, retrieval, tool calls, retry, fallback
Качество	результат принят?	eval score, эскалация, исправление человеком, бизнес-исход

Что записывать в трассу

Корневой span описывает пользовательскую или бизнес-операцию. Дочерние spans — отдельные действия. Минимальная схема:

trace ID и session/thread ID;
environment, service, scenario и tenant;
версия приложения, workflow, промпта и базы знаний;
провайдер, точный model ID и параметры генерации;
input/output/cached/reasoning tokens, если доступны;
начало, окончание, time to first token и статус;
retrieval query, идентификаторы найденных документов и ранги;
название инструмента, валидированные аргументы и результат;
retry/fallback с причиной;
автоматическая оценка, отзыв пользователя и решение эксперта.

OpenTelemetry GenAI semantic conventions дают стандартные имена части атрибутов, включая систему, модель и usage. Соглашения развиваются, поэтому внутреннюю схему трассы версионируют и хранят слой преобразования.

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

Метрики задержки, токенов и стоимости

Среднее значение часто скрывает хвост распределения. Для пользовательских сценариев смотрят медиану и p95/p99, отдельно time to first token и полное время. Для batch-задач важнее время завершения очереди и доля просроченных задач.

Метрика	Для чего нужна	Частая ошибка
Requests	нагрузка и сезонность	не делить по сценарию
Error rate	доступность	смешивать policy deny с аварией
p95 latency	хвост задержки	смотреть только среднее
Input/output tokens	объём и стоимость	не учитывать retry и tool loop
Cost per request	бюджет API	не связывать с качеством
Cost per accepted task	экономика процесса	считать без ручных исправлений
Fallback rate	устойчивость primary	считать fallback успехом без eval

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

Как измерять качество ответов

Один «общий quality score» плохо диагностирует проблему. Набор оценок зависит от сценария:

точное совпадение или проверка JSON-схемы для извлечения данных;
groundedness и корректность ссылок для RAG;
соблюдение политики и отсутствие запрещённого действия для агента;
полнота, стиль и решение эксперта для поддержки;
фактический бизнес-исход после ответа.

Используйте четыре источника качества:

Детерминированные проверки. Схема, диапазоны, ссылки, бизнес-правила.
Эталонный eval-набор. Версионированные примеры с ожидаемыми ответами или критериями.
Экспертная разметка. Выборка реальных трасс с причиной решения.
LLM-judge. Масштабируемая предварительная оценка, откалиброванная против экспертов.

MLflow Evaluation позволяет повторно оценивать сохранённые traces разными scorers, не вызывая приложение заново. Документация также описывает асинхронную оценку выборки production-трафика. Judge не является независимой истиной: его версия, промпт, модель и согласие с человеком тоже мониторятся.

Что мониторить у RAG

RAG может вернуть гладкий ответ при плохом поиске. Разделите pipeline:

доля запросов без найденных документов;
recall на эталонном наборе;
ранги и источники выбранных фрагментов;
дубликаты и устаревшие версии документов;
доля утверждений со ссылкой;
корректность соответствия цитаты утверждению;
ответ при недостатке данных;
задержка retrieval отдельно от LLM.

Если качество упало после обновления базы, сравните версии индекса, chunking, embeddings, reranker и промпт. Замена LLM может не исправить ошибку поиска.

Что мониторить у ИИ-агента

Для агента результат зависит от траектории. Полезны:

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

Завершённая трасса не обязательно успешна. Агент мог остановиться по лимиту и сформулировать уверенный ответ. Поэтому бизнес-сервис должен возвращать проверяемый статус операции, а не позволять модели объявлять успех текстом.

Алерты без лишнего шума

Порог нельзя копировать из чужого блога. Сначала соберите baseline по конкретному сценарию и согласуйте SLO. Хороший алерт содержит владельца, окно, сегмент и действие.

Алерты высокого приоритета:

резкий рост ошибок или таймаутов у production-сценария;
невозможность выполнить критичный инструмент;
нарушение policy или попытка действия вне прав;
падение доли принятых результатов;
превышение бюджета или runaway loop;
исчезновение трасс при продолжающемся трафике.

Сигналы вроде роста p95 или fallback rate сначала могут идти как предупреждения. Используйте burn rate и несколько окон, чтобы краткий всплеск не будил команду без необходимости.

Разбор инцидента

Определите затронутые сценарии, версии и временное окно.
Сравните сервисные метрики с baseline.
Выберите репрезентативные traces, включая успешные рядом по времени.
Найдите первый расходящийся span: retrieval, модель, парсер или tool.
Проверьте изменения провайдера, промпта, индекса, цены и маршрута.
Ограничьте ущерб: выключите инструмент, верните прошлую версию, переключите на проверенный резерв или включите человека.
Добавьте найденный случай в regression-набор.

Отчёт должен различать непосредственную причину и системный пробел. Например, таймаут провайдера — событие, а отсутствие idempotency перед retry инструмента — причина двойной операции.

Инструменты и архитектура

Есть три пути:

существующий OpenTelemetry-стек плюс собственные GenAI-атрибуты;
open-source платформа вроде MLflow Tracing, которая поддерживает traces, token usage, feedback и evaluation;
управляемые сервисы наблюдаемости с автоматической инструментализацией.

Выбирайте по данным, интеграциям, экспорту, стоимости хранения, eval-возможностям и контролю доступа. Не покупайте trace viewer до определения схемы и процессов реагирования: красивый waterfall без владельца качества не предотвращает инциденты.

Приватность трасс

Трассы могут содержать документы, персональные данные, секреты и аргументы инструментов. Примените:

редактирование до экспорта;
allowlist записываемых полей;
разные sampling rules для обычных и рискованных сценариев;
шифрование и ролевой доступ;
короткий срок хранения полного payload;
отдельное долговременное хранение обезличенных метрик;
аудит чтения и экспорта трасс.

Сэмплирование ошибок и policy-событий обычно выше обычного трафика, но точные доли определяются риском и бюджетом. Не отправляйте чувствительный trace внешнему judge без отдельной проверки маршрута данных.

План внедрения

Неделя 1: один процесс и одна трасса

Зафиксируйте текущие показатели, источники данных, ограничения и критерий приёмки. Протяните trace ID через retrieval, LLM и tool.

Следующий этап: сервисные панели

Добавьте запросы, ошибки, p95, токены, стоимость и fallback по версии и сценарию. Проверьте пропуск трасс и лимиты хранения.

Затем: качество

Соберите regression-набор из типовых и аварийных случаев. Подключите детерминированные scorers, экспертную разметку и только потом откалиброванный judge.

Наконец: алерты и runbook

Назначьте владельцев, протестируйте отказ провайдера, плохой retrieval, runaway loop и запрещённый tool. Каждый инцидент должен обогащать eval-набор.

FAQ

Чем мониторинг LLM отличается от обычного APM?

APM показывает сервисы, ошибки и задержку. LLM observability добавляет prompts/versions, model usage, retrieval, tool calls, многошаговую трассу, feedback и оценки качества. Обычно она строится поверх существующего tracing, а не заменяет его.

Нужно ли логировать промпты и ответы полностью?

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

Какие метрики LLM самые важные?

Для эксплуатации — error rate, p95 latency, токены и стоимость по сценарию. Для продукта — доля принятого результата, критические ошибки и эскалации. Для агента — успешное конечное состояние, tool failures и превышение лимитов.

Можно ли доверять LLM-judge?

Только после калибровки на экспертной разметке. Judge полезен для выборочного масштабирования контроля, но его собственные ошибки, версия и дрейф должны измеряться.

Что делать, если качество падает без роста ошибок API?

Сегментируйте traces по версии модели, промпта, индекса, маршрута и типу запроса. Проверьте retrieval и tool results, затем воспроизведите случаи на regression-наборе.

Как AI рассвет настраивает наблюдаемость ИИ

AI рассвет начинает с одного процесса: фиксирует его текущие показатели, источники данных, ограничения и критерий приёмки. Затем команда может:

спроектировать схему traces и метрик для LLM, RAG и инструментов агента;
подключить мониторинг токенов, стоимости, задержек, ошибок и маршрутизации;
собрать eval-набор, детерминированные проверки и контур экспертной обратной связи;
настроить алерты, runbook, отказные тесты и передачу эксплуатационных регламентов.

Обсудить задачу

Итог

Мониторинг LLM и ИИ-агентов работает, когда соединяет три картины: доступность сервиса, полную траекторию выполнения и качество бизнес-результата. Токены и latency важны, но сами по себе не покажут неверный документ RAG или опасный повтор инструмента.

Начните с одного процесса и сквозного trace ID. Затем добавьте панели, regression-набор и владельцев алертов. Инструмент можно заменить; версионированная схема данных, критерии качества и цикл «инцидент → новый eval» остаются основой.