Как обновлять ИИ-агента клиентского сервиса и проверять, что он стал лучше

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

Если смотреть только на среднее, команда принимает решение по самой частой и простой части потока. Редкие, но дорогие диалоги остаются в тени. Именно они чаще всего дают повторные обращения, ручную работу второй линии и потерю доверия.

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

До выкладки новой версии фиксируют не модель и не формулировку промпта, а контур проверки.

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

Без этого каталога сравнение версий превращается в спор о среднем числе. С ним команда видит, какой именно слой сервиса задет обновлением.

Рабочий способ — не выключать старую версию сразу, а пустить новую на долю обращений. Обе версии должны получать сопоставимый поток: те же каналы, те же часы, те же типы клиентов.

Для каждой версии считают не одну цифру, а набор:

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

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

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

Сложные диалоги занимают меньшую долю, но стоят дороже. Если их оценка падает, среднее может остаться почти тем же: плюс на простых случаях перекрывает минус на сложных. Руководитель видит «плюс 2 процента» и утверждает релиз, который ухудшил как раз те разговоры, из-за которых клиент уходит или пишет жалобу.

Поэтому решение принимают по разрезу, а не по одной строке отчета. Сначала смотрят критичные типы, затем общую картину.

Не каждый релиз нужно принимать или откатывать целиком.

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

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

• Результаты одной компании нельзя переносить как готовый норматив. Важны типы диалогов, а не чужая средняя цифра.
• Короткая проверка не ловит сезонные и редкие случаи.
• Оценка «решил / не решил» зависит от того, кто размечает диалоги и какой исход считается допустимым.
• Если агент меняет и тексты, и доступ к системам одновременно, нельзя понять, что именно дало эффект.
• Исследование Nubank, представленное на KDD 2026 (arxiv 2606.08867v1), показывает сам эффект маскировки на живом сервисе. Оно не задает универсальный порог, после которого релиз можно считать успешным.

• [ ] Типы диалогов описаны и отделены от общей кучи обращений.
• [ ] Для каждого типа зафиксирован допустимый исход.
• [ ] Есть контрольные сложные случаи, не только типовые.
• [ ] Старая версия остается доступной для сравнения.
• [ ] Новая версия получает сопоставимый поток, а не только удобные диалоги.
• [ ] Отчет показывает разрез по типам, а не одну среднюю оценку.
• [ ] Правило отката согласовано заранее, а не после спора о цифрах.
• [ ] Команда готова оставить обновление только на части сценариев.

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

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