Тестування LLM-продуктів
Тестування LLM-продукту — це тестування фічі, яка може двічі відповісти на те саме питання по-різному, а кожна ваша практика тестування припускає, що той самий ввід дає той самий вивід. LLM-фіча це ламає, і звична реакція — вирішити, що її не можна тестувати. Це неправда, і дорога неправда. Більшість важливого в LLM-фічі досі перевіряється точно, та частина, що ні, стає вимірюванням проти порога, а робота тестувальника зміщується від написання кроків до визначення, якою є добра відповідь. Ця сторінка — про це зміщення і про те, що робити в понеділок після нього.
- Перевірка стає
- Вимірюванням
- Тестуйте спершу
- Те, що досі точне
- Один запуск —
- Не доказ
Що справді змінюється, а що ні
Змінюється одна річ: ви більше не можете стверджувати, що вивід дорівнює очікуваному рядку. Усе інше, що з цього випливає — що один запуск мало що доводить, що результати читають як частки, що потрібен набір кейсів, а не кейс, — є наслідком саме цього факту, а не новою дисципліною.
Права панель притягує увагу, а починати роботу слід із нижнього ряду. Ще до будь-якої оцінки велику частку того, що справді хвилює власника продукту, можна перевірити точно: що відповідь є валідним JSON за схемою, якої чекає інтерфейс; що класифікація — одна з чотирьох дозволених міток; що виклик інструмента ніс правильні аргументи; що в тексті немає персональних даних; що відповідь прийшла в межах бюджету затримки й нижче стелі вартості. Це звичайні тести зі звичайними перевірками, і їм місце в тому самому наборі, що й усьому іншому.
Спершу збудуйте детермінований шар
Перш ніж написати бодай одну оцінювану перевірку, покрийте те, що має точні відповіді. Це дешево, виконується за мілісекунди, ніколи не суперечить саме собі, і кожен такий тест закриває збій, що інакше дійшов би до користувача.
| Перевірка | Що не дійде до користувачів |
|---|---|
| Відповідь парситься й відповідає схемі | Порожній екран чи падіння, коли модель повертає текст там, де інтерфейс чекав полів. |
| Мітка — одне з дозволених значень | Пʼята категорія, вигадана на місці, що тихо скеровує тікети в чергу, яку ніхто не читає. |
| Інструмент викликано, з цими аргументами | Агент, що впевнено відповідає з памʼяті замість того, щоб щось знайти. |
| Кожна цитата існує в джерелі й містить твердження | Правдоподібна відповідь, прикріплена до документа, що каже інше, — найшкідливіший збій у пошуковому продукті. |
| Жодних персональних даних, секретів та внутрішніх ідентифікаторів у виводі | Регуляторний інцидент — це не баг-репорт, а лист від чийогось юриста. |
| Кейси відмови досі відмовляють | Зміна промпту, що зробила асистента кориснішим — і водночас охочішим робити те, чого не можна. |
| Затримка й вартість на виклик у межах бюджету | Фіча, що працює бездоганно і яку вимикають наприкінці місяця через її вартість. |
Зміна ролей: хто що пише
Тестувальник на звичайній фічі пише кроки й очікувані результати. На LLM-фічі кроки тривіальні — надішли це, прочитай те, — і вся складність переїжджає у визначення того, якою є добра відповідь. Це визначення є специфікацією, його справді важко написати, і це найцінніший артефакт на проєкті.
QA володіє визначенням «добре»
Записана рубрика: що має бути присутнім, чого не має бути ніколи, який тон, що робити, коли відповідь невідома. Без неї кожен розбір — суперечка про смак.
QA володіє корпусом збоїв
Кожна скарга, інцидент і дивна відповідь стають кейсом. Догляд за цим — саме та робота, що робить набір кращим у міру користування продуктом.
Розробка володіє каркасом
Запуск набору, закріплення версій, запис результатів, вбудовування воріт у пайплайн. Це звичайна інфраструктура, і ставитися до неї слід так само.
Один названий власник числа
Хтось має мати змогу заблокувати реліз за якістю. У LLM-фічі немає природного власника: промпт, пошук і рахунок зазвичай належать трьом різним людям.
Предметний експерт має бути в цьому циклі — і зазвичай його там немає. Чи правильне юридичне резюме, чи безпечна медична інструкція, чи відповідає підтримка політиці — жодне з цих питань не вирішує команда, що збудувала фічу, а рубрика без такого експерта закодовує здогадку інженерів про предметну область. Плануйте час експерта явно й рано, а його оцінки вважайте еталоном, за яким калібрують кожен автоматичний оцінювач.
Де в пайплайні місце кожної перевірки
Оцінювані перевірки коштують грошей і тривають хвилини, тож не можуть запускатися на кожен коміт, як юніт-тести. Це обмеження породжує природні рівні, і записати їх — значить спинити два збої: набір, надто дорогий, щоб його тихо не вимкнули, і процес релізу, де якість не перевіряє ніщо.
| Момент | Що запускається | Чому саме там |
|---|---|---|
| Кожен коміт | Детерміновані перевірки на записаних відповідях: схема, парсинг, маршрутизація, шляхи помилок. | Безкоштовно, миттєво — і покриває той збій, що спричиняє більшість інцидентів. |
| Зміна промпту, моделі чи пошуку | Повний оцінюваний набір, порівняний покейсно із записаною базовою лінією. | Ці три і є артефактом розгортання. Зміна будь-чого з них — це реліз, хай що каже тікет. |
| Щоночі | Той самий набір проти живих провайдерів плюс набір безпеки й відмов. | Ловить дрейф, якого ви не спричиняли: зміну провайдера, оновлення модерації, повільніший ендпоінт. |
| Перед релізом | Захищений набір — кейси, які ламати не можна, — плюс людський розбір вибірки. | Останній момент, коли на справжній вивід дивиться людина перед клієнтом. |
| У продакшні | Онлайн-перевірки на справжньому трафіку: збої схеми, частка відмов, затримка, вартість виклику, частка «не сподобалось». | Єдине місце, де існує справжній розподіл вводів. Ваш набір оцінок — завжди вибірка минулого кварталу. |
Збої, які варто тестувати навмисно
Деякі збої властиві саме цьому класу продуктів, і жодного з них не знайти тестуванням щасливого шляху. Кожен заслуговує на невеликий постійний набір кейсів.
- Інструкції, що приходять усередині контенту, який читає модель. Документ, лист чи вебсторінка можуть містити текст, спрямований на вашу систему, — і якщо знайдений контент має ту саму владу, що й ваш промпт, це спрацює. Тестуйте на ворожих документах навмисно.
- Впевнена хибна відповідь. Ставте питання, відповідей на які в джерелі немає взагалі: правильна поведінка — сказати про це, а поведінка за замовчуванням часто — видати щось правдоподібне.
- Версія моделі, що змінилася під вами. Аліаси провайдерів рухаються: якщо ваша прив’язка — аліас, ваша система оновила себе в продакшні без диффу, без рев’ю і без шляху відкату.
- Довгі входи. Поведінка на межі контекстного вікна відрізняється від поведінки в його середині, а обрізання зазвичай прибирає інструкцію, а не шум.
- Мови й формати, яких не було на демо. Продукт, протестований лише англійською, зустріне свою першу українську адресу, першу таблицю в PDF і перший емодзі в день запуску.
Антипатерни, які варто назвати
- Оголосити фічу нетестованою й випускати за демо: так кожен клієнт стає безоплатним тестувальником без каналу звітності.
- Перевіряти точні рядки: виходить набір, що падає на кожному запуску з причин, не повʼязаних з якістю.
- Судити про зміну за одним запуском одного промпту, де самий лише семплінг дає будь-який із висновків.
- Будувати платформу оцінювання до того, як є фіча й жменя справжніх збоїв, які туди можна покласти.
- Лишити вартість і затримку поза набором тестів: першим це помітить той, хто відкриє рахунок.
Коли це застосовувати
Застосовуйте, коли
- Будь-яка фіча, де вивід моделі досягає користувача, зовнішньої системи чи рішення з наслідками.
- Починайте з детермінованого шару — схема, інструменти, цитати, безпека, бюджет — до будь-якого оцінювання.
- Із записаною рубрикою, узгодженою з предметним експертом, — інакше кожен розбір є суперечкою про смак.
- З онлайн-перевірками в продакшні: лише там існує справжній розподіл вводів.
Уникайте, коли
- Перевірок точних рядків на згенерованому тексті: вони падають постійно з причин, не повʼязаних з якістю.
- Висновків з одного запуску, де самого лише семплінгу досить, щоб підперти будь-яку відповідь.
- Оцінки моделлю там, де перевірка схеми, перерахунок чи пошук вирішили б питання точно.
- Ставлення до всієї фічі як до непізнаваної: так ви віддаєте звичайне тестування ПЗ, що ловить більшість інцидентів.
Було корисно?
Поділіться з тим, хто працює над тією ж задачею.