DSE Fest — технично и понятно про data science для разработчиков. Первые доклады уже на сайте >>
×Закрыть

DOU Labs: як у EPAM розробили Facebook Messenger бота, що замовляє квитки на події

У рубриці DOU Labs ми запрошуємо IT-компанії ділитись досвідом власних цікавих розробок та внутрішніх технологічних ініціатив. Питання і заявки на участь надсилайте на editors@dou.ua.

Ця стаття — про досвід EPAM у розробці комерційного чат-боту для однієї з найбільших компаній у сфері продажу квитків на події. Зараз такими штуками важко здивувати. А на той час — кінець 2016 року — проект був для львівської команди шансом проявити себе у сфері, що набирає обертів.

Передісторія

Ще у 2011 році аналітики Gartner прогнозували, що 85% випадків взаємодій із клієнтом буде відбуватися через розмовні інтерфейси. І вгадали. Чат-боти швидко увійшли в маси, особливо після того, як свої платформи запустили всі популярні месенджери. Свого часу через 2,5 місяці після запуску ботів на Facebook Messenger Platform їх було вже більше 11 000. Станом на 1 травня цього року їх було вже 300 000.

Звичайно, в тих сферах бізнесу, де розмовна мова є складною і критичною для реагування, поки що рОбота не поставиш. Але у вирішенні простих разових завдань ситуація інша. Люди неохоче встановлюють додатки, наприклад, для замовлення піци, квитків на транспорт або отримання довідок. З ботом зручніше: працює всередині звичних месенджерів, не займає зайве місце, потребує менше трафіку — а це може стати в нагоді в роумінгу або місцевості із слабким покриттям.

На щастя, небажання людей розводити «application zoo» розуміє і бізнес. Тому починає розробляти чат-ботів, щоб спростити користувацький досвід, бути ближчим до користувача та цілодобово тримати з ним контакт.

Бізнес використовує чат-ботів переважно з двома цілями: зекономити компанії гроші або допомогти їх заробити.

Перші — це, наприклад, боти, що замінюють перший рівень служби підтримки і розвантажують операторів. На ринку є продукти, які фокусуються на заміні IVR-систем (Interactive Voice Response) через технологію розпізнання голосу у поєднанні із NLP (Natural Language Processing). Коли відсоток розпізнання малий, людину автоматично перемикають на оператора. Ініціювати перехід може і сам клієнт.

Другі призначені для того, щоб збільшити прибуток через взаємодію в нових комунікаційних каналах (месенджерах) та через збільшення частоти продаж. Саме таким був наш кейс.

Замовлення

Вже протягом двох років наша команда займається R&D у сфері conversational user interface. За цей час ми розробили більше 10 proof of concept для замовників із різних сфер на основі власного акселератора і доступних на ринку бот-фреймворків.

Така експертиза стала в нагоді майже одразу. У жовтні 2016 року EPAM сконтактувала із потенційним клієнтом — однією зі світових компаній з продажу квитків на публічні події. Компанія вирішила зробити комерційного чат-бота, який допомагав би користувачам знаходити та замовляти квитки прямо у Facebook Messenger.

Спочатку мова йшла про те, що EPAM розробить тільки back-end бота на Java. Частину роботи, пов’язану з NLP, замовник планував делегувати каліфорнійському стартапу, який фокусується саме на NLP та чат-ботах. Проте наша команда, використовуючи акселератор та R&D-напрацювання, буквально за тиждень створила повноцінного чат-бота, і таким чином ми виграли bidding у каліфорнійців і стали відповідальними за весь проект.

Що зовні

Перше delivery ми зробили вже за 9 днів. На той момент це був чат-бот, який був сфокусований на пошуку музичних подій в США. Після кожного релізу відбувалося user acceptance testing для покращення користувацького досвіду.

За вісім місяців провели публічний реліз чат-боту. За його допомогою користувач може швидко знайти подію за такими фільтрами:

  • виконавець;
  • час і дата проведення;
  • тип події (спортивна чи музична);
  • жанр (рок, джаз або баскетбол, гольф);
  • місцезнаходження (заклад, місто, країна, штат, координати на мапі та геолокація).

Коли людині немає чим зайнятися, вона може спитати, що відбувається сьогодні поруч, — і чат-бот запропонує варіанти подій. Крім того, він має базовий рекомендаційний алгоритм і здатний пропонувати події у схожих жанрах, якщо нічого не було знайдено за його запитом. Розмовний інтерфейс розпізнає синоніми, омоніми та розуміє контекст на основі структури речення. У випадку двозначності чат-бот перепитує користувача та запам’ятовує його вибір.

Для користувачів замовника бот закриває функцію discovery — пошуку подій. А самому замовнику дає ще один автоматизований канал лідогенерації.

Що під капотом

