tgoop.com/startup_custdev/172
Last Update:
Тестирование 💫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 интерфейсом. Выглядит круто, кодить не нужно. Советую заценить.
BY Идеальный стартап
Share with your friend now:
tgoop.com/startup_custdev/172