Как измерять coding agents в диалоге

Классический coding benchmark даёт агенту полное условие и после длинного автономного запуска проверяет итоговый repository state. Это удобно для сравнения моделей, но плохо описывает реальную разработку: постановка часто неполна, ограничения появляются после первых изменений, а пользователь уточняет намерение, замечая неверную траекторию. Поэтому multi-turn eval измеряет уже не только исполнение, но и способность сохранять контекст и принимать корректирующую обратную связь.

SWE-Together идёт снизу вверх: авторы превращают реальные пользовательские сессии в 109 воспроизводимых задач и строят реактивного симулятора, который сверяет исходные intent anchors с текущим ходом агента. SWE-INTERACT идёт сверху вниз: берёт 75 задач из существующих benchmark, сохраняет исходные verifier и раскрывает скрытые требования небольшими порциями от лица требовательного senior-инженера. Первый дизайн ближе к наблюдаемой практике, второй лучше изолирует разницу между single-turn и диалогом.

SWE-Together разделяет результат и усилие пользователя. Frozen rubric отвечает, выполнена ли задача, а User Correction считает перенаправления и более мягкие подсказки. В семи протестированных моделях эта метрика сильно обратно связана с pass@1: Pearson −0,92. Сильные модели в среднем требуют меньше вмешательств, но выпуск предлагает смотреть дальше стоимости токенов: каждая коррекция означает внимание инженера, который должен наблюдать, понимать отклонение и формулировать следующий ход.

SWE-INTERACT показывает ещё более резкий эффект. На тех же задачах и с тем же verifier resolve rate GPT-5.5 падает с 48,0 до 24,7%, а Opus 4.8 — с 50,7 до 26,7%. Для GPT-5.5 число шагов вырастает до 3,9 раза, стоимость — до 3,5 раза. Среди провальных траекторий лидируют технические ошибки и забытые требования: агент может увидеть условие в ранней реплике, но не сохранить его в финальной реализации.

Участники не превращают результаты в универсальный рейтинг. SWE-Together сохраняет лишь 0,97% исходных сессий и использует LLM одновременно как симулятора и судью. SWE-INTERACT опирается на одну persona, разные provider-specific harnesses и пользователя с shell-доступом, превосходящим обычную человеческую скорость проверки. Поэтому результат описывает конкретную систему «модель × обвязка × симулятор × verifier», а перенос в production требует собственных сценариев и репозиториев.

Практический scorecard должен хранить финальный success, количество User Correction и разрыв между single-turn и multi-turn на одинаковых задачах. Явный requirement ledger, предварительный plan, фиксация каждой итерации и независимая проверка могут уменьшить забывание и сделать review дешевле, но это пока гипотезы для A/B eval. Главный сдвиг — оценивать агента как участника совместной работы: способен ли он спросить, удержать договорённости, принять поправку и оставить проверяемый результат.