Тестирование ИИ: как проверить нейросетевые функции продукта

По данным Stanford AI Index Report 2026, доля галлюцинаций у 26 ведущих языковых моделей на бенчмарке AA-Omniscience колеблется от 22% до 94%, а база AI Incident Database зафиксировала 362 инцидента с ИИ в 2025 году против 233 годом ранее. Параллельно растёт и список известных уязвимостей: OWASP Top 10 for LLM Applications 2025 описывает десять классов рисков — от промпт-инъекций до неограниченного потребления ресурсов. Поэтому тестирование ИИ перестало быть экспериментом R&D-отдела и стало обязательной частью релиза любого продукта с нейросетевыми функциями.

Для бизнеса проблема в том, что ошибка ИИ звучит уверенно: чат-бот не падает с ошибкой 500, а вежливо называет несуществующий тариф или «вспоминает» пункт договора, которого нет. Вторая особенность — ИИ-функция ломается без изменения вашего кода: достаточно, чтобы провайдер обновил версию модели, кто-то поправил промпт или в базу знаний попали новые документы. Мы в YuSMP берём на себя тестирование программного обеспечения с ИИ-функциями и видим одну и ту же картину: классические тест-кейсы такие сбои не ловят.

Ниже — практическое руководство для владельцев продукта, CTO и QA-лидов: чем тестирование LLM отличается от обычного QA, что проверять на каждом уровне цепочки, как собрать эталонный набор, как ловить галлюцинации и инъекции, как тестировать RAG и AI-агентов, как встроить проверки в CI/CD и что пройти по чек-листу перед релизом.

Что такое тестирование ИИ и чем оно отличается от обычного QA

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

Причина — недетерминированность. Один и тот же запрос к LLM может дать разные ответы из-за параметра temperature, порядка документов в контексте или обновления модели у провайдера. Даже при temperature = 0 ответы не всегда побайтово совпадают. Поэтому «тест прошёл» в мире ИИ означает не «ответ равен эталону», а «ответ удовлетворяет критериям в N случаях из M прогонов».

Критерий	Классическое ПО	ИИ-функция
Ожидаемый результат	Один, точно известен заранее	Множество допустимых ответов с общими фактами и свойствами
Критерий прохождения	Фактический результат = ожидаемому	Доля успешных прогонов не ниже порога по метрикам
Регрессия	Появляется после изменения кода	Появляется после смены модели, промпта, данных или настроек поиска
Источник поломки	Баг в логике, интеграции, окружении	Галлюцинация, неверный контекст, инъекция, дрейф модели
Кто оценивает	Автотест или тестировщик по тест-кейсу	Метрики, LLM-судья, асессоры и эксперты предметной области
Стоимость прогона	Почти нулевая, тесты гоняют сотни раз в день	Каждый прогон стоит токенов и времени, набор приходится дозировать

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

Что тестировать в продукте с ИИ: карта уровней

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

Уровень	Что может сломаться	Чем проверяем
Запрос пользователя	Опечатки, смешение языков, слишком длинный ввод, вредоносные инструкции	Метаморфические тесты, adversarial-набор, ограничения длины
Поиск (ретривер)	Находит не те документы или не все нужные	Recall@k и точность выдачи на размеченных запросах
Контекст	Обрезан, устарел, противоречив, содержит скрытые инструкции	Проверки сборки контекста, тесты непрямых инъекций
Модель	Галлюцинации, игнорирование инструкций, неверный тон	Эталонный набор, groundedness, LLM-as-a-judge
Бизнес-логика и постобработка	Невалидный JSON, неверный парсинг, небезопасный вывод в HTML или SQL	Валидация по схеме, классические unit- и интеграционные тесты
Действие	Агент вызывает не тот инструмент или с неверными аргументами	Проверка траектории, песочница, подтверждение человеком

