Столкнулся недавно с тем, что перформанс популярных кодинговых агентов на внутренних бенчмарках, может значимо скакать (3-7%) в зависимости от времени суток и нагрузки на провайдера.

Дело в том, что в пиковые часы агенты могут медленнее генерировать решения из-за большого трафика. Особенно сильно у меня проседал Claude Code. Как результат, наблюдал всплеск AgentTimeoutError при прогонах автономных бенчей.

Единственного решения такой проблемы нет, есть только много вариантов с своими нюансами. 1) Ограничивать не время, а доступный бюджет на задачу 2) Увеличивать время на выполнение задачи на основе прошлых прогонов 3) Ловить пики и запускать бенчи только когда нет высокого трафика. И еще много-много эвристик. Все решения по-своему плохи, когда у тебя весь продукт про эвалы, но это уже другой момент.

Интересно было посмотреть, сталкивается ли кто-то еще с подобными проблемами. И из свежего наткнулся на заметку от самих Антропиков – Quantifying infrastructure noise in agentic coding evals. Они делятся в целом своим опытом борьбы с шумом в инфраструктуре.

Конкретно, рассказывают, что отловили неприятный эффект, который сказывался на результатах бенчмарка Terminal Bench.

Kubernetes кластер команды был устроен так, что если агент во время выполнения задачи в изолированной среде, в контейнере, вдруг превышал лимит на гарантированно отведенные ему ресурсы, то контейнер сразу умирал.

У контейнерных рантаймов обычно есть два отдельных параметра на ресурсы: гарантированные ресурсы, которые резервируется заранее, и жёсткий upper bound, при превышении которого контейнер просто убивается. Если выставить их в одно и то же значение (что было сделано у антропиков), то нет запаса на непредвиденные всплески – любое отклонение приведет к OOM контейнера, который в норме спокойно бы дожил до конца задачи.

В общем, они заметили что процент таких ошибок большой (достигает 6% по их графикам) и решили расслабить ограничения, увеличив зазор лимита на ресурсы в 1x, 2x, ... 4x и наконец убрав ограничение совсем.

Результаты на картинке снизу. Инфраструктурные ошибки почти ушли, а скоры выросли пропорционально, на 6%. Приятно и полезно.

Отдельно пишут и про другие источники шума, в частности time limit constraints, которые по их опыту влияют на результаты бенчей, но конкретных исследований и замеров не проводили.

Так что да, если релизите модель или бенч, убедитесь, что результаты достоверны и не зависят от шума в инфре, или искусственных ограничений. А то сегодня +2% на бенче может быть SOTA!