Тестування AI в застосунках: як забезпечити коректність, безпечність і користь для юзера

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт! Мене звати Люда, я QA Engineer із понад трирічним досвідом у сфері тестування. Зараз працюю в Universe Group — групі компаній, що вже понад сім років будує tech-бізнеси, перетворюючи ідеї на глобальні продукти. Один із з них — Guru Apps, де я відповідаю за якість застосунку Visify, що за допомогою AI редагує фото та генерує контент.

Я люблю наш продукт, бо він поєднує технології та естетику. Завжди дивує, як один клік може зробити фото більш «живим» і впевненим. Особливо приємно, коли користувачі дякують за результат.

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

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

Як тестувати AI в застосунку

Штучний інтелект (AI) все частіше зʼявляється в наших проєктах, але тестування таких систем сильно відрізняється від класичного підходу. AI не гарантує однакову відповідь навіть якщо давати ті самі вхідні дані. І це створює додаткові ризики. Тому часто треба підключати власну надивленість і критичність.

Також при тестуванні АІ досить складно відтворювати баги й для цього потрібно прилаштуватися. Тому до тестування треба підходити трохи інакше.

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

1. Спочатку розібратись, який AI використовується

Оскільки тестування AI завжди залежить від контексту, на старті важливо зрозуміти, який саме стек використовується у продукті.

Специфіка AI, що використовується:

  • NLP — тестуємо, як AI розуміє запит, відповідає по темі, чи підтримує різні мови.
  • Computer Vision — дивимось, як розпізнаються обʼєкти, як впливають ракурс, освітлення, якість фото.
  • Generative AI — фокус на сенсі, доречності, візуальній якості та безпечності результату.
  • Audio AI — сюди входить speech-to-text, text-to-speech, виявлення емоцій, шумоприглушення. Тут важливо тестувати акценти, швидкість мовлення, фон, якість аудіо.

Комбінації стеків — норма

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

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

Це допоможе визначити ризики і зрозуміти, де шукати потенційні проблеми.

Наприклад, може бути так, що перед генерацією зображення робиться captioning, коли AI сам описує, що бачить на фото. І якщо вже на цьому етапі щось піде не так (наприклад, не впізнає окуляри або неправильно опише стать), то й генерація буде дивною. Або навпаки, captioning описує як треба, але модель погано генерує якусь расу. Відповідно при тестуванні важливо шукати слабкі місця кожного з елементів.

Що тестуємо — те і готуємо

Від того, який стек AI використовується, залежить і те, які тестові дані потрібно готувати: для Vision — це картинки, для NLP — тексти, для скорингових моделей — табличні або числові значення. Кожен стек має свої специфічні ризики. Наприклад, NLP може бути токсичним, а Vision — помилятись у розпізнаванні або генерувати дивні образи.

2. Input/output — наші головні орієнтири

AI — це чорна скринька. Але ми точно можемо контролювати, що в неї входить і що виходить.

І якраз від того наскільки ви «пограєтесь» з вхідними даними залежить можливість спіймати неочікувані баги.

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

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

Тому важливо:

  • розуміти, що саме ми передаємо в інпут (текст, фото, відео, аудіо і т.д.).
  • перевірити, як змінюється результат при іншому input.
  • з’ясувати, які параметри та характеристики інпуту AI аналізує під час обробки, і як саме вони впливають на результат
  • розуміти, який результат очікуємо на виході і як він має виглядати.

3. Навіщо це взагалі — бізнес-ціль і користь

І найважливіше розуміння перед тестуванням — які потреби бізнесу та юзера має вирішити АІ в застосунку. Наприклад, це може бути реальна користь для юзера, яка природно тягне за собою покращення метрик. Це розуміння дозволяє створювати реальні use-cases, які має пройти AI.

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

Основні напрямки тестування AI

Перевірка функції

Перше питання, яке виникає — чи працює взагалі. Тому важливо перевірити:

  • чи АІ віддає результат?
  • чи працює на різних сценаріях?
  • чи відповідь має правильний формат?
  • і найголовніше — чи вона по темі? Памʼятайте, що АІ може віддати результат, навіть у правильному форматі, але на запит: «Покажи дешеві страхові» віддає рандом. І весь сенс втрачається.

Тому важливо бачити різницю. Функціональне тестування AI на відміну від класичного — це не про «відповідність очікуванню» або «правильно чи неправильно», а про «адекватно чи ні, доречно чи ні, корисно чи ні».

Перевірка коректності результату

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

  • Чи відповідь по суті?
  • Чи AI нічого не вигадав?
  • Чи немає порушення compliance?
  • Чи правильний формат?

