Метрики AI-ассистента в production

Пять групп целей

В докладе AI-команды одного крупного банка о запуске ассистента цели заданы так: безопасность — 100 %, полезность — 90 %, плюс техническое качество, стоимость LLM на одного пользователя и like ratio (доля оценок «нравится» среди всех оценок). Это хороший каркас, потому что он сразу говорит, что метрик несколько и у каждой своя планка.

Правило выбора измерителя из модуля про evaluation: чёткое правило — код; размытый смысл — judge-модель; качество самого judge — люди.

Почему безопасность 100 %, а польза 90 %

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

Но «100 %» здесь значит конкретное: 100 % на наборе проверки безопасности — подобранных случаях, где ассистент обязан отказать или ответить строго по правилам. Это не обещание нуля в production. Правило трёх: 0 нарушений в 300 разных попытках даёт с уверенностью 95 % только «частота ниже ~1 %», а для «ниже 0,1 %» нужно 3 000. Значит, «никогда» обеспечивает дизайн — права tools, подтверждения, минимум данных в ответе, — а набор проверяет, что дизайн работает, и ловит регрессии.

Набор безопасности и golden set — разные вещи

Golden set (эталонный набор) — представительная выборка настоящих задач с эталонными ответами: «сколько стоит перевод в евро», «как перевыпустить карту». Он отвечает на вопрос «полезен ли ассистент на обычном трафике» и даёт те самые 90 %.

Набор проверки безопасности — состязательный: попытки prompt injection, вопросы о чужих данных, провокации на запрещённые темы, слова из стоп-списков. Он намеренно непредставителен: таких запросов в трафике мало, а проверять их нужно все. В докладе он пополняется из инцидентов: каждый случай из production, где что-то пошло не так, становится новой строкой набора.

Оба набора — ворота в CI (урок a7-3): изменение не выходит, если безопасность ниже 100 % на наборе или польза упала ниже порога. И оба считают по языкам и сегментам.

Как мерить полезность, чтобы 90 % что-то значили

Полезность — размытое понятие, поэтому её мерит judge-модель по рубрике. Рубрика разбивает «полезно» на проверяемые вопросы: ответил ли ассистент именно на заданный вопрос, совпадают ли факты с документами, может ли клиент сделать следующий шаг. Каждый вопрос — да или нет, без шкалы 1–10: бинарные оценки judge ставит стабильнее.

Прежде чем верить judge, его сверяют с людьми: двое людей размечают 100–200 ответов, judge размечает те же, и смотрят согласие (κ) и recall на плохих ответах. Если judge расходится с людьми, его 90 % ничего не стоят.

И разброс. На golden set из 200 задач при доле 90 % стандартная ошибка равна √(0,9 × 0,1 / 200) ≈ 2,1 пункта, а 95-процентный интервал — около ±4 пунктов. Значит, 88 % и 91 % на двух версиях — не разница. Версии сравнивают на одних и тех же задачах и смотрят, какие задачи поменяли результат.

Online-метрики: что видно только после запуска

Offline-наборы не видят настоящих клиентов. После выпуска добавляются: - containment (доля решённых без человека); - escalation rate (доля передач оператору); - repeat contact за 48 часов — клиент вернулся с тем же вопросом, значит, первый ответ не помог; - жалобы; - ручная выборка разговоров раз в неделю.

Каждую метрику держат в паре с той, что ловит её подделку. Containment легко поднять, если ассистент просто не отпускает к оператору. Поэтому рядом стоят repeat contact и жалобы. Like ratio страдает от смещения выборки: оценку ставит малая и нетипичная часть пользователей, чаще всего очень довольные или очень злые. Он годится как сигнал тренда, но не как мерило полезности.

Пример с числами

За неделю 10 000 разговоров. Без оператора закрыто 7 200 — containment 72 %. Но 900 из этих 7 200 клиентов вернулись с тем же вопросом в течение 48 часов. Честный containment: (7 200 − 900) / 10 000 = 63 %. Разница в 9 пунктов — разговоры, которые выглядели решёнными, но не были.

Стоимость на пользователя (цены — допущение для примера: $1 за 1 млн input tokens и $5 за 1 млн output tokens). Пользователь в месяц ведёт 3 разговора по 6 реплик; каждая реплика — 4 000 tokens на входе (история, документы RAG) и 300 на выходе. Input: 3 × 6 × 4 000 = 72 000 tokens → $0,072. Output: 3 × 6 × 300 = 5 400 tokens → $0,027. Итого около $0,10 на пользователя в месяц. Видно, что дорогой здесь вход, а не выход: сокращение контекста RAG с 4 000 до 2 000 tokens сэкономит больше, чем сокращение ответов вдвое. Реальные цены берутся со страницы поставщика в день расчёта.

Как собрать это в один dashboard

Верхняя строка — цели с планкой и текущим значением: безопасность на наборе, польза на golden set, честный containment, p95 latency, $ на пользователя. Под каждой — срез по языку, каналу и версии выпуска. Alerts (оповещения) — на нарушения безопасности (любое) и на резкие сдвиги остальных метрик относительно прошлой недели. А раз в неделю — чтение разговоров людьми: метрики говорят, что изменилось, разговоры объясняют почему.