Привычный способ проверки переключения моделей внутри LLM-агентов — проигрывание записанных траекторий по склеенным логам — оценивает состояния, которые при живом запуске просто не возникают. К такому выводу приходит исследование «The Replay Gap» (Ashritha Gonuguntla, COLM 2026, arXiv:2608.08239), в котором живые траектории SWE-bench-агентов разветвлялись в контрольных точках и продолжались другой моделью. Для рынка LLM-роутеров, чья экономика держится на подобных replay-бенчмарках, это прямой удар по методологии, а для инженеров — сигнал перепроверять каскады моделей в собственных агентных пайплайнах на живых раскатках, а не на логах.
Что произошло
В августе 2026 года вышла статья «The Replay Gap» (Ashritha Gonuguntla, arXiv:2608.08239), представленная на Efficient Reasoning Workshop в рамках конференции COLM 2026. Вместо replay-оценки, которая проигрывает записанную траекторию и подменяет модель в выбранных точках, автор разветвлял живые траектории SWE-bench-агентов в контрольных точках, заново собирал окружение для каждой ветки и продолжал её другой моделью — всего около 900 раскаток в шести парных прогонах. После подмены модели перезаписывается от 61 до 94 процентов последующих действий, а валидными остаются лишь 3 процента проигранных состояний. Оценщик на основе склейки логов, log-stitching, ошибся в каждом решающем вызове об успехе, а сходство предсказанных им патчей с реальными составило от 0.00 до 0.11. Все пять переворотов исхода, зафиксированных в работе — апгрейд модели спасал нерешённый инстанс, даунгрейд терял единственное найденное решение, — произошли только в ветках с переключением; в 359 контрольных ветках не было ни одного. Отдельным результатом стало то, что квантование FP8 делает режим temperature-0 недетерминированным: одинаковые модели на FP8-инференсе расходятся более чем на 90 процентов развилок, тогда как на AWQ-инференсе расхождений почти нет.
Контекст
Replay-оценка возникла потому, что живые агентные раскатки дороги: чтобы не перезапускать агента заново после каждой подмены модели, бенчмарки проигрывают записанную траекторию и предполагают, что остальная её часть не изменится. Методологическая слабость этого предположения в том, что агентная траектория — это цепочка состояний, где каждое действие меняет окружение: подмена одного вызова переводит запуск в другую ветку, по которой записанная лог-тrail дальше не идёт, поэтому replay-оценщик валидирует сценарии, которые в реальности не случаются. Внутри этой логики выросла продуктовая категория per-step роутинга — выбора самой дешёвой достаточной модели не только на запрос, но и на каждом шаге агента. Побочный результат про FP8 имеет более широкий смысл: раз квантование инференса ломает детерминизм temperature-0, то классическое требование «одинаковый вход плюс temperature-0 равно одинаковый выход» в современных serving-стеках не выполняется по умолчанию.
Почему это важно для индустрии
Рыночная ставка агентного роутинга держится на replay-метриках, которые по этим данным систематически невалидны для агентов: обещание «самая дешёвая достаточная модель на каждом шаге» оценивается на склеенных логах, а решения о роутинге, принятые по ним, не переносятся на живой запуск. Для вендоров LLM-роутеров это риск того, что заявленная экономия не переживёт первый живой аудит заказчика. Для стартапов открывается окно в «доверенной» оценке агентов, где продуктом становится сама методология — разветвлённые раскатки с пересборкой окружения и контрольными ветками, а не очередная модель. Находка про FP8 бьёт дополнительно и по статическим сравнениям моделей как таковым: без фиксации инференс-стека такие сравнения теряют воспроизводимость, и «воспроизводимый инференс» со временем может превратиться в пункт требований к поставщикам. Если независимые проверки повторят цифры на других доменах, ожидаемо eval-инструменты начнут добавлять режим branching-раскаток, а вопрос заказчика про происхождение метрики станет стандартным пунктом due diligence.
Почему это важно для пользователей
Если вы тестируете каскады или роутинг между моделями в собственном агентном пайплайне, метрики, посчитанные на логах без живого перезапуска окружения, нельзя считать валидированными для вашей системы. Альтернатива уже доступна: харнесс автора и все траектории выложены открыто на GitHub и Hugging Face, поэтому свой стек можно прогнать через разветвлённые раскатки с пересборкой окружения и контрольными ветками, а затем сравнить live-раскатку с показаниями replay-логов. До такой проверки заявления вида «дешёвая модель справляется не хуже» внутри агентов разумно считать неподтверждёнными. Отдельно стоит проверить, не стоит ли ваш serving на FP8: если да, то temperature-0 нельзя считать воспроизводимым, а для сравнений моделей имеет смысл фиксировать инференс-стек и рассматривать альтернативное квантование, например AWQ. Для покупателя простая проверка того, считены ли заявленные вендором метрики на живых раскатках, — уже сейчас обязательный пункт чек-листа.
Что пока неизвестно / ограничения
Вся доказательная база собрана на SWE-bench-агентах в шести парных прогонах при примерно 900 раскатках, поэтому перенос вывода на другие классы агентов, например браузерных или tool-use, и на «рыночную ставку роутеров в целом» является гипотезой о влиянии, а не результатом работы. Сигнал интереса рынка пока ранний: три поинта и ноль комментариев на Hacker News — это академический сигнал, а не переоценка рынка. Ожидания относительно появления branching-режимов в eval-инструментах и пересмотра бенчмарков вендоров также остаются интерпретациями до независимых репликаций.
Источники
- The Replay Gap: Static Evaluation of Model Switching in LLM Agents Scores the Wrong World (arXiv:2608.08239, COLM 2026)
- Replay Gap — код и харнесс разветвлённых раскаток, репозиторий AshrithaG на GitHub
- Replay Gap Trajectories — датасет траекторий на Hugging Face Datasets
Автор
Look at AI, редакция