Что перестаёт работать в тестировании, когда приходит LLM

13 лет я тестировала софт, где у бага был адрес: шаг 1, шаг 2, ожидаемый результат, фактический. Нажал — получил. Нажал ещё раз — получил то же самое.

А пару лет назад я начала тестировать продукты на LLM. И почти всё, на чём держится классический QA, перестало работать. Не «усложнилось» — перестало работать как метод.

Ниже — где именно ломается, по пунктам. Если вы тестировщик и заходите в AI, это ваша новая реальность.

Нет одного «ожидаемого результата»

В классике эталон один: 2 + 2 = 4. В LLM правильных ответов — десятки. «Столица Франции — Париж», «Париж», «Это Париж, крупнейший город страны» — все верны. А проверка expected == actual тихо падает на каждом.

Что меняется: мы тестируем не совпадение со строкой, а соответствие критериям — корректность, релевантность, полнота, тон. Эталон превращается из строки в рубрику.

Один и тот же тест даёт разный результат

Запустили кейс — прошёл. Запустили ещё раз, ничего не меняя, — упал. Это не флапающий тест, который надо «починить». Это встроенное свойство системы: та же модель на тот же запрос отвечает по-разному.

Особенно ярко это вылезло на голосовом ответчике. Один и тот же аудиозапрос разные модели распознавания слышали по-разному: Deepgram стабильнее, watsonx сыпался чаще. Но даже на одной модели результат плавал — из 10 прогонов одного и того же запроса 4 распознавались неверно, и дальше по цепочке менялся весь ответ. В классике я бы завела баг «не воспроизводится» и закрыла. Здесь 4 из 10 — это не шум, это и есть дефект: пришлось мерить частоту, а не смотреть на единичный прогон.

Что меняется: «воспроизводимость бага» больше не бинарна. Мы думаем в терминах частоты: дефект на 2 из 100 прогонов — это дефект или шум? И как его репортить, если он не воспроизводится по щелчку?

«Зелёный прогон» больше ничего не гарантирует

Прошли все тесты — отпустили в прод. В LLM так нельзя: ваш набор кейсов покрывает доли процента того, что напишут реальные пользователи. Модель уверенно выдаст правильную форму и выдуманный факт внутри неё — и ни один assert этого не поймает.

Нагляднее всего — на агенте, который заполняет формы и ходит по сайту за пользователя. Один день всё работало, на следующий тот же сценарий поехал — без единого изменения с нашей стороны. Из реального отчёта пользователя: агент перепутал поля формы (стоишь в поле email, а он просит юридическое название компании), заполнял только обязательные поля вместо всех и писал в чат не то, что произносил голосом. Зелёный прогон накануне не предсказал ничего из этого — потому что стенд стабилен, а живая система между двумя днями ведёт себя по-разному.

Что меняется: качество смещается из «прошёл/не прошёл на фиксе» в непрерывный мониторинг в проде. Тестирование не заканчивается на релизе — оно там только начинается.

Баг может прийти оттуда, где вы кода не меняли

Поменяли одно слово в промпте — поехало поведение в трёх несвязанных сценариях. Обновился провайдер модели под капотом — у вас регрессия, а в вашем коде ни одной строчки диффа.

Что меняется: появляется новый класс тестов — regression-тесты на промпты и на саму модель, а не только на код.

Появились дефекты, которых раньше не существовало

В классическом ПО не было категории «система уверенно врёт». А в LLM это топовый дефект: галлюцинации, утечка system prompt, prompt injection, токсичность, утечка персональных данных. Их нельзя «найти, кликая по кнопкам» — их нужно целенаправленно провоцировать (это называется red teaming).

Что меняется: в тест-стратегию добавляется безопасность и adversarial-тестирование как отдельная дисциплина.

«Покрытие» считается иначе

Раньше: ветки, строки, граничные значения. В LLM пространство входов — это весь естественный язык. 100% покрытия не существует в принципе.

Что меняется: мы переходим к risk-based мышлению — не «покрыть всё», а «покрыть то, что дороже всего сломать», и к датасетам, которые отражают реальное распределение запросов.

Что со всем этим делать

Классический QA не выбрасывается — наоборот. Тест-дизайн, классы эквивалентности, негативные сценарии, risk-based подход, умение формализовать ожидания и внятно репортить — всё это ровно то, что нужно для LLM. Просто переносится в недетерминированный мир и достраивается новыми инструментами: оценка качества ответа, LLM-as-a-judge, evals в CI/CD, мониторинг в проде.

Хорошая новость: тестировщик с инженерным мышлением входит в AI QA быстрее, чем кажется. Плохая — большинство материалов учат либо «AI поможет тебе тестировать» (наоборот), либо «вот запусти эту библиотеку». А как именно перенести QA-мышление на LLM — почти никто.

Я собрала в шпаргалку, что обычно проверяю в LLM-фиче. Прикладываю картинкой ниже — забирайте, пользуйтесь на проекте, перешлите коллеге, если пригодится.

Вот про это «почти никто» я и собираю курс — тот, которого мне самой не хватало, когда я входила в LLM-тестирование. Не «запусти эту библиотеку» и не «AI поможет тебе тестировать», а как взять инженерное QA-мышление, которое у тебя уже есть, и достроить его под недетерминизм: что считать дефектом, как поймать его в системе, которая каждый раз отвечает по-разному, как собрать тест-стратегию и встроить процесс в команду. На русском, для практиков.

— Что у вас сейчас самое непонятное в тестировании LLM?

— Сталкивались с дефектами из списка выше — какой бесил больше всего?

Тот самый курс, о котором выше, — уже опубликован, бесплатно на Stepik: «QA для LLM: тестирование нейросетей и AI-агентов». По шагам: что считать качеством ответа, тест-дизайн для недетерминированной системы, LLM-as-a-judge, RAG и агенты, безопасность и red teaming, тест-стратегия и мониторинг в проде. В конце — сквозной проект для портфолио.

🎓 Курс (бесплатно): https://stepik.org/course/291671/promo

💻 Репозиторий с примерами кода (JavaScript + Playwright): https://github.com/VeronLezh/llm-testing-playwright

Источник: habr.com