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

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

Ніхто не відкриває сторінку про тестування LLM-продуктів заради визначення. Її відкривають, бо фіча на носі, а звичний тест-план не пасує: вивід змінюється між запусками, тож що взагалі перевіряти? Відповідь менш екзотична, ніж питання. Нижче — двадцять збоїв, з якими, найімовірніше, вийде асистент замовлень в інтернет-магазині. Він відповідає на «де моє замовлення», пояснює правила повернення з довідкового центру й може розпочати повернення. Кожен рядок називає, що отримує клієнт, яка перевірка це ловить, якого вона роду і коли запускається. Рядки 1–4 — інтеграція, 5–10 — контракт виводу, 11–15 — зміст, 16–19 — супротивник, а 20 — дрейф. Наступні розділи посилаються на них за номерами.

Що змінюється насправді: зник оракул

У дослідженнях тестування є назва для того, що зламалося. Тестовий оракул — це те, що вирішує, чи правильний вивід; зазвичай це очікуване значення, записане поруч із вводом. 2015 року Ерл Барр, Марк Гарман і колеги зробили огляд проблеми оракула: як відрізнити правильну поведінку від хибної, коли очікуваного значення немає або його надто дорого записати. Вона є в наукових симуляціях, є в моделях машинного навчання, а LLM-фіча має її в найчистішому вигляді. Очікуваний вивід на «де моє замовлення?» — будь-яке з тисячі прийнятних речень.

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

Поширений обхід — поставити температуру на нуль і все одно порівнювати рядок. Нульова температура означає, що модель завжди бере найімовірніший наступний токен, тож вивід мав би повторюватися. У вересні 2025 року Горас Гі та колеги з Thinking Machines Lab показали, чому на звичайному сервері інференсу цього не стається. Вони надіслали один промпт тисячу разів за нульової температури й отримали вісімдесят різних продовжень. Перші 102 токени збігалися в усіх тисячі; на 103-му 992 продовжили «Queens, New York», а вісім — «New York City».

Причиною була не випадковість у моделі, а навантаження на сервер. Те, скільки запитів інших користувачів обробляли разом в одному пакеті, змінювало порядок додавань із рухомою комою, а з ним — останні знаки, що вирішують майже нічию між двома токенами. Їхнє виправлення, ядра, інваріантні до розміру пакета, зробило всі тисячу продовжень однаковими — ціною швидкості. Спільний APIAPIApplication Programming Interface — контракт між програмамиПравила, за якими одна програма звертається до іншої: які запити можна надіслати, у якому вигляді й що прийде у відповідь. Для того, хто звертається, це контракт — усе, що за ним, лишається чорною скринькою, і саме тому другий бік можна переписати, не зламавши вас.Докладніше в статті →Усі терміни не вмикає цього за вас. Тож вважайте модель у хмарі недетермінованою за будь-якої температури й пишіть тести, яким це байдуже.

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

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

Структурований вивід прибрав цілий клас цих збоїв і лишив три. Коли OpenAI запустила його в серпні 2024 року, її власна оцінка на складних схемах виросла з менш ніж 40% у старішої моделі до 100% у суворому режимі. Те саме оголошення перелічує, чого гарантія не покриває. Відмова повертається як відмова, а не за схемою. Відповідь, що дійшла до max_tokens, зупиняється, не завершивши обʼєкт. А значення всередині валідного обʼєкта однаково можуть бути хибними. Ці три обмеження — рядки 1, 3 і 8; тому гарантія схеми не скасовує тестів, а підказує, які саме писати.

Інтеграційні рядки можуть запускатися на кожен коміт, лише якщо нічого не коштують, а нічого не коштують, лише якщо провайдера не викликають. Тож один раз запишіть справжні відповіді — звичайну, відмову, обрізану, виклик інструмента — і відтворюйте їх із файлів під час тестів. Потім напишіть ті відповіді, яких на замовлення не запишеш: тайм-аут, 429, 500, збій інструмента, відповідь зі зламаним JSONJSONJavaScript Object Notation — текстовий формат данихТекстовий формат для передавання даних: пари «ключ — значення», списки, числа й рядки. Він народився в JavaScript, але сьогодні його читає будь-яка мова — і саме тому ним відповідає більшість API, а не чимось потужнішим.Усі терміни. Тепер набір швидкий і детермінований, і він тестує саме той код, що перетворює поведінку провайдера на те, що бачить клієнт.

Немає очікуваної відповіді? Перевіряйте властивість

Рядки 13–15 не мають очікуваного виводу — і все одно їх не оцінюють балом. Вони порівнюють два запуски фічі між собою. Тестування ПЗ робить так десятиліттями всюди, де бракує оракула. Метаморфне тестування, огляд якого 2018 року зробили Цонг Юе Чен і колеги, перевіряє звʼязок між виводами замість самих виводів: поверніть вхідне зображення — і виявлені обʼєкти мають повернутися разом із ним.

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

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

Супротивник: список OWASP 2026 як план тестування

