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

Если вы хоть раз смотрели детектив, то понимаете, как выглядит первичный этап в ML-проекте: проверяется множество гипотез, много времени уходит на сбор данных и погружение в процессы, планы часто меняются по ходу работы, все постоянно торопят. Несмотря на неопределенность, именно этот этап позволяет раскрыть весь потенциал внедрения машинного обучения, а значит важен как для бизнеса, так и для data scientist'ов.

Меня зовут Настя, я DS Team Lead в компании Домклик. В мае этого года мы запускали data science в команде «Речевые сервисы». За полгода реализовали несколько успешных проектов, об одном из них пойдет речь.

Почему важно критически анализировать постановки задач от заказчика

Когда мы запускали речевую аналитику, была потребность увеличить качество работы колл-центра, в котором работает несколько тысяч человек. Его функция — упростить процесс выдачи ипотеки клиенту. Примерно так выглядит типичный звонок:

Клиент: Алло.

Оператор: Здравствуйте, Юлия Владимировна.

Клиент: Да, здравствуйте.

Оператор: Сбербанк России, меня зовут Роман, я звоню по поводу вашей заявки на ипотеку, есть пару минут свободных сейчас у вас?

Клиент: Да, могу говорить.

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

Клиент: Угу

Оператор: Скажите, у вас с первоначальным взносом будут наличные средства, правильно?

Клиент: Нет, материнский капитал.

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

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

• искать ключевые слова под текущую аналитику продаж;

• обнаруживать отдельные фразы в диалогах;

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

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

Как небольшая разметка может помочь разобраться в важных аспектах задачи

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

• У нас много общения, не связанного с продажами.

• Клиенту может быть предложено несколько продуктов, мы хотим анализировать их все (у нас 10).

• Для анализа продаж нужно слушать все звонки у клиента, обычно их 10-20, продолжительностью иногда по 15-20 минут.

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

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

• Наверняка, есть еще важные факторы, о которых мы пока не знаем.

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

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

Вот как выглядела таблица с разметкой:

За счет чего удалось добиться максимального результата?

• Разметчик — один из сотрудников колл-центра, с большим опытом и пониманием специфики.

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

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

• Проверку гипотез полезно формулировать в виде бинарных вопросов. Так проще работать разметчику и точнее получается результат.

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

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

Что получили в результате?

• Подтвердили или опровергли имеющиеся гипотезы.

• Получили статистику по продажам каждого продукта: почему покупают и не покупают.

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

• Получили представление о проблемах, ведущих к снижению продаж.

Как за один день узнать больше, чем за месяц работы с данными

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

Самый эффективный способ погрузиться в работу сотрудников — это увидеть ее вживую своими глазами. Для этого мы организовали гембу: посетили один из наших колл-центров. Там мы:

• понаблюдали за работой реальных сотрудников;

• пообщались с их непосредственными руководителями и посмотрели на ситуацию также их глазами;

• получили представление о процессе «изнутри».Оказалось, это непростая работа. Менеджеры сделок с недвижимостью универсальны. Есть несколько систем, между которыми они должны переключаться, да еще и быстро, чтобы не тратить время клиента. 

Вот чем нам помогло это посещение:

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

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

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

• Проверили наши идеи по оптимизации процесса. Например, предложения по справедливому учету продаж получили практическое подтверждение. 

Переходим к постановке задачи

Наконец, мы готовы сформулировать целевое решение. Оно нам подходит, если имеет понятную бизнес-ценность для заказчика и понятную ML-постановку для data scientist'ов.

С точки зрения ML хотим:

• Скорить все звонки и выделять интервалы общения по каждому из продуктов.

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

• Определять реакцию клиента на предложение о покупке (клиент согласился купить/отказался/думает).

Ожидаем следующий бизнес-эффект:

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

• Понимаем эффективность работы продавца при каждом звонке (по реакции клиента и отработке возражений).

• Оцениваем навыки продаж у сотрудников, понимаем, у кого лучше получается продавать.

• Находим лучшие практики продаж и масштабируем на всех сотрудников.

Подготавливаем качественную ручную разметку

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

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

• Сотрудники не мотивированы делать качественную разметку и не будут тратить свое время на вдумчивое заполнение.

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

«Лучше мало, но хорошо, чем много, но плохо». Ни для кого не секрет, что данные — это 80 % успеха модели. Чтобы её качество не оказалось гораздо хуже потенциально достижимого, мы много внимания уделили ручной разметке.

Вот несколько важных моментов, о которых стоит сказать:

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

• Данные в разметке = данные в проде. Если мы собрались применять модель ко всем звонкам, то и в разметку должны попасть звонки без фильтраций. Это важно не только для модели, но и для получения честных метрик на подвыборке, выделенной для тестирования.

• С самого начала полезно «обкатать» разметку на одном человеке (не погруженном в задачу). Это поможет выявить слабые места в инструкции, частые проблемы и вопросы.

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

Вместо заключения

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