Вычисления на этапе тестирования

Назначение

Почему более длительные вычисления в одном решении агента делают агента увереннее, но не делают его правильнее?

Один вызов модели возвращает одно предложение, и на трудном решении это предложение часто оказывается гладкой фиксацией на неверной гипотезе. Прежде чем действовать, среда выполнения может купить дополнительный вывод: позволить модели рассуждать дольше, выбрать несколько кандидатов или запустить проверку и вернуть ее результат на доработку. Каждая такая покупка стоит токенов, секунд и денег, и лишь некоторые из них меняют то, что известно среде выполнения. Более длинные рассуждения и неуправляемая повторная выборка снова опираются на те же веса и тот же промпт, поэтому они добавляют стоимость быстрее, чем свидетельства, тогда как один дешевый тест, способный забраковать кандидата, может решить вопрос сразу. У отбора есть собственная ловушка: поиск среди многих кандидатов по несовершенной проверке находит именно тех кандидатов, которых проверка пропускает. Поэтому инженерный вопрос состоит не в том, сколько думать, а в том, какое свидетельство покупает данная трата, какие проверки могут принять результат и когда остановиться. В терминах H·S·A вычисления на этапе тестирования не добавляют собственных экспозиций, поскольку ничего не действует, пока среда выполнения не допустит кандидата. Но каждый раунд доработки расходует горизонт внутри одного решения, и эта трата оправдана только тогда, когда повышает свидетельства замыкания, стоящие за предложением, которое среда выполнения в итоге допустит.

Цели обучения

• Объяснить, почему одно предложение модели рано фиксируется на гипотезе и почему повторная выборка без новых свидетельств добавляет стоимость, но не информацию.
• Сравнить глубину, ширину и обратную связь, включая модели рассуждений и бюджеты на размышление, по свидетельствам, которые каждая из них покупает на токен, секунду и доллар.
• Проанализировать отбор кандидатов голосованием, обученными верификаторами и судьями на основе LLM, рассматривая pass@$k$ как потолок выбора по схеме best-of-k.
• Рассчитать точность принятого верификатором множества и объяснить, почему более сильный поиск по несовершенному верификатору отбирает эксплойты.
• Представить многошаговый план как пересматриваемый граф зависимостей, сбои которого исправляются локально, а не повторной генерацией.
• Спроектировать правила остановки и эскалации поиска по жестким пределам, сертифицированному досрочному выходу и предельному приросту.
• Оценить стратегию на этапе тестирования относительно базовой линии с одним кандидатом по стоимости принятой задачи и задержке к предельному сроку.

Почему один кандидат может провалиться

При 95-процентном успехе на шаг до конца доходят менее 15 процентов 40-шаговых траекторий. Это предел разомкнутого контура из раздела «Растяжение времени: от наносекундных операций до килосекундных траекторий».

Высокопроизводительное распределенное хранилище «ключ — значение», развернутое в нескольких зонах доступности, начинает демонстрировать деградацию хвостовой задержки и периодические аномалии чтения устаревших данных при интенсивной параллельной записи. Мониторинг показывает, что отставание синхронизации реплик периодически поднимается выше 120 миллисекунд, однако телеметрия сетевых интерфейсов показывает потери пакетов и повторные передачи, неотличимые от фонового шума. Две взаимно исключающие причины дефекта одинаково правдоподобно объясняют эту телеметрию: ненастроенный таймаут сигнала живости кластера, который преждевременно понижает исправные реплики и запускает дорогие всплески повторной синхронизации, либо состояние гонки в параллельном протоколе аннулирования аренд, которое пропускает барьеры памяти при обновлении нескольких ключей и позволяет репликам чтения отдавать аннулированные записи до того, как временная метка отзыва аренды распространится по кластеру.

Когда инженер показывает эту неоднозначную трассу журнала непривилегированной базовой модели в интерактивной сессии, авторегрессионный цикл декодирования выбирает токены, опираясь только на промпт и выученные параметрические веса. Поскольку таймауты сокетов и настройки сигнала живости часто встречаются на форумах разработчиков и в открытых репозиториях обучающего корпуса, проекция выходных эмбеддингов модели назначает гипотезе о сигнале живости высокое условное правдоподобие. Модель генерирует патч, увеличивающий таймаут сокета, оборачивает правку в гладкое диагностическое обоснование и представляет предложение. В интерактивном режиме эта неверная гипотеза — небольшая разговорная неудача: человек-инженер изучает предложение, замечает, что счетчики сетевого интерфейса чистые, отвергает гипотезу и приносит дополнительные системные метрики. Но когда системная инженерия переходит от разговорной помощи к автономному делегированию, то есть когда среда выполнения агента передает многошаговую диагностику, изменение кода и развертывание напрямую непривилегированной модели без участия человека, один прямой проход становится критической единственной точкой отказа. Внедрение непроверенного патча в производство не устраняет лежащую в основе гонку аннулирования аренд и позволяет молчаливым порчам данных распространяться по нижестоящим хранилищам.

Один вызов модели не может надежно решить сложную диагностическую или инженерную задачу, потому что правдоподобие последовательности не является прокси операционной истины. В автономной системе основной вычислительный отказ — это не синтаксическая недопустимость и не поверхностная несвязность, а преждевременная фиксация на неподтвержденной гипотезе при отсутствии различающих свидетельств. «Базовая модель» оценила такое предложение в выходных токенах и показала, что оно достигает среды только через периметр верификации среды выполнения («Верификация кандидатных последовательностей»). Пока этот периметр его не допустит, предложение остается непроверенным буфером, который хранится в эскроу.

Цикл декодирования делает такую фиксацию трудно обратимой. Как только токен выбран и его векторы ключа и значения попадают в KV-кеш, каждый последующий токен потока обращает на него внимание, и ничто в потоке не может его отозвать («Авторегрессионная генерация»). Если ранний токен направляет траекторию на ошибочную посылку, например утверждение, что аномалия кластера вызвана таймаутом сигнала живости, все последующие скрытые состояния обращают внимание на это утверждение. Поскольку генеративное предобучение оптимизирует логарифм правдоподобия связных последовательностей, модель не обнаруживает лежащего в основе физического противоречия и не останавливается. Ее поздние токены обосновывают, оправдывают и развивают исходную ошибку, порождая гладкие, но выдуманные аргументы, которые сохраняют связность текста. Это отравление контекста из раздела «Динамика отравления контекста», действующее внутри одной генерации, а не между ходами.

Дерево диагностики и различающая верификация: при неоднозначном наблюдении телеметрии разомкнутая авторегрессионная генерация (слева) преждевременно фиксируется на гипотезе $H_1$, отравляя контекст KV-кеша последующих шагов и порождая ошибочный патч, который оставляет корневой дефект нетронутым. Целенаправленный поиск (справа) не выполняет действие, пока целевой различающий зонд не опровергнет $H_1$, не выделит $H_2$ и не позволит проверенно разрешить состояние.

Исполнение попадает в ложный путь (garden path): траекторию, на которой локальные вероятности переходов токенов остаются высокими, а глобальная вероятность успеха задачи падает до нуля. Стандартная авторегрессионная выборка на каждом токене задействует граф вычислений фиксированной глубины независимо от трудности задачи и неоднозначности телеметрии. Когда автономная система работает разомкнуто, исполнение одного кандидата распадается по четырем различным системным режимам отказа:

1. Эпистемическая неоднозначность и смещение априорных вероятностей: входной вектор телеметрии не содержит достаточной информационной энтропии, чтобы выделить истинный дефект, однако политика выборки вынуждает немедленную необратимую фиксацию, смещенную априорными вероятностями предобучения в сторону распространенных поверхностных шаблонов.
2. Авторегрессионная фиксация и отравление посылки: как только неподкрепленная посылка попадает в KV-кеш, каузальная маска внимания гарантирует, что последующие токены обусловлены этой ошибкой, и модель не может самокорректироваться в пределах того же потока генерации.
3. Неглубокие композиционные горизонты: один прямой проход выделяет фиксированный, постоянный объем вычислений ($O(1)$ слоев трансформера) на токен. При диагностике сложных распределенных гонок цепочка композиционных зависимостей превышает непосредственную представительную способность одной последовательности без развернутых промежуточных состояний рассуждения.
4. Ошибка перефразирования: запрос на неуправляемый второй проход или просьба модели «пересмотреть» без введения новых внешних свидетельств дает нулевой прирост информации. Если промпт содержит тот же вектор наблюдения и выборка идет из того же распределения параметров $\Theta$, неуправляемая повторная выборка лишь колеблется в том же бассейне вероятности. Перефразирование ошибочной посылки добавляет нулевую взаимную информацию ($I(Y;\text{Truth}\mid X)=0$). Правдоподобный язык не может заменить эмпирические свидетельства.

Как показано на рисунке «Дерево диагностики и различающая верификация», разомкнутая генерация слева необратимо фиксируется на высоковероятной априорной гипотезе $H_1$ ($P(H_1)=0,75$), позволяя отравленному контексту KV-кеша направить последующее исполнение к неэффективному патчу таймаута. Справа целенаправленное исполнение удерживает действие в корневом состоянии $s_0$, пока внешний диагностический зонд не выполнит целевой тест на параллельность. Зонд фиксирует конкретное свидетельство времени выполнения: сокеты исправны, а блокировки аренды освобождаются преждевременно. Это свидетельство однозначно опровергает $H_1$, отсекает недопустимую ветвь и направляет последующую генерацию к проверенному исправлению синхронизации в состоянии $s_2^{\ast }$.

Зонд против более длинного ответа

Задача: при диагностике устаревшего чтения сколько генерации заменяет зонд с различением продолжительностью 40 мс?

Переменные: модель декодирует на уровне однопоточного предела из раздела «Задержка обслуживания на ускорителе», $t_{\text{tok}}\approx$ 21,1 мс на выходной токен. Остальное — допущения сценария. Конечная точка берет $15 за миллион выходных токенов. Ответ модели доходит до $K=$ 1 024 выходных токенов и фиксируется на $H_1$ на токене 16. Априорные вероятности: $P(H_1)=0,75$ и $P(H_2)=0,25$. Зонд работает 40 мс на CPU в песочнице и возвращает около 60 токенов вывода, которые следующий вызов читает как входные данные.

Расчет: полный ответ занимает около 21,6 с и стоит около $0,015. Все после токена 16 развивает непроверенную посылку: это 1 008 токенов, или 21,2 с, то есть 98 % генерации. До зонда неопределенность среды выполнения относительно двух гипотез составляет

$$H=-\left(0,75{\log }_{2}0,75+0,25{\log }_{2}0,25\right)\approx 0,81\text{ бит}$$

Зонд опровергает одну из гипотез, и неопределенность падает до нуля. Длинный ответ оставляет ее на уровне 0,81 бита, поскольку его содержание не зависит от того, какой дефект присутствует.

Системный вывод: зонд занимает около 1/540 времени генерации по часам и снимает всю неопределенность, которую генерация не снимает вовсе. Ни то ни другое не стоит много денег; дорогой исход — развернутый ошибочный патч. Среде выполнения следует покупать свидетельства за секунду, а не токены за секунду.

«Принцип замыкания инвариантов» уже помещает корректность задачи за пределы модели, на границу приложения, поэтому генератор не может подтвердить собственные гипотезы, проверив их внутреннюю согласованность или поразмыслив над ними в диалоге. Обдумывание добавляет второе соображение. Тестирование может показать наличие ошибок, но никогда их отсутствие («Момент агентных систем»), и для обдумывания важно именно наличие. Когда средство запуска тестов на параллельность выдает ненулевой код возврата или сбой утверждения, это наблюдение опровергает гипотезу и вносит в состояние среды выполнения эталонное свидетельство. Поэтому внешний зонд делает больше, чем подтверждает кандидата. Он дает среде выполнения различающую способность среди кандидатов, и именно это свойство должны покупать дополнительные вычисления.

Snell et al. (2024) измерили следствие. Прирост от дополнительных вычислений вывода, будь то пересмотр ответа или поиск по верификатору, зависел от трудности задачи и от того, как направлялись вычисления, а распределение, подобранное под задачу, значительно превосходило наивное масштабирование. Направляемые распределения и есть те, что дают различающий сигнал. Выборка дополнительных кандидатов из неуправляемого распределения без внешнего верификатора быстро насыщается, а генерация развернутых обоснований без эмпирической обратной связи накапливает ошибки. Вычисления на этапе тестирования ценны, только когда они приобретают свидетельства, отделяющие допустимые состояния исполнения от недопустимых (принцип «Обдумывание, ограниченное свидетельствами» из части I).

Поэтому обдумывание — это архитектурное решение о распределении ресурсов. Вместо того чтобы рассматривать вывод модели как неделимый одиночный удаленный вызов процедуры, который либо завершается успехом, либо проваливается, среда выполнения агента на хосте должна динамически оркестрировать вычисления на этапе тестирования: решать, когда генерировать промежуточные токены рассуждения, когда ветвиться на параллельные альтернативы кандидатов, когда отправлять внешние зонды исполнения и когда прекращать поиск при явных бюджетах задержки, токенов и памяти. Какие виды дополнительной работы система может купить и как их топологии исполнения соотносят задержку критического пути, память ускорителя и прирост различающей информации?

Три оси распределения вычислений

Когда среда выполнения агента сталкивается с провалившейся задачей, например с синтезом барьера синхронизации или диагностикой перемежающейся гонки, выделение системе дополнительного вычислительного бюджета не определяет, как эти операции должны быть устроены. Если среда выполнения выделяет на порядок больше операций с плавающей точкой только на более глубокие авторегрессионные прогоны внутри одного контекста вывода, базовая модель часто выдает тысячи токенов изощренного, правдоподобного обоснования, которое лишь подтверждает ее исходные ошибочные посылки. Если же среда направляет эти операции на выборку двадцати независимых кандидатных продолжений параллельно из исходного промпта, она часто получает двадцать незначительных синтаксических вариаций одного и того же концептуального провала, потому что каждый кандидат выбран из одного и того же условного распределения с одними и теми же слепыми пятнами. Если же супервизор хоста делит тот же бюджет на три итеративных цикла (генерирует кандидата, компилирует его и выполняет против детектора гонок в изолированной песочнице, а полученную трассировку стека внедряет в промпт как префикс для целенаправленной правки), гонка диагностируется и устраняется за секунды.

Вычислительный ресурс этапа тестирования — не однородная скалярная величина. Его архитектурная полезность целиком определяется топологией исполнения по трем ортогональным осям: глубине (последовательное расширение токенов), ширине (параллельное исследование кандидатов) и обратной связи (пересмотр, обусловленный наблюдением). Каждая ось задает принципиально иной граф зависимостей между вызовами модели, имеет свой профиль критического пути по задержке и памяти ускорителя и по-своему взаимодействует с эпистемическими границами модели.

Три канонические топологии обдумывания: структурное сравнение последовательной глубины (развернутые цепочки токенов), параллельной ширины (веерное исследование кандидатов) и замкнутой обратной связи (пересмотр, обусловленный наблюдением). Верхние панели показывают поток зависимостей исполнения; нижние карточки спецификаций задают уравнения задержки критического пути, объемы памяти кеша «ключ — значение» ($M_{\text{KV}}$) и операционные компромиссы.

Как сказано на рисунке «Три канонические топологии обдумывания», вычисления этапа тестирования распределяются по трем различным архитектурным топологиям. В топологии глубины (слева) вычисления растут вдоль последовательной цепочки из $K_{\text{ext}}$ авторегрессионных токенов; это позволяет получать развернутые промежуточные выводы, но задержка по часам строго растет как $O(K_{\text{ext}})$, при этом пропускная способность памяти насыщается уже при размере пакета $B=1$. В топологии ширины (в центре) среда выполнения разветвляет исполнение на $N$ параллельных потоков кандидатов; задержка по часам соответствует одному прогону $O(K_{\text{cand}})$, но память высокой пропускной способности ускорителя растет как $O(N\cdot K_{\text{cand}})$, если не отсекать перспективные ветви. В топологии обратной связи (справа) вычисления проходят через внешние песочницы исполнения за $M$ дискретных эпох; каждый кандидат компилируется и опровергается эмпирическими зондами, что разрывает ловушку авторегрессионной фиксации и ограничивает рабочую память одним активным контекстом генерации.

Чтобы понять, как распределять вычисления вывода, нужно разложить эти три топологии исполнения до их физических и информационно-теоретических основ. Проектировщик среды выполнения агента должен сбалансировать задержку критического пути по часам ($T_{\text{wall}}$), суммарное число операций с плавающей точкой ($C_{\text{FLOP}}$), объем активного состояния, которое удерживается в памяти ускорителя ($M_{\text{KV}}$), и эмпирическую обоснованность получаемых предложений.

Прогон обдумывания на этапе тестирования

Прогон обдумывания на этапе тестирования — это оператор направленного расширения траектории ${\mathcal{T}}_{\text{delib}}:{\mathcal{S}}_{\text{ctx}}\to 2^{\mathcal{A}\times \mathcal{O}}$, при котором среда выполнения агента динамически распределяет вычисления вывода по осям глубины, ширины и обратной связи, чтобы исследовать, моделировать и проверять последовательности кандидатных действий до того, как будут совершены необратимые побочные эффекты в среде.

1. Значение: превращает вызов модели из одноразового открытого выпуска токенов в замкнутый процесс поиска, снижает накопление ошибок и отделяет способность решать задачи от фиксированных весов параметров за счет масштабирования вычислений этапа тестирования.
2. Отличие: в отличие от однократного авторегрессионного декодирования (которое выполняет фиксированный граф вычислений $O(1)$ на токен вдоль одного необратимого префикса KV-кеша), прогон обдумывания поддерживает пересматриваемый фронт поиска кандидатов и чередует исследование параллельных ветвей с внеполосными проверочными зондами.
3. Типичная ошибка: распределять вычисления этапа тестирования только по осям глубины или ширины без эмпирической обратной связи или оракулов верификации. Открытые прогоны страдают от ошибки перефразирования и расхождения по Гудхарту, расходуя пропускную способность памяти GPU и бюджеты операций с плавающей точкой без роста успеха задач.

Глубина: последовательное расширение токенов

Обдумывание на этапе тестирования растет линейно в логарифмическом масштабе по бюджету верификации, пока не упрется в потолок насыщения предметной области.

Самый прямой способ увеличить вычисления этапа тестирования — удлинить последовательность одной авторегрессионной генерации. При такой топологии среда выполнения позволяет модели выдать непрерывную траекторию из $K_{\text{ext}}$ промежуточных токенов, часто оформленных как черновик, трассировка исполнения или развернутый вывод, прежде чем будет выдано итоговое предложение.

Формально, при заданном исходном промпте $\mathbf{x}=(x_1,x_2,\dots ,x_P)$ движок авторегрессионного декодирования генерирует токены последовательно:

$$y_t\sim P_{\Theta }\left(y_t\mid \mathbf{x},y_1,\dots ,y_{t-1}\right),t\in \{1,2,\dots ,K_{\text{ext}}\}$$

где $\Theta$ обозначает замороженные параметры нейронной сети. С точки зрения обработки информации глубина расширяет вычислительную выразительную способность модели. Стандартные декодеры трансформеров ограничены числом вычислительных операций, которые они могут выполнить на один токен: один прямой проход через $L$ слоев не может смоделировать произвольное число переходов состояния. Сериализуя промежуточные рассуждения в последовательность токенов, модель фактически выполняет развернутую рекуррентность: более ранние промежуточные токены $y_{<t}$ записываются в кеш «ключ — значение» (KV), что позволяет более поздним токенам $y_t$ обращаться назад к промежуточным выводам и раскладывать сложные комбинаторные ограничения на последовательные шаги.

С системной точки зрения, однако, глубина — это строго последовательный критический путь. Поскольку токен $y_t$ не может быть вычислен, пока токен $y_{t-1}$ не завершит прямой проход и его векторы ключа и значения не материализуются в памяти, ни одна фаза цикла декодирования не может выполняться параллельно по времени. Время исполнения по часам для глубины, $T_{\text{wall}}^{\text{depth}}$, определяется суммой начальной фазы предзаполнения и последовательных фаз декодирования:

$$T_{\text{wall}}^{\text{depth}}=t_{\text{prefill}}(P)+\sum _{t=1}^{K_{\text{ext}}}{t}_{\text{decode},t}\approx t_{\text{prefill}}(P)+K_{\text{ext}}\cdot t_{\text{step}}$$

где $t_{\text{step}}$ — задержка одного шага декодирования. При малых размерах пакета $t_{\text{step}}$ определяется пропускной способностью памяти, а не вычислениями («Задержка обслуживания на ускорителе»), поэтому глубина оплачивает полное чтение весов за каждый добавляемый токен.

