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

Почему генеративный ИИ может справиться с задачей оператора колл-центра?

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

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

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

Чтобы успешно внедрить Data Science, важно не только разбираться в технической составляющей, но и досконально изучить этот самый бизнес-процесс, куда планируется его внедрять. Уверен, вы с этим процессом сталкивались как клиент, поэтому не составит труда понять, что происходит на другом конце провода.

Как устроен процесс обслуживания клиентов?

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

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

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

А, обобщая, работа оператора состоит всего из 6 пунктов:

• Прочесть вопрос.

• Изучить данные клиента.

• Вспомнить информацию с обучения.

• Задать уточняющие вопросы.

• Ответить на вопрос клиента.

• Совершить целевые действия.

Какие модули необходимы для автоматизации процесса?

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

• передать необходимый набор данных о клиенте,

• интегрировать через RAG-пайплайн c базой знаний компании,

• реализовать модуль доспрашивания,

• и научить совершать целевые действия в интерфейсе через классификатор действий.

Далее, подробнее разберём каждый из модулей.

№1. Данные клиента

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

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

Как ускорить процесс интеграции данных? Правильно:

Переиспользовать действующие интеграции до интерфейса оператора.

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

Современные LLM умеют из коробки работать с табличными данными, если сделать всего две настройки.

• Во-первых, необходимо названия полей в таблице сделать читаемыми для человека. Если поле будет называться field 124, то большая языковая модель не поймет, что в нём содержится. Да и вы тоже.

• Во-вторых, модели эффективнее обрабатывают табличные данные, если их перевести в формат Markdown. Если выполните эти условия, то получите точность ответов выше 90%, что сравнимо с человеком.

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

№2. RAG — интерфейс работы с базой знаний

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

В целевой картине база знаний должна представлять из себя продакшн систему с развитыми процессами по обновлению и наполнению информации, системой контроля доступа, возможностью интеграции по API и, конечно, контролями полноты и качества знаний. Возможно, в вашей компании она будет представлена в виде набора Word и Excel документов. В таком случае при внедрении ИИ вы станете драйвером развития базы знаний.

RAG (Retrieval Augmented Generation) по определению состоит из генеративной и retrieve-частей. Как вы знаете, LLM отлично справляются с задачей ответа на вопросы по документу, если на вход им подать документ и вопрос, на который нужно ответить.

Однако в базах знаний обычно содержатся десятки тысяч таких документов. Если бы они даже все смогли пролезть в LLM в рамках одного запроса, то их обработка существенно бы замедлила ответ клиенту. Ввиду этой особенности эффективнее сначала, максимизируя recall, найти релевантные для ответа на вопрос клиента кусочки статей более легковесной моделью и подготовить их для передачи в LLM, что как раз и делает retrieve-часть.

Успех RAG-пайплайна на 90% зависит от реализации retrieve-части и полноты базы знаний.

Очевидно, что если в базе знаний нет ответа на вопрос, то, как бы вы качественно ни реализовали поиск по ней, помочь клиенту не сможете. В результате качество работы RAG-пайплайна в первую очередь зависит от наличия информации в базе знаний. А во вторую — от качества работы retrieve-части. Выбор LLM и её дообучения не влияют на итоговое качество.

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

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

1. Определите метрики качества retrieve-части, иначе вы не будете знать на сколько она хорошо работает.

2. Обучите эмбеддинги на своем домене данных, таким образом вы передадите знания находящиеся в контуре вашей компании в модель.

3. Используйте reranker для повышения качества ранжирования на основе размеченных данных.

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

   Напишите в комментариях, если вы хотите узнать о нашем опыте подробнее и мы выпустим отдельную детальную статью про этот этап.

№3. Модуль доспрашивания

Вы задаёте уточняющий вопрос собеседнику с единственной целью — сократить неопределённость в пространстве возможных ответов. Действительно, не озвучивать же по очереди все возможные интерпретации вопроса, а потом ответ для каждой из них? Соответственно, чтобы предоставить ответ клиенту, необходимо определить пространство возможных ответов. Далее, в формате игры «Акинатор» выбрать тот, который поможет клиенту решить его проблему.

Контекст для доспрашивания поможет получить классификатору интентов, из которого вы вытащите топ наиболее вероятных интентов. Далее, передаёте их описание в промпт LLM и просите сформировать ряд уточняющих вопросов. Описание можно составить как при помощи разметчиков, так и при помощи репрезентативного множества вопросов.

Недавно один банк мне привез картхолдер, но не привез карту, как я просил. Дело в том, что я отправил запрос в чате в виде двух отдельных сообщений. Оказалось, что не только чат-боты, но и операторы не всегда умеет обрабатывать контекст диалога.

№4. Модуль совершения целевых действий

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

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

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

№5*. Модуль цензурирования

Галлюцинации LLM, а также спланированные на них атаки могут привести к тому, что генеративная модель (и вы, как владелец, за компанию) реализует один из юридических, репутационных или финансовых рисков. Для защиты просто необходима модель-охранник с небольшим количеством обучаемых параметров, что понижает вероятность её взлома. Действительно, в таком случае у модели снижается число степеней свободы на этапе принятия решений и она начинает действовать строго по регламенту, как мы и хотели.

Набор регулярных выражений — ваш первый идеальный кандидат, так как он содержит минимальное количество параметров. Некоторые компании и вовсе ограничиваются только им. Легковесный классификатор на основе tf-idf или простая свёрточная сеть — второй кандидат, менее идеальный, но более «робастный», рекомендуется применять в комбинации с первым.

