скрипты яндекс такси для оператора

Как мы учили искусственный интеллект отвечать на вопросы в поддержку. Опыт Яндекс.Такси

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

В Яндекс.Такси из двух вариантов выбрали третий — с помощью машинного интеллекта создать техподдержку с человеческим лицом. Меня зовут Татьяна Савельева, моя группа занимается машинным обучением на неструктурированных данных. Под катом — делюсь пользовательскими инсайтами, рассказываю как автоматизировать сложный процесс, организовать работу совершенно разных команд и, конечно же, применить на практике Deep learning и технические хаки (куда без них).

Зачем вообще что-то автоматизировать?

Казалось бы, зачем изобретать многоступенчатую структуру поддержки — наймите побольше людей. Возможно это сработает, если в поддержку приходит около 10 запросов в день. Но когда число пользовательских обращений стремится к миллиону (что для Яндекс Такси малый процент от поездок, однако абсолют впечатляет), приходится задуматься о более надёжной тактике: найти и обучить достаточное количество операторов, способных справляться с нетипичными проблемами в таких объёмах, как минимум, сложнее.

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

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

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

С чего начать?

Предположим, вам не повезло: водитель не приехал и не выходит на связь. Что произойдёт с вашим обращением в службу поддержки Яндекс.Такси?

Что можно оптимизировать, чтобы проблемы решались ещё быстрее? Начнём с первого этапа, где тикет направляется на одну из двух линий. Изначально выбор зависел от ключевых слов в запросе — работало, но точность определения была довольно низкой. Исправить это помог классификатор на основе классической нейросетевой модели-энкодера BERT.

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

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

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

Эксперимент удался: в 70% случаев операторы выбирали одно из предложенных сообщений, что позволило уменьшить время отклика на 10%. Кажется, пора полностью автоматизировать первую линию.

Нужен план. Что делает сотрудник первой линии?

Первым делом сотрудник определит тематику обращения: «Двойное списание с карты». Далее проверит способ оплаты, статус и сумму списания. Деньги списаны один раз: в чём может быть причина? Ага, вот оно: два уведомления подряд.

Что должна делать система автоответов?

Всё то же самое. Даже ключевые требования к ответам не изменятся:

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

Скорость
Особенно если ситуация критическая и ответ важен прямо сейчас.

Гибкость и масштабируемость

Задача со звездочкой: хотя началось создание системы поддержки с Такси, полезно перенести результат и на другие сервисы: Яндекс.Еду или Яндекс.Лавку, например. То есть при изменении логики поддержки — шаблонов ответа, тематик обращений и др. — хочется перенастраивать систему за дни, а не месяцы.

Как это реализовано

Этап 1. Определяем тематику текста с помощью ML

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

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

BERT предобучается на двух задачах с неразмеченными текстами. В первой 15% токенов случайным образом заменяются на [MASK], а сеть на основании контекста предсказывает исходные токены — это обеспечивает модели естественную «двунаправленность». Вторая задача учит определять связь между предложениями: два поданных на вход располагались подряд или были разбросаны по тексту?

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

Ещё немного об адекватности: для всех наших сервисов — в том числе Такси — была разработана целая библиотека модулей архитектур моделей и способов валидации порогов вероятностей. Она позволяет:

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

Шаблон: «Здравствуйте! Я всё проверил: поездка оплачена один раз. Деньги сперва „замораживаются” на вашей карте и только потом списываются, из-за этого банк может дважды оповестить об одной операции. Пожалуйста, проверьте выписку с банковского счёта, чтобы во всём убедиться. Если увидите там две списанные суммы, пришлите, пожалуйста, скан или фото выписки»

Правило: payment_type is “card” and transaction_status is “clear_success” and transaction_sum == order_cost

Только для шаблонов клиентской поддержки наши эксперты заполнили уже более 1,5 тысяч правил.

Этап 3. Выбираем ответ: соединяем соответствующие тематики текста и бизнес-правила для шаблонов

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

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

Финализируем

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

И снова к примерам. Топ самых популярных хотелок заказчиков (и как мы справляемся с ними без написания кода):

У Такси классные автоответы: хочу такие же в Яндекс.Еде

Чтобы подключить любую поддержку к нашей системе, потребуются четыре простых шага:

Логика поддержки поменялась, хотим новые правила

Пожалуйста — заполните новые правила в нашей админке. Система проанализирует, как изменения повлияют на процент автоответов*, учитывая, насколько востребовано было правило. Если все прошло успешно, заполненные правила превращаются в конфиг и подгружаются в ML-сервис. Ура! Прошло меньше часа, а бизнес-правила обновлены в production, не написано ни единой строчки кода, программисты не потревожены.

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

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

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

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

На тестовой выборке старая и новая модель сравниваются по специальным метрикам — точность, доля автореплая. Если изменения положительные, в production выкатывается новая модель.

Анализируем метрики: не просадить, не сломать

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

Однако как бы мы не старались, методы машинного обучения иногда выдают абсурдные реакции. После очередного обновления модели, мы отловили такой случай:

Пользователь: Спасибо водителю, машина приехала вовремя, водитель молодец, все прошло прекрасно!
Саппорт: Водителя накажем, такого больше не повторится.

Запуск, к счастью, был тестовый. А проблема была в следующем: модель училась отвечать на отзывы с рейтингом меньше 4, а мы иногда по ошибке показывали ей отзывы с 4 и 5 звёздами. Разумеется, из-за ограничений при обучении, ничего более умного нейронка ответить и не могла. При внедрении такие случаи редки (0.1% от общего количества) — отслеживаем их и принимаем соответствующие меры: на повторное сообщение пользователя ответит уже не нейросеть.

О выводах и планах на будущее

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

