Постоянный контроль качества AI-агента в продакшене: Monitors, Scorecards и закрытый цикл улучшения

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

Короткий ответ: Intercom внедрил Monitors и Custom Scorecards — они выбирают рисковые диалоги (финансовая уязвимость клиента, зацикливание агента, эскалации), оценивают их по кастомным карточкам качества (часть — авто‑LLM, часть — человек) и кладут проваленные случаи в Review Queue, где они становятся задачами на обновление контента или правил.

Короткий ответ: по практике Unlim Group, компании, которые не настраивают такой контур после запуска, через 2–3 месяца теряют контроль над качеством: дрифт контента, незамеченные регрессы и отсутствие единого показателя качества делают поддержку «чёрным ящиком».

Почему пост‑запусковый контроль — это не опция, а требование выживания

Fin у Intercom обрабатывает около 2 млн клиентских запросов в неделю при среднем resolution rate 76 %. На таком объёме любая мелочь — устаревшая статья в базе знаний, неточная формулировка в Procedure, смена тона после правки Guidance — масштабируется в тысячи плохих опытов за день. Старые инструменты (CSAT‑опросы, случайная выборка 50 диалогов в месяц) здесь не работают: они медленные, субъективные и не покрывают хвост распределения, где скрываются самые дорогие ошибки.

Intercom сформулировал это как «Fin Flywheel»: Train → Test → Deploy → Analyze. Analyze — единственный шаг, который работает непрерывно в продакшене и кормит остальные три. Без него volante останавливается.

Архитектура непрерывного QA: три компонента

1. Monitors — «что проверяем и как часто»

Monitors — это правила отбора диалогов на ревью. В отличие от случайной выборки, они таргетируют сигналы риска:

• клиент проявил признаки финансовой уязвимости;
• агент дал один и тот же ответ дважды подряд без разрешения (loop detection);
• эскалация на человека произошла позже заданного порога;
• диалог касается регулируемой темы (GDPR, финпродукты, медданные);
• пользовательский запрос на естественном языке: «клиент жаловался на нечестное списание, но агент просто переслал ссылку на политику».

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

2. Custom Scorecards — «как измеряем качество»

Готовые метрики (CSAT, resolution rate) говорят «как клиент почувствовал», но не «сделал ли агент правильно по нашим стандартам». Custom Scorecards позволяют описать «хорошо» на своём языке:

• критерий: «Procedure «Возврат средств» запущена, когда клиент просит возврат внутри 14 дней» — авто‑оценка LLM‑judge;
• критерий: «Тон ответа соответствует бренд‑гайдлайлу: эмпатия, без жаргона, активный залог» — авто‑оценка;
• критерий: «Агент не обещал то, чего нет в политике» — ревью человеком (критический флаг: провал = fail всего скора);
• критерий: «Все факты подтверждены актуальной статьей KB» — авто‑проверка RAG‑цитаты.

Веса критериев настраиваются; можно пометить критерий как critical — тогда любой провал обнуляет общий балл. Итог — единый quality score от 0 до 100, сопоставимый во времени и между командами.

3. Review Queue — «от флага к фиксу»

Диалоги, провалившие Scorecard, попадают в Review Queue со статусами: Not reviewed → Reviewed → Needs a fix → Fix complete. Ревьюер видит транскрипт, событийный лог, сработавшие критерии и может сразу:

• создать задачу на обновление статьи KB;
• поправить Procedure или Guidance;
• добавить новый Simulation в Eval‑сьют для регрессионного теста.

Ничего не уходит в Slack/Таблицы/Jira — цикл закрыт внутри одной системы.

Как это выглядит в numbers (данные Intercom, 2026)

• Fin: ~8 000 клиентов, ~2 млн решенных запросов в неделю, resolution rate 76 % (декабрь 2025).
• Monitors позволяют перейти от случайной выборки 50–100 диалогов/мес к целевому охвату 100 % рисковых кейсов и стабильному бенчмарку на остальных.
• Custom Scorecards: каждый критерий может быть auto (LLM‑judge) или human; поддерживаются critical‑флаги.
• Reporting связывает quality score с CX Score, resolution rate, escalation rate — делает QA непрерывным сигналом, а не разовой акцией.

Практический чек‑лист внедрения для B2B‑команды (РФ/СНГ)

1. Определите 3–5 рисковых сценариев, которые стоят дороже всего: неверное обещание скидки, утечка ПДн, пропуск эскалации VIP‑клиента, халлюцинация цены, несовпадение с договором.
2. Настройте Monitors под эти сценарии: фильтры по тегам CRM, ключевым словам, каналу, сегменту клиента. Добавьте базовый стратифицированный сэмпл (5 % от объёма) для тренда.
3. Соберите Custom Scorecard из 8–12 критериев: 60 % auto (фактологичность, наличие Procedure, тональность, цитируемость KB), 40 % human (юридическая точность, эмпатия, исключения). Пометьте 2–3 критерия как critical.
4. Запустите Review Queue с SLA: первый ревью — 24 ч, фикс в KB/Procedure — 48 ч, повторный прогон Eval — до следующего релиза.
5. Подключите Reporting к еженедельному дашборду руководителя поддержки: quality score тренд, топ‑3 провальных критерия, конверсия «провал → фикс → прохождение Eval».
6. Расширьте на человеческую команду (Human agent QA — на roadmap Intercom) — единый скоринг для AI и людей убирает двойные стандарты.

Таблица: Сравнение подходов к QA AI‑агента

Подход	Охват	Скорость обратной связи	Масштабируемость	Действенность (провал→фикс)
CSAT‑опросы	~5–10 % ответивших	дни–недели	хорошо	низкая (нет контекста диалога)
Случайная выборка QA‑специалистом	50–200 диалогов/мес	недели	плохо (ручной труд)	средняя (зависит от процесса)
Monitors + Custom Scorecards + Review Queue	100 % рисковых + выборка базы	минуты–часы (auto‑оценка)	отлично (авто + человек)	высокая (встроенный workflow)

Частые ошибки и как их избежать

Ошибка 1: «Сначала запустим, потом придумаем QA»

Дрифт начинается с первого дня. Настройте хотя бы один Monitor и минимальный Scorecard (5 критериев) до гоу‑лайва. Добавьте остальное итеративно.

Ошибка 2: «Авто‑оценка LLM‑judge заменит людей полностью»

LLM‑judge отлично ловит фактологию, структуру, тональность. Но юрид. точность, контекст исключений, эмпатию — пока лучше валидирует человек. Делайте гибрид.

Ошибка 3: «Quality score — для отчёта руководству»

Если дашборд не ведёт к задаче «обновить статью KB #123» или «добавить Simulation в Eval refund_policy» — он бесполезен. Настройте алерты на падение score ниже порога и авто‑создание тикетов в трекере контента.

Внутренние ссылки для углубления

• Как тестировать ИИ-агентов перед продом: Eval-driven подход от Intercom к российским реалиям — про pre‑prod симуляции и Evals.
• Как измерять клиентский опыт при масштабировании AI-агентов: оценка каждого диалога — про CX Score и метрики восприятия.

Резюме: постройте свой Fin Flywheel

AI‑агент в продакшене — это не статичный артефакт, а живой процесс. Monitors выбирают правильные разговоры, Custom Scorecards переводят ваши стандарты в измеримые критерии, Review Queue превращает провалы в фиксы, Reporting делает качество управляемым сигналом. Вместе они закрывают цикл Analyze → Train → Test → Deploy. Начните с трёх мониторов и пяти критериев сегодня — через месяц у вас будет основа, которой нет у 90 % конкурентов на рынке РФ/СНГ.