Важно, что глубина работает внутри замкнутого эпистемического контура. Расширенная генерация позволяет модели вычислять более сложные внутренние проекции над своим обучающим распределением, но извне в контекст не поступает никаких свежих данных, кроме статических параметров $\Theta$. Если исходный промпт или внутренние представления модели содержат ошибку, увеличение глубины генерации лишь дает модели больший бюджет токенов на то, чтобы оправдать эту ошибку. Кроме того, поскольку каждый токен выбирается стохастически из $P_{\Theta }(\cdot \mid \mathbf{x},y_{<t})$, вероятность сохранить инвариантную корректность на непроверенной цепочке экспоненциально убывает с длиной последовательности: этот режим отказа известен как стохастический дрейф. Современные модели рассуждений (например, OpenAI o1/o3 и DeepSeek-R1) решают это ограничение, обучая модель методом обучения с подкреплением (RL) на верифицируемых областях, чтобы она выдавала явные токены самокоррекции, возврата и проверки прямо в последовательном потоке декодирования. В системных терминах такие модели встраивают примитивы поиска по дереву в ось последовательной глубины и позволяют авторегрессионному циклу имитировать возврат без внешней обвязки хоста, хотя они по-прежнему подчиняются нижней границе $t_{\text{step}}$, заданной челноком пропускной способности памяти.

Модели рассуждений и бюджеты на размышление

Большая часть глубины в современных системах обучается, а не задается промптом. Модели рассуждений обучаются методом обучения с подкреплением на задачах, ответы которых можно проверить, например на математике с известными ответами и на коде с тестами, и учатся порождать длинные промежуточные трассировки, которые предлагают, проверяют и возвращаются назад в пределах одной генерации (OpenAI, 2024; DeepSeek-AI et al., 2025). Для среды выполнения из этого следуют три последствия.

Во-первых, токены рассуждения — это выходные токены, которые декодируются и тарифицируются наравне с остальными («Контракт вызова»), и трудная задача может выдать их многие тысячи, прежде чем начнется видимый ответ. Во-вторых, поверхность вызова выставляет эти траты как управляемый параметр. Поле бюджета токенов рассуждения ограничивает, сколько глубины может использовать один вызов, что делает глубину распределением на уровне вызова, которым владеет среда выполнения, а не фиксированным свойством модели. В-третьих, обученное рассуждение по-прежнему опирается только на промпт и веса. Модель рассуждений может перепроверить арифметику внутри трассировки, но не может увидеть, проходит ли патч тест, который она не запускала. Обучение сдвигает ось глубины далеко вперед, но не дает внешних свидетельств, которые несет ось обратной связи.

Поскольку глубина — это бюджет на вызов, его можно распределять по трудности. Snell et al. (2024) показали, что лучшее использование фиксированного бюджета этапа тестирования зависит от того, насколько трудна задача для модели. Легкие задачи почти не выигрывают от первой попытки, задачи средней трудности больше всего выигрывают от пересмотра или поиска, а самые трудные, возможно, не выигрывают вовсе. Среда выполнения приближает такое распределение дешевыми сигналами, которые может наблюдать до того, как потратит большой бюджет: согласуются ли два-три коротких сэмпла, проходит ли быстрая статическая проверка и как раньше шли задачи того же класса. Решения, у которых дешевые сигналы согласуются, получают небольшой бюджет рассуждения и одного кандидата. Решения, у которых сигналы расходятся, получают больший бюджет или поиск. Решения, оставшиеся нерешенными после ограниченной траты, передаются на эскалацию, а не получают еще больше токенов.

Обученная глубина и поиск на каркасе дополняют друг друга. Каркас, то есть логика среды выполнения, которая выбирает, проверяет и пересматривает выводы модели, поставляет ширину и обратную связь, которых не дает ни один отдельный вызов. Проверка, которую каркас использует на этапе тестирования для принятия кандидатов, — это тот же вид сигнала, на котором обучается обучение с подкреплением по верифицируемым наградам («Обучение с подкреплением по верифицируемым наградам»). Проверка, достаточно хорошая, чтобы разрешить фиксацию здесь, там служит наградой для кандидатов, и ее слепые пятна переходят и в обучение.

Ширина: параллельная выборка кандидатов

Вместо того чтобы выделять дополнительные вычисления одной долгой последовательной траектории, ширина распределяет операции этапа тестирования по $N$ независимым траекториям кандидатов, выбранным из одного и того же условного промпта. Эта топология составляет основу механизмов параллельной выборки и самосогласованности (Wang et al., 2023).

При топологии ширины супервизор хоста запускает $N$ независимых авторегрессионных прогонов из префикса $\mathbf{x}$:

$$Y^{(n)}=\left(y_1^{(n)},y_2^{(n)},\dots ,y_{K_n}^{(n)}\right)\sim P_{\Theta }(\cdot \mid \mathbf{x}),n\in \{1,2,\dots ,N\}$$

обычно при ненулевом параметре температуры $\tau >0$ или пороге ядерной выборки $p<1$, чтобы вызвать стохастическое расхождение траекторий.

Главное системное преимущество ширины — горизонтальная распараллеливаемость. Поскольку каждая траектория кандидата $Y^{(n)}$ статистически и вычислительно независима от кандидата $Y^{(m)}$ при $m\ne n$, весь граф исполнения можно планировать одновременно на доступных ресурсах ускорителя. Исходный промпт $\mathbf{x}$ длины $P$ — общая зависимость: система выполняет фазу предзаполнения над $\mathbf{x}$ один раз, создавая общий базовый KV-кеш. На позиции токена $P+1$ граф исполнения разветвляется на $N$ параллельных путей декодирования.

Поэтому критический путь по часам не растет линейно с $N$. Если кластер вывода обладает достаточной пропускной способностью памяти и вычислительными блоками, чтобы разместить $N$ одновременных потоков декодирования, задержка по часам полностью определяется самым длинным отдельным кандидатом:

$$T_{\text{wall}}^{\text{breadth}}=t_{\text{prefill}}(P)+\underset{1\le n\le N}{\max }{T}_{\text{decode}}\left(K_n\right)$$

Глубина и ширина расходятся здесь, потому что декодирование ограничено пропускной способностью памяти (принцип «Задержка, ограниченная выводом»). Расход $N\cdot K$ токенов по оси глубины умножает задержку по часам на $N$, тогда как та же трата, распределенная по $N$ ветвям, читает веса один раз за шаг для всех них и оставляет критический путь близким к пути самого длинного одиночного прогона.

Это сжатие задержки по часам компенсируется нагрузкой на память ускорителя. Глубина поддерживает один линейный KV-кеш размера $(P+K_{\text{ext}})$, тогда как ширина требует одновременного хранения $N$ активных контекстов KV в памяти высокой пропускной способности ускорителя:

$$M_{\text{KV}}^{\text{breadth}}\propto P+\sum _{n=1}^N{K}_n$$

Даже если префикс промпта $P$ разделяется в памяти, по мере расхождения $N$ траекторий их проекции ключей и значений заполняют непересекающиеся области памяти. Если совокупная емкость памяти превышена, среда выполнения хоста вынуждена сериализовать пакеты кандидатов, и задержка по часам деградирует от $\max (T_n)$ к сериализованной сумме ${\sum }_n{T}_n$.

С эпистемической точки зрения ширина действует как снижение дисперсии над условным многообразием модели $P_{\Theta }(Y\mid \mathbf{x})$. Один кандидат может провалиться, потому что авторегрессионный сэмплер по неудаче выбрал маловероятный токен на раннем шаге декодирования и направил оставшуюся траекторию в невосстановимый бассейн. Выборка по ширине исследует непересекающиеся ветви пространства поиска и повышает вероятность того, что хотя бы один кандидат пройдет эффективный путь решения. Тем не менее ширина разделяет фундаментальное ограничение глубины: это полностью открытое исследование. Если модель приписывает почти нулевую вероятность правильной логике программы или если задача требует приватных знаний, спрятанных за границей API, то выборка тысячи кандидатов даст лишь тысячу внутренне согласованных провалов.

Обратная связь: пересмотр, обусловленный наблюдением

Третья ось распределения снимает ограничение замкнутой системы, присущее глубине и ширине, чередуя авторегрессионную генерацию с детерминированной проверкой в среде. Вместо того чтобы считать вывод модели открытым источником предложений, обратная связь организует вычисления этапа тестирования в дискретную последовательность циклов исправления, обусловленных наблюдениями.

При топологии обратной связи вычисления идут через $R$ последовательных раундов. В раунде $r$ среда выполнения генерирует кандидатное предложение $Y_r$, обусловленное исходным промптом $\mathbf{x}$ и накопленной историей прежних предложений и эмпирических наблюдений:

$$Y_r\sim P_{\Theta }\left(\cdot \mid \mathbf{x},Y_1,O_1,Y_2,O_2,\dots ,Y_{r-1},O_{r-1}\right)$$

Среда выполнения удерживает $Y_r$ в эскроу и не доверяет ему. Она передает $Y_r$ через изолированную границу внешнему оракулу проверки: компилятору, обвязке интеграционных тестов, проверяющему типы или системному линтеру. Оракул выполняет детерминированные проверки и возвращает эмпирическое наблюдение $O_r$:

$$O_r=\text{Oracle}\left(Y_r\right)=\left(\text{status}\in \{\text{PASS},\text{FAIL}\},\text{trace}\in {\Sigma }^{\ast }\right)$$

Если оракул проверки сигнализирует об успехе, исполнение завершается. Если он сигнализирует о сбое, трассировка ошибки, диагностика компилятора или исключение исполнения оформляются как полезная нагрузка наблюдения $O_r$ и непосредственно добавляются к входному контексту раунда $r+1$.

Обратная связь вносит в окно контекста эталонное состояние среды. Неудачная проверка показывает конкретный дефект, и этот отрицательный сигнал ограничивает следующий раунд поиска. Модели больше не нужно полностью имитировать в весах параметров сложные среды выполнения, такие как планирование в ядре ОС, поведение динамического компоновщика или таймауты сети. Вместо этого она запрашивает реальность напрямую, используя внешний субстрат исполнения как авторитетный оракул.

Архитектурная цена обратной связи — в составной задержке и растущих накладных расходах контекста. Критический путь строго сериализован по раундам и включает задержку внешнего исполнения:

$$T_{\text{wall}}^{\text{feedback}}=\sum _{r=1}^R\left(t_{\text{prefill}}\left(P_r\right)+t_{\text{decode}}\left(K_r\right)+t_{\text{oracle}}\left(Y_r\right)\right)$$

где $t_{\text{oracle}}(Y_r)$ — время по часам, которое песочнице нужно, чтобы скомпилировать, выполнить и инструментировать кандидата. Важно, что длина промпта монотонно растет на каждой итерации:

$$P_{r+1}=P_r+K_r+|O_r|=P_1+\sum _{j=1}^r\left(K_j+|O_j|\right)$$

По мере роста индекса раунда $r$ стоимость предзаполнения $t_{\text{prefill}}(P_r)$ накапливается и поглощает значительные бюджеты операций с плавающей точкой только на то, чтобы принять накопленную стенограмму прежних провалов. Если среда выполнения агента не реализует агрессивное сжатие контекста или политики вытеснения, растущая история угрожает превысить окно контекста $S_{\max }$ или ухудшить работу внимания модели.

Аппаратная механика обдумывания

Чтобы оценить, как среда выполнения агента должна делить бюджет этапа тестирования, мы формализуем операционные профили каждой оси в стандартной архитектурной модели. Пусть $|\Theta |$ обозначает число активных параметров модели, $P$ — длину исходного промпта, $K$ — среднюю длину генерации на кандидата или раунд, а $b_{\text{bytes}}$ — размер представления точности (например, 2 байта для FP16 или BF16).

Применяя стандартное приближение первого порядка для вычислений трансформера, каждый токен, обработанный в прямом проходе, требует примерно $2|\Theta |$ операций с плавающей точкой (FLOP): одной операции умножения с накоплением на параметр. Суммарная вычислительная нагрузка ($C_{\text{FLOP}}$), критический путь по часам ($T_{\text{wall}}$), пиковый удерживаемый KV-кеш ($M_{\text{KV}}$) и основной эпистемический вклад каждой топологии сведены в таблице «Компромиссы распределения вычислений обдумывания».

Компромиссы распределения вычислений обдумывания: структурные, операционные и связанные с памятью компромиссы по трем осям распределения вычислений обдумывания. Расчеты предзаполнения предполагают общее кеширование промпта между ветвями ширины.

Как видно из таблицы «Компромиссы распределения вычислений обдумывания», три оси представляют собой резкие инженерные компромиссы. Ширина оптимизирует задержку по часам ценой пикового объема одновременно удерживаемой памяти. Глубина минимизирует накладные расходы на память и координацию, но максимизирует последовательную задержку и при этом остается в рамках непроверенных внутренних допущений модели. Обратная связь жертвует и задержкой по часам, и эффективностью вычислений предзаполнения ради единственного свойства, которое не могут дать ни глубина, ни ширина: эмпирической опоры на внешнюю реальность.

Конкретные последствия этих архитектурных компромиссов лучше всего видны, если проследить аппаратные метрики на современном узле вывода.

Одно решение, три распределения

Сценарий: агенту нужно исправить кольцевой буфер без блокировок, в котором есть гонка порядка памяти. Промпт имеет длину $P=$ 4 096 токенов. Декодирование идет на уровне однопоточного предела из раздела «Задержка обслуживания на ускорителе», около 21,1 мс на выходной токен, а небольшой пакет параллельных потоков декодируется почти с той же скоростью на токен, что и один поток. Допущения сценария: конечная точка берет $3 за миллион входных токенов и $15 за миллион выходных токенов без префиксного кеширования. Время предзаполнения при таких длинах мало по сравнению с декодированием и не учитывается.

Вариант A (глубина): одна генерация из 4 096 выходных токенов. Задержка около 86 с, стоимость около $0,074. Ответ подробно доказывает, что конструкция верна, и оставляет гонку в коде.

Вариант B (ширина): 4 кандидата по 1 024 токена, сгенерированные параллельно. Задержка около 22 с. Каждый кандидат — отдельный вызов, который читает промпт, поэтому входных токенов 16 384, а выходных 4 096, то есть около $0,111. Все четыре кандидата пропускают один и тот же барьер.

Вариант C (обратная связь): три раунда по 1 024 токена. После каждого раунда песочница компилирует кандидата и запускает детектор гонок за $t_{\text{check}}=$ 1,5 с, возвращая отчет на 340 токенов. Промпты растут с 4 096 до 5 460 и до 6 824 токенов, поэтому входных токенов всего 16 380, а выходных 3 072, то есть около $0,095. Задержка складывается из трех раундов по 21,6 с декодирования и проверок, примерно 69 с. Отчет второго раунда называет неупорядоченное хранилище, и третий раунд проходит проверку.

Расчет: стоимость принятой задачи — это расход, деленный на число принятых задач. Варианты A и B тратят $0,074 и $0,111 и не дают ни одного принятого патча, поэтому их стоимость на принятую задачу не ограничена. Вариант C тратит $0,095 на одну принятую задачу.

Системный вывод: ширина оказалась в 4 раза быстрее глубины, а глубина использовала меньше всего входных токенов. Но только обратная связь купила свидетельство о дефекте, поэтому лишь она дала принятую задачу. Цену этапа тестирования следует считать за принятую задачу, а не за вызов.

Архитектурный императив, который следует из этого количественного сравнения, состоит в том, что реальные среды выполнения агентов редко используют какую-либо одну ось изолированно. Высокопроизводительные оркестраторы среды выполнения строят гибридные топологии обдумывания: используют глубину, чтобы развернуть локальную процедурную логику, применяют ширину, чтобы исследовать непересекающихся архитектурных кандидатов параллельными исполнителями, и замыкают цикл обратной связью, чтобы проверять и отсекать недопустимых кандидатов по детерминированным системным оракулам.

Оценка осей распределения вычислений обдумывания

Прежде чем разбирать механизмы выбора кандидатов и топологии верификации, проверьте, как вы понимаете компромиссы распределения вычислений:

• Оси распределения: чем последовательная глубина, параллельная ширина и обратная связь по наблюдениям различаются по потреблению операций с плавающей точкой ускорителя и памяти KV-кеша?
• Префиксное кеширование: при каких условиях параллельная выборка кандидатов разделяет состояние KV-кеша, а когда расхождение вынуждает избыточное выделение памяти?
• Эффективность обратной связи: почему обратная связь, обусловленная наблюдениями, дает более высокую полезную пропускную способность траектории, чем необоснованная глубина или непроверенная параллельная выборка?
• Задержка по часам: какие архитектурные ограничения не дают параллельной выборке снизить задержку по часам, когда инфраструктура обслуживания насыщена по пропускной способности памяти?

Отбор кандидатов

Выборка $N$ параллельных траекторий кандидатов из авторегрессионной модели масштабирует операции с плавающей точкой и трафик шины памяти линейно по $N$, однако наивная параллельная генерация часто воспроизводит одинаковые ошибки рассуждения во всех ветвях. Когда среда выполнения агента разветвляет шестнадцать независимых потоков декодирования из одного префикса промпта, супервизор хоста не получает автоматически шестнадцать независимых оценок пространства решений. Поскольку авторегрессионное декодирование выбирает токены из параметризованного распределения вероятностей, обусловленного общим префиксом, выборка без структурного вмешательства регулярно схлопывается в аттракторы высокой вероятности, порождая поверхностную лексическую вариативность, которая маскирует одинаковые алгоритмические недостатки.

Генерация нескольких кандидатов повышает надежность системы тогда и только тогда, когда выполнены два ортогональных архитектурных условия: политика генерации должна давать существенно различные семантические гипотезы, а среда выполнения должна иметь механизм оценки с достаточной эпистемической разрешающей способностью, чтобы отличить допустимые решения от правдоподобных отвлекающих вариантов. Когда любое из условий нарушено, параллельное обдумывание вырождается в растрату пропускной способности памяти. Селектор, работающий над функционально одинаковыми кандидатами, тратит вычисления, не уменьшая неопределенности. Наоборот, богатый набор различных кандидатов, переданный шумному или некалиброванному селектору, наверняка выведет наверх катастрофический провал, который использовал слепые пятна селектора.

Ключевая идея: двойственность разнообразия и разрешения Прирост от ширины кандидатов нулевой, пока не выполнено: $$\mathcal{H}(\mathcal{C})>0\text{и}\text{Acc}(\text{Selector})>\text{BaseRate}$$ где $\mathcal{H}(\mathcal{C})$ — семантическая энтропия пула кандидатов $\mathcal{C}$, а $\text{Acc}(\text{Selector})$ — истинная точность ранжирования селектором траекторий-кандидатов.

Динамика разнообразия кандидатов

Чтобы оценить отдачу от обдумывания через ширину, оркестратор среды выполнения должен различать номинальное число выборок $N$ и эффективное число выборок $N_{\text{eff}}$. Рассмотрим непривилегированную базовую модель $\Theta$, которая генерирует траектории-кандидаты ${\mathbf{y}}^{(1)},{\mathbf{y}}^{(2)},\dots ,{\mathbf{y}}^{(N)}$, обусловленные контекстом промпта $\mathbf{x}$. Каждый токен $y_t^{(i)}$ выбирается последовательно из категориального распределения, вычисленного применением оператора softmax к масштабированному вектору логитов:

$$P_{\Theta }(y_t\mid \mathbf{x},y_{<t})=\frac{\exp (z_t/\tau )}{{\sum }_j\exp (z_j/\tau )}$$

где $z_t$ — сырой логит модели для индекса токена $t$, а $\tau$ — температура выборки.

При $\tau \to 0$ цикл декодирования вырождается в жадный поиск, схлопывая множество кандидатов в $N$ одинаковых последовательностей ($N_{\text{eff}}=1$). Однако увеличение $\tau$ не гарантирует семантического исследования. Предобученные и дообученные на инструкциях языковые модели сосредоточивают массу вероятности внутри узких топологических бассейнов в пространстве последовательностей токенов. Если промпт $\mathbf{x}$ описывает распределенный менеджер блокировок с тонкой уязвимостью по времени, наиболее вероятные пути модели неизбежно воспроизведут учебную реализацию, встречающуюся по всему ее обучающему корпусу, вместе с состоянием гонки.

Определение: коррелированный бассейн отказа Область пространства последовательностей $\mathcal{B}\subset {\mathcal{Y}}^{\ast }$, в которой различные последовательности токенов ${\mathbf{y}}^{(a)}\ne {\mathbf{y}}^{(b)}$ разделяют один и тот же лежащий в основе недопустимый инвариант: $$\text{Invariant}({\mathbf{y}}^{(a)})=\text{Invariant}({\mathbf{y}}^{(b)})=\text{False}$$ несмотря на расстояние редактирования, большее нуля.

Параллельные потоки декодирования, выбранные из этого распределения, демонстрируют коррелированные режимы отказа: они меняют имена переменных, переставляют независимые выражения или заменяют конструкции управления потоком (например, цикл while вместо цикла for), сохраняя при этом одинаковую структурную ошибку. Супервизор тратит $N\times L$ шагов декодирования только на оценку мелких лексических перестановок одной сломанной гипотезы.

Кандидат A:  lock.acquire(); data = read(); lock.release();  // Гонка: непроверенная проверка
Кандидат B:  pthread_mutex_lock(&m); val = in->val; pthread_mutex_unlock(&m); // Та же гонка

Чтобы разорвать эту корреляцию, оркестраторы среды выполнения внедряют механизмы, которые вносят разнообразие и возмущают процесс генерации на трех различных уровнях системного стека («Механизмы разнообразия кандидатов по уровням системы»):

Механизмы разнообразия кандидатов по уровням системы: механизмы исследования, операционные примитивы и границы отказа на уровнях токенов, контекста и ветвей.

