Тестирование ИИ: что и когда тестировать в LLM-приложении и насколько это востребовано

Тестирование ИИ-приложения — это проверка качества системы, в которой ответ генерирует языковая модель: чат-бота, RAG-ассистента или агента. Здесь нет единственно верного ожидаемого значения, а один и тот же вход может дать разные ответы, поэтому проверяют не строку, а свойства ответа: фактичность, релевантность, безопасность, формат и стабильность. Проверять нужно каждый слой системы отдельно, а не только итоговый ответ.

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

Самый крупный свежий источник по индустрии — World Quality Report 2025-26 от Capgemini. Он описывает применение генеративного ИИ в инженерии качества, но его цифры хорошо показывают, с чем сталкиваются команды, когда ИИ выходит из режима эксперимента [1].

Осторожно с выводами: отчёт не измеряет напрямую число вакансий на «тестирование LLM». Но три барьера из четырёх названных (приватность, интеграция, галлюцинации) — это ровно то, что проверяет инженер по качеству ИИ-систем, а четвёртый — нехватку компетенций — признаёт половина опрошенных. Это сильный аргумент, что спрос на такие навыки есть и растёт вместе с числом ИИ-продуктов. Цифры по российскому рынку и конкретным вакансиям лучше проверять самостоятельно: посмотрите на выдачу hh.ru и Хабр Карьеры по запросам «тестирование LLM», «AI QA», «LLM evals» и сравните с прошлым кварталом.

Последняя строка важнее остальных: качество ответа меняется не только при правке кода. Достаточно обновить документы в базе знаний, поправить одну фразу в системном промпте или получить новую версию модели от провайдера, и поведение бота изменится при неизменном коде.

Чтобы не тестировать «ответ целиком» и не гадать, где проблема, разделите систему на слои. На каждом слое свой тип дефектов и свои проверки.

Увеличить

Типичная ситуация: пользователь пишет в поддержку «бот ответил не по делу». Вы не знаете, что именно сломалось: поиск не нашёл нужный документ, модель не воспользовалась найденным, промпт стал двусмысленным или обновилась модель. Чинить наугад дорого. Поможет одна и та же последовательность:

• ▸Воспроизведите диалог по trace id или логам: точный вопрос, история, версии промпта и модели, найденные фрагменты.
• ▸Определите слой. Посмотрите, какие фрагменты принёс поиск: нужного среди них нет — проблема в поиске; нужный есть, а ответ неверный — в генерации.
• ▸Уточните экспериментом с идеальным контекстом: подставьте нужный фрагмент вручную. Если ответ стал хорошим, виноват поиск. Разбор с блок-схемой — в статье про тестирование RAG.
• ▸Проверьте, не изменилось ли что-то между «было хорошо» и «стало плохо»: версия промпта, модель, индекс, параметры.
• ▸Превратите диалог в кейс: положите его в корзину регрессий golden set, чтобы автоматически ловить повторение.

• День 1–2: соберите 30–50 реальных вопросов из логов и разложите по корзинам
• День 3: напишите рубрику для одного критерия (например, фактичность) и запустите LLM-судью
• День 4: отдельно проверьте поиск на 20 вопросах с известными нужными документами
• День 5: включите прогон в CI с порогами по корзинам и заведите привычку добавлять в набор каждый баг

Чем тестирование ИИ отличается от использования ИИ в тестировании?

Использование ИИ в тестировании — это когда инженер применяет модель как инструмент: для генерации тестов или разбора логов. Тестирование ИИ — это проверка качества продукта, в котором работает модель: чат-бота, RAG-ассистента, агента. Навыки пересекаются, но задачи разные.

Что нужно тестировать в LLM-приложении в первую очередь?

Начните с фактичности ответов (нет ли выдуманных фактов относительно вашей базы знаний), устойчивости к prompt injection и корректного отказа на вопросы вне области. Это самые дорогие ошибки. Затем добавляйте проверку поиска, формата ответа и многоходовых диалогов.

Когда запускать тесты LLM-приложения?

На каждый pull request запускайте быстрый smoke-набор, перед релизом полный, а при смене модели, промпта или базы знаний обязательно полную регрессию: эти изменения меняют поведение бота при неизменном коде. В проде оценивайте выборку реальных диалогов.

Как понять, что виновата база знаний, а не модель?

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