Тому важливо постійно розвивати експертизу в оцінці коректності. У цьому можуть допомогти такі дії:

  • Збір хороших прикладів (golden dataset).
  • Фіксування прикладів поганих кейсів.
  • Формування загальних вимог до результатів.
  • Спілкування з Product managers/ML-командою.
  • Аналіз фідбеку від реальних юзерів.

Можна вести таблицю, де для кожної операції фіксувати те, що може стати корисним при наступному тестуванні: особливості, фідбек від юзерів, коментарі від ML-команди, кейси, які неможливо пофіксити, дивні ситуації тощо. Тобто все, що можна використати як «expected result» у майбутньому.

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

UX AI-функції

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

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

Щоб бути впевненими, що використання АІ в застосунку буде комфортним для юзера, важливо впевнитись:

  • Чи зрозуміло, що застосунок використовує АІ, та яка суть дії?
  • Як виглядає результат, чи він зручний та зрозумілий для юзера? Чи використовується коректна мова?
  • Чи є зрозумілі повідомлення, якщо щось пішло не так?
  • Чи може користувач взаємодіяти з результатом, відмовитись або відредагувати?
  • Чи може поділитись своєю думкою щодо результату?
  • Чи надає АІ свою послугу по запиту, не навʼязуючись самостійно?

Негативні сценарії

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

Важливо перевіряти AI на некоректні inputs у класичному розумінні (порожні поля, смайлики, довгі тексти тощо), а також імітувати ускладнення, які можуть виникати під час використання — шумне середовище при голосовому запиті або не комплаєнс запити до AI.

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

Тестування етичності та упередженості

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

Промпти

Промпт — це як код. Якщо класичний код має баги, то й промпт може їх мати.

  • Якщо промпт занадто загальний — результат вийде нечіткий, «про все й ні про що».
  • Може мати стереотипи або упередження, про які навіть не думаєш.
  • Може містити токсичні/емоційні тригери. Наприклад, згенерувати небезпечний або дивний контент.
  • Не враховує edge-cases, а модель «ламається» або видає нісенітницю.

Наприклад, у запиті ми написали: «write a short note about a cool project». Мали на увазі «цікавий» проєкт, але AI сприйняв cool буквально — як «пов’язаний із холодом» — і створив текст про кліматичні технології.

Як ми це хендлимо:

  • Створили набір прикладів із потенційно небезпечними або емоційними тригерами (наприклад: red, dark, broken, black, child, etc).
  • МL-команда переглянула логіку формування промптів.
  • Тестимо на прикордонних кейсах — спеціально використовуємо inputs з потенційною неоднозначністю, щоб «виловити» подібні ситуації до релізу.

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

Регресія та стабільність

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

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

В нас була ситуація, коли на запит «Як готувати борщ?», який до цього оброблявся коректно, після оновлення версії AI на більш ​​просунуту — він відмовлявся давати відповідь.

Тому щоб це контролювати, важливо відстежувати такі кейси:

  • чи стабільні результати на одних і тих самих даних?
  • чи не стало гірше?
  • чи не з’явились нові дивні затримки?
  • чи не змінилась логіка відповіді?
  • чи не зникла раніше виправлена проблема?
  • чи не вилізло щось нове, що порушує compliance?

І наостанок

При тестуванні АІ завжди треба памʼятати, що він може бути супер-розумним, технічно правильним, навіть вражаючим. Але якщо він відповідає повільно, непередбачувано або небезпечно — користувач піде. А отже, вся магія зникає.

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

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Мені сподобалось, з досвіду добавлю ще думок

Тестування AI значно складніше, ніж здається. Це не просто перевірка output моделі, а повноцінний QA контроль усієї ML інфраструктури, де будь-яка похибка в даних, анотаціях чи логіці може спричинити критичні помилки (в неті є достатньо прикладів)

Фокус має йти на весь end-to-end ML lifecycle, що може включати: аудит датасетів, перевірка анотацій, моніторинг метрик, model drift, оцінка bias, regression між версіями.

Великий акцент робиться на класифікацію AI-багів: data bugs, annotation bugs, model bugs, pipeline bugs, behavior bugs на edge-case в інпутах і тд. Також потрібно приділити час на evaluation моделей і вести реальний моніторинг моделей на продакшені. Документації буде багато, хоча її не хочеться писати.

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

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

Дякую за цікаву інфу! Можу уявити, які «неочікувані» результати може генерувати АІ в стадії тестування. Також з тексту розумію, що не стільки важлива «правильність», як зручність та комфортність для юзера

Дякую за дуже цінну інформацію

Дуже цікавий досвід, дякую, що поділилась!)

Підписатись на коментарі