DOU Labs: як у EPAM розробили Facebook Messenger бота, що замовляє квитки на події
У рубриці DOU Labs ми запрошуємо IT-компанії ділитись досвідом власних цікавих розробок та внутрішніх технологічних ініціатив. Питання і заявки на участь надсилайте на Данный адрес e-mail защищен от спам-ботов, Вам необходимо включить Javascript для его просмотра. .
Ця стаття — про досвід 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 це дуже просто, бо є доступ до логів діалогів з користувачем.
