Дек. 19

Як перевіряти роботу NLP в текстових асистентах: поради та чекліст для QA

Привіт! Мене звуть Іра Ярославцева, і вже п’ять років я займаюсь тестуванням, три з яких — текстових асистентів (чат-ботів, систем NLP, голосових асистентів). За цей час співпрацювала з компаніями в різних бізнес-доменах. Наприклад, зі всесвітньо відомим мобільним оператором T-Mobile, косметичним брендом Aveda та спортивною організацією World Surf League.

У цій статті ми розглянемо:

що таке NLP і фази роботи з такими системами;
челенджі, які можуть бути під час тестування NLP;
методи, що допоможуть з ними впоратися;
і як бонус — QA-basic-чекліст.

Матеріал буде корисним насамперед тестувальникам, а також усім, хто працює в ІТ, щоб розуміти тенденції розвитку індустрії.

Актуальність

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

За дослідженням Oracle, до 2020 року 80% брендів планують мати чат-бот. Ідеться про реальний досвід людського спілкування з бізнесом і вирішення запитів користувача, а не про звичайну програму, що видає не завжди влучні «картки» з готовими відповідями. Це вимагає вдосконалення інтерфейсів спілкування. Тому кількість проектів росте, як і їхні масштаби: від звичайного бажання замовника перевірити готовність своєї аудиторії (запуск невеликого скоупу з поступовим наростанням фіч) до великих проектів.

Ці тенденції вимагають розробки та тестування нових типів спілкування, зокрема NLP. Оскільки повної та змістовної інформації про тестування NLP мало, я хочу поділитися своїм досвідом.

Особливості роботи з NLP

Обробка запитів людей — основна складність під час створення чат-бота, і це можна зробити двома способами:

Задати строгий набір команд у форматі «запитання-відповідь», що суттєво лімітує систему. Це системи Rule-based, які можна порівняти з роботою веб-сторінок, чітко обмежених адресою.
Підключити машинне навчання, що допоможе моделі розуміти користувача за кількома ключовими словами. Це системи AI-based, в основі яких лежать моделі NLP (Natural language processing — системи обробки природної мови).

У статті розглянемо тестування таких NLP-систем.

Робота з NLP триває впродовж усього циклу розробки й поділяється на 4 фази: дискавері, тренування моделі, безпосередньо тестування та навчання після виходу в реліз.

Фаза 1. Дискавері

Тестування NLP починається на стадії збору вимог. Тут важливо визначити такі моменти:

Мова. Впливає на вибір NLP-інструмента, кількість часу, який буде закладено в тест-план, залучення додаткових спеціалістів у команду.
Feature scope. На час розробки та тестування на кількість фраз для перевірки впливає ще й те, який функціонал завдяки NLP-діалогам хоче покрити клієнт.
Цільова аудиторія. Деталі про стать, вік, геолокацію, професію — показники, що допоможуть вибрати оптимальні висловлювання для тренування і тестування.

Фаза 2. Тренування моделі

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

Фаза 3. Тестування

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

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

Для розв’язання цих проблем і ефективного тестування NLP ми виділили два методи:

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

Фаза 4. Навчання на продакшені

Після релізу починається найцікавіша фаза тестування — збір статистики. Нам важливо розуміти:

чи дійсно користувачі пишуть те, що ми очікували;
які слова і фрази найпопулярніші;
як система реагує на валідні та невалідні запити.

Після аналізу інформації потрібно:

визначити, що варто додати, змінити або видалити в поточній моделі;
перетренувати систему;
зробити ще один раунд тестування, щоб зрозуміти, як поводитиметься нова модель.

Ця фаза може повторюватись 1-2 рази на місяць, залежно від нової функціональності, побажань клієнта та результатів попереднього аналізу.

QA-basic-чекліст

Це результат роботи над статистикою та ризиками, який покриває основні тестові ідеї. У ньому найважливіше опрацювати:

1. Помилки в словах

У доборі слів для тестування потрібно аналізувати ризики й вибирати найкритичніші варіанти. Наприклад, якщо функцією нашого асистента є доставка піци, обов’язково потрібно перевірити всі варіанти написання з помилками слів «оrder» та «pizza».

2. Слова-синоніми

Щоб дібрати оптимальну кількість слів, потрібно фокусуватися на найуживаніших синонімах. У цьому можуть допомогти словники та статистика юзер-інпутів. Синонімами також можуть бути цілі фрази.

3. Речення, які крім ключових фраз мають додаткові слова, що не належать до основного наміру користувача

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

4. Речення, які крім ключових фраз мають смолтоки (smallTalks)

Цей кейс тестується окремо від попереднього, бо фрази смолтоку належать окремій групі слів — smallTalk. У такому разі QA має перевірити, чи система правильно розпізнає ключові слова й адекватно відповідає користувачам.

5. Різні наміри, але ті ж слова

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

Наприклад, користувач зробив покупку, не отримав доставку вчасно і написав у чат-бот: «I’d like to know where is my dress». Це trackOrder-намір. У такому випадку повести користувача на makeOrder-контент буде недоречно. Імовірно, що людина не зробить ще одну покупку, покине застосунок і звернеться у службу підтримки на веб-сайті.

6. Випадки, коли NLP мовчить

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

7. Випадки, коли NLP допомагає користувачу не заблукати в структурі бота

Це актуально тоді, коли асистент має послідовну структуру (тобто після першого кроку юзер відразу переходить до другого). Тут необхідно врахувати, що користувач може випадково вийти з бота, не завершивши всі кроки. Ми пропонуємо додавати повторні запитання, щоб повернути його в попередню точку. Але щоб «перепитування» не дратувало користувача, варто дібрати кілька варіантів одного питання. Тут обов’язково передбачити вихід із циклу для користувачів, які мають інший запит — кнопки «back» чи «exit».

Не завжди чек-ліст — це єдиний інструмент. На проектах трапляються челенджі, які вимагають додаткових зусиль.

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

Висновки

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

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

Вдалий досвід роботи з таким персональним асистентом підвищує задоволення користувача (Customer satisfaction — важливий KPI для бізнесу). Та це працює тоді, коли NLP-складова бездоганно протестована, що зі свого боку залежить від тестової стратегії. Стратегія, в основі якої лежать аналіз ризиків і робота зі статистикою, показала непогані результати на реальних проектах і допомагає уникнути вищезгаданих проблем і невпевненості за якість продукту.