Как нейросеть автоматически разбирает письма и заявки
Разбираю рабочую схему: от входящего письма до проверенного черновика ответа без потери контроля человеком.
Поток входящих обращений редко состоит из однотипных сообщений. В одном ящике могут оказаться вопрос о доставке, просьба изменить реквизиты, жалоба на оплату и письмо без единого понятного вопроса. Если оператор каждый раз читает текст с нуля, распределяет его вручную и заново пишет ответ, задержка накапливается уже после 30–50 сообщений за смену.
Нейросеть помогает вынести повторяющиеся операции в отдельный контур: определить тему, извлечь сведения, назначить приоритет и подготовить черновик. Человек сохраняет контроль над спорными случаями, персональными данными, возвратами и обещаниями клиенту. Подробно о проверке результатов генерации я пишу в материале «Нейросеть для генерации текста: задачи и проверка результата».
Как устроен автоматический разбор входящих
Автоматический разбор строится из 4 последовательных шагов: приём сообщения, классификация, извлечение полей и подготовка следующего действия. Такая цепочка позволяет отдельно проверять каждый участок, а не оценивать весь результат одним впечатлением.
Сначала система получает текст письма, тему, дату, адрес отправителя и сведения о вложениях. Затем определяет категорию обращения. Для службы поддержки это могут быть «доставка», «оплата», «возврат», «техническая проблема» и «другое». После классификации модель ищет конкретные данные: номер заказа, город, дату события, название услуги или требуемый срок ответа.
Последний шаг зависит от категории. Для простого вопроса создаётся черновик, для запроса на возврат формируется задача оператору, а для сообщения с угрозой, юридической претензией или неполными данными включается ручная маршрутизация. Модельный кейс: компания из сферы логистики, около 200 сотрудников, может разделить входящие на 6 очередей и направлять сообщения с пропущенным номером отправления на уточнение, не смешивая их с обычными вопросами о сроках доставки.
Схему удобно представить так:
Сообщение → Категория → Поля и приоритет → Черновик или маршрут → Проверка
Я не советую начинать с попытки автоматизировать весь цикл. Сначала полезнее добиться стабильного определения темы и обязательных полей. Если эти два слоя работают предсказуемо, черновик ответа легче ограничить правилами.
Какие данные извлекать из письма или заявки
Для устойчивой маршрутизации достаточно начать с 6 полей: тема, намерение, приоритет, идентификатор обращения, недостающие сведения и рекомендуемое действие. Такой набор закрывает большую часть повторяющихся операций и не перегружает инструкцию лишними признаками.
Тема отвечает на вопрос, о чём пишет человек. Намерение уточняет действие: узнать статус, изменить заказ, отменить услугу, сообщить о проблеме. Приоритет лучше задавать через понятные уровни, например «обычный», «срочный» и «критический». Не стоит смешивать приоритет с эмоциональностью текста: раздражённый тон сам по себе ещё не доказывает срочность.
Идентификатором может быть номер заказа, договора, счёта или заявки. Если его нет, система должна вернуть значение «не найден», а не догадаться. Поле с недостающими сведениями показывает оператору, что спросить в первом ответе. Рекомендуемое действие связывает результат с процессом: ответить по шаблону, запросить документ, передать специалисту, остановить автоматическую отправку.
Для каждой категории заранее задайте допустимые значения. Например, у поля «приоритет» может быть ровно 3 варианта, а у поля «действие» 5 вариантов. Это уменьшает число разнородных формулировок и упрощает отчёты. В материале о внедрении нейросетей в рабочие процессы я подробно разбираю, почему сценарий использования лучше начинать с одной повторяемой операции.
Полезный формат результата выглядит так:
| Поле | Допустимый результат | Что проверяет оператор |
|---|---|---|
| Категория | доставка, оплата, возврат, другое | Верно ли выбрана очередь |
| Приоритет | обычный, срочный, критический | Есть ли основание для срочности |
| Номер обращения | найденное значение или «не найден» | Совпадает ли номер с текстом |
| Недостающие данные | список полей | Что запросить у клиента |
| Действие | ответить, уточнить, передать | Можно ли продолжить без человека |
Таблица нужна не для красоты. Она задаёт контракт между моделью и оператором: если результат не помещается в допустимое значение, его проще отправить на дополнительную проверку.
Как готовить черновик ответа
Хороший черновик проходит 2 проверки: отвечает на фактический вопрос и не добавляет сведений, которых нет во входящем сообщении. Вторая проверка защищает от выдуманных сроков, сумм, условий возврата и обещаний, которых компания не давала.
В инструкции для модели зафиксируйте роль, список категорий, обязательные поля, тон ответа и условия остановки. Просите сначала кратко описать найденные факты, затем предложить черновик. Такой порядок позволяет увидеть, на каких данных построена формулировка.
Например, для обращения о задержке доставки инструкция может требовать:
- Найти номер отправления и дату, если они указаны.
- Не сообщать новый срок без подтверждённого значения.
- Если номера нет, задать один точный уточняющий вопрос.
- Передать оператору сообщения с юридическими требованиями или угрозой санкций.
Модельный кейс: при письме «Заказ 4817 не приехал 12 мая, прошу вернуть деньги» корректный результат должен выделить номер 4817, дату 12 мая, тему «доставка», намерение «возврат» и необходимость проверки условий. Нельзя автоматически дописывать сумму возврата или обещать зачисление в течение 3 дней, если таких данных нет в источнике.
Отдельное внимание уделите персональным данным. В текстах могут встречаться адреса, телефоны, паспортные сведения и реквизиты. Перед передачей обращения в модель определите, какие поля нужно скрывать, а какие необходимы для маршрутизации. Внутреннее правило должно отвечать на вопрос, кто увидит исходный текст и сколько времени он хранится.
Формулировать такие инструкции проще, если разобрать структуру запроса в статье «Искусство промптинга: как правильно формулировать запросы для нейросетей». Там же полезно сопоставить требования к формату ответа с реальной задачей, а не с абстрактным пожеланием «отвечай качественно».
Какой подход выбрать для разных потоков
Для потока до 50 обращений в день обычно достаточно правил, шаблонов и выборочной помощи нейросети. При 50–300 сообщениях разумно разделить классификацию и подготовку ответа, а при большем объёме добавить очереди, журнал ошибок и формальные пороги передачи человеку.
| Подход | Что делает | Где полезен | Ограничение |
|---|---|---|---|
| Ручная обработка | Оператор читает и распределяет каждое сообщение | Юридические, редкие и конфликтные случаи | Время растёт вместе с объёмом |
| Правила и фильтры | Ищут ключевые слова, адреса и шаблоны | Стабильные темы, номера заказов, типовые уведомления | Плохо понимают контекст и перефразирование |
| Нейросеть с контролем | Определяет смысл, извлекает поля, готовит черновик | Разнообразные формулировки и повторяющиеся вопросы | Нужны тестовая выборка и проверка человека |
| Смешанный маршрут | Простые случаи идут по шаблону, сложные передаются оператору | Потоки с разным риском ошибок | Требует ясных условий переключения |
На практике смешанный маршрут чаще всего даёт более понятный баланс. Правила быстро отсекают сообщения с известными признаками, а нейросеть обрабатывает свободный текст. Для критичных категорий можно установить запрет на автоматическую отправку независимо от уверенности модели.
При сравнении инструментов оценивайте не число заявленных функций, а путь одного обращения. Сколько полей нужно заполнить? Где хранится исходный текст? Можно ли увидеть причину выбранной категории? Что произойдёт при пустом номере заказа? Ответы на эти 4 вопроса часто важнее красивого демонстрационного диалога.
Как измерять качество и находить ошибки
Качество процесса нужно оценивать по 4 показателям: точность категории, полнота извлечения полей, доля принятых черновиков и время до первого ответа. Один показатель без остальных создаёт ложное ощущение порядка.
Точность категории показывает, сколько сообщений попало в правильную очередь. Полнота извлечения отвечает за наличие нужных номеров, дат и признаков проблемы. Доля принятых черновиков отражает практическую пользу для операторов, а время до первого ответа связывает автоматизацию с клиентским результатом.
Условный пример: если из 100 сообщений 90 относятся к доставке, точность 90% сама по себе мало о чём говорит. Система может постоянно выбирать одну крупную категорию и пропускать редкие, но дорогие случаи, например возвраты или претензии. Поэтому тестовую выборку нужно разделить по категориям и отдельно считать ошибки для каждой группы.
Соберите минимум 100 обезличенных обращений, разметьте их вручную и сохраните исходные формулировки, включая опечатки. Затем проверьте 3 среза: обычные письма, короткие сообщения без контекста и конфликтные обращения. После запуска раз в неделю просматривайте ошибки, меняйте инструкцию небольшими блоками и сравнивайте результаты на той же выборке.
Полезно ввести порог уверенности, но не принимать его за гарантию. Если модель оценивает категорию ниже установленного значения, обращение отправляется оператору. Сам порог выбирается по цене ошибки: пропустить вопрос о статусе обычно менее рискованно, чем неверно обработать заявление на возврат.
Общие рекомендации по проверке результатов текстовой генерации собраны в статье о задачах и контроле нейросетей при создании текста. Для входящих обращений к ним нужно добавить проверку полей, маршрута и соответствия внутренним правилам компании.
Как внедрить схему без резкого изменения процесса
Первый запуск можно разложить на 10 рабочих дней: 2 дня на сбор примеров, 3 дня на разметку, 2 дня на настройку инструкции и 3 дня на тестирование с операторами. Это план работ, а не обещание результата: срок зависит от числа категорий, качества архивных писем и требований к защите данных.
В первые 2 дня соберите письма за один период и удалите лишние персональные сведения. Не выбирайте только хорошо написанные обращения. В выборке должны остаться короткие сообщения, цепочки переписки, вложения без пояснений и вопросы с несколькими темами.
На третьем и четвёртом днях определите категории и спорные границы между ними. Если оператору трудно отличить «оплату» от «возврата», модель тоже будет ошибаться. На пятом дне закрепите по 10–20 примеров на каждую категорию, но не превращайте их в единственный источник истины.
Далее настройте формат результата. Поля должны быть короткими, обязательные значения перечислены заранее, а неизвестные данные обозначены одинаково. После этого проведите тест без автоматической отправки сообщений. Оператор сравнивает исходное письмо, найденные факты, категорию и черновик.
Модельный кейс: для отдела с 8 категориями можно начать с одной очереди «доставка» и проверить 120 обезличенных писем. Если ошибки связаны с отсутствием номера, сначала меняют вопрос к модели и форму входных данных, а не добавляют десятки новых правил.
Для сотрудников полезно описать 5 ситуаций, в которых автоматический маршрут всегда останавливается: претензия, запрос персональных данных, спорная сумма, угроза судебного разбирательства и отсутствие обязательного идентификатора. Такой список должен быть доступен рядом с рабочим процессом, а не храниться в отдельном длинном документе.
О практических сценариях для бытовых и рабочих задач можно прочитать в статье как использовать нейросети и чат-боты для повседневных задач. Для поддержки принцип тот же: сначала описывается повторяемая операция, затем задаётся граница ответственности человека.
Где в схеме нужен чат SoftChat
Чат нужен для диалога с языковой моделью, уточнения инструкции и получения текстового результата, а маршрутизация писем требует отдельного рабочего процесса. В SoftChat доступен веб-чат с потоковой выдачей ответов через SSE и переключением моделей для конкретного разговора.
В веб-интерфейсе есть вкладки «Текст» и «Графика», а разделы «Видео», «Код», «Аудио» и «Презентации» имеют статусы «Скоро» или «В разработке». Для задачи разбора писем здесь уместен текстовый сценарий: оператор формулирует запрос, получает ответ по частям и при необходимости выбирает другую модель в рамках текущего разговора.
Я бы не смешивал чат с почтовой очередью в одной инструкции. Внешний процесс должен передать в чат обезличенный текст и требуемый формат результата, а затем вернуть классификацию, поля и черновик в место, где оператор принимает решение. Так проще разделить доступы, журналировать ошибки и убрать автоматическую отправку там, где она опасна.
Если сотрудники впервые открывают веб-чат, после регистрации может появиться обзор из 5 карточек с основными элементами интерфейса. Его можно закрыть кнопкой «Пропустить» или запустить заново в профиле через раздел «Знакомство с SoftChat». Это помогает быстро найти переключатель модели и меню инструментов, но не заменяет инструкцию по обработке обращений.
Что бы я сделал на вашем месте
Я бы начал с одной категории, одного формата результата и 100 обезличенных писем. Сначала проверил бы маршрутизацию и обязательные поля, затем добавил черновик ответа для простых вопросов. Автоматическую отправку оставил бы за пределами первого этапа.
Через неделю сравнил бы 4 показателя: точность категории, полноту полей, долю исправлений оператором и время до первого ответа. Если ошибка связана с нехваткой контекста, улучшил бы входные данные. Если модель добавляет неподтверждённые обещания, усилил бы запрет на догадки и расширил список случаев для передачи человеку.
Такой порядок даёт измеримый результат без резкой перестройки поддержки. Нейросеть берёт на себя повторяемый анализ, оператор сохраняет решение там, где цена ошибки выше экономии нескольких минут.