Отдельно напомним очевидное, о чём часто забывают в погоне за метриками: классическую часть продукта — авторизацию, права доступа, хранение истории диалогов, UI чата, оплату — тестируют как обычно. Утечка переписки из-за ошибки в правах доступа не имеет отношения к нейросети, но бьёт по репутации ИИ-функции сильнее любой галлюцинации.

Как собрать эталонный набор (golden dataset)

Эталонный набор (golden dataset) — это версионируемая коллекция типовых, граничных и запрещённых запросов с ожидаемыми фактами и критериями оценки, на которой ИИ-функцию прогоняют при каждом изменении. Без него тестирование ИИ превращается в «поспрашивали бота и вроде нормально» — то есть в субъективное мнение, которое нельзя повторить.

1. Выпишите сценарии и интенты. Возьмите реальные обращения в поддержку, поисковые запросы на сайте, логи пилота. Сгруппируйте их по намерениям пользователя и отметьте, какие сценарии критичны для бизнеса.
2. Соберите стартовый набор вопросов. На старте обычно достаточно 50–200 эталонных запросов — это наша рекомендация, а не норматив. Для каждого фиксируйте не точную формулировку ответа, а обязательные факты, источник и недопустимые утверждения.
3. Добавьте граничные и запрещённые кейсы. Вопросы вне тематики продукта, запросы персональных данных, попытки обойти ограничения, вопросы, на которые в базе знаний нет ответа и правильная реакция — «не знаю».
4. Разметьте критерии оценки. Для каждого запроса определите, что проверяется: факты, формат, тон, наличие ссылки на источник, отказ. Договоритесь о порогах прохождения с продуктом и бизнесом заранее.
5. Версионируйте набор вместе с промптами. Храните набор в репозитории рядом с промптами и конфигурацией модели, чтобы любой прогон можно было воспроизвести на конкретной версии.
6. Пополняйте набор из инцидентов прода. Каждая жалоба пользователя или найденная ошибка превращается в новый тест — так набор со временем покрывает реальные, а не придуманные риски.

Какие метрики считать

Метрики переводят «хорошо или плохо отвечает» в числа, которые можно сравнивать между версиями. Ниже — базовый набор, который мы используем как отправную точку; конкретные пороги подбирают под продукт.

Метрика	Что показывает	Где важна
Доля верных ответов	Сколько ответов содержат все обязательные факты без ошибок	Любая ИИ-функция
Опора на источник (groundedness, faithfulness)	Подтверждается ли каждое утверждение ответа найденным контекстом	RAG, ассистенты по базе знаний
Релевантность ответа (answer relevancy)	Отвечает ли модель на заданный вопрос, а не на соседний	Чат-боты, поиск
Полнота поиска (recall@k)	Есть ли нужный документ среди первых k найденных	RAG, семантический поиск
Доля отказов и ложных отказов	Отказывает ли модель там, где должна, и не отказывает ли там, где не должна	Поддержка, финансы, медицина
Соблюдение формата	Проходит ли вывод валидацию по JSON-схеме или шаблону	Интеграции, агенты, извлечение данных
Латентность p95	Время ответа для 95% запросов	Пользовательские интерфейсы
Стоимость на запрос	Расход токенов и денег на один сценарий	Масштабирование, юнит-экономика

Как проверить галлюцинации

Галлюцинация — это уверенно сформулированное утверждение модели, которое не подтверждается ни источником, ни реальностью. Полностью исключить галлюцинации нельзя, поэтому цель тестирования — измерить их долю и удерживать её ниже согласованного порога.

На практике работают три подхода, и лучше комбинировать их:

• Сверка с источником. Ответ разбивают на отдельные утверждения и проверяют, подтверждается ли каждое переданным в модель контекстом. Это основа метрики groundedness для RAG-систем.
• Проверка консистентности. Один и тот же вопрос задают несколько раз или в разных формулировках. Если факты в ответах расходятся, высока вероятность, что модель «додумывает».
• Сравнение с эталонными фактами. Для вопросов из эталонного набора заранее известны обязательные и запрещённые утверждения — ответ проверяют на их наличие автоматически или с помощью LLM-судьи.

