В день на Ozon поступают сотни тысяч заказов — при таких масштабах у пользователей неизбежно возникает множество разнообразных вопросов, которые они пишут в чат поддержки: как оплатить баллами «Спасибо», как вернуть ненужную куртку.
Нравится или есть доставка в Норильск.
При этом большинство вопросов поддержки однотипны, и пользователи ожидают ответа мгновенно и в любое время суток.
Чтобы ответить на все эти вопросы, у Ozon есть несколько тысяч сотрудников КС в Твери и Тамбове, но даже при таком количестве специалистов им нужна помощь, прежде всего, в ответах на часто повторяющиеся вопросы.
И самое очевидное решение — автоматизация с помощью чат-бота.
Меня зовут Михаил Волков, я руковожу разработкой платформы чат-ботов и сегодня расскажу вам, как мы измеряем качество их работы и улучшаем взаимодействие наших чат-ботов с пользователями.
Давайте посмотрим на это с нескольких разных сторон и попытаемся понять, какой из существующих подходов более эффективен.
Автоматизация нам поможет
Чат-бот на службе коммерции — это не простой веб-чат, это скорее коммуникационная платформа, автоматизирующая общение пользователя с УК.А любая автоматизация должна решать задачи пользователя быстрее, точнее и удобнее, чем оператор.
Правда, есть две задачи, которые чат-бот решить не может (и не должен), потому что это человеческие задачи:
- Когда люди пишут специально, чтобы поспорить.
С ботом спорить глупо, потому что с человеком-оператором гораздо интереснее.
Поэтому такие пользователи не общаются с чат-ботом.
- Позвоните курьеру.
Иногда пользователи хотят, чтобы оператор позвонил курьеру и спросил его или что-то уточнил.
Сам чат-бот, конечно, может позвонить курьеру, но объяснить, что от него нужно пользователю, он пока не может.
Но мы поставили перед собой сверхзадачу — решить проблему пользователя до того, как он ее сформулировал.
Допустим, уже 19:05, а курьер должен был приехать к получателю до 19:00. Становится понятно, о чем будет вопрос, а значит, чат-бот может быстро подтянуть информацию о курьере и рассказать пользователю, что с ним произошло (если это зафиксировано в системе).
Как мы можем определить, насколько хорошо чат-бот помогает нашим пользователям и насколько хорошо он на самом деле работает?
Хорошо ли работает наш робот?
Если спросить в среднестатистической ИТ-компании, кто отвечает за качество, самым популярным ответом будет тестировщики.В некоторых компаниях процент таких ответов будет достигать ста.
В соответствии с ИСО/МЭК ТР 19759:2005 тестирование программного обеспечения — — это процесс изучения и тестирования программного продукта с целью проверки соответствия между фактическим поведением программы и ее ожидаемым поведением в конечном наборе тестов.Ожидаемое поведение нашего бота: он должен быть живым, дружелюбным, но серьезным и ориентированным на решение бизнес-задач.
Надо отвечать быстро и по делу.
Совершенно непонятно, насколько это можно протестировать и можно ли вообще провести тестирование, чтобы определить, насколько хорошо работает наш бот. Ответ на этот вопрос спорен и не очевиден, хотя существует множество известных подходов.
Мы можем собирать обратную связь.
Например, отправьте сообщение: «Оцените, как вы общались, все ли в порядкеЭ» после завершения диалога.
Но есть нюанс.
По моему опыту, на это сообщение отвечают примерно 10% пользователей и, как правило, они не репрезентативны.
Обычно человек не будет писать отзывы или оценки после того, как уже решил свою проблему.
Люди, настроенные на ссору, продолжают общаться.
Если мы сосредоточимся только на таких пользователях, мы быстро зайдем в тупик.
При этом не следует забывать, что наши пользователи — это не только клиенты Ozon, которым мы помогаем решать проблемы, но и сама компания.
Например, у менеджеров свои требования к боту.
Кроме того, нашими пользователями являются операторы, которым мы также помогаем в работе:
- Сокращение рутины — Снимаем монотонные вопросы с операторов.
- Сокращение времени обработки билетов : бот задает вопросы клиенту и оператору, посмотрев переписку, сразу понимает в чем проблема и дает однозначный ответ.
- Улучшение показателей оператора благодаря классификации и предварительной классификации.
Благодаря тому, что мы ставим теги во время диалога, если чат передается оператору, мы можем отправить его напрямую нужному специалисту, который «исследует определенную тему».
Для бота это создает возможность дать пользователю релевантный ответ, если классификация была верной.
Например, операторы могут жаловаться на то, что «бот ворует рейтинги 24/7» (и операторы, и бот получают оценки от пользователей по результатам диалога, и иногда их сложно разделить) или что «ПВЗ — мы делаем Не пиши так!» (действительно, «пункт выдачи заказов» следует писать без сокращений).
Гарантия качества
Обеспечение качества в чат-боте похоже на слоеный пирог.Он имеет несколько уровней.
Уровень 0: Девопс
Как только наш разработчик разворачивает заглушку абсолютно любого сервиса, он автоматически получает мониторинг, оповещения, трассировку, централизованное логирование и непрерывную интеграцию:
Такие графики показывают, что наш сервис работает, реагирует на запросы пользователей и не сильно нагружает базу данных.
Здесь мы также увидим, что тесты упали.
Это действительно важная задача — понять, что сервис в принципе работает и дает ответы на запросы, скажем, в 95% случаев.
Вернемся к тестированию: чтобы посмотреть на него изнутри, обратимся к самим тестировщикам.
В настоящее время мы проводим много интервью в этой области.
Помимо простых задач: «Давайте напишем что-нибудь на pytest и протестируем API», я пытаюсь понять, как тестировщики понимают цель своей работы, каковы их функции, где они начинаются и заканчиваются.
Пример: Вопрос: В чем вы видите смысл работы тестировщика? Ответ кандидата : Тестировщик должен сообщить разработчикам, хорошо ли работает их код.Я представил себе тестировщика, который приходит и говорит мне, что здесь плохо, что здесь плохо, а что здесь хорошо.
В принципе, где-то это действительно так.
Но мне интересно, можно ли сделать тестирование более эффективным?
Ответ кандидата: Тестировщик должен помогать разработчикам улучшать рабочий процесс и подсказывать пути оптимизации.Так мы переходим на новый уровень обеспечения качества.Последующий вопрос: Расскажите о самом интересном случае, когда вы улучшили процесс разработки в своей команде? Кандидат:
Уровень 1: программисты
Программисты должны писать высококачественный код. Ведь для этого их и нанимают. Но что такое качественный код? Как понять, что Вася плохой программист, а Петя хороший? Для этого нам понадобится качественные методы программирования.
У наших программистов задача минимум — обеспечить качество чат-бота, чтобы код делал то, что написано в задании в Jira. Но это не всегда легко, поэтому велик соблазн доверить управление программистами роботам: цифры и метрики.
Например, введите показатели качества кода:
- тестовое покрытие;
- цикломатическая сложность;
- количественные метрики разного рода, позволяющие оцифровать впечатление, что код легко читается и модифицируется.
В Ozon мы много разрабатываем на Go — это язык, ориентированный на простоту: открываем код, читаем, все понятно, добавляем классную фичу.
Для этого мы пишем модульные тесты, следя за тем, чтобы тестовое покрытие кода не опускалось ниже какого-то разумного уровня, а остальным не заморачиваемся.
Но есть команды, которые все измеряют, и у них тоже отлично получается.
Еще мы тратим много времени на линтеры, поэтому написать неправильно сложнее, чем написать правильно.
Должен быть единый путь с хорошей производительностью и читабельностью.
А линтер подсветит плохие пути красным цветом.
Это конечная цель, к которой мы стремимся.
Еще одна история интервью подводит нас к следующей части.
Ответ кандидата: Если я отправлю тот же запрос, то я должен получить тот же ответ, верно?В случае с ML это не так.
Уровень 2: Инженеры машинного обучения
Одним из важнейших столпов вычислений является повторяемость.По идее, если мы сложим 2 и 2 и получим 4, то завтра мы также должны получить 4. Понятно, что если мы оперируем числами с плавающей запятой, то это не всегда так, однако люди ждут от компьютерных систем повторяемости.
Но для систем, в которых присутствует большая часть машинного обучения, это может быть не так.
У чат-бота есть часть машинного обучения — это может быть, например, нейронная сеть, которой мы предоставляем некоторые входные данные в качестве входных данных и получаем некоторые выходные данные в качестве выходных данных.
Отдельный вопрос, как проверить, что вход и выход исправны? Если мы просто перемешиваем параметры нейронной сети и входные данные до тех пор, пока нам не начнет нравиться результат, это вообще нормальный подход к тестированию обеспечения качества? Или мы все еще можем добиться большего? Кроме того, у чат-бота есть более предсказуемая часть кода, где API на вопрос «Когда мне вернут деньгиЭ» берет из огромной контентной части подходящий ответ: «В зависимости от того, как вы заплатили».
Машинное обучение по-прежнему является частью прикладной математики.
Мы можем взять формулу, которая покажет, что все хорошо или не очень.
Бот в своей ML-части представляет собой классификатор текстовых запросов.
У нас есть неограниченное поле запросов от пользователей и ограниченное поле классов, на которые мы хотим классифицировать вопросы от пользователей, например: 
В зависимости от присвоенного класса мы предоставляем заранее письменный ответ из системы контента.
А на запрос «Хочу изменить заказ» отвечаем: «Вам нужно зайти туда и нажать такую-то кнопку.
Или вы хотите, чтобы вам помоглиЭ», предлагая провести пользователя через сценарий диалога бота.
Теоретически это делается так: берём вопрос пользователя, помещаем его в самую модную сегодня нейросеть и получаем классификацию.
По опыту, лучшие системы классификации в ботах примечательны не своими крутыми нейросетями, а количеством костылей из предметной области, которые подкладываются под эту нейросеть.
Потому что в распознавании классификации есть много проблем, которые не очевидны для нейронной сети, обученной, скажем, на Википедии.
Например, «Большое спасибо» — хороший ответ, и мы можем ответить на него словами «Пожалуйста».
Но если человек перефразирует вопрос или начнет иронизировать: «Они отменили мой заказ — ну, спасибо!», то странно будет ответить: «Спасибо, мы тоже очень довольны».
Может, лучше посочувствовать? Или пользователя следует направить к оператору? Другой пример: баллы «Спасибо от Сбербанка», ставшие кошмаром для всех классификаторов и чат-ботов.
Люди могут легко написать: «Спасибо, я хочу расплатиться баллами.
Спасибо».
Но поскольку МО по-прежнему остается прикладной математикой, оно сможет определить, насколько хорошо мы обучили классифицирующую модель.
Метрик очень большое количество, я приведу самые простые.
Точность — самая интуитивно понятная метрика.
Берем общее количество предсказаний (угаданий), которые делает бот, и считаем долю угаданных правильно.
Это отличный показатель системных ошибок: 
Точность — метрика случайной ошибки (вариативности) .
Это не системная ошибка, а ошибка, отвечающая за случайные процессы, например, в нейросети: 
Отзывать — метрика полноты, то есть насколько мы правильно исчерпали все случаи классификации: 
Оценка F1 это среднее гармоническое : 
ЛогарифмическаяПотеря - указать, что не все классы классификации одинаково важны, и вознаградить нашего классификатора за то, что он угадал более важные классы, чем неважные.
Понятно, что раз появляются логарифмы, значит, что-то усредняется и сглаживается: 
Матрица путаницы для классификатора — это наглядная возможность проверить наш классификатор, доступный даже менеджеру: 
По вертикали мы видим предсказанные ботом классы.
По горизонтали — реальные классы.
Чем больше мы получим, тем синее будет квадрат. В идеале должна быть окрашена только главная диагональ.
Если иначе, то что-то пошло не так.
На изображении показан именно такой пример.
Мы можем посмотреть, какие классы сбивает с толку наш чат-бот, и прийти к двум разным выводам: чат-бот может работать плохо или это может быть один и тот же класс.
На самом деле это человек разбивает на классы, может быть он сделал это неправильно и нам нужны совсем другие классы, а от этих стоит отказаться? Важный вопрос о показателях качества: когда их измерять? При обучении модели мы измеряем их на заранее помеченной тестовой выборке.
Как правило, нашу тестовую выборку маркируют люди с Толоки — человек пробегается по различным вопросам и классифицирует их.
Например, вопрос: «Я хочу отменить заказ» — это аннулирующий класс, а «Я хочу изменить размер своего свитера» — это класс изменения размера.
После этого мы выбираем обучающую, проверочную и тестовую части в заранее размеченной выборке.
Соответственно, мы учимся в обучающей части, валидируем в валидационной части и так несколько раз.
В результате мы получаем число для нашей обученной модели и интерпретируем его.
Кроме того, мы можем измерить производительность модели постфактум, по результатам работы.
В конце концов, даже оператор, когда к нему приходит тикет, проставляет категорию запроса.
Мы можем взять запросы пользователей, категории запросов от операторов, предположения бота (которые, очевидно, были ошибочными, так как тикет был передан оператору), измерить и получить какую-то цифру.
Это тоже показатель качества.
Но есть проблема с показателями качества ML. Например, если мы увеличим Precision на несколько пунктов, это будет огромным достижением, но как это улучшит качество работы бота и сколько это будет стоить в деньгах – непонятно.
К сожалению, показатели машинного обучения хуже всего интерпретируются.
Часто это просто вещь сама по себе.
Но это не значит, что их не нужно измерять.
Вот что еще говорят тестировщики на собеседованиях:
Вопрос: Как мы узнаем, что пора заканчивать тестирование? Сколько ошибок можно оставить? Ответ кандидата: Когда в проекте не осталось ошибок.Некоторые говорят, что тестировать надо до конца, до 0 критического, некоторые упоминают известные крупные компании, у которых огромное количество багов, но они не волнуются.Вопрос: Совсем? Отвечать: Нет, ну немного можно.
К тестировщикам мы вернемся позже, а пока перейдем к следующему уровню качества — нашим аналитикам.
Уровень 3: Аналитики
У нас есть аналитическая система Power BI: она анализирует все числа, которые можно извлечь из всех наших сообщений чата.Понятно, что теоретически в нем можно найти ответы на все вопросы, но невозможно понять, какое число за что отвечает. Поэтому наши аналитики несут ответственность за преобразование цифр в знания и идеи.
Самыми популярными и визуальными метриками аналитики являются воронка и дерево декомпозиции.
Они отвечают на вопрос, на каком конкретно этапе какого сценария произошел сбой бота: 
Допустим, к нам в чат пришло 100 человек, из них мы решили проблемы 30. Остальные 70 отвалились на каком-то этапе.
Мы задали всем несколько вопросов, и кто-то не справился с первым, кто-то с третьим, кто-то с пятым.
Соответственно, мы можем видеть, на каком этапе кто отваливается — эти этапы представляют собой дерево разложения.
Благодаря этому дереву мы можем увидеть, что задаем неправильный вопрос или не можем понять ответ. Допустим, мы спрашиваем, какой порядок вы имеете в виду, и люди отвечают: «Вот этот».
Понятно, что для человека это имеет смысл, но для бота невозможно понять, какой «этот».
Обнаружение «плохого» вопроса позволяет напортачить серьезную логику, чтобы бот пытался выяснить, какой «этот» последний, первый или второй.
Проанализировав метрики, аналитики получили важный вывод: бот — такой же оператор, как и человек, а значит, к нему можно применить все метрики из теории массового обслуживания.
Теория очередей — это математика, раздел теории вероятностей, который говорит нам, что произойдет, если 100 человек встанут в 10 очередей, или если какой-то человек на почте будет медленно доставлять посылки, или если люди перейдут из одной очереди в другую.
Благодаря этой теории у нас есть доступ к огромной библиотеке метрик, которые мы можем использовать: например, время ожидания, время обслуживания и другие.
Эта же теория отвечает на вопрос, как мы поймем, что решили проблему пользователя.
Как правило, в службе поддержки бытует мнение, что если клиент несколько минут не отвечает в чате, значит, он доволен.
Многие операторы таким образом получают плюсик в системе аналитики (вопрос считается решенным).
Вот мы и приближаемся к последнему уровню нашего «пирога» — менеджерам.
Уровень 4: Менеджеры
В конце концов, менеджеры отвечают за то, чтобы мы не забывали, что проект — это деньги и ему нужно двигаться вперед и приносить прибыль.Если не забывать, что все это можно исчислить деньгами, то возникают неожиданные озарения.
Например, мы попытались посчитать эффективность простого бота, который ищет в запросе пользователя слово «Спасибо» и отвечает на него: «Пожалуйста! Мы работаем для вас.
» Бот максимально простой, но оказалось, что в масштабах Ozon он сэкономил достаточно денег, чтобы поддержать небольшую команду разработчиков.
Наши менеджеры также полагаются в основном на метрики.
Например, есть метрика закрытия тикетов — это, проще говоря, один диалог с пользователем и в идеале одна решенная проблема.
Или показатель удовлетворенности пользователя, который показывает, насколько пользователь доволен ботом.
Эти метрики противоположны и уравновешивают друг друга, но можно ужесточить одну из них.
Например, мы хотели бы максимизировать показатель закрытия заявок, поскольку нам необходимо достичь ключевого показателя эффективности закрытия 80%.
Все понимают, как это сделать (и многие компании так делают) — только не отпускайте пользователя.
Мы просим его переформулировать вопрос, сказать его по-другому.
Так продолжается до тех пор, пока ему не надоест, или он так и не вникнет в фразу, которую распознает бот. Это позволяет добиться фантастических показателей закрытия заявок – 80, 90, 95%! С другой стороны, предположим, что мы хотели бы улучшить показатель удовлетворенности пользователей — в том смысле, в каком мы его понимаем.
Это также очень легко сделать.
Когда пользователь заходит в чат, ему говорят: «У вас проблемы? Отлично, вот 400 бонусных баллов!» Довольный пользователь их берет, ставит пятерку или пишет хороший отзыв.
Но раздувание метрик не обеспечит нам качество и не увеличит скорость обслуживания, а может лишь дать нам обманчивое ощущение отсутствия проблем.
Мы вроде бы прошли все уровни контроля качества, но тестировщиков среди них не было.
Они упоминались кое-где, но не заняли своего места.
Почему? Потому что, используя ту же кулинарную метафору, наши тестировщики, как сироп в слоеном торте, задействованы на каждом этапе.
И конечно, они сами измеряют и влияют на качество.
Как еще можно это проверить?
У нас есть бот, который принимает ввод, обрабатывает его и что-то отвечает. Это реальный скриншот редактора бота, его дерево скриптов:
Вот тут и возникает идея — давайте сделаем еще одного бота, который принимает входные данные от первого бота и выдает ответ в духе: «Брат, ты все сказал правильно» или «Брат, ты все сказал неправильно».
Позвольте боту протестировать бота.
Таким образом, мы сможем протестировать большое количество сценариев на той технологической базе, которая у нас уже есть.
Собрать еще одного бота-контроллера несложно, когда их уже 5. Такой бот должен сидеть в очереди сообщений, читать их и при необходимости сопоставлять с шаблонами, описанными в yaml. Например, если от бота было два сообщения подряд, скорее всего это неверно? Или если пользователь начинает ругаться, а чат-бот его не успокаивает. Мы можем взять более или менее формальные характеристики.
А поскольку на дворе уже 2022 год и все боты должны писать в Slack, то и ChatOps не за горами!
Заключение
Ответ чат-бота представляет собой комбинацию большого количества параметров.Мы можем вернуть практически любой товар, но если это электроника или медицина, то тут будут свои тонкости.
А запросы от премиум-пользователей получают приоритетную обработку.
То есть существует огромное количество сценариев взаимодействия, тестирование которых — отдельная большая задача.
Конечно, есть определенные сложности (они тоже интересны) в обеспечении качества чат-бота:
- Недетерминированный результат. Сегодня мы получили один вывод от чат-бота, но не можем его записать, поместить в JSON и сравнить с завтрашним и послезавтрашним, посчитав эталонным.
Потому что завтра мы переобучим модель, немного подкорректируем в ней какой-нибудь параметр, и чат-бот будет реагировать по-другому.
- Неопределенные требования.
Требования, конечно, простые — чат-бот должен помочь решить проблему.Что значит «решить проблему» — это вопрос, который мы обсуждаем целый день.
- Множество сценариев взаимодействия.
Чат-бот должен помочь пользователю в любом вопросе – от доставки в Норильск до получения сертификатов на товар.
Конференция по автоматизации тестирования Конференция TestDriven 2022 пройдет в Москве 28-29 апреля 2022. Помимо хардкора про автоматизацию и разработку в тестировании, будут и вещи полезные в обычной работе.Теги: #Машинное обучение #искусственный интеллект #нейронные сети #тестирование #тестирование веб-сервисов #ml #боты для мессенджеров #боты #тестирование веб-приложений #тестирование качества #боты качества #контроль качестваРасписание Он уже готов, но вы можете купить билет Здесь .
-
Новостной Портал Risingbd Online Bangla
19 Oct, 24 -
Интеграция Opencart С 1С Предприятие
19 Oct, 24 -
Typescript: Общие Впечатления
19 Oct, 24 -
О Высшем Образовании
19 Oct, 24