Рядки 15–19 узято зі списку, яким тестувальник може користуватися безпосередньо. OWASPOWASPOpen Worldwide Application Security Project — відкрита спільнота безпеки застосунківНекомерційна фундація, що публікує безкоштовні настанови з безпеки, написані спільнотою, — найвідоміша своїми списками Top 10 найкритичніших ризиків для вебзастосунків, API та LLM-застосунків. Top 10 ранжує категорії ризиків, проти яких проєктують і тестують; це не чеклист, що доводить безпеку системи.Усі терміни опублікував редакцію 2026 року свого Top 10 for LLM Applications 4 серпня 2026 року. Уперше рейтинг — не лише думка: голосування практиків важить три чверті, а решту дають 6 639 класифікованих реальних інцидентів. Передмова формулює позицію, що стоїть за всіма десятьма пунктами: «Перестаньте намагатися збудувати модель, яку неможливо обдурити. Збудуйте систему навколо неї так, щоб, коли модель обдурять — а це станеться, — не зламалося нічого важливого».

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

Три інші пункти — ланцюг постачання (LLM04), отруєння даних і моделі (LLM05) та слабкі місця векторів і ембедингів (LLM09) — живуть переважно в тому, як модель та індекс будують і наповнюють. Їм місце радше в безпековому огляді цього конвеєра, ніж у наборі тестів фічі. Одна практична пастка: список 2026 року пересунув вісім із десяти пунктів. System Prompt Leakage, що 2025 року був LLM07, тепер називається Hidden Context Exposure і має номер LLM08; Improper Output Handling опустився з пʼятого місця на десяте. Тест-план, що посилається на пункти лише за номером, тепер указує на інші пункти, тож пишіть рік поруч із номером — LLM08:2026.

Хто що пише і де запускається кожна перевірка

Тестувальник на звичайній фічі пише кроки й очікувані результати. На LLM-фічі кроки тривіальні — надішли це, прочитай те, — і складність переїжджає у визначення того, якою є добра відповідь. Це визначення є специфікацією. Його справді важко написати, і це найцінніший артефакт на проєкті, бо кожен оцінюваний рядок і кожен оцінювач добрі рівно настільки, наскільки добре воно.

• QA володіє визначенням «добре»

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

• QA володіє корпусом збоїв

  Кожна скарга, інцидент і дивна відповідь стають кейсом. Догляд за ним — саме те, що робить набір кращим у міру користування продуктом.

• Розробка володіє каркасом

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

• Один названий власник числа

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

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

Пʼять релізів — і рядки, що спіймали б кожен

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

Де це вироджується

Чесне обмеження всього на цій сторінці в тому, що набір перевіряє те, що хтось здогадався в нього покласти. Двадцять рядків — це двадцять збоїв, які хтось уявив; тести властивостей потребують, щоб хтось вигадав звʼязок; червона команда знаходить атаки своїх учасників. Тестування не може показати, що інʼєкція неможлива, — саме тому передмова OWASP просить системи, у якій обдурена модель не ламає нічого важливого, і саме тому рядки, що обмежують можливості моделі (7, 16–19), варті більше за будь-яку оцінку.

• Оголосити фічу нетестованою й випускати за демо: так кожен клієнт стає безоплатним тестувальником без каналу звітності.
• Перевіряти точні рядки: виходить набір, що падає на кожному запуску з причин, не повʼязаних з якістю, — і його вимикають.
• Поставити температуру на нуль і назвати вивід детермінованим.
• Почати з оцінюваних рядків, бо вони нові, і так і не дійти до точних, що спричиняють інциденти.
• Набір відтворення, якого не перезаписували від запуску, — зелений проти провайдера, якого вже не існує.
• Вправа червоної команди, проведена один раз: знахідки виправили, але так і не перетворили на кейси.
• Правки промпту й оновлення від постачальника, що оминають набір, бо «нічого не розгортали».
• Пункти OWASP із номером, але без року — після перенумерації 2026 року.
• Лишити вартість і затримку поза набором тестів: першим помітить той, хто відкриє рахунок.

Коли це застосовувати

Пов’язані сторінки

• QAОцінювання AIОцінювання AI — це вимірювання того, чи достатньо добрі виводи моделі, щоб їх випускати: фіксовані кейси, оцінювач для кожного й числа з їхньою невизначеністю. Сторінка починається з шістнадцяти речей, які команда захоче оцінювати, — найдешевшого оцінювача, що вирішує кожну, і того, що його обманює; далі — аналіз помилок, складання набору, драбина оцінювачів, модель-суддя й те, як їй довіряти, читання чисел і чотири опубліковані вимірювання, що ввели в оману.
• QAРегресія промптівРегресійне тестування промптів перевіряє, кейс за кейсом, чи не зламала зміна промпту або моделі щось, що працювало до цієї зміни. Сторінка починається з однієї правки промпту, розібраної від початку до кінця, — асистент замовлень, v7 → v8, — далі негативні перескоки, що закріплювати, три запуски на кейс і межа шуму, ворота, оновлення моделі й чотири зміни, що пішли не так.
• РозробкаLLMOpsLLMOps — це практика тримати в продакшені фічу на мовній моделі, де той самий ввід не дає надійно того самого виводу. Вона існує тому, що все, що робить програму придатною до релізу — тест, який падає, дифф, що пояснює зміну, відкат, який повертає вчорашній стан, — припускає, що дає. Сторінка починається з чеклиста готовності до прода на двадцять чотири рядки; далі — чим заміняють кожну практику, чому одиниця розгортання складається з чотирьох речей, а не з однієї, оцінювання як набір тестів, що має містити слід, як поводяться вартість і затримка під справжнім трафіком, і пʼять задокументованих інцидентів.