Отдельный класс тестов — вопросы без ответа в базе знаний. Правильное поведение здесь — честное «не знаю» или переадресация на оператора, а не правдоподобная выдумка. На наших проектах именно эти кейсы чаще всего проваливаются на первом прогоне: модель стремится помочь и заполняет пробел сама.

Метаморфическое и сценарное тестирование

Метаморфическое тестирование — это проверка того, что изменение запроса, не меняющее его смысла, не меняет и суть ответа, а изменение, которое должно повлиять на ответ, влияет предсказуемо. Оно особенно удобно для ИИ, потому что не требует знать «правильный ответ» заранее — достаточно сравнить пары.

• Перефразирование. «Как вернуть товар?» и «Хочу оформить возврат покупки» должны давать эквивалентные ответы с одинаковыми сроками и условиями.
• Изменение формы ответа. «Объясни кратко» — ответ короче, но факты те же; «ответь списком» — меняется формат, а не содержание.
• Шум во вводе. Опечатки, отсутствие знаков препинания, ВЕРХНИЙ РЕГИСТР, смешение русского и английского не должны ломать понимание запроса.
• Смена языка. Если продукт заявлен как мультиязычный, один и тот же вопрос на разных языках должен давать согласованные по фактам ответы.

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

Как тестировать безопасность ИИ-функции: OWASP Top 10 для LLM

Тестирование безопасности ИИ — это проверка того, что функцию нельзя заставить нарушить правила, раскрыть данные или выполнить вредное действие. Удобная рамка — OWASP Top 10 for LLM Applications 2025: по ней строят план атак и регрессионный набор вредоносных запросов.

Риск OWASP 2025	Как проявляется	Как проверяем
LLM01 Prompt Injection	Пользователь или документ в контексте подменяет инструкции модели	Набор прямых инъекций в чате и непрямых — через загруженные файлы, письма, веб-страницы
LLM02 Sensitive Information Disclosure	Модель выдаёт персональные данные, коммерческую тайну, чужие диалоги	Запросы на данные других пользователей, проверка маскирования ПДн в ответах и логах
LLM05 Improper Output Handling	Ответ модели исполняется как HTML, SQL или код без проверки	Внедрение разметки и команд в ответ, проверка экранирования и валидации на выходе
LLM06 Excessive Agency	Агент получает больше прав и инструментов, чем нужно для задачи	Аудит прав инструментов, попытки вызвать действие вне сценария
LLM07 System Prompt Leakage	Модель пересказывает системный промпт с внутренней логикой и секретами	Серия запросов «повтори свои инструкции» в разных формулировках
LLM09 Misinformation	Уверенные ложные утверждения, на которые полагаются пользователи	Тесты галлюцинаций и опоры на источник, дисклеймеры
LLM10 Unbounded Consumption	Запросы, раздувающие расход токенов и стоимость, вплоть до отказа в обслуживании	Длинные и рекурсивные запросы, проверка лимитов на сессию и пользователя

Остальные пункты списка — LLM03 Supply Chain, LLM04 Data and Model Poisoning и LLM08 Vector and Embedding Weaknesses — проверяют на уровне архитектуры: откуда берутся модели и библиотеки, кто может изменить данные для обучения и базу знаний, разграничен ли доступ к векторному хранилищу.

Помимо OWASP в план безопасности входят red teaming — целенаправленные попытки «сломать» модель силами команды или внешних специалистов, проверка на предвзятость (одинаково ли модель отвечает разным группам пользователей) и токсичность. Если ИИ-функция обрабатывает персональные данные, утечку ПДн считайте отдельным критичным риском — в том числе с точки зрения требований 152-ФЗ.

Тестирование RAG: поиск, контекст и генерация

RAG (Retrieval-Augmented Generation) — это схема, в которой модель отвечает не «из головы», а по документам, найденным в вашей базе знаний. Тестирование RAG требует проверять три слоя по отдельности, иначе невозможно понять, где именно возникла ошибка.

