Как построить replay-тест для ИИ-агента и не выпускать ошибку в продакшен
Replay-тест воспроизводит прошлую задачу на новой версии модели и сравнивает результат с эталоном. Такой подход полезен, когда агент читает документы, вызывает инструменты или меняет состояние системы: ручная проверка каждой сессии слишком дорогая, а один демонстрационный пример ничего не гарантирует. Ниже — маршрут от сбора трасс до решения о выпуске.
Соберите безопасный архив
Выберите обезличенные логи и удалите токены, адреса клиентов и внутренние ключи. Сохраните порядок сообщений, ответы инструментов и финальный результат. Отдельно отметьте задачи, где решение было отклонено человеком.
Опишите эталон
Для каждого прогона запишите обязательные факты, допустимые варианты формулировки и запрещённые действия. Эталон не обязан быть одной строкой: иногда правильный ответ — честное «данных недостаточно».
Зафиксируйте среду
Версия модели, системные инструкции, доступные функции и лимит шагов должны быть одинаковыми. Иначе разница между запусками окажется следствием настроек, а не обновления.
Проведите слепое сравнение
Спрячьте названия версий от проверяющего и оцените факты, формат, отказ и побочные действия. Сохраняйте полный diff, а не только итоговый балл.
Введите стоп-критерии
Остановите релиз при новой утечке данных, опасном вызове инструмента или росте существенных исправлений. Условия должны быть известны до запуска, чтобы команда не подгоняла вывод.
Соберите отчёт
Покажите количество прогонов, долю улучшений и регрессий, время проверки и открытые вопросы. Укажите, какие случаи требуют ручного решения и когда повторить тест.
Что проверить перед публикацией
Зафиксируйте версию, дату, исходные данные и владельца решения. Уберите секреты, проверьте факты вторым человеком и сохраните неудачный пример рядом с причиной возврата. Результат должен быть обратимым: сначала тестовая среда, затем ограниченный пилот, и только после измерений — расширение доступа.
FAQ
Зачем нужен replay-тест?
Он показывает регрессии на воспроизводимых прошлых задачах до выпуска новой версии.
Что включить в трассу?
Сообщения, ответы инструментов, настройки, версии и итоговое решение проверяющего.
Когда блокировать релиз?
При утечке данных, опасном вызове или росте существенных исправлений.
Рабочая заметка редакции
Любой вывод о новой технологии полезно проверять в контексте процесса. Спросите себя, кто отвечает за исходные данные, кто имеет право остановить выполнение и как будет восстановлена система после ошибки. Отдельно запишите, что модель не умеет: отсутствие факта, ограниченный язык, зависимость от сети или невозможность подтвердить источник. Такой список не выглядит эффектно, зато помогает коллегам использовать материал без неверных ожиданий. Внутреннее обсуждение проведите до публикации результата, а не после инцидента. Пусть второй читатель попробует повторить основной шаг и найти место, где формулировка допускает двойное толкование. Если он справился, добавьте замечание в журнал и обновите инструкцию. Если нет, сократите область доступа и повторите тест. В конце недели сравните не число сгенерированных ответов, а минуты до принятого решения и количество существенных исправлений. Это универсальный критерий для новости, гайда, обзора и карточки модели. Он показывает реальную пользу и не зависит от громкости названия или красивого интерфейса.