Классификация текста: почему ручной разбор не масштабируется
Поток обращений растёт быстрее, чем команда успевает его разбирать. Ручной разбор обращений упирается в пропускную способность людей: один оператор за смену обрабатывает ограниченное число писем, и как только поток превышает норму, очередь обработки заявок растёт быстрее, чем её расчищают. Задержка накапливается — неразобранное ждёт, к нему добавляются напоминания и повторные письма.
Цена задержки — не только время ответа на обращение. Пока очередь короче смены, пауза почти незаметна; когда она переваливает за сутки, часть обращений превращается в «клиент ушёл, не дождавшись». Параллельно плывут метки: расхождения в метках между операторами стабильно возникают на спорных категориях, и чем выше темп, тем больше доля таких расхождений — у людей нет ни времени, ни единого критерия, чтобы решать одинаково.
Дальше страдает аналитика: накопленные расхождения в метках ломают сводные отчёты, и решения принимаются по шумным данным — тема кажется непопулярной, хотя спрос просто размазался по соседним категориям. Классификация текста закрывает самую дорогую ступень — маршрутизацию: модель относит обращение к категории, отдаёт оценку уверенности и передаёт человеку только спорные случаи.
Ниже разбираем, как это закрывается на практике: от статистических моделей вроде TF-IDF до языковых, чем они отличаются, как измеряется качество и как новая ступень встраивается в текущую очередь обработки заявок без остановки поддержки.
Где автоматический разбор обращений даёт измеримый эффект
Доля автоматически разобранных обращений — базовая метрика, и считать её нужно по обращениям, закрытым без участия человека, а не по числу ответов модели. На типовом потоке — заявки, вопросы по заказу, жалобы, запросы документов — классификация текста уверенно закрывает от половины до трёх четвертей, остальное осознанно уходит оператору.
Скорость сортировки потока меняется заметнее, чем кажется: раньше обращение ждало оператора в общей очереди, в пиковые часы — до следующей смены. Теперь маршрутизация заявок происходит в момент поступления: тема, срочность, язык и адресат определяются сразу, а ожидание измеряется минутами, а не сменами.
Снижение ручной обработки — следствие того, что оператор перестаёт быть сортировщиком и работает только со сложными случаями. Если уверенность модели ниже порога, обращение уходит человеку с пометкой и причиной решения, а не в случайный отдел или в общую очередь.
Самое ценное здесь — ушедший класс ошибок, а не скорость. Это заявки, которые сутками лежали неразобранными, дубли от одного клиента, обращения не тому адресату и занижённый приоритет у срочных. Такой класс закрывается правилом обработки, а не бдительностью конкретного сотрудника.
Проверяемость эффекта закладывается до старта автоматического разбора: берём исторический поток, размечаем выборку и смотрим, какая доля разбирается без человека и на чём модель ошибается. Если поток мал или однотипен, заметной доли автоматических решений не будет — это тоже честный результат разбора, и его лучше получить до начала работ.
Сравнение подходов: правила, обучение на примерах, готовые модели
Выбор подхода определяется тремя параметрами, которые обычно не проговаривают на старте: сколько классов нужно различать, сколько размеченных примеров есть в наличии и насколько «живые» формулировки приходят во входных данных. На формальном словаре выигрывают правила, на устойчивой тематике — обучение на размеченных примерах, на длинном хвосте классов и потоке новых формулировок — готовая языковая модель. Ниже сравнение с ограничениями, которые проявляются в эксплуатации, а не в демонстрациях.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Правила и словари | Классы описываются формальными признаками: реквизиты, маркеры, шаблонные обращения | Держатся на ручной поддержке, ломаются на новых формулировках, каждое изменение словаря — риск регресса |
| Обучение на размеченных примерах (TF-IDF и линейные модели) | Есть 1–2 тыс. примеров на класс, тематика и стиль стабильны | Точность на редких классах падает, разметку приходится обновлять при смене тематики |
| Готовая языковая модель | Много классов, мало разметки, живые формулировки и запросы пользователей | Дороже на объёме, нужны контроль качества и явная точка отката к предыдущей версии |
Внешние замеры на открытых наборах задач обработки текста, которые агрегирует Papers with Code, показывают: при 1–2 тыс. размеченных примеров на класс разрыв между классическими моделями и готовыми языковыми моделями почти исчезает. Он держится в двух местах — редкие классы и формулировки, которых не было в выборке. Поэтому при эксплуатации чаще собирают гибрид: модель на признаках закрывает частые классы как быстрый фильтр, а готовая модель подключается там, где уверенность классификатора ниже порога.
Внедрение классификации текста: этапы от аудита до передачи
Разметка и обучение — половина работы; вторая половина — воспроизводимый порядок, при котором результат переносится на новые данные. Ниже — этапы внедрения классификации текста в том виде, в котором мы их проходим: от аудита данных до передачи модели в эксплуатацию.
- Аудит данных. Выгружаем корпус, считаем долю дублей, пустых полей и текстов без полезной нагрузки, смотрим распределение по темам. Фиксируем, что размечено, а что придётся размечать, и сколько примеров нужно добить до рабочего объёма.
- Схема классов. Собираем таксономию без пересечений: один текст — один класс или несколько, что делать со смешанными случаями. Спорную выборку прогоняем через двух разметчиков и снимаем расхождения правилами, а не устными договорённостями.
- Рабочая модель и базовая линия. Идём от простых частотных моделей к векторным представлениям и языковым моделям, наращивая сложность только там, где она даёт прирост на отложенной выборке. Порог уверенности подбираем под цену ошибки.
- Настройка и интеграция. Описываем предобработку входа, отсечение мусора, версионирование модели и разметки, логирование предсказаний вместе с уверенностью — без этого разбор ошибок через месяц превращается в гадание.
- Проверка качества. Считаем точность и полноту по каждому классу, разбираем матрицу ошибок и пограничные примеры. Отдельно смотрим поведение на данных другого периода или источника: так видно, где модель держится на признаках времени, а не на смысле текста.
- Передача в эксплуатацию. Отдаём регламент дообучения, правила отката на предыдущую версию, мониторинг доли неуверенных ответов и инструкции для команды заказчика.
Комплект поставки: модели, схемы и регламенты разметки
Модель без окружения — это артефакт, который через месяц никто не сможет ни переобучить, ни объяснить. Поэтому комплект поставки собираем так, чтобы задача классификации текста жила без нас: от весов до правил, по которым разметчики разбирают спорные случаи.
- Обученная модель и код вызова — веса, обёртка для инференса, зафиксированные зависимости; поднимается на вашем контуре одной командой, без сборки «по памяти».
- Схема классов — таксономия с границами между похожими категориями, примерами на каждую и списком пар, которые путаются чаще всего.
- Регламент разметки — инструкция для аннотаторов: разрешение конфликтов, порядок эскалации спорных случаев, требования к согласованности между разметчиками.
- Политика доступа к данным — где лежат тексты, кто и на каком основании их читает, что маскируется перед журналированием и как устроен след обращений.
- Документация по модели — метрики качества по каждому классу, а не одно усреднённое число; известные ограничения и признаки начинающейся деградации.
- Набор проверочных примеров — эталонная выборка с метками, на которой прогоняется каждая новая версия: просадка видна до выката, а не после жалоб.
- Конфигурации развёртывания — описания окружений, схемы сервисов, лимиты и очереди; стенд воспроизводится без чтения чужого кода и вопросов нам.
Всё это передаём вместе с разбором для вашей команды: где менять список классов, как добавлять примеры и когда пора переобучать.
Кейс: разбор входящих обращений до и после внедрения
Исходная картина
Обращения падали в общую очередь, а разбор держался на правилах по ключевым словам: они уверенно разбирали 42% потока и рассыпались на перефразировках. Остальное вручную сортировали операторы — медиана до попадания к нужному специалисту составляла около трёх часов, а доля ошибочных меток доходила до 28%. В пиковые дни очередь росла быстрее, чем её успевали разбирать.
Что изменили
Из архива собрали корпус обращений и зафиксировали схему классов, а контрольную выборку — тысячу обращений — отложили и в обучении не использовали. На ней замеряли качество на каждом шаге: сначала базовая модель на частотных признаках, затем модель на предобученном языковом представлении, поверх — правила для редких и юридически значимых категорий. Разметку сверили с операторами, чтобы метки совпадали с их картиной мира.
После внедрения автоматически разбирается 88% обращений, доля ошибочных меток — 6%, время сортировки сократилось до 12 минут. Контрольная выборка переразмечается ежемесячно: если расхождений на ней больше 5%, запускается повторное обучение на свежих данных. Такой контур показывает сдвиг в языке клиентов или появление новой категории до того, как это заметят по жалобам, — логика оценки качества разобрана в публикациях ACL Anthology.
Чем отличается своя модель от готовой языковой модели?
Это выбор не «лучше или хуже», а под какие данные и какую цену ошибки. Свой классификатор обучается на вашей разметке, готовая языковая модель решает задачу по инструкции, без обучения. Разница проявляется на ваших классах, а не на демонстрационных примерах.
Своя модель выигрывает там, где классы узкие и близкие: «жалоба на сроки доставки» и «претензия к качеству» для общей модели почти одно и то же, а для бизнеса — разные маршруты обработки. Обучаясь на ваших примерах, классификатор проводит границу так, как её провели вы, и на своих классах даёт качество, измеримое на отложенной выборке.
Готовая языковая модель нужна, когда размеченных примеров нет, а решение требуется быстро. Она разбирает формулировки, не встречавшиеся в обучении, и не требует подготовки корпуса — но на редких рубриках отвечает нестабильно, а качество приходится проверять выборочно: ответ формируется заново на каждом запросе.
Доработка под новые классы тоже устроена по-разному. Своей модели добавляют размеченные примеры и переобучают — поведение воспроизводимо, метрики сопоставимы от версии к версии. У готовой модели правят инструкцию и подбирают удачные примеры, и после правки нельзя гарантировать, что ранее верные ответы не поехали.
На практике чаще работает связка: готовая языковая модель размечает большой массив текста, на этой разметке обучается свой классификатор, и дальше он работает быстро и предсказуемо. Критерий выбора один — качество на своих классах и то, как часто эти классы будут меняться.
Частые технические вопросы по проекту
Разметка и поддержка модели определяют, окупится ли классификация. Ниже — пять вопросов, которые чаще всего звучат на технических сессиях, с ответами по делу.
Сколько данных нужно разметить для старта?
Для базовой модели по разреженным признакам хватает нескольких тысяч примеров на класс — этого достаточно, чтобы закрыть 80–90% типовых обращений. Нейросеть требует большего объёма, но к ней мы переходим только там, где простая модель стабильно ошибается.
Что делать, если исторических данных нет?
Стартуем с правил и поиска по ключевым фразам: они закрывают очевидные случаи и попутно размечают корпус. Уверенные ответы становятся обучающей выборкой — история накапливается в процессе, отдельный архив не нужен.
Разметчики трактуют категории по-разному — это проблема?
Это главный потолок качества. До разметки фиксируем инструкцию с пограничными примерами, затем считаем согласованность между разметчиками, а спорное разбираем на сессии. Если категорию можно прочитать двояко — правим инструкцию, а не данные.
Как поймать деградацию качества?
Следим за долей уверенных предсказаний, распределением классов и долей обращений, ушедших на ручной разбор. Изменение входных текстов — дрейф данных, лечится переобучением; просадка метрик при том же входе — деградация, и откат на предыдущую версию возвращает качество.
Как часто нужно дообучать модель?
По событию, а не по календарю: метрики ушли за порог или накопилась партия размеченных исправлений. Каждый цикл даёт версию с журналом метрик и возможностью отката, поэтому дообучение не становится необратимым.
Обсудим задачу: что нужно от вас и когда вернёмся с планом
Чтобы оценка была предметной, а не «по ощущениям», нам нужен минимум контекста: где классификация встраивается в процесс, какой объём текстов через неё проходит и что считается ошибкой. Разговор занимает у заказчика один разговор, зато снимает половину уточнений на этапе оценки.
- Постановка задачи: какой процесс обслуживаем — маршрутизацию обращений, разметку отзывов, сортировку документов — и что именно решает модель.
- Исходные данные от заказчика: выгрузка текстов за период, желательно с уже проставленными метками хотя бы на части примеров.
- Список категорий и правила их пересечения: что делать, если текст подходит к двум сразу.
- Требования к качеству: какая доля ошибок допустима и какая ошибка дороже — пропуск или ложное срабатывание.
- Точка интеграции: куда возвращаем результат — в систему заявок, хранилище документов или внутренний сервис, и в каком виде.
- Ограничения: персональные данные, закрытый контур, требования к хранению — они определяют, какие модели допустимы.
Порядок оценки такой: разбираем данные, проверяем, хватает ли примеров для обучения, и возвращаемся с планом работ. Первым этапом ставим пилот на одном процессе — он показывает реальное качество на ваших текстах, и только после него масштабируем на остальные потоки.
Опишите задачу и приложите, что есть по данным, — вернёмся с оценкой и планом работ.