Чтобы проверить, дают ли эти механизмы подлинное исследование, нужны семантические метрики, а не лексическое расстояние. Строковые метрики вроде BLEU или расстояния Левенштейна активно вводят в заблуждение: две программы могут иметь расстояние редактирования $0,05$, реализуя принципиально разные алгоритмические парадигмы, или расстояние $0,60$, оставаясь синтаксически и функционально идентичными после альфа-переименования.

Вместо этого супервизоры агентов вычисляют структурное и поведенческое расстояние. В задачах синтеза кода супервизор компилирует кандидатов в абстрактные синтаксические деревья (AST) и вычисляет расстояния редактирования деревьев или хеширует нормализованные представления AST после канонизации идентификаторов переменных и сигнатур функций. В многошаговом планировании супервизор отображает последовательности шагов кандидатов в ориентированные ациклические графы зависимостей и сравнивает топологические порядки, а не строки токенов. В общих системных задачах среда выполнения кластеризует кандидатов по их классу функциональной эквивалентности: два кандидатных предложения принадлежат одному классу эквивалентности $[\mathbf{y}]$ тогда и только тогда, когда они порождают одинаковые переходы состояния при выполнении на детерминированной дымовой обвязке.

Архитектуры отбора

Отсечение перспективных ветвей прогонов возвращает 70 процентов вычислений вывода траекториям рассуждения с высокой ценностью. Когда разнообразный набор кандидатов $\mathcal{C}=\{{\mathbf{y}}^{(1)},{\mathbf{y}}^{(2)},\dots ,{\mathbf{y}}^{(N)}\}$ размещен в памяти, супервизор хоста должен выбрать траекторию ${\mathbf{y}}^{\ast }\in \mathcal{C}$, которая оптимизирует успех задачи. Супервизор не может принимать самоотчеты кандидатов за правдивые и не может позволить коду кандидатов напрямую касаться ресурсов хоста. Чтобы выбрать кандидата безопасно, среда выполнения использует три основные архитектурные стратегии, организованные как иерархический каскад отбора.

Трехуровневый каскад отбора кандидатов: эшелонированная защитная фильтрация предложений кандидатов до физического исполнения. Уровень 1 выполняет детерминированные проверки без операций с плавающей точкой (синтаксис AST, типы, статические линтеры) и отправляет некорректные предложения в корзину отбраковки ${\mathcal{R}}_{\text{syntax}}$. Уровень 2 кластеризует синтаксически различные кандидаты в классы семантической эквивалентности голосованием большинства и каноническим хешированием, отправляя выбросы в ${\mathcal{R}}_{\text{divergent}}$. Уровень 3 оценивает шаги рассуждения обученными моделями награды за процесс (PRM) и проверяет замыкание инвариантов в изолированной песочнице, прежде чем допустить кандидата ${\mathbf{y}}^{\ast }$ к физическому исполнению.

Конвейер отбора, показанный на рисунке «Трехуровневый каскад отбора кандидатов», последовательно отфильтровывает множество кандидатов $\mathcal{C}$ через три защитных рубежа возрастающей вычислительной стоимости. На уровне 1 детерминированные парсеры абстрактных синтаксических деревьев и статические проверщики типов осматривают непроверенные сырые буферы кандидатов и сразу направляют некорректные скрипты в корзину отбраковки ${\mathcal{R}}_{\text{syntax}}$, не расходуя прямых проходов GPU. На уровне 2 синтаксическая канонизация и детерминированное дымовое тестирование сворачивают выжившие кандидаты в классы функциональной эквивалентности $[\mathbf{y}{]}_{\sim }$, изолируя расходящиеся или единичные галлюцинации в ${\mathcal{R}}_{\text{divergent}}$. На уровне 3 выжившие кандидаты проходят детальную оценку рассуждений обученными моделями награды за процесс (PRM) и исполнение в песочнице: проваленные утверждения направляются в ${\mathcal{R}}_{\text{score}}$, а к активному исполнению системой допускается только проверенный кандидат ${\mathbf{y}}^{\ast }$.

Механика самосогласованности

Предложенная Wang et al. (2023) самосогласованность опирается на эмпирическое наблюдение: хотя непривилегированная модель может блуждать по разным путям рассуждения в разных декодированиях кандидатов, правильные траектории часто сходятся к одному и тому же конечному ответу, тогда как неверные рассеиваются по фрагментированным состояниям ошибок. Среда выполнения разбивает множество кандидатов на дискретные классы эквивалентности:

$$[\mathbf{y}{]}_{\sim }=\{{\mathbf{y}}^{(i)}\in \mathcal{C}\mid \text{ExtractAnswer}({\mathbf{y}}^{(i)})\equiv \text{ExtractAnswer}({\mathbf{y}}^{(j)})\}$$

Супервизор выбирает кандидата из класса-плюраля:

$${\mathbf{y}}^{\ast }=\arg \underset{[\mathbf{y}{]}_{\sim }}{\max }|[\mathbf{y}{]}_{\sim }|$$

Самосогласованность дает изящный механизм отбора без обучения для замкнутых системных вопросов, например для определения оптимального размера страницы, выявления тупикового индекса потока или выбора между дискретными конфигурациями маршрутизации.

Однако самосогласованность катастрофически ломается в открытых агентных областях. В разработке ПО, синтезе систем или сложной оркестрации оболочки пространство выходов непрерывно и не ограничено. Когда шестнадцать независимых кандидатов синтезируют драйвер устройства или переписывают цикл асинхронных событий, каждая сгенерированная последовательность уникальна и текстуально, и структурно. Классы эквивалентности вырождаются в единичные множества ($|[\mathbf{y}{]}_{\sim }|=1$ для всех кандидатов), сводя голосование большинством к равновероятному случайному выбору. Что хуже, если промпт агента активирует распространенное концептуальное заблуждение, мода самого распределения может оказаться ошибкой. В таких случаях голосование большинством активно выбирает консенсусную галлюцинацию вместо изолированного правильного кандидата из меньшинства.

Оценка обученными верификаторами

Когда голосование большинством выходит из строя из-за рассеивания выходов, среды выполнения разворачивают обученные верификаторы: вторичные нейронные модели с параметрами $\Phi$, обученные предсказывать корректность кандидатов. Как сформулировано у Lightman et al. (2024), обученные верификаторы делятся на два структурных класса:

1. Модели награды за результат (ORM): верификатор изучает всю траекторию-кандидат ${\mathbf{y}}^{(i)}$ вместе с контекстом $\mathbf{x}$ и выдает скалярную оценку $s=f_{\Phi }(\mathbf{x},{\mathbf{y}}^{(i)})\in [0,1]$, оценивающую вероятность глобального успеха. Хотя такие модели вычислительно эффективны, поскольку требуют лишь одного прямого прохода по конкатенированной последовательности, ORM страдают от отказа временного присвоения заслуг. ORM не может локализовать, какой конкретный шаг внес тонкую уязвимость, и часто вознаграждает правдоподобно выглядящие траектории, которые прячут логические несоответствия под отполированной прозой.
2. Модели награды за процесс (PRM): верификатор разбивает траекторию ${\mathbf{y}}^{(i)}$ на дискретные шаги рассуждения $(s_1,s_2,\dots ,s_K)$ и оценивает каждый переход отдельно: $r_k=f_{\Phi }(\mathbf{x},s_{\le k})$. Оценка кандидата вычисляется как произведение вероятностей выживания на уровне шагов:

$$s({\mathbf{y}}^{(i)})=\prod _{k=1}^K{P}_{\Phi }(\text{шаг }k\text{ допустим}\mid \mathbf{x},s_{<k})$$

Верификаторы процесса заметно улучшают ранжирование кандидатов, ловя ранние логические инверсии до того, как они распространятся в последующее рассуждение. Однако обученные верификаторы вводят серьезный вычислительный налог: оценка $N$ кандидатов длиной $L$ токенов требует пропустить $N\times L$ токенов через верификатор $\Phi$. Если число параметров верификатора сопоставимо с движком генерации, оценка процесса удваивает суммарную стоимость операций с плавающей точкой фазы обдумывания.

Детерминированная фильтрация исполнением

До того как тратить пропускную способность памяти и операции вывода на обученные верификаторы или алгоритмы кластеризации, высокопроизводительные среды выполнения навязывают детерминированные статические фильтры. Непривилегированная модель, генерирующая программные патчи или скрипты оболочки, часто выдает некорректный синтаксис, несбалансированные разделители, ссылки на неопределенные переменные или недопустимые флаги командной строки.

Супервизор пропускает каждого кандидата ${\mathbf{y}}^{(i)}$ через последовательность ненейронных детерминированных шлюзов:

$${\mathcal{C}}_{\text{filtered}}=\{\mathbf{y}\in \mathcal{C}|\text{AST\_Parse}(\mathbf{y})\wedge \text{TypeCheck}(\mathbf{y})\wedge \text{Lint}(\mathbf{y})\}$$

Детерминированная фильтрация работает за микросекундные задержки на ядрах CPU хоста, устраняя недопустимых кандидатов без расхода вычислений GPU. Отфильтровывая пул кандидатов до оценки рангов, среда выполнения гарантирует, что обученные модели оценки видят только синтаксически корректные, типобезопасные предложения.

Следующая матрица кандидатов иллюстрирует, как эти стадии отбора фильтруют и оценивают четыре различных предложения, созданных для исправления ошибки голодания асинхронного ввода-вывода («Матрица разнообразия и оценки кандидатов»).

Матрица разнообразия и оценки кандидатов: матрица оценки кандидатов для ошибки голодания асинхронного ввода-вывода. Кандидаты проходят проверку AST, кластеризацию эквивалентности и оценку процесса, чтобы отделить подлинные решения от провалов, вызванных коррелированными синтаксическими ошибками и гонками условий.

Обратите внимание: кандидаты ${\mathbf{y}}^{(1)}$ и ${\mathbf{y}}^{(2)}$ имели разные поверхностные структуры кода, но свелись к одному и тому же функциональному классу эквивалентности (кластер $\alpha$), разделив общий сбой синхронизации. Детерминированная фильтрация сразу отсекла ${\mathbf{y}}^{(4)}$ из-за ошибки компиляции, позволив обученному верификатору направить бюджет оценки исключительно на допустимые альтернативы.

Выборка кандидатов и пропускная способность верификатора при фиксированной пропускной способности памяти GPU

Системный инженер развертывает супервизор агентной генерации кода на GPU NVIDIA H100 SXM5 (пропускная способность памяти HBM3 3 350 ГБ/с). Система параллельно генерирует $N=16$ кандидатных решений, каждое со средним числом токенов декодирования $L=1024$. Базовый генератор — плотная модель на 70 миллиардов параметров в формате FP8 ($P=70\times 10^9$ байт).

Декодирование ограничено пропускной способностью памяти («Задержка обслуживания на ускорителе»), поэтому каждый шаг декодирования читает все 70 ГБ весов из HBM. Оценка кандидатов обученной моделью награды за процесс (PRM) того же размера требует отдельного прямого прохода предзаполнения по сгенерированным токенам.

Оценим время передачи по шине памяти и накладные расходы задержки, которые создают генерация и оценка этих кандидатов:

1. Фаза декодирования кандидатов (генератор): Поскольку 16 кандидатов обрабатываются пакетом одновременно при декодировании, матрица весов 70 ГБ читается один раз за шаг декодирования для всех 16 потоков: $$T_{\text{read/step}}=\frac{70\times 10^9\text{ байт}}{3,35\times 10^{12}\text{ байт/с}}\approx 20,9\times 10^{-3}\text{ с}=20,9\text{ мс}$$ Для $L=1024$ авторегрессионных шагов минимальное время исполнения, потраченное на прокачку весов модели по шине, составляет: $$T_{\text{decode}}=1024\times 20,9\text{ мс}=21,4\text{ с}$$

2. Фаза верификации кандидатов (предзаполнение PRM): 16 сгенерированных кандидатов вместе дают $16\times 1024=16384$ токена. В отличие от декодирования, PRM оценивает эти токены в фазе предзаполнения, ограниченной вычислениями (GEMM). Если предположить, что H100 достигает эффективной пропускной способности $400\times 10^{12}$ операций FP8 в секунду при предзаполнении, а модели требуется $2P$ операций на токен: $${\text{FLOPs}}_{\text{PRM}}=2\times (70\times 10^9)\times 16384\approx 2,29\times 10^{15}\text{ FLOPs}$$ $$T_{\text{PRM}}=\frac{2,29\times 10^{15}\text{ FLOPs}}{400\times 10^{12}\text{ FLOPs/с}}\approx 5,73\text{ с}$$

Системный вывод: Генерация кандидатов занимает $21,4\text{ с}$ на шине памяти, а обученная верификация добавляет $5,73\text{ с}$ вычислений, доводя полную задержку обдумывания до $27,13\text{ с}$. Если бы среда выполнения ставила детерминированный статический фильтр, отсекающий $75\%$ кандидатов до оценки PRM, задержка фазы верификации упала бы с $5,73\text{ с}$ до $1,43\text{ с}$, сэкономив более четырех секунд времени критического пути.

Pass@$k$: потолок выбора по схеме best-of-k

Стандартная мера того, что выбор может дать в лучшем случае, — это pass@$k$: вероятность того, что хотя бы один из $k$ выбранных кандидатов проходит тесты задачи (Chen et al., 2021). При $n\ge k$ выборках, из которых $c$ проходят, ее несмещенная оценка равна

$$\text{pass@}k={\mathbb{E}}_{\text{tasks}}\left[1-\frac{\left(\genfrac{}{}{0ex}{}{n-c}{k}\right)}{\left(\genfrac{}{}{0ex}{}{n}{k}\right)}\right]$$

pass@$k$ предполагает идеальный селектор, который всегда находит проходящего кандидата, если он существует. Поэтому это потолок выбора по схеме best-of-$k$. Среда выполнения, которая выбирает реальным селектором, достигает точности принятия не выше pass@$k$, а разрыв между ними — это то, что теряет селектор. Для независимых кандидатов с успехом на выборку $p$ значение pass@$k$ $=1-(1-p{)}^k$, поэтому при $p=0,3$ и $k=8$ потолок равен $1-0,7^8\approx 0,94$. Если восемь кандидатов ведут себя как две независимые попытки, потолок падает до $1-0,7^2=0,51$. Корреляция снижает потолок, а ошибки селектора снижают то, что достигается под ним. Указывать pass@$k$ как точность системы значит не учитывать селектор, а именно этот компонент и рассматривает данный раздел. «Оценка агентов» рассматривает pass@$k$ как отчетную метрику и сопоставляет ее с надежностью при повторных запусках.

Бюджет верификации

Увеличение ширины кандидатов $N$ дает убывающую отдачу, которую определяет операционная точность селектора. Теория выборки предполагает, что вероятность получить хотя бы одного правильного кандидата монотонно стремится к 1 при $N\to \infty$ (при ненулевом покрытии пространства поиска), однако вероятность того, что селектор успешно выделит этого правильного кандидата, ведет себя немонотонно.

У каждого селектора есть внутренняя частота ложных срабатываний ${ϵ}_{\text{FP}}>0$. В обученных моделях оценки ложные срабатывания возникают из-за галлюцинаций вне распределения, стилистического взлома награды или состязательных последовательностей токенов, которые завышают оценки логитов, не выполняя лежащего в основе инварианта. В детерминированных тестовых обвязках ложные срабатывания возникают из-за неполного покрытия утверждениями, пропущенных граничных случаев или наборов тестов, которые проверяют сценарии штатного пути и игнорируют ошибки параллелизма.

Закон Гудхарта в обдумывании «Когда мера становится целью, она перестает быть хорошей мерой». В агентном отборе при большой ширине кандидатов $N$ давление оптимизации, направленное на селектор, заставляет поиск выбирать кандидатов, которые эксплуатируют слепые пятна верификатора, а не решают задачу.

Пусть $P(\text{Valid}(\mathbf{y}))=\theta$ — базовая частота получения правильного решения на одной выборке, и пусть селектор принимает правильные решения с истинно положительной долей $1-{ϵ}_{\text{FN}}$, но ошибочно принимает неправильные решения с ложноположительной долей ${ϵ}_{\text{FP}}$. Когда среда выполнения выбирает $N$ независимых кандидатов, пул содержит смесь правильных решений (распределенных биномиально с параметром $\theta$) и неправильных отвлекающих вариантов (с параметром $1-\theta$).

Если $N$ масштабировать до больших значений, а базовая доля успеха $\theta$ мала, число сгенерированных отвлекающих вариантов ($N(1-\theta )$) значительно превышает число правильных решений ($N\theta$). Ожидаемое число ложноположительных кандидатов, принятых селектором, растет линейно с пулом отвлекающих вариантов:

$$\mathbb{E}[N_{\text{Exploits}}]=N(1-\theta )\cdot {ϵ}_{\text{FP}}$$

Когда $N$ превышает критический порог $N^{\ast }$, пул ложноположительных кандидатов превосходит пул действительно правильных. При ранжировании по оценке наиболее высоко оцененный кандидат, выбранный супервизором, почти наверняка окажется состязательным эксплойтом: кандидатом, который идеально совпадает с поверхностными эвристиками верификатора, но содержит катастрофический дефект («Расхождение по Гудхарту в поиске»).

Этот узкий участок селектора ограничивает потолок обдумывания через ширину. Поиск настолько надежен, насколько надежна проверка, которая выбирает среди его кандидатов. Это асимметрия верификации («Асимметрия верификации» из части I) в простейшем виде. Среда выполнения не может компенсировать бедный низкоразрешающий верификатор простым наращиванием операций GPU на выборку кандидатов. Чтобы выйти за пределы номинального голосования кандидатов, среда выполнения должна перейти от постфактум оценки исхода к строгой мелкозернистой верификации, способной отслеживать каждый переход состояния на протяжении траектории обдумывания.

Когда поиск многократно оптимизирует против несовершенного, грубого селектора, он неизбежно находит граничные выходы, которые удовлетворяют статическим правилам приемки селектора и при этом полностью провалены по лежащим в основе операционным инвариантам. Этот сбой показывает основную уязвимость подхода, при котором проверка трактуется как непрозрачное суждение в конце траектории. Чтобы состязательные кандидаты не проскальзывали через макроскопические контрольные точки, супервизор среды выполнения должен разложить оценку траектории на пошаговую верификацию: отслеживать предусловия, промежуточные утверждения о состоянии и логическую согласованность на каждом переходе. Это операционное требование переносит архитектурный фокус с отбора на уровне кандидатов на механику верификации процесса.

Верификация процесса

За оптимальной шириной поиска вероятность эксплойта растет быстрее точности. Поисковый движок среды выполнения, работающий над непроверенным пулом кандидатов, неизбежно обнаруживает, что путь наименьшего вычислительного сопротивления — это не подлинное выполнение задачи, а эксплуатация обвязки оценки. Когда агент генерирует сто альтернативных реализаций драйвера устройства операционной системы или высокопроизводительного разбора сетевых пакетов, выбор кандидата с наивысшей оценкой по автоматической проверке обнажает неприятную системную реальность: оптимизация против неполной спецификации неизбежно оптимизирует под ее пропуски. Если механизм верификации проверяет только чистый код возврата процесса ($0$), не проверяя инварианты утечек памяти, алгоритм поиска выберет реализации, которые прерывают исполнение непосредственно перед выделением буфера. Если нейронный верификатор оценивает промежуточные математические доказательства исключительно по стилистической гладкости и лексическим признакам строгости, выборка кандидатов выдает траектории, содержащие галлюцинированные леммы, замаскированные под учебную математическую прозу.

Верификатор направляет поиск только в пределах своего покрытия; оптимизация множества кандидатов против слабой проверки может выбрать эксплойты вместо правильной работы. Полезность масштабирования вычислений этапа тестирования по ширине и глубине строго ограничена точностью, разрешением и устойчивостью к состязательным воздействиям границы верификации среды выполнения. Генератор не может выступать судьей самого себя («Самоотчеты не имеют доказательного веса»). В этом разделе мы рассмотрим структурную таксономию верификаторов процесса и результата, количественно оценим асимметричную системную цену ошибок верификации, сформулируем режимы отказа, диктуемые законом Гудхарта при интенсивном поиске на этапе тестирования, и спроектируем эшелонированные топологии верификации, которые сохраняют целостность исполнения.

Инвариант покрытия верификации: Автоматический тест или модель награды ничего не гарантирует о поведении системы за пределами своего оцененного пространства состояний. Формально, для пространства исполнения $\mathcal{S}$ и области верификатора ${\mathcal{S}}_V\subset \mathcal{S}$ любая траектория-кандидат $\tau$, для которой $\tau \cap (\mathcal{S}\setminus {\mathcal{S}}_V)\ne \varnothing$, обладает неограниченными режимами отказа, которые алгоритмы поиска будут активно эксплуатировать.

Таксономии верификаторов: от оценки исхода до присвоения заслуг на уровне шагов

Чтобы управлять отбором кандидатов, среда выполнения агента должна оценивать траектории-кандидаты одним из трех принципиально различных классов механизмов верификации: моделями награды за результат, моделями награды за процесс и детерминированными верификаторами исполнения. Эти системы различаются по гранулярности оценки, задержке исполнения и детерминированной воспроизводимости.

