Как мы внедрили ИИ для улучшения скриптов в колл-центре

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

Вот почему мы запустили пилот с LLM (Large Language Model), чтобы повышать эффективность скриптов, основанных на анализе успешных и неуспешных диалогов.

Зачем колл-центру LLM

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

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

В идеале, модель должна была бы выполнять несколько ключевых функций:

1. Анализировать успешные и неуспешные диалоги — чтобы понять, какие элементы скрипта работают, а какие нет.
2. Выявлять, на каком этапе диалога теряется клиент — например, если оператор не смог правильно ответить на возражение или не выявил потребности.
3. Предлагать корректировки в реальном времени (в будущем) — чтобы при возникновении проблем модель могла предложить варианты улучшений прямо во время работы с клиентом.

Каждое обновление сценария диалога требует анализа сотен или тысяч диалогов. Это требует значительных временных затрат, а ошибки, возникающие, например, из-за невнимательности, могут привести к неэффективным изменениям. Именно поэтому мы решили использовать Large Language Model (LLM), дообучив уже существующую модель (Mistral 7B), чтобы она могла автоматически предлагать улучшения в скриптах, адаптированные под текущие условия рынка.

Подготовка данных и fine-tuning

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

• Успешные диалоги — те, где оператор закрыл сделку или получил заявку.
• Неуспешные диалоги — те, где клиент отказался.

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

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

Для этого мы:

• Загрузили собранные транскрипты диалогов и разделили их на части, чтобы модель могла понимать контекст разговора (например, реплики клиента и оператора). Для того, чтобы дообучить модель мы взяли более 2000 удачных диалогов и 600 неудачных.
• Создали дополнительные примеры успешных и неуспешных решений по конкретным вопросам. Это помогло модели обучаться на том, что работает, а что нет. 

Использование метрик и анализ производительности

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

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

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

После каждой итерации обучения мы проверяли эти метрики, чтобы увидеть, насколько хорошо модель справляется с задачей. Если perplexity была высокой или BLEU-score низким, это подсказывало, что модель нуждается в улучшении. Мы корректировали обучение, чтобы повысить точность модели и улучшить ее способность генерировать правильные ответы в реальных диалогах.

Проблемы и сложности

При дообучении модели мы столкнулись с несколькими проблемами, которые потребовали дополнительного внимания.

1. Операторы иногда идут не по скрипту

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

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

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

2. Недостаток контекста

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

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

Как теперь проходит процесс корректировки скрипта с LLM

После того как мы завершили дообучение, модель стала частью нашего рабочего процесса. Теперь, когда мы видим, что показатели эффективности (KPI) начинают снижаться, мы используем модель для анализа транскриптов звонков. Модель выявляет, на каком этапе общения с клиентом возникли проблемы, и предлагает исправления.

Каждое изменение в скрипте проходит A/B-тестирование среди операторов, чтобы оценить, какой вариант работает лучше всего. Тот вариант, который дает наилучшие результаты, внедряется в основную практику.

Итоги и перспективы

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

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