Мульти-ботовий підхід до впровадження корпоративних чат-ботів.
В першій частині цієї багатосерійної серії блогів ми описали чотири проблеми, з якими можуть зіткнутися бізнес-чат-боти, розширюючи свої можливості та сферу застосування, часто приводячи до збоїв ботів, що випливають з обмежень поточної технології NLP. Хоча одне – визнати недоліки сучасної технології NLP з точки зору обсягу намірів і висловлювань, з якими бот може добре впоратись, задовольняючи потреби конкретного випадку використання бізнесу, підходу до вирішення цього бракувало.
З настанням 2020 року розширення рішень чат-ботів у великих організаціях, безсумнівно, призведе до підвищення обізнаності про обмеження НЛП та наслідку, що вплине на досвід користувачів. У цьому випадку ми очікуємо, що підприємства почнуть застосовувати концепцію спільного багатомодельного підходу до організації ботів в організації.
Боти = навички
У нашому попередньому блозі ми представили концепцію організації ботів навколо навичок, подібно до того, як компанія організовує навички співробітників. Подібно до того, як жодна людина в бізнесі не може робити все, така ж логіка застосовується і до ботів. Незважаючи на те, що концепція індивідуальних навичок не є унікальною і застосовується такими, як Amazon від Alexa та Google Assistant, підхід до того, щоб ці навички співпрацювати більш спільно, використовуючи природну мову, є тим горіхом, який підприємство ще не розірвало.
Представляємо модель оркестровки з декількома ботами
Щоб забезпечити більш послідовний та послідовний досвід роботи кількох бізнес-ботів, необхідний спільний підхід. Подумайте про це з точки зору того, як кваліфіковані співробітники співпрацюють, щоб ефективно задовольнити потреби клієнта чи бізнесу.
Ми розглянемо прецедент мультимодельних підходів та недоліки рішень ботів першого покоління, які спрямовують користувачів між ботами подібними структурованими способами, як традиційні IVR обробляють вхідні запити, та направляють вас до служби відповідно до заздалегідь визначеного вибору.
Потім у блозі пропонується модель оркестровки з декількома ботами, яка створює можливість для співпраці, яка долає проблеми з поганим досвідом та обмеженнями NLP, викладаючи елементи цього підходу та чому це важливо в контексті впровадження корпоративних чат-ботів.
Прецедент чат-ботів для організації навичок
Той факт, що один бот не може зробити все і що потрібен мультимодельний підхід, не є новою концепцією. Наприклад, Alexa та Google Assistant від Amazon, коли вони вперше були запущені, мали лише кілька навичок сторонніх розробників, що спричинило обмежене використання та поганий досвід.
Однак зараз Alexa може похвалитися понад 100 000 навичок, в основному внесених третіми сторонами, а не самою Amazon. Оскільки до цих ботів додаються навички, їх можливості розширюються, щоб зробити їх більш ефективними в широкому спектрі функцій. Google підійшов до цього подібним чином, хоча вони вже інтегрували свій AI у свого помічника і змогли відкрити для нього новий канал, що дозволило їм розширити його сферу застосування.
Незважаючи на зростання кількості навичок, якими володіють ці асистенти, користувальницький досвід все ще фрагментований і складається з купи різнорідних навичок, які не призначені для спільної роботи. Отже, вони зазнають деяких ключових недоліків, таких як:
Співпраця між навичками дуже обмежена, що часто призводить до роз’єднаності та розчарування досвіду користувачів.
Вам потрібно використовувати ім’я виклику навички, щоб викликати запит. Користувач повинен знати назви навичок, щоб змінити навички, а не покладатися на виявлення намірів для зміни навичок. Для цього потрібні знання від імені користувача під час постійного навчання, необхідного для інформування користувача про всі імена та можливості навичок. Це може призвести до плутанини та помилок у розумінні асистента користувача.
Вони все ще не дуже добре вирішують складні питання, тобто мені потрібна копія рахунку, щоб я міг погасити залишок, оскільки переїжджаю додому.
Виклик для віртуальних помічників підприємств = співпраця між навичками
Оскільки підприємства прагнуть перетворити деякі основні бізнес-процеси на можливості самообслуговування з використанням ботів, їм потрібно пройти аналогічний шлях і створити власного помічника, подібного до Alexa або Google, узгодженого з їхніми бізнес-вимогами та з багатьма навичками (або ботами), які може виконувати різні можливості.
Підприємства формують навички власних ботів, оскільки їм потрібно контролювати бренд свого віртуального помічника, але оскільки вони додають навички, завдання, з яким вони стикаються, полягає у забезпеченні узгодженого та послідовного досвіду роботи з усіма цими навичками.
Створення ботів з різними навичками не є ключовою проблемою для підприємства. Зрештою, прецедент уже є з подібними Alexa та Google Assistant. Більше питання, яке потрібно вирішити, – це як організувати кілька навичок в одну розмову, тобто як боти можуть співпрацювати для вирішення складеного запиту?
У більшості бесід є частини, які не пов’язані із завданням. Якщо один бот повинен обробляти всі завдання, тоді він стає занадто великим для управління. За допомогою декількох ботів ви можете спеціалізуватись на виконанні завдань і робити речі простішими, але це означає, що для завершення розмови потрібно переходити між ботами.
Google і Amazon ще не вирішили цього, оскільки їхні навички не співпрацюють, але це те, над чим підприємству потрібно буде працювати, щоб створити послідовний досвід роботи з брендом.
Шість елементів підходу до мультиботівської оркестрації
То що означає спільний підхід до оркестровки до проектів корпоративних ботів?
Ось шість ключових концепцій, що лежать в основі моделі оркестрації з декількома ботами.
Все можна адресувати з однієї точки або розмови. Контекстуально відповідні навички повинні автоматично використовуватися природною мовою, а не іменами, що викликаються, під час розмови. Наприклад, якщо клієнт Capital One хоче перевірити свій банківський баланс через Alexa, він повинен спочатку застосувати цю навичку, сказавши “запустити Capital One”. Коли на все можна звернутись, покласти на користувача обов’язок знати необхідні навички та використовувати їх, це вже не проблема.
Випадок використання бізнесу не обмежується моделлю AI. На сьогоднішній день модель штучного інтелекту для одного бота може бути замалою, щоб задовольнити потреби в комерційному випадку. Про це йшлося в нашому блозі про те, чому корпоративні чат-боти не працюють, тобто.
= Існує практична верхня межа можливостей штучного інтелекту з точки зору максимальної кількості намірів та тем, які можна обробляти в рамках однієї моделі.
= Коли моделі використовуються для вирішення конкретного завдання, цієї верхньої межі достатньо, щоб врахувати всі випадки використання бізнесу.
= Організація декількох моделей разом призводить до додаткового збільшення загального розуміння AI.
= Якщо в одній моделі упаковано занадто багато, вам потрібно зробити компроміси щодо якості та функціональності. Це трапляється занадто часто, коли організація створює перших декількох ботів. Вони беруть відгуки користувачів і додають чат-чат та інші приємності своєму єдиному боту. Це фактично знижує верхню межу функціональності, яку може забезпечити бот, і ставить під загрозу якість розуміння.
Входить концепція різних типів ботів. Не всі боти однакові. Можуть бути боти для подорожей клієнтів або боти, які обробляють транзакції, бесіду, мову та інші різні функції. Це стає важливим, коли ви починаєте розглядати історії, історію та стан. Штат посилається на шляхову точку та історію подорожі користувача, тоді як без громадянства – це коли бот не повинен знати, що пішло раніше, щоб продовжувати правильно реагувати. Наприклад, подорожній бот повинен пам’ятати стан, тоді як бот FAQ не має статусу і не повинен пам’ятати, що було раніше. У підході до спільного бота всі вони можуть працювати разом, коли це необхідно для виконання необхідних завдань.
Неоднозначність необхідна, щоб знати, який бот повинен вжити заходів. Те, як користувачі щось просять, тобто їх висловлювання, може сильно відрізнятися. Коли кілька ботів працюють разом, чим менш двозначним є намір, тим більша ймовірність того, що він буде правильно направлений до відповідного кваліфікованого бота. Прикладом страхової компанії, яка займається кількома продуктами, є той факт, коли клієнт запитує котирування, не вказуючи, який товарний ряд, тобто „я хочу отримати ціну” Отже, системі потрібно усунути неоднозначність (тобто усунути неоднозначність) і з’ясувати, який бот може обслуговувати користувача. Тож бот може запитати: “Вам потрібна страховка для вашого човна, машини чи будинку?”
Обмін інформацією між кількома ботами. Це означає, що всі боти можуть отримати доступ до спільних служб у бізнес-процесах так само, як кваліфіковані працівники можуть отримати доступ до спільних ресурсів, таких як ІТ, HR та ін. Це створює більшу ефективність та послідовність у моделі та кращий досвід для клієнта. Наприклад, клієнт не повинен ідентифікувати себе або номер свого рахунку щоразу, коли він перемикає контекст на нового бота.
Нагляд та управління допомагають контексту ниток разом. Ключовою функцією цього є не просто звернення до потрібного бота, а можливість прив’язати відповіді окремих людей до контексту в рамках розмови. Це має вирішальне значення у забезпеченні хорошого досвіду роботи з брендом так, як це робить людина. Нагляд також важливий для визначення впливу на користувача шляхом виявлення таких ситуацій, як винятки, настрої, пропущені введення чи висловлювання та знання того, що робити, якщо бот не відповідає.
Як виглядає мультиботова оркестрація
Після того, як ці елементи встановлені, ви отримуєте набір тонких ботів, які визначаються за тематичною областю, типом чи функцією, при цьому кожен бот усвідомлює свої індивідуальні межі.
Це схоже на експертів з предметних предметів різних відділів. Наприклад, у страховій компанії відділ збитків може мати різних спеціалістів або навички роботи з різними лініями страхових продуктів або на різних етапах повного процесу розгляду претензій – від відповіді та подання позову, обробки позову, відшкодування витрат клієнту тощо.
Потім їх оркеструє мозок з певними функціями, які централізовані та доступні для всіх. Ці спільні послуги аналогічні різним сферам бізнесу, що використовують спільні ресурси або послуги, такі як ІТ, кадровий персонал, фінанси, адміністрація та інші.
Приклад мульти-бот-моделі в обслуговуванні клієнтів
Ще одним хорошим прикладом цього є те, як центри обслуговування клієнтів організовані навколо навичок, напр. виставлення рахунків, скарги, замовлення, стан рахунку, активації, повернення тощо. Коли підхід до бота не є спільним, рішення може стати дуже громіздким.
Ми бачили, як деякі великі організації застосовують кілька рішень для ботів, де вони не можуть переключати контекст, використовуючи природну мову. Ці рішення незмінно передбачають безглузду маршрутизацію до ботів-предметів із маршрутизацією на основі відповідності ключових слів та вибору із заздалегідь визначених списків – підходу, який покладається на евристику, схильну до помилок, а не на природну розмовну маршрутизацію. Ці рішення вимагають тригерів, таких як системи IVR, або виклик навичок Alexa, покладаючи на користувача обов’язок розуміти структуру та місце, де бот направляє користувача назад на початок, якщо вони змінюють контекст.
Навпаки, природна маршрутизація розмов – це маршрутизація на основі намірів, за допомогою семантики для виявлення наміру, а потім визначення наступного найкращого кроку. Помітне поліпшення точності та ефективності, коли маршрутизація базується на намірах, а не на евристиці, і являє собою розумніший підхід до організації декількох ботів. Машинне навчання просунулося настільки, що тепер ми можемо створити розумну маршрутизацію, яка підтримує контекст в межах однієї розмови, і саме тому ми створили модель спільної оркестрації, яка базується на AI та машинному навчанні, а не на евристиці.
Короткий зміст: переваги мультимодельного підходу.
По мірі розширення та зрілого впровадження розмовного штучного інтелекту в різних випадках використання, аргумент для моделі організації декількох ботів буде важко ігнорувати. Переваги цієї моделі спільної оркестрації, яку створив ServisBOT, є:
Ви можете відслідковувати кілька розмов: Навіть маючи загальну розмову в грі, наша модель також відстежує, як користувач розмовляє окремо з кожним ботом. Він також може відстежувати стан у поїздках, щоб бот запам’ятав попередню історію. Це забезпечує більш складні випадки використання та покращує взаємодію з користувачем.
Складність та витрати на обслуговування зменшуються: утримання тонких ботів набагато простіше у виконанні. Ви можете протестувати окремі функції, щоб бути впевненими, що вони працюють належним чином. Складність різко знижується, тому простіше налаштувати модель і підтримувати загальну якість досвіду. Отже, витрати на обслуговування бота нижчі.
Ви можете легко вмикати та вимикати ботів: Ви можете динамічно видаляти бота з режиму реального виконання без необхідності перебудовувати весь досвід роботи Віртуального помічника. Це полегшує швидке внесення змін, якщо виникає необхідність.
Ви можете отримати вищу точність, не дотримуючись обмежень NLP: Точність моделей AI падає, коли кількість налаштованих намірів та тем стає великою. Для досягнення високих рівнів точності можна обмежити кількість намірів на модель, а потім поступово додавати більше моделей.
Ви можете розширити ширину випадків використання та функціональність: оскільки у вас є можливість продовжувати додавати більше навичок, функціональність або діапазон випадків використання можна розширити у кожному бізнесі. Наприклад, Alexa від Amazon, на даний момент, може розрізняти 100 000 навичок за іменами. Тоді питання в тому, скільки навичок визначають ваш бізнес?
Для отримання додаткової інформації про наш спільний підхід до декількох ботів для впровадження корпоративних чат-ботів ви можете запланувати демонстрацію або поговорити з нашими технічними експертами.
Щоб побачити чудовий проект чат-бота в дії, перегляньте наше тестування клієнтів щодо страхування.
Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/6-elements-multi-bot-approach-overcome-nlp-user-issues-cathal-mcgloin/.
Cathal McGloin люб’язно дозволив нам перекласти і опублікувати цю статтю.
Temy.co - Software Development Partner 