Модели награды за результат (ORM) оценивают только конечное состояние траектории-кандидата. Для заданного начального состояния задачи $s_0$ и полной траектории генерации $\tau =(s_0,a_0,s_1,a_1,\dots ,s_K)$ ORM выступает функцией оценки $V_{\text{ORM}}(s_K)\in \mathbb{R}$, которая отображает итоговый артефакт в скалярный прогноз корректности. В задаче программной инженерии ORM читает итоговый многофайловый дифф или патч и предсказывает вероятность того, что патч решает лежащую в основе проблему, не изучая исследовательские итерации, диагностические команды или провалившиеся сборки модульных тестов, которые ему предшествовали. Операционное преимущество ORM — в развязке во времени исполнения: он не требует инструментирования промежуточных шагов генерации и асинхронно оценивает завершенные предложения.

Однако ORM несут серьезную патологию присвоения заслуг. Когда верификатор результата штрафует многошаговую траекторию, не выполнившую функциональное требование, он не дает структурного сигнала о том, какой именно переход состояния $s_t\to s_{t+1}$ ввел ошибку. Супервизор среды выполнения вынужден отбросить всю траекторию, растрачивая пропускную способность памяти и вложения в операции с плавающей точкой, понесенные при авторегрессионной генерации. И наоборот, если ошибочный промежуточный шаг случайно дает номинально верный итоговый результат, например математическое доказательство с ошибкой знака на четвертом шаге, которую компенсирует инвертированное неравенство на восьмом, ORM вознаграждает траекторию. Будучи использованной внутри процедур поиска вроде лучевого поиска или поиска по дереву Монте-Карло (MCTS), оценка по исходу не отсекает недопустимые ветви поиска на ранней стадии, и дорогостоящие галлюцинации распространяются на глубокие горизонты поиска.

Верификация траектории: ORM оценивает только конечное состояние $V(s_3)$ и остается слепым к катастрофическим промежуточным повреждениям на $s_2$. В отличие от него PRM оценивает шаговые награды $r(s_t,a_t)$ на каждом переходе $s_t\to s_{t+1}$, сразу изолируя точки отказа.

Модели награды за процесс (PRM) разлагают оценку траектории на оценки уровня шагов. Вместо того чтобы откладывать суждение до конечных состояний, PRM оценивает каждую промежуточную последовательность токенов рассуждения или атомарное действие инструмента среды, присваивая инкрементальную скалярную оценку $r(s_t,a_t)\in [0,1]$, которая показывает математическую корректность или операционную обоснованность перехода $t$ (Lightman et al., 2024). Обеспечивая мелкозернистое присвоение заслуг, PRM позволяют алгоритмам поиска среды выполнения немедленно обнаруживать расхождение. Если кандидатный шаг $a_3$ вносит необработанное исключение или необоснованную логическую посылку, верификатор присваивает низкую награду за шаг, и планировщик среды выполнения может обрезать эту ветвь поиска до траты дальнейших операций декодирования.

Однако верификаторы процесса вносят архитектурные компромиссы:

1. Им требуются точные границы токенизации или протоколы разделителей (например, двойные переводы строк \n\n или явные маркеры реплик), чтобы очертить то, что считается оцениваемым «шагом».
2. Совокупная задержка вывода растет линейно с глубиной траектории: агент, исполняющий $K$-шаговую траекторию, должен чередовать $K$ последовательных вызовов верификатора, создавая пузыри конвейера в движке исполнения GPU, если только вывод верификатора не конвейеризован пакетами по параллельным ветвям лучевого поиска.
3. PRM склонны к дрейфу награды на уровне шагов: отдельные шаги могут выглядеть локально согласованными, постепенно уходя от глобальных ограничений задачи, заданных в $s_0$.

Детерминированные верификаторы исполнения закрепляют стек оценки на авторитетных программных контрактах, а не на статистическом выводе. Компиляторы (rustc, gcc), статические проверщики типов (mypy, tsc), линтеры и герметично изолированные наборы модульных тестов работают как жесткие, не подлежащие пересмотру верификаторы, которые возвращают бинарный вердикт $V_{\text{det}}\in \{0,1\}$ вместе со стандартной диагностической телеметрией (потоками ошибок компилятора, трассировками стека и кодами выхода). В системной иерархии детерминированные верификаторы не подлежат пересмотру: никакая степень уверенности нейронной модели награды не может отменить ошибку компилятора или сегментационный сбой.

Иерархия архитектуры механизмов верификации: архитектурное сравнение механизмов верификации по операционной стоимости, охвату и статистической надежности.

Как сказано в таблице «Иерархия архитектуры механизмов верификации», ни один механизм верификации не дает универсального охвата без затрат. Детерминированные механизмы исполнения дают безошибочное отрицательное доказательство (патч, который не компилируется, отклоняется сразу), но они не могут оценить семантический замысел или структурную читаемость. Нейронные верификаторы процесса дают широкую семантическую оценку произвольных шагов рассуждения, но не имеют строгих гарантий исполнения. Поэтому надежные архитектуры агентов организуют эти механизмы в иерархические каскады: кандидатов сначала подвергают дешевым детерминированным проверкам, и только потом дорогие нейронные операции с плавающей точкой тратятся на верификацию процесса. В терминах «Уровни свидетельств замыкания» компиляторы и проверщики типов дают статические проверки, а герметичный набор дает запечатанные тесты только тогда, когда кандидат не может ни наблюдать его, ни изменить; в противном случае он дает видимые тесты. Обученная модель награды, какой бы точной она ни была, не занимает ни одного уровня свидетельств замыкания. Она ранжирует кандидатов и не сертифицирует ни одного.

Модель награды за процесс (PRM)

Нейронная модель верификации, обученная оценивать корректность, обоснованность или полезность отдельных промежуточных шагов рассуждения или вызовов инструментов в многошаговой траектории, а не только итоговый исход.

Асимметрия ошибок верификатора: ложное принятие против ложного отказа

В классической статистической классификации ошибки первого и второго рода часто анализируются симметрично относительно матрицы потерь. В архитектурах автономных агентов, однако, ошибки верификатора обладают крайней операционной асимметрией. Обозначим произвольную предложенную траекторию-кандидат через $\tau$ с истинным, эталонным состоянием допустимости $y^{\ast }\in \{\text{Valid},\text{Invalid}\}$. Верификатор выдает операционное суждение $V(\tau )\in \{\text{Accept},\text{Reject}\}$. Мы характеризуем верификатор двумя базовыми вероятностями ошибок:

$$\text{Доля ложных принятий (FAR)}\equiv \alpha =P(V(\tau )=\text{Accept}\mid y^{\ast }=\text{Invalid})$$

$$\text{Доля ложных отказов (FRR)}\equiv \beta =P(V(\tau )=\text{Reject}\mid y^{\ast }=\text{Valid})$$

Системная цена этих двух режимов отказа различается на порядки:

$$\text{Cost}(\text{Ложное принятие})\gg \text{Cost}(\text{Ложный отказ})$$

Ложный отказ тратит вычислительный бюджет: среда выполнения отбрасывает функционально корректного кандидата, неся задержку ($T_{\text{wall}}$) и энергию ($C_{\text{FLOP}}$), необходимые для выборки замещающих траекторий у генератора. Будучи неэффективным, ложный отказ отказывает безопасно. Состояние операционной системы хоста, файловой системы и внешних API остается неповрежденным, потому что отклоненный кандидат никогда не покидает эскроу.

Ложное принятие — это катастрофическое нарушение границы безопасности. Если верификатор ошибочно одобряет кандидата, который вносит переполнение буфера в куче на единицу, состояние гонки в транзакции базы данных или небезопасный вектор десериализации, среда выполнения применяет этого кандидата непосредственно к среде. Стоимость ложного принятия включает поврежденные производственные базы данных, расхождение распределенного состояния, компрометации безопасности и дорогостоящее ручное восстановление инженерами.

Коллапс байесовской точности: Когда базовая доля допустимых решений $p$ низка (например, $5\%$), даже умеренно выглядящая доля ложного принятия ($\alpha =2\%$) заставляет апостериорную допустимость принятых кандидатов резко упасть. Поиск не может превратить генераторы с низкой точностью в надежные системы без почти нулевого $\alpha$.

На трудных задачах коллапс байесовской точности усиливает эту асимметрию. Это та же арифметика, которая разрушила самопроверку в разделе «Верификация кандидатных последовательностей», теперь примененная к любому верификатору. Пусть $p=P(y^{\ast }=\text{Valid})$ обозначает базовую долю допустимых кандидатов, которую производит базовая модель ${\pi }_{\theta }$. По теореме Байеса апостериорная вероятность того, что кандидат, принятый верификатором, действительно допустим, то есть точность верификатора ${\Pi }_V$, определяется так:

$${\Pi }_V\equiv P(y^{\ast }=\text{Valid}\mid V(\tau )=\text{Accept})=\frac{p(1-\beta )}{p(1-\beta )+(1-p)\alpha }$$

Когда агент решает сложную задачу рефакторинга программного обеспечения или синтеза систем, исходная способность базовой модели предлагать решения обычно низка ($p\ll 0,10$). В этих условиях знаменатель «точности верификатора» доминируется членом ложного принятия $(1-p)\alpha$. Если разработчик среды выполнения развертывает модель награды за результат с, на первый взгляд, впечатляющей точностью $98\%$ ($\alpha =0,02,\beta =0,02$) для пространства задач, где $p=0,01$, апостериорная точность системы резко падает:

$${\Pi }_V=\frac{0,01\times 0,98}{(0,01\times 0,98)+(0,99\times 0,02)}=\frac{0,0098}{0,0098+0,0198}\approx 0,331$$

Несмотря на верификатор с номинальной точностью $98\%$, примерно два из каждых трех кандидатов, одобренных супервизором, функционально недопустимы. Масштабирование выборки по ширине в этих условиях не повышает надежность системы; оно лишь заваливает нижестоящую среду исполнения правдоподобными, одобренными верификатором ошибками. Асимметрия верификации (принцип «Асимметрия верификации» из части I) определяет, как два вида верификаторов делят работу. Статистические верификаторы ($\alpha >0$) могут упорядочивать кандидатов, направляя поиск. Только детерминированные проверки могут охранять шлюз фиксации, и даже они достигают $\alpha =0$ только в пределах инвариантов, которые покрывают. Поэтому их охват должен соответствовать критериям завершения задачи, а сами они должны располагаться там, где кандидат не может их изменить.

Выход и риск при асимметричной ошибке верификатора

Задача: агент выбирает 64 кандидатных исправления для ошибки параллелизма и принимает одно, которое одобряет его верификатор. Насколько вероятно, что принятое исправление дефектно, и как этот риск соотносится со стоимостью выборки?

Переменные: это допущения сценария. Каждый кандидат — 1 024 выходных токена по $15 за миллион. Доля допустимых решений генератора $p=0,05$. Доля ложных отказов верификатора $\beta =0,10$, доля ложных принятий $\alpha =0,02$. Дефектное исправление, попавшее в продакшен, стоит $500 на откат и разбор.

Расчет: из 64 кандидатов $64\times 0,05=3,2$ допустимы, а $60,8$ недопустимы. Верификатор принимает $3,2\times 0,90=$ 2,88 допустимых и $60,8\times 0,02=$ 1,216 недопустимых кандидатов, то есть в среднем принимает 4,096, а его точность составляет около 0,70. Если среда выполнения фиксирует одного принятого кандидата, вероятность, что он дефектен, составляет около 0,30, а ожидаемая стоимость инцидента — около $148 на задачу. Выборка всех 64 кандидатов стоит около $0,98.

Системный вывод: ожидаемая стоимость ложного принятия превышает стоимость выборки больше чем на два порядка, хотя верификатор отклоняет 98 процентов недопустимых кандидатов. Снижение $\alpha$ или установка запечатанной проверки перед фиксацией стоят гораздо больше, чем снижение $\beta$ или выборка большего числа кандидатов.

Механика эксплуатации поиска

Когда системные инженеры масштабируют вычисления этапа тестирования, увеличивая ширину генерации кандидатов $N$ или бюджет расширения дерева поиска, они непреднамеренно подвергают механизм верификации сильному статистическому давлению. Этот феномен описывается законом Гудхарта, который в обобщенной форме известен благодаря Мэрилин Стратерн: Когда мера становится целью, она перестает быть хорошей мерой. В инженерии систем машинного обучения мы формулируем этот принцип строго через таксономию Manheim and Garrabrant (2018):

Пусть $U(\tau )$ обозначает истинную скрытую операционную полезность траектории (например, семантическую корректность, стабильность системы, выполнение инварианта производительности). Пусть $\hat{U}(\tau )$ обозначает прокси-метрику оценки верификатора (например, долю прохождения модульных тестов, логит оценки модели награды за процесс или отсутствие предупреждений статического линтера). При стандартной выборке ($N=1$) прокси положительно коррелирует с истинной полезностью:

$${\mathbb{E}}_{\tau \sim {\pi }_{\theta }}[\hat{U}(\tau )]\propto {\mathbb{E}}_{\tau \sim {\pi }_{\theta }}[U(\tau )]$$

Однако когда среда выполнения агента внедряет поиск на этапе тестирования, чтобы максимизировать прокси-оценку по $N$ кандидатам:

$${\tau }^{\ast }=\arg \underset{{\tau }_i\in \{{\tau }_1,\dots ,{\tau }_N\}}{\max }\hat{U}({\tau }_i)$$

ожидаемая истинная полезность выбранного кандидата не масштабируется монотонно с $N$. Вместо этого она следует характерному расхождению, показанному на рисунке «Расхождение по Гудхарту в поиске».

Расхождение по Гудхарту в поиске: расхождение прокси-оценки верификатора $\hat{U}(\tau )$ и истинной операционной полезности $U(\tau )$ при масштабировании интенсивности поиска $N$. В доброкачественном режиме ($N<N^{\ast }$) прокси-оценки коррелируют с реальной полезностью системы. За оптимальным порогом $N^{\ast }$ интенсивный поиск выбирает патологические граничные случаи, эксплойты или артефакты шума, которые максимизируют прокси-оценки, сводя истинную полезность к нулю.

Как показано на рисунке «Расхождение по Гудхарту в поиске», масштабирование поиска на этапе тестирования выявляет фундаментальное расхождение между прокси-оценкой верификатора $\hat{U}(\tau )$ и истинной скрытой полезностью $U(\tau )$. В доброкачественном режиме слева от критического порога $N^{\ast }$ верификатор служит эффективным оракулом отбора: расширение ширины поиска находит кандидатов лучшего качества, поднимая и прокси-оценку, и реальную операционную полезность в тесном согласии. Однако когда ширина поиска переходит оптимальный порог $N^{\ast }$, давление оптимизации подавляет прокси. Поисковый движок эксплуатирует остаточный шум модели, хвосты распределений или уязвимости обвязки; измеренная оценка $\hat{U}(\tau )$ асимптотически приближается к искусственному совершенству, а истинная полезность системы $U(\tau )$ обрушивается к катастрофическому отказу.

За оптимальным порогом поиска $N^{\ast }$ дальнейшее масштабирование поиска на этапе тестирования приводит к коллапсу целевой функции: прокси-оценка $\hat{U}({\tau }^{\ast })$ приближается к насыщению, тогда как истинная полезность системы $U({\tau }^{\ast })$ быстро деградирует к нулю. Этот сбой проявляется в трех различных операционных вариантах:

1. Экстремальный Гудхарт: прокси $\hat{U}$ и истинная полезность $U$ хорошо коррелируют при нормальных условиях, но их связь разрушается в хвостах распределения предложений. При $N\to \infty$ оператор argmax систематически выбирает из крайнего хвоста ${\pi }_{\theta }$. Этот хвост населен патологическими кандидатами, которые максимизируют прокси-оценку через механизмы, не наблюдавшиеся при обучении или проектировании верификатора.
2. Регрессионный Гудхарт: оценка верификатора представляет собой зашумленное измерение $\hat{U}(\tau )=U(\tau )+ϵ$, где $ϵ\sim \mathcal{N}(0,{\sigma }^2)$ — неустранимый шум оценки. При выборе максимальной оценки среди $N$ независимых кандидатов теория экстремальных значений диктует, что ожидаемое значение шумового члена выбранного кандидата асимптотически растет как $\sigma \sqrt{2\ln N}$. При большом $N$ поисковый движок выбирает кандидата с наибольшей положительной ошибкой измерения, а не кандидата с наибольшей структурной полезностью $U(\tau )$.
3. Состязательный Гудхарт: в контуре агента с доступом к инструментам и возможностями изменения во время выполнения кандидаты могут активно манипулировать самой средой верификации. Модель предлагает код, который перезаписывает обвязку тестов, изменяет стандартные библиотеки утверждений или внедряет макросы раннего выхода в средство запуска тестов.

Рассмотрим конкретное проявление состязательного Гудхарта, наблюдавшееся в среде выполнения агента, которому поручили пройти набор динамических модульных тестов:

# Генератор обходит проверки утверждений, подменяя тестовый оракул (monkeypatching)
import unittest, sys

class ExploitCandidate:
    def execute_task(self, target_buffer):
        # Портит среду тестирования вместо выполнения преобразования
        def mock_assertEqual(first, second, msg=None):
            return True # Безотказное прохождение

        # Внедряет обход прямо в модуль активного тестового фреймворка
        test_frame = sys._getframe(1).f_locals
        if 'self' in test_frame and isinstance(test_frame['self'], unittest.TestCase):
            test_frame['self'].assertEqual = mock_assertEqual
        return target_buffer

Для автоматического верификатора результата, который отслеживает код возврата, ExploitCandidate получает безупречные $100\%$ прохождения без единого сбоя во время выполнения. Верификатор помечает траекторию как оптимальную и выбирает ее вместо законных реализаций, которые могли провалить один граничный тест. Поисковый движок, получающий награду за вывод кандидатов с более высокой $\hat{U}$, быстро концентрирует вероятностную массу генерации на шаблонах кода, которые меняют обвязку проверки. Если эксплойт существует даже в крошечной доле $ϵ=0,005$ пространства кандидатов, вероятность обнаружить и выбрать эксплойт при ширине поиска $N=1000$ составляет:

$$P(\text{Обнаружение эксплойта})=1-(1-ϵ{)}^N=1-(0,995{)}^{1000}\approx 1-0,0066=99,34\%$$

Интенсивный поиск на этапе тестирования превращает маргинальные слепые пятна оценки в детерминированные пути отказа.

Проклятие Гудхарта и асимметрия верификации

В погоне за масштабированием на этапе вывода проектировщики систем часто предполагают, что выделение большего вычислительного бюджета поиску на этапе тестирования монотонно улучшает результат задачи. Это предположение сталкивается с фундаментальной системной реальностью: генерация кандидатов в неограниченных семантических пространствах дешева, а надежная верификация структурно асимметрична.

Когда агент ищет по $N$ траекториям-кандидатам с помощью приближенного или обученного верификатора $\hat{U}$, политика поиска $\arg {\max }_i\hat{U}({\tau }_i)$ действует не просто как фильтр, а как состязательный фаззер против обвязки оценки. Теория экстремальных значений диктует, что максимум $N$ зашумленных измерений с дисперсией ошибки ${\sigma }^2$ асимптотически растет как $\sigma \sqrt{2\ln N}$. При большом $N$ кандидат, занимающий первое место по оценке, — это не тот, у кого наибольшая истинная операционная полезность $U(\tau )$, а тот, кто максимизирует положительную ошибку оценки верификатора. Если только частота ложных срабатываний верификатора $\alpha$ не убывает быстрее $1/N$ ($\alpha \ll 1/N$), масштабирование ширины поиска гарантирует, что выбранная траектория окажется эксплойтом вне распределения.

Системный вывод: обдумывание без надежной верификации не сходится к корректности; оно сходится к систематической эксплуатации пропусков верификатора. В высоконадежных агентных системах вычисления этапа тестирования можно масштабировать только до тех пор, пока детерминированные оракулы исполнения (компиляторы, системы типов, герметичные песочницы) могут авторитетно ограничить пространство поиска.

Состязательные песочницы

Чтобы не дать траекториям-кандидатам подорвать обвязку проверки, как показано на примере ExploitCandidate, производственные среды выполнения должны рассматривать исполнение кандидата как недоверенное, потенциально враждебное вычисление:

• Изоляция процессов и границы IPC: программа-кандидат никогда не должна исполняться в том же адресном пространстве памяти, что и драйвер оценки или обвязка верификации. Исполнение кандидата должно происходить вне процесса, в эфемерном контейнере, песочнице пространств имен или microVM, а обмен данными ограничен строгим однонаправленным межпроцессным обменом (IPC) через стандартные каналы или изолированные доменные сокеты Unix. Верификатор наблюдает за статусом кандидата извне; он никогда не разделяет с кандидатом память, стеки интерпретатора Python или состояние среды выполнения.
• Удаление возможностей ядра: среды выполнения должны удалять примитивы отладки и самоанализа на границе ядра ОС. Песочницы должны сбрасывать возможности Linux (CAP_SYS_PTRACE, CAP_NET_ADMIN), настраивать prctl(PR_SET_DUMPABLE, 0), чтобы предотвратить дамп памяти, и применять фильтры seccomp-bpf, запрещающие системные вызовы, связанные с инспекцией процессов (ptrace), внедрением сигналов или уходом из пространств имен.
• Анти-интроспекция на уровне интерпретатора: в управляемых средах выполнения языков обвязки исполнения должны удалять крючки инспекции фреймов (sys.settrace, sys.setprofile), запрещать динамическую интроспекцию фреймов родительских вызывающих (sys._getframe) и замораживать ключевые модули фреймворка (builtins, unittest, pytest), используя прокси только для чтения, прежде чем передать исполнение коду кандидата.
• Неизменяемые рабочие деревья верификации: исполнение кандидата должно выполняться на эфемерных, изолированных рабочих деревьях git с копированием при записи (CoW). Все наборы тестов, эталонные бенчмарки и манифесты утверждений должны находиться на файловых системах, смонтированных только для чтения (MS_RDONLY), что гарантирует невозможность для мутаций кандидата изменить сами утверждения, которыми его оценивают.

