кейс

2

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

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

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

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

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

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

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

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

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

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

Чтобы быстро оценить ценность решения, разработчики начали с самого простого представления клиентов в виде «мешка слов» (англ. bag-of-words — упрощенное представление текста в виде массива слов и указанием их количества), состоящего из символов их событий.

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

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

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

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

Технические проблемы

1. Определение оптимального окна для событий Было замечено, что увеличение окна событий снижает производительность модели, поскольку наиболее значимые события, как правило, происходят недавно. Однако слишком сильное уменьшение окна привело бы к снижению охвата. После нескольких тестов было выбрано 3-часовое окно.

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

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

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

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

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

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

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