Это история о том, как команда данных Kickstarter сотрудничала с командой поддержки сообщества и командой инженеров, чтобы создать инструмент автоматизации поддержки под названием Sassy, и как в ходе этого процесса наша совместная работа на рабочем месте обогатилась.
Истоки сочувствия
Успешные компании склонны глубоко сочувствовать своим пользователям. В Kickstarter мы стараемся привнести сочувствие в каждую часть организации, от разработки ориентированных на человека продуктов до заботы и тона наших электронных писем в службу поддержки сообщества.
В группе данных мы стремимся понять наших пользователей через данные, которые они генерируют. Иногда это оказывается проблемой, поскольку точки данных являются лишь тенями людей, которые их создают.
Мы также стараемся сопереживать нашим коллегам из других отделов Kickstarter. Наша команда поддержки сообщества, например, продвигает это, проводя так называемую ротацию CS, при которой каждый в компании получает смену обучения CS и временно действует как агент CS, отвечая на несколько заявок в службу поддержки в течение одной недели.
Я сделал ротацию CS осенью 2015 года, в первую неделю, когда это было предложено. Отвечать на вопросы оказалось намного сложнее, чем я мог себе представить, но я обнаружил, что мне нравится иметь возможность общаться и помогать людям, которые на самом деле используют продукты, которые я помогаю создавать и поддерживать. Я испытывал острые ощущения, которых я обычно не испытываю, анализируя результаты A / B-теста.
Эта ротация не только помогла мне лучше понять шаблоны и болевые точки наших пользователей, но и стала отличным упражнением в ознакомлении с рабочими процессами, используемыми нашей командой CS.
Хотя написание ответов на электронные письма пользователей было медленным и кропотливым процессом, опытные агенты CS работают с молниеносной скоростью. И они должны - количество обращений в службу поддержки велико, и требуется много человеческих сил, чтобы обработать их своевременно и точно.
Когда я узнал о рабочем процессе CS, я также узнал, что команда CS была заинтересована в изучении расширенной поддержки, то есть в найме внешних подрядчиков для управления определенными типами заявок или, возможно, даже в введении некоторой автоматизации в свои рабочие процессы. Появилась возможность для межкомандного сотрудничества.
Автоматизация человека
Быстрая работа является обязательным условием для нашей команды CS, но не менее важно следить за тем, чтобы с нашими пользователями обращались как с людьми. Когда пользователи пишут с помощью сложных тикетов, важно иметь возможность копать глубже, но часто эти глубокие погружения могут начаться только после обмена несколькими диагностическими сообщениями об устранении неполадок. Эти первые электронные письма часто решают проблемы пользователей сразу.
Я быстро понял, что большая часть поддержки сообщества включает в себя ответы на множество простых, почти идентичных обращений: сброс пароля, устранение неполадок при оплате и пользователи, просящие изменить свое обещание, являются обычным делом. Как и многие группы поддержки в отрасли, команда CS на Kickstarter создала набор «макросов» - заранее написанных ответов на простые вопросы, которые можно вызвать несколькими нажатиями клавиш - для ответа на многие из этих запросов. Опытные агенты CS запомнили множество этих макросов и могут создать правильный, персонализировать его и запустить всего за несколько секунд.
Все это делается в программном обеспечении обслуживания клиентов под названием Zendesk, которое, помимо поддержки макросов, позволяет помечать пользовательские электронные письма, определять их приоритеты и перенаправлять различным агентам службы поддержки. Многим из этого тоже можно управлять автоматически, используя Zendesk API.
Хотя использование макросов уже экономит нам много времени, мы хотели посмотреть, можем ли мы пойти дальше. Команда CS здесь небольшая и разрозненная, и время, которое они тратят даже на самые быстрые электронные письма на основе макросов, отнимает время, которое можно было бы потратить на решение более сложных проблем, требующих помощи экспертов и людей.
Вместе команды CS и Data определили несколько вариантов использования, в которых можно автоматизировать высокоавтоматические и в конечном итоге трудоемкие человеческие действия с помощью машинного обучения.
- Автоматическая расстановка приоритетов. Команда CS недавно организовала поддержку на несколько разных уровней в зависимости от сложности проблем / заявок. Задачу определения приоритета и направления билетов соответствующему агенту или группе можно автоматизировать.
- Автоматический ответ. На некоторые распространенные запросы часто отвечают с помощью простых неизмененных макросов. Если бы алгоритм машинного обучения мог надежно идентифицировать эти тикеты, мы могли бы автоматически отвечать на определенные тикеты первого касания, вводя человека в цикл для любых последующих ответов.
Помня об этих целях, мы решили создать службу классификации билетов, которая будет известна как Sassy - пакет поддержки + классификатор.
Поле и сервис
До сих пор идея автоматизированной поддержки сообщества была изобретением только команды Data и группы поддержки сообщества. Чтобы продать идею команде продукта, я работал в R над разработкой блестящего прототипа приложения для службы классификации билетов. С одной стороны у него было текстовое поле, а с другой - список макросов ответов и оценок релевантности. По мере того, как вы набираете свой вопрос, оценки макросов будут обновляться, и наиболее релевантные макросы поднимутся в верхнюю часть списка.
За кадром находился мультиклассовый классификатор логистической регрессии, обученный в Глмнет. Я работал с командой CS, чтобы сгруппировать макросы в дюжину или около того тематических сегментов, и я использовал эти сегменты в качестве меток в моем наборе для обучения. Людям понравился прототип, и мы решили создать сервис по-настоящему.
Возвращаясь к инженерной стороне Kickstarter, мы только что начали инициативу по разделению нашего монолитного приложения Rails на более мелкие автономные микросервисы. После долгих размышлений и пилотных испытаний наша команда инженеров решила, что эти службы будут написаны на Java.
У меня был некоторый опыт написания кода на C ++, поэтому я был рад провести некоторое время вдали от R и Ruby и поработать в мире статически типизированной Java. Какие-то добрые инженеры из команды Platform (включая тех, кто несколько месяцев назад находился в ротации моего CS) помогли построить всю надежную сантехнику и инфраструктуру, чтобы сделать скелет Java-сервиса классификаций. Моя работа заключалась в том, чтобы вставить ИИ.
Преодоление разрыва
Здесь я начал сталкиваться с классической проблемой науки о данных: как преодолеть разрыв между прототипом и производством - как связать то, что обучает вашу модель, с тем, что ей служит.
Я знал, что R отлично подходит для построения моделей машинного обучения из необработанных данных, и мой прототип был построен на R, но мы не хотели использовать эти объекты R для обслуживания запросов в нашем сервисе производственного уровня; это была работа Java. С другой стороны, у меня не было опыта обучения моделям на Java, и я даже не был уверен, существуют ли надежные библиотеки для создания моделей машинного обучения строго в мире Java.
Именно тогда мы натолкнулись на платформу машинного обучения под названием H2O, которая в основном предназначена для решения этой проблемы. Я смог обучить свой многоклассовый классификатор в R, используя настраиваемые модели ML H2O (в итоге я использовал модель дерева с усилением градиента), а затем экспортировать свою обученную модель в виде файла Обычный старый объект Java (POJO). . Затем этот POJO может быть вставлен в службу Java без каких-либо зависимостей - вся логика самой модели закодирована в POJO с помощью простых классов и контейнеров Java.
Я написал обучающий сценарий для извлечения необработанных данных из нашей базы данных заявок в службу поддержки, очистки и токенизации текста в R, обучения модели в H2O, экспорта этой модели в файл POJO и копирования этого файла в исходный код Java. Есть серия тестов на точность, которые модель должна пройти, чтобы быть выпущенной. Логика, которую мне пришлось вставить в службу Java для обслуживания запросов, была довольно простой, и POJO, хотя и состоял из многих десятков тысяч строк сгенерированного кода, работал как шарм.
Этот набег на Java также послужил шаблоном для нашей новой парадигмы сервис-ориентированной архитектуры. Мы сохранили наши классы достаточно абстрактными, чтобы можно было легко расширить службу классификации для других задач классификации, которые могут нам понадобиться в будущем, таких как модели для прогнозирования успеха проекта или классификаторы спама.
Мы развернули этот сервис в начале 2017 года. Он обрабатывает тикеты Zendesk через POST-запрос, отправленный из нашего приложения, содержащий текст тикета и некоторые другие метаданные. Затем служба Java очищает и токенизирует текст, передает его через логику модели POJO и отвечает списком меток и соответствующих вероятностей. Затем вызывающий абонент может предпринять действие на основе ответа, например, направить заявку по приоритету или даже вызвать Zendesk для автоматического ответа на заявку. Эти действия запускаются тегами, которые вызывающий абонент применяет к заявкам через Zendesk API.
При поддержке Sassy
Частично радость от этого проекта заключалась в сотрудничестве с другими командами на протяжении всего процесса разработки Sassy. Это не закончилось, когда продукт был развернут. Процесс изменения меток обучения и периодического переобучения модели с течением времени принадлежит группе поддержки сообщества. Решения о том, какие макросы следует сгруппировать вместе, какие макросы следует использовать в качестве автоответчиков и какие макросы никогда не следует автоматизировать, - это вопросы, на которые может ответить только CS.
Я работал с членами команды CS, знакомя их с использованием Github, внесением и фиксацией изменений, а также открытием и объединением запросов на вытягивание. Все подробности о метках обучения модели содержатся в одном простом файле конфигурации, право собственности на который редактировать они, а сценарий переподготовки запускается с помощью простой консольной команды. Приложив немного усилий, чтобы дать возможность людям, не входящим в группу инженеров, использовать несколько инженерных инструментов, Sassy теперь может расти более автономно - и наши отдельные команды стали более сплоченными.
Вот пример фрагмента файла конфигурации, используемого для группировки макросов в метки Sassy:
config:
-
parent_macro:
parent_macro_passwords
macros:
- macro_pw_trouble
- macro_acct_profile_forgot_password
-
parent_macro:
parent_macro_media_video
macros:
- macro_creator_build_video_resolution
- macro_creator_build_embed_video_in_update
- macro_creator_build_insert_video_in_description
Агенты CS периодически контролируют точность Sassy вручную, и время от времени заинтересованные стороны CS и Data собираются вместе, чтобы обсудить результаты. Взяв на себя ответственность за большую часть этого процесса, мои коллеги по CS развивают сильную интуицию в отношении сильных и слабых сторон моделей машинного обучения, которые мы используем. Это помогает нам совместно вносить более информированные обновления в модель, и этот цикл продолжается.
Нахальный в будущем
Эта служба, получившая название Sassy, в настоящее время используется, сортируя билеты по приоритету и даже автоматически отвечая на определенные типы билетов. Sassy будет продолжать развиваться дальше, поскольку мы собираем более точные обучающие данные, повторяем различные модели и исследуем другие воплощения продуктов. Например, немного поработав, будущая итерация Sassy, возможно, сможет обеспечить автоматическую поддержку в реальном времени на сайте, пока вы печатаете. Мы надеемся на то, что нас ждет впереди.
То, что началось как неделя ответов на запросы по ротации CS, переросло в межгрупповое сотрудничество с Community Support, Data и Engineering, построив и развернув совершенно новую услугу. Мы учились друг у друга на протяжении всего процесса, и в результате наши команды и мы стали сильнее.