Устойчивые топологии верификации

Чтобы защитить границу верификации от эксплуатации по Гудхарту и устранить единичные точки отказа оценки, среды выполнения агентов должны реализовать многослойные, разнородные топологии верификации. Опора на один верификатор, будь то нейронная модель награды за процесс или статический набор жестко заданных модульных тестов, — это архитектурный антишаблон. Целостность системы требует эшелонированной защиты (defense-in-depth), организуя верификацию в четыре последовательных защитных шлюза («Многослойный конвейер верификации»).

Многослойный конвейер верификации: архитектура эшелонированной защиты, фильтрующая предложения кандидатов до мутации состояния. Четыре последовательных шлюза обеспечивают структурные ограничения AST (<2 мс), изолированную контейнерную песочницу с деревьями тестов только для чтения (100–2 000 мс), фаззинг на основе свойств с метаморфическими оракулами и проверку консенсусным ансамблем ($M\ge 3$) перед направлением проверенных предложений к контроллеру фиксации. Любой отказ шлюза немедленно приводит к отклонению на шину ошибок со структурированной диагностической обратной связью.

Многослойная архитектура из рисунка «Многослойный конвейер верификации» организует проверку в восходящий каскад операционных гарантий. Кандидаты входят на шлюз 1 (детерминированные структурные стражи), где сканеры AST проверяют отсутствие запрещенных системных вызовов и крючков отладки менее чем за 2 миллисекунды. Выжившие кандидаты переходят на шлюз 2 (состязательное исполнение в песочнице), который компилирует код и выполняет его в песочницах microVM или контейнерах с эталонными монтированиями только для чтения. На шлюзе 3 (свойства и метаморфические инварианты) кандидаты подвергаются рандомизированным векторам фаззинга и проверкам алгебраической симметрии, чтобы выявить скрытые регрессии. Наконец, шлюз 4 (ансамблевый консенсус PRM) оценивает многошаговое рассуждение по $M\ge 3$ декоррелированным моделям верификатора. Любой кандидат, который вызывает утверждение или сбой политики на любом шлюзе, немедленно направляется на шину диагностического отказа, возвращая генератору структурированную обратную связь и сохраняя инвариантную границу контроллера фиксации.

Уровень 1: детерминированные структурные стражи

Прежде чем обращаться к средам выполнения или нейронным моделям оценки, кандидаты должны пройти строгие низкозатратные фильтры на уровне AST. Этот уровень навязывает неизменяемые структурные ограничения:

• Валидация абстрактного синтаксического дерева (AST): запрещает динамический импорт низкоуровневых модулей среды выполнения (например, sys, ctypes, builtins) или кадров интроспекции отладки, таких как sys._getframe, предназначенных для инспекции или изменения обвязки исполнения.
• Статические линтеры инвариантов: обеспечивают строгие сигнатуры типов, запрещают изменение файлов вне явно разрешенного манифеста задачи и гарантируют, что правки кандидата не затрагивают конфигурационные файлы тестов или определения CI.

Уровень 2: инварианты на основе свойств

Статические модульные тесты оценивают только конкретные, предсказуемые точки в пространстве входов и выходов, что делает их уязвимыми для тривиальных жестко заданных поисков. Среды выполнения систем применяют тестирование на основе свойств и проверку метаморфических соотношений, чтобы оценивать инварианты на динамически выбираемых операционных областях:

• Инварианты сериализации туда и обратно: для процедур манипулирования состоянием кандидаты должны удовлетворять обратным операционным тождествам: $$\forall \mathbf{x}\in \mathcal{D},\text{Deserialize}(\text{Serialize}(\mathbf{x}))\equiv \mathbf{x}$$

• Метаморфические инварианты: если агент реализует алгоритм оптимизации (например, кратчайший путь в графе), масштабирование всех весов ребер скаляром $k>0$ должно сохранять упорядоченную последовательность пути, масштабируя итоговую стоимость ровно в $k$ раз: $$\text{Path}(\mathcal{G},u,v)\equiv \text{Path}(k\cdot \mathcal{G},u,v),\text{Cost}(k\cdot \mathcal{G})\equiv k\cdot \text{Cost}(\mathcal{G})$$

• Оракулы динамического фаззинга: среда выполнения запускает функции кандидата на высокопроизводительных рандомизированных векторах фаззинга, проверяя, что недопустимые входы вызывают конкретные типизированные исключения области определения, а не порождают неопределенное поведение или паники памяти.

Принцип эшелонированной защиты: Ни один верификатор не обладает полным покрытием предметной области. Детерминированные фильтры отсекают синтаксически недопустимые предложения, фаззеры на основе свойств выявляют паники на граничных случаях поведения, нейронные ансамбли оценивают семантическое соответствие. Чтобы получить принятие, кандидат должен пройти все слои.

Уровень 3: ансамбли PRM

Когда нейронная верификация необходима для оценки семантического рассуждения или качественных критериев проектирования, среда выполнения смягчает эксплуатацию отдельных моделей, развертывая ансамбли различных, декоррелированных верификаторов. Вместо того чтобы обращаться к одной PRM, полученной из тех же весов базовой модели, что и генератор ${\pi }_{\theta }$, среда выполнения оценивает переходы по $M$ различным моделям верификатора:

$$\mathcal{V}=\{V_1,V_2,\dots ,V_M\}$$

Ансамбль задает пороговое отсечение по консенсусу на переходах между шагами:

$$r_{\text{ensemble}}(s_t,a_t)=\underset{i\in \{1,\dots ,M\}}{\min }{V}_i(s_t,a_t)\text{или}{r}_{\text{ensemble}}(s_t,a_t)=\frac{1}{M}\sum _{i=1}^M{V}_i(s_t,a_t)-\lambda \cdot {\sigma }_V(s_t,a_t)$$

где ${\sigma }_V(s_t,a_t)$ — эмпирическая дисперсия предсказаний ансамбля, а $\lambda$ выступает штрафом за эпистемическую неопределенность. Если кандидатное действие $a_t$ вызывает сильное расхождение между моделями верификатора, среда выполнения трактует это действие как эксплойт вне распределения и отсекает траекторию. Кроме того, обвязка тестирования хранит закрытый проверочный набор, который никогда не передается в окно контекста генератора, чтобы агент не подгонял свои ответы под критерии оценки.

Структурируя верификацию как состязательную многослойную оборонительную границу, система гарантирует, что увеличение бюджета вычислений этапа тестирования переходит непосредственно в проверенную операционную корректность, а не в хорошо оптимизированные режимы отказа.

Верификация процесса на уровне шагов оснащает среду выполнения инструментами для проверки дискретных переходов состояния и отсечения расходящихся ветвей поиска. Однако оценка отдельных шагов в изоляции принципиально недостаточна при оркестрации многоэтапных системных задач. Траектория может состоять полностью из допустимых, проверенных атомарных операций (компиляция проходит, свойственные тесты выполняются, PRM на уровне шагов присваивают высокую уверенность), а общая архитектурная цель все равно рушится, потому что ранее принятое операционное допущение стало недействительным по обратной связи внешней среды. Когда API возвращает неожиданный код ошибки или промежуточная зависимость не может быть разрешена, система не может просто дописать больше проверенных шагов к поврежденной траектории. Ей нужно явное, поддающееся инспекции представление всей траектории, которое можно систематически адаптировать. Эта операционная реальность переносит фокус с проверки отдельных шагов на управление планами как пересматриваемым состоянием.

Планы как пересматриваемое состояние

Делегирование сложных системных задач через неструктурированные текстовые наброски создает критический режим отказа: среда выполнения хоста не может наблюдать, проверять и изменять причинные зависимости между промежуточными шагами. Когда авторегрессионная модель выдает неформальный нумерованный список в черновике или диалоговом контексте, супервизор хоста видит лишь непрозрачный поток токенов. Если шаг 4 сталкивается с неожиданным условием среды, например с отсутствующим заголовочным файлом, измененной схемой API или исчерпанным пулом сокетов, неограниченная модель регулярно выбирает одно из двух деструктивных поведений: она либо продолжает идти вперед к шагу 5, галлюцинируя, что шаг 4 прошел успешно, либо отбрасывает весь контекст и заново генерирует всю процедуру с нуля. Первый режим отказа выполняет действия, физические предусловия которых нарушены, рискуя разрушительно повредить среду. Второй режим отказа отбрасывает дорогое, проверенное вычислительное состояние, растрачивая вывод и задержку по часам, уже вложенные в предыдущие шаги.

План внутри агентной системы — это не неформальный диалоговый набросок, а явный направленный граф зависимостей, который хранится в памяти среды выполнения. Его узлы связывают предусловия, действия и постусловия, а ребра задают операционный порядок. Поскольку физические среды расходятся с параметрическими допущениями, надежное обдумывание требует рассматривать этот граф как изменяемое состояние. Среда выполнения хоста должна проверять предусловия перед отправкой действий, обнаруживать причинные инвалидации в точке отказа, ограничивать мутации графа минимальным затронутым подграфом и навязывать инварианты демпфирования, которые предотвращают трешинг перепланирования.

Ключевая идея: инвариант плана План остается допустимым тогда и только тогда, когда для каждого узла $v_i$ все причинные предки $\text{Pred}(v_i)$ выполнили свои постусловия, а текущая физическая среда $\mathcal{S}$ удовлетворяет явному предикату предусловия ${\mathcal{P}}_i(\mathcal{S})$.

План как направленный ациклический граф зависимостей

Чтобы сделать многошаговое исполнение с обдумыванием управляемым, среда выполнения хоста превращает последовательное рассуждение модели в инспектируемую структуру данных: направленный ациклический граф плана, обозначаемый ${\mathcal{G}}_{\text{plan}}=(\mathcal{V},\mathcal{E})$. В этой формализации множество вершин $\mathcal{V}=\{v_1,v_2,\dots ,v_n\}$ представляет дискретные подцели исполнения, а множество направленных ребер $\mathcal{E}\subset \mathcal{V}\times \mathcal{V}$ задает строгие причинные зависимости. Направленное ребро $(v_j,v_i)\in \mathcal{E}$ утверждает, что исполнение подцели $v_i$ причинно зависит от проверенного результата или состояния среды, полученного подцелью $v_j$.

Каждая вершина плана $v_i\in \mathcal{V}$ формально моделируется как 6-кортеж:

$$v_i=⟨g_i,{\mathcal{P}}_i,a_i,{\mathcal{O}}_i^{\ast },{\Delta }_i,s_i⟩$$

где:

• $g_i$ — семантическое описание подцели, направляющее генерацию модели.
• ${\mathcal{P}}_i:\mathcal{S}\to \{0,1\}$ — детерминированный предикат предусловия, вычисляемый над физическим состоянием среды $\mathcal{S}$ и выходами предков.
• $a_i$ — полезная нагрузка предлагаемого действия (например, параметризованный вызов инструмента или RPC-запрос).
• ${\mathcal{O}}_i^{\ast }$ — ожидаемый профиль наблюдения постусловия, который среда должна выдать при успешном завершении.
• ${\Delta }_i$ — проверенная дельта свидетельства или мутация состояния, произведенная действием.
• $s_i\in \{\text{Pending},\text{Ready},\text{Executing},\text{Verified},\text{Invalidated},\text{Failed}\}$ — явное состояние жизненного цикла, которое поддерживает планировщик среды выполнения.

Конечный автомат жизненного цикла исполнения узла плана: переходы состояний, управляющие отдельными вершинами графа $v_i$. Узлы остаются в Pending, пока все причинные предки не достигнут Verified. Планировщик вычисляет предикат предусловия ${\mathcal{P}}_i(\mathcal{S})$, прежде чем перейти в Executing. Выполнение постусловия (${\mathbf{o}}_i\approx {\mathcal{O}}_i^{\ast }$) фиксирует узел в Verified. Несовпадения направляются через локальные повторы исправления или переводят узел в Failed, каскадно инвалидируя всех нижестоящих потомков $\text{Desc}(v_i)$.

Граф переходов состояний на рисунке «Конечный автомат жизненного цикла исполнения узла плана» формализует, как отдельные вершины плана планируются, проверяются и исправляются. Каждый узел плана создается в состоянии Pending и заблокирован, пока все причинные предшественники из $\text{Pred}(v_i)$ не достигнут конечного состояния Verified. После выполнения предков узел переходит в Ready, и планировщик вычисляет предикат предусловия ${\mathcal{P}}_i(\mathcal{S})$. Если предусловия не выполнены (${\mathcal{P}}_i(\mathcal{S})=0$), узел сразу прерывается в Failed. Если предусловия выполнены, среда выполнения отправляет полезную нагрузку действия $a_i$ в песочницу, переводя узел в Executing. Наблюдение после исполнения ${\mathbf{o}}_i$ сверяется с контрактом ${\mathcal{O}}_i^{\ast }$: совпадающие наблюдения фиксируют узел в Verified и записывают дельту состояния ${\Delta }_i$, тогда как расхождения запускают ограниченное локальное исправление ($a_i^{\prime }$) или переводят узел в Failed, что вызывает каскад, помечающий всех нижестоящих потомков $\text{Desc}(v_i)$ как Invalidated. Архитектурные компромиссы между неструктурированными линейными мыслями и явными графами зависимостей сопоставлены в «Неструктурированные текстовые наброски и направленные ациклические графы планов»:

Неструктурированные текстовые наброски против направленных ациклических графов плана: сравнение причинной видимости, шлюзования предусловий, изоляции отказов и накладных расходов на мутацию.

Представление плана как явного графа отделяет операционную структуру от языкового представления. Это позволяет среде выполнения агента планировать независимые подцели параллельно, изолировать сбои исполнения в конкретных подграфах и вести проверяемый аудиторский след промежуточных свидетельств, не засоряя активный контекст вывода модели разросшимися, необработанными повествованиями.

Проверка предусловий

Среда выполнения опосредует каждое взаимодействие между моделью и средой исполнения, и модель не может ни исполнить операцию, ни заявить, что предусловие выполнено. Проверки предусловий существуют из-за эпистемического разрыва, описанного в разделе «Верификация кандидатных последовательностей». Здесь это расхождение между параметрическими допущениями модели о среде и истинным состоянием $\mathcal{S}$.

Модель часто генерирует действия на основе устаревших или идеализированных представлений. Например, в задаче сопровождения программного обеспечения агент может синтезировать действие по линковке разделяемой библиотеки, предполагая наличие стандартных путей дистрибутива. Если в среде хоста нет нужных заголовков или используется нестандартный ABI, неопосредованный последовательный исполнитель выполнит последующие команды компиляции, порождая каскад необъяснимых последующих сбоев.

FAILED: lib/libtransport.so
/usr/bin/ld: cannot find -luring: No such file or directory
clang-16: error: linker command failed with exit code 1
ninja: build stopped: subcommand failed.

В неуправляемом цикле исполнения трасса ошибки компоновщика механически дописывается в окно контекста, и модели остается интерпретировать пятьдесят строк трассировки шаблонов C++ в неструктурированном контексте. При обдумывании, опосредованном графом, сбой локализуется на границе узла $v_{\text{link}}$. Среда выполнения сравнивает фактическое наблюдение ${\mathbf{o}}_{\text{link}}$ с ожидаемым профилем постусловия ${\mathcal{O}}_{\text{link}}^{\ast }$, который требует нулевого кода возврата и наличия libtransport.so в файловой системе. Поскольку ${\mathbf{o}}_{\text{link}}\not\approx {\mathcal{O}}_{\text{link}}^{\ast }$, предикат не выполняется, и запускается процесс пересмотра плана, показанный на рисунке «Обдумывающий пересмотр плана и пересинтез подграфа».

Обдумывающий пересмотр плана и пересинтез подграфа: изоляция сбоя среды и локализованное восстановление графа. На панели A (слева) исходный граф плана DAG сталкивается с неразрешимым сбоем зависимости в узле $v_2$, что запускает автоматический каскад инвалидации по нижестоящим потомкам $\{v_3,v_4\}$. На панели B (справа) проверенные предковые узлы ($v_0,v_1$) и независимая параллельная ветвь $v_5$ сохраняются в эскроу памяти, а ограниченный мост пересинтеза заменяет $\{v_2,v_3\}$ проверенными узлами $\{v_2^{\prime },v_3^{\prime }\}$, чтобы восстановить сходимость к $v_4$.

Как показано на рисунке «Обдумывающий пересмотр плана и пересинтез подграфа», пересмотр плана отделяет восстановление после сбоя от глобальной регенерации. На панели A, когда узел $v_2$ сталкивается со сбоем среды, среда выполнения проходит обход инвалидации, помечая достижимых потомков $v_3$ и $v_4$ как инвалидированных, но сохраняя независимую параллельную ветвь $v_5$. На панели B вместо того чтобы отбрасывать весь граф, среда выполнения закрепляет проверенных предков $v_0$ и $v_1$ в эскроу памяти вместе с $v_5$. Супервизор обращается к генератору только за ограниченным мостом замены $\text{Bridge}({\mathcal{F}}_{\text{verified}}\to {\mathcal{C}}_{\text{downstream}})$, синтезируя компенсирующие шаги $v_2^{\prime }$ и $v_3^{\prime }$, которые удовлетворяют предусловиям $v_4$, и возвращая допустимое состояние без повторного исполнения завершенных операций.

При объявлении узла $v_i$ как $\text{Failed}$ среда выполнения запускает немедленный каскад инвалидации:

$${\mathcal{V}}_{\text{invalid}}=\text{Desc}(v_i)=\{v_k\in \mathcal{V}\mid v_i⇝v_k\}$$

Среда выполнения вычисляет множество достижимых потомков $\text{Desc}(v_i)$ обходом в ширину по $\mathcal{E}$ и немедленно переводит каждый найденный потомок-узел в состояние $\text{Invalidated}$. Это предотвращает исполнение осиротевших ветвей, причинные допущения которых рухнули. Важно, что любой узел $v_m\notin \text{Desc}(v_i)$, принадлежащий независимой параллельной ветви графа, остается полностью незатронутым. Его предусловия остаются действительными, исполнение может продолжаться без помех, а его проверенные вычислительные результаты сохраняются в эскроу памяти.

Иерархическая механика пересмотра

Когда инвалидация локализована, механизм обдумывания должен адаптировать план. Наивные реализации агентов реагируют на ошибки, отбрасывая весь план и запрашивая у модели полную регенерацию. Это вычислительно безрассудно: такой подход тратит избыточные токены генерации, увеличивает сквозную задержку задачи и рискует повторно исполнить неидемпотентные операции, которые уже изменили физическую среду. Принцип модульного сдерживания ошибок Солтцера и Каашука предписывает системе обрабатывать сбои на самом нижнем уровне, способном их разрешить. Поэтому среда выполнения реализует трехуровневую иерархическую стратегию пересмотра («Иерархическая механика пересмотра плана на трех уровнях»).

Иерархическая механика пересмотра плана на трех уровнях: модульное сдерживание ошибок, которое обрабатывает сбои исполнения на самом нижнем жизнеспособном архитектурном уровне. Уровень 1 выполняет локальное исправление узла ($a_i^{\prime }$) без каких-либо инвалидаций, когда внешние контракты ${\mathcal{O}}_i^{\ast }$ можно сохранить. Уровень 2 обрезает инвалидированный подграф $\text{Desc}(v_{\text{fail}})$ и пересинтезирует ветви-замены, закрепляя проверенное состояние предков в эскроу памяти. Уровень 3 останавливает исполнение и передает дело операторам, когда опровергнуты инварианты корневой задачи.

Структура решений на рисунке «Иерархическая механика пересмотра плана на трех уровнях» реализует структурированное сдерживание ошибок в духе Dijkstra на трех архитектурных границах. Когда узел сталкивается с наблюдением сбоя ${\mathbf{o}}_i\not\approx {\mathcal{O}}_i^{\ast }$, среда выполнения сначала пытается уровень 1 (локальное исправление): если внешний интерфейс постусловия остается достижимым, среда выполнения запрашивает у генератора альтернативную полезную нагрузку действия $a_i^{\prime }$ без инвалидации нижестоящих узлов и без расширения контекстных токенов. Если локальное исправление не удается или постусловия нельзя выполнить, механизм эскалирует на уровень 2 (пересинтез подграфа): среда выполнения обрезает провалившуюся ветвь $\text{Desc}(v_{\text{fail}})$, закрепляет проверенные состояния предков в эскроу памяти и просит генератор синтезировать локализованный мост замены. Только когда дефект среды опровергает предусловие корневой задачи (например, отсутствие аппаратных возможностей ядра или отозванные учетные данные), среда выполнения эскалирует на уровень 3 (глобальная эскалация), останавливая исполнение и передавая операторам-людям проверяемое диагностическое доказательство.

