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

Как устроен чат-бот?

У клиентов часто возникают вопросы по различным продуктам и процессам Банка.

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

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

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

  2. Либо осуществляем перевод на оператора (теряя автоматизацию — одну из ключевых метрик чат-бота).

  3. Либо производим перевод на чат-бота второй линии поддержки (с применением генерации ответов, используя RAG на корпоративной базе знаний). Но в этой статье речь пойдет именно про чат-бота первой линии (без использования генеративных ответов).

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

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

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

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

Почему такой сложный подход ?

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

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

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

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

Метрики

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

Понижение VOC (Voice of Client / Удовлетворенность пользователя) провоцируется ответами бота даже на неуверенные с точки зрения модели запросы. Никакому клиенту такое поведение не понравится и он решит поставить плохую оценку после общения. Таким образом, у нас существует некоторый размен между автоматизацией и удовлетворенностью, который регулируется требованиями бизнеса.

Более детально о комплексе ML-моделей

Комплекс ML моделей, обрабатывающих сообщения пользователей в диалоге с ботом, достаточно обширен и не ограничивается определением интентов.

Каждая из них направлена на повышение VOC (Voice of Client / Удовлетворенность пользователя) или автоматизации. 

Начнем по порядку:

Модель склонности к постановке низкого VOC

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

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

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

  • интенты, которые предсказывала соответствующая для этого модель,

  • статусы по текущим обращениям в банке,

  • темы банковских обращений,

  • различные статистики по сообщениям, которые писал клиент в чат,

  • количество диалогов за определенный промежуток времени (всех  / с трансфером на оператора  / с лайком или дизлайком),

  • выявленные категории негатива за последнее время.

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

OCR

В мобильном приложении клиенты всё чаще прикрепляют скриншоты к сообщениям: списания средств, пользовательский интерфейс, SMS от Банка.

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

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

Модель определения интента

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

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

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

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

  1. Предообучили её на специализированном банковском корпусе и реальных чат-диалогах, сместив фокус, в сторону банковского домена.

  2. Провели дистилляцию для поддержания установленных ограничений по скорости ответа, сократив число параметров модели практически вдвое и не потеряв качество на метриках.

  3. Применили эвристики при финальном дообучении на задачу классификации интентов:  оригинальный пулинг над выходами энкодера; Layer-Wise LR Decay; SWA; конвертация в ONNX формат и др.

В ходе ретроспективного скоринга был зафиксирован значимый рост модельной метрики, что являлось хорошим результатом и послужило проведению трехнедельного A/B теста. Удалось пронаблюдать рост VOC и повышение доли диалогов, в которых модель правильно распознала все интенты пользователя. А на текущий момент модель внедрена на весь поток и обслуживает все вопросы физических лиц, пользующихся приложением Альфа-Банка на мобильных устройствах.

Модель пулов

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

Но что происходит, когда порог не преодолевается?

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

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

Одновременно с этим в чате появляются «быстрые кнопки-подсказки»: мы берём top-k интентов из основного классификатора интентов, оставляем только те, что принадлежат пулу и отображаем клиенту наиболее релевантные варианты. Пользователь может нажать одну из кнопок, чтобы уточнить своё намерение, и бот сразу продолжит диалог с учётом выбора.

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

Модель лайков

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

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

На помощь пришла разработанная модель «лайков», которая сейчас активна в чат-боте. На каждом вопросе клиента она одновременно обрабатывает пару: вопрос клиента — потенциальный ответ бота, заранее (до ответа бота) моделируя ответную реакцию пользователя — вероятность поставить «дизлайк». Таким образом, это позволяет автоматически переводить диалог на оператора в случае высокой предрасположенности пользователя к негативной реакции, наращивая дополнительную автоматизацию.

Модель рекомендаций интентов

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

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

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

Для этого мы берём историю диалога, убираем из неё последнюю реплику клиента (чтобы модель «смотрела вперёд», а не назад) и на её основе учим модель прогнозировать, что клиент с высокой вероятностью сделает дальше.

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

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

Модель конца диалога

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

Текущий процесс сбора обратной связи через SMS и пуш-уведомления показывает низкую конверсию: многие клиенты просто не отвечают и банк теряет важные сигналы о качестве работы бота. Чтобы повысить долю откликов, мы разработали модель, которая в реальном времени, учитывая контекст последних сообщений (о котором говорилось ранее), определяет момент завершения диалога. В этот момент в самом чате автоматически появляется всплывающая форма для оценки взаимодействия. Появление такого «inline» окна сразу после диалога увеличивает вероятность того, что клиент оставит отзыв, а значит, мы получаем более репрезентативные данные для улучшения моделей и сценариев.

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

Заключение

Подводя итог, каждое нововведение проходило качественную офлайн-оценку и A/B-тестирование, что позволило убедиться в реальном росте бизнес-метрик: автоматизация возросла на несколько процентов, что сильно помогло Банку сэкономить на колл-центре сотни миллионов рублей, а средний VOC показал уверенную положительную динамику.

Дальнейшие шаги — это более глубокая персонализация через user-profiling, расширение базы знаний и улучшение RAG-генерации для внедрения на бОльший поток пользователей. Благодаря такой поэтапной, data-driven стратегии мы не только укрепляем позицию Альфа-Банка как технологичного лидера, но и создаём по-настоящему живое, дружелюбное общение с клиентом — быстрое, точное и максимально удобное.

Комментарии (0)


  1. PereslavlFoto
    19.09.2025 10:06

    Я никогда не пользовался этим чат-ботом и всегда просил оператора.

    Как я должен вести себя в чате, чтобы чат-бот перестал задавать мне наводящие вопросы и сразу переключал к людям?

    Спасибо.


  1. PereslavlFoto
    19.09.2025 10:06

    В режиме оператора я задаю вопрос, решение которого требует 5 минут.

    Через 10 минут отвечает Первый оператор, задаёт вежливый встречный вопрос и отключается. Отвечаю ему.

    Через 10 минут отвечает Второй оператор, задаёт уточняющий вопрос и отключается. Отвечаю ему.

    Через 10 минут отвечает Третий оператор. Каждому из них приходится заново читать всю переписку.

    Что сделать, чтобы операторы не менялись по три-четыре раза за один диалог, чтобы один оператор быстро обсудил мой вопрос?

    Спасибо.