Доверие клиентов и простота использования OTT-сервисов, таких как WhatsApp, сузили источники дохода для операторов связи. Чтобы увеличить или хотя бы сохранить текущую долю рынка, хорошее обслуживание клиентов в сети становится все более важным. В этом документе представлен подход к отслеживанию опыта мобильных клиентов в режиме реального времени и доступа к условиям, которые побуждают пользователя звонить в центр обслуживания клиентов телекоммуникационной компании.
Контур
- Вступление
- Данные
- Исследование данных
- Предлагаемый метод - ограниченные случайные леса
- Интерпретируемость
- Показатели эффективности
- Эксперимент и результаты
Вступление
Основная проблемная статья, на которую обращаются внимание, заключается в том, как заранее оценить опыт клиента, прежде чем он позвонит в центр обслуживания клиентов и пожалуется на это.
Наличие метода, который может прогнозировать взаимодействие с пользователем в режиме, близком к реальному времени, может помочь операторам связи выявлять проблемы и активно их решать. В худшем случае, когда клиент звонит в службу поддержки, информация может быть передана руководителю службы поддержки клиентов в качестве контекста, в котором происходит звонок.
В документе упоминается: «Мы исходим из предположения, что о плохом опыте пользователя можно судить, глядя на производительность сети при использовании им определенных мобильных приложений и услуг».
В результате подмножество пользователей, на которые будет ориентирован этот подход, - это те, кто регулярно использует мобильные данные.
Данные
Как и в случае с электронной коммерцией, в данных телефонной компании нет явных признаков хорошего или плохого пользовательского опыта. Если нет звонка в службу поддержки, то впечатление можно считать хорошим, но как насчет плохого опыта? Звонок в службу поддержки клиентов для регистрации жалобы свидетельствует о неудовлетворительном опыте работы. Но какая транзакция в сети должна быть связана с плохим опытом, а какие с хорошим опытом?
Здесь снова делается предположение, что транзакции с сетью непосредственно перед обращением в службу поддержки являются плохими, а после - хорошими, потому что, надеюсь, проблема была решена. Образец функций можно увидеть на Рисунке 1 ниже,
Возможно, вы заметили, что функции разработаны как совокупное использование данных для каждого приложения в час для пользователя. Каналы данных в сети показывают схему использования, а журналы вызовов службы поддержки клиентов содержат информацию о соответствующих метках для функций.
Функции, извлеченные из фида данных, показаны на рисунках 2 и 3 ниже.
Теперь проблема сводится к проблеме двоичного прогнозирования, то есть с учетом пользовательского контекста предсказать, является ли опыт хорошим или плохим.
Исследование данных
В данных, которыми поделились авторы, есть некоторые выводы.
Пространственное распределение
График выше показывает, что в большинстве перегруженных районов скорость повторной передачи выше и количество обращений в службу поддержки клиентов выше. Это довольно интуитивно понятно.
Временное распределение звонков
Временное распределение звонков также интуитивно понятно. Существует ежедневный график с пиковыми и внепиковыми периодами.
Абоненты и не звонящие
Графики на рисунке 6 показывают, что вызывающие абоненты интенсивно используют данные и имеют большее количество повторно переданных пакетов (обратите внимание на длинные хвосты) по сравнению с не вызывающими абонентами.
На диаграммах на рис. 7 показаны приложения и устройства для вызывающих и не вызывающих абонентов. Я не вижу здесь многого, что стоило бы объяснять (вы видите что-нибудь интересное?).
Ограниченный случайный лес (RRF)
Ограниченный случайный лес (RRF) был предложен авторами для задачи бинарной классификации. Случайный лес можно определить как
где M - количество деревьев, I - индикаторная функция, которая сопоставляет точку данных x с классом, а T_m - это m-е дерево с параметрами theta_m.
Ограничение в RRF относится к функциям. Выбор функций для каждого дерева не является случайным для RRF, но контролируется разработчиком модели, чтобы гарантировать интерпретируемость каждого дерева. Объекты сгруппированы по категориям, а деревья обучаются исключительно по категории объектов. Например. некоторые из категорий, обсуждаемых в статье:
- заявка
- Тип приложения
- Клетка
- Зона расположения
- Модель устройства
- Производитель устройства
- Сетевые KPI
Интерпретируемость
В случае, когда RRF приводит к звонку в службу поддержки или предсказанию плохого опыта, вы можете посмотреть на составляющие деревья, которые также предсказывают плохой опыт, и проанализировать эти деревья, чтобы понять проблему. Поскольку каждое дерево обучается по категории характеристик, его можно интерпретировать по своей природе. Для интерпретации вам нужно выяснить,
- какой листовой узел дерева решений активируется при прохождении через него данных, а затем
- следуйте пути решения, чтобы определить потенциальную проблему.
Например. в дереве решений, показанном на рисунке 11, если прогнозирование звонков в службу поддержки является результатом второго конечного узла дерева, то проблема может быть идентифицирована как высокая скорость повторной передачи из-за Apple Maps.
Показатели эффективности
Из-за несбалансированного характера задачи авторы используют метрики точности, отзыва и оценки F1. Это довольно стандартный выбор для несбалансированного корпуса.
Эксперимент и результаты
Для устранения классового дисбаланса отрицательные примеры отбираются случайным образом с заменой и являются гиперпараметром эксперимента. Категориальный признак закодирован одним горячим способом.
Авторами проведено 2 эксперимента. В эксперименте 1 используются агрегированные характеристики за час, а в эксперименте 2 - за 24 часа.
Производительность RRF сравнивается с базовой линией (случайное назначение на основе исторического распределения классов), SVM, GBT и случайным лесом.
«Ансамбли моделей RRF достигают улучшения показателя f1 примерно на 85% и 57% по сравнению с исходным уровнем при использовании подходов 1 и 2 соответственно. RRF также выгодно отличается от современных классификаторов в обоих экспериментах ».
Одно из деревьев, построенных на группе переменных приложения, показано на рисунке 11.
Дерево указывает пути, ведущие к потенциальному обращению в службу поддержки, однако в статье неясно, как используются такие деревья. Есть ли какой-либо диагноз, который будет предложен сетевым операторам? Если да, то каков будет этот диагноз?
Заключительные замечания
В документе представлен интересный подход к маркировке объектов с хорошим и плохим опытом работы в телекоммуникационной сети, а также идея ограниченных случайных лесов для создания интерпретируемых деревьев в лесу. Однако подробное обсуждение интерпретируемости помогло бы лучше понять эту технику. Например. что происходит, когда деревья становятся слишком глубокими?
Естественным продолжением этой работы будет использование DNN для прогнозирования опыта, но это будет происходить за счет интерпретируемости.
Вы можете прочитать полный документ в разделе На пути к прогнозированию качества обслуживания клиентов в режиме реального времени для операторов электросвязи.