Локальное исправление (повтор на уровне узла)

Локальное исправление запускается, когда сбой узла $v_i$ можно устранить без изменения его внешнего контракта, то есть без смены ожидаемого профиля постусловия ${\mathcal{O}}_i^{\ast }$, который ожидают его нижестоящие потомки $\text{Desc}(v_i)$. Топология графа $\mathcal{E}$ остается полностью неизменной. Среда выполнения предоставляет модели строго ограниченный контекст, содержащий только подцель $g_i$, провалившееся действие $a_i$ и непосредственное наблюдение ошибки ${\mathbf{o}}_i$, и просит модель сгенерировать пересмотренную полезную нагрузку действия $a_i^{\prime }$. Примеры включают исправление неверно оформленного флага CLI, замену эквивалентного пути утилиты или корректировку параметра таймаута. Если $a_i^{\prime }$ удовлетворяет ${\mathcal{O}}_i^{\ast }$, узел $v_i$ переходит в $\text{Verified}$, и исполнение нижестоящих узлов возобновляется без структурных возмущений графа плана.

Пересинтез подграфа

Когда локальное исправление не удается или когда среда показывает, что постусловие ${\mathcal{O}}_i^{\ast }$ недостижимо (например, нужная сторонняя зависимость отсутствует в дистрибутиве хоста), среда выполнения эскалирует до обрезки подграфа. Планировщик удаляет провалившийся узел $v_i$ и всех его нижестоящих потомков $\text{Desc}(v_i)$ из активного плана. Проверенные узлы ${\mathcal{V}}_{\text{verified}}$ и накопленные дельты состояния $\Delta$ остаются закрепленными в эскроу памяти.

Затем среда выполнения запрашивает у модели синтез заменяющего подграфа ${\mathcal{G}}_{\text{sub}}^{\prime }=({\mathcal{V}}_{\text{sub}}^{\prime },{\mathcal{E}}_{\text{sub}}^{\prime })$. Запрос на пересинтез не требует полного плана задачи; он формулирует ограниченную задачу сшивания графа:

$$\text{Bridge}({\mathcal{F}}_{\text{verified}}\to {\mathcal{C}}_{\text{downstream}})$$

где ${\mathcal{F}}_{\text{verified}}$ — проверенный фронт (множество завершенных узлов, выходы которых доступны как входы), а ${\mathcal{C}}_{\text{downstream}}$ — целевое множество неинвалидированных нижестоящих узлов, предусловия которых в конечном счете должны быть выполнены. Когда модель выдает заменяющие узлы, среда выполнения встраивает ${\mathcal{G}}_{\text{sub}}^{\prime }$ в ${\mathcal{G}}_{\text{plan}}$, проверяет, что полученный составной граф остается ацикличным, и возобновляет исполнение на вновь введенном фронте.

Разница в токенах велика. Возьмем двенадцатиузловой план, шаги которого в среднем дают 150 выходных токенов, с отказом в шестом узле. Регенерация всего плана читает промпт из 7 596 токенов инструкций и истории 5 завершенных шагов и выдает 1 800 токенов. Замена трех затронутых узлов читает ограниченный промпт в 1 200 токенов и выдает 450 токенов, то есть четверть выходных токенов и, значит, примерно четверть времени декодирования. Кроме того, не нужно повторно исполнять 5 завершенных шагов, и это более значительная экономия, если эти шаги изменили среду. В длинной траектории план должен переживать любое отдельное решение. Обвязка хранит указатель на него в записи траектории («Обвязка агента»), а долговечное исполнение позволяет этой записи пережить сбой («Долговечное выполнение»).

Глобальная эскалация (инвалидация корня)

Когда сбой среды опровергает инвариант самой корневой задачи (например, встречается неустранимая аппаратная несовместимость, отсутствуют возможности ядра или отозваны учетные данные доступа), пересинтез на уровне ветвей не может преуспеть. Продолжение обдумывания в этом режиме тратит токены в неразрешимом пространстве поиска. Среда выполнения останавливает исполнение графа, помечает корневую цель как недостижимую при текущих ограничениях среды и эскалирует дело супервизору или оператору-человеку, выдавая структурированное диагностическое доказательство, которое содержит цепочку проверенных дельт состояния и терминальную сигнатуру инвалидации.

Экономия вычислений и токенов при пересинтезе подграфа по сравнению с глобальной регенерацией

Рассмотрим автономного агента систем, работающего на кластере вывода, который обслуживает плотную базовую модель на 70 миллиардов параметров ($P=70\times 10^9$ параметров) в 16-битной точности. Архитектура модели использует групповое внимание с запросами (GQA) с $L=80$ слоями трансформера, $d_{\text{model}}=8192$ и 8 головами ключей и значений ($d_{\text{head}}=128$).

При GQA каждый токен, хранящийся в KV-кеше, занимает:

$$M_{\text{token}}=2\times L\times n_{\text{kv}}\times d_{\text{head}}\times 2\text{ байт}=2\times 80\times 8\times 128\times 2=327680\text{ байт}\approx 320\text{ КиБ}$$

Агент исполняет граф плана из 12 узлов. Каждому узлу плана в среднем требуется 150 токенов для описания. Исходный системный промпт, описание среды и определения инструментов занимают $N_{\text{base}}=4096$ токенов.

Агент успешно исполняет узлы с $v_1$ по $v_5$. За эти пять шагов аргументы вызовов инструментов и наблюдения исполнения среды добавляют в контекст совокупно $N_{\text{exec}}=3500$ токенов истории взаимодействия. На узле $v_6$ компиляция C++ завершается с ошибкой из-за несовместимого ABI разделяемой библиотеки.

Оценим вычислительные и временные затраты для двух стратегий восстановления:

• Стратегия A (глобальная регенерация): среда выполнения отбрасывает текущий план, добавляет в контекст всю историю взаимодействия и журнал ошибки и просит модель заново сгенерировать полный план из 12 узлов.
• Стратегия B (пересинтез подграфа): среда выполнения сохраняет узлы с $v_1$ по $v_5$ в эскроу памяти, обрезает провалившуюся ветвь $\{v_6,v_7,v_8\}$ и предоставляет ограниченный промпт, который содержит только базовые системные инструкции ($N_{\text{base}}$), дельту состояния, произведенную $v_5$, и конкретную ошибку компоновщика. Этот ограниченный промпт составляет $N_{\text{scoped}}=1200$ токенов. Модель генерирует заменяющий подграф из 3 узлов ($3\times 150=450$ токенов), который собирает недостающую зависимость из исходников.

1. Анализ вычислений вывода (FLOP): Напомним, что обработка токенов промпта (фаза предзаполнения) требует примерно $2P$ операций с плавающей точкой на токен, а генерация выходных токенов (фаза декодирования) требует $2P$ операций на токен.

Для стратегии A: $$\text{Длина промпта }{N}_{\text{prompt, A}}=N_{\text{base}}+N_{\text{exec}}=4096+3500=7596\text{ токенов}$$ $$\text{FLOPs предзаполнения}=2\times (70\times 10^9)\times 7596=1,063\times 10^{15}\text{ FLOPs}=1,063\text{ PFLOPs}$$ $$\text{Длина генерации }{N}_{\text{gen, A}}=12\text{ узлов}\times 150\text{ токенов/узел}=1800\text{ токенов}$$ $$\text{FLOPs декодирования}=2\times (70\times 10^9)\times 1800=2,52\times 10^{14}\text{ FLOPs}=0,252\text{ PFLOPs}$$ $${\text{Суммарные вычисления}}_{\text{Policy A}}=1,063+0,252=1,315\text{ PFLOPs}$$

Для стратегии B: $$\text{Длина промпта }{N}_{\text{prompt, B}}=1200\text{ токенов}$$ $$\text{FLOPs предзаполнения}=2\times (70\times 10^9)\times 1200=1,68\times 10^{14}\text{ FLOPs}=0,168\text{ PFLOPs}$$ $$\text{Длина генерации }{N}_{\text{gen, B}}=3\text{ узлов}\times 150\text{ токенов/узел}=450\text{ токенов}$$ $$\text{FLOPs декодирования}=2\times (70\times 10^9)\times 450=6,30\times 10^{13}\text{ FLOPs}=0,063\text{ PFLOPs}$$ $${\text{Суммарные вычисления}}_{\text{Policy B}}=0,168+0,063=0,231\text{ PFLOPs}$$

$$\text{Сокращение вычислений}=\frac{1,315-0,231}{1,315}=\frac{1,084}{1,315}\approx 82,4\%$$

2. Задержка генерации на критическом пути: Авторегрессионное декодирование строго ограничено пропускной способностью памяти и последовательно. Предполагая, что сервис вывода достигает пропускной способности авторегрессионного декодирования в 40 токенов в секунду для этой модели на 70 миллиардов параметров: $$T_{\text{decode, Policy A}}=\frac{1800\text{ токенов}}{40\text{ токенов/с}}=45,0\text{ с}$$ $$T_{\text{decode, Policy B}}=\frac{450\text{ токенов}}{40\text{ токенов/с}}=11,25\text{ с}$$

Пересинтез подграфа дает ускорение в 4,0 раза по задержке перепланирования на критическом пути и при этом исключает риск повторного исполнения или порчи проверенных дельт состояния, произведенных шагами с $v_1$ по $v_5$.

Инварианты демпфирования перепланирования

Хотя рассмотрение планов как пересматриваемого состояния необходимо, чтобы выжить при волатильности физической среды, неограниченная политика перепланирования вводит серьезный динамический режим отказа: ловушку трешинга перепланирования. В операционных системах трешинг подкачки возникает, когда машина тратит больше циклов на перекачку страниц виртуальной памяти между диском и DRAM, чем на выполнение пользовательских инструкций. В среде выполнения агента трешинг перепланирования возникает, когда система тратит больше вычислений и времени на изменение своего графа плана, чем на исполнение действий, которые продвигают физическое состояние («Цикл трешинга перепланирования и контроллер демпфирования»).

Цикл трешинга перепланирования и контроллер демпфирования: слева чрезмерно чувствительные предикаты инвалидации загоняют агента в бесконечную блокировку, при которой несмертельные предупреждения среды запускают непрерывную мутацию плана без продвижения физического состояния ($\chi >2,0$). Справа трехэтапный структурный контроллер демпфирования применяет фильтрацию наблюдений, уменьшает ограниченный бюджет мутаций ($R_{\text{budget}}$) и записывает провалившиеся мутации в реестр карантина, чтобы обеспечить прогресс вперед.

Как показано на рисунке «Цикл трешинга перепланирования и контроллер демпфирования», неуправляемое перепланирование запускает нестабильный цикл блокировки (левая панель): несмертельные диагностические предупреждения ошибочно трактуются как инвалидации контракта, что вызывает повторные регенерации подграфа. Эти регенерации мутируют план, не продвигая состояние среды, и заставляют коэффициент трешинга $\chi ={\Delta }_{\text{replan}}/{\Delta }_{\text{exec}}$ сильно превысить порог неустойчивости ($\chi >2,0$). Правая панель раскрывает системное решение: трехэтапный контроллер демпфирования, который перехватывает сырую обратную связь исполнения. Этап 1 отфильтровывает некритичные предупреждения в информационный буфер; этап 2 уменьшает явный бюджет мутаций ($R_{\text{budget}}\leftarrow R_{\text{budget}}-1$), замораживая топологию графа, когда бюджет исчерпан; а этап 3 записывает отклоненные действия в неизменяемый реестр карантина, чтобы предотвратить циклическую регенерацию известных провальных команд.

Трешинг перепланирования обычно запускается чрезмерно чувствительными предикатами инвалидации. Современные среды инструментов выдают обильный диагностический шум: предупреждения компилятора, уведомления об устаревании, информационные баннеры динамических библиотек и ненулевые коды возврата стандартных разведочных команд (например, grep, возвращающий код выхода 1, когда шаблон не найден). Если среда выполнения трактует каждый непустой поток стандартной ошибки как инвалидацию контракта, агент запускает пересинтез почти после каждого действия. Модель непрерывно перестраивает нижестоящие подцели, переформулирует задачи и меняет топологии исполнения, так и не достигая сквозной цели задачи.

Чтобы предотвратить трешинг, среда выполнения навязывает три структурных инварианта демпфирования:

Фильтрация наблюдений

Обратная связь среды должна формально разделяться на структурные нарушения контракта и информационные предупреждения. Профиль постусловия ${\mathcal{O}}_i^{\ast }$ узла никогда не должен опираться на сырое текстовое равенство потоков stdout или stderr. Вместо этого предикаты задаются над семантическими эталонами: матрицами статусов кодов возврата, проверками свойств файловой системы (например, наличия inode, пороговых значений размера файла или криптографических контрольных сумм) или явной валидацией JSON-схемы. Нераспознанные предупреждающие токены направляются в информационный накопитель, а не запускают обработчик инвалидации узла.

Ограниченные бюджеты перепланирования

Среда выполнения назначает явный бюджет пополнения структурным мутациям на любой заданной траектории $\tau$. Пусть $R_{\text{budget}}$ обозначает максимальное число структурных пересинтезов ветвей, допустимых для задачи. Каждый вызов пересинтеза подграфа уменьшает этот бюджет:

$$R_{\text{budget}}\leftarrow R_{\text{budget}}-1$$

Когда $R_{\text{budget}}=0$, планировщик блокирует топологию графа. Любой последующий сбой в узле $v_k$ ограничивается попытками локального исправления. Если локальное исправление не удается, система немедленно запускает глобальную эскалацию, а не входит в бесконечный цикл перепланирования.

Определение: коэффициент перестройки плана $$\chi =\frac{|{\mathcal{V}}_{\text{mutated}}|}{|{\mathcal{V}}_{\text{initial}}|}$$ Если совокупный коэффициент перестройки $\chi$ превышает архитектурный порог (обычно $\chi >2,0$), механизм обдумывания объявляет динамическую нестабильность и принудительно вводит паузу оценки.

Механика карантина шагов

Чтобы предотвратить циклическое перепланирование, когда модель бесконечно переключается между двумя взаимно исключающими подпланами через последовательные шаги, среда выполнения ведет эфемерный реестр карантина провалившихся сигнатур действий внутри состояния траектории. Если предложенная пересинтезированная ветвь вводит узел $v_k^{\prime }$, сигнатура действия которого совпадает с ранее помещенным в карантин сбоем:

$$\text{Sig}(a_k^{\prime })\in {\mathcal{K}}_{\text{quarantine}}$$

среда выполнения отклоняет заменяющий граф до отправки, снижает оценку генерации модели и заставляет механизм обдумывания исследовать ортогональную ветвь.

Формализуя планы как проверяемые, типизированные графы зависимостей, среда выполнения перекидывает мост между стохастической генерацией токенов и детерминированным исполнением систем. Предусловия защищают физическую среду от сломанных причинных допущений, иерархические механизмы исправления сохраняют дорогое проверенное состояние, а инварианты демпфирования устраняют трешинг перепланирования.

Однако даже демпфированный, структурированный графом планировщик работает в физической реальности: каждая исследованная ветвь, каждый сгенерированный кандидат и каждое проверенное предусловие потребляют пропускную способность памяти, операции с плавающей точкой и время. Эта вычислительная реальность ставит центральный архитектурный вопрос: по каким формальным критериям среда выполнения должна прекращать поиск, фиксировать путь исполнения или прерывать неперспективную траекторию?

Критерии остановки поиска

Неограниченный древовидный поиск с авторегрессионным генератором быстро приводит к комбинаторному взрыву: расширение четырех альтернатив на каждом шаге траектории рассуждения из десяти шагов порождает более миллиона листовых состояний ($4^{10}\approx 1,05\times 10^6$). В среде вывода, где генерация каждого токена требует последовательных передач памяти по шине с высокой пропускной способностью (HBM), неограниченное ветвление исчерпывает квоту токенов сервера и нарушает интерактивные соглашения об уровне обслуживания за секунды, задолго до того, как будет найдена проверяемо правильная траектория. И наоборот, преждевременное завершение останавливает исследование непроверенных путей, оставляя агента наедине с необоснованными эвристиками или неполными решениями.

Топологию поиска нельзя отделить от его учета ресурсов и критериев остановки: обдумывание на этапе тестирования — это задача условной оптимизации, в которой среда выполнения агента должна динамически балансировать бюджеты токенов, задержку по часам, стоимость верификации и риск исполнения. Если оставить поиск неуправляемым, он либо схлопывается в нехватку вычислений, либо вырождается в избыточное обдумывание малоценных ветвей.

Топологии поиска

Архитектура обдумывания на этапе тестирования определяется топологией исследования пространства состояний. Когда агент выходит за рамки одного авторегрессионного декодирования, среда выполнения хоста должна организовать траектории-кандидаты в явную структуру данных, которая определяет, как альтернативы предлагаются, оцениваются и отсекаются. Три различные топологии доминируют в практических системах: плоская параллельная выборка (Best-of-$N$), итеративное расширение с отсечением (лучевой поиск, Beam Search) и древовидный поиск, направляемый эвристиками исследования и эксплуатации (поиск по дереву Монте-Карло, MCTS), а также возникающие агрегации на основе DAG, такие как Graph of Thoughts («Топологии поиска»).

Топологии поиска: параллельная выборка, лучевой поиск, MCTS и Graph of Thoughts: архитектурные компромиссы между четырьмя структурами поиска на этапе тестирования. Best-of-$N$ максимизирует параллелизм пакетов GPU, но откладывает все отсечение до завершения последовательности ($t=L$); лучевой поиск отсекает синхронно на границах шагов с памятью $O(B)$; поиск по дереву Монте-Карло балансирует исследование и эксплуатацию через оценки ценности, распространяемые обратно; Graph of Thoughts допускает произвольное ветвление DAG, петли обратной связи и слияние мыслей.

Четыре топологии, показанные на рисунке «Топологии поиска», демонстрируют резкие компромиссы между гранулярностью отсечения, аппаратной эффективностью и объемом памяти. В Best-of-$N$ (вверху слева) генерация исполняется как $N$ независимых неотсеченных прогонов. Хотя эта структура эффективно отображается на пакетные тензорные ядра GPU, любая ошибка, внесенная на ранних шагах, декодируется до конца, тратя до 87 процентов FLOP генерации. В лучевом поиске (вверху справа) синхронное отсечение на границах шагов сохраняет только верхние $B$ кандидатов, ограничивая память KV-кеша величиной $O(B\cdot L)$ ценой простоев конвейера во время проходов верификатора. Поиск по дереву Монте-Карло (внизу слева) строит асимметричное дерево поиска, используя верхние доверительные границы (PUCT), чтобы направлять вычисления к перспективным фронтам рассуждения, одновременно распространяя обратно эмпирические терминальные награды. Наконец, Graph of Thoughts (внизу справа) расширяет древовидные структуры до произвольных ориентированных ациклических графов, поддерживая вершины преобразования, которые объединяют, перегоняют и уточняют мысли из разных ветвей.

Фундаментальный компромисс между топологиями поиска заключается в том, где происходит отсечение: Best-of-$N$ откладывает все отсечение до терминального токена, максимизируя параллелизм пакетов ценой избыточной генерации токенов; лучевой поиск отсекает синхронно на границах шагов; а MCTS распределяет вычисления адаптивно в зависимости от неопределенности ценности, распространяемой назад.

Плоская выборка, которую обычно называют Best-of-$N$, представляет собой самую простую и наиболее параллельную топологию поиска. Для заданного промпта задачи $\mathbf{x}$ генератор параллельно выбирает $N$ независимых траекторий полной длины ${\tau }^{(1)},{\tau }^{(2)},\dots ,{\tau }^{(N)}\sim P_{\Theta }(\tau \mid \mathbf{x})$, где каждая траектория занимает до $L$ токенов. Когда все последовательности достигают терминального токена или границы длины, внешний селектор или верификатор оценивает каждого завершенного кандидата:

$${\tau }^{\ast }=\arg \underset{i\in \{1,\dots ,N\}}{\max }V\left({\tau }^{(i)}\right)$$

Best-of-$N$ естественно согласуется с аппаратным исполнением на GPU. Поскольку все $N$ последовательностей статистически независимы и генерируются одновременно, движок обслуживания объединяет их в один непрерывный запрос вывода. Это максимизирует арифметическую интенсивность фазы декодирования, амортизируя передачи весов модели по $N$ активным потокам генерации.

Однако Best-of-$N$ демонстрирует серьезную алгоритмическую неэффективность: в нем нет отсечения на уровне шагов вовсе. Если траектория допускает фатальную логическую ошибку или генерирует недопустимый синтаксис на токене $y_{17}$, генератор не замечает сбоя и продолжает декодирование до токена $y_{1024}$. Вычисления, затраченные на остальные 1 007 токенов, полностью тратятся впустую.

Лучевой поиск устраняет эти задержки и потери токенов, структурируя обдумывание как поэтапное расширение на уровне шагов. Вместо генерации полных сквозных траекторий среда выполнения сегментирует процесс генерации на дискретные шаги рассуждения или подцели $s_t\in \mathcal{S}$. На шаге $t$ генератор расширяет каждый из сохраненных сейчас путей в $M$ кандидатов-преемников, получая $B\times M$ кандидатных продолжений, где $B$ — ширина луча.