На ринку вже є достатня кількість рішень NLP. Є багато SaaS-рішень, які є частиною чат-бот фреймворків. Є SaaS-рішення конкретно по NLP — Microsoft LUIS, IBM Watson, Amazon Lex, Google Dialogflow. Є низькорівневі фреймворки, які працюють як сервіс чи бібліотека: Google SyntaxNet або Google Cloud Natural Language API, spaСy, Stanford CoreNLP.

Проте для чат-бота ми вирішили розробити кастомний бекенд та кастомний NLP Pipeline. Основною складовою була бібліотека NLP4J від Emory University. Інші складові — це онтологія knowledge graph, за допомогою якої знаходили і зберігали всі entity і зв’язки між ними. Наприклад, виконавець, який відноситься до жанру музики, її піджанру, сегменту і так далі. Так само зберігали деяку інформацію про користувача, яку він надавав, щоб бот не задавав однакові питання кілька разів.

Ще один компонент — Rule Engine. У деяких випадках команда писала невелику кількість дедуктивних правил, бо на початку дуже важко назбирати тренувальний набір даних. Це основна проблема багатьох проектів із машинним навчанням: без training set дуже важко побудувати будь-яку модель. Тому для «холодного старту» використовували knowledge graph, dependency tree, part of speech tree, named entity recognition для того, щоб збирати необхідний набір даних.

У замовника для такого проекту була суттєва перевага — у компанії вже є інформація про основні entity в системі. Є визначена кількість виконавців, майданчиків, країн, міст, різних можливих варіацій часу (увечері, наступного дня, тижня, місяця, у четвер). Тому, якщо речення просте і не містить заперечень, логічно використовувати named entity recognition і більш низькорівневі інструменти без training set. Без великої кількості репортів для генерації такого сету та процесу навчання.

NLP4J, як і Microsoft LUIS, дає можливість на основі training set виокремлювати з речення різні entity, включаючи параметри часу. Але команда використала її лише для складних кейсів. Наприклад, Осло може бути і містом, і театральним гуртом. У такому випадку користувач може вибрати, що він має на увазі. Проте якщо користувач, наприклад, пише «What’s up in Oslo?» одразу буде зрозуміло, що мова йде про географію.

Тести, тести, тести

Функціональність продукту ми планували у тісній взаємодії із замовником. На його стороні був один стейкхолдер з топ-менеджменту, UX-дизайнер і технічний стейкхолдер. Наш Product Owner постійно спілкувався із топ-менеджером клієнта — з ним формували візію та беклог. Львівська команда EPAM складалася з 9 людей: Delivery Manager, Product Owner, Solution Architect, NLP-інженер, два розробники, QA і два DevOps.

Основний ризик розмовних — та і загалом нових — інтерфейсів у тому, що такі технології зазвичай ще не повністю опробувані користувачами. Тому невідомо, наскільки чат-бот може бути популярним на ринку і чи взагалі користувачі, які, наприклад, купують квитки у додатку, будуть користуватися чат-ботом. Щоб підтвердити чи спростувати ці припущення, команда після кожного релізу проводила user acceptance testing.

Фактично близько 50% scope було визначено, а решта 50% формувалася на основі user acceptance testing. Він проходив через Slack-канали, де була внутрішня фокус-група із працівників клієнта — до сотні людей в різний час. Кожні два тижні після кожного релізу їм анонсували нову функціональність, збирали конкретний фідбек і всі результати зберігали в одному проекті в Trello. В Jira вже працювали з конкретним фронтом робіт, який вирішили передавати в розробку. Через те, що половина scope формувалася на основі відгуків користувачів, робота була побудована по Kanban.

Процес роботи над ботом

Досить багато часу у команди пішло на дизайн продукту. Ми розробили десятки різних прототипів із використанням Botsociety — цей інструмент дозволяє прототипувати чат-ботів і продукувати user experience. Необхідно було вирішити, яким чином чат-бот має виглядати: він має бути клікабельним чи розуміти мову?

Для аналізу спілкування тестових користувачів із ботом команда інтегрувала аналітичні інструменти Dashbot.io та Google Analytics, для яких розробила кастомну метрику вимірювання конверсії.

Загалом проект мав декілька дедлайнів. Спочатку ми орієнтувалися лише на музичні події в США і реліз був запланований на грудень 2016 року. Але замовник захотів, щоб бот підтримував усі типи подій по всьому світу. Тобто до NLP-пошуку треба було додати місця проведення подій. Далі необхідно було додати всі їх типи: крім музичних — спортивні, театральні, мистецькі та інші.

Паралельно йшла робота над базовими рекомендаціями. Наприклад, якщо користувач шукає концерт «Океану Ельзи» у Львові, а такого не буде, бот порекомендує концерти гурту в інших містах. Якщо шукають doom metal концерти у Львові, то бот не буде рекомендувати аналогічні події по всій країні, бо людина через жанр не поїде в інше місто.

