Тестирование 💫AI приложенений💫

Топик большой и сложный. Часть дизайна AI \ ML System. В чем проблема? Когда мы меняем промпт, входные данные или что-либо другое, то хотим удостовериться, что у нас ничего не сломалось, а в идеале улучшилось. Если вы собираетесь работать над проектом больше двух или трех дней, то совсем скоро вам надоест запускать скрипт, вручную вводить 10 разных данных и смотреть результаты. Как же быть? На самом деле правила здесь схожие с тем, что у нас есть в обычном мире software development: юнит, интеграционные и другие тесты.

Гипотеза и метрики

Наша цель – улучшать систему, вводить новые функции и удешевлять производство. Поэтому перед каждым изменением промпта / температуры и других параметров модели формируем гипотезы и метрики. Это могут быть:

-Качество (accuracy, faithfulness, f1, любая другая)
-Стоимость (количество токенов)
-Задержка

Гипотеза может быть:

Уменьшить стоимость на 30%, не потеряв в основной метрике более 3%.

Модульность

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

Тестируем вход, выход, количество потраченных токенов, вызов функций, задержка – на любом этапе может возникнуть проблема.

Датасеты

Не должен вас удивить, если скажу, что прежде всего нам нужны датасеты. Чем больше, тем лучше. Собираем все, что возможно: пограничные случаи, сложные вопросы, джейлбреки (если вам это важно). Необязательно с самого начала собирать датасет на 1000 всевозможных случаев. Куда проще сделать небольшой набросок, выдумать 10-20 примеров и затем в продакшене находить баги и добавлять эти случаи в набор данных.

Регресс-тесты и версии

Когда у нас есть golden-set для тестирования всех подсистем, смотрим на метрики каждого блока. Версионируем промпты, датасеты и модели – так будет легче найти источник проблемы и откатиться к работающей версии.

Работаем с недетерминизмом

LLM может выдавать разный ответ на один и тот же вопрос. Это происходит из-за ненулевой температуры, разных версий моделей, обновлении библиотек.

-Фиксируем seed (если работаем локально), снижаем температуру
-Делаем 3-5 прогонов и усредняем результаты. Не забываем смотреть на стандартное отклонение.

Как тестируем?

Structured Output – простые тесты. Смотрим на возвращаемые поля и проверяем, что обязательность типы и их значения находятся в адекватном значении. Возраст – int от 0 до 120 условно, Имя – строка.

LLM as Judge – как проверить, что модель действительно вернула логичный ответ? Использовать другую LLM!

Еще есть другие типы тестирования для RAG, Agentic и остальных видов систем, но об этом мб в следующий раз.

Онлайн тестирование

Работа с наборами данных называется оффлайн тестированием. Когда мы заливаем модель в прод, то есть возможность протестировать её в реальных условиях – это онлайн тестирование. Здесь можно посмотреть не только на метрики модели, но и реакцию пользователей на нее.

-Заводим A\B тест, смотрим на бизнес метрики: конверсию, ретеншн, время проведенное на сайте.

Полезные инструменты

OpenEval – OpenSource реализация многих инструментов для тестирования. В том числе LLM as Judge – не нужно реализовывать это с нуля. Есть возможность тестирования RAG, tool calling, Agent systems и множество других.

Langsmith with UX – обертка над OpenEval с UX интерфейсом. Выглядит круто, кодить не нужно. Советую заценить.

Что для ИИ ценнее, чем сам ИИ? Данные

Если подумать, ИИ — это просто алгоритм оптимизации: он пытается решить поставленную задачу, оптимизируя функцию потерь. Для LLM это предсказание следующего токена, для роботов на основе обучения с подкреплением – успешно засунуть куб в квадратное отверстие. При этом, ИИ требует больше одной демонстрации с коробкой чтобы успешно справиться с задачей.

Сегодня мы упираемся в потолок данных. OpenAI, Claude, Grok — все эти компании уже спарсили весь интернет, открытые и закрытые наборы данных. Это заметно по недавнему релизу GPT-5: да, кое-где добавили технические фишечки и выжали ещё +5–10% точности. Но это не тот большой скачок, который был между 3 и 4, и проблема становится ещё очевиднее. Какое решение? Синтетические данные!

И это нужно не только для робототехники или дронов. Смоделированные пользователи, инструменты, рынки позволяют создавать, а не просто собирать ситуации и данные. К примеру, AlphaGO была натренирована с помощью симуляции игры двух нейросетей и они оптимизировались на потенциально всех возможных партиях в игре, что позволило в итоге превзойти человека.

Недавние достижения в области игровых движков, создаваемых ИИ (например, Matrix Game), потенциально могут применяться не только в играх, но и является прочной базой для ИИ симуляций для роботехники. Ну и напоследок, вот что мы должны ждать от подобных движков:

– Fidelity (правдоподобие): насколько синтетика статистически и поведенчески похожа на реальность

– Coverage (покрытие хвостов): редкие/опасные/дорогие кейсы

– Controllability (управляемость): можно целенаправленно варьировать сложность/объекты/условия

– Diversity (разнообразие): достаточно ли в каждом сегменте данных