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?
— Сталкивались с дефектами из списка выше — какой бесил больше всего?
ссылка на оригинал статьи https://habr.com/ru/articles/1049482/