B2B-навик Аліси: від прототипу до першого зекономленого рубля


Не так давно в Санкт-Петербурзі пройшла друга конференція Conversations, присвячена розмовній AI, на якій мені пощастило виступити в якості доповідача. Темою була розробка прототипу B2B-навички для великої компанії. У доповіді розповідалося про те, як вдалося «подружитися» навичка з відносно повільними веб-сервісами та закритою інфраструктурою компанії. Про це і піде мова під катом.

Якщо раптом ви не знаєте, що таке навички Аліси, загляньте під спойлер: там коротко описано, що до чого.

Для непосвяченихЩо таке Хто така Аліса, думаю, багато хто знає. Але на всяк випадок – це голосовий помічник від Яндекса. Крім того, що вона багато чого вміє робити «з коробки», у розпорядженні розробників є платформа для розширення її функціональних можливостей – Яндекс.Діалоги (вони ж навички Аліси).

З точки зору користувача, навичка — це спеціальний режим Аліси, який викликається певними активаційними фразами. У цьому режимі Аліса передає репліки користувача на сторонній веб-сервіс, і відповідає переданим у відповідь повідомленням.

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

Ідея

З чого ж все почалося? 13го березня 2018 року оголосили про бета-тестуванні платформи Яндекс.Діалоги (навички Аліси). В той час вже багато цікавилися віртуальним помічником, а значить це була відмінна можливість попрацювати з досить великою аудиторією. У мене в голові давно крутилася ідея одного чат-бота, тому я вирішив, що буде цікаво зробити за його мотивами який-небудь навик у вільний час. А якщо він зможе до того ж принести користь на роботі – взагалі відмінно.

Наша компанія надає повний спектр послуг в області ділового туризму, а значить можна зробити навик, який допоможе користувачеві поїхати у відрядження.
Тоді я був у команді по розробці мобільного додатку, за допомогою якого можна знайти варіанти рейсів та готелів для відрядження, та оформити відповідні з них. Одним з ключових показників, за збільшення якого ми боролися, було кількість скачувань. Виникла ідея того, що, якщо навик буде приводити користувачів у додаток, то він допоможе нам збільшити ці показники. Це і потрібно було перевірити за допомогою даного проекту.

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

Виходить, що навичка повинен працювати приблизно так: привітати користувача; знайти його по ПІБ; задати уточнюючі питання і, таким чином, отримати необхідні параметри поїздки міста (звідки і куди) і дати. Далі показати розпізнані параметри. Якщо все правильно, запустити пошук, і дати посилання на додаток.

Читайте також  Немає доступу до цільової папки у Windows 10, 8.1 і Windows 7

Ресурси та обмеження

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

Наприклад, тестовий сервер. У розробників вистачає прав, щоб розгорнути на ньому веб-додаток, але воно буде доступно лише під внутрішньої мережі компанії, тому що сервер не «стирчить» назовні. При цьому у нього є доступ в інтернет, а значить цим можна буде скористатися.

Веб-сервіс навички обов’язково повинен бути доступний ззовні (щоб Алісі було куди відправляти запити), тому його довелося розмістити на зовнішньому хостингу.

Щоб навик міг виконати свою задачу, потрібен такий веб-сервіс компанії, який умів би шукати профілі і міста, і був би доступний ззовні. Для цього підійде API мобільного додатку, хоча у нього є свої нюанси. Вони полягають у тому, що підключитися до API можна від імені лише одного певного користувача, а значить буде обмежено коло доступних для пошуку профілів. А найнеприємніше — результати пошуку, запущеного через API, будуть приходити тільки цьому користувачеві. Тим не менше, воно володіє необхідним функціоналом, а значить з ним можна працювати.

Отже, навик на зовнішньому хостингу буде взаємодіяти з API. Воно звичайно ж досить швидке, але іноді, за результатами тестів, відповідь не встигає прийти за потрібні 1500 мс (такою вимогою платформи Яндекс.Діалоги). А для того, щоб все-таки надіслати результати потрібного користувачеві, треба від його імені запустити службу пошуку, яка доступна тільки у внутрішній мережі. API, на жаль, у цьому не допоможе, а значить треба якимось чином передати запит від навички безпосередньо у внутрішню інфраструктуру.
Будемо вирішувати ці проблеми по мірі надходження.

Етапи. Проблеми і рішення

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

Вибір припав на Redis. Він добре показав себе в тестах на відгук, а також ми щільно використовуємо його на роботі, а значить, в разі успіху, цей проект можна буде легко перенести в компанію (і спойлер – ми його перенесли). В якості ключа можна використовувати ідентифікатор користувача в навичці (зазначається у запиті), а в значенні зберігати дані стану в форматі JSON. Безкоштовний примірник Redis можна розгорнути на Heroku, а з деяких пір він підтримується і в Яндекс.Хмарі.

Тепер докладніше розглянемо етапи навички. При найпершому запуску користувач бачить звичайну вітальну фразу. Далі він повинен назвати свої ПІБ, за яким навик буде шукати профіль.

Читайте також  16 DevOps конференцій 2018 року, виступи з яких варто подивитися

Якщо він знайдеться, то в стан слід записати його ім’я, і, раз вже використовується кеш, то й іншу необхідну інформацію про профілі можна покласти в нього. Тепер, коли клієнт знову повернеться в навик, він побачить персональне привітання. Якщо ж людина зайде з іншого пристрою і назве свої ПІБ, його профіль також буде знайдений в кеші, а значить уникаємо повторного пошуку через API, що економить час на обробку запиту.

