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


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

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

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

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

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

Ідея

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

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

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

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

Читайте також  Як дізнатися ємність батареї ноутбука в Windows 10

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

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

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

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

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

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

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

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

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

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

Читайте також  Розсікаючи складне: дорожня карта ефективного співробітництва

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

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

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

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

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

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

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

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

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

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

Читайте також  В Італії знайдено поховання «Вампіра Луньяно»

В інтернеті знайшлося хороше хмарне рішення, яке надає чергу повідомлень як сервіс – 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 адреса не оприлюднюватиметься. Обов’язкові поля позначені *