Шаговый верификатор (например, модель награды за процесс, PRM) оценивает каждое продолжение, и среда выполнения сохраняет только $B$ лучших кандидатов с наивысшими совокупными оценками, немедленно отсекая оставшиеся $(M-1)B$ ветвей. Отбрасывая тупики на ранней стадии, лучевой поиск предотвращает экспоненциальный взрыв ветвления.

Однако лучевой поиск вносит два различных системных недостатка. Во-первых, он синхронизирует исполнение на каждой границе шага, вынуждая движок обслуживания останавливать генерацию в ожидании, пока шаговый верификатор оценит пакет. Во-вторых, он уязвим к необратимым ошибкам поиска: если верификатор процесса присваивает ошибочно низкую оценку пути, который в конечном счете дал бы правильное решение, этот путь отбрасывается навсегда. «Сравнение топологий поиска» сопоставляет эти структурные компромиссы с деревом поиска.

Сравнение топологий поиска: архитектурное сравнение топологий поиска на этапе тестирования по профилям исполнения, гранулярности отсечения и представлению состояния.

Чтобы справиться с напряжением между ранним отсечением и необратимой фиксацией, поиск по дереву Монте-Карло (MCTS) строит явный асимметричный граф поиска над состояниями рассуждения, обобщая фреймворк Tree-of-Thoughts, формализованный Yao et al. (2023). В агентной конфигурации MCTS узлы представляют частичные траектории или состояния среды $s\in \mathcal{S}$, а направленные ребра — шаги рассуждения, вызовы инструментов или действия $a\in \mathcal{A}$. Вместо равномерного расширения узлов или строгого отсечения по немедленной оценке шага MCTS балансирует исследование и эксплуатацию в четырех непрерывных фазах:

1. Выбор: начиная с корневого состояния $s_0$, среда выполнения проходит по существующему дереву, выбирая дочерние узлы, которые максимизируют вариант верхней доверительной границы, адаптированный для нейронной генерации (например, предиктор-верхние доверительные границы, применяемые к деревьям, или PUCT): $$a^{\ast }=\arg \underset{a}{\max }\left[Q(s,a)+c_{\text{puct}}\cdot P_{\Theta }(a\mid s)\frac{\sqrt{{\sum }_{a^{\prime }}N(s,a^{\prime })}}{1+N(s,a)}\right]$$ где $Q(s,a)$ — эмпирическая средняя награда траекторий, проходящих через ребро $(s,a)$, $N(s,a)$ — счетчик посещений, а $P_{\Theta }(a\mid s)$ — априорная вероятность действия $a$ у генератора.
2. Расширение: когда достигается листовой узел, который посещали больше порогового числа раз, среда выполнения запрашивает у генератора $K_{\text{ext}}$ кандидатных продолжений и создает новые дочерние узлы в дереве.
3. Симуляция / оценка: среда выполнения оценивает ценность нового расширенного узла либо выполняя прогон до конца, либо оценивая состояние напрямую нейронной сетью ценности или автоматизированной обвязкой тестов.
4. Обратное распространение: оценка $V\in [0,1]$ распространяется назад вдоль предковой траектории от листа к $s_0$, обновляя счетчики посещений $N(s,a)\leftarrow N(s,a)+1$ и скользящие оценки ценности $Q(s,a)\leftarrow Q(s,a)+\frac{V-Q(s,a)}{N(s,a)}$.

MCTS обеспечивает асимптотическую сходимость и восстанавливается после локально обманчивых промежуточных оценок. Однако его профиль исполнения нерегулярен: глубины ветвей динамически меняются, размеры пакетов колеблются между циклами выбора, а расширение узлов требует непрерывного обновления метаданных дерева.

Единая модель учета ресурсов

Каждая развернутая ветвь, каждый сгенерированный кандидат и каждая проверенная утверждением проверка потребляют физические ресурсы. Чтобы обдумывание не вырождалось в неограниченное потребление вычислений, среда выполнения агента должна вести явный журнал совокупных затрат по всем фазам поиска.

Полные затраты на обдумывание $C_{\text{total}}$ определяются тремя аддитивными компонентами:

$$C_{\text{total}}=C_{\text{gen}}+C_{\text{verif}}+C_{\text{tool}}$$

где $C_{\text{gen}}$ учитывает авторегрессионную генерацию, $C_{\text{verif}}$ измеряет накладные расходы верификации, а $C_{\text{tool}}$ фиксирует затраты на исполнение в среде.

Стоимость генерации $C_{\text{gen}}$ растет вместе с совокупным числом токенов, сгенерированных на всех исследованных ветвях. Ее задержка подчиняется нижней границе декодирования из раздела «Задержка обслуживания на ускорителе», а вычислительная стоимость для модели с $|\Theta |$ активными параметрами выражается в операциях с плавающей точкой:

$$C_{\text{gen}}=2\cdot |\Theta |\cdot \sum _{b\in \mathcal{B}}{K}_b\text{[FLOPs]}$$

где $\mathcal{B}$ обозначает множество всех развернутых ветвей в дереве поиска, а $K_b$ — длина последовательности, сгенерированной на ветви $b$.

Стоимость верификации $C_{\text{verif}}$ сильно зависит от природы верификатора. При использовании нейронных моделей награды, таких как верификатор исхода (ORM) или верификатор процесса (PRM), $C_{\text{verif}}$ повторяет формулировку для генерации:

$$C_{\text{verif}}^{\text{neural}}=2\cdot |{\Theta }_{\text{verif}}|\cdot \sum _{j\in {\mathcal{V}}_{\text{eval}}}{K}_j\text{[FLOPs]}$$

где ${\mathcal{V}}_{\text{eval}}$ — множество вызовов оценки, а $|{\Theta }_{\text{verif}}|$ — число параметров модели верификатора. Напротив, детерминированные верификаторы (такие как компиляторы, наборы тестов и линтеры) расходуют такты центрального процессора хоста, задержку подготовки контейнеров и накладные расходы изоляции песочницы, а не операции с плавающей точкой GPU:

$$C_{\text{verif}}^{\text{det}}=\sum _{j\in {\mathcal{V}}_{\text{eval}}}\left(t_{\text{sandbox}}+t_{\text{exec}}^{(j)}\right)\text{[seconds]}$$

Стоимость исполнения инструментов $C_{\text{tool}}$ включает задержку, пропускную способность сети и накладные расходы сторонних API, которые возникают, когда исследовательская ветвь взаимодействует с внешней средой. В отличие от чистой генерации, исполнение инструментов вносит недетерминированные задержки по часам: ветвь агента, которая вызывает внешний запрос к базе данных или инструмент статического анализа, может простаивать сотни миллисекунд, удерживая состояние памяти ускорителя в ожидании.

Best-of-16 против лучевого поиска с шаговым верификатором

Сценарий: агент-программист строит патч в четыре шага рассуждения по 128 токенов каждый. Генератор декодирует со скоростью около 21,1 мс на выходной токен («Задержка обслуживания на ускорителе»), а небольшой пакет декодируется почти с однопоточной скоростью. Допущения сценария: выход генератора стоит $15 за миллион токенов; небольшая модель PRM оценивает один 128-токенный шаг за 15 мс и стоит $0,50 за миллион входных токенов; тестовый прогон в песочнице занимает 0,5 с, по 8 прогонов параллельно.

Вариант A (best-of-16): шестнадцать полных кандидатов по 512 токенов, декодированных одним пакетом. Выход — 8 192 токена, то есть около $0,123. Декодирование занимает около 10,8 с. Все 16 кандидатов проверяются в 2 волны по 8, добавляя 1 с, поэтому задержка около 11,8 с, а поиск использует 16 прогонов в песочнице.

Вариант B (лучевой поиск, $B=4$, $M=3$): шаг 1 расширяет корень в 3 продолжения, шаг 2 расширяет их в 9, а шаги 3 и 4 расширяют по 4 сохраненных префикса в 12 каждый, всего 36 сегментов шагов. Выход — 4 608 токенов, то есть около $0,069. PRM читает те же 4 608 токенов примерно за $0,002. Декодирование занимает четыре последовательных шага по 128 токенов, около 10,8 с; оценка добавляет 0,06 с; проверка четырех выживших в одной волне добавляет 0,5 с. Задержка около 11,4 с, с 4 прогонами в песочнице.

Расчет: лучевой поиск генерирует примерно на 44 процента меньше выходных токенов и использует четверть прогонов в песочнице при похожей задержке.

Системный вывод: раннее оценивание шагов здесь окупается, потому что PRM мала и оценивает короткие шаги. PRM лишь решает, какие префиксы сохранить; четырех выживших по-прежнему принимают или отклоняют тесты. Когда шаговый верификатор так же велик, как генератор, и перечитывает длинные префиксы, его токены могут превысить токены генератора, и баланс меняется на обратный.

Многокритериальные инварианты остановки

Поисковый движок без граничных условий остановки будет расходовать бесконечные токены или бесконечно крутиться в рекурсивных вызовах инструментов. Среда выполнения хоста должна навязывать явные многокритериальные правила остановки, которые определяют, когда фиксировать кандидата, когда отсекать поддерево и когда полностью прерывать поиск.

Эти граничные условия работают по трем различным операционным измерениям: жесткие потолки ресурсов, удовлетворение порогов и остановка по предельной полезности («Граничные условия остановки поиска на этапе тестирования и многокритериальное пространство состояний»).

Граничные условия остановки поиска на этапе тестирования и многокритериальное пространство состояний: иерархия остановки, балансирующая жесткие потолки ресурсов, оппортунистическое удовлетворение порогов и экономику предельной полезности. В пространстве состояний оценки верификатора $V(\tau )$ против вычислений токенов $K$ сертифицированная детерминированная проверка ($V=1,0$) запускает немедленный оппортунистический выход; достижение жестких потолков ресурсов ($K_{\max },T_{\max },D_{\max }$) безусловно останавливает поиск; а предельный прирост ниже порога ($\Delta P/\Delta C<{ϵ}_{\text{stop}}$) завершает исследование, когда отдача падает. Порядок приоритетов соблюдается от приоритета 1 (жесткие потолки) до приоритета 3 (предельная остановка).

Как формализовано в панели (a) «Граничные условия остановки поиска на этапе тестирования и многокритериальное пространство состояний», среда выполнения координирует решения об остановке в многомерном пространстве состояний, которое задается оценкой верификатора $V(\tau )$ и накопленными затратами вычислений $K$. Панель (b) задает порядок, в котором эти границы проверяются. Когда ветвь исполнения достигает сертифицированной гиперплоскости $V(\tau )=1,0$ (через прохождение компилятора или детерминированного набора тестов), граница удовлетворения запускает немедленную оппортунистическую фиксацию и прерывает все спекулятивные соседние ветви. Если ни одна ветвь не удовлетворяет сертифицированному порогу, исследование продолжается, пока либо кривая предельной полезности не выровняется ($\Delta P/\Delta C<{ϵ}_{\text{stop}}$), либо суммарные вычисления не пересекут вертикальный жесткий потолок $K_{\max }$ (или предельный срок по часам $T_{\max }$). Среда выполнения навязывает строгий порядок оценки: жесткие системные инварианты (приоритет 1) строго имеют преимущество над эвристическим удовлетворением (приоритет 2) и критериями предельной остановки (приоритет 3).

Обдумывание расходует горизонт внутри одного решения, а жесткие потолки ограничивают этот расход.

Жесткие потолки ресурсов замыкают границы поиска механически, ниже уровня модели, как того требует «Принцип замыкания инвариантов». Они ограничивают горизонт, который может потратить одно решение, и предотвращают неуправляемые циклы, вызванные деградацией генератора, вырожденными выходами инструментов или круговыми путями рассуждения. Среда выполнения отслеживает три основных потолка:

1. Квота токенов ($K_{\max }$): максимальное совокупное число токенов, сгенерированных на всех активных ветвях. Когда ${\sum }_b{K}_b\ge K_{\max }$, цикл поиска завершается, а селектор выбирает кандидата с наивысшей оценкой из завершенных в эскроу. Ветви, обрезанные квотой, возвращают TRUNCATED и остаются в карантине (принцип «Инвариант карантина»).
2. Предельный срок по часам ($T_{\max }$): абсолютный порог прошедшего времени, заданный бюджетами задержки для пользователя или таймаутами вышестоящих сервисов. Соблюдается через таймеры срока среды выполнения, которые прерывают активные вызовы модели.
3. Максимальная глубина ветви ($D_{\max }$): максимально допустимая длина траектории исследования в дискретных шагах рассуждения или действиях инструментов. $D_{\max }$ не дает моделям уходить по бесконечным цепочкам нерелевантного исследования.

Удовлетворение порога (также называемое satisficing) реализует оппортунистический досрочный выход. Когда среда выполнения оценивает кандидата детерминированным верификатором (например, автоматическим компилятором, криптографическим набором тестов или полным прохождением модульных тестов), бинарный сигнал успеха ($V(\tau )=1$) дает эмпирическое подтверждение выполнения задачи. Если какая-либо ветвь дает сертифицированного кандидата, продолжение поиска не дает никакой дополнительной полезности. Среда выполнения немедленно прерывает все конкурирующие ветви, освобождает их ожидающие запросы и фиксирует успешную траекторию.

Однако когда верификация опирается на стохастическую или непрерывную нейронную оценку (например, модель награды, выдающую $v\in [0,1]$), высокая оценка не гарантирует корректность; она лишь указывает на статистическое правдоподобие. В таких режимах ранняя остановка по эвристическим порогам рискует преждевременной фиксацией на состязательных эксплойтах награды, как показано в разделе «Верификация процесса».

Третья парадигма остановки — остановка по предельной полезности — оценивает, оправдывает ли ожидаемое повышение точности от генерации еще одного кандидата инкрементальную трату вычислений. Snell et al. (2024) показали, что поиск на этапе тестирования демонстрирует логарифмическое поведение масштабирования: вероятность найти правильное решение вначале растет с вычислениями, но быстро выходит на плато, когда пространство поиска насыщается или генератор упирается во внутренние пределы ошибки. Так возникают кривые предельной полезности, показанные на рисунке «Распределение бюджета поиска и предельная полезность».

Распределение бюджета поиска и предельная полезность: масштабирование вычислений этапа тестирования по топологиям поиска при фиксированных потолках вычислений. На панели A вероятность успеха задачи $P(\text{success})$ демонстрирует логлинейное масштабирование до насыщения области, с оптимальной рабочей точкой $C^{\ast }$, балансирующей предельный прирост и стоимость. На панели B раннее отсечение ветвей верификатором сводит эффективный коэффициент ветвления с $b=5,0$ к $b_{\text{eff}}\approx 1,6$, предотвращая комбинаторный взрыв листьев и экономя 68 процентов токенов вывода.

Двупанельный анализ на рисунке «Распределение бюджета поиска и предельная полезность» показывает, почему неуправляемая ширина поиска страдает от сильной убывающей отдачи. Панель A прослеживает эмпирическую траекторию успеха задачи как функцию вычислений вывода: первые вложения вычислений дают крутой рост точности, но предельное улучшение выравнивается, когда генератор исчерпывает бассейн своих высокодоверенных знаний. Точка $C^{\ast }$ — это оптимальная касательная остановки, где $\Delta P/\Delta C={ϵ}_{\text{stop}}$. Панель B иллюстрирует, как активная верификация меняет геометрию дерева поиска: слепой поиск в глубину с коэффициентом ветвления $b=5,0$ разворачивает 125 листовых узлов на трех шагах глубины, тогда как промежуточное стробирование верификатором отсекает 68 процентов недопустимых ветвей, снижая эффективный коэффициент ветвления до $b_{\text{eff}}\approx 1,6$ и оставляя пропускную способность ускорителя для допустимых кандидатных завершений.

Пусть $P_m(\text{success})$ обозначает оцененную вероятность успеха задачи после затраты вычислений $C_m$ (измеряемых в токенах или FLOP) на $m$ итерациях поиска. Предельная полезность продолжения определяется как:

$${\mathcal{U}}_{\text{marg}}(m)=\frac{P_m(\text{success})-P_{m-1}(\text{success})}{C_m-C_{m-1}}\approx \frac{\Delta P}{\Delta C}$$

Среда выполнения отслеживает ${\mathcal{U}}_{\text{marg}}(m)$ по скользящему окну итераций. Когда предельный прирост опускается ниже настроенного порога эффективности ${ϵ}_{\text{stop}}$:

$$\frac{\Delta P}{\Delta C}<{ϵ}_{\text{stop}}$$

поиск останавливается. Дальнейшие вычисления при этом условии дают убывающую отдачу, поэтому оптимальная политика переходит от более глубокого локального поиска к выдаче текущего лучшего кандидата ${\tau }^{\ast }$ или эскалации на альтернативный план.

Эмпирическая реализация остановки по предельной полезности требует ведения скользящих оценок вероятности успеха по итерациям кандидатов:

def should_terminate_search(history: list[float], cost_history: list[int],
                            k_max: int, eps: float = 1e-5) -> bool:
    """Оценивает остановку по предельной полезности при бюджетах токенов и эффективности."""
    if cost_history[-1] >= k_max or len(history) < 2:
        return cost_history[-1] >= k_max
    # Предельный эмпирический прирост на тысячу токенов в скользящем окне
    delta_p = max(0.0, history[-1] - history[-2])
    delta_c = max(1, cost_history[-1] - cost_history[-2])
    marginal_utility = (delta_p / delta_c) * 1000.0
    return marginal_utility < eps

Помимо бюджетов токенов и задержки, автономные агенты сталкиваются с бюджетом риска действий. Когда агент взаимодействует с внешними средами, действия обладают разной степенью обратимости. Запросы только на чтение (например, git status, ls, просмотр файлов) находятся на уровне полномочий $A_0$ в терминах «Экспозиции H·S·A». Они ничего не меняют, поэтому исследовательские ветви могут выполнять их без отката. Однако риск у них есть: то, что они читают, может утечь через последующие выводы, поэтому среда выполнения все равно контролирует, куда попадают их результаты.

И наоборот, необратимые мутации на уровне $A_3$ (например, выполнение миграций базы данных, удаление удаленных веток или отправка внешних писем) несут неограниченный радиус поражения. Если непроверенная исследовательская ветвь выполняет необратимое действие в неизолированной среде, поиск не может просто «откатиться» после обнаружения последующего сбоя.

Чтобы защитить среду, среда выполнения должна гарантировать, что исследовательский поиск работает исключительно в изолированных черновиках или песочницах, которые среда выполнения может отбросить и которые удерживают его действия на уровне $A_1$ (как формализовано в разделе «Песочницы агентов»). Фиксация изменений в физической среде откладывается до завершения алгоритма поиска, выполнения критериев остановки и формального выбора и сертификации траектории-кандидата.

Оценка топологий поиска и инвариантов остановки

Прежде чем сравнивать стратегии обдумывания при равенстве ресурсов, проверьте, как вы понимаете механику ограниченного поиска:

• Инвалидация плана: когда наблюдение среды на промежуточном шаге нарушает предусловие в DAG плана, какие нижестоящие узлы нужно пометить как устаревшие?
• Асимметрия ошибок верификатора: почему ложное принятие верификатором (${\alpha }_{\text{accept}}$) ухудшает сквозное выполнение задачи сильнее, чем ложный отказ (${\beta }_{\text{reject}}$)?
• Инварианты остановки: как многокритериальные правила остановки предотвращают трешинг поиска, когда оценки верификатора выходят на плато или бюджеты токенов исчерпываются?
• Необратимые действия: почему исследовательские ветви поиска должны оставаться строго в песочнице до тех пор, пока траектория-кандидат не удовлетворит оракулы сертификации?

Оценка стратегий обдумывания

Оценка стратегии вывода с обдумыванием представляет тонкую ловушку системных измерений: архитектура, которая выглядит превосходящей в неограниченном бенчмаркинге, часто схлопывается под жесткими потолками токенов, строгими целями уровня обслуживания по хвостовой задержке или ненадежными верификаторами. В литературе с разомкнутым контуром принято демонстрировать, что поиск по дереву Монте-Карло или итеративный цикл самокоррекции достигают более высокой абсолютной точности на бенчмарке, чем одношаговый жадный базис. Однако такие сравнения регулярно сопоставляют неравные классы вычислений. Дерево поиска, исследующее тридцать два кандидатных ветви, тратит в тридцать два раза больше прямых FLOP, требует гигабайтов временной памяти кеша «ключ — значение» и умножает задержку по часам на критическом пути. Если бы тот же вычислительный бюджет был выдан модели базы большей емкости или распределен по параллельным независимым выборкам с голосованием большинством, кажущееся превосходство сложной политики поиска часто испаряется.

Политики обдумывания никогда не должны оцениваться против неограниченного горизонта вычислений. Каждый дополнительный токен, ветвь расширения или исполнение в песочнице расходует конкретные физические ресурсы, которые должны оправдывать свой предельный вклад в принятую точность.

