Тестовое задание AI QA тестировщика

Задание, конечно, выдуманное. Но суть показывает хорошо.

Сценарий тестового задания:
Приложение для медицинских консультаций получает шквал жалоб от пользователей, хотя внутренняя модель анализа настроений (sentiment model) по-прежнему рапортует о высокой «глобальной точности» (Global Accuracy). Ваша миссия: найти «слепые зоны», которые скрывают метрики.

Данные:
1000 пользовательских отзывов (в формате JSON), содержащих эталонные значения (ground truth), предсказания модели и показатели уверенности (confidence scores).

Что ожидается в качестве результата?
Просто показать навыки кодинга недостаточно. В Evaluation главное — это ответ на вопрос «Ну и что?».

Структурированный аудит: Текстовое объяснение того, где именно находятся слепые зоны, подкрепленное цифрами.

Визуальные доказательства: Калибровочные кривые (Calibration Curves) и матрицы ошибок (Confusion Matrices), которые покажут, почему старые метрики пропустили провалы.

Какими навыками нужно обладать?
Чтобы блеснуть, вам понадобится «гибридный» профиль:

• Теоретическая база: Понимание того, как именно модели ошибаются, и какие метрики применимы к конкретным edge cases.

• Интуиция данных: Способность искать пробелы как вручную, так и автоматически.

• Инженерная строгость: Навыки работы с Python для создания пайплайнов и внедрения LLM-as-a-judge.

• Стратегическая коммуникация: Умение излагать выводы структурированно, точно и грамотно.

Давайте разберем выполнение этой гипотетической задачи по фазам:

Фаза 1: «Детектив» (Анализ данных)
Прежде чем писать хоть одну строчку кода, нужно провести аудит распределения данных:

• Проверка дисбаланса классов: Если «позитивных» отзывов в 10 раз больше, чем «негативных», ваша метрика Accuracy вам нагло врет.

• Поиск предвзятости (bias): Не падает ли качество модели на специфических срезах (например, медицинский жаргон против простого английского)?

• Критика статус-кво: Почему старая «глобальная точность» подвела? Сравните её с метриками, которые реально важны для несбалансированных данных.

Фаза 2: «Архитектор» (Реализация)
Теперь строим фреймворк для оценки:

• Python-архитектура: Используйте чистый, модульный код. Будь то Scikit-learn или Pandas, покажите, что вы заботитесь о поддерживаемости.

• LLM-as-a-Judge vs. метрики: Решите, где нужны статистические библиотеки, а где не обойтись без LLM, чтобы «рассудить» нюансы сарказма или сложного медицинского контекста.

• Уверенность vs. Правильность: Напишите проверку на «уверенно неверные» (Confidently Incorrect) предсказания. Это ваши самые высокорисковые ошибки.

Фаза 3: «Стратег» (Отчетность)
Работа Eval-инженера — это на 20% получение цифр и на 80% объяснение того, что они значат.

• Визуализация: Приложите калибровочные кривые и матрицы ошибок.

• Бриф по «слепым зонам»: Структурируйте выводы. Где именно пробел? Модель пропускает «негатив», потому что там используются сложные термины? Объясните, почему старые метрики проглядели эти критические сбои.

Совет кандидатам
Работодатели в сфере ML Eval ищут не «Data Scientist Lite», а инженеров по качеству и надежности. В вашем GitHub должен быть не просто .py файлы, а README, который рассказывает историю рисков и их минимизации.