«Його легко можна навчити поганому»: як ми тестували програму зі штучним інтелектом

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

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

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

Ми очікували, що одразу матимемо доступ до алгоритму роботи штучного інтелекту та, виходячи з цього, розберемося, як він працює. Однак наш Product Owner придбав цей алгоритм у третьої сторони, тому вибір рішення для штучного інтелекту був винятковим бажанням клієнта. Так в умовах нашої співпраці з’явилося NDA від провайдера штучного інтелекту.

Оскільки наш замовник не мав права поділитися з нами ні кодом, ні принципами роботи алгоритму, цей ШІ для нас виявився чорною скринькою.

Щоб наш самонавчальний алгоритм працював на основі штучного інтелекту, його спочатку необхідно… правильно — навчити! Робити це нам потрібно було вручну за допомогою безлічі кейсів і сетів вхідних даних. Ми цілком серйозно розраховували на видачу адекватних результатів від програми, яка вміє думати. Однак на практиці наш інструмент зовсім не відслідковував адекватність встановлених нами даних. З цим теж треба було щось робити.

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

На вхід до системи подавалися анкети користувачів. Потім система аналізувала ці дані і, керуючись своїми алгоритмами на основі штучного інтелекту (та сама чорна скринька), видавала результат збігу: відмова (збігу не виявлено) або наявність збігу (результат вказувався у відсотковому співвідношенні).

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

Але як саме система виносила свій вердикт, нам було невідомо.

Планування тестування

Щоб полегшити собі тестування системи на базі штучного інтелекту, ще на етапі планування процесу зверніть увагу на такі аспекти:

• Попросіть у замовника якомога більшу кількість тестових даних. Чим більше у вас буде валідних вхідних даних, тим простіше скласти адекватний data setup і розпочати навчання системи.
• Зберіть злагоджену команду. Можливо, це звучить банально, але у нашому випадку цей аспект зіграв вирішальну роль. Враховуючи те, що системи на основі штучного інтелекту самонавчальні, під час прийняття командою невірних рішень у роботі з нею, легко можна навчити ваш штучний інтелект поганому. В результаті програма буде мислити неправильно і працюватиме некоректно.
• Попросіть у Product Owner дані про відсоток допустимої похибки. Так ви заощадите собі багато часу і нервів.
• Вчіться думати нестандартно. Не намагайтеся передбачати дії штучного інтелекту. Спробуйте зрозуміти його нестандартну логіку і тоді легко зможете взаємодіяти з нею.

Технічні вимоги та (не)відповідність їм — як діяти?

Повернемось до нашого прикладу. У вимогах не йшлося про алгоритм, завдяки якому система ухвалює рішення. У технічній документації згадувалися лише загальні дані щодо UI. Жодним чином не був описаний user flow — сценарій взаємодії користувача з системою.

User flow наочно ілюстрував би порядок дій, необхідний для коректної роботи застосунку.

Сценарій «Користувач виконує дію X, система відповідає дією Y… і все працює» — цілковито не відповідав тому, з чим ми зіткнулися.

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

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

Підготовка до тестування

Перш ніж розпочати тестування ПЗ з елементами штучного інтелекту, переконайтеся, що у вас:

• Налагоджено надійний контакт із замовником ПЗ. Лише ця людина добре уявляє, що саме вона хоче отримати від системи, яка розробляється.
• У команді є фахівець, відповідальний за інтеграцію. Він зможе хоч якось впливати на роботу програмного алгоритму.
• За можливості налагодьте контакт з розробником ПЗ. Спілкування з ним допоможе суттєво полегшити розуміння того, що саме написано в коді.
• Вивчайте user flow. Якщо ви не будете досконало розуміти де, як і навіщо ваш замовник впроваджує штучний інтелект, ви не зможете зрозуміти, як саме його тестувати.

Тестування продукту

У нашому випадку він розпочався з повного абсурду:

1. Насамперед ми побачили відсутність будь-якої адекватної інтеграції — зі старту вона взагалі не працювала.
2. Другою причиною абсурдної поведінки став досить високий відсоток похибки системи (у нашому випадку вона коливалася аж до 50%), що ніяк не відповідало вказаній похибці у технічній документації.
Онлайн-курс DevOps engineer від Mate academy.
DevOps інженери відповідають за автоматизацію процесів розробки, тестування та випуску продукту. Завдяки цьому курсу ви швидко станете високооплачуваним спеціалістом.
Отримати знижку на курс
3. І третє — негативні перевірки та тестування із граничними значеннями принесли протилежні від очікуваних результати.

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

Звідси висновок: використання негативних тестів для самонавчених алгоритмів потрібно мінімізувати, довівши їх до одного-двох.

У процесі тестування ми виділили декілька важливих аспектів. Радимо вам врахувати ці моменті у своїй роботі:

• Пам’ятайте: системи на базі штучного інтелекту підходять для імітування реального процесу ухвалення рішень. Тому під час їх тестування відштовхуйтеся від ситуацій, які можуть статися з користувачем, коли він взаємодіє з продуктом.
• Опануйте підключення стороннього інструменту ШІ з вашим застосунком. З’ясуйте, як саме функціонує серверна частина і як відбувається індексація даних. Це допоможе уникнути дефектів.
• Постійно тренуйте вашу систему. Вона ж створена для того, щоб навчатися. Правильно підбирайте валідні тестові дані, виходячи з даних production-сервера. Аналізуйте результат не за сухими інструкціями з техдокументації, а за власною логікою. Майте на увазі, що негативні тести слід використовувати обережно. Інакше можна навчити систему «думати» неправильно.

Перш ніж передавати продукт у продакшн, переконайтеся, що ви дотримались наступних умов:

• Клієнт знає, що продукти на основі штучного інтелекту не можуть працювати «з коробки» ідеально. Спочатку їх треба навчити, тренуючи систему на валідних вхідних даних.
Онлайн- курс Java developer від Mate academy.
Якщо ви не можете навчатись повний день, обирайте курс Java developer з гнучким графіком! Ви зможете опанувати нову професію та отримати нову роботу!
Отримати знижку на курс
• Якщо ваш Product Owner не має таких даних, наполягайте на проведенні бета-тестування та UAT — користувацького тестування. Все ж таки участь реальних людей у тестуванні продукту не замінять жодні першокласні тест-кейси.
• Одразу тестуйте hot-fixes. Таким чином ви переконаєтеся, що розробники правильно проаналізували знайдені вами дефекти і внесли потрібні коригування в код. Однак будьте готові до того, що тестування може відбуватися в овертайм.

Замість висновку

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