Если в случае классических приложений нефункциональное тестирование часто переносят в разряд “было бы неплохо” и оставляют на потом, то при тестировании AI-приложений так уже не получится.
Например, тестирование стоимости (Costs testing).
Возьмем наш реальный кейс:
Для выбора основной AI-модели в приложении было проведено тестирование точности (Accuracy) и стоимости популярной AI-модели А и менее известной AI-модели Б.
В результате получены интересные результаты:
Модель А дает на 63% ошибок больше, чем модель Б.
При этом стоимость модели А составляет $75 за миллион входных токенов, а модели Б — $3.75 за миллион входных токенов.То есть модель Б в 20 раз дешевле при гораздо лучшей точности!
Выбор команды в данном случае был очевиден.
Или посмотрим на тестирование прослеживаемости (Traceability testing).
AI-модели – это полноценные «черные ящики». Даже разработчикам зачастую невозможно понять, как конкретный ввод данных привел к конкретному решению или выводу.
Представьте, что вы стоите перед великим Сверхразумным Вычислителем, который его создатели в романе “Автостопом по галактике” построили с единственной целью: дать ответ на «Главный Вопрос Жизни, Вселенной и Всего Такого».
После очень длинных вычислений Вычислитель выдает ответ: «42».
Сам ответ, «42», удивительно прост. Но в этом и заключается вся проблема: это чистый, финальный вывод (output), без раскрытой логики. Это идеальный «черный ящик» (black box).
Без хорошо организованного тестирования прослеживаемости, когда мало кто в команде понимает, почему именно сейчас выдан такой результат, любое AI-приложение очень быстро превращается в генератор так “любимого” пользователями слопа.
Другая боль AI-приложений – это надежность. Задержка и пропускная способность часто “плавают”, а какая-нибудь AI-модель (если их в приложении несколько) периодически норовит отвалиться.
Опять же пример из нашей практики:
В AI-приложении используются три разных AI-модели от трех разных AI-провайдеров.
При одновременном выполнении нескольких десятков автотестов всё работает нормально.
Но при одновременном запуске больше сотни автотестов:
– одна из AI-моделей начинает генерировать ошибку 429 (Too Many Requests);
– другая AI-модель в этой же ситуации никакой ошибки не выдает, но примерно в 10% случаев возвращает пустой вывод.
Если хочется получить представление обо всем этом:
-
Тестирование стоимости (Costs testing)
-
Тестирование прослеживаемости (Traceability testing)
-
Тестирование надежности (Reliability testing)
-
Тестирование устойчивости (Robustness)
-
Тестирование конфиденциальности и утечки данных (Privacy and data leakage testing)
-
Как выбрать правильную AI-модель и почему нельзя слепо верить публичным бенчмаркам?
-
Как применять LLM-as-a-Judge для тестирования?
-
Зачем вообще появились AI-Агенты и как их тестировать?
-
Как тестировать RAG?
-
Как тестировать Fine-tuned модели?
-
Как тестировать данные?
но при этом не закопаться в ненужных деталях, то наш обзорный бесплатный курс – находка для классического тестировщика.
Он для тех, кто с тестированием AI-приложений еще не сталкивался и пока не планирует, но при этом хочет “для своего спокойствия” хотя бы примерно быть в курсе, что это такое.
Как всегда, бесплатно и без регистрации
Регистрация нужна только для сохранения прогресса.
Как тестировать AI-приложения: Нефункциональное тестирование
Также курс бесплатно доступен и на Stepik.
Всем интересного и результативного обучения!
Анонс выхода материалов про тестирование чат-ботов и AI-агентов – в телеграм-канале Становимся продвинутым QA.
Автор: lilia_urmazova