Ввиду высокой стоимости ошибки и низкой стоимости затрат на цензурирование, этот модуль целесообразно применять как к входным, так и к выходным данным из LLM.

№6*. Векторное кэширование

Кэширование пар «вопрос-ответ» позволит сэкономить до 70 % затрат на аренду или покупку серверов с GPU. Действительно, поиск ответа в векторном хранилище стоит на один-два порядка дешевле по сравнению с генерацией через LLM. Получается, нам нужно накопить базу из пар «вопросов-ответов», определить триггеры для её обновления и перед отправкой вопроса в LLM попытаться ответить клиенту, используя более дешёвый ресурс. Давайте сначала идейно поймём, почему такое возможно.

Идея этого модуля появилась после общения с основателем одного из стартапов, который использовал LLM. По его опыта, порядка 70% процентом запросов были повторяющимися. Его инжинерный бэкграунд подсказал единственное правильное решение - кэширование. Оптимизация железа - это вопрос экономии ресурса для бигтеха, а для стартапа - вопрос выживания.

Но сначала рассмотрим, как нам это поможет.

• Во-первых, клиенты задают много одинаковых и похожих вопросов, на которые операторов учат отвечать в рамках обучающих курсов.

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

• В-третьих, текущие чат-боты содержат до десятка тысяч предзаготовленных ответов и успешно справляются с обработкой до 70% обращений клиентов.

Теперь разберём подробнее каждый из этапов.

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

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

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

В конце концов, можно вспомнить о том, чему учили на курсах по NLP, и, наконец, векторизировать все запросы клиентов, выделить в нём плотное подмножество и сохранить его в кэш вместе с ответами, сгенерированными LLM.

Как определить размер векторного кэша? Данный модуль позволяет вам сэкономить ресурс GPU, однако при использовании векторного кэша вы будете давать максимально похожий на вопрос клиента, но не в точности на него. Соответственно, вам нужно понять, насколько процентов в качестве вы готовы уступить за такую возможность сэкономить, подобрать порог качества на основе АБ-теста и наполнять векторный кэш таким образом, чтобы при использовании ответа из него качество было не ниже. Технически нужно установить связь между качеством ответа и расстоянием в векторном пространстве вопросов клиентов.

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

Соответственно, нам потребуется связать с парой «вопрос-ответ» на этапе формирования базы знаний кусочки статьи из базы, на основе которой были сформированы ответы. Далее, при изменении кусочков статей в базе знаний, находить в векторном кэше все связанные пары из вопросов-ответов и обновлять ответы. Дополнительным триггером могут стать новые популярные формулировки вопросов, которые не залогированы вместе с ответами LLM в векторном кэше.

Модификация чат-бота 1.0

Многие чат-боты на данный момент работают по схеме, представленной ниже.

Нейронная сеть классифицирует вопрос клиента на предзаготовленный список из нескольких сотен категорий. Далее идентификатор категории запускает некоторый сценарий обслуживания клиента. В рамках сценария клиенту могут быть заданы предзаписанные вопросы и далее выдаётся заранее заготовленный ответ.

По сути, в сценарии закэшированы ответы на самые частые классы вопросов клиентов.

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

Векторный кэш позволит модифицировать процесс создания сценариев.

Суммаризируем полученные знания, собрав все модули в единую схему.

• Система автоматизированного обслуживания клиентов получает на вход переписку с клиентом и данные, доступные оператору.

• Сначала пытается ответить на его вопрос на основе данных, представленных в векторном кэше, чтобы сэкономить до 70% вызовов LLM.

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

• Входные и выходные данные в LLM обрабатываются цензор-модулем, чтобы избежать юридических, репутационных и финансовых рисков.

Ключевые выводы

1. Уровень развития ИИ позволяет обслуживать клиентов на уровне естественного интеллекта.

2. Имитация оператора возможна за счёт интеграции данных о клиенте, реализации механизмов доспрашивания и RAG-пайплайна, а также классификатора целевых действий оператора.

3. Переиспользование интеграции данных в интерфейса оператора позволяет существенно ускорить процесс внедрения технологии.

4. Качеcтво работы RAG-пайплайна на 90% зависит от качества реализации retrieve-части.

5. LLM способны в сыром виде работать с табличными данными.

6. Векторный кэш позволит сэкономить до 70% вызовов LLM, а также заменить и улучшить чат-бота предыдущего поколения.

7. Переиспользование классификатора интентов позволит повысить качество доспрашивания.

8. Модуль цензурирования на основе классификаторов и регулярных выражений защитит ваше решение от атак и галлюцинаций.

Статья получилась достаточно объёмной. Спасибо, что дочитали до конца. Подписывайтесь на канал «Нескучный Data Science» (10000+ подписчиков), где мы делимся нашими успехами и неудачами, постим статьи, анонсы конференций и запускаем соревнования по анализу данных от команды Лаборатории машинного обучения. Также подписывайтесь на канал «Нескучный Data Science Jobs», если тоже хотите внедрять ИИ в технологической компании.

Не успели разобраться в том как работает ИИ? Практика показывает, что руководителям, которые успешно внедряют машинное обучение в свои процессы не требуется уметь писать код и даже брать производную. Научим и вас применять Data Science на практике, присоединяйтесь к курсу для менеджеров «Принятие решений на основе данных».