Наблюдаемость и evaluation
Телеметрия замечает провал, но теряет причину
TelemetrySuffBench разделяет три разных вопроса: случился ли failure, на каком
шаге возникла его причина и должна ли система воздержаться от ответа, если
данных недостаточно.
На синтетических agent traces пять frontier-моделей с полной телеметрией
определяли исходный шаг с точностью от 33,8% до 97,2%. Когда те же traces
показывали через metadata-, OpenTelemetry- и OpenInference-подобные views,
failure detection оставался почти идеальным — 99,5–100% F1, — но точность
локализации причины падала максимум до 0,5%. Удаление decision content обнуляло
её у всех моделей.
Это не измерение production OpenTelemetry: benchmark синтетический, а названия
форматов означают выбранное авторами представление. Но он ловит реальный дефект
наших dashboard. Статус failed и последняя ошибка хорошо отвечают на вопрос
«кого разбудить». Они почти ничего не говорят о том, какое раннее решение
создало поздний сбой.
Для agent observability нужны не только логи инструментов, но и provenance:
какой вывод привёл к следующему действию, откуда пришли данные и какая версия
policy разрешила переход. Без этой связи дорогая модель-диагност видит аккуратно
оформленную потерю информации.
Источник: TelemetrySuffBench.
Replay оценивает траекторию, которой после замены модели не существует
Обычный способ тестировать model router выглядит разумно: взять записанную
траекторию агента, заменить ответ дешёвой модели на ответ сильной и посмотреть,
улучшился ли итог. The Replay Gap проверяет именно это предположение.
Автор форкал живые траектории mini-SWE-agent в контролируемых точках,
восстанавливал среду и продолжал выполнение с другой моделью. В 74–77% ранних
замен следующее же действие расходилось с оригиналом. Все пять observed outcome
flips случились в swap arms, ни одного — в 359 same-model control forks.
Статический log-stitching неверно предсказал все пять случаев, где успех мог
измениться.
Работа узкая: один scaffold, две небольшие Qwen, всего пять outcome flips.
Зато она демонстрирует не статистический нюанс, а причинную ошибку. Новый ответ
меняет следующий tool call, тот меняет состояние репозитория, и старая
траектория перестаёт быть counterfactual.
Соседний препринт о routing добавляет второе предупреждение. На четырёх обычных
benchmark теоретический oracle gap был большим, но лучший prompt router
возвращал лишь 7,5–14,4% этого разрыва. После поправки на выбор лучшей из 11
политик данные вообще не доказывали превосходство над лучшей фиксированной
моделью. Эксперимент проведён на моделях 0,5–7B, не на frontier agents, поэтому
важна не величина, а дисциплина вывода.
Router нужно оценивать живым fork, а его победу — проверять после selection.
Иначе красивый gain рождается дважды: сначала из несуществующего replay, потом
из выбора лучшей конфигурации на тех же данных.
Источники: The Replay Gap,
selection-valid routing diagnostics.