KPI для AI-агентов: где ломается контроль качества
Агент запущен в рабочий контур: отвечает на обращения, часть заявок закрывает без участия человека. Приёмка при этом обычно исчерпывается десятком вопросов — их задавали до запуска, ответы устроили, и дальше качество никто не измеряет. Реальный поток запросов отличается от тестового, поэтому первый сигнал о проблеме приходит от недовольных пользователей, а не от системы.
Деградация ответов почти никогда не выглядит как поломка. Обновили системную инструкцию под новый сценарий, расширили базу знаний, сменили модель под нагрузку — и на части запросов агент начинает уверенно отвечать без опоры на источник. Каждое изменение по отдельности выглядит безобидно, а накопленный эффект виден только в сравнении: тем же вопросом, заданным до и после.
KPI для AI-агентов работают, когда это набор измеряемых величин, а не один агрегат «довольны или нет». Доля обращений, закрытых без передачи человеку; доля ответов с подтверждённым источником; доля повторных обращений по тому же вопросу; время до полезного ответа; доля диалогов, где пользователь переспросил. Эти величины снимаются двумя способами — на регулярном прогоне эталонного набора запросов и на живой выборке из диалогов.
Оценка работы агента без эталонного набора упирается в ручную разметку, а без живой выборки — в самообман: тестовые вопросы перестают отражать реальные формулировки. Разбираем, как собрать обе части, связать метрики с изменениями конфигурации и получить контроль качества агентов, при котором проблемы внедрения агентов ловятся до жалоб, а решение откатывается по конкретному показателю, а не по ощущению.
Что даёт система метрик для AI-агентов в работе
Метрики AI-агентов начинают работать, когда их считают на каждом диалоге, а не по факту жалобы. Базовая величина — доля корректных ответов: фиксированный набор реальных обращений с разметкой прогоняется на каждой смене промптов, инструментов и модели, результат сравнивается с предыдущей версией. Расхождение выше порога — обновление не уходит в боевой контур, а возвращается на доработку.
Второй контур — время реакции на отклонение. Пока качество отслеживают глазами, между просадкой и её обнаружением проходят сутки, и всё это время агент уверенно отвечает неправильно. Метрика переводит срок в минуты: падение доли корректных ответов или рост отказов вызова инструментов поднимает сигнал сразу, дежурный открывает конкретный диалог и видит причину, а не только факт.
Снижение эскалаций — интегральный показатель, поэтому мы разносим их по классам: агент не нашёл данные, неверно определил намерение, вышел за рамки регламента, сорвал срок ответа. У каждого класса своя метрика и свой владелец в команде заказчика, поэтому устраняется причина, а не отдельный случай из очереди.
Собирается это на штатной телеметрии: события диалога, вызовы инструментов, задержки и исходы попадают в общий контур наблюдаемости, панели в Grafana обновляются без ручных выгрузок. Просадка становится видна до того, как о ней напишет клиент, а откат версии конфигурации занимает минуты.
Подходы к измерению: разбор диалогов и автопроверки
Оценивать агента одной цифрой бессмысленно: методы различаются ценой, охватом и тем, какие ошибки вообще попадают в поле зрения. Ниже — четыре рабочие опции и их слепые зоны: от полностью машинных прогонов до ручного разбора.
| Метод | Когда подходит | Где упирается в ограничения |
|---|---|---|
| Автопроверки по правилам | Формат ответа, обязательные шаги, корректность вызова внутренних функций | Формально верный, но бесполезный ответ проходит как успех |
| Автопроверка моделью-арбитром по рубрике | Массовые прогоны, регресс после каждой правки инструкций агента | Наследует слепые зоны модели, требует калибровки на людях |
| Эталонные наборы диалогов | Сравнение версий агента между собой, защита от деградации | Устаревают, покрывают только известные сценарии |
| Экспертный разбор диалогов | Спорные кейсы, запуск новой линии, разбор отказов | Дорог по времени экспертов, малая выборка |
Методы не конкурируют, а делят роли. Эталонный набор фиксируем как регресс-контур: правка инструкций прогоняется по нему, и видно, что именно стало хуже. Автопроверки идут на каждую реплику потока, экспертный разбор — по выборке из расхождений и отказов.
Связка держится на калибровке: пока оценка арбитра и оценка эксперта расходятся в пределах нескольких процентов, машинные прогоны можно считать метрикой. Как только расхождение растёт, рубрику пересматриваем — иначе KPI для агентов начинает измерять не качество ответов, а их гладкость.
Как мы выстраиваем KPI для AI-агентов: этапы работ
KPI для AI-агентов начинается не с графиков, а с аудита: пока не описан каждый сценарий и не ясно, где именно агент ошибается, любая цифра в отчёте спорна. Поэтому первые дни работы уходят на разбор потока обращений и определение точек, где качество можно измерить объективно.
- Аудит сценариев. Разбираем все пути, по которым агент ведёт диалог: типовые запросы, редкие ветки, передачи оператору. По каждому фиксируем, что считаем успехом, а что сбоем.
- Сбор данных. Настраиваем логирование так, чтобы сохранялись запрос, ответ агента, использованные источники и действие пользователя. Без этого пороги будет не на чем проверять.
- Согласование метрик. Сводим технические показатели с целями бизнеса: доля обращений, закрытых без оператора, точность ответа по базе знаний, время до ответа, доля отказов.
- Настройка порогов. Для каждой метрики задаём не одно значение, а коридор: норма, предупреждение, аварийный уровень. Границы считаем по накопленной статистике, а не на глаз.
- Проверка метрик. Прогоняем систему на отложенной выборке и намеренно ломаем сценарии: если метрика этого не замечает, она не работает.
- Внедрение и передача. Выводим показатели в общий мониторинг, описываем регламент реакции на отклонения и учим команду заказчика менять пороги самостоятельно.
После передачи регламент живёт без нас — новые сценарии и правки порогов команда добавляет сама.
Что заказчик получает на руки по итогам проекта
Проект по метрикам для AI-сотрудников заканчивается не презентацией, а рабочим комплектом: каждый артефакт команда заказчика использует без нашего участия. Передаём всё с указанием владельца, версии и порядка изменений — чтобы через полгода никто не восстанавливал логику метрики по переписке.
- Каталог метрик. По каждой: что именно измеряет, на каком уровне считается (отдельный диалог, сценарий, исполнитель), целевой коридор и что считается отклонением.
- Схемы расчёта метрик. Формулы, источники данных, окно агрегации, правила обработки пропусков и повторных обращений. Одна и та же метрика даёт одинаковый результат при пересчёте на другом периоде.
- Панель мониторинга. Срезы по сценариям и исполнителям, динамика во времени и отдельный блок отклонений — дежурный видит проблему раньше, чем её замечает пользователь.
- Политики доступа к данным. Кто и на каком основании видит диалоги, кто — только агрегаты, где обезличивание при выгрузке и как ведётся журнал обращений.
- Регламенты разбора. Пороговые значения, при которых запускается разбор, ответственные роли, сроки реакции и порядок фиксации вывода по инциденту.
- Документация и передача. Инструкция по добавлению новой метрики, схема её связи с бизнес-показателями подразделения и запись обучающей сессии для ваших инженеров и операторов.
Такой комплект переживает смену подрядчика и рост числа AI-сотрудников: метрики добавляются по описанной процедуре, а не заново придумываются под каждый новый сценарий.
Кейс: качество ответов агента до и после внедрения
Точка отсчёта
Агент-консультант отвечал неточно примерно на 4 из 10 обращений: пропускал условие из базы знаний или подставлял устаревшие данные об услуге. Качество при этом измерялось выборочно — 30 диалогов в неделю вручную, а разбор одного отклонения занимал в среднем 40 минут: журнал диалога лежал отдельно от вызовов инструментов и фрагментов, которые агент вытащил из базы.
Повторные обращения по той же теме составляли 23% — клиент возвращался, потому что первый ответ был формально верным, но задачу не закрывал.
Что изменили
Ввели схему разметки ответов: корректный, неполный, выдуманный факт, отказ. Журнал вызовов сшили с журналом диалога в Langfuse — на одном экране видно всю цепочку: запрос, извлечённые фрагменты, вызванный инструмент, финальный ответ. Разбор отклонения перестал быть археологией по разрозненным файлам.
Собрали эталонный набор из 240 вопросов с ожидаемыми ответами и повесили прогон на каждый релиз инструкций агента: падение доли корректных ответов ниже порога блокирует выкат.
Доля корректных ответов выросла с 61% до 89%, время разбора отклонения сократилось с 40 до 8 минут, повторные обращения по той же теме упали с 23% до 9%. Метрики стоят в панели мониторинга рядом с числом обращений — просадку точности после правки базы знаний видно в тот же день, а не через месяц по жалобам.
Чем метрики качества отличаются от метрик нагрузки
Метрики нагрузки считают то, что легко снять с инфраструктуры: число обращений, время до первого токена, полную задержку ответа, долю технических ошибок, объём потреблённых токенов. Они отвечают на вопрос «сервис жив и справляется с потоком», но ничего не говорят о том, решил ли агент задачу пользователя. Ровный график задержек одинаково хорошо выглядит и у работающего помощника, и у вежливого автоответчика, который пересказывает инструкцию.
Метрики качества измеряют результат диалога, а не его обслуживание. Ключевые из них: доля сценариев, закрытых без передачи человеку; доля повторных обращений по той же теме внутри одной сессии; доля ответов, подкреплённых источником, а не сгенерированных по памяти; доля диалогов, где пользователь переформулировал запрос дважды и более — это прямой признак, что полезность ответа низкая.
Расхождение между двумя наборами проявляется быстро. Ускоряем генерацию, сокращая цепочку проверок, — задержка падает вдвое, а доля эскалаций на оператора растёт, потому что агент чаще отвечает уверенно и неверно. Метрики нагрузки при этом выглядят лучше, чем до изменений, и решение легко принять ошибочное.
Считать качество можно только на размеченной выборке реальных диалогов: эталонные наборы с ожидаемым исходом, периодическая ручная разметка, трассировка шагов агента. У нас для этого разворачивается контур наблюдения — например, LangSmith — где каждый прогон сравнивается с предыдущим по доле решённых задач, а не по скорости.
Практический вывод простой: нагрузка — фон и условие работоспособности, качество — критерий приёмки. KPI для AI-агентов строятся на втором, иначе оптимизация уводит систему в сторону быстрых, но бесполезных ответов.
Сомнения по метрикам агентов: отвечаем по существу
Возражения по метрикам обычно одни и те же: нет эталонных ответов, журналы диалогов приходят неполными, а проверки агент проходит формально и на живых обращениях ведёт себя иначе. Ни одно из этих сомнений не отменяет измерений — оно меняет схему: где брать опору вместо эталона, что считать полнотой журнала и как отличить реальное качество от подгонки под проверку.
У нас нет эталонных ответов — с чем тогда сравнивать?
Эталон нужен только там, где ответ однозначен. Для диалоговых сценариев опора другая: рубрики оценки по критериям, парные сравнения двух версий агента между собой и разметка выборки людьми с калибровкой расхождений. Такой набор устойчивее одного «правильного» ответа и показывает движение качества от версии к версии.
Журналы диалогов неполные — оценка будет недостоверной?
Полнота журнала — сама по себе метрика. Мы фиксируем, сколько шагов сохраняется: вызовы инструментов, входные и выходные данные, факт передачи человеку. Если в записи теряются промежуточные шаги, это отдельный класс отказов — по нему видно, где пропадает контекст, и его закрывают до того, как считать показатели по задаче.
Агент формально проходит проверки — как это ловится?
Формальное прохождение — признак того, что проверки стали предсказуемыми. Поэтому часть наборов держим скрытыми, задания перемешиваем и не показываем подряд, а решение о готовности принимаем по работе на потоке реальных обращений, а не по внутренним прогонам. Расхождение между проверкой и живой работой тоже измеряем: оно показывает, где агент выучил шаблон вместо задачи.
Обсудим задачу: разберём сценарии и соберём метрики
Чтобы разбор не превратился в обмен общими соображениями, к первому разговору достаточно трёх вещей: перечня сценариев, где AI-сотрудник уже работает или должен работать, примеров его ответов за последние недели и понимания, кто в компании принимает решение «ответ верный или нет». Этого хватает, чтобы наметить KPI для AI-агентов и не угадывать вслепую.
Что разбираем на старте:
- какие сценарии закрывает агент и где проходит граница его ответственности;
- как выглядит корректный и некорректный ответ в каждом сценарии — из этого вырастает разметка;
- какие метрики уже собираются, а какие придётся добавить в логирование;
- где нужен автоматический контроль, а где выборка с ручной проверкой;
- кто со стороны заказчика подтверждает эталонные ответы и с какой частотой;
- какие ограничения по данным и доступам есть у команды агента.
После разбора возвращаемся с планом работ: перечень метрик с определениями и порогами, схема сбора данных, этапы внедрения с контрольными точками. Там же — оценка сроков по каждому этапу и состав команды: кто отвечает за разметку, кто за оценку качества, кто за доработку инструкций агента и правил отката. Опишите задачу — обсудим сценарии и вернёмся с оценкой и планом.