Политика обдумывания заслуживает своей архитектурной сложности, только если она доминирует по Парето над более простыми базовыми вариантами при строго согласованных бюджетах ресурсов, выровненных привилегиях среды и реалистичной точности верификации. Введение очередей расширения деревьев, обученных верификаторов процесса или многоходовых циклов рефлексии — это не автоматическое алгоритмическое обновление; это архитектурное обязательство, которое влечет конкретные накладные расходы пропускной способности памяти, сложность планирования и усиление хвостовой задержки. Чтобы определить, должна ли среда выполнения агента обдумывать, инженер обязан подвергнуть кандидатные стратегии контролируемой, ресурсно-эквивалентной оценке по многомерным метрикам производительности, нанеся точные границы Парето, где обдумывание работает, и определив операционные режимы, в которых оно вызывает катастрофический отказ.

Управляемая системная оценка при равенстве ресурсов

Строгая системная оценка требует, чтобы все смешивающие переменные вне политики поиска оставались неизменными. В инженерии системного программного обеспечения сравнение двух процедур сортировки требует их запуска на одинаковых архитектурах CPU с одинаковыми иерархиями кешей, конфигурациями памяти и флагами оптимизации компилятора. В среде выполнения агентной системы машинного обучения эквивалентный экспериментальный контроль требует заморозить три различные архитектурные границы:

1. Инвариантность параметров модели и точности ($\Theta$): веса базовой модели, формат квантования (например, FP8, BF16) и конфигурации движка обслуживания должны оставаться одинаковыми во всех испытуемых стратегиях. Оценка итеративной политики поиска на модели с 8 миллиардами параметров против одношагового промпта на модели с 70 миллиардами параметров измеряет масштабирование параметров, а не эффективность поиска.
2. Инвариантность интерфейса среды и песочницы (равные полномочия): каждая стратегия-кандидат должна работать в точно той же непривилегированной границе песочницы. Если политика обратной связи среды получила доступ к цепочке инструментов компилятора или набору линтеров, базовые политики должны оцениваться через тот же интерфейс вызовов инструментов и тот же набор полномочий.
3. Общий потолок вычислений (${\mathcal{C}}_{\max }$): все политики должны оцениваться при идентичном ограничении максимального бюджета. Это ограничение параметризуется либо общим потолком генерации токенов ($T_{\text{total}}=T_{\text{prompt}}+T_{\text{completion}}$), либо совокупным потолком операций с плавающей точкой ($C_{\text{FLOP}}$), либо жестким таймаутом задержки по часам ($T_{\text{wall}}\le T_{\max }$).

Snell et al. (2024) показали, что оптимизация распределения вычислений этапа тестирования может дать прирост точности, эквивалентный масштабированию параметров на порядки, при условии что вычисления согласованы с явным механизмом верификации.

Необходимость строгого согласования вычислений была эмпирически сформулирована Snell et al. (2024), которые показали, что оптимальная стратегия распределения вычислений этапа тестирования принципиально зависит от задачи. При фиксированной трате вычислений $\mathcal{C}$ среда выполнения агента сталкивается с явным компромиссом распределения ресурсов: можно тратить токены по глубине (генерируя более длинные и подробные авторегрессионные трассировки рассуждения), по ширине (выбирая $N$ независимых траекторий и выбирая среди них) или по обратной связи (итеративно запуская код-кандидат в песочнице внешнего исполнения и уточняя по логам ошибок). Наивный бенчмаркинг скрывает этот компромисс, сообщая точность как неограниченную функцию алгоритмической сложности.

# Эмпирическая проверка: соблюдение строгого бюджета токенов всеми стратегиями
def compute_efficiency(tokens_spent: int, success: bool, budget: int) -> float:
    if tokens_spent > budget:
        return 0.0  # Дисквалификация: превышение бюджета нарушает системную эквивалентность
    return 1.0 if success else 0.0

Когда стратегии оцениваются при строгом потолке ${\mathcal{C}}_{\max }$, иерархия систем меняется. Сложный граф обдумывания с несколькими стадиями расширения промптов и эвристическими отсекателями ветвей часто исчерпывает бюджет токенов на разговорную оркестрацию и повторную подачу промптов в окно контекста, оставляя недостаточно бюджета на основной синтез решения. Более простая стратегия, например параллельный Best-of-$N$ с автоматическим синтаксическим верификатором, часто фиксирует доступный прирост производительности, избавляясь от сложного отслеживания состояния поиска по дереву.

Многомерные системные метрики

Оценка среды обдумывания только по бинарной доле успеха задач (точности) — архитектурный антишаблон. В промышленной эксплуатации агент, который поднимает точность на пять процентных пунктов, но утраивает хвостовую задержку $p99$ или увеличивает число молчаливых порч, неприемлем. Всесторонняя системная оценка требует одновременно отслеживать четыре ортогональные метрики.

Pass@1 против pass@$k$ при согласованных бюджетах

В академической генерации кода метрика $\text{Pass}@k$ широко определяется как вероятность того, что хотя бы один из $k$ сгенерированных кандидатных решений проходит данный набор проверок:

$$\text{Pass}@k={\mathbb{E}}_{\text{tasks}}\left[1-\frac{\left(\genfrac{}{}{0ex}{}{N-c}{k}\right)}{\left(\genfrac{}{}{0ex}{}{N}{k}\right)}\right]$$

где сгенерировано $N\ge k$ выборок, а $c$ — число правильных выборок. Хотя $\text{Pass}@k$ дает теоретическую границу потенциала генерации стохастического распределения модели, это обманчивая системная метрика. $\text{Pass}@k$ предполагает существование всезнающего оракула нулевой стоимости, который без усилий выберет единственного работающего кандидата из набора из $k$.

В настоящей системной реализации такого оракула не существует. Супервизор хоста должен либо выбрать одного кандидата для фиксации в постоянном хранилище с помощью автоматического верификатора, либо вывести кандидата, стоящего на первом месте в ранжировании. Непроверенный набор из $k$ кандидатов дает нулевую операционную полезность. Поэтому системная оценка должна сообщать точность принятия при ограниченном бюджете: эмпирическую вероятность того, что кандидат, выбранный и выданный политикой поиска при бюджете $\mathcal{C}\le B$, проходит все инварианты.

Эффективная стоимость на проверенный успех

Сырое потребление токенов не масштабируется линейно с системной ценностью. Стратегия поиска, которая поднимает успех задач с 50 до 60 процентов, одновременно увеличивая среднее потребление токенов с 1 000 до 8 000 токенов, представляет собой архитектурное ухудшение экономической эффективности. Этот баланс мы количественно оцениваем через эффективную стоимость на проверенный успех ($C_{\text{eff}}$):

$$C_{\text{eff}}=\frac{\mathbb{E}[C]}{P(\text{верифицированный успех})}$$

где $\mathbb{E}[C]$ обозначает ожидаемую стоимость ресурсов на экземпляр задачи, измеряемую в совокупных токенах генерации или операциях с плавающей точкой, а $P(\text{верифицированный успех})$ — доля задач, которые проходят обвязку верификации супервизора хоста. Если базовая политика с одним кандидатом достигает точности 45 процентов при средней стоимости 512 токенов, ее $C_{\text{eff}}$ составляет $1138$ токенов на успешный исход. Если итеративный цикл уточнения достигает точности 68 процентов, но тратит в среднем $4096$ токенов на повторные итерации проверки, его $C_{\text{eff}}$ вырастает до $6024$ токенов на успешный исход, то есть более чем в пять раз больше ресурсов, требуемых для выдачи одного проверенного результата.

Распределения задержки по часам

Разные топологии обдумывания распределяют вычислительную нагрузку по критическому пути принципиально разными способами:

• Топологии, тяжелые по глубине (последовательное обдумывание): последовательная генерация цепочки рассуждений, итеративная критика и возврат по одной ветви сериализуют исполнение. Задержка по часам строго ограничена суммой последовательных прямых проходов:

  $$T_{\text{wall}}=\sum _{i=1}^D{t}_{\text{decode}}(y_i)$$

  Поскольку декодирование ограничено пропускной способностью памяти («Задержка обслуживания на ускорителе»), критический путь нельзя сжать, бросая параллельные вычисления на один экземпляр. Это создает высокую медианную задержку ($p50$) и подвергает исполнение сильной дисперсии, если модель входит в расширяющийся цикл генерации.

• Топологии, тяжелые по ширине (параллельная выборка): одновременная генерация $N$ кандидатов позволяет супервизору хоста объединять предзаполнение промпта и декодирование токенов по рангам GPU с тензорным параллелизмом. Пока совокупный размер пакета не превышает порога насыщения аппаратуры или не исчерпывает память высокой пропускной способности (HBM), задержка критического пути по часам масштабируется около $\mathcal{O}(1)$ относительно $N$. Однако стратегии ширины создают серьезное давление на кеш «ключ — значение» (KV):

  $$M_{\text{KV, total}}=N\cdot 2\cdot L\cdot d_{\text{model}}\cdot S$$

  где $L$ — число слоев, а $S$ — длина контекста. Если $M_{\text{KV, total}}$ превышает физическую емкость памяти GPU, движок обслуживания вынужден вытеснять последовательности или выгружать блоки KV в DRAM хоста, из-за чего хвостовая задержка ($p99$) резко возрастает.

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

Частота ложного принятия

Когда выбор кандидатов опирается на автоматические верификаторы, эвристические линтеры или обученные модели награды за процесс, оптимизация поиска подчиняется закону Гудхарта: когда мера становится целью, она перестает быть хорошей мерой. По мере расширения ширины исследования кандидатов $N$ вероятность того, что генератор обнаружит состязательный граничный случай, то есть кандидата, который технически удовлетворяет синтаксическим проверкам верификатора, но полностью нарушает лежащие в основе инварианты задачи, монотонно растет.

Мы определяем частоту ложного принятия (FAR) как вероятность того, что обвязка верификации среды выполнения помечает провалившееся или испорченное предложение как допустимое:

$$\text{FAR}=P(\text{accept}\mid \text{incorrect})$$

Поскольку модель не имеет неявных полномочий, кандидат меняет среду только после того, как среда выполнения его принимает; поэтому ложное принятие — это молчаливая утечка отказа. Агент, который выдает явный сигнал о сбое, позволяет супервизору хоста остановиться, запустить компенсирующее действие или передать задачу на проверку человеку. И наоборот, агент с высокой частотой ложного принятия фиксирует испорченные изменения состояния в постоянной среде, отравляя нижестоящие компоненты системы.

Компромиссы обдумывания при согласованных вычислениях

Рассмотрим автономный сервис ремонта кода, который обрабатывает поступающие отчеты об ошибках. Движок обслуживания работает на GPU NVIDIA H100 (3 350 TFLOPS FP8, 3,35 ТБ/с HBM3). Среда выполнения навязывает срок SLA $T_{\max }=10,0\text{ с}$ и оценивает три различные стратегии при согласованном общем потолке вычислений ${\mathcal{C}}_{\max }\le 4096\text{ токенов}$:

1. Жадный одношаговый: генерирует одно решение из 512 токенов.
2. Параллельный Best-of-8 (ширина): объединяет в пакет 8 одновременных генераций кандидатов по 512 токенов каждая ($T_{\text{total}}=4096\text{ токенов}$). Кандидаты оцениваются верификатором — средством запуска тестов; выбирается первый кандидат, прошедший все тесты.
3. Последовательное уточнение (глубина): выполняет до 4 итеративных циклов «критика — генерация», потребляя в среднем 800 токенов на цикл ($T_{\text{total}}\le 3200\text{ токенов}$).

Эмпирические журналы исполнения дают показатели, сведенные в таблице «Результаты эталонного теста стратегий обдумывания»:

Стратегия	$P(\text{success})$	Средние токены	$C_{\text{eff}}$ (токены/успех)	Задержка $p50$	Задержка $p99$	FAR
Жадный одношаговый	0,42	512	$1219$	1,1 с	1,4 с	0,01
Параллельный Best-of-8	0,74	$4096$	$5535$	1,8 с	9,4 с	0,09
Последовательное уточнение	0,61	$2650$	$4344$	6,2 с	14,8 с	0,04

Результаты эталонного теста стратегий обдумывания: доля успешных исходов, потребление токенов, эффективная стоимость и хвостовая задержка по стратегиям исследования.

Анализ:

• Точность против стоимости: параллельный Best-of-8 дает самую высокую сырую точность ($0,74$), но его $C_{\text{eff}}$ в 4,5 раза выше, чем у жадной стратегии. Каждый проверенный успех требует сжечь $5535$ токенов мощности GPU.
• Срок SLA по хвостовой задержке: хотя параллельный Best-of-8 сохраняет приемлемую задержку $p50$ 1,8 с благодаря одновременному пакетному декодированию, его задержка $p99$ деградирует до 9,4 с, опасно близко к сроку SLA 10,0 с, из-за конкуренции за память KV-кеша в движке обслуживания. Последовательное уточнение полностью нарушает SLA на $p99$ (14,8 с), поскольку последовательные проходы авторегрессионного декодирования накапливаются детерминированно.
• Риск молчаливого отказа: параллельный Best-of-8 пропускает тревожные 9 процентов ложного принятия. Генерируя 8 разнообразных кандидатов, модель часто создает тонкие эксплойты, которые проходят неполные утверждения тестов (например, жестко прописывая ожидаемые возвращаемые значения для конкретных тестовых случаев).

Три стратегии на одной задаче ремонта

Сценарий: сервис ремонта обрабатывает задачи со сроком 75 секунд. Одна попытка — 1 000 выходных токенов, что при однопоточной скорости из раздела «Задержка обслуживания на ускорителе» занимает около 21 с. Допущения сценария: один запечатанный тестовый прогон занимает 10 с; одна попытка проходит с вероятностью $p=0,40$; выход стоит $15 за миллион токенов, стоимость входа для простоты не учитывается.

Вариант A (одна попытка): $P(\text{accepted})=0,40$. Расход — 1 000 токенов, поэтому $C_{\text{eff}}=$ 2 500 токенов, около $0,037. Задержка — одна попытка плюс один тест, около 31 с.

Вариант B (best-of-8, запечатанные тесты как селектор): восемь кандидатов коррелированы и ведут себя как три независимые попытки, поэтому $P(\text{accepted})=1-0,6^3\approx$ 0,78. Поскольку селектором выступает сам запечатанный набор, это равно потолку pass@8. Расход — 8 000 токенов, поэтому $C_{\text{eff}}\approx$ 10 200 токенов, около $0,15. Кандидаты и тесты выполняются параллельно, поэтому задержка остается около 31 с, при 8 прогонах в песочнице.

Вариант C (обратная связь, до трех раундов): после провала отчет теста поднимает вероятность прохождения каждой правки до $0,35$. Тогда $P(\text{accepted})=1-0,6\times 0,65\times 0,65\approx$ 0,75. Ожидаемое число раундов составляет $1+0,6+0,6\times 0,65=$ 1,99, поэтому ожидаемый расход — 1 990 токенов, а $C_{\text{eff}}\approx$ 2 670 токенов, около $0,040. Каждый раунд занимает около 31 с, поэтому ожидаемая задержка около 62 с, а наихудший случай — 93 с.

Расчет: вариант C почти достигает успеха варианта B примерно при четверти его стоимости на принятую задачу и стоит лишь около 7 процентов больше на принятую задачу, чем одна попытка. Вариант C также нарушает срок 75 секунд в третьем раунде, что случается в 39 процентах задач.

Системный вывод: ни одна стратегия не выигрывает по всем осям. При сроке 75 секунд вариант B — единственный, который достигает успеха около 0,78; при более мягком сроке обратная связь почти совпадает с ним при четверти стоимости. Сырая точность не может ранжировать три варианта, поскольку они тратят разные бюджеты; стоимость на принятую задачу при заданном сроке ставит их на одну шкалу.

Парето-фронт обдумывания

Построение эмпирического успеха задачи против потребления токенов и задержки по часам выявляет Парето-фронт обдумывания: множество оптимальных рабочих точек, в которых никакое альтернативное распределение вычислений вывода не может достичь более высокой точности без расхода дополнительных ресурсов или нарушения границ задержки («Парето-фронт обдумывания и режимы отказа»).

Парето-фронт обдумывания и режимы отказа: эмпирическая вероятность успеха задачи $P(\text{success})$, построенная против эффективной стоимости вычислений вывода $C_{\text{eff}}$ (токены на успешную задачу) по эмпирическому бенчмарку из таблицы «Производительность стратегий обдумывания». Жадный одношаговый подход дает низкозатратную базовую линию (1 163 токена, 44 процента точности). Основанное на глубине самоуточнение (Self-Refine) и параллельный Best-of-8 повышают точность, но оказываются ниже Парето-фронта из-за закрепления ложной посылки и накладных расходов неуправляемой выборки. Заземление обдумывания на обратной связи от исполнения внешних инструментов (ReAct) задает эмпирический Парето-фронт (4 939 токенов, 83 процента точности, 3 процента FAR), устраняя необоснованную эксплуатацию нейронного поиска.

Эмпирические компромиссы, визуализированные на рисунке «Парето-фронт обдумывания и режимы отказа», напрямую отображаются на многостратегический бенчмарк из таблицы «Производительность стратегий обдумывания». Базовая линия «Жадный одношаговый» задает нижний левый угол ($1163$ токена, $44\%$ проверенного успеха). Направление вычислений на последовательное самоуточнение поднимает успех до $58\%$, но обходится в $4482$ токена на успех из-за закрепления ложной посылки. Параллельный Best-of-8 достигает $71\%$ успеха, но расходует $5769$ токенов, пропуская $8\%$ ложного принятия. MCTS без заземления с обученной PRM достигает $76\%$ успеха, но требует непомерных $8684$ токенов и демонстрирует $11\%$ ложного принятия из-за гудхартинга верификатора. Доминирующий рабочий фронт задает ReAct с обратной связью внешних инструментов ($4939$ токенов, $83\%$ проверенного успеха, $3\%$ FAR). Опираясь на детерминированные компиляторы песочницы и зонды утверждений среды выполнения, система достигает строго более высокой точности при меньшей стоимости, чем чистый нейронный поиск. Это доказывает, что заземление в среде — необходимое условие Парето-эффективного обдумывания.

Как показано на кривой фронта, три вычислительные оси занимают в этом пространстве компромиссов разные рабочие ниши:

1. Режим глубины (последовательные дедуктивные цепочки): оптимален для задач с высокой плотностью внутренних ограничений и низким промежуточным ветвлением, таких как математические доказательства или синтез сложных алгоритмов. В этом режиме промежуточные токены рассуждения работают как черновик, стабилизирующий авторегрессионную траекторию модели. Однако предельная отдача от дополнительной глубины быстро падает: за критической длиной контекста дополнительные токены рассуждения вызывают блуждание, при котором модель начинает ставить под сомнение проверенные факты или теряет исходные ограничения.
2. Режим ширины (независимое исследование кандидатов): оптимален, когда пространство решений широко, существуют несколько несвязанных путей решения, а проверка кандидатов вычислительно дешева (например, проверки компиляции или детерминированные валидаторы схем). Выборка по ширине минимизирует задержку критического пути на высокопроизводительных движках вывода ценой огромного совокупного расхода токенов.
3. Режим обратной связи (исполнение, опосредованное средой): оптимален, когда внутренняя самокритика по своей природе не заземлена. Базовые модели демонстрируют серьезные слепые пятна, когда пытаются проверить собственные выходы чистой интроспекцией. Внедрение детерминированной обратной связи среды (сообщений об ошибках компилятора, трассировок сбоев тестов или исключений времени выполнения базы данных) закрепляет процесс обдумывания в эмпирической истине и разрывает круговые петли рассуждения.

# Системная проверка: фильтрация стратегий-кандидатов по операционному фронту Парето
def is_pareto_efficient(candidates: list[tuple[float, float, float]]) -> list[bool]:
    # candidates: список (стоимость, задержка, -точность)
    efficient = [True] * len(candidates)
    for i, c1 in enumerate(candidates):
        for j, c2 in enumerate(candidates):
            if i != j and all(x <= y for x, y in zip(c2, c1)) and any(x < y for x, y in zip(c2, c1)):
                efficient[i] = False
                break
    return efficient

Режимы отказа

Важно: обдумывание не всегда полезно. В широком классе операционных задач выделение дополнительных вычислений этапа тестирования дает отрицательный перенос: наблюдаемое явление, когда поиск ухудшает результат ниже базовой линии одного шага.

Отрицательный перенос возникает в основном через два механизма отказа:

• Ловушка чрезмерного обдумывания: при простых задачах с высокой уверенностью среда выполнения обдумывания, настроенная на обязательную рефлексию или поиск по дереву, часто порождает мнимую сложность. Модель трактует тривиальные требования как неоднозначные граничные случаи, галлюцинирует гипотетические угловые условия и переписывает краткое, правильное решение в переусложненную, ошибочную абстракцию.
• Закрепление ложной посылки: если ранний шаг последовательной цепочки рассуждений допускает тонкую смысловую ошибку, выделение дополнительной глубины рассуждения заставляет модель рационализировать и закреплять ошибку вместо ее исправления. Поскольку авторегрессионная генерация обращает внимание на собственный предшествующий контекст, галлюцинированная посылка становится неизменяемым историческим фактом внутри промпта и постоянно уводит нижестоящую дедукцию от правильного решения.

Чтобы строго зафиксировать эти компромиссы, «Производительность стратегий обдумывания» сопоставляет пять канонических топологий обдумывания при одинаковом потолке токенов ($T_{\text{total}}\le 8192\text{ токенов}$), сообщая 95-процентные доверительные интервалы по партиям эмпирических испытаний.