AI‑агенты в проде: как оценивать качество, стоимость и стабильность

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

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

Почему качество агентов сложно измерять

С обычными ML‑моделями и алгоритмами всё понятно. Мы можем сравнить предсказание с эталоном и получить интерпретируемую оценку.

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

Более того, один и тот же запрос пользователя не гарантирует одинакового поведения ^[1]. Агент может выбрать разную траекторию действий, вызвать другой инструмент, сделать шаги в другом порядке или по‑разному интерпретировать один и тот же контекст. При этом итоговый ответ может быть одинаковым, а стоимость и время выполнения разными. На проде такая вариативность быстро становится источником риска: сегодня агент решил задачу, завтра на похожем запросе ушёл в неверную ветку.

Есть ещё одна сложность, финальный ответ от агента может выглядеть правдоподобно, но внутри цепочки произошла ошибка ^[2]. Например, а этапе извлечения (retrieval) система нашла нерелевантный документ, API вернул неполные данные, база знаний оказалась устаревшей, парсер некорректно обработал ответ инструмента. Агент может не заметить проблему и продолжить рассуждать так, будто всё в порядке. В результате пользователь получает уверенный, хорошо сформулированный, но неправильный ответ.

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

Три базовые метрики: Latency, Cost, Error Rate 

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

Но в проде есть более базовый слой. Агент должен быть не только умным, но и пригодным к эксплуатации. Если он отвечает слишком долго, стоит дорого или часто падает, то пользовательский опыт ^[3] и бизнес‑эффект будут плохими даже при хорошем содержании ответов. Поэтому я начну с трёх базовых метрик: Latency, Cost и Error Rate, которые полезно измерять почти для любого агента. Они формируют фундамент для оценки скорости отклика, экономической эффективности и стабильности системы.

• Latency — сколько времени требуется агенту для ответа;

• Cost — сколько стоит один запрос / сессия / успешно решенная задача;

• Error Rate — как часто агент ошибается или не доводит задачу до успешного результата.

На практике агент — это почти всегда trade‑off между этими тремя метриками. Можно сделать агента более качественным, добавив больше шагов, самопроверки, RAG, дополнительные тулы. Но тогда вырастут Latency и Cost. Можно сделать быстрее и дешевле, но может пострадать качество. Поэтому задача не просто «сделать умного агента», а найти баланс: достаточное качество при приемлемой стоимости и скорости.

Подробнее о каждой из метрик далее. 

Latency 

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

Agent Latency = response_finished_at — user_request_received_at

Но для агентов среднее Latency часто обманчиво, потому что агент может отвечать за 5 секунд, но в 10% случаев уходить в 40 секунд из‑за перезапусков, долгих вызовов тулов или лишних шагов и это сильно портит клиентский опыт. Лучше смотреть распределения и квантили:

• p50 latency — типичное время ответа;

• p95 latency — плохие, но не редкие случаи;

• p99 latency — хвосты, где пользователю уже совсем больно.

Если p95 или p99 начинают расти, важно не пытаться «ускорить агента в целом», а сначала найти конкретный источник длинного хвоста. В этом случае полезно раскладывать Latency на более детальные компоненты, потому что итоговое время складывается не только из LLM‑вызова. Чтобы понимать, на каком этапе агент застревает, полезно анализировать трейсы и мониторить время исполнения составляющих компонент:

• LLM latency — время вызова модели;

• Tool latency — время вызова внешних инструментов/API;

• Retrieval latency — время поиска по базе знаний/RAG;

• Orchestration overhead — время на маршрутизацию, обработку состояний, парсинг, валидацию;

• Time to first token / first response — время до первого видимого ответа, если используется streaming;

• Time to resolution — время до фактического решения задачи, если агент не просто отвечает, а выполняет действие.

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

Cost 

Cost агента одна из самых важных и при этом часто недооценённых метрик. Кажется, что cost — это просто стоимость токенов. Но на проде агент почти никогда не ограничивается одним вызовом модели. Он может планировать, вызывать инструменты, ходить в RAG, делать повторные запросы, перепроверять себя и генерировать финальный ответ. Поэтому итоговая стоимость складывается из нескольких слоёв:

Cost = Inference cost + Infrastructure cost + Hidden costs

Inference cost

Inference cost складываются из cтоимости обработки запроса агента — это сумма стоимости всех LLM‑вызовов, которые понадобились для обработки запроса. В упрощённом виде можно представить так:

Inference cost = tokens × price × steps

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

• Steps per request — сколько шагов делает агент на один запрос;

• Tokens per request — сколько токенов тратится на запрос;

• Tokens per successful task — сколько токенов нужно, чтобы успешно решить задачу.

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

Infrastructure cost

Не стоит забывать ^[5] и про затраты на инфраструктуру. Агенту нужны векторные базы, хранение документов, пайплайны обновления знаний, backend для инструментов, очереди, мониторинг, логирование, compute для обработки данных. Если агент работает с RAG, нужно учитывать не только сам модуль поиска и извлечения (retrieval), но и индексацию, хранение эмбеддингов, обновление базы знаний и поддержку качества поиска.

Hidden costs