Також деякий час ми вирішували кейс динамічної генерації діалогу — якщо подій більше, ніж 10, бот задає питання, щоб звузити вибір користувача. Потрібно було реалізувати перепитування, якщо виникають двозначні кейси.

Врешті-решт, було необхідно оптимізувати performance, щоб система витримувала сотні тисяч одночасних запитів користувачів. Стабільний build був готовий на кінець квітня. А публічний реліз відбувся 21 травня. Тоді про бота написали кілька впливових міжнародних технологічних медіа. І написали схвально.

Зараз проект на стадії підтримки. Напрямок розвитку визначає живий досвід користувачів. У conversational solutions це дуже просто, бо є доступ до логів діалогів з користувачем.

LinkedIn

14 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Дякую, що поділилися досвідом. Цікавить декілька питань. 1. Чому на етапі планування було прийнято рішення розробляти власне NLP, а не користуватися готовими платфорами, і як на це погоджувався клієнт. 2. Скажіть, будь ласка, чи використовували ви аналітику (зокрема funnels, behaivor flows etc.) для покращення/зміни флоу. 3. Чи було реалізовано можливість підключення оператора клієнта до чату (handover protocol). 4. Поділіться лінкою на бота. Дякую

Привіт! 1. В клієнта є були структуровані дані по всіх entities. (жанри, виконавці, місця проведення і т.д.). Це хороший фундамент для шкидкого «холодного старту», коли тренінг сету нема. Є можливість розробити онтологію та додати синоніми. 2. Так! Ми користувалися dashbot.io, google analytics, facebook anaytics. Також ми групували нерозпізнанні повідомлення для подальшого аналізу. Для візуалізації та аналізу флову, інструментів подібних до Chatbase в цьому проекті ми не використовували. 3. Клієнт не має департаменту який займається продажем квитків. Все відбувається виключно онлайн без залучення людей. Не було змісту «здорожчувати» вартість продажі квитків. 4. Не можу, NDA

Дякую за розгорнуту відповідь. Чудово, що у вас вийшло домовитись з клієнтом на кастом NLP рішення і зробити його. Щодо аналізу флоу, то в вашому випадку воно впливає на конверсію. В деяких проектах, де я приймав участь, аналіз флоу був важливий через присутність людини на саппорті. І тоді кожен handover чатботу мав конкретну ціну за час, що тратив оператор на консультацію. Доводилося аналізувати флоу в Chatbase і оптимізувати шлях вирішення проблеми в чатботі.

І ще інформація по даній темі всюди в основному рекламного характеру. Тому дякую, що ділетесь деякими технічними деталями реалізації

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

як у EPAM розробили Facebook Messenger бота

Проект під NDA. На жаль, не можу дати більше інформації.

а нащо там nlp, можна ж команди зробити як в телеграмі «/tickets» «/buy» «/more_info» і тд

Це стиль телеграму. Як на мене він занадто механізований і складається враження, що використовєш якийсь інтерпритатор :) Краще якісне NLP, ніж система команд

Це альтернативний підхід. Є два види взаємодії із користувачем «Guided discovery» з використанням клавіш. Цей підхід корисний, коли користувач не визначився чого хоче. Альтернативний підхід «Direct discovery» — користувач знає продукт який хоче купити. Тут краще застосовувати NLP, оскільки можна зразу найти що цікавить,

Ми використали гібридний підхід. Наприклад: користувач цікавиться, які фільми він зможе подивитися на вихідних. Фільмів більше 40. Чат бот запитує в користувача жанр, який йому більше цікавий (комедія, драма).

Кожне рішення має свої переваги. Наприклад, чат-бот woebot — бот-психотерапевт. Дуже успішний в світі. Використовує лише кнопки та в деяких випадках keyword matching.

Guided discovery краще ще й тим, що користувач йде по запланованому сценарію і в кінці флоу зачасту знайде те що шукав. В той час коли з використанням NLP є велика йомвірність не розпізнати запит. Guided flow дає більший контроль над спілкуванням з ботом

На самом деле работа чисто механическая. NLP движки есть, апишки есть. Бери и делай, все остальное в рамках вашего стека :)

Дякую, цікава стаття. Результати виглядають дуже позитивними! Цікаво, якщо не таємниця, як формувався бюджет. Чи вдалося другі 50% скоупу, яка була додана на основі user acceptance testing, включити в основний скоуп в процесі? Або, можливо, була попередня домовленість, що лише 50% бюджету буде витрачено на такі покращення?

Чат-боти та віртуальні асистенти достатньо нова технологія для користувачів. Ще нема чітко сформованих «best practices». Тому є високий ризик, що користувачі не будуть взаємодіяти і спілкуватися із чат-ботом як було це спроектовано під час розробки. Через велику к-сть зворотнього звязку під час UAT було прийнято рішення з замовником виділити до 50% об’єму спрінтів на вирішення найважливіших користувацьких проблем.

Подписаться на комментарии