1. Главная
  2. Блог
  3. Автоматизация процессов с ИИ
  4. Классификация обращений с помощью ИИ: справочник, спорные случаи, точность

Классификация обращений с помощью ИИ: справочник, спорные случаи, точность

14 августа 2026
8

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

При этом качество классификации почти никогда не упирается в модель. Оно упирается в справочник категорий — и это работа не техническая, а организационная.

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

Как строить справочник

Из реального потока, а не из головы. Возьмите 300–500 обращений за последние месяцы и разложите руками. Категории должны вырасти из данных.

Категории не должны пересекаться. Классический дефект: «Проблема с доставкой» и «Претензия». Куда попадает претензия по доставке? Модель выберет случайно, потому что выбор действительно неоднозначен.

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

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

Обязательна категория «прочее». Без неё модель будет натягивать обращение на ближайшую подходящую, и вы не узнаете о появлении новой темы.

Разумное число — от пяти до пятнадцати. Больше — категории начинают пересекаться и различаются плохо. Если нужна детализация, делайте два уровня: сначала крупная категория, потом подкатегория внутри неё.

Что классифицировать помимо темы

Обычно одной категории мало. Полезные дополнительные признаки:

Признак Что даёт
Срочность приоритет в очереди
Тональность выявление недовольства до эскалации
Наличие претензии отдельный маршрут
Требуется ли ответ часть писем ответа не требует
Продукт или услуга маршрут к нужной группе
Язык выбор шаблона и исполнителя

Каждый признак определяется отдельно. Попытка закодировать всё в одну категорию порождает комбинаторный взрыв: «срочная претензия по доставке» как отдельная категория — тупиковый путь.

Что делать со спорными случаями

Разрешить несколько категорий. Обращение «сколько стоит и почему до сих пор не привезли» содержит две темы. Заставлять систему выбирать одну — терять половину.

Ввести приоритет. Если сработала претензия — она выигрывает у любой другой темы независимо от того, что ещё нашлось.

Использовать порог уверенности. Ниже порога — категория «требует разбора», обращение уходит человеку.

Не бояться категории «прочее». Она честнее неверной классификации.

Как измерять

Нужен набор из 200–300 реальных обращений с проверенной категорией. Размечают минимум два человека независимо — расхождения между ними показывают, где справочник неоднозначен.

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

Метрики считаются по каждой категории отдельно, а не в среднем:

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

Средняя точность по всем категориям скрывает картину: система может работать отлично на трёх крупных категориях и проваливать две редкие, а среднее будет высоким.

Разбор: классификатор, который переделали через месяц

Задача. Поток около 4 000 обращений в месяц: почта, форма на сайте, мессенджеры. Нужна автоматическая маршрутизация.

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

Что получилось. Точность на контрольном наборе — около 60%. Плохо, и непонятно почему: обращения выглядели простыми.

Что показала матрица ошибок. Ошибки были не размазаны, а сосредоточены в нескольких парах категорий. Три пары давали больше половины всех ошибок:

  • «Вопрос по оплате» и «Проблема с платежом» — граница не определялась даже людьми;
  • «Технический вопрос» и «Не работает сервис» — то же;
  • «Претензия» и всё остальное — претензия могла быть по любой теме.

Проверка на людях. Дали 100 обращений двум сотрудникам поддержки. Их разметка совпала в 71% случаев. То есть модель работала почти на уровне согласия между людьми — и упиралась не в свои способности, а в справочник.

Это ключевой момент: пока люди не согласны между собой, требовать точности от системы бессмысленно.

Что сделали.

Свели 22 категории к 9, объединив те, что путались. Проверили на людях снова: согласие выросло до 91%.

Вынесли «претензию» из категорий в отдельный признак — теперь обращение имеет тему и отдельно отметку о претензии. Это сняло целый класс конфликтов.

Добавили второй уровень: внутри крупной категории — подкатегория, если она нужна для маршрута. Модель сначала определяет крупную, потом подкатегорию только внутри неё. Задача становится проще на каждом шаге.

Добавили «прочее» и порог уверенности.

Результат. Точность на контрольном наборе выросла примерно до 88%. Модель не менялась — менялся справочник и устройство задачи.

Что стоит забрать. Когда классификация работает плохо, первый вопрос — не «какую модель взять», а «а сами вы согласны между собой?». Если разметка двух сотрудников расходится, дело в категориях.

Когда модель не нужна

Честная оговорка: часть классификации решается без ИИ.

Если тема определяется по формальному признаку — адресу отправителя, теме письма с шаблонным префиксом, полю формы, — это правило в коде. Дешевле, быстрее, стопроцентно предсказуемо.

Разумная схема: сначала правила, модель для остатка. Письма из клиент-банка распознаются по отправителю, обращения с формы — по выбранному полю, а модель разбирает только свободные обращения. Часто это сокращает поток к модели вдвое, и с разбора такого состава я начинаю работу по автоматизации процессов«Когда хватит скрипта вместо ИИ».

Частые вопросы

Как построить справочник категорий для классификации?

Из реального потока: разложить руками 300–500 обращений и посмотреть, какие группы получились. Категории не должны пересекаться, должны описывать суть обращения, а не отдел-получатель, и каждая должна иметь определение с примерами. Обязательно нужна категория «прочее».

Сколько категорий должно быть?

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

Что делать, если обращение относится к двум темам?

Разрешить несколько категорий сразу и задать приоритет: например, признак претензии выигрывает у любой другой темы. Принудительный выбор одной категории на многотемных обращениях — прямая потеря информации.

Какая точность классификации считается хорошей?

Ориентир — согласие между людьми на том же наборе. Если два сотрудника размечают одинаково в 90% случаев, это верхняя планка и для системы. Если они согласны только в 70%, проблема в справочнике, и настраивать модель бесполезно.

Как понять, какие категории путаются?

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

Нужна ли модель, если у нас есть форма с выбором темы?

Для обращений через форму — нет, там тема уже указана. Модель нужна для свободных обращений: писем и сообщений в мессенджерах. Разумно сначала обрабатывать правилами всё, что определяется формально, а модели отдавать остаток.

Что дальше

Что делать с неуверенными случаями — «Человек в контуре проверки». Как заставить модель возвращать категорию в строгой форме — «Структурированный вывод модели». Прикладные направления: обработка почты и обработка отзывов. Если система должна не только классифицировать, но и обрабатывать заявку целиком — «ИИ-агент для обработки заявок».