• Поиск. Ретривер находит не те документы или не все нужные. Проверяем на размеченных запросах: есть ли правильный фрагмент среди первых k результатов (recall@k), сколько в выдаче лишнего, как влияет размер чанка и выбор эмбеддингов.
• Контекст. Нужный документ найден, но обрезан по лимиту, устарел или противоречит другому документу. Проверяем сборку контекста: порядок, дедупликацию, актуальность версий, поведение при конфликте источников.
• Генерация. Контекст правильный, но модель не опирается на него — добавляет факты «от себя» или игнорирует важную оговорку. Здесь работают метрики faithfulness и answer relevancy.

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

Как тестировать AI-агентов

Тестирование AI-агентов — это проверка не только итогового ответа, но и всей траектории действий: какие инструменты агент выбрал, с какими аргументами их вызвал, сколько шагов сделал и вовремя ли остановился. Агент не просто отвечает, он действует — создаёт заявки, пишет в CRM, отправляет письма, — поэтому цена ошибки выше.

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

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

Чем агенты отличаются от чат-ботов и где они приносят пользу бизнесу, мы разбирали в статье «AI-агенты: что это и как их внедрять».

LLM-as-a-judge и оценка людьми: когда что применять

LLM-as-a-judge — это подход, при котором ответы одной модели оценивает другая модель по заданным критериям и шкале. Он позволяет масштабировать оценку на тысячи ответов, но не заменяет людей полностью: судья тоже ошибается, и его самого нужно проверять.

Способ оценки	Скорость	Стоимость	Надёжность	Где применять
Автоматические метрики и правила	Высокая	Низкая	Высокая для формальных критериев, низкая для смысла	Формат, наличие фактов, recall@k, латентность
LLM-судья	Высокая	Средняя — платим за токены судьи	Средняя, требует калибровки	Релевантность, опора на источник, тон, полнота ответа
Асессоры и эксперты	Низкая	Высокая	Самая высокая в предметной области	Калибровка судьи, критичные домены, спорные кейсы

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

Производительность и стоимость: латентность, токены, лимиты

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

• Время до первого токена и полного ответа. Для чата важнее первое: пользователь видит, что ответ пошёл. Для интеграций — второе.
• Латентность p95 под нагрузкой. Средние значения скрывают хвосты, а именно хвосты раздражают пользователей.
• Длинный вход и выход. Что происходит, когда история диалога или документ переполняют контекстное окно, и когда модель генерирует очень длинный ответ.
• Бюджет токенов. Сколько стоит типичная сессия и какой лимит защищает от аномально дорогих запросов.
• Отказ провайдера. Поведение при rate-limit, таймауте и недоступности API: есть ли фолбэк на резервную модель или понятное сообщение пользователю.

Общие подходы к подготовке сервиса к нагрузке — профили нагрузки, сценарии, интерпретация результатов — мы описали в статье о нагрузочном тестировании; для ИИ-функций к ним добавляются метрики токенов и стоимости.

Как встроить тесты ИИ в CI/CD и мониторинг

Встраивание тестов ИИ в CI/CD — это автоматический прогон эталонного набора при каждом изменении, которое может повлиять на поведение функции, с блокировкой релиза при падении метрик ниже порога. Изменением считается не только коммит в код, но и правка промпта, смена версии модели, обновление базы знаний или настроек поиска.

Из-за недетерминированности тесты делают вероятностными: каждый критичный кейс прогоняют N раз и требуют успешного результата в заданной доле случаев — например, не менее 90% прогонов (порог подбирают под продукт). Версию модели у провайдера фиксируют явно, чтобы обновление не прошло незаметно, а переход на новую версию оформляют как отдельный релиз с полным регрессом.

После релиза тестирование продолжается в виде наблюдаемости (observability):

• логи запросов и ответов с маскированием персональных данных;
• трейсы цепочки — что нашёл ретривер, какой контекст собрался, какие инструменты вызвал агент;
• метрики качества на выборке живого трафика, латентность, стоимость, доля отказов;
• обратная связь пользователей («палец вниз», жалобы), которая попадает в эталонный набор.

