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