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