Разбираем построение работающих evals

Как понять, что AI-агент действительно готов к production? Красивый ответ и даже высокий "pass rate" показывают только финал одного запуска. Агент мог подсмотреть решение, выбрать опасный путь, нарушить права или рассыпаться при повторном прогоне.

Обсудили это вместе с Евгением Сергеевым - Engineering Director в Flow Health с двадцатилетним опытом разработки и управления инженерными командами. Мы разбирали как превратить evals из разовой проверки ответа в воспроизводимую инженерную систему.

Минимальная единица такой системы - воспроизводимый эпизод (`replayable episode`): замороженное исходное состояние, входные данные, контракт агента, скрытая проверка, трасса действий и критерий выпуска. Для кода это может быть commit до PR и `hidden tests`; для архитектуры - требования, ограничения и проверка исполнимости решения; для data platform - snapshot данных, lineage и инварианты.

Обсудили

• Почему оценивать нужно всю агентную систему, а не только модель;
• Как заморозить исходное состояние и не дать агенту подсмотреть будущее решение;
• Что фиксировать в контракте: инструменты, права, сеть, время и бюджет;
• Зачем проверять не только результат, но и траекторию действий;
• Почему одного успешного запуска недостаточно и нужны повторные прогоны;
• Как собрать `production scorecard` из результата, траектории, стоимости, безопасности и принятия человеком;
• Как связать offline-evals с реальными production outcomes и превратить их в `release gates`.

Для меня главный вывод такой: устойчивое качество создаёт не одна метрика и не конкретная модель. Нужен собственный каталог реальных задач, воспроизводимые проверки и понятный критерий, после которого новой версии агента действительно можно доверить работу.