В реальном продукте агент редко живёт без сопровождения. Нужно разбирать ошибки, улучшать промпты, поддерживать инструменты, проверять спорные ответы, доразмечать данные, реагировать ^[6] на инциденты и иногда подключать человека для верификации.

CPS и CPR

Сами по себе затраты нужно контролировать, но они не отвечают на главный бизнес вопрос: сколько стоит полезный результат для пользователя. Стоимость токенов и отдельных LLM‑вызовов важна для диагностики, но бизнесу чаще нужны более приземлённые метрики, которые проще интерпретировать и оптимизировать. Поэтому Costs масштабируются на количество сессий и получаются метрики CPS (Cost per Session) и CPR (Cost per Successful Resolution).

CPS =  (Inference cost + Infrastructure cost + Hidden costs) / number_of_sessions — сколько стоит одна пользовательская сессия.

CPR = CPS/ success_rate — cколько стоит один успешно решенный запрос пользователя.

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

Error Rate

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

Технические ошибки

На первом уровне стоит смотреть на технические ошибки. Это превышения тайм‑аутов, ошибка API, недоступность инструмента, ошибка парсинга, превышение лимита шагов, падение оркестратора и другие инфраструктурные сбои.

На проде такие ошибки должны быть ниже заранее заданного трешхолда. Если агент часто выходит за тайм‑ауты, ловит исключения или падает на вызовах инструментов, то пользовательский опыт будет плохим независимо от того, насколько хорошо спроектирована логика ^[7] агента. Но техническая стабильность сама по себе ещё не означает хорошее качество. Агент может ни разу не упасть, но при этом регулярно ошибаться по смыслу.

Ошибки в логике агента

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

Измерять такие ошибки можно через анализ трейсов. Для каждого запроса стоит сохранять не только финальный ответ, но и промежуточные шаги агента: как он понял запрос, какой план построил, какие инструменты выбрал, какие данные получил и какие выводы сделал. После этого трейс можно оценивать асессорами или LLM‑as‑a‑judge по заранее заданным критериям.

Ошибки в ответе

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

Считать такие ошибки можно через разметку ответов. Обычно берётся выборка диалогов или запросов, для каждого ответа задаются критерии качества, а затем ответ оценивается человеком, LLM‑as‑a‑judge или комбинацией этих подходов. Например, можно проверять, ответил ли агент на вопрос, использовал ли он только доступные источники, нет ли противоречий с контекстом, не нарушены ли инструкции, достаточно ли полный и безопасный ответ. Тогда можно видеть не только общий Answer Error Rate, но и понимать, какой тип ошибок растёт.

Критичность ошибок

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

• Minor errors — незначительные ошибки, которые не мешают решить задачу;

• Major errors — ошибки, из‑за которых пользователь получил неправильный или неполный результат;

• Critical errors — ошибки с финансовым, юридическим, безопасностным или репутационным риском.

Дополнительные разрезы для анализа

Error Rate важно смотреть не только в среднем, но и в разрезах:

• по типу задачи;

• по версии промпта;

• по модели;

• по инструменту;

• по источнику данных;

• по длине диалога;

• по количеству шагов;

• по сегменту пользователей.

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

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

Метрики стабильности

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

• pass@k — вероятность успешного решения задачи хотя бы в одной из k независимых попыток

• pass^k — вероятность успешного решения задачи во всех k независимых попытках

Для поведения агента на проде часто важнее не только то, может ли агент решить задачу за несколько попыток, а насколько надёжно он делает это с первого раза. Поэтому pass@k стоит смотреть вместе с pass@1 — вероятность успешного решения с первой попытки.

Если pass@k высокий, а pass@1 низкий, это значит, что агент в принципе способен решить задачу, но делает это нестабильно. А в продукте чаще важен именно pass@1, потому что реальный пользователь обычно не запускает один и тот же запрос 10 раз.

Offline vs Online‑оценка 

Есть ещё один важный момент, у агентов часто сильно отличаются результаты offline и online‑оценки. В offline можно собрать датасет‑корзинку, прогнать сценарии, сравнить ответы, посчитать метрики. Это полезно для замеров контроля качества еще до выкати на прод, но то, что агент может решить тестовую задачу не значит, что агент решит реальную задачу пользователя.

Все потому что реальные пользователи:

• формулируют задачи не так, как в тестовом наборе;

• дают неполный контекст;

• меняют цель по ходу диалога;

• используют продукт не так, как мы ожидали.

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

Именно поэтому offline и online eval лучше рассматривать не как альтернативы, а как два разных уровня оценки. Offline отвечает на вопрос «не сломали ли мы качество на известных сценариях», а online «работает ли агент стабильно и полезно в реальных условиях».

Итоги

В проде AI‑агента уже нельзя оценивать по одному красивому примеру из демо. В реальности это система из нескольких шагов, которая должна раз за разом понимать, что хочет пользователь, выбирать подходящий план, обращаться к нужным инструментам, корректно работать с данными и доводить задачу до результата. Поэтому качество агента нельзя оценивать одной метрикой. Нужен базовый набор production‑метрик, который позволяет смотреть на систему с разных сторон: насколько быстро агент отвечает, сколько стоит его работа, как часто он ошибается и насколько стабильно доводит задачи до успешного результата.