Третья статья цикла про работу AI-QA-инженера (но написана без использования AI)

В предыдущих статьях:

• Как тестировать AI-приложения:
  - За полгода мне в Mentorpiece пришлось поучаствовать в тестировании сразу нескольких коммерческих AI-проектов (не путать с использованием AI-инструментов для тестирования).
  - Кому из QA-инженеров стоит изучать тестирование AI, а кому нет.
  - Как тестировать, если ты QA-джун, который попал на AI-проект, и ничего не понимаешь.

• Тестируем AI-приложения на практике. Черный ящик: бинарный вывод:
  - Тестирование AI-приложений для начинающих на практике.

Сейчас: как AI-QA-инженеру сэкономить много денег для проекта и компании?

Напомню принципы этой серии статей про тестирование AI:
1. Очень простой подход - говорим про то, что большинство тестировщиков могут освоить и без глубокого знания программирования.
2. Очень прикладной подход - это не голая теория, а то, что уже используется для тестирования AI-функционала на коммерческих проектах в компаниях с платящими клиентами (а не в пет-проектах или стартапах на начальных стадиях)

Зачем тестировать стоимость AI-приложения

На некоторых проектах QA-инженеру приходится доказывать свою полезность.
В случае AI-проекта это тем более может быть актуально. 

Здесь на помощь может прийти простое правило AI-разработки: 

"Каждый квартал появляется AI-модель, которая эффективнее и дешевле используемой на проекте сейчас".

Лучший способ заработать себе очки в глазах коллег - это провести небольшое тестирование и найти модель лучше той, которая используется на проекте сейчас. 
Наш кейс: в результате тестирования найдена модель, которая в 20 раз дешевле и дает на 60% меньше ошибок.

Есть много различных метрик, оценивающих тот или иной аспект AI-модели: например, релевантность (Relevancy), точность (Accuracy), корректность (Faithfulness), ясность (Clarity), уровень галлюцинаций (Hallucinations) и так далее.

Есть не меньшее число бенчмарков - стандартизированных наборов данных или задач, помогающих сравнивать производительность моделей в определенной области: MathQA (Математические вопросы и ответы), MMLU (Масштабное многозадачное понимание языка) или свежий HealthBench (Производительность и безопасность моделей в медтехе) и прочие.

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

Логичный выход - проверить качество работы разных моделей именно для собственных задач.

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

Посмотрим на два основных вида стоимостного тестирования - тестирование стоимости модели (AI Model Costs Testing) и тестирование стоимости реализации (AI Implementation Costs Testing).

Как тестировать стоимость AI-модели

Разные модели дают разное качество.

Использование разных AI-моделей стоит разных денег.

Было бы логично предположить, что чем AI-модель дороже, тем она лучше работает. Но это далеко не так. Опять же вернемся к мысли из предыдущего абзаца - всё зависит от ваших собственных данных, сценариев использования и того, в каких целях AI-модель используется.

Самый простой способ - прогнать функционал AI-приложения, настроенные промпты и все остальное на разных моделях разных провайдеров с разными температурами и сравнить коэффициент валидности тестов.

Легче всего это делать на примере бинарного вывода из предыдущей статьи Тестируем AI-приложения на практике. Черный ящик: бинарный вывод - ведь бинарный вывод дает четкий ответ "да" или "нет" и поэтому сравнивать результаты выполнения разных конфигураций легче. В Mentorpiece для этого используется небольшой фреймворк ai_manager - который позволяет быстро конфигурировать нужные провайдеры/модели, параллельно прогонять по ним тесты с учетом rate limits разных провайдеров, а результаты прогонов получать сразу в Google Sheets.

Столбцы - это тесты.
Строки - это прогоны тестов на разных моделях разных провайдерах с разными температурами.
Ячейки - это:
- Passed (зеленый) - результат теста истинно положительный или истинно отрицательный
- Failed (красный) - результат теста ложно положительный или ложно отрицательный
- Crashed (белый) - модель “упала” и не вернула ответ. На момент прогона тестов подобным грешил Gemini.

Как мы видим, разные прогоны одних и тех же тестов по разным моделям дают разные результаты.

И прогоны по разным температурам одной и той же модели тоже дают разные результаты.

Так как результаты тестов логгируются сразу в Google Sheets, то за пару секунд строим Pivot Table со средними результатами прогонов по всем провайдерам/тестам/моделям:

Gemini из-за своих падений оказался аутсайдером со средним результатом 81.5%

Среди моделей OpenAI самый хороший коэффициент валидности тестов 97.8% у gpt-4.5-preview. Одновременно это и самая дорогая модель, которую, скорее всего, из-за этой дороговизны и выводят из эксплуатации. Жаль, она была действительно качественной.