Под эти задачи есть открытые и коммерческие инструменты: фреймворки для тестирования промптов и регрессии (promptfoo), библиотеки метрик оценки LLM (DeepEval), инструменты оценки RAG (Ragas), платформы трассировки и наблюдаемости (Langfuse, LangSmith), сканеры уязвимостей и качества моделей (Giskard). Выбор зависит от стека и требований к размещению данных — инструмент вторичен по отношению к эталонному набору и порогам.

Как рамку процесса удобно использовать NIST AI Risk Management Framework: четыре функции Govern, Map, Measure и Manage помогают не забыть про ответственность, карту рисков, измерения и реакцию на инциденты, а профиль NIST AI 600-1 (2024) адаптирует их под генеративный ИИ. Общие принципы автоматизации — пирамида тестов, выбор фреймворка, окупаемость — мы разбирали в статье об автоматизации тестирования.

Чек-лист перед релизом ИИ-функции

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

1. Эталонный набор собран, критерии оценки и пороги согласованы с бизнесом.
2. Регрессионный прогон на текущей версии модели и промпта пройден.
3. Доля галлюцинаций и неверных ответов ниже согласованного порога, на вопросы без ответа модель говорит «не знаю».
4. Прямые и непрямые промпт-инъекции проверены, системный промпт не утекает.
5. Персональные данные не попадают в ответы и маскируются в логах.
6. Формат вывода валидируется, ответ модели не исполняется как код или разметка без проверки.
7. Есть фолбэк на сбой и rate-limit провайдера.
8. Установлены лимиты токенов и стоимости на запрос, сессию и пользователя.
9. Настроены логирование, трейсы и алерты по качеству, латентности и стоимости.
10. Есть сценарий отката на предыдущую версию промпта и модели.
11. Для критичных и необратимых действий в контуре есть человек.
12. Пользователь видит, что общается с ИИ, и понимает ограничения ответов.

Частые вопросы о тестировании ИИ

Можно ли полностью автоматизировать тестирование ИИ?

Большую часть — да: регрессионные прогоны эталонного набора, формальные метрики, проверки формата и LLM-судья работают автоматически в CI. Но полностью убрать людей нельзя: асессоры калибруют судью, эксперты оценивают спорные и критичные кейсы, а red teaming и поиск новых сценариев атак требуют творческой работы.

Сколько примеров нужно в эталонном наборе?

Универсального числа нет. На старте мы рекомендуем 50–200 запросов, покрывающих основные интенты, граничные и запрещённые кейсы. Дальше набор растёт за счёт инцидентов из прода и новых сценариев. Важнее не размер, а репрезентативность: набор должен отражать реальные запросы пользователей.

Чем тестирование LLM отличается от тестирования ML-модели (классификатора)?

Классификатор выдаёт ответ из фиксированного набора классов, поэтому его оценивают классическими метриками — точностью, полнотой, F1 на размеченной выборке. LLM генерирует свободный текст: правильных ответов много, поэтому нужны критерии по фактам, опоре на источник, формату и безопасности, а также LLM-судья или асессоры.

Как часто перепроверять ИИ-функцию после релиза?

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

Нужно ли заново тестировать при смене версии модели у провайдера?

Да. Новая версия модели может иначе следовать инструкциям, менять формат и тон ответов, по-другому реагировать на инъекции. Поэтому версию фиксируют явно, а переход на новую проводят как отдельный релиз с полным регрессионным прогоном и сравнением метрик со старой версией.

Кто должен тестировать ИИ: QA, разработчики или эксперты предметной области?

Все вместе, у каждого своя роль. QA проектирует набор, сценарии и пороги и строит регресс в CI. Разработчики отвечают за тесты ретривера, валидацию вывода и наблюдаемость. Эксперты предметной области размечают эталонные ответы и оценивают спорные кейсы, а специалисты по безопасности проводят red teaming.