Далі відбувається отримання параметрів поїздки. Я, як користувач голосового навички, хочу називати міста і дати як мені хочеться, наприклад, «Пітер», і «через тиждень». Навичка повинен вміти розпізнавати такі фрази, щоб передати повну назву міста API і виконати пошук на потрібний день. Зараз веб-сервіс навички відразу отримує цю інформацію безпосередньо у запиті:

Але така фіча з’явилася приблизно в жовтні 2018 року, а навик розроблявся трохи раніше, тому для розуміння природної мови був обраний Dialogflow. У нього є відмінна система розмітки, і періодично можна приходити навчати його, вказуючи, що в тій чи іншій фразі користувач мав на увазі.

Отже, клієнт по-своєму називає місто і дату, навик передає його слова в Dialogflow, і відправляє розпізнане назва міста API, звідки вже отримує необхідний ідентифікатор. Ланцюжок довга і тому знову велика ймовірність не вкластися в необхідні 1500 мс.

Очевидний вихід — кешувати. Причому в якості ключа можна вказувати саме те, що сказав користувач, а в значенні зберігати ідентифікатор міста з нашої системи. Тоді в кеші може бути кілька записів для одного міста, наприклад для слів «Пітер» і «Санкт-Петербург». Але це не критично, якщо значення вказано не занадто багато інформації. У будь-якому випадку, такий підхід дозволить наповнити кеш найпопулярнішими містами, які запитували інші користувачі, або «прогріти» його заздалегідь. Це дозволить надалі рідше звертатися до Dialogflow і API, що знову заощадить час.

Найцікавіший етап – це початок пошуку. Всі необхідні параметри є, але, щоб результати прийшли потрібній людині, треба якимось чином «смикнути» внутрішню службу пошуку. Крім того, сам по собі пошук виконується досить довго, а тривалі операції краще виконувати не в тому ж веб-сервісі, а в окремому додатку.

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

Таким додатком цілком може стати фонова служба.

З назви зрозуміло, що цей додаток без UI, яке має починати свою роботу разом із запуском сервера і виконувати заплановані дії або дії по певній команді (повідомленням). Таку службу зазвичай ми організуємо на фреймворку Topshelf, а команди вона може отримувати, наприклад, з черги повідомлень, заснованої на протоколі AMQP.

Якщо коротко, то черга працює приблизно так: є брокер, який відправники додають повідомлення певного типу. І є читачі, які підключаються до брокера і отримують потрібну інформацію.
Більш докладний опис можна знайти, наприклад, в цій статті.

Читайте також  Як прибрати щит з ярлика Windows

В інтернеті знайшлося хороше хмарне рішення, яке надає чергу повідомлень як сервіс – CloudAMQP. У нього є безкоштовний тариф, але працює стабільно. Ще одним аргументом для його вибору є те, що даний сервіс працює на основі RabbitMQ, який ми також щільно використовуємо на роботі.

Отже, поглянемо на роботу навику в цілому: веб-сервіс навички взаємодіє з API мобільного додатка і Dialogflow. Результати звернень до них зберігається в Redis, і там же зберігається стан. Після підтвердження параметрів поїздки навик передає брокеру повідомлення з усією необхідною інформацією. Фонова служба на тестовому сервері підключається до нього, і при появі повідомлення запускає пошук, а результати відправляються в мобільний додаток.


Коли клієнт завантажить і встановить його, то знайде їх у своїх запитах:

На цьому робота навички завершується.

Підсумки

Що ж було далі? Даний навик був показаний кільком клієнтам для отримання зворотного зв’язку, і ось що ми з’ясували: самі по собі користувачі неохоче переходять на мобільний додаток, яким би класним воно не було. Деяким з них простіше зателефонувати нашому агенту і попросити його пошукати те, що потрібно.

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

Виходить, що, завдяки навичці, можна заощадити певні ресурси і підвищити деякі ключові показники, тобто припущення про користь навички для нашої компанії підтвердилося.

Хотілося б зробити акцент на деяких висновках. Очевидний: щоб встигати в 1500 мс, уникайте виконання зайвих запитів до веб-сервісів, кэшируйте. Для однієї і тієї ж інформації можна використовувати різні ключі кеша. Це виправдано, якщо хоча б одна людина потрапить в кеш, сформований іншим користувачем. І найголовніше: краще виконувати тривалі операції в окремій фонової служби: крім того, що вона дає децентралізацію навички, у неї буде менше проблем з багатопоточністю, і при необхідності її можна «розгорнути» всередині закритої мережі компанії і «забирати» повідомлення ззовні.

Замість епілогу

Чат-боти і навички часто пишуть на JavaScript і Python (судячи по кол-ву репозиторіїв на GitHub за запитом «chatbot»). Це відбувається в тому числі з-за легкої публікації на сервера. Даний проект був написаний на C# під .net core. У випадку класичного .net framework є певні труднощі з публікацією (працює в основному під Windows, тощо), але з появою .net core багато чого змінилося. Для кожного згаданого вище сервісу або фреймворку є бібліотеки, які повністю підтримують дану технологію. Завдяки цьому навичка потенційно можна запустити на линуксовых серверах, і вже тим більше на будь-якому хостингу, підтримує Docker. Якщо раптом ви знаходитесь у творчому пошуку, рекомендую звернути увагу на цей фреймворк, він стає гарною альтернативою для розробки чат-ботів.

Степан Лютий

Обожнюю технології в сучасному світі. Хоча частенько і замислююся над тим, як далеко вони нас заведуть. Не те, щоб я прям і знаюся на ядрах, пікселях, коллайдерах і інших парсеках. Просто приходжу в захват від того, що може в творчому пориві вигадати людський розум.

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *