Мониторинг и eval AI-агентов: как запускать в production без веры

Раздел

AI-агенты для бизнеса

Сложность

сложная

Обновлено

2026-05-20

Короткий ответ

AI-агента нельзя выпускать в production только потому, что он хорошо прошел демо. Нужны eval-наборы, traces, журнал tool calls, метрики стоимости и задержки, разбор ручных правок, алерты на опасные действия и критерий остановки. Иначе вы узнаете о проблеме из жалобы клиента или испорченных данных.

Мониторинг AI-агентов отличается от обычного backend-мониторинга. HTTP 200 не означает, что агент выбрал правильный tool, нашел верный источник, отказался без данных и не сделал лишний шаг. Наблюдаемость должна показывать семантику решения, а не только latency запроса.

Эта статья продолжает темы создания AI-агента, оценки качества RAG и выбора LangChain или LlamaIndex.

Что измерять

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

Качество:

• success rate по задачам;
• доля ручных правок;
• точность выбора tool;
• retrieval hit rate;
• доля отказов без источника;
• повторные обращения по той же теме.

Безопасность:

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

Стоимость и скорость:

• tokens per task;
• стоимость успешного результата;
• p50, p95, p99 latency;
• число шагов на задачу;
• ретраи;
• доля timeout.

Обычные метрики инфраструктуры нужны, но их недостаточно. Агент может быть быстрым и дешевым, но неверно закрывать тикеты.

Trace как источник правды

Trace должен показывать весь путь задачи: вход, выбранный сценарий, prompt, retrieval, tool calls, ответы tools, решение агента, guardrails, handoff и финальное действие. Без trace невозможно понять, где ошибка: в данных, модели, prompt, tool, правах или бизнес-правиле.

Для каждого запуска сохраняйте:

• task_id или conversation_id;
• версию prompt;
• версию модели;
• входные данные после очистки;
• найденные источники;
• tool name и аргументы;
• результат tool;
• финальный ответ;
• решение человека, если было ревью;
• стоимость и latency.

Компактный trace должен быть читаемым без просмотра всего prompt:

{
  "task_id": "support_4921",
  "scenario": "refund_request",
  "prompt_version": "support-agent-2026-05-20",
  "retrieval": {
    "top_source": "refund_policy_v4",
    "access_filter": "passed",
    "stale_source": false
  },
  "tool_calls": [
    {"name": "crm.get_ticket", "allowed": true, "latency_ms": 120},
    {"name": "billing.issue_refund", "allowed": false, "reason": "requires_human"}
  ],
  "outcome": "handoff",
  "human_reason": "money_movement",
  "cost_usd": 0.043,
  "latency_ms": 1840
}

Такой trace сразу показывает, что агент не просто “ответил”, а правильно заблокировал опасный tool. Для реализации удобно сравнить подходы из OpenAI Agents SDK tracing и LangSmith observability; если стек другой, структура trace все равно нужна.

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

Eval-набор

Eval-набор - это не таблица красивых примеров. Он должен включать реальные задачи, граничные случаи, плохие входы, отсутствующие источники, запреты, права доступа и ситуации, где нужен человек.

Для агента фиксируйте:

• вход;
• ожидаемый outcome;
• допустимые tool calls;
• запрещенные tool calls;
• нужный источник;
• критерий handoff;
• критичные ошибки;
• expected cost или лимит шагов.

Пример eval-кейса для risky tool:

Автоматические проверки можно дополнять trace grading: OpenAI описывает отдельный подход для trace grading, а agent evals стоит держать рядом с регрессионным набором из Agent evals. Для инфраструктурных метрик удобно сверять названия span/event с OpenTelemetry GenAI semantic conventions.

Запускайте eval перед изменением prompt, модели, retrieval, tools и прав. Если агент стал лучше в одном сценарии, но начал чаще вызывать опасный tool, релиз нельзя считать улучшением.

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

Production alerts

Алерты должны ловить не только падение сервиса. Для AI-агента нужны бизнес- и safety-сигналы:

