Меня зовут Лилия Урмазова, более 20 лет назад я начала работать классическим QA-инженером.
А последние пару лет специализируюсь на тестировании AI-приложений. В настоящее время — Senior Staff AI-QA Engineer/ML Evaluation Engineer в крупной международной IT-компании.
Для тех тестировщиков, кто хочет как минимум быть “в курсе” тестирования AI, я с коллегами подготовила небольшой бесплатный практический курс.
Хорошая новость
Кое-что из того, что касается тестирования AI-приложений, можно мерить классическими, легко рассчитываемыми метриками.
Предположим, ваше AI-приложение в результате работы должно возвращать некий перечень - упорядоченные результаты текстового поиска или какие-то изображения. Для тестирования того, насколько всё это хорошо работает, можно использовать простые статистические метрики.
Пример:
QA-инженер Виктор проверяет поисковую AI-систему, которая должна помочь специалистам находить документы в базе знаний.
Он вводит запрос в AI-поиск и внимательно изучает топ-10 результатов:
Позиция (Ранг) |
Результат (Документ) |
Истинность (Релевантность) |
1 |
Документ X1 |
Нерелевантный (Н) |
2 |
Документ Y2 |
Релевантный (Р) |
3 |
Документ Z3 |
Нерелевантный (Н) |
4 |
Документ W4 |
Нерелевантный (Н) |
5 |
Документ K5 |
Релевантный (Р) |
6 |
Документ L6 |
Нерелевантный (Н) |
7 |
Документ M7 |
Релевантный (Р) |
8 |
Документ N8 |
Нерелевантный (Н) |
9 |
Документ O9 |
Нерелевантный (Н) |
10 |
Документ P10 |
Нерелевантный (Н) |
Посмотрев на результаты, Виктор может рассчитать, например, Точность (Precision).
А именно: сколько действительно релевантных документов среди всех тех, которые система объявила релевантными.
Расчет элементарный:
Система выдала 10 результатов.
Из них 3 релевантных (TP=3), 7 нерелевантных (FP=7).
Precision = 3/(3+7) = 0.30
При этом с заказчиком ранее утвердили, что Precision должен быть не ниже 0.5. То есть из десяти документов не менее 5 должны быть релевантными.
Можно с чистой совестью писать дефект.
Изучить другие аналогичные метрики и потренироваться с ними на практике можно в первой части бесплатного курса Mentorpiece Как тестировать AI-приложения (Non-LLM метрики).
Плохая новость
Классические статистические метрики (Non-LLM метрики) покрывают только небольшую часть AI-задач. Поэтому нужно быть знакомым и с LLM метриками - которые специфичны именно под AI.
И тут всё намного интереснее.
Ведь нам приходится решать задачи типа таких:
QA-аналитик Антон тестирует новый AI-модуль анализа отзывов, интегрированный в крупную платформу электронной коммерции. Основная цель этого модуля — автоматически обрабатывать тысячи неструктурированных пользовательских отзывов о товаре и генерировать структурированное резюме для менеджеров по продукту и потенциальных покупателей.
Антон предоставляет AI-модулю контекст (массив из 1000+ отзывов о конкретном товаре). Модель пытается извлечь ключевые темы ("Срок службы батареи", "Качество сборки") и генерирует результат в строго заданном JSON-формате, указывая точное количество положительных и отрицательных упоминаний по каждой теме.
Проблема №1 - Релевантность
Антон проверяет, выполнила ли модель основную задачу. Задача была не просто «почитать отзывы», а «выделить конкретные проблемы» (батарея, экран, сборка), чтобы менеджер продукта мог их исправить.
Система же выдает Антону: «Покупатели в целом довольны, телефон хороший».
Проблема №2 - Точность
Модель сообщает, что в массиве отзывов есть 120 жалоб. Антон перепроверяет эту информацию, и обнаруживает, что их на самом деле 150. При следующем прогоне модель обнаружила в массиве отзывов уже 200 жалоб. ???
Проблема №3 - Достоверность
В массив отзывов загружена информация о конкретной партии телефонов. Модель пишет: «У этого телефона порт USB-C, который поддерживает быструю зарядку 65 Вт». Но Антон помнит, что в загруженных отзывах никто не упоминал про 65 Вт - это низкая Достоверность. Модель «подсмотрела» в свою память, а не в контекст.
Проблема №4 - Ясность
Кое-где в ответах приложения проскакивает «Наблюдается девиация гаммы при квантификации LUT-таблиц на уровне API», хотя конечными пользователями будут менеджеры по продукту, а это люди не сильно технические. Нужно что-то делать.
Проблема №5 - Галлюцинации
Периодически модель сообщает: «Пользователи массово жалуются на сбои после обновления до iOS 26». При этом Антон знает, что на момент написания отзывов iOS 26 еще не вышла. Модель «додумала» версию ОС, опираясь на свои вероятностные паттерны (после 25 идет 26), а не на факты.
Именно такие проблемы и пути их локализации мы разбираем во второй части бесплатного курса - Как тестировать AI-приложения (Non-LLM метрики).
Теория - это хорошо, но на практике изучать всё это гораздо более увлекательно. Поэтому мы встроили в курс специальный AI-тренажер (AI-модели стоят денег, поэтому требуется покупка токенов).
Этот AI-тренажер Mentorpiece Sim позволяет на практике наблюдать, как разные метрики:


