Как мы заменили скриптового робота на LLM-бота в крупной ЖКХ-компании
LLM-бот на голосовой и текстовые каналы, реализованный полностью в закрытом контуре – именно такое решение мы разработали для одного из наших заказчиков в этом году. Рассказываем, с чего началась эта история, какие проблемы пришлось решить и как продукт проявляет себя в промышленной эксплуатации.
Какое было «до»?
Наш заказчик ежемесячно получает около 20 000 обращений по разным каналам: телефон, чат-боты в «Максе», «ВКонтакте», «Одноклассниках», мобильном приложении.
Раньше все эти обращения обрабатывал скриптовый робот, разработанный нами же около 5 лет назад. Изначально создавали его с одной задачей: принимать показания счётчиков. Но за 5 лет добавили к нему ещё около 60 сценариев. Здесь и стало понятно, что технология упёрлась в свой потолок.
Робот плохо распознавал свободную речь. Если клиент формулировал вопрос нестандартно, робот терялся.
В одной фразе могло содержаться одновременно несколько вопросов. Робот не мог их разделить.
В голосовом канале при непонимании робот переводил абонента на оператора, создавая очередь.
В текстовых каналах оператора не было, и клиент попадал в тупик: «Обратитесь по телефону». И тот же диалог шёл по второму кругу, но уже в голосовом канале.
Масштабирование было долгим и дорогим. Каждый новый сценарий добавлялся разработчиком вручную.
Что требовалось от нового решения?
Заказчик сформулировал чёткие требования, которые во многом определили архитектуру будущего решения:
Один бот на все каналы (единое ядро для телефона и чатов).
Полностью закрытый контур. Никаких облачных сервисов. Все данные и вычисления внутри инфраструктуры заказчика.
Работа с живой речью и текстом. Робот должен понимать спонтанную речь по телефону и опечатки, исправления в чате.
Быстрый отклик. В голосовом канале клиент не должен ждать ответа робота 5–10 секунд.
Человечный синтез речи. Чтобы клиент не догадывался, что говорит с роботом.
Как работает новый робот?
Шаг 1. Клиент может обратиться по телефону или через текстовые каналы: чат-бот в «Максе», «ВКонтакте», «Одноклассниках», в мобильном приложении. При этом все каналы подключены к единому ядру – одному боту.
Шаг 2. Система разпознавания речи превращает голос клиента в текст. В текстовом канале такой необходимости нет, но нужно учесть опечатки, сокращения и сообщения без контекста.
Шаг 3. Робот определяет тему обращения: что хочет клиент? Если робот не может однозначно классифицировать обращение, он задаёт уточняющий вопрос.
Шаг 4. После определения темы робот переходит к поиску ответа на вопрос клиента. Для этого он обращается к базе знаний или внутренним системам компании, с которыми настроена интеграция.
Шаг 5. Ответ клиенту: голосом или текстом в зависимости от канала связи.
Важно, что для клиента от озвучивания вопроса до получения ответа проходит около секунды, как если бы на звонок отвечал реальный человек.
Проблемы, которые не были техническими
На этапе разработки мы решали ряд технических проблем, связанных с распознаванием речи, дообучением модели, попутно даже создали свой мини-сервис распознавания адресов. Но столкнулись и с другими, неожиданными сложностями.
1. Клиенты не доверяют роботам
Люди определяют даже качественно синтезированный голос робота и сразу требуют оператора, даже не озвучив вопрос. Чтобы дать шанс роботу проявить себя, мы записали так называемые «превойсы» – живые фразы-приветствия голосами реальных сотрудников. Робот начинает диалог с живого голоса: «Спасибо за звонок, какой у вас вопрос?». Клиент думает, что ответил человек, и сразу задаёт вопрос. Дальше превойс говорит: «Понял, перевожу на специалиста», и здесь подключается LLM-бот.
2. Канцелярские ответы выдают робота
Мы были сильно ограничены требованиями к формулировкам ответов «как в регламенте». Живой оператор так не говорит. Мы со своей стороны провели работу по синтезу речи, чтобы голос звучал максимально человечно. Но параллельно работаем с заказчиком над тем, чтобы формулировки были более живые.
3. Живой голос напугал клиентов
Одним из первых сценариев прошлого робота был сценарий приёма показаний. За 5 лет люди настолько привыкли передавать показания через робота, что сильно испугались, когда на звонок стал отвечать человеческий голос. Клиенты терялись, метрики падали. И мы приняли решение, что именно по этому сценарию оставим старого скриптового робота.
По каким метрикам заказчик принимал проект?
Время ожидания оператора. В ТЗ была поставлена цель менее 10 секунд. По нашим последним замерам мы достигли менее 5 секунд. Соответственно, если по какой-то причине звонок переводится на оператора, соединение происходит практически мгновенно. То есть операторов мы разгрузили очень сильно.
Покрытие по сценариям. Скриптовый робот был ограничен 60 сценариями. Сейчас их уже около 85.
Точность классификации обращений. Требование, которое ставилось в ТЗ, – более 85% обращений должны правильно определяться роботом, и, соответственно, абонент должен получать корректный ответ на них. Мы достигли 98%, то есть практически абсолютной точности. По некоторым темам показатель держится ровно на уровне 100%, то есть робот не ошибается никогда.
Доля обращений, которые закрываются без оператора. В ТЗ ставилась цель закрывать без оператора больше половины обращений, мы достигли около 72% сейчас. То есть человек вообще не отвечает на 72% звонков или обращений в текстовом канале, и решение вопросов абонентов происходит в автоматическом режиме.
Доступность сервиса. Это стандартное требование для крупной компании. На данном этапе у нас есть как резервирование самого бота, так и возможность переключения на старого скриптового робота на случай критических ситуаций.
И достаточно субъективная оценка – человечность диалога. Мы подготовили три разных голоса для синтеза, которые оценивались сотрудниками заказчика. Были замечания, но в итоге, по мнению заказчика, голос стал очень похож на живых людей.
Куда двигаемся дальше?
Больше сценариев. У нас уже лежит около 10 сценариев, которые нужно будет реализовать. Это новые категории обращений и новые ветки диалога, которые заказчик хочет закрывать без оператора.
Проактивные уведомления. Сейчас робот отвечает на входящие запросы. Но почему бы ему самому не проявлять активность и не писать первым? Идея заключается в том, чтобы бот сам связывался с абонентом по поводу начислений, плановых работ, необходимости передать показания.
Автоматическое дообучение. Сейчас сотрудники заказчика прослушивают звонки, и, если видят ошибку, создают обращение в сервисную систему. Мы разбираем обращения, исправляем, при необходимости дообучаем модель. А стремимся к тому, чтобы сотрудник говорил, как правильно, и модель сама на этом дообучалась, без нашего прямого участия.
Хотите обсудить внедрение такого робота в Вашей компании? Оставьте заявку – свяжемся с Вами в течение 1 рабочего дня.