Вторая статья цикла про работу AI-QA-инженера (но написана без использования AI)
— Когда работаешь в IT уже почти 25 лет, то все обещаемые революционные изменения в IT воспринимаешь со значительным скепсисом. Но за полгода мне в Mentorpiece пришлось поучаствовать в тестировании сразу нескольких коммерческих AI-проектов (не путать с использованием AI-инструментов для тестирования)
— Кому из QA-инженеров стоит изучать тестирование AI, а кому нет
Сейчас: что делать, если вы никогда не сталкивались с AI-функционалом, но попали на AI-проект?
Каждый пятый QA-джун попадает на проекты как единственный тестировщик
Хорошо это или плохо — открытый вопрос.
С точки зрения возможности наломать дров — однозначно плохо.
С точки зрения получить опыт из расчета «год за три» — однозначно хорошо.
Из моих подопечных в Mentorpiece некоторые новички попали не просто единственными QA-инженерами на проект, но единственными AI-QA-инженерами на проект.
Что делать в такой ситуации? Первое, что приходит в голову — это пойти спросить сам AI. Но если вы попросите, например, Gemini сделать исследование о тестировании AI, то он подготовит вам «небольшой» документ страниц на 60 с сотней основных методов. Получив такое на руки, легко надолго впасть в ступор выученной беспомощности.
Моя задача состоит в обратном — показать, что начинать тестировать AI можно с малого и для того, чтобы “причинить пользу” проекту уже в первые две недели работы, не требуется фантастических знаний математики.
Принципы этой серии статей про тестирование AI:
— Очень простой подход — говорим про то, что большинство джунов могут освоить и без глубокого знания программирования
— Очень прикладной подход — это не голая теория, а то, что уже используется для тестирования AI-фукнционала на коммерческих проектах в компаниях с платящими клиентами (а не в пет-проектах или стартапах на начальных стадиях)
Бинарный вывод (Binary Choice), семантический поиск (Semantic Search), генерация (Generation) или классификация (Classification)?
Многообразие AI-систем велико, и их классификация пока еще не очень устоялась.
Но если посмотреть с точки зрения тестировщика, то можно выделить несколько основных типов:
- Бинарный вывод (Binary Choice) — это когда от системы ожидается четкий AI-ответ “да/нет”. Например, ответ по наличию определенной позиции продукции, модерация контента, показ рекламы, одобрение кредита/страхового случая, предварительная меддиагностика, аутентификация, тестирование знаний и т.д.
- Семантический поиск (Semantic Search) — в этом случае пользователь ожидает по своему запросу наиболее релевантную выдачу текста/изображений/аудио/видео. Функционал все чаще реализуется именно с помощью AI.
- Генерация (Generation) — это наиболее известное широкой публике написание AI-моделью текстов, генерация идей, изображений/аудио/видео.
- Распознавание/классификация (Classification) — обнаружение и сегментация различных объектов. Например, анализ видеопотока камер в казино с целью распознавания фишек на столах, отслеживания их положения, переходов между игроками и выявления случаев мошенничества (это описание реального AI-проекта моего знакомого). Указанный выше бинарный вывод является частным случаем задачи классификации, но для удобства мы рассматриваем его отдельно.
Как работает бинарный вывод (binary choice)
Начнем с самого простого — бинарного вывода.
Добрый день!
Интересует семиместная электричка. Хотел бы забронировать драйвтест в любом салоне на юго-западе в ближайшие выходные после 14:00.
Пришлите, пожалуйста, подтверждение брони на этот номер.
Яркий пример бинарного вывода — здесь функционал AI-приложения должен выдать по сути «да или нет».
Если в базе бронирований есть свободные слоты на определенные модели автомобилей в определенном салоне на определенное время — то клиенту должно уйти соответствующее подтверждение.
Если в базе бронирований таких свободных слотов нет, то должна запуститься другая ветка функционала — например, агент-консультант, который попробует помочь клиенту иначе.
В любом случае здесь от AI-модели ожидается четкий ответ — да, слоты есть, или нет, слотов нет.
Но, как показывают теория и практика, из-за механизмов работы AI добиться четкого ответа от модели как раз сложнее всего.
И поэтому нам нужно хорошее качественное тестирование.
Как тестировать бинарный вывод
Напомню, что здесь мы тестируем черным ящиком и не погружаемся в детали внутренней реализации. Не изучаем особенности формирования промптов или нюансы дообучения модели. Нас интересует только то, насколько правильно система отрабатывает.
Здесь может быть 4 варианта ответа системы:
- Истинно положительный (True Positive) — свободные слоты тест-драйва с нужными условиями есть, система готова их забронировать
- Ложно положительный (False Positive) — свободные слоты с нужными условиями отсутствуют, но система готова их забронировать
- Истинно отрицательный (True Negative) — свободные слоты с нужными условиями отсутствуют, система готова обработать их отсутствие
- Ложно отрицательный (False Negative) — свободные слоты с нужными условиями есть, но система готова обработать их отсутствие
Дальше наша задача — написать позитивные и негативные тесты.
- Позитивные — подаем на ввод то, что должно давать положительный вывод, и ожидаем положительный вывод
- Негативные — подаем на ввод то, что должно давать отрицательный вывод, и ожидаем отрицательный вывод
Вышеуказанное называется работой с матрицей ошибок (confusion matrix):
Так как таких тестов у нас будет много, то из практических соображений нам удобнее работать с матрицей результатов (Result Matrix). Про нее — далее.
Если ваши AI-тесты всегда зеленые — это плохие тесты
Мы написали/сгенерировали несколько десятков или сотен ручных/автоматизированных тестов — позитивных и негативных.
Какой результат мы получим в результате их прогона?
В случае тестирования AI ваши тесты практически НИКОГДА не будут проходить успешно на 100%. Если они проходят, то это значит, что ваши тесты слишком грубые, или имеют плохое покрытие, не учитывают все возможные варианты вводов от пользователей. И в проде вас ждут неприятные сюрпризы.
Поэтому нужно говорить не про то, являются ли тесты зелеными или красными, а про то, в каком проценте тестовых случаев ожидаемое поведение системы совпадает с фактическим. Этот параметр мы в Mentorpiece называем «коэффициентом валидности тестов». Не путать с «коэффициентом валидности» — в AI он имеет более широкое значение, связанное с общим качеством работы модели.
Матрица результатов
Как она выглядит:
Строки — это прогоны тестов.
Столбцы — это тесты.
Ячейки — это:
Passed (зеленый) — результат теста истинно положительный или истинно отрицательный
Failed (красный) — результат теста ложно положительный или ложно отрицательный
Еще бывает пустая ячейка (белый) — некоторые модели иногда просто падают при ответе, и такие ситуации лучше рассматривать отдельно.
Самый левый столбец — это коэффициент валидности тестов (Test Validity Coefficient) — какой процент тестов завершился успешно.
Прогон тестов даже на одной и той же версии приложения с одними и теми же промптами и с одними и теми же настройками AI-модели иногда будет давать разные результаты.
Тем более, прогоны тестов будут давать разные результаты, когда команда разработки будет что-то менять, подкручивать — особенно получая от вас обратную связь, что что-то работает не так. Именно результаты такого подкручивания мы видим на изображении выше. В данном случае на одном из проектов Mentorpiece нам удалось увеличить коэффициент валидности тестов и снизить частоту ошибок на 60% просто за счет смены модели.
В анализе подкручиваний и их последствий вам сильно облегчит жизнь, если вы одним из первых проведете также тестирование прослеживаемости. Если в двух словах — это тестирование того, что все значимые параметры и настройки AI-модели логгируются и по этой информации потом можно провести расследование.
Автоматизация
На ранних стадиях проекта, когда команда выбирает подходящую модель, может потребоваться большое число прогонов тестов — на разных температурах на разных моделях разных AI-провайдеров.
На следующих стадиях проекта, когда команда экспериментирует с промптами или fine-tuning, тоже потребуется много прогонов.
Более того — во всех остальных видах приложений, кроме бинарного вывода, вам потребуется тестирование LLM-as-a-Judge, а его вручную гонять совсем печально.
Плохая новость — всё это рано или поздно придется автоматизировать.
Хорошая новость — автоматизируется это всё легко или при помощи специализированных решений, или при помощи несложного vibe-кодинга.
Специализированные решения — это, в первую очередь, хорошо известный DeepEval и его аналоги.
Но для тестирования бинарного вывода это может быть слишком тяжеловесным решением. Тем более, что сам DeepEval бесплатный, а вот удобная аналитика для него (confident-ai.com) для средней по размеру команды может обойтись в районе $500/мес.
Поэтому мы в Mentorpiece поступили проще и на базе pytest сделали небольшой фреймворк ai_manager, который прогоняет обычные или LLM-as-a-Judge тесты на любых моделях, а результаты тестов записывает в Google Sheets. QA-джун без каких-либо навыков программирования может показать этот каркас Copilot, объяснить, что ему нужно, и за час-два vibe-кодинга получить нужную автоматизацию.
И еще немного про тестирование разных моделей. Сейчас есть множество агрегаторов AI-моделей, которые позволяют через один API обращаться к разным моделям — но я бы не рекомендовала их использовать. Некоторые AI-провайдеры сами по себе нестабильны, и по тестам это становится хорошо видно, а работа через посредника может создать дополнительные «наводки».
Google Sheets
Существует большое разнообразие инструментов, готовящих отчеты по результатам тестов.
При работе с AI вам, скорее всего, придется изучать разные метрики, а некоторые из них проще рассчитывать в банальном Google Sheets. Поэтому если результаты ваших прогонов будут сразу оказываться в Google Sheets или чем-то аналогичном по функционалу с возможностью «набрасывать» формулы, pivot tables и графики, то вы не только сильно облегчите себе жизнь, но и сможете быстрее делать анализ того, что сейчас происходит с системой. И предсказывать, куда она мигрирует.
В следующей статье поговорим про такой необычный вид тестирования, как тестирование стоимости. Когда AI-QA-инженер может сэкономить много денег для проекта и компании.
Полезное компаниям — бесплатно
Разрабатываете AI-проект? Если что-то работает не так и/или хочется снизить стоимость разработки, то вот два варианта получить толковые кадры бесплатно:
— Получите в штат QA-специалиста, который уже имеет практический опыт работы с AI. Мы никаких комиссий не берем, платите зарплату напрямую ему. Наш интерес: чтобы AI-QA-специалист получил полную загрузку по специальности.
— Целая QA-команда под руководством опытного QA-лида на 3+ месяца от Mentorpiece. Мы также никаких денег не берем и в этом случае даже зарплату платить никому не надо. Наш интерес: интересные R&D задачи. В 2/3 случаев одного-двух интернов компания оставляет в штат.
Работаете на AI-проекте?
Есть вопросы? Хотите поделиться опытом или поучаствовать в нашем R&D?
Добро пожаловать!
Полезное изучающим AI — бесплатно
Бесплатный учебник по тестированию AI сейчас в разработке. Тысячи уже знают, например, наши бесплатные 100-Year QA-Textbook или Оранжевый учебник.
Анонсы выхода учебника и следующих статей цикла — в телеграм-каналах:
Становимся тестировщиком — ссылки на статьи по Black-Box тестированию AI.
Становимся продвинутым QA — ссылки на статьи по Gray-Box тестированию AI.
