{"id":14268,"url":"\/distributions\/14268\/click?bit=1&hash=1e3309842e8b07895e75261917827295839cd5d4d57d48f0ca524f3f535a7946","title":"\u0420\u0430\u0437\u0440\u0435\u0448\u0430\u0442\u044c \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a\u0430\u043c \u0438\u0433\u0440\u0430\u0442\u044c \u043d\u0430 \u0440\u0430\u0431\u043e\u0447\u0435\u043c \u043c\u0435\u0441\u0442\u0435 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f71e1caf-7964-5525-98be-104bb436cb54"}

Принятие решений со скоростью потоков событий на живом примере

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

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

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

Хьюстон, у нас проблема!

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

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

Каждые 5 минут ожидания на 10 000 входящих звонков — это 800 часов загрузки линий и операторов.

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

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

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

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

Реальный пример

В прошлом году мы в Fabrique.AI реализовали кейс по предсказанию причины обращения клиентов в колл-центр телеком-оператора в момент звонка.

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

Кажется очевидным, что если клиент сталкивается с проблемой сейчас, то нужно брать самые последние события, предшествующие звонку. Данные за вчера или неделю назад окажутся мало информативными. В рассматриваемом кейсе 80% причин обращения попадают в 2-часовой диапазон до момента звонка.

При этом невозможно заранее предугадать, кто из клиентов сегодня позвонит. Это значит, что нужно:

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

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

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

Решение задачи

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

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

Как только задачи распределены начинается реализация. Решение разворачивается внутри ИТ контура. Подключаются данные. Реализуется бизнес-логика сценария обработки данных. Строятся онлайн агрегаты. Производится обучение AI алгоритмов. Алгоритмы декомпозируются и вводятся в эксплуатацию. Настраиваются метрики. Реализуется хранилище метрик, признаков и обратной связи. Производится обучение команды дата аналитиков. Проводится тестирование. Проект готов к приемке и вводу в эксплуатацию.

Полный цикл реализации первого кейса объединенной командой занял 3 месяца.

Реализация каждого последующего кейса сократилась до 2-4 недель. Время разработки и ввода в эксплуатацию новой версии AI алгоритма составило от 1 до 5 дней в зависимости от сложности алгоритма. Ввод в эксплуатацию занимает 5-10 минут. Внесение изменений в конфигурацию уже введенного в эксплуатацию сценария осуществляется онлайн без остановки процесса обработки.

Прошло 3 месяца. Что имеем на выходе?

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

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

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

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

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

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

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

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

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

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

0
1 комментарий
Asf

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

Обработка потоков данных

Это НЕ обработка потока

Строятся онлайн агрегаты.

Это микросервисы

Ответить
Развернуть ветку
-2 комментариев
Раскрывать всегда