Оператор городской транспортной системы

Задача

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

Задача звучала стандартно: автоматизировать ответы на типовые обращения. Как получить идентификатор, как войти через госуслуги, почему не загружается фото с паспортом, что делать при смене телефона. Восемьдесят процентов вопросов повторяются, но каждый сформулирован по-своему. Сотрудник поддержки читает письмо и сразу понимает, о чём речь. Но чтобы найти нужный фрагмент в базе знаний, ему нужно перевести вопрос водителя на язык документации — и на этот перевод уходит основное время. Из пяти-десяти минут на обращение сам ответ занимает полминуты, остальное — поиск.

Что ломается на настоящих письмах

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

Первый сюрприз оказался не в модели, а в данных. База знаний строилась из QA-датасета: команда контроля качества разбирала реальные тикеты, фиксировала вопрос водителя и три варианта ответа — фактический от сотрудника, исправленный по регламенту и отредактированный до логической чистоты. Но в тех же ячейках попадались служебные метки: «спам», «модерация», «работа оператора» — так QA-команда размечала категорию обращения. Без фильтра эти метки оказались бы в поисковом индексе как эталонные ответы, и на вопрос водителя система вернула бы слово «спам». Рядом в датасете лежали примеры ненормативной лексики — негативные кейсы для обучения модерации. Без отдельной очистки они тоже попадали бы в индекс. Пришлось ставить три уровня фильтрации до того, как данные попадут в систему: отсеивать служебные метки, отсеивать модерационные примеры и выбирать лучший вариант ответа из трёх по приоритету.

Второй провал — в самих ответах. На вопрос вроде «как обновить номер телефона» система могла найти фрагмент про управление аккаунтом и сгенерировать инструкцию: удалить аккаунт и создать новый. Формально по теме — и аккаунт, и телефон упоминаются. На практике водитель теряет все данные вместо обновления одного поля. Поиск не различал намерения внутри одной темы. Для этого появились шесть категорий намерений — система повышает оценку при совпадении категории вопроса и документа и снижает при несовпадении. Одну исключительную пару прописали руками: «загрузка документов» не штрафуется за пересечение с «редактированием профиля», потому что загрузка фото часто включает шаги по редактированию.

Потом случилась галлюцинация, с которой начинается этот текст. Модель ссылалась на техническую проблему, которой не существовало, и ни один из фильтров этого не ловил — ответ был грамотным, вежливым, релевантным по теме. Просто ложным. Для таких случаев появился жёсткий фильтр: список из восьми фраз-маркеров («массовая техническая проблема», «инцидент», «сервис недоступен», «разработчик разбирается» и ещё четыре). Если маркер есть в ответе, но ни в одном из найденных документов его нет, ответ блокируется. Решение грубое, но галлюцинация, которая уходит водителю, обходится дороже.

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

Все эти параметры складываются в формулу уверенности, которая определяет маршрут ответа. Высокая уверенность — ответ уходит водителю автоматически. Ниже порога — система честно передаёт обращение оператору без попытки угадать.

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

Результат

Система работает в продакшене на двух каналах: email и Telegram. Сотрудник поддержки больше не ищет ответы в базе знаний — он работает только с обращениями, где уверенности системы не хватает для автоответа.

Настройка продолжается, пока идут обращения, и система становится точнее с каждой неделей эксплуатации — без переобучения модели и без переписывания кода. Каждый новый класс ошибок превращается в конкретное правило, которое не даёт этой ошибке повториться.