работают в пяти разных моделях:

Сейчас в нем можно сравнить работу следующих AI-моделей:
Qwen/Qwen3-VL-30B-A3B-Instruct
meta-llama/Llama-3.3-70B-Instruct:novita
google/gemma-3-27b-it
claude-sonnet-4-5-20250929
Gpt-5.1-2025-11-13
Отдельное развлечение для пытливых и неслабонервных - это джейлбрейкинг:



Одни AI-модели на инъекциях “валятся” только так, а для других требуются очень изощренные способы.
Как всегда, бесплатно и без регистрации
Регистрация нужна только для сохранения прогресса.
Бесплатный курс "Как тестировать AI-приложения (LLM метрики)"
Всем интересного и результативного обучения!
Анонс выхода следующих, тоже бесплатных частей - в телеграм-канале Становимся продвинутым QA.
Комментарии (7)

ToniDoni
18.02.2026 09:47Так как тестировать-то в итоге?
Напиши промпт во всех моделях... Самостоятельно оцени ответ
Это кто должен сделать? более сильная модель или человек? Как они должны считать relevance и accuracy?

lilia_urmazova Автор
18.02.2026 09:47Если вопрос про LLM метрики и если не сильно погружаться в детали, то используем LLM-as-a-Judge - более мощная AI-модель работает в роли судьи. Конкретные примеры, как это работает, есть в третьей части курса.

ToniDoni
18.02.2026 09:47а как вы добиваетесь воспроизводимости результата тогда?

lilia_urmazova Автор
18.02.2026 09:47Заданием четких рамок для LLM-as-a-Judge и статистически достоверным количеством прогонов.

ToniDoni
18.02.2026 09:47Вот это очень интересно кстати, надеюсь расскажете в следующих статьях сколько надо прогонов для какой-нибудь конкретной задачи.
averagedigital
хотелось бы добавить: если вы используете локальный инференс для компании, можно смело брать облачных гигантов для валидации (ЛЛМ судья поверх ответов маленькой модели) которой для валидации прописать классы (если классификатор) сущности и тд. К тому же на время валидации не обязательно собирать ответы в том формате, в котором вы будете использовать их в проде, например: вход - выяви ключевые сущности - строгий json, можно декомпозировать ответ до отдельных задач и сравнивать только их.Так проверять значительно приятнее. Ну а если бот "с базой знаний" (я понял это как ретривал), то там специально валидировать на выходе не нужно - у вас и так косинусное расстояние рассчитывается на уровне векторной бд.
lilia_urmazova Автор
Да, всё так. Спасибо за комментарий!