Модель автореплая закрывает порядка 60% первой линии, не просаживая при этом среднюю оценку пользователей. Планируем и дальше развивать метод и довести процент использования автоответов на первой линии до 99.9%. Ну и, конечно же, продолжать помогать вам — поддерживать в наших приложениях и делиться опытом об этом на Хабре.

Источник

Примеры использования скриптовых системных событий

Пошаговая настройка нескольких примеров использования системных событий.

Содержание

Запрос погоды для глобального атрибута

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

Создаем нужные атрибуты в справочнике «Атрибуты»:

Все атрибуты с типом значения «Число» (дополнительные параметры задавать не нужно) и признаком «Глобальный атрибут».

Чтение глобального атрибута в расширенном тарифе

В расширенном тарифе (скрипт тарифа можно получить, обратившись в техническую поддержку ООО БИТ «Мастер») возможно выбрать глобальный атрибут, в зависимости от значения которого можно менять стоимость поездки.

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

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

Далее настраиваем параметры наценок, в зависимости от того, как должна происходить наценка.

Проверка штрафов ГИБДД

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

Звонок, если водитель заехал в определенную зону/район

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

Нужен будет сценарий для телефонии.

Необходимы атрибуты «Атрибут флага дозвона» и «Атрибут последнего района» с типом «Число» и возможностью привязки к заказу и группе экипажей.

Проверка рейсов самолетов

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

Проверка слов в заказе

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

Смена группы экипажей у экипажа

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

Источник

6 способов, как службе такси справиться с наплывом заказов

1. Анализировать работу диспетчерской

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

Ошибки в работе диспетчерской

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

У диспетчеров отсутствуют навыки общения с клиентами и управления разговором. Например, клиент сообщил адреса: «С Бассейна в Пивной дворик», а диспетчер в ответ рассмеялась. Диспетчеры могут отвлекается на свои личные дела, на общение друг с другом, на обсуждение клиента в процессе звонка. Это также создаёт шум в диспетчерской, что мешает работе с клиентом.

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

Некачественная карта, диспетчер не находит адреса. Диспетчер не может найти на карте пункты «Бассейн Аквамарин» или «Торговый центр Восточный». Не может сходу ввести точный адрес места подачи и места назначения. В итоге оформление заказа затягивается, оператор злится, пассажир негодует. Число принятых заказов на одного оператора снижается, доходы службы падают.

Ошибки в работе диспетчерской, которые выявили специалисты Такси-Мастер в результате аудита 63 служб такси

Как найти и исправить ошибки в работе диспетчерской

Аудит бизнеса такси. Чтобы проанализировать рабочие процессы в службе такси, руководитель может заказать аудит бизнеса такси. Бизнес-консультант Такси-Мастер проверит работу диспетчеров и водителей, настройки программного комплекса. После он даст рекомендации, как улучшить работу диспетчеров и принять максимальное количество звонков.

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

Школа оператора. Куратор школы проанализирует работу диспетчеров и поможет выявить проблемы в их работе: долго принимают заказы, грубят, недовольны руководством и т.д. Далее куратор проведет с диспетчерами уроки, упражнения, тематические игры, тестирование по взаимодействию с реальными клиентами. По ходу обучения куратор отвечает на вопросы диспетчеров и руководителя службы, даёт обратную связь, следит, чтобы каждый участник обучения усвоил курс.

2. Запустить мобильное приложение для заказа такси

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

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

3. Подключить голосового робота

Голосовой робот — это сервис, который обрабатывает звонки клиентов без участия диспетчера. Он распознает адреса подачи и назначения, понимает атрибуты, создает заказ в программном комплексе Такси-Мастер.

Служба может выбрать, как и когда использовать голосового робота. Например, робот начинает работать только во время резкого роста заказов. Когда все диспетчеры заняты, робот придёт на помощь и не позволит службе упустить заказы. Клиентам не придется долго висеть на линии в ожидании ответа диспетчера. Робот примет звонок и оставит хорошее впечатление о службе.

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

4. Привлекать удаленного оператора

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

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

В программном комплексе Такси-Мастер есть специальный инструмент для удалённой работы операторов — Кабинет организации. Веб-кабинет работает через браузер. Не нужно устанавливать весь программный комплекс на компьютер оператора и дополнительно его настраивать. В Кабинете организации оператор, который работает вне офиса, принимает звонки, создаёт и редактирует заказы, рассчитывает примерную стоимость поездки, отслеживает передвижение автомобилей по маршруту.

Кабинет организации в программном комплексе Такси-Мастер

5. Взять еще одного оператора в штат

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

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

6. Подключить центр обмена заказами «TMMarket»

Центр обмена заказами «TMMarket» подойдет, когда служба может принять все заказы в часы пик или в другое время резкого роста заказов, но не может их все вывезти, потому что не хватает водителей. ЦОЗ позволяет увеличить количество машин на линии в часы пик в результате сотрудничества с другими службами. Также служба может сама помочь другим службам-партнёрам с вывозом. За вывоз заказов друг друга службы получают комиссию.

Во время наплыва заказов заявка на поездку поступает в службу и автоматически отправляется в «TMMarket». ЦОЗ подбирает экипаж среди служб-партнёров, который в последствии его вывозит. Служба не теряет клиентов, пассажир остаётся доволен.

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

Особенности каждого способа кратко

Анализ работы диспетчерской

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

Мобильное приложение для заказа такси

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

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

Сэкономит затраты на содержание своего рабочего места в офисе службы.

Ещё один оператор в штате

Поможет, если все бизнес-процессы службы налажены и работают исправно.

Центр обмена заказами «TMMarket»

Подойдет, если у службы не хватает водителей, чтобы вывезти все заказы.

Источник