AISI: почему test-time compute меняет оценку AI-агентов
AISI показал, почему один score уже плохо описывает AI-агента: результат зависит от бюджета токенов, повторных попыток и длины задачи.
Факты проверены 3 июля 2026 года. Британский AI Security Institute опубликовал разбор, из которого следует неприятный для привычных таблиц вывод: оценка AI-агента зависит не только от модели и набора задач, но и от того, сколько токенов и вычислений агенту разрешили потратить во время решения. Если бюджет остановили слишком рано, benchmark score становится нижней оценкой, а не реальным потолком возможностей.
Test-time compute AI-агентов — это бюджет токенов и вычислений, который агент тратит уже во время выполнения задачи: на шаги, планирование, проверку результата, исправление ошибок и повторные попытки. Для простого чат-ответа это звучит как техническая деталь. Для агента, который чинит код, ищет уязвимость или проходит длинный cyber-range, это часто решает, увидим ли мы способность вообще.
На Toolarium мы уже разбирали, почему 100% в бенчмарке агента не доказывает способность. Новый материал AISI добавляет к этому важную поправку: даже честный score может вводить в заблуждение, если рядом не указан бюджет токенов и форма запуска.
Оценка агента должна быть кривой, а не одним числом
Стандартная таблица выглядит удобно: модель A получила 42%, модель B — 55%, значит B сильнее. В агентных задачах это слишком грубо. AISI предлагает смотреть на кривую возможностей: как меняется результат по мере роста test-time compute.
Если кривая продолжает расти на последнем измеренном бюджете, оценка ещё не дошла до плато. В таком случае опубликованный score показывает только то, что агент успел сделать до отсечки. Он не показывает, где способность закончилась.
| Где проверяли | Что менялось при большем бюджете | Ограничение вывода |
|---|---|---|
| Cyber CTFs AISI | Около 8% задач решались только при 10M+ токенов; отдельные задачи требовали до 50M токенов. | Это narrow cyber tasks, а не доказательство автономного взлома реальных компаний. |
| TerminalBench 2.0 и SWE-Bench Pro | При росте бюджета с 1M до 10M токенов результат на software engineering задачах вырос примерно на 25%. | Результат зависит от среды, инструментов и того, разрешены ли повторные попытки. |
| FrontierMath и Humanity's Last Exam | На maths/academic задачах AISI сообщает рост примерно на 22% при бюджете до 5M токенов. | Больше compute помогает не везде: на HealthBench модели выходили на плато в обычном бюджете. |
Дополнительный compute можно потратить двумя способами. Первый — дать одному агенту длиннее работать в одной последовательной попытке: искать, ошибаться, проверять и возвращаться к задаче. Второй — запустить несколько независимых попыток и засчитать лучший успешный результат. Оба режима полезны, но они измеряют разные свойства: глубину одного рабочего цикла и вероятность, что хотя бы один запуск попадёт в правильную траекторию.
Поэтому сравнение агентных систем без описания бюджета похоже на сравнение разработчиков без указания времени на задачу. Один получил 10 минут, другой получил день, а в таблице осталась только галочка «решил / не решил».
Длинные задачи первыми страдают от жёсткого лимита
Самая сильная часть разбора AISI не в отдельных процентах, а в связи между человеческой длительностью задачи и расходом токенов. Институт сопоставил 211 software engineering задач METR и 78 cyber CTF задач AISI. Вывод простой: чем больше времени задача заняла бы у сильного человека, тем больше токенов обычно нужно агенту, чтобы показать успех.
В сноске AISI описывает эту связь как степенную зависимость с показателем примерно 0,7-1,0. Практический перевод такой: минутная задача для человека может стоить агенту тысячи токенов, часовая — миллионы, недельная — миллиарды. Это не закон природы, а наблюдение по конкретным cyber и software-задачам. Но для оценки агентов оно уже достаточно важно.
Жёсткий лимит бюджета режет именно длинные задачи. Короткая задача успевает завершиться. Длинная обрывается посередине, хотя агент ещё мог двигаться в правильном направлении. В таблице это выглядит как «модель не справилась», хотя реальная причина может быть другой: оценка дала слишком мало времени и токенов.
Киберпример: 100M токенов всё ещё не значит полный успех
Связанная arXiv-работа AISI по multi-step cyber attack scenarios хорошо показывает обе стороны истории. Исследователи проверяли семь моделей, выпущенных с августа 2024 по февраль 2026 года, на двух симулированных cyber-ranges: 32-шаговой корпоративной атаке The Last Ones и 7-шаговой промышленной Cooling Tower.
На The Last Ones увеличение бюджета с 10M до 100M токенов давало прирост до 59%. Среднее число пройденных шагов при 10M токенов выросло от 1,7 у GPT-4o в августе 2024 года до 9,8 у Opus 4.6 в феврале 2026 года. Лучший отдельный прогон Opus 4.6 при 100M токенов прошёл 22 из 32 шагов. Авторы сопоставили это примерно с 6 часами работы из 14 часов, которые, по их оценке, понадобились бы эксперту-человеку.
Здесь важно не раздуть вывод. Это были симулированные сети без активных защитников и механизмов обнаружения. Полного сквозного прохождения модели не показали. На Cooling Tower прогресс был заметно слабее: лучший средний результат у Opus 4.6 составил 1,4 шага из 7 при 100M токенов, а лучший единичный максимум у GPT 5.3 Codex — 3 шага из 7.
Цена тоже требует аккуратности. Авторы оценили 100M-token attempt для Opus 4.6 примерно в $80 при standard API pricing на дату публикации и input-token caching. Эту цифру нельзя переносить на все модели и все будущие запуски: цены и кэширование быстро меняются, а длинные траектории требуют context compaction.
Что теперь спрашивать у любого бенчмарка
Для разработчика, security-команды или менеджера одного score уже мало. Рядом с результатом агентного бенчмарка должны быть минимум четыре ответа.
- Какой был token budget на задачу?
- Это одна длинная попытка или несколько параллельных запусков?
- Агент остановился на плато или его оборвали, пока кривая ещё росла?
- Сколько стоил успешный прогон и как эта цена считалась?
Это особенно важно для кибербенчмарков. Мы отдельно писали про кибербенчмарки для поиска уязвимостей в коде: там легко перепутать обнаружение конкретного бага, воспроизведение exploit chain и автономную работу в большой среде. Бюджет токенов добавляет ещё один слой: слабый результат может означать слабую модель, плохой scaffold или слишком короткую оценку.
Терминологически рядом лежит test-time scaling и распределение бюджета токенов, но здесь фокус другой. AISI говорит не о красивой технике ускорения или оптимизации инференса, а о методологии измерения: capability нужно публиковать вместе с кривой по compute.
Вывод для Toolarium
Главная мысль этой истории не в том, что «все бенчмарки сломаны». Они всё ещё нужны. Но agentic benchmark без бюджета токенов становится плохо читаемой цифрой. Он показывает результат конкретного режима запуска, а не чистую способность модели.
Если AISI прав, ближайшие сравнения AI-агентов должны выглядеть менее компактно: score при 1M, 10M, 50M и 100M токенов; отдельно надёжность, достижимая сложность и эффективность; отдельно стоимость. Для таблицы лидеров это неудобно. Для реальных решений — честнее.
Самый короткий практический тест: если в отчёте про AI-агента нет token budget, числа стоит читать как черновик, а не как verdict. Особенно когда речь о software engineering, cyber и других задачах, где агент может проверять свою работу и восстанавливаться после ошибок.
Источники
- AISI: More compute, more capability, 2 июля 2026 года.
- Measuring AI Agents' Progress on Multi-Step Cyber Attack Scenarios, arXiv:2603.11214v2, март 2026 года.
- AISI Frontier AI Trends Report, проверено 3 июля 2026 года.
- The Decoder: UK AI Security Institute finds standard benchmarks systematically underestimate what AI agents can actually do, RSS-источник темы.
