Точность 95% может скрывать проблему: как проверять классификацию входящих заявок
Материал VOSHOD. Практический разбор для команд, которые распределяют обращения с помощью ИИ. Подготовлено с использованием ИИ. Примеры и числа условные, клиентские результаты не приводятся.
Сначала определите, куда должен попасть запрос
Классификация полезна тогда, когда её результат меняет следующее действие. Метки «продажи», «поддержка» и «партнёрство» имеют смысл, если за каждой закреплён маршрут. Если две категории всегда обрабатывает один сотрудник одинаковым способом, разделение может не давать практической пользы.
Опишите категории коротко: что входит, что не входит и какой пограничный пример вызывает спор. Например, вопрос о возврате после покупки относится к сопровождению клиента, даже если в тексте есть слово «купить». Запрос на оптовую цену может требовать отдельного маршрута, хотя похож на обычную заявку.
Почему общий процент вводит в заблуждение
Представим тест из 1000 сообщений: 950 обычных запросов и 50 срочных жалоб. Система, которая всегда выбирает обычный запрос, покажет 95% совпадений. При этом она пропустит каждую срочную жалобу. Высокая общая точность не отвечает на главный вопрос: замечает ли система то, что важно бизнесу.
Проверьте каждую категорию отдельно. Для срочных жалоб полезны два показателя. Полнота показывает, какую долю реальных срочных жалоб система нашла. Точность выбранной категории показывает, какая доля сообщений, помеченных срочными, действительно была срочной. Эти показатели отвечают на разные вопросы и не заменяют друг друга.
Разберите ошибки по направлениям
Составьте простую таблицу: строки содержат правильную категорию, столбцы выбранную системой. Диагональ показывает совпадения. Остальные клетки показывают конкретные путаницы: жалоба ушла в продажи, новая заявка ушла в поддержку, партнёрство попало в общий ящик.
Для каждой частой путаницы спросите, что происходит дальше. Неверный маршрут может увеличить срок ответа, вызвать лишний перевод или оставить обращение без владельца. Вес ошибки определяется последствиями, поэтому одинаковая доля промахов в двух категориях не означает одинаковый риск.
Подготовьте тест, который не подсказывает ответ
Возьмите примеры из разных каналов и периодов, убрав ненужные персональные данные. Добавьте короткие сообщения, опечатки, несколько намерений в одном тексте и обращения без ясной цели. Сохраняйте отдельную проверочную часть, которую не используете при настройке.
Если редкие обращения специально добавлены в большем количестве, это полезно для проверки защиты от ошибок. Но общий процент на такой выборке нельзя выдавать за ожидаемую точность на реальном потоке. Отдельно покажите результаты по категориям и реальную долю каждой категории.
Для спорных случаев нужна инструкция разметчикам. Если два человека не могут согласовать правильную метку, сначала уточните правило. Не стоит считать модель виноватой в том, что сама организация не определила маршрут.
Разрешите системе не выбирать
Категория «нужна проверка» помогает избежать принудительной классификации неизвестных запросов. Но она требует владельца и допустимого времени ожидания. Иначе неопределённость превратится в забытую очередь.
Не полагайтесь на уверенное объяснение модели как на численно надёжную вероятность. Порог автоматической маршрутизации проверяют на размеченных примерах. Для более рискованных категорий можно использовать отдельные правила и обязательную проверку человеком.
Что включить в решение о запуске
Покажите объём теста, результаты по каждой категории, число пропущенных важных обращений и долю ручной проверки. Зафиксируйте недопустимые ошибки. После запуска выборочно проверяйте реальные сообщения и сохраняйте новые спорные примеры для следующего теста.
Хороший классификатор помогает быстрее направлять работу. Его качество следует оценивать по правильности маршрутов и последствиям ошибок, а не только по одной цифре в отчёте.
О проекте: VOSHOD. Для связи: Telegram-бот VOSHOD.