Самый же лучший результат - у claude-3-7-sonnet-20250219. Коэффициент валидности тестов составляет 99.2%.

Таким образом получается, что конкретная модель claude дает на 63% ошибок меньше, чем самая дорогая модель у OpeanAI. 

Если же вспомнить про стоимость, то результат становится еще более интересным. Стоимость gpt-4.5-preview составляла $75 за миллион входных токенов, а claude-3-7-sonnet-20250219 - всего лишь $3.75. 

В 20 раз дешевле при гораздо лучшем коэффициенте валидности тестов!

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

Частный случай тестирования стоимости: Роутинг

Роутинг - это когда запросы отправляются приложением в ту или иную AI-модель по определенному условию.

Классический случай роутинга - когда более простые запросы заправляются в более дешевую AI-модель, а более сложные запросы - в более продвинутую и поэтому более дорогую AI-модель. Это тоже позволяет ощутимо снизить стоимость использования AI-моделей.

Здесь тестирование достаточно очевидное - мы прогоняем тесты на более дешевой модели и выделяем те, которые прошли успешно. Проверяемый ими функционал будет работать на дешевой модели.
Те тесты, что прошли неуспешно, нужно проанализировать. Проверяемый ими функционал, скорее всего, будет использовать более дорогие модели.

Как тестировать стоимость реализации

Здесь мы говорим про более сложные тесты, которые уже могут выходить за пределы квалификации AI-QA-джуна. 

Напомню, что с точки зрения QA-инженера виды AI-функционала мы в Mentorpiece раскладываем на бинарный вывод (binary choice), семантический поиск (semantic search), генерацию (GenAI) или классификацию (classification).

Поговорим про генерацию - наиболее известное широкой публике применение AI-моделей для написания текстов, генерации идей, изображений/аудио/видео. В случае такого функционала нам надо как-то помнить контекст диалога - всю предыдущую историю сообщений пользователя и AI-модели в рамках текущего сеанса. Иначе модель будет страдать ретроградной амнезией и не сможет отвечать на "догоняющие" вопросы пользователя.

Самый популярный метод управления контекстом - это хранение списка всех предыдущих сообщений и их передача в модель с каждым новым сообщением. И все бы неплохо, но снова старое "но" - токены у нас платные.

Если мы будем хранить и передавать модели весь-весь контекст, то это будет замечательно с точки зрения пользователя, но будет не очень с точки зрения стоимости - контекст с продолжением разговора будет становиться всё больше и каждое следующее сообщение будет стоить всё дороже. Есть еще и одна неприятная особенность - "перегрузка контекстом" (Context Overload) - когда слишком большой размер контекста приводит к росту ошибок у AI-модели.

Есть и обратное решение - передача модели только ограниченного контекста. Например, только последних 5 сообщений. Это, несомненно, дешевле полного хранения контекста. Но не страдает ли в этом случае пользовательский опыт?

Как лучше поступать в случае конкретного проекта, должно быть определено исходя из функционала продукта с помощью данных, полученных AI-QA-инженером. Оценка контекстной точности (Contextual Precision), контекстная полнота/полнота охвата контекста (Contextual Recall) и другие метрики, прогнанные на разных конфигурациях приложения - это то, что позволит команде найти лучшую по соотношению качество/стоимость конфигурацию.

Так как это более сложные метрики, то для работы с ними лучше использовать фреймворк для оценки качества AI-моделей DeepEval или его аналоги.

Тестировщик теперь может не только влиять на какое-то там качество продукта - которое невидимо и сложно измеримо. Он может помочь проекту и компании сэкономить очень конкретное количество денег. И тем самым повысить свою "стоимость" в глазах коллег.

Продолжение

В следующей статье "Как тестировать AI на практике - Черный ящик, семантический поиск" говорим про очень интересное тестирование - когда мы тестируем AI при помощи другого AI. Так называемый LLM-as-a-Judge.

Полезное AI-компаниям - бесплатно 

Разрабатываете AI-проект? Если что-то работает не так и/или хочется снизить стоимость разработки, то вот два варианта получить толковые AI-кадры бесплатно:

Работаете на AI-проекте? 

Есть вопросы? Хотите поделиться опытом или поучаствовать в нашем R&D?
Добро пожаловать в ЛС!

Полезное изучающим тестирование AI - бесплатно 

Бесплатный учебник по тестированию AI сейчас в разработке. Тысячи уже знают, например, наши бесплатные 100-Year QA-Textbook или Оранжевый учебник. 

Анонсы выхода учебника и следующих статей цикла - в телеграм-каналах:
Становимся тестировщиком - анонсы статей по Black-Box тестированию AI.
Становимся продвинутым QA - анонсы статей по Gray-Box тестированию AI.