Как мы меняем клиентский сервис с помощью AI: часть 1

Я не раз попадал в ситуацию, когда задавал чат-боту вроде элементарный вопрос, он в ответ уточнял у меня одно, другое, третье. И когда я думал, что сейчас наконец получу то, зачем пришел, чат-бот говорил «зову оператора».

Другая интересная история, если спросить у чат-бота что-то конкретное, например, как получить выписку по счету. Бот расскажет все: какой нужно выбрать период, что будет в выписке, как долго ее будут делать, но не ответит, как же ее получить. Тогда бот позовет оператора, и человек уже опишет шаги.

Бывало, чат-бот зацикливался на одном и просто несколько раз подряд здоровается с пользователем.

Многие компании используют классические сценарии автоматизации. Они работают таким образом: 

1. Пользователь пишет запрос.

2. Этот запрос попадает в какой-то препроцессинг на скриптах, который думает примерно так: «вроде бы здесь есть слово “здравствуйте”, давайте запустим сценарий “здравствуйте”».

3. Дальше вступает обученная модель классификации и запускается подходящий сценарий. Это может быть приветствие, обработка заказа и в целом сценарий чего угодно.

Проблема такого подхода в том, что нужно прописывать сценарий и логику на каждый тип обращения, которых может быть бесчисленное множество. Нужно сначала выявить эти типы, разложить по ним обращения, прикинуть все нужные интеграции, сделать верификации и построить процессы так, чтобы все это было алгоритмизируемо.

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

Поэтому мы не пытались расписать все сценарии и полностью заместить специалиста поддержки искусственным интеллектом. Вместо этого мы постарались создать удобный инструмент на базе AI, с помощью которого любой специалист сможет быстро разобраться в проблеме и помочь клиенту. При этом не терять человечность ответов и делать их даже более дружелюбными.

Для этого мы решили внедрить генеративные подсказки — варианты ответов, автоматически создаваемые большой языковой моделью. LLM определяет, с чем пришел пользователь, как ему помочь, и дает инженеру готовую подсказку, которую он может скорректировать и отправить клиенту. 

Собрать генеративные подсказки — не такая уж и простая задача. Для этого мы:

1. Вычитали большой пласт обращений. Потратили на это месяц, разбирались, какие вообще есть типы обращений, что интересует клиентов, как можно классифицировать эти обращения.

2. Кластеризовали данные с помощью машинного обучения. 

3. Обучили модели классификации, чтобы понять, какие у нас есть тематики.

4. Поняли, что есть тематики обращений, которые обычной документацией не закрываются. Поэтому мы сделали дополнительную, кастомную базу знаний. В ней мы сами готовим документацию, оформляем ее под формат RAG-сервисов и учитываем специфику работы сервиса. Например, смысловой блок документа не должен превышать 100 слов.

5. Собрали базу знаний для модели, которую непрерывно обновляем и пополняем.

6. Дальше много промптили, подбирали модели. Для этого у нас в Cloud.ru есть Evolution AI Factory — облачная среда с AI- и ML-инструментами. Например, в Evolution Foundation Models вы можете выбрать готовые LLM- и AI-модели и адаптировать их под свои задачи. 

Так мы получили простой и удобный инструмент, который учитывает проблему пользователя, возможности наших сервисов, и всегда находится под рукой у инженера. В интерфейсе коллег это выглядит так:

• лампочка хранит сгенерированные подсказки;

• карандаш исправляет орфографические и пунктуационные ошибки;

• молния улучшает тон всего ответа (о ней расскажу дальше);

• лист копирует подсказку в рабочую зону.

Что нам дали генеративные подсказки:

• АНТ сократилось на 25 минут. Это влияет и на все прочие метрики поддержки: SLA на ответ, количество отработанных тикетов.

• Покрыли 62% входящего потока обращений. 

• Получили фундамент для дальнейшей автоматизации. 

Когда я выступал на GoCloud, нашей конференции про облака и AI, я спросил у аудитории, как она понимает дружелюбие. Кто-то ответил, что текст без ошибок это и есть уважительное обращение, кто-то, что должно быть коротко и ясно, а кто-то написал, что дружелюбие — это когда тебе в целом отвечают.

Это подтверждает гипотезу, что у каждой компании есть свое понимание, что есть дружелюбие, как и у каждого человека.

Поэтому, когда мы говорим, что хотим сделать дружелюбные ответы, то имеем в виду комплекс мер. И у себя мы решили эту задачу таким образом:

1. Адаптировали Tone of voice Cloud.ru (голос бренда), который ранее был разработан департаментом бренд-маркетинга и коммуникаций, для инженеров поддержки и провели обучение инженеров по Tone of voice.

2. Создали чек-лист для LLM. Чтобы замерить прогресс и оценить, стали ли инженеры отвечать дружелюбнее, сделали объективную метрику: разложили ToV на чек-лист из 10 простых вопросов, на которые можно ответить «да» или «нет». Например, есть ли в тексте канцеляризмы, которые усложняют ответ инженера и добавляют лишний официоз. Модель проходит по чек-листу и анализирует каждый ответ, который уходит клиенту. Благодаря этому у нас появилась метрика, которая оценивает дружелюбие ответа и соответствие Tone of voice в целом.

3. Добавили в рабочее место инженера ту самую молнию, которую показывал на скрине выше. Этот инструмент учитывает Tone of voice, добавляет в текст структуру и выдает ответ в нужном формате. Работает так: инженер пишет ответ, нажимает на одну кнопку и получает текст, который разбит на абзацы, в нем нет ошибок, ссылки вставлены правильно, а сложные предложения стали простыми и читаемыми.

Сейчас мы уже видим прогресс по метрике Tone of voice и, самое главное — мы перестали видеть фидбэк клиентов про недостаток дружелюбия в ответах.

Один из важных показателей для нашей компании — уровень удовлетворенности наших клиентов (NPS). За год этот показатель вырос на 17 пунктов, и многие клиенты отметили рост качества и скорости работы технической поддержки. 

Если смотреть на фактическое использование LLM нашими сотрудниками, мы видим такую статистику: 47% ответов были даны с использованием генеративного AI. Либо это была генеративная подсказка, либо улучшение текста, либо исправление ошибок. При том, что у инженеров нет KPI на создание ответов с AI — каждый специалист решает сам, когда обращаться к этим инструментам.

Дальше мы перешли к работе над AI-агентом, который уже отвечает на 10% запросов наших клиентов, а к концу года мы доверим ему до 70%. О том, как мы создавали агента, какие результаты получили и как AI будет менять работу поддержки дальше — расскажу во второй части.