Обращения нельзя надёжно распределить, если категории существуют отдельно от работы поддержки. Сначала определите, что должно произойти после каждой метки: кто получит запрос, какое действие выполнит и в каких случаях позовёт человека. Только затем подключайте ИИ.
Главный принцип: классификатор не обязан выбирать одну категорию любой ценой. Он должен сохранить важные темы обращения, показать основание решения и передать спорный случай на ручную проверку. Иначе аккуратный отчёт скроет запрос, который так и не дошёл до нужного специалиста.
Начните с действия после метки
Категория полезна, когда меняет маршрут обращения. Метка «Доступ» может направить запрос специалисту, который проверяет учётную запись. Метка «Документы» — ответственному за акты и закрывающие документы. Если две категории ведут в одну очередь и не меняют дальнейшую работу, возможно, поддержке не нужно разделять их на первом этапе.
Для каждой категории ответьте на пять вопросов:
- Какие обращения входят в категорию?
- Какие похожие случаи в неё не входят?
- Кто отвечает за следующий шаг?
- Что должен сделать этот сотрудник или система?
- Что происходит, если сведений недостаточно или подходят несколько категорий?
Не смешивайте категорию, приоритет и статус. «Не могу войти» описывает тему обращения. «Работа остановлена» может влиять на срочность. «Передано специалисту» обозначает состояние обработки. Если записать всё в одно поле, одинаковые обращения начнут получать разные метки из-за эмоциональной формулировки.
Фраза «Срочно помогите, это ужасно» сама по себе не доказывает высокий приоритет. Правило срочности лучше связать с проверяемыми обстоятельствами: остановлена ли работа, затронуты ли другие пользователи, есть ли установленное обязательство по времени реакции. Конкретные правила определяет владелец процесса.
Опишите границы категорий
Одного названия недостаточно. Слова «оплата», «доступ» или «документы» встречаются в разных ситуациях и не всегда определяют маршрут. Поэтому справочник должен объяснять не только центр категории, но и её границы.
| Поле справочника | Что записать |
|---|---|
| Название | Короткая метка, понятная сотрудникам |
| Определение | Какую рабочую задачу объединяет категория |
| Включённые случаи | Характерные обращения, которые относятся к категории |
| Исключения | Похожие случаи, которые нужно направить иначе |
| Примеры | Обезличенные обычные и пограничные формулировки |
| Ответственный | Роль или очередь, которая получает обращение |
| Неопределённость | Уточнение, несколько меток или ручной разбор |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Если специалисты регулярно спорят о категории одного и того же запроса, сначала исправьте справочник. Модель не устранит противоречие между правилами, которыми по-разному пользуются люди.
Необязательно заранее предусматривать любую будущую тему. Категория «Не определено» или отдельная очередь разбора полезнее случайной метки. Новые обращения из этой очереди покажут, какой темы не хватает в справочнике и стоит ли создавать для неё отдельный маршрут.
Поддержка также может разрешить несколько категорий для одного сообщения. Это решение зависит от дальнейшей работы: иногда достаточно отправить обращение одному диспетчеру, иногда нужно создать две связанные задачи. Такое правило следует зафиксировать явно, а не прятать внутри инструкции модели.
Подготовьте примеры для разметки и проверки
Используйте только разрешённые обезличенные обращения. Сохраните не только итоговую категорию, но и основание решения разметчика: какой фрагмент сообщения и какое правило справочника повлияли на выбор. Без этого трудно отличить ошибку модели от спорного определения.
В наборе нужны разные ситуации:
- обычное обращение с одной ясной темой;
- короткая фраза без контекста;
- сообщение с двумя независимыми вопросами;
- запрос с новой формулировкой;
- обращение, которому не подходит ни одна категория;
- противоречивые или неполные сведения.
Не существует универсального числа примеров, после которого классификация автоматически становится готовой. Объём зависит от числа категорий, разнообразия формулировок и последствий ошибки. Важно проверить все существенные маршруты и пограничные случаи.
Разделите материалы для настройки и приёмки. Если проверять систему только на примерах, которые уже использовались при подготовке, результат покажет узнавание знакомых формулировок, но не работу с новыми обращениями.
Учебный пример: в сообщении две темы
Условное обращение: «Не могу войти, и ещё не получил закрывающий документ».
В справочнике есть категории «Доступ» и «Документы». Выбрать только первую нельзя: тогда вопрос о документе исчезнет из маршрута.
| Фрагмент обращения | Категория-кандидат | Основание | Ответственный или уточнение |
|---|---|---|---|
| «Не могу войти» | Доступ | Пользователь сообщает, что вход недоступен | Ответственный за доступ; при нехватке данных уточнить учётную запись и проявление ошибки |
| «не получил закрывающий документ» | Документы | Пользователь ожидает документ | Ответственный за документы; уточнить нужный документ и период, если это требуется процессом |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Дальнейшее действие зависит от правил поддержки. Система может сохранить две темы и применить согласованный маршрут. Другой вариант — передать всё обращение диспетчеру, который разделит его на задачи. В обоих случаях исходный текст должен оставаться доступным сотруднику.
Это учебный пример, а не результат запущенного классификатора. Он показывает требование к проектированию: ни одна значимая тема не должна пропасть из-за ограничения «одному обращению — одна метка».
Сделайте неопределённость видимой
Пустое сообщение, неизвестная услуга, несколько тем и противоречивые сведения требуют отдельного действия. Для каждого такого случая заранее выберите один из вариантов:
- запросить недостающие данные;
- предложить несколько категорий;
- передать обращение в очередь ручного разбора;
- остановить автоматическую маршрутизацию и показать причину.
Число уверенности модели нельзя автоматически считать вероятностью правильного ответа. Сначала нужно проверить на собственной размеченной выборке, как такой показатель связан с ошибками в конкретных категориях. До этой проверки понятная причина передачи человеку полезнее условного процента.
Сотруднику на ручной проверке нужны исходное обращение, предложенные категории, основание выбора и доступные действия. Краткий пересказ без оригинала может скрыть как раз тот фрагмент, который меняет маршрут.
Последовательность спорного случая может выглядеть так:
- Система сохраняет исходный текст и источник обращения.
- Классификатор предлагает одну или несколько категорий и показывает основания.
- Правила выявляют неоднозначность или отсутствие подходящей категории.
- Сотрудник подтверждает решение, исправляет его или запрашивает сведения.
- Журнал сохраняет первоначальное предложение, итог и причину изменения.
Сохраняйте исправления вместе с причиной
Одной итоговой метки недостаточно для улучшения процесса. Сохраняйте предложенную категорию, исправленный вариант, автора проверки и причину изменения в объёме, допустимом вашими правилами работы с данными.
Причины удобно связывать со справочником: «две темы», «не хватило данных», «границы категорий пересекаются», «появилась новая тема», «неверно определён маршрут». Тогда повторяющиеся ошибки можно разбирать по источнику.
Если сотрудники постоянно заменяют одну категорию другой, проблема может быть не в модели. Возможно, определения пересекаются, примеры противоречат правилам или две формально разные категории ведут к одному действию. После изменения справочника повторите затронутые проверки на прежних и новых примерах.
Исправления не стоит автоматически превращать в новые правила. Ошибиться может и проверяющий. Сначала владелец процесса подтверждает изменение, затем команда обновляет справочник и контрольный набор.
Принимайте маршрут, а не красивую среднюю цифру
Для приёмки подготовьте согласованную разметку и отдельно проверьте ясные, смешанные, короткие, нерелевантные и новые запросы. Сравнивайте не только совпадение меток, но и последствия ошибки.
| Проверка | Что должно быть видно |
|---|---|
| Ясный запрос | Назначена категория с понятным основанием |
| Две темы | Обе темы сохранены или обращение направлено на согласованный разбор |
| Короткий запрос | Система не додумывает отсутствующие сведения |
| Нет подходящей категории | Запрос не получает случайную метку и уходит по заданному маршруту |
| Новая формулировка | Решение опирается на смысл и границы категории, а не только на знакомые слова |
| Исправление сотрудника | Первоначальное предложение, итог и причина изменения прослеживаются |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Средний показатель может скрыть опасную ошибку в небольшой категории. Поэтому рассматривайте результаты по категориям и маршрутам: потеряна ли важная тема, дошёл ли запрос до нужного ответственного, заметил ли сотрудник спорный случай.
Универсального порога готовности нет. Критерии зависят от цены ошибки и роли автоматизации. Для одного процесса допустимо, чтобы система только предлагала метку. Для другого можно автоматически направлять ясные обращения, но оставлять смешанные и неизвестные человеку. Эти условия нужно согласовать до пилота.
Когда нужен ИИ-агент, а когда достаточно правил
Если известные поля всегда запускают один маршрут, задачу может решить обычная интеграция или фиксированная автоматизация. Чат-бот нужен, когда пользователю требуется удобный вход в процесс через диалог. ИИ-агент уместен, если система должна разобрать свободный текст, выбрать следующий разрешённый шаг, запросить уточнение или обратиться к разным источникам по ситуации.
Название технологии не заменяет проверку процесса. Сначала опишите вход, категории, полномочия, ручную очередь и ожидаемый результат. Затем выбирайте реализацию с учётом доступных систем и данных.
Switch On AI помогает спроектировать такой сценарий в рамках услуги разработки AI-агентов: разобрать рабочий процесс, определить допустимые действия и подготовить проверки на согласованных примерах. Прототип ключевого сценария помогает сверить требования, но не считается полноценным внедрением.
Подход к рубрикам, основаниям и исправлениям показан в демонстрации классификации с проверкой. Это демонстрационный сценарий, а не клиентская система и не доказательство точности на вашем потоке.
Что подготовить к обсуждению проекта
Соберите текущий справочник, несколько обезличенных обычных и спорных обращений, правила маршрутизации и роли ответственных. Отдельно отметьте категории, о которых сотрудники чаще всего спорят, и ошибки с наиболее заметными последствиями.
Этих материалов достаточно, чтобы начать разбор. Вместе можно определить границы категорий, путь смешанного обращения, условия ручной проверки и критерии приёмки. Чтобы обсудить свой процесс, расскажите Switch On AI о задаче.
Вопросы по этой задаче
Кто должен определять категории обращений?
Категории определяет владелец процесса вместе с сотрудниками, которые маршрутизируют и обрабатывают обращения. Они связывают каждую метку с границами, ответственным и следующим действием; модель применяет согласованный справочник.
Что делать, если в обращении две темы?
Нужно сохранить обе значимые темы. По правилам процесса обращению назначают несколько категорий, разделяют его на связанные задачи или передают диспетчеру. Выбирать только первую тему и терять вторую нельзя.
Можно ли верить проценту уверенности модели?
Не без проверки на собственной размеченной выборке. Само число не доказывает вероятность правильной категории; до проверки спорный случай лучше явно передавать человеку с указанием причины.
Как исправлять ошибочную категорию?
Сохраните первоначальное предложение, итоговую категорию и причину исправления. Повторяющиеся ошибки нужно разбирать: они могут указывать не только на проблему модели, но и на пересекающиеся или неясные правила справочника.