• выросла доля handoff;
• выросли ручные правки;
• агент вызывает tool чаще нормы;
• увеличилась стоимость задачи;
• появились ответы без источника;
• retrieval возвращает архивные документы;
• пользователь просит человека, но агент продолжает;
• tool записи вызван без подтверждения;
• p95 latency вышла за порог.

Порог должен быть связан с процессом. Для голосового бота важна задержка и перебивания. Для RAG - источники и права. Для CRM-агента - запись, дубли и некорректные стадии.

У каждого алерта должен быть владелец и действие: отключить сценарий, перевести в режим черновиков, остановить tool, вернуть старый prompt, отправить очередь человеку.

Пример правил для первого production-этапа:

alerts:
  - name: unsafe_tool_attempt
    condition: tool.allowed == false and tool.side_effect == "write"
    action: disable_autonomous_mode
  - name: rag_source_missing
    condition: answer.has_source == false and scenario.requires_source == true
    action: route_to_human_review
  - name: latency_p95_regression
    condition: latency_p95_ms > 2500 for 15m
    action: switch_to_draft_mode

Эти правила не заменяют мониторинг сервиса, но закрывают риски, которые обычный uptime не видит.

Контроль tool calls

Tool calls - самая опасная часть агента. Ошибка текста может быть исправлена человеком, а ошибка записи может изменить CRM, создать дубль, отправить письмо или удалить данные.

Для каждого tool опишите:

• назначение;
• входную схему;
• права;
• side effects;
• нужен ли human approval;
• лимит вызовов;
• rollback или компенсацию;
• что писать в журнал.

Отдельно смотрите лишние вызовы. Если агент вызывает поиск десять раз вместо двух, проблема может быть в prompt, памяти, плохом описании tool или отсутствии лимита.

Не давайте агенту универсальный tool “выполнить запрос” или “вызвать любой API”. Tools должны быть узкими и проверяемыми.

RAG и источники

Для RAG-агента monitoring должен показывать не только ответ, но и retrieval. Важно видеть, какие chunks найдены, какие отклонены reranker, какие источники показаны пользователю, была ли свежая версия и проходили ли фильтры прав.

Минимальные RAG-метрики:

• правильный источник в top-3;
• доля ответов без источника;
• доля отказов без данных;
• устаревшие документы;
• ошибки metadata filters;
• средняя свежесть источника;
• правки ответа человеком.

Если ответ плохой, сначала выясните, нашелся ли правильный источник. Если нет, чините corpus, chunking, embeddings, filters или reranking. Prompt меняйте после этого.

Режимы запуска

Не выпускайте агента сразу в автономный режим. Используйте ступени:

1. Offline eval на исторических данных.
2. Shadow mode без влияния на пользователя.
3. Draft mode, где человек подтверждает результат.
4. Ограниченная запись для низкого риска.
5. Автономный режим только для доказанных операций.

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

Даже после автономного запуска оставьте kill switch. Иногда правильное действие - быстро выключить сценарий, а не спорить с мониторингом.

Чеклист запуска

• Есть eval-набор с реальными и плохими случаями.
• Trace показывает prompt, retrieval, tools, guardrails и handoff.
• Чувствительные данные маскируются в логах.
• Для каждого tool описаны права и side effects.
• Есть алерты на опасные действия, latency и стоимость.
• RAG-ответы проверяются по источникам и правам.
• Релизы prompt и модели проходят regression eval.
• Первые недели есть ручная разметка ошибок.
• Определены режимы shadow, draft и autonomous.
• Есть kill switch и владелец инцидентов.

FAQ

Можно ли ограничиться логами приложения?

Нет. Обычные логи редко показывают, почему агент выбрал tool, какой источник нашел и где нарушил правило. Нужны traces и evals.

Как часто запускать eval?

Перед каждым изменением prompt, модели, tools, retrieval и прав. Для активного продукта полезен ежедневный или per-release regression set.

Нужен ли LLM-судья?

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

Что считать главным KPI агента?

Стоимость успешного и безопасного результата. Просто количество автоматических ответов может расти вместе с ошибками.

Что читать дальше?

Для RAG-контроля смотрите оценку качества RAG. Для выбора архитектуры - LangChain или LlamaIndex.