Курирование траекторий

Назначение

Почему обучение агента на собственных журналируемых траекториях так часто ухудшает его работу?

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

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

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

Диагностика разрыва возможностей

Исчерпание детерминированных уровней среды выполнения устраняет 90 % сбоев до перехода к переобучению модели, при разнице в задержке в четыре порядка.

Когда автономный агент миграции баз данных снова и снова проваливается на задачах изменения схемы в производственных кластерах, инженерная команда сталкивается с фундаментальной системной дилеммой. В журналах телеметрии агент выдает некорректные SQL-операторы при операциях ALTER TABLE, что вызывает откаты транзакций БД из-за исключений синтаксической ошибки. Первый эксплуатационный импульс во многих командах машинного обучения — отнести этот сбой к фундаментальному дефициту модели и немедленно запланировать дорогостоящее дообучение с учителем на тысячах отобранных скриптов миграции баз данных. Однако строгая криминалистическая декомпозиция трассы показывает, что схема инструмента, показанная модели, execute_sql(query: string), не указывала диалект и версию целевого движка базы данных. Не имея этого ограничения среды в подготовленном буфере контекста, модель по умолчанию использовала корректный синтаксис PostgreSQL, тогда как выполнение шло на действующем кластере MySQL 8.0. Обновление спецификации JSON-схемы с явным перечислением engine_dialect и внедрение версии целевого движка в окно контекста устранили 100 % сбоев мгновенно, без изменения ни одного веса модели.

Прежде чем выбирать адаптацию политики, инженеры среды выполнения должны строго диагностировать, вызван ли наблюдаемый сбой дефицитом информации, неоднозначным интерфейсом инструмента, дефектом среды выполнения или действительным дефицитом возможностей модели. Рассматривать адаптацию параметров как механизм исправления первой линии — архитектурный антипаттерн, известный как ловушка преждевременного дообучения. В проектировании компьютерных систем адаптация весов параметров $\Theta$ базовой модели — самое медленное ($T_{\text{train}}\ge 10^4\text{ с}$), самое капиталоемкое, наименее наблюдаемое и наименее обратимое воздействие во всем программном стеке агента. Тогда как изменение промпта в контексте, обогащение поискового запроса или исправление схемы инструмента выполняются с почти нулевой задержкой развертывания ($T_{\text{deploy}}\le 1\text{ с}$) и детерминированным откатом на уровне git, переобучение нейронной политики расходует огромные часы работы ускорительного кластера, инвалидирует структуры кеша вывода ниже по потоку и несет серьезный эксплуатационный риск катастрофического забывания ранее проверенных возможностей.

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

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

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

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

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

Четыре первопричины сбоя траектории: криминалистическая классификация аномалий выполнения по уровням среды перед началом адаптации модели.

Дефицит контекста возникает, когда поисковый движок, менеджер памяти или сборщик рабочего набора не может передать критически важное состояние среды в активное окно контекста модели. Агент проваливается не потому, что его внутренние веса рассуждений неспособны, а потому, что нужные факты — например, актуальная версия библиотеки, переменная окружения или импортированная сигнатура интерфейса — были вытеснены или так и не были получены. Неоднозначность интерфейса возникает, когда определения инструментов, типы параметров или семантические docstring-описания противоречивы, недоопределены или структурно не согласованы с нижележащей диспетчеризацией выполнения среды. Если агент выдает некорректные аргументы или не может вызвать существующую возможность, дефект почти всегда находится в контракте схемы, представленном модели, а не в способности нейронного ядра рассуждать. Дефект среды выполнения целиком возникает в подсистеме выполнения под моделью: таймауты запуска контейнера песочницы, потери сети microVM, завершения процессов ядром хоста при нехватке памяти (OOM-killer), несоответствия прав доступа к файловой системе или гонки при асинхронной диспетчеризации RPC. Дообучать модель с 70 миллиардами параметров, чтобы компенсировать эфемерный таймаут контейнера или необработанный разрыв сокета, — катастрофическое нерациональное расходование инженерных ресурсов.

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

Чтобы воплотить эту криминалистическую сортировку, среда выполнения агента применяет системную лестницу вмешательства. Инженеры систем должны исчерпать более дешевые, детерминированные и легко обратимые уровни, прежде чем переходить к стохастической адаптации параметров: $$\text{Внедрение контекста}\prec \text{Перепроектирование схемы инструментов}\prec \text{Укрепление среды выполнения}\prec \text{Адаптация политики с учителем}\prec \text{Обучение с подкреплением}$$

Эта последовательность напрямую воплощает классический сквозной принцип (end-to-end argument) в проектировании систем, сформулированный Солтцером, Ридом и Кларком (Saltzer et al., 1984): функция системы не должна реализовываться на более низком, более тяжелом уровне архитектуры, если ее можно полностью и корректно реализовать легковесными механизмами на границе приложения. Попытка «научить» агента сигнатуре API путем дообучения весов модели, когда в основе схемы инструмента нет явных ограничений типов, прямо нарушает этот принцип. Дообучение модели для компенсации дефектов интерфейса выше по потоку порождает хрупкое запоминание: как только меняется нижележащий API, обученные веса устаревают. Типизированный контракт действий (принцип «Типизированный контракт действий») и полный контекст, напротив, задают инварианты, которые выполняются для любой модели за ними.

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

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

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

• Шлюз 1 (телеметрия подсистемы выполнения) проверяет коды выхода cgroup ядра, срабатывания OOM-killer и таймауты microVM, чтобы выявить дефекты среды выполнения до того, как будут проверены веса модели.
• Шлюз 2 (окно контекста и рабочий набор) проверяет сборку токенов промпта и полноту извлечения относительно активного рабочего пространства, чтобы перехватить дефициты контекста, вызванные вытеснением состояния.
• Шлюз 3 (интерфейс инструмента и типизация схемы) сверяет выданные аргументы со строгой JSON-схемой и границами параметров, чтобы выделить неоднозначности интерфейса на границе контракта инструмента.
• Шлюз 4 (оракул инвариантов и дельта состояния) запускает герметичные наборы тестов и аудит разницы состояний (${\Delta }_{\text{fs}}$), чтобы отличить безвредные циклы повторов от настоящих неспособностей политики.

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

Компромиссы системной лестницы вмешательства

Задача: Среда выполнения автономного обслуживания программного обеспечения, развернутая в корпоративном кластере, обрабатывает $N=50000$ траекторий агента в месяц. Телеметрия показывает устойчивую долю сбоев $f=6\%$, что соответствует $M=3000$ неудачным траекториям в месяц. Криминалистический анализ выявляет, что $70\%$ этих сбоев происходят из неоднозначностей интерфейса в недавно добавленных схемах git-инструментов, $20\%$ — из таймаутов запуска контейнеров песочницы ($T>10\text{ с}$) на перегруженных рабочих узлах, и только $10\%$ ($300$ траекторий) представляют собой настоящие пробелы в возможностях политики в сложной логике рефакторинга нескольких файлов.

Инженерная команда оценивает два пути исправления. По стратегии A (системная лестница вмешательства) инженеры устраняют неоднозначности интерфейса строгими контрактами JSON Schema, укрепляют среду выполнения песочницы асинхронным пулом контейнеров и изолируют оставшиеся $300$ настоящих сбоев политики. По стратегии B (преждевременное дообучение) инженеры собирают все $3000$ необработанных неудачных траекторий, генерируют синтетические исправления и проводят полный прогон дообучения с учителем (SFT) открытой модели с 70 миллиардами параметров на узле с 8 GPU.

Оцените обе стратегии по трудозатратам инженеров, вычислениям обучения в FLOP, финансовым расходам, задержке развертывания и риску катастрофического забывания. Примите модель с $70\text{B}$ параметрами ($N_{\text{params}}=70\times 10^9$), среднюю длину последовательности $L=4096$ токенов за $E=3$ эпохи обучения, узел из 8 ускорителей NVIDIA H100 SXM5 ($989\text{ TFLOP/s}$ плотных вычислений BF16 на GPU при $45\%$ MFU), арендную ставку в облаке $\$3,50\text{ за GPU-час}$ и ставку труда инженеров $\$150\text{ в час}$.

Решение:

Стратегия A: системная лестница вмешательства (исправление схемы и укрепление среды выполнения). Обновление спецификаций OpenAPI и JSON-схем со строгими ограничениями перечислений и явной типизацией требует примерно $4$ инженерных часов. Внедрение асинхронного пула предварительно прогретых контейнеров в демоне песочницы требует $12$ инженерных часов, что доводит общие трудозатраты до $16\text{ ч}\times \$150/\text{ч}=\$2400$. Поскольку валидация схем и пулинг контейнеров выполняются целиком на существующей процессорной инфраструктуре хоста, вычислительные накладные расходы обучения составляют ровно ноль FLOP и ноль долларов за GPU. Обновления схем и конфигурации среды выполнения развертываются через непрерывную интеграцию за $T_{\text{deploy}}\le 15\text{ мин}$. Вмешательство полностью детерминировано: если изменение схемы вносит неожиданную регрессию, оно мгновенно откатывается через систему контроля версий, так что риск катастрофического забывания несвязанных возможностей равен нулю ($\Delta {\text{Acc}}_{\text{unrelated}}=0\%$). Главное, что это окончательно устраняет $70\%+20\%=90\%$ ежемесячных сбоев ($2700$ задач), а оставшиеся $300$ настоящих пробелов в политике помещаются в карантин для целевого курирования траекторий.

Стратегия B: преждевременное обучение с учителем. Дообучение авторегрессионного трансформера требует примерно $6\times N_{\text{params}}$ операций с плавающей точкой на токен за эпоху ($2$ FLOP на прямой проход и $4$ FLOP на обратное распространение градиента). При $3000$ траекториях, упакованных до $L=4096$ токенов и обученных за $E=3$ эпохи, набор данных содержит $1,2288\times 10^7$ токенов, что требует $1,548\times 10^{19}\text{ FLOPs}$ общих вычислений обучения. На узле из 8 ускорителей NVIDIA H100 SXM5, работающих при $45\%$ утилизации FLOP модели, пропускная способность кластера достигает $3,560\times 10^{15}\text{ FLOP/s}$, что дает фактическое время обучения $T_{\text{train}}\approx 4348\text{ с}$ ($1,21\text{ ч}$). С учетом токенизации набора данных, оценок контрольных точек, запусков обвязки оценки и квантования весов общая занятость кластера достигает $6\text{ ч реального времени}$, что дает $\$168$ сырых вычислительных затрат ($48\text{ GPU-ч}\times \$3,50/\text{ч}$). Курирование синтетических трасс, очистка набора данных, оркестрация конвейера обучения и аудит регрессий после обучения занимают $40$ инженерных часов ($\$6000$). Проверка контрольных точек, сравнительное тестирование регрессий на наборах задач по программированию и канареечный выпуск обслуживающего движка увеличивают задержку развертывания до $T_{\text{deploy}}\approx 48\text{ ч}$. Кроме того, стандартные посттренировочные оценки моделей на 70 миллиардов параметров, дообученных на узких трассах инструментов, часто показывают снижение точности $\Delta {\text{Acc}}_{\text{general}}\approx -2,5\%$ до $-4,0\%$ на общих бенчмарках рассуждений из-за дрейфа параметров. Важнее всего то, что поскольку первопричины на уровне системы — отсутствующие перечисления схемы и таймауты контейнеров — так и не были устранены в среде выполнения, дообученная модель по-прежнему страдает от таймаутов контейнеров, а когда внешние API инструментов меняют сигнатуры параметров, вновь обученные веса полностью устаревают.

Вывод: Стратегия A детерминированно устраняет $90\%$ сбоев с задержкой развертывания менее часа, нулевыми вычислительными накладными расходами и нулевым риском регрессии модели. Преждевременное дообучение по стратегии B влечет значительные инженерные издержки, увеличивает задержку развертывания на два порядка, вводит катастрофическое забывание и не устраняет лежащие в основе системные сбои.

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

Проектирование фикстур задач

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

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

Инвариант фикстуры задачи: Фикстура задачи $F=⟨S_0,{\mathcal{M}}_{\text{tool}},P_{\text{task}},{\mathcal{H}}_{\text{reset}},{\mathcal{O}}_{\text{verify}}⟩$ гарантирует, что для любых двух прогонов с одинаковыми затравками (seed) и детерминированным выводом переходы состояний $S_t\to S_{t+1}$ остаются побитово воспроизводимыми на любых воркерах выполнения.

Пять компонентов фикстуры агентной задачи

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

Базовая линия начального состояния ($S_0$) определяет неизменяемый эталонный снимок среды выполнения до появления агента. В инженерии программного обеспечения и анализе данных эту линию нельзя задавать расплывчато, как базовую операционную систему или текущий указатель ветки. Вместо этого она должна разрешаться в криптографический хеш: дайджест образа контейнера, адресуемый по содержимому (например, образ Docker, закрепленный по sha256), неизменяемый снимок файловой системы с копированием при записи или явный git-коммит SHA вместе с зафиксированными lock-файлами. Каждая общая библиотека, инструментальная цепочка компилятора, системный демон и вспомогательный конфигурационный файл должны находиться внутри этой замороженной границы. Если агент работает в окружении, где apt-get update или npm install при инициализации среды подтягивают незакрепленные пакеты из внешних источников, подсистема выполнения нарушает герметичность, и временные сравнения между контрольными точками моделей теряют смысл.

Манифест интерфейса инструментов (${\mathcal{M}}_{\text{tool}}$) задает формальные операционные границы, через которые модель наблюдает состояние и изменяет его. Поскольку модель не имеет никаких неявных полномочий, на манифест распространяется принцип наименьших привилегий, и инструменты никогда не должны открывать непосредственные привилегии хоста или непроверенные каналы RPC. Манифест задает строгие схемы под контролем версий (обычно в виде спецификаций OpenAPI или JSON Schema), которые объявляют точные типы параметров, обязательные поля и детерминированные ответы об ошибках. Там, где инструменты взаимодействуют с внешними сетями третьих сторон, фикстура предоставляет детерминированные имитационные серверы или заглушки воспроизведения. Перехватывая недетерминированный сетевой ввод-вывод и воспроизводя записанные фикстуры, среда выполнения защищает конвейер сбора траекторий от сбоев внешних API, ограничений частоты запросов и временного дрейфа полезной нагрузки.

Промпт спецификации задачи ($P_{\text{task}}$) инкапсулирует пользовательское намерение, предъявляемое политике. Архитектурная строгость требует, чтобы эта спецификация ясно формулировала цель, операционные границы и ожидания по завершению, не раскрывая привилегированных путей решения и пошаговых обоснований. Промпт должен избегать неоднозначных указательных местоимений («исправь эту проблему» без ссылки на соответствующий модуль), сохраняя при этом подлинную неоднозначность, с которой сталкиваются в реальных окружениях. Важно, что промпт должен определять, что считается отказом от продолжения, давая политике однозначные критерии того, когда прекратить выполнение, а не бесконечно зацикливаться в исследовательском состоянии декодирования.

Обвязка сброса за доли секунды (${\mathcal{H}}_{\text{reset}}$) определяет физический механизм возврата среды к $S_0$ между последовательными эпизодами. При крупномасштабном сборе траекторий воркеры генерируют миллионы шагов прогонов в тысячах параллельных окружений. Если сброс окружения требует холодного запуска контейнера, полного клонирования диска или установки зависимостей размером в несколько гигабайт, задержка подготовки окружения начинает доминировать над временем вывода на GPU и резко снижает утилизацию кластера. Высокопроизводительные движки сбора реализуют сброс за доли секунды через многослойные оверлеи с копированием при записи (CoW). Наложив поверх общего, доступного только для чтения нижнего базового слоя временную tmpfs в памяти или разреженное блочное устройство, воркер прогона может отбросить все изменения, очистить активные процессы ядра и заново смонтировать чистый слой выполнения менее чем за $500\text{ мс}$.

Свидетельство завершения: Заявление модели о том, что она закончила («Я выполнил задачу»), не имеет доказательной силы («Уровни свидетельств замыкания»). Оракул проверяет состояние, которое оставила после себя траектория.

Механический оракул верификации (${\mathcal{O}}_{\text{verify}}$) задает объективную истину, которая относит собранную траекторию к успеху или к неудаче. Принцип замыкания инвариантов («Принцип замыкания инвариантов») требует, чтобы это свидетельство поступало из-за пределов полномочий модели, поэтому оракул верификации полностью отделен от самооценки модели. Он состоит из автоматизированных наборов тестов, линтеров абстрактного синтаксического дерева (AST), проверок двоичного выполнения или проверок утверждений о состоянии базы данных, выполняемых в отдельном привилегированном процессе супервизора. Оракул оценивает измененное окружение относительно запечатанных приемочных инвариантов и выдает детерминированную двоичную оценку $y\in \{0,1\}$ или структурированный диагностический вектор. Если оракул опирается на незакрепленного LLM-судью, который оценивает завершенность траектории, в границу оценки возвращается стохастический дрейф, и целостность маховика данных оказывается под угрозой.

Источники данных траекторий

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

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

Демонстрации экспертов-людей — эталон педагогической ясности и синтаксической точности. Опытный инженер, работающий в инструментированной среде выполнения, дает плотные трассы выполнения, отличающиеся оптимальным выбором инструментов, аккуратным управлением контекстом и содержательными цепочками рассуждений (chain-of-thought). Однако человеческие данные имеют серьезные системные ограничения: они строго не масштабируемы, исключительно дороги и содержат минимальное разнообразие восстановления после сбоев. Поскольку опытные люди следуют каноническим путям решения, в их траекториях редко видны запутанные петли восстановления с откатами, которые автономным политикам приходится осваивать, когда инструменты возвращают частичные сбои или ненулевые коды выхода.

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

Синтетические прогоны модели снимают узкое место пропускной способности, сочетая масштабируемые движки вывода модели с автоматизированными фикстурами задач и оракулами верификации. С помощью выборки с отбраковкой (Best-of-$N$) базовая политика ${\pi }_{\theta }$ генерирует $K$ параллельных кандидатных прогонов на одной и той же фикстуре $F$. Оракул верификации ${\mathcal{O}}_{\text{verify}}$ механически отфильтровывает полученные трассы, отбрасывая неудачные пути и собирая проверенные завершения в буфер обучения политики. Хотя синтетическая генерация позволяет собирать миллионы токенов в день по стоимости товарного вывода, она несет серьезные статистические риски. Без агрессивной диверсификации фикстур синтетические прогоны страдают от mode collapse: политика раз за разом использует один и тот же узкий набор вызовов инструментов, чтобы удовлетворить оракул, лишая буфер обучения разнообразных траекторий исследования. Более того, модели, оптимизированные исключительно под синтетические наборы тестов, часто прибегают к обходу спецификации (specification gaming): выполняют букву утверждения теста, одновременно порождая неподдерживаемый, странный или уязвимый код.

# Атомарная очистка и пересоздание оверлея overlayfs с копированием при записи для сброса за доли секунды
umount /mnt/sandbox/merged
rm -rf /mnt/sandbox/upper/* /mnt/sandbox/work/*
mount -t overlay overlay \
  -o lowerdir=/mnt/fixtures/base,upperdir=/mnt/sandbox/upper,workdir=/mnt/sandbox/work \
  /mnt/sandbox/merged

Ввод-вывод хранилища кластера прогонов и задержка

Задача: Команда инженеров ИИ эксплуатирует распределенный кластер сбора траекторий, содержащий $W=512$ параллельных воркеров прогона. Каждый воркер работает на отдельном ядре ЦП и управляет непривилегированной песочницей выполнения над стандартной фикстурой корпоративного программного обеспечения (размер репозитория $S_{\text{repo}}=2,4\text{ ГБ}$). Средний эпизод траектории состоит из $T=15$ ходов взаимодействия и завершается за $T_{\text{exec}}=120\text{ с}$.

Оцените пропускную способность ввода-вывода хранилища и пропускную способность кластера при двух архитектурных решениях:

1. Наивное холодное повторное клонирование: воркер уничтожает каталог и между эпизодами выполняет новое локальное git-клонирование и загрузку зависимостей из кешированного локального архива. Задержка сброса составляет $t_{\text{cold}}=12\text{ с}$.
2. Копирование при записи (CoW) в OverlayFS: базовый репозиторий монтируется только для чтения (lowerdir). Все изменения воркера фиксируются в эфемерном верхнем слое на tmpfs (upperdir). Между эпизодами воркер выполняет атомарную последовательность «размонтировать — очистить — смонтировать заново», показанную выше. Средний объем мутаций за эпизод составляет ${\Delta }_{\text{mut}}=18\text{ МБ}$. Задержка сброса составляет $t_{\text{cow}}=65\text{ мс}$.

Расчет:

Случай 1: архитектура холодного повторного клонирования Полное время цикла одного эпизода равно: $${\tau }_{\text{cold}}=T_{\text{exec}}+t_{\text{cold}}=120\text{ с}+12\text{ с}=132\text{ с}$$

Скорость завершения эпизодов в кластере равна: $$R_{\text{cold}}=\frac{W}{{\tau }_{\text{cold}}}=\frac{512}{132\text{ с}}\approx 3,879\text{ эпизодов/с}$$

Каждый сброс требует записи всего репозитория размером $S_{\text{repo}}=2,4\text{ ГБ}$. Суммарная устойчивая пропускная способность записи, которую требует локальная подсистема хранения, равна: $$B_{\text{cold}}=R_{\text{cold}}\times S_{\text{repo}}=3,879{\text{ с}}^{-1}\times 2,4\text{ ГБ}\approx 9,31\text{ ГБ/с}$$

Устойчивая запись со скоростью 9,31 ГБ/с исчерпывает пропускную способность шины PCIe и ресурс записи стандартных корпоративных массивов NVMe, вызывая огромные очереди ожидания ввода-вывода. Кроме того, время простоя воркера, которое уходит на ожидание сбросов диска, составляет: $${\text{Доля простоя}}_{\text{cold}}=\frac{t_{\text{cold}}}{{\tau }_{\text{cold}}}=\frac{12}{132}\approx 9,09\%$$ За 24-часовой прогон кластер впустую тратит 1 117 часов работы воркеров только на запись дублирующих байтов на диск.

Случай 2: архитектура копирования при записи (CoW) Полное время цикла одного эпизода при CoW равно: $${\tau }_{\text{cow}}=T_{\text{exec}}+t_{\text{cow}}=120\text{ с}+0,065\text{ с}=120,065\text{ с}$$

Скорость завершения эпизодов в кластере возрастает до: $$R_{\text{cow}}=\frac{512}{120,065\text{ с}}\approx 4,264\text{ эпизодов/с}$$

Поскольку на диск записываются только мутации, которые затем отбрасываются из верхнего слоя в памяти, физическая пропускная способность записи на диск падает до: $$B_{\text{cow}}=R_{\text{cow}}\times {\Delta }_{\text{mut}}=4,264{\text{ с}}^{-1}\times 18\text{ МБ}\approx 76,75\text{ МБ/с}$$

Время простоя воркера снижается до: $${\text{Доля простоя}}_{\text{cow}}=\frac{0,065}{120,065}\approx 0,054\%$$

Системный вывод: Архитектура CoW снижает пропускную способность записи в хранилище в 121,3 раза, устраняет износ NVMe-накопителей и возвращает более $1100$ часов работы воркеров в сутки, которые раньше простаивали. Обвязки сброса за доли секунды — обязательное механическое требование крупномасштабного сбора траекторий.

Стратификация матрицы задач

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

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

Чтобы систематически наполнить обучающее распределение, инженеры среды выполнения организуют фикстуры в стратифицированную матрицу задач. Эта матрица упорядочивает экземпляры окружения по трем экспозициям H·S·A, описанным в разделе «Экспозиции H·S·A»:

• Горизонт ($H$): стратифицирован на поверхностные однократные команды ($H=1$), локализованные многоходовые сценарии ($H\in [2,5]$) и глубокое исследовательское решение задач ($H\in [10,50]$).
• Состояние ($S$): каждая фикстура несет контекст $S_1$ и рабочие файлы $S_2$, поэтому матрица стратифицирует состояние по длине подготовленного контекста $M$, разделяя его на компактные контексты ($2\text{k}$ токенов, ориентированные на локализованный рефакторинг AST), промежуточные контексты ($8\text{k}\text{–}16\text{k}$ токенов, характерные для навигации по модулям из нескольких файлов) и контексты масштаба репозитория ($32\text{k}\text{–}128\text{k}$ токенов, требующие иерархического поиска и извлечения из внешней памяти).
• Полномочия ($A$): классифицируются от чтения только для просмотра на уровне $A_0$ (с помощью grep, find или просмотра файлов), через локальные мутации в песочнице на уровне $A_1$ (например, редактирование исходного кода и запуск модульных тестов) до скоординированной оркестрации нескольких ресурсов — класса задач, который в производстве обладает $A_2$ (миграции баз данных, вызовы платежного шлюза или межсервисные RPC). Фикстура направляет эти вызовы на собственные заглушки, поэтому сам прогон остается на уровне $A_1$, а политика учится поведению $A_2$.

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

# Механическая спецификация верификации с двойным оракулом (парадигма SWE-bench)
def evaluate_trajectory_patch(workspace_path: str, test_patch: str) -> bool:
    # 1. Проверка устранения целевой ошибки (сбои должны перейти в успехи)
    f2p_result = run_pytest(workspace_path, test_patch, target="FAIL_TO_PASS")
    if f2p_result.failed != 0 or f2p_result.passed == 0:
        return False
    # 2. Защита от регрессий (должны сохраняться все существующие инварианты)
    p2p_result = run_pytest(workspace_path, test_patch, target="PASS_TO_PASS")
    return p2p_result.failed == 0 and p2p_result.passed > 0

Ключевой бенчмарк SWE-bench (Jimenez et al., 2024) иллюстрирует строгое применение стратифицированных фикстур задач, построенных на реальной истории разработки программного обеспечения. SWE-bench преобразует реальные pull request-ы на GitHub в воспроизводимые фикстуры агентов. Каждый экземпляр задачи объединяет точную базовую линию git-коммита ($S_0$), подлинную постановку проблемы, извлеченную из описания issue ($P_{\text{task}}$), и оракул верификации с двойным тестом (${\mathcal{O}}_{\text{verify}}$).

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

1. FAIL_TO_PASS: набор вновь введенных тестов, которые специально проверяют ошибку, описанную в $P_{\text{task}}$. Непропатченная кодовая база обязана проваливать эти тесты в $S_0$. Траектория принимается, только если предложенные агентом мутации переводят эти тесты из красного состояния в зеленое.
2. PASS_TO_PASS: полный исторический набор регрессионных тестов, который проходит в $S_0$. Мутации агента не должны нарушать никакую уже существующую функциональность. Если предложенное исправление устраняет целевую ошибку, но ломает несвязанный модуль, оракул фиксирует категориальный отказ.

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

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

Поэтапные каскады верификаторов

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

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

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

• Ступень 1 (синтаксис и AST): выполняется в памяти со стоимостью $c_1=50\text{ мкс}$, проверяя соответствие JSON-схеме и корректность AST. При условной доле прохождения $p_1=0,65$ она сбрасывает $35\%$ сырых предложений в сток отказов синтаксиса, оставляя $65,0\%$ выживших.
• Ступень 2 (статические инварианты): запускает линтеры на стороне хоста (ruff) и анализаторы типов (mypy) со стоимостью $c_2=120\text{мс}$ ($p_2=0,40$), отправляя еще $39,0\%$ исходного объема в сток статических нарушений и оставляя $26,0\%$ совокупного выживания.
• Ступень 3 (динамическая песочница): направляет выжившие кандидаты в одноразовые microVM ($c_3=8,5\text{с}$, $p_3=0,25$). Важно, что кандидаты, не прошедшие модульные проверки ($19,5\%$ сырого объема), не отбрасываются; вместо этого их направляют в сток трудных негативных примеров (${\tau }^{-}$), чтобы дать контрастивный обучающий сигнал для оптимизации предпочтений. Только $6,5\%$ предложений выдерживают это динамическое испытание.
• Ступень 4 (аудит дельты состояния): проверяет снимки файловой системы с копированием при записи ($c_4=450\text{мс}$, $p_4=0,85$), помещая подмену тестов и изменения файлов вне дерева проекта в сток карантина подмены, и дает $5,5\%$ выживания.
• Ступень 5 (семантическая сортировка): применяет рекомендательную оценку модели и аудит человеком ($c_5=15,0\text{с}$, $p_5=0,70$), чтобы подавить тавтологические решения; каждый отказ на этой ступени — решение человека-аудитора. Завершающим результатом становится золотой обучающий корпус с итоговым выходом $Y=3,87\%\approx 3,9\%$ ($3867$ из $100000$ прогонов) при амортизированной стоимости оценки $C_{\text{attempt}}=3,15\text{с}$ на кандидата.

Сырые трассы выполнения нельзя допускать в обучающие корпуса на основании самоотчета о завершении или одного прохода оценки. Кандидатные траектории вместо этого проходят нарастающий каскад независимых верификаторов — от синтаксической проверки за микросекунды до динамической изоляции за несколько секунд, и каждая ступень отсеивает недопустимые предложения с минимальными вычислительными затратами. Ступени поднимаются по уровням свидетельств замыкания из «Уровней свидетельств замыкания». Ступени 1 и 2 — статические проверки, ступень 3 запускает тесты, а монтирование тестов вне дерева проекта из «Защиты от обхода верификатора» делает эти тесты запечатанными, а не видимыми агенту. Допуск через этот конвейер никогда не устанавливает метафизическую правильность; он доказывает лишь, что траектория пережила конечную последовательность строгих эмпирических проверок опровержимости.

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

Архитектура верификации в пять ступеней

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

| 2. Инварианты | $1\text{–}100\text{мс}$ | Статическая типизация (mypy), линтинг (ruff), безопасность AST | Демон хоста | | 3. Динамика | $1\text{–}10\text{с}$ | Запуск тестов в песочнице (pytest), границы таймаута | Одноразовая microVM | | 4. Дельта | $100\text{мс}\text{–}2\text{с}$ | Проверка структурного диффа, проверки целостности схемы | Изолированный снимок файловой системы | | 5. Семантика | $5\text{–}30\text{с}$ | Рекомендательная стилистическая сортировка, аудит экспертом-человеком | Офлайн-очередь проверки |

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

Ступень 1 обеспечивает синтаксическую и схемную валидацию в памяти за микросекунды. Прежде чем запрашивать или менять какое-либо состояние окружения, верификатор проверяет структурное устройство траектории. Если агент вызвал инструмент, полезная нагрузка должна строго соответствовать ожидаемой JSON-схеме; если агент сгенерировал исходный код, код должен разбираться в корректное абстрактное синтаксическое дерево (AST). Пустые выходные буферы, обрезанные генерации, незакрытые строки-разделители и некорректные кодировки параметров немедленно отклоняются в памяти хоста, что применяет инвариант карантина (принцип «Инвариант карантина») к собранным трассам. Этот ранний фильтр гарантирует, что среда выполнения никогда не выделяет контейнер и не запускает фоновую оболочку для проверки скрипта, который не выдерживает базового лексического анализа.

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

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

Ступень 4 выполняет верификацию дельты состояния за время от нескольких сотен миллисекунд до двух секунд. Прохождение модульных тестов на ступени 3 — необходимое, но недостаточное условие допуска: ограниченный агент может пройти модульные тесты, одновременно внося разрушительные побочные эффекты в окружение. Ступень 4 аудирует дельту состояния ($\Delta S=S_{\text{post}}-S_0$) на границах окружения. Верификатор вычисляет точный дифф файловой системы относительно базового коммита и проверяет, что изменены только файлы из допустимого манифеста правок задачи. Он проверяет висящие дочерние процессы, оставшиеся временные файлы, незакоммиченные артефакты Git и целостность внешних ключей базы данных. Если траектория устранила ошибки в модульных тестах, но оставила осиротевшие lock-файлы или изменила немаппированные файлы за пределами разрешенного каталога рабочего пространства, ступень 4 отклоняет кандидата.

Ступень 5 завершает конвейер неблокирующей семантической сортировкой и аудитом человеком, работая в масштабе от нескольких секунд до нескольких минут. На этой ступени кандидатные траектории оцениваются по сопровождаемости кода, стилистической согласованности, архитектурной элегантности и семантической документированности. Этот слой регулируется важным архитектурным инвариантом: стохастические большие языковые модели, выступающие в роли автоматических судей, должны оставаться строго неблокирующими рекомендательными сигналами. Вспомогательная модель может вычислять оценку читаемости или упорядочивать очередь проверки, но автоматический нейронный судья никогда не должен обладать односторонним правом допускать или отклонять кандидатную траекторию. Окончательный допуск в золотые обучающие корпуса моделей зарезервирован исключительно за пересечением детерминированных механических верификаторов (ступени 1–4) и калиброванного аудита экспертом-человеком. Асимметрия верификации (принцип «Асимметрия верификации») проводит эту границу: шлюз фиксации должен быть детерминированной проверкой, которую агент не может изменить, а вторая модель в роли судьи такой проверки не дает.

Защита от обхода верификатора

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

--- a/tests/test_transaction_escrow.py
+++ b/tests/test_transaction_escrow.py
@@ -14,6 +14,5 @@ def test_escrow_settlement_under_partition():
     service = EscrowCoordinator(timeout_ms=500)
-    result = service.settle_batch(mock_unstable_network)
-    assert result.status == SettlementStatus.COMMITTED
-    assert result.reconciled_balance == 10000
+    # Обход утверждения о разбиении сети из-за таймаута
+    assert True

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

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

1. Монтирование тестов вне дерева проекта: каталог с набором тестов и скриптами оценки никогда не должен находиться по пути файловой системы, доступному агенту на запись. Среда выполнения монтирует авторитетный каталог тестов как строго доступный только для чтения том (mount -o ro) или подставляет набор тестов из внешнего монтирования хоста после того, как агент сигнализирует о завершении и передает управление выполнением.
2. Белый список дельты состояния: верификация ступени 4 должна сопоставлять дельту Git с криптографически хешированным манифестом неизменяемых файлов. Любая траектория, дифф которой затрагивает файлы в иерархии тестов, конфигурации сборки или определения CI, немедленно отклоняется с классификацией подмены — независимо от кодов выхода тестов.
3. Изоляция пространства имен и обезьяньего патчинга во время выполнения: в динамических языках, таких как Python, скрипт агента может импортировать обвязку тестирования и применить обезьяний патчинг (monkey-patch) к утверждениям времени выполнения (например, переопределив unittest.TestCase.assertTrue или заменив pytest.fail пустой функцией). Чтобы устранить подмену в памяти, выполнение тестов на ступени 3 должно идти в независимом интерпретаторе с чистым состоянием, запущенном напрямую супервизором хоста и изолированном от любых инициализационных скриптов или изменений переменных окружения, внесенных моделью.

Защита от подмены тестов

Защита от подмены тестов — это инвариант изоляции выполнения $\text{PathDiff}({\mathcal{W}}_{\text{src}}^{\prime },\text{HEAD})\cap {\mathcal{W}}_{\text{test}}=\varnothing$, требующий, чтобы фикстуры тестов верификации находились на неизменяемых монтированиях только для чтения, физически отделенных от изменяемого рабочего пространства агента во время сбора траекторий.

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

Bohrbugs и Heisenbugs при автоматизированной верификации траекторий

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

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

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

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

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

Формулировки «стоимость — выход»

Последовательная фильтрация отсекает 93,5 % некорректных предложений до дорогостоящего запуска тестов microVM, сокращая вычисления кластера на 68,6 %. Последовательное расположение фильтров верификации определяется явным экономическим компромиссом. Пусть попытка кандидатной траектории проходит каскад из $K$ последовательных ступеней с индексами $i\in \{1,2,\dots ,K\}$. Пусть $c_i$ — предельная вычислительная стоимость выполнения ступени $i$, измеряемая в нормированных вычислительных единицах или во времени выполнения. Пусть $p_i\in [0,1]$ — условная вероятность выживания кандидата, входящего в ступень $i$ (при $p_1=1,0$, что соответствует поступлению необработанных прогонов без проверки). Кандидат переходит на ступень $i+1$ тогда и только тогда, когда он удовлетворяет всем инвариантам, которые обеспечивает ступень $i$.

Ожидаемая вычислительная стоимость оценки одной сырой попытки траектории, $C_{\text{attempt}}$, выражается как накопленная сумма стоимостей ступеней, взвешенная по совокупной вероятности достижения каждого последующего шлюза:

$$C_{\text{attempt}}=c_1+p_1{c}_2+p_1{p}_2{c}_3+p_1{p}_2{p}_3{c}_4+\cdots +\left(\prod _{j=1}^{K-1}{p}_j\right)c_K$$

Аналогично, совокупный выход сбора $Y$, то есть доля сырых кандидатных прогонов, успешно проходящих все $K$ ступеней валидации, задается произведением всех условных долей прохождения ступеней в «совокупном выходе каскада»:

$$Y=\prod _{i=1}^K{p}_i$$

Центральная цель оптимизации конвейера сбора траекторий — минимизировать суммарную вычислительную стоимость на принятую качественную траекторию, $C_{\text{accepted}}=C_{\text{attempt}}/Y$. Рассмотрение «стоимости каскада верификатора» показывает математическое обоснование пятиступенчатой архитектуры: поскольку динамическое выполнение в песочнице ($c_3$) и семантическая сортировка ($c_5$) на порядки дороже синтаксического и статического анализа ($c_1,c_2$), условные доли прохождения $p_1$ и $p_2$ должны работать как агрессивные фильтры. Если инженер среды выполнения ставит дорогой набор тестов перед статическим линтингом, кандидаты с синтаксическими ошибками израсходуют полный бюджет выполнения в песочнице, прежде чем будут отброшены, и доведут $C_{\text{attempt}}$ до запретительных значений.

Экономика каскада верификации и пропускная способность

Задача: Кластер автономного сбора в области программной инженерии производит $N=100000$ сырых кандидатных прогонов траекторий в день. Инженер среды выполнения должен выбрать между двумя архитектурами конвейера:

1. Наивная монолитная архитектура: каждая кандидатная траектория сразу запускается в полном контейнеризированном интеграционном наборе (ступень 3), после чего следуют статический линтинг (ступень 2) и семантическая сортировка (ступень 5).
2. Поэтапный каскад верификаторов: конвейер применяет строго упорядоченный пятиступенчатый каскад (ступень 1 $\to$ ступень 2 $\to$ ступень 3 $\to$ ступень 4 $\to$ ступень 5).

Допустим, эмпирические стоимости выполнения ступеней и условные вероятности выживания, измеренные на двухсокетном хосте AMD EPYC 9654 (192 vCPU), таковы:

• Ступень 1 (синтаксис / AST): $c_1=50\text{ мкс}=0,00005\text{с}$, условная доля прохождения $p_1=0,65$
• Ступень 2 (статические инварианты): $c_2=120\text{мс}=0,12\text{с}$, условная доля прохождения $p_2=0,40$
• Ступень 3 (динамическая песочница): $c_3=8,5\text{с}$, условная доля прохождения $p_3=0,25$
• Ступень 4 (дельта состояния): $c_4=450\text{мс}=0,45\text{с}$, условная доля прохождения $p_4=0,85$
• Ступень 5 (семантическая сортировка): $c_5=15,0\text{с}$, условная доля прохождения $p_5=0,70$

Вычислите ожидаемое время вычислений на одну сырую попытку ($C_{\text{attempt}}$), суммарное время вычислений кластера, необходимое для обработки всех $100000$ прогонов, и итоговую экономию вычислений, которую дает поэтапный каскад.

Решение:

Шаг 1: вычисляем совокупный выход $Y$. Итоговый выход допуска по всем пяти ступеням равен: $$Y=p_1\times p_2\times p_3\times p_4\times p_5=0,65\times 0,40\times 0,25\times 0,85\times 0,70=0,038675(3,87\%)$$ Из $100000$ попыток в обучающий корпус продвигаются ровно 3 867 траекторий.

Шаг 2: оцениваем наивную монолитную архитектуру. В наивном конвейере каждое сырое предложение сразу несет стоимость динамической песочницы ($c_3=8,5\text{с}$). Только предложения, прошедшие ступень 3 ($25\%$), переходят к оставшимся ступеням. Ожидаемая стоимость одной попытки равна: $$C_{\text{naive}}=c_3+p_3{c}_2+(p_3{p}_2)c_5=8,5+(0,25\times 0,12)+(0,25\times 0,40\times 15,0)$$ $$C_{\text{naive}}=8,5+0,03+1,50=10,03\text{с}$$ Суммарное время вычислений на $100000$ попыток: $$T_{\text{naive}}=100000\times 10,03\text{с}=1003000\text{с}\approx 278,6\text{ядро-ч}$$

Шаг 3: оцениваем поэтапный каскад верификаторов. Применяя «стоимость каскада верификатора» в строгом порядке возрастания: $$C_{\text{cascade}}=c_1+p_1{c}_2+(p_1{p}_2)c_3+(p_1{p}_2{p}_3)c_4+(p_1{p}_2{p}_3{p}_4)c_5$$ Подставляем эмпирические параметры:

• Слагаемое 1: $c_1=0,00005\text{с}$
• Слагаемое 2: $p_1{c}_2=0,65\times 0,12=0,078\text{с}$
• Слагаемое 3: $p_1{p}_2{c}_3=(0,65\times 0,40)\times 8,5=0,26\times 8,5=2,21\text{с}$
• Слагаемое 4: $p_1{p}_2{p}_3{c}_4=(0,26\times 0,25)\times 0,45=0,065\times 0,45=0,02925\text{с}$
• Слагаемое 5: $p_1{p}_2{p}_3{p}_4{c}_5=(0,065\times 0,85)\times 15,0=0,05525\times 15,0=0,82875\text{с}$

Суммирование слагаемых дает:

$$C_{\text{cascade}}=0,00005+0,078+2,21+0,02925+0,82875=3,14605\text{с}$$ Суммарное время вычислений на $100000$ попыток: $$T_{\text{cascade}}=100000\times 3,146\text{с}=314605\text{с}\approx 87,4\text{ядро-ч}$$

Шаг 4: вычисляем системный дифференциал. $$\text{Экономия вычислений}=\frac{T_{\text{naive}}-T_{\text{cascade}}}{T_{\text{naive}}}=\frac{1003000-314605}{1003000}=\frac{688395}{1003000}\approx 68,6\%$$ Поэтапный каскад снижает потребление вычислений кластера на 68,6 процента, экономя более 191 ядро-часа в день при допуске ровно того же набора из 3 867 проверенных траекторий.

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

Обученные ранжировщики под шлюзом

Детерминированные проверки говорят, удовлетворила ли траектория оракул. Они ничего не говорят о том, какая из восьми проходящих траекторий для одной и той же задачи лучше всего подходит для обучения, была ли проходящая беседа о возврате средств вежливой или на каком ходу провалившаяся траектория пошла не так. Ответы на эти вопросы дают обученные модели: модели награды, обученные на предпочтениях людей, модели процессной награды, оценивающие отдельные шаги (Uesato et al., 2022; Lightman et al., 2024), и большие языковые модели (LLM) в роли судей, которым задается рубрика. «Верификация процесса» ввела их как верификаторы и показала, что их ошибки эксплуатируемы при отборе. «Оценка агентов» измеряет их калибровку, смещение и согласованность с детерминированными проверками.

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

• Упорядочить очередь аудита, чтобы рецензенты ступени 5 сначала видели самых сомнительных кандидатов.
• Выбирать среди проходящих траекторий, отдавая предпочтение самой короткой или самой чистой из нескольких, которые все прошли ступени 1–4.
• Находить ход расхождения в проваливающейся траектории, что размечает трудные негативные примеры и точки восстановления для «Курирования демонстраций восстановления».

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

Каскады допуска и их пределы

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

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

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

Оценка каскадов верификаторов и защит обвязки

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

• Порядок каскада: почему дешевые синтаксические проверки и статические линтеры должны предшествовать дорогому динамическому выполнению в песочнице microVM?
• Подмена тестов: как монтирование набора тестов как тома только для чтения (mount -o ro) не дает агентам удалять утверждения, чтобы создавать ложные успехи?
• Белый список дельты состояния: почему верификатор должен пересекать git diff рабочего пространства с неизменяемым манифестом путей, прежде чем принять задачу как выполненную?
• Экономический выход: как поэтапная фильтрация оптимизирует суммарную вычислительную стоимость $C_{\text{attempt}}$ для парка, собирающего тысячи траекторий в день?

Курирование демонстраций восстановления

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

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

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

Опасности ковариатного сдвига

Без демонстраций восстановления непреднамеренные ошибки запускают квадратичное накопление, которое пересекает порог отказа 50 процентов на шаге 14. Фундаментальный недостаток обучения агента исключительно на безупречных демонстрациях коренится в классической проблеме ковариатного сдвига в последовательном прогнозировании, впервые формализованной Стефаном Россом, Джеффри Гордоном и Дж. Эндрю Бэгнеллом (2011) в их анализе имитационного обучения. В стандартном режиме обучения с учителем обучающий корпус состоит из пар состояние–действие $(s_t,a_t)$, выбранных из распределения состояний, порожденного оптимальной экспертной политикой, $d^{{\pi }^{\ast }}(s)$. Однако при автономном прогоне непривилегированная политика агента ${\pi }_{\theta }$ порождает собственное, отличное распределение траекторий, $d^{{\pi }_{\theta }}(s)$.

Если агент, выполняющий многоходовую задачу, на любом дискретном шаге $t$ имеет независимую вероятность $ϵ$ допустить непреднамеренную ошибку или столкнуться с внешним сбоем окружения, он переходит в состояние вне распределения:

$$s_t\sim P(\cdot \mid s_{t-1},a_{t-1})\notin \text{supp}(d^{{\pi }^{\ast }})$$

Поскольку корпус, состоящий только из безупречных траекторий, не содержит никакой массы состояний с ненулевыми кодами выхода, некорректными JSON-ответами или сигналами операционной системы, политика не может обусловить свое следующее действие никакой выученной эвристикой восстановления. Вместо того чтобы выдать диагностический вызов инструмента (например, ls -la, чтобы проверить права доступа к файлам, или tail -n 50 /var/log/syslog, чтобы найти отсутствующую зависимость), агент выдает действия из высокоэнтропийного, некалиброванного распределения логитов. В таких условиях вероятность продолжать провал на каждом последующем шаге стремится к единице. Как показано в работе Росса и соавторов (Ross et al., 2011), ошибки в последовательном принятии решений накапливаются квадратично на горизонте выполнения длины $T$, давая ожидаемую совокупную границу отказа, которая растет как $O(ϵT^2)$, а не линейной частотой ошибок $O(ϵT)$ стандартного обучения с учителем.

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

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

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

Трехчастная таксономия траекторий

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

Трехчастная типология траекторий: сравнительные графы выполнения «состояние–действие» для безупречных прямых демонстраций, четырехфазных циклов самовосстановления и трудных негативных примеров, размеченных в точке необратимого расхождения ($t_{\text{div}}$).

Топологии «состояние–действие» этих трех классов непосредственно сопоставлены на «Трехчастной типологии траекторий»:

• Безупречные демонстрации (${\tau }_{\text{pristine}}$, левый столбец) проходят строго монотонный путь состояний от исходной фикстуры задачи $s_0$ через обоснованный контекст AST ($s_1$) и герметичные мутации рабочего пространства ($s_2$) к прохождению верификатора ($s_{\text{goal}}$), удовлетворяя $\text{Passed}(V_3)\wedge \text{Error}(o_t)=\varnothing$ в жестких границах ходов ($T\le 1,2\cdot T_{\min }$). Они составляют $60\text{–}70\%$ целевого корпуса SFT.
• Демонстрации восстановления (${\tau }_{\text{recover}}$, средний столбец) выполняют замкнутый четырехфазный цикл самовосстановления: сбой окружения, внедренный в $t_{\text{div}}$ (errno 13: Permission denied), переводит агента в состояние ошибки ($s_{\text{err}}$); политика выдает диагностические пробы только для чтения (stat), чтобы найти первопричину ($s_{\text{diag}}$); применяет атомарное исправление (chmod +x) и восстанавливает состояние в $t_{\text{rec}}$ ($s_{\text{healed}}$), чтобы добиться удовлетворения верификатора. Составляя $20\text{–}30\%$ корпуса, траектории восстановления дают причинные токены, которые ограничивают квадратичное накопление ошибок ($O(ϵT^2)$).
• Трудные негативные примеры (${\tau }_{\text{negative}}$, правый столбец) начинаются с корректных правдоподобных шагов ($s_0\to a_1$), но на шаге $t_{\text{div}}$ испытывают фатальное расхождение — например, удаление утверждений или генерацию некорректных аргументов, — и коллапсируют в авторегрессионную ловушку зацикливания ($h(s_t)==h(s_{t-k})$), прежде чем остановиться в терминальном стоке (${\tau }^{-}$). Составляя $\sim 10\%$ наборов данных о предпочтениях, эти парные негативные примеры обучают контрастивные целевые функции (такие как DPO и функция потерь неправдоподобия RLVR), чтобы штрафовать обманчивые паттерны завершения.

1. Безупречные демонстрации (${\mathcal{T}}_{\text{pristine}}$): эти траектории представляют собой пути с минимальным числом ходов, монотонно продвигающиеся от исходной фикстуры задачи $S_0$ до подтвержденного достижения цели. Каждый вызов инструмента удается с первой попытки; аргументы синтаксически и семантически оптимальны; диагностических откатов не происходит. Безупречные демонстрации задают фундаментальное индуктивное смещение модели по отношению к грамматике инструментов, соблюдению схем API и экономному по токенам планированию. Без них агент становится чрезмерно многословным, выполняя избыточные проверки перед рутинными действиями.
2. Траектории восстановления и самовосстановления (${\mathcal{T}}_{\text{recover}}$): эти траектории содержат один или несколько промежуточных сбоев выполнения, за которыми следуют успешная диагностическая проверка, пересмотр гипотезы, корректирующее действие и в итоге выполнение инварианта. Корректная траектория восстановления имеет отчетливую четырехфазную структуру:
   • Событие сбоя: окружение возвращает явный сигнал трения (например, errno 13: Permission denied, заголовок ограничения частоты HTTP 429 или синтаксическую ошибку компилятора).
   • Диагностическая проверка: вместо повторения неудачного вызова политика вызывает инструменты диагностики только для чтения, чтобы проверить состояние окружения (id, stat, cat config.json).
   • Исправление: политика применяет атомарную корректирующую мутацию (например, chmod 644, обновление заголовка авторизации, исправление синтаксической ошибки).
   • Возобновление: агент повторно выполняет исходное намерение и продолжает, пока не удовлетворит верификатор задачи.
3. Демонстрации трудных негативных примеров (${\mathcal{T}}_{\text{negative}}$): эти траектории представляют катастрофические или неустранимые сбои, которые завершились нарушением инвариантов, циклами выполнения или таймаутами песочницы. Важно, что трудный негативный пример — это не неструктурированный случайный шум; это траектория, в которой первоначальный путь политики был правдоподобен, но конкретное неверное решение вызвало необратимое расхождение состояний. Конвейер сбора извлекает такие трассы и размечает точную точку расхождения — дискретный шаг $t_{\text{div}}$, на котором агент перевел систему из восстанавливаемого состояния в сток, нарушающий инварианты. Структурные сигнатуры, основные функции обучения и инварианты фильтрации этих трех поведенческих классов сведены в «Трехчастной таксономии траекторий».

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

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

// Различие метаданных трасс: восстановление и трудный негативный пример
{
  "trace_id": "traj-8492-recov",
  "fault_injected": "ERRNO_13_ACCES",
  "fault_turn": 4,
  "diagnostic_turns": [5, 6], // "ls -la /build", "whoami"
  "remediation_turn": 7,       // "chmod +x /build/compile.sh"
  "terminal_status": "VERIFIER_PASS"
}
// ----------------------------------------------------
{
  "trace_id": "traj-9104-neg",
  "divergence_turn": 4,        // Выполнено "rm -rf /" вместо "./"
  "invariant_violated": "INV_FILESYSTEM_ROOT_INTEGRITY",
  "terminal_status": "VERIFIER_FAIL_TERMINAL"
}

Синтез внедрения сбоев

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

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

| Сбои команд | Код выхода 127 (command not found), 126 (permission denied), 1 (ошибка) | Проверить окружение, установить или найти исполняемый файл, исправить права доступа | | Файловая система и состояние | Отсутствующий файл, переполненный диск, маркеры конфликта слияния | Найти файл, освободить место, отредактировать маркеры конфликта и подготовить результат | | Сеть и сервис | HTTP 429, HTTP 504, разорванное соединение | Учитывать заголовки повтора, делать паузу или обходить неисправную конечную точку | | Некорректные или обрезанные данные | Ошибка разбора JSON, обрезанный вывод | Повторно выдать корректный вызов или запросить вывод постранично |

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

Обвязка внедрения сбоев работает как детерминированный прокси-слой, встроенный между средой выполнения агента и нижележащей песочницей выполнения. Используя перехваты на уровне ОС — такие как перехват через ptrace, предзагрузку динамического компоновщика (LD_PRELOAD) или собственную обертку виртуальной файловой системы (VFS), — обвязка перехватывает стандартные вызовы выполнения инструментов и внедряет синтетические сбои в соответствии с заданным расписанием возмущений:

• Возмущения файловой системы: имитация исчерпания хранилища (ENOSPC), монтирования файловой системы только для чтения (EROFS), отсутствия прав на запись (EACCES) или висячих символических ссылок во время изменения файлов.
• Возмущения процессов и выполнения: внедрение отсутствующих общих библиотек (порча LD_LIBRARY_PATH), неустановленных инструментальных цепочек компилятора, завершений по нехватке памяти (SIGKILL через cgroups Linux) или коллизий с устаревшими lock-файлами (EEXIST).
• Возмущения сети и RPC: внедрение кратковременных HTTP 429 (Too Many Requests), HTTP 503 (Service Unavailable), поврежденных полезных нагрузок JSON-ответов или потерянных TCP-пакетов во время обмена с инструментом.

Структурная достижимость
Внедрение сбоя корректно тогда и только тогда, когда состояние окружения после сбоя $S^{\prime }$ сохраняет непустое множество путей достижимости цели: $\text{Paths}(S^{\prime }\to S_{\text{goal}})\ne \varnothing$. Внедрение неустранимых сбоев вырождает качество набора данных в случайный шум.

Внедрение сбоев подчинено важному инженерному ограничению: инварианту структурной достижимости. Синтезированный сбой должен устраняться инструментами, доступными в манифесте агента ${\mathcal{M}}_{\text{tool}}$. Если обвязка имитирует отсутствие библиотеки, удаляя менеджер пакетов, или полностью обрывает сетевой интерфейс без локального запасного варианта, агент не может решить эту дилемму. Внедрение неустранимого сбоя не порождает траекторию восстановления; оно тратит вычислительные циклы и создает только неинформативные негативные примеры. Обвязка должна поддерживать детерминированную проверку, подтверждающую, что для каждого профиля внедренного сбоя существует верифицированная последовательность восстановления.

Пропорции состава корпуса

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

Если обучающее распределение политики избыточно представлено траекториями восстановления ($>40\%$ от всех токенов), модель развивает операционную паранойю. Наблюдая подавляющую частоту неожиданных ошибок после стандартных вызовов инструментов, политика начинает выдумывать риски там, где их нет. Перед выполнением простого git status или компиляцией тривиального теста чрезмерно чувствительный агент проводит избыточные предполетные проверки: вызывает whoami, проверяет место на диске командой df -h и проверяет сетевые сокеты. Такое чрезмерно защитное поведение раздувает потребление окна контекста, увеличивает задержку по реальному времени и повышает стоимость обслуживания, не улучшая доли успешного выполнения задач.

И наоборот, если набор данных избыточно представлен демонстрациями трудных негативных примеров ($>20\%$), у политики развивается выученная беспомощность, или чрезмерное поведение отказа. Получая сложные, неоднозначные постановки задач, агент предсказывает, что катастрофический сбой неизбежен, и предпочитает выдавать токены отказа или непрерывно оговариваться, вместо того чтобы решительно действовать в окружении.

Эмпирическая системная оценка показывает, что оптимальная устойчивость политики достигается за счет асимметричной смеси корпуса:

$${\mathcal{D}}_{\text{train}}=\alpha \cdot {\mathcal{T}}_{\text{pristine}}\cup \beta \cdot {\mathcal{T}}_{\text{recover}}\cup \gamma \cdot {\mathcal{T}}_{\text{negative}}$$

где коэффициенты смешивания ограничены:

$$\alpha \in [0,60,0,70],\beta \in [0,20,0,30],\gamma \approx 0,10$$

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

Распределение бюджета токенов при смешанном курировании

Задача: команда инженеров ИИ-систем собирает набор данных для дообучения из $N=50000$ верифицированных траекторий для кодирующего агента с 70 миллиардами параметров. Инфраструктура обслуживания задает максимальное окно контекста $T_{\max }=32768$ токенов.

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

• Безупречные трассы (${\mathcal{T}}_{\text{pristine}}$): среднее число ходов ${\bar{k}}_{\text{p}}=6$. Средняя длина последовательности ${\bar{L}}_{\text{p}}=7200$ токенов.
• Трассы восстановления (${\mathcal{T}}_{\text{recover}}$): среднее число ходов ${\bar{k}}_{\text{r}}=14$ (4 хода начального выполнения, 1 ход сбоя, 4 диагностических хода, 2 хода исправления и 3 хода завершения). Средняя длина последовательности ${\bar{L}}_{\text{r}}=18500$ токенов.
• Трудные негативные примеры (${\mathcal{T}}_{\text{negative}}$): обрезаются на ходе расхождения плюс 2 исследовательских хода после расхождения. Среднее число ходов ${\bar{k}}_{\text{n}}=8$. Средняя длина последовательности ${\bar{L}}_{\text{n}}=9800$ токенов.

Инженерный руководитель задает целевое соотношение смешивания траекторий: $\alpha =0,65$ безупречных, $\beta =0,25$ восстановления и $\gamma =0,10$ трудных негативных примеров.

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

---

Решение:

Шаг 1: распределение числа траекторий
Используя целевые коэффициенты смешивания для $N=50000$ траекторий: $$N_{\text{pristine}}=0,65\times 50000=32500\text{ траекторий}$$ $$N_{\text{recover}}=0,25\times 50000=12500\text{ траекторий}$$ $$N_{\text{negative}}=0,10\times 50000=5000\text{ траекторий}$$

Шаг 2: общий объем токенов и эффективное распределение токенов
Умножим число траекторий на соответствующие средние длины последовательностей: $${\text{Tokens}}_{\text{pristine}}=32500\times 7200=234000000\text{ токенов (234,0 млн)}$$ $${\text{Tokens}}_{\text{recover}}=12500\times 18500=231250000\text{ токенов (231,25 млн)}$$ $${\text{Tokens}}_{\text{negative}}=5000\times 9800=49000000\text{ токенов (49,0 млн)}$$

Общий объем токенов ${\mathcal{V}}_{\text{total}}$ равен: $${\mathcal{V}}_{\text{total}}=234,0+231,25+49,0=514,25\times 10^6\text{ токенов (514,25 млн)}$$

Теперь вычислим эффективную долю на уровне токенов для каждого класса: $${\text{Share}}_{\text{pristine}}=\frac{234,00}{514,25}\approx 45,50\%$$ $${\text{Share}}_{\text{recover}}=\frac{231,25}{514,25}\approx 44,97\%$$ $${\text{Share}}_{\text{negative}}=\frac{49,00}{514,25}\approx 9,53\%$$

Шаг 3: системные следствия и экономический анализ
Хотя траектории восстановления составляют лишь $25\%$ от сырого числа траекторий (12 500 из 50 000), их диагностическая многословность и увеличенное число ходов приводят к тому, что они генерируют 44,97 процента всех токенов обучения с учителем.

При стандартном представлении float16 (2 байта на параметр или токен в следе градиента в загрузчиках данных) набор данных занимает более 1,028 ГБ упакованного хранилища токенов. Еще важнее, что разброс длин последовательностей (${\bar{L}}_{\text{r}}=18500$ против ${\bar{L}}_{\text{p}}=7200$) создает серьезные трудности упаковки в памяти при распределенном обучении. Если батчи наивно дополняются до самой длинной последовательности в микробатче, батчи, содержащие траектории восстановления, понесут значительные накладные расходы на хвостовое дополнение. Поэтому конвейер обучения должен реализовать динамическую упаковку последовательностей (например, конкатенированную упаковку нескольких траекторий с маскированием перекрестного внимания), чтобы сохранять высокую загрузку тензорных ядер во время обновлений градиентов.

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

Цикл самосовершенствования

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

Выборка с отбраковкой и экспертная итерация

Цикл состоит из четырех шагов. Текущая политика ${\pi }_n$ пробует каждую фикстуру $k$ раз. Каскад допускает успешные попытки. Обучение на них дает ${\pi }_{n+1}$ (см. «Дообучение на траекториях»). Новая политика оценивается на отложенной выборке и, если проходит шлюзы выпуска, становится сэмплером для следующего раунда. Фильтрация выходов сэмплера верификатором и обучение на выживших — это дообучение методом выборки с отбраковкой (rejection sampling fine-tuning). Повторение этого с каждой новой политикой в роли сэмплера — это экспертная итерация, а тот же шаблон, где в роли обучающего сигнала выступают собственные успешные рассуждения модели, лежит в основе методов бутстрэп-рассуждений (Zelikman et al., 2022). Верификатор играет роль, которую в обычном случае играл бы эксперт-демонстратор, поэтому корректность каскада ограничивает то, чему может научиться цикл.

Где находится обучающий сигнал

Не каждая фикстура приносит вклад. Если политика успешно решает задачу с вероятностью $p$ за попытку, то среди $k$ независимых попыток задача дает хотя бы один успех с вероятностью $1-(1-p{)}^k$ и ничего нового не дает, когда все попытки уже успешны, с вероятностью $p^k$. Информативная доля равна

$$P_{\text{inform}}(p,k)=1-(1-p{)}^k-p^k$$

При $k=8$ «информативность курирования траекторий» показывает: задача, которую политика решает в 5 процентах случаев, информативна с вероятностью около 0,34; задача, которую она решает в половине случаев, — с вероятностью около 0,99; а задача, которую она решает в 95 процентах случаев, снова с вероятностью около 0,34. Задачи, которые политика никогда не решает, не дают успехов, а задачи, которые она решает всегда, дают траектории, которые она и так производит. Сигнал сосредоточен в средней полосе трудности, и бюджет выборки цикла должен находиться именно там. Доли прохождения по задачам из «Разделения скрытого потенциала и надежности» позволяют определить эту полосу, а генерация фикстур должна поддерживать ее заполненной по мере улучшения политики.

Устаревание и обновление

Траектории, взятые из ${\pi }_n$, описывают то, что делает ${\pi }_n$. Как только обучение производит ${\pi }_{n+1}$, корпус становится внеполитичным (off-policy). Задачи, которые находились в информативной полосе, сдвинулись к решенному краю, а ошибки, после которых стоит учиться восстановлению, — уже не те, что делает ${\pi }_{n+1}$. Обучение с учителем переносит раунд или два устаревания, но корпус, который переиспользуется во многих раундах, продолжает учить поведению старой модели. Практическое правило: перед каждым раундом обучения пересэмплировать каждую фикстуру полосы новой политикой и записывать дайджест политики сэмплирования в каждую траекторию («Отслеживание происхождения траекторий»), чтобы устаревшие траектории можно было находить и выводить из обращения. Обучение с подкреплением по верифицируемым наградам (RLVR) сталкивается с той же проблемой в гораздо меньшем масштабе времени, где разрыв между сэмплером и обучаемым измеряется в шагах градиента.

Коллапс

Модель, которую многократно обучают на собственных выходах, теряет хвосты своего распределения. Редкие, но допустимые стратегии выбираются реже, допускаются реже и на них обучаются реже, пока совсем не исчезнут (Shumailov et al., 2024). Для агента симптомы измеримы. Число различных последовательностей действий на фикстуру падает. Pass@1 растет, тогда как pass@$k$ при больших $k$ остается неизменным, что «Разделение скрытого потенциала и надежности» трактует как политику, концентрирующуюся на стратегиях, которые у нее уже были, а не приобретающую новые. Качество на отложенных семействах задач стоит на месте, тогда как на обучающих семействах оно по-прежнему растет.

Четыре меры поддерживают цикл в здоровом состоянии:

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

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

Сигналы обратной связи из производства

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

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

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

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

Архитектура конвейера сбора

Выполнение тысяч многоходовых траекторий автономных агентов в реальных программных окружениях выявляет фундаментальное рассогласование между слоями вычислительного стека. Воркер авторегрессионного прогона ограничен пропускной способностью памяти GPU при декодировании и выдает пачки токенов с перерывами на протяжении десятков секунд. Напротив, песочница окружения, которая исполняет bash-вызовы агента, изменения файлов и вызовы компилятора, меняет локальное состояние ядра, расходует изменчивые блоки хранилища и выделяет сетевые пространства имен хоста. Когда непроверенные кандидатные траектории завершают взаимодействие с окружением, их нужно передать в пул верификации, состоящий из статических линтеров, герметичных средств запуска тестов и вторичных нейронных дискриминаторов, задержки выполнения которых охватывают четыре порядка величины: от $15\text{ мс}$ на разбор абстрактного синтаксического дерева (AST) до $180\text{ с}$ на полный интеграционный набор системы с синтетическими сетевыми задержками.

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

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

Топология распределенного конвейера

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

• Ступень 1 (диспетчер задач) управляет хранилищем фикстур репозитория ($S_0$), спецификациями задач ($P_{\text{task}}$) и манифестами инструментов (${\mathcal{M}}_{\text{tool}}$), выдавая аренды по запросу ($T_{\text{lease}}=2\times T_{\max }$) через движок приоритетов с активным регулятором частоты аренд ($P_{50}=2\text{мс}$).
• Ступень 2 (парк прогонов) размещает непривилегированные супервизоры агентов, взаимодействующие с GPU-декодерами vLLM с непрерывной пакетной обработкой ($P_{50}=8\text{с}$). Супервизор не дает модели никаких неявных полномочий, передавая все выполнения оболочки и компилятора через опосредованные границы RPC.
• Ступень 3 (пул эфемерных песочниц) поддерживает прогретые приостановленные снимки microVM Firecracker ($P_{50}=8\text{мс}$). Используя таблицы страниц с копированием при записи (CoW) и локальные оверлеи NVMe, воркеры возобновляют чистые фикстуры за время менее $10\text{мс}$, возвращают супервизору дельты наблюдений (${\Delta }_{\text{fs}}$) и проходят асинхронное свертывание.
• Ступень 4 (промежуточная шина и верификаторы) буферизует сырые полезные нагрузки (${\tau }_{\text{raw}}\approx 8,5\text{МБ}$) в долговечный кольцевой буфер Kafka ($P_{50}=120\text{мс}$), а CPU-воркеры выполняют многоуровневый каскад верификаторов ($V_1\to V_2\to V_3$). Когда глубина очереди $L_q>Q_{\max }$ (интенсивность трафика $\rho =\lambda /\mu \ge 0,85$), ступень верификации активирует петлю обратной связи обратного давления по замкнутому контуру, сигнализируя регулятору частоты аренд диспетчера о необходимости ограничить частоту аренд прогонов ${\lambda }_{\text{rollout}}$.
• Ступень 5 (стоки хранения и разбиения) принимает проверенные трассы (${\tau }_{\text{ver}}$) в колоночные наборы данных Apache Arrow / Parquet ($P_{50}=50\text{мс}$), вычисляет печати происхождения HMAC ($H_{\text{lineage}}$) и разделяет данные на разбиения, непересекающиеся по семействам репозиториев, между чистым хранилищем обучения (${\mathcal{D}}_{\text{train}}$) и стоком карантина трудных негативных примеров (${\tau }^{-}$).

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

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

Жизненный цикл отдельной траектории начинается у диспетчера задач. Диспетчер ведет приоритетную очередь дескрипторов фикстур задач ($\mathcal{F}=⟨S_0,{\mathcal{M}}_{\text{tool}},{\mathcal{P}}_{\text{task}},K⟩$). Он присваивает каждой задаче криптографическую затравку, которая гарантирует детерминированную инициализацию генератора псевдослучайных чисел (PRNG) при повторных прогонах. Вместо того чтобы проталкивать работу прямо на вычислительные узлы, диспетчер предоставляет протокол аренды по запросу. Когда простаивающий воркер в парке прогонов запрашивает задачу, диспетчер сдает фикстуру в аренду на время $T_{\text{lease}}=2\times T_{\max }$, где $T_{\max }$ — жесткий таймаут выполнения задачи. Если воркер прогона не выдает сигнал живости до истечения $T_{\text{lease}}$, диспетчер возвращает фикстуру в очередь с увеличенным счетчиком повторов.

Воркер прогона выступает как непривилегированный супервизор хоста без состояния. Он выполняет цикл агента: запросы на генерацию токенов отправляются по gRPC в кластер вывода (например, vLLM или SGLang с высокопроизводительным спекулятивным декодированием), а кандидатные действия с инструментами опосредуются при нулевых неявных полномочиях. Воркер прогона не выполняет команды локально. Вместо этого он получает аренду на выполнение из пула эфемерных песочниц.

Чтобы действия агента не загрязняли хост и не перекрестно влияли на параллельные запуски, каждая траектория закрепляется за изолированной аппаратной виртуальной машиной (например, microVM Firecracker) или непривилегированной контейнерной песочницей. Вместо того чтобы нести многосекундную задержку на загрузку нового ядра Linux или на запуск docker run с нуля, пул песочниц поддерживает прогретый резерв приостановленных снимков microVM. Используя таблицы страниц с копированием при записи (CoW) и оверлейное блочное хранилище на локальных массивах NVMe, воркер возобновляет идентичный базовый снимок $S_0$ менее чем за $10\text{ мс}$.

По завершении траектории — вызванном явным стоп-токеном, исчерпанием бюджета или неустранимым сбоем песочницы — воркер прогона сериализует полную последовательность событий $\tau =(s_0,a_0,o_0,\dots ,a_T,o_T)$ в компактный буфер протокола и ставит ее в очередь на промежуточной шине верификации. Воркер немедленно возвращает свою microVM менеджеру песочниц для фонового свертывания, отделяя аппаратуру вывода от постобработки и оценки.

Пул воркеров верификации извлекает сырые траектории из очереди и подвергает их поэтапным каскадам, установленным в разделе «Поэтапные каскады верификаторов»:

1. Ступень 1 выполняет быструю статическую верификацию ($V_1$), проверяя форматирование JSON, синтаксис патча и корректность AST. Траектории, не прошедшие $V_1$, сразу сортируются как кандидаты в трудные негативные примеры или отбрасываются, минуя дорогие последующие ступени.
2. Ступень 2 создает герметичный тестовый контейнер для запуска детерминированных модульных и регрессионных наборов тестов ($V_2$).
3. Ступень 3 (если применимо) выполняет семантические проверки ($V_3$) с изолированными инструментальными цепочками компиляторов. Вторичная модель-дискриминатор может также оценить траекторию, чтобы упорядочить человеческую проверку, но, как того требует «Архитектура верификации в пять ступеней», она никогда сама по себе не допускает и не отклоняет траекторию.

Траектории, прошедшие порог верификации $c^{\ast }$, помечаются полными метаданными выполнения (коды статуса, реальное время выполнения, дифф патчей и сводки верификаторов) и передаются в сток хранения. Сток хранения ведет отображаемые в память кольцевые буферы, которые пакуют поступающие трассы в колоночные пакеты Apache Arrow и периодически сбрасывают сжатые файлы Parquet в распределенное объектное хранилище. Колоночный формат выравнивает последовательности токенов, полезные нагрузки вызовов инструментов и метки верификаторов в непрерывные байтовые векторы, оптимизируя пропускную способность ввода-вывода последующего распределенного обучения.

Управление обратным давлением

Поскольку отдельные ступени конвейера сбора имеют резко различные распределения времени обслуживания, неуправляемая архитектура неизбежно будет колебаться между катастрофическим исчерпанием памяти и голоданием воркеров. Пусть ${\lambda }_{\text{rollout}}$ обозначает среднюю интенсивность поступления завершенных траекторий из парка прогонов, а ${\mu }_{\text{verify}}$ — совокупную интенсивность обслуживания пула воркеров верификации.

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

$$\rho =\frac{{\lambda }_{\text{rollout}}}{{\mu }_{\text{verify}}}<1$$

Однако ни ${\lambda }_{\text{rollout}}$, ни ${\mu }_{\text{verify}}$ не являются детерминированными. Частота завершения прогонов ${\lambda }_{\text{rollout}}$ колеблется вместе с длиной авторегрессионной последовательности, глубиной вызовов инструментов и сетевой задержкой до движков вывода. Что серьезнее, распределение времени обслуживания верификации $B(t)$ сильно скошено вправо: синтаксическая верификация ($V_1$) завершается за десятки миллисекунд, тогда как проваливающийся модульный тест в $V_2$ может крутиться до таймаута в $120\text{ с}$. Если пачка задач демонстрирует неожиданную регрессию, которая вызывает каскад таймаутов тестов, ${\mu }_{\text{verify}}$ обваливается до двух порядков величины.

Применяя закон Литтла ($L=\lambda W$), получаем, что среднее число траекторий, накапливающихся в промежуточном буфере верификации ($L_q$), равно произведению интенсивности поступления $\lambda$ и среднего времени ожидания в очереди ($W_q$):

$$L_q={\lambda }_{\text{rollout}}\cdot W_q={\lambda }_{\text{rollout}}\left(\frac{\rho }{{\mu }_{\text{verify}}(1-\rho )}\right)\cdot \left(\frac{C_a^2+C_s^2}{2}\right)$$

где $C_a^2$ и $C_s^2$ — квадраты коэффициентов вариации для интервалов между поступлениями и времен обслуживания соответственно (аппроксимация Кингмана для системы $G/G/1$). Поскольку наборы программных тестов имеют распределения времени выполнения с тяжелым хвостом ($C_s^2\gg 1$), любой устойчивый всплеск, при котором ${\lambda }_{\text{rollout}}\to {\mu }_{\text{verify}}$, приводит к взрывному росту $L_q$.

Поскольку каждый буфер протокола сырой траектории содержит полные многоходовые истории выполнения — включая дампы stdout/stderr окружения, промежуточные git diff и телеметрию высокого разрешения, — сериализованный объем одной траектории в памяти в среднем составляет ${\bar{S}}_{\text{traj}}\approx 8,5\text{ МБ}$, достигая $64\text{ МБ}$ в крупных прогонах рефакторинга нескольких файлов. Неуправляемая промежуточная очередь с $10000$ траекториями в накопленном хвосте займет более $85\text{ ГБ}$ оперативной памяти системы и вызовет сбои OOM ядра на брокере сообщений.

Размер промежуточных буферов и обратного давления

Рассмотрим промышленный кластер сбора траекторий, работающий с $N_{\text{roll}}=1024$ параллельными воркерами прогонов. Каждый воркер завершает траекторию агента в среднем за $T_{\text{roll}}=45\text{ с}$ (${\lambda }_{\text{rollout}}=1024/45\approx 22,75\text{ траекторий/с}$). Сырая сериализованная полезная нагрузка в среднем составляет ${\bar{S}}_{\text{traj}}=8,5\text{ МБ}$.

Пул верификации на следующей ступени состоит из $N_{\text{ver}}=512$ слотов CPU-воркеров. Время обслуживания каскада верификатора двумодально:

• $75\%$ траекторий проваливают ранние статические проверки ($V_1$), расходуя $t_{\text{fast}}=2,5\text{ с}$.
• $25\%$ траекторий требуют выполнения полного набора тестов ($V_2$), расходуя $t_{\text{slow}}=60,0\text{ с}$.

1. Вычислите номинальную интенсивность обслуживания верификации и загрузку мощности: Среднее время обслуживания верификации на траекторию равно: $${\bar{t}}_{\text{verify}}=(0,75\times 2,5\text{ с})+(0,25\times 60,0\text{ с})=1,875\text{ с}+15,0\text{ с}=16,875\text{ с}$$

Совокупная интенсивность обслуживания для $512$ слотов верификации равна: $${\mu }_{\text{verify}}=\frac{N_{\text{ver}}}{{\bar{t}}_{\text{verify}}}=\frac{512}{16,875\text{ с}}\approx 30,34\text{ траекторий/с}$$

Номинальная интенсивность трафика равна: $$\rho =\frac{{\lambda }_{\text{rollout}}}{{\mu }_{\text{verify}}}=\frac{22,75}{30,34}\approx 0,750$$ В установившемся режиме пул верификации обладает достаточным запасом ($\rho <1$).

2. Влияние патологического всплеска зависаний кода: Допустим, поврежденная фикстура программного обеспечения вводит бесконечный цикл в наборе тестов, из-за которого все тесты упираются в жесткий таймаут исполнителя тестов ($t_{\text{timeout}}=120\text{ с}$), и распределение меняется так, что $100\%$ поступающих прогонов попадают в $V_2$ и упираются в таймаут.

Деградировавшая интенсивность обслуживания падает до: $${\mu }_{\text{degraded}}=\frac{512}{120\text{ с}}\approx 4,27\text{ траекторий/с}$$

Деградировавшая интенсивность трафика становится равной: $${\rho }_{\text{degraded}}=\frac{22,75}{4,27}\approx 5,33\gg 1$$ Очередь растет с чистой скоростью: $$\Delta \lambda ={\lambda }_{\text{rollout}}-{\mu }_{\text{degraded}}=22,75-4,27=18,48\text{ траекторий/с}$$

С точки зрения накопления физической памяти на брокере сообщений: $$\frac{dM}{dt}=\Delta \lambda \times {\bar{S}}_{\text{traj}}=18,48\text{ траекторий/с}\times 8,5\text{ МБ}\approx 157,08\text{ МБ/с}$$

3. Определение пределов буфера и ограничение входящего потока: Если брокер очереди сообщений выделяет под промежуточный буфер отдельную память ОЗУ в объеме $M_{\max }=32\text{ ГБ}$, время до исчерпания памяти в деградировавших условиях равно: $$T_{\text{exhaust}}=\frac{32\times 1024\text{ МБ}}{157,08\text{ МБ/с}}\approx 208,6\text{ с}\approx 3,48\text{ мин}$$

Чтобы предотвратить катастрофический отказ системы, конвейер должен задать абсолютный порог глубины очереди: $$Q_{\max }=\frac{M_{\max }}{{\bar{S}}_{\text{traj}}}=\frac{32\times 1024\text{ МБ}}{8,5\text{ МБ}}\approx 3855\text{ траекторий}$$

Установка верхней отметки $Q_{\text{high}}=0,75\times Q_{\max }\approx$ 2 891 траектория позволяет контроллеру обратного давления немедленно остановить выдачу аренд у диспетчера задач, вынуждая воркеры прогонов приостановить выполнение до того, как брокер исчерпает физическую память.

Чтобы защитить систему от исчерпания памяти и каскадного отказа воркеров, архитектура сбора реализует контроллер обратного давления по замкнутому контуру с двумя водяными знаками. Контроллер отслеживает мгновенную глубину очереди $Q_{\text{current}}$ промежуточного буфера верификации:

$$\text{Состояние диспетчера}=\{\begin{array}{ll}\text{ACTIVE}& \text{если }{Q}_{\text{current}}\le Q_{\text{low}}\\ \text{THROTTLED}(p_{\text{shed}})& \text{если }{Q}_{\text{low}}<Q_{\text{current}}<Q_{\text{high}}\\ \text{HALTED}& \text{если }{Q}_{\text{current}}\ge Q_{\text{high}}\end{array}$$

Когда $Q_{\text{current}}$ пересекает $Q_{\text{high}}$, диспетчер задач отзывает предложения аренд у парка прогонов. Простаивающим воркерам прогонов не дают начинать новые прогоны, и они остаются припаркованными в асинхронном цикле ожидания.

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

$$C_{\text{total}}=Q_{\text{target}}+N_{\text{ver}}$$

где $Q_{\text{target}}$ — оптимальная глубина очереди, необходимая для сглаживания джиттера планирования верификации без накопления избыточного объема памяти. Когда воркер верификации завершает последнюю ступень оценки и сбрасывает запись в сток хранения, он возвращает кредит в пул аренд. Если верификация встает, доступные кредиты уменьшаются до нуля, автоматически заставляя парк прогонов голодать на входной ступени и предотвращая раздувание очереди по построению, как формализовано в «Протоколе конвейера обратного давления на основе кредитов».

| Компонент конвейера | Эксплуатационный механизм | Состояние управления потоком | Гарантируемый инвариант |

|:——————————|:—————————————————————————————————————————–|:—————————––|:——————————————————————————| | Парк воркеров прогонов | Генерирует кандидатные траектории ($T_{\text{rollout}}$); запрашивает кредиты выполнения у пула аренд перед началом шагов. | Блокируется, когда кредиты $\le 0$ | Никогда не переполняет память нижестоящего буфера. | | Промежуточная очередь | Высокопроизводительный брокер сообщений в памяти (Kafka / Redis Streams), буферизующий непроверенные трассы. | Ограничена $Q_{\text{target}}$ | Накладные расходы памяти очереди строго ограничены значением $M_{\text{queue}}\le 4\text{ГБ}$. | | Парк воркеров верификации | Выполняет поэтапные верификаторы ($V_1\to V_2\to V_3$); возвращает кредиты в пул при записи в сток. | Динамическое масштабирование параллелизма | Пропускная способность верификации соответствует скорости нижестоящего потребителя. | | Сток хранения и разбиения | Направляет проверенные успехи в обучающий сток, проверенные провалы — в трудные негативные примеры, а поврежденные трассы — в отброс. | Постоянное потоковое добавление | Детерминированно разбивает данные для сбалансированной смеси дообучения. |

Протокол конвейера обратного давления на основе кредитов: координация между парками генераторов прогонов и нижестоящими ступенями верификации при строгой аренде по схеме «корзина токенов» (token bucket).

Гигиена гипервизора

Поскольку агентные траектории выполняют внутри песочниц произвольные недетерминированные команды оболочки, тестовые скрипты и системные утилиты, они оказывают сильное накопительное воздействие на нижележащую операционную систему хоста. Хотя основные изменения файлов происходят внутри границы песочницы, механика многократного создания, подключения и уничтожения тысяч сред выполнения в час приводит к критическим утечкам ресурсов в ядре Linux хоста. На практике долго работающие парки сбора редко падают из-за сбоев вывода модели; они падают, потому что у гипервизора хоста заканчиваются блоки хранилища, сетевые таблицы или записи таблицы процессов ядра. Слои подсистем, механизмы утечек и политики санитарной обработки на границе «хост–песочница» показаны в «Изоляции границы ресурсов гипервизора хоста».

Изоляция границы ресурсов гипервизора хоста: слои подсистем, режимы отказов, механизмы утечек и политики санитарной обработки во время выполнения на границе «хост–песочница».

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

1. Висящие сетевые пространства имен и виртуальные интерфейсы: каждому контейнеру или microVM нужна виртуальная пара Ethernet (veth), которая связывает сетевой интерфейс гостя с изолированным мостом хоста (например, br0). Когда агент истекает по таймауту или аварийно падает, несогласованные скрипты завершения часто убивают гостевой процесс, но не удаляют соответствующий интерфейс veth на стороне хоста. Ядро Linux накладывает жесткое архитектурное ограничение на число сетевых интерфейсов (часто задаваемое конфигурацией по умолчанию или памятью таблиц маршрутизации). За тысячи итераций оставшиеся интерфейсы насыщают таблицы сетевой подсистемы ядра, и последующие выделения сокетов начинают завершаться ошибками ENFILE (переполнение таблицы файлов) или EADDRINUSE.
2. Осиротевшие блоки хранилища и отвязанные inode: быстрый сброс песочницы опирается на оверлеи с копированием при записи (CoW), такие как overlayfs в Linux или тонкое выделение DeviceMapper. Прогон агента, которая меняет каталоги сборки, компилирует бинарные файлы или скачивает зависимости, может записать гигабайты временных данных в верхний каталог эфемерного оверлея (upperdir). Если воркер падает посреди свертывания, счетчик ссылок на нижележащее loopback-монтирование или логический том остается ненулевым. Хотя путь каталога может быть отвязан от дерева файловой системы, нижележащие блоки хранилища остаются выделенными на массиве NVMe хоста. Это проявляется как коварная «призрачная утечка»: использование диска хоста (df) показывает $100\%$ заполнения, тогда как обход каталогов (du) показывает ничтожное потребление файлов.
3. Утечки POSIX-разделяемой памяти и IPC: приложения, работающие внутри песочниц выполнения, в частности многопроцессная обработка Python, CPU-тензоры PyTorch и безголовые процессы браузера, интенсивно выделяют разделяемую память через /dev/shm и семафоры POSIX. Когда песочницы завершаются прямым SIGKILL без аккуратного завершения субреапера, ядро хоста сохраняет осиротевшие сегменты разделяемой памяти. Поскольку /dev/shm смонтирован как виртуальная файловая система памяти (tmpfs), осиротевшие сегменты напрямую занимают ОЗУ хоста, вытесняют кеш страниц ОС и вызывают нехватку памяти во всем хосте.

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

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

Обвязка санитарной обработки реализует сдерживание процессов через иерархии управления cgroup v2 Linux. Каждой эфемерной песочнице назначается уникальный выделенный путь группы управления (например, /sys/fs/cgroup/agent/sandbox_<id>). Когда воркер прогона сигнализирует о завершении или упирается в крайний срок выполнения, среда выполнения хоста начинает свертывание, записывая 1 в атомарный контроллер завершения группы управления:

# Атомарно завершить все потомки-потоки внутри cgroup песочницы
echo 1 > /sys/fs/cgroup/agent/sandbox_1042/cgroup.kill

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

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

# Освобождение виртуального интерфейса аренды на стороне хоста с устойчивостью к ошибкам
def release_sandbox_network(sandbox_id: str, veth_host: str) -> None:
    try:
        # Явное удаление veth на стороне хоста удаляет парный интерфейс в пространстве имен гостя
        subprocess.run(["ip", "link", "delete", veth_host], check=True, timeout=2.0)
    except (subprocess.CalledProcessError, subprocess.TimeoutExpired) as err:
        logger.error(f"Failed to detach veth {veth_host} for sandbox {sandbox_id}: {err}")
        # Принудительная сверка: перенести интерфейс в резервное пространство имен уборщика для фоновой очистки
        quarantine_network_interface(veth_host)

Наконец, низкоприоритетный демон хоста (Janitor Agent, «уборщик») работает вне основного потока на каждом физическом узле гипервизора. Уборщик каждые $30\text{ с}$ сверяет системные таблицы с активными идентификаторами песочниц и арендами ресурсов хоста. Любое сетевое пространство имен, точка монтирования оверлея или выделение /dev/shm, не имеющее активной аренды у диспетчера задач, немедленно размонтируется, отвязывается и возвращается. Изолируя гипервизоры хоста от накопленных артефактов выполнения, распределенный конвейер может поддерживать непрерывные циклы сбора по миллионам прогонов траекторий без простоев на обслуживание.

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

Отслеживание происхождения траекторий

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

Собранная траектория без криптографической родословной — это невоспроизводимая телеметрия; собранная траектория без автоматического удаления учетных данных — токсичная корпоративная угроза. Рассмотрение трассы выполнения как полноценного системного артефакта требует поднять ее от произвольной последовательности сериализованных JSON-строк до неизменяемой криптографически запечатанной структуры данных — конверта происхождения (lineage envelope) — и одновременно выполнять детерминированные многопроходные конвейеры санитарной обработки, которые сохраняют синтаксическую целостность вызовов инструментов, не сохраняя ни одного бита приватных неявных полномочий.

Криптографический конверт происхождения

В классической теории распределенных систем и баз данных происхождение данных отвечает на два фундаментальных вопроса, сформулированных Питером Бьюманом, Санджевом Ханной и Тан Ванг-Чью (2001): why-provenance, которое указывает конкретные входные данные, вызвавшие появление выхода, и wherefore-provenance, описывающее точный вычислительный процесс и структурные преобразования, которые породили этот выход. В среде выполнения агента каждый наблюдаемый переход $s_t\stackrel{a_t}{\to }{s}_{t+1}$ — не просто продукт весов модели ${\pi }_{\theta }$; он является совместным продуктом четырехуровневого вычислительного стека: нейронного движка вывода, каркаса оркестрации хоста, плоскости выполнения инструментов и песочничного окружения операционной системы.

Чтобы гарантировать полное wherefore-provenance, конвейер сбора должен заключать каждую собранную траекторию в неизменяемый конверт происхождения траектории (Trajectory Lineage Envelope). Этот конверт связывает последовательность переходов состояний с криптографическими дайджестами каждого аппаратного и программного компонента, участвующего в цикле генерации траектории. Если изменится любой компонент этого стека — инженер выше по потоку поправит одно предложение в системном промпте, разработчик инструмента добавит необязательный параметр в схему OpenAPI или базовый образ Docker пересоберет нижележащую динамическую разделяемую библиотеку, — криптографическая идентичность траектории сместится, и тихие сдвиги распределения не смогут испортить нижестоящий корпус обучения политики.

Алгоритмический и побитовый детерминизм Из-за вариаций порядка параллельного редуцирования чисел с плавающей точкой в ядрах матричного умножения на GPU (например, неассоциативные GEMM в FP16/BF16 при разных планировщиках блоков потоков) точный побитовый детерминизм на разных микроархитектурах GPU исключительно трудно гарантировать. Фиксация затравки генератора, параметров генерации и контрольных сумм весов гарантирует алгоритмическую воспроизводимость, отделяя дрейф программного обеспечения от расхождения микроархитектуры аппаратуры.

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

1. Снимок базовой модели: каноническое название семейства модели, архитектурная ревизия и криптографический дайджест SHA-256 полного набора весов модели (например, вычисленный по отсортированному плоскому словарю тензоров дистрибутива safetensors). Если применяется параметро-эффективное дообучение (PEFT), конверт отдельно фиксирует точный хеш коммита и контрольную сумму весов активного адаптера LoRA.
2. Манифест каркаса и интерфейса: дайджест SHA-256 канонического шаблона системного промпта, дайджест конфигурации токенизатора BPE и семантическая версия и хеш схемы OpenAPI 3.0 каждой конечной точки инструмента, зарегистрированной в таблице диспетчеризации агента.
3. Состояние песочничного окружения: криптографический адрес содержимого (дайджест) корневого образа контейнера (например, дайджест docker-manifest.v2+json), версия ядра хоста и точный git-коммит SHA тестируемого репозитория, включая дайджест SHA-256 любого незакоммиченного диффа рабочего дерева, примененного до шага $t_0$.
4. Кортеж стохастического сэмплирования: затравка псевдослучайного генератора, переданная движку вывода, вместе с полным кортежем гиперпараметров, управляющих генерацией токенов: температура $\tau$, порог нуклеарного сэмплирования top-$p$, top-$k$, штраф за повторы и границы максимального числа генерируемых токенов.
5. Подписи верификации и исхода: хеш git-коммита набора тестов верификации, стандартный код выхода POSIX каждого поэтапного верификатора и отсоединенная криптографическая подпись воркера верификации, который оценил траекторию.

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

Чтобы предотвратить подмену или деградацию данных в распределенных объектных хранилищах, конвейер сбора вычисляет агрегированный идентификатор происхождения $H_{\text{lineage}}$ по всему конверту выполнения:

$$H_{\text{lineage}}=\text{HMAC-SHA256}\left(K_{\text{pipe}},H_{\text{model}}\parallel H_{\text{prompt}}\parallel H_{\text{tools}}\parallel H_{\text{env}}\parallel H_{\text{sample}}\parallel H_{\text{trajectory}}\right)$$

где $K_{\text{pipe}}$ — закрытый ключ конвейера приема, а $H_{\text{trajectory}}$ — корень Меркла, вычисленный по упорядоченной последовательности ходов взаимодействия $⟨(s_0,a_0),(s_1,a_1),\dots ,(s_T,a_T)⟩$. Хранение траекторий с индексом по $H_{\text{lineage}}$ гарантирует адресуемое по содержимому хранение: последующие задания обучения могут выборочно фильтровать обучающие данные по точным конфигурациям окружения, гарантируя, что политики никогда не обучаются на трассах, сгенерированных при несовместимых определениях инструментов или непроверенных средах выполнения.

Конверт происхождения траектории и поток санитарной обработки: привязка по дереву Меркла весов модели, схем инструментов и базовых линий окружения в неизменяемый HMAC-конверт (слева) в паре с трехпроходным конвейером удаления секретов с сохранением AST (справа), который гарантирует нулевую утечку токенов.

Полная структура этой криптографической привязки и последующего потока редактирования подробно показана на «Конверте происхождения траектории и потоке санитарной обработки»:

• Слева схема записи криптографического конверта происхождения ($S_{\text{envelope}}\approx 2,65\text{КБ}$) упаковывает три неизменяемых уровня:
  1. Неизменяемый манифест заголовка, фиксирующий криптографические дайджесты весов модели ($H_{\text{model}}$), шаблонов системного промпта ($H_{\text{prompt}}$), схем инструментов OpenAPI ($H_{\text{tools}}$), корневой файловой системы контейнера и SHA коммита ($H_{\text{env}}$) и затравок сэмплирования PRNG ($H_{\text{sample}}$).
  2. Дерево Меркла «состояние–действие» по всем $T$ шагам взаимодействия, которое хеширует кортежи шагов $h_t=H(s_t,a_t,o_t)$ и дельты файловой системы ${\Delta }_{\text{fs}}$ в единый корень Меркла $H_{\text{trajectory}}$.
  3. Механическое доказательство верификации и ярлык роли, связывающий утверждения о выходе тестов и классификацию траектории (RECOVERY_DEMONSTRATION). Эти поля запечатываются под ключом HMAC $K_{\text{pipe}}$, давая неизменяемый адресуемый по содержимому индекс $H_{\text{lineage}}$, и задают авторитетный ключ объектного хранилища (s3://corpus/traj-e84a1b.arrow).
• Справа трехпроходный синтаксически инвариантный поток санитарной обработки очищает входящие трассы без синтаксического повреждения. Сырое наблюдение, раскрывающее учетные данные (например, ключ AWS AKIAIOSFODNN7EXAMPLE, адрес электронной почты сотрудника и IP-адрес по RFC 1918 10.240.0.12), проходит проход 1 (сопоставление регулярными выражениями на основе DFA и фильтрацию по скользящему окну энтропии Шеннона для $H(S)\ge 4,5\text{бит/символ}$), проход 2 (квантованный DistilBERT NER и обнаружение подсетей CIDR) и проход 3 (маскирование строковых литералов AST солеными псевдонимами HMAC(K_salt, secret)[:12]). Получающаяся колоночная запись сохраняет побитово корректную грамматику JSON и длины последовательностей токенов, одновременно обеспечивая нулевую утечку токенов (${\Lambda }_{\text{leak}}=0,00\%$) в веса нижестоящей модели.

Хранение конвертов происхождения и задержка приема

Рассмотрим промышленный кластер сбора траекторий, обрабатывающий $N=100000$ завершенных траекторий в день. Каждая траектория фиксирует в среднем $T=32$ шага взаимодействия.

Характеристики траектории: Каждый шаг взаимодействия фиксирует блок генерации модели (512 токенов, примерно $2048\text{ байт}$ текста в UTF-8) и полезную нагрузку наблюдения инструмента (в среднем $1536\text{ байт}$ вывода оболочки или JSON). Сырой текст взаимодействия на одну траекторию равен: $$S_{\text{raw}}=32\times (2048+1536)\text{ байт}=32\times 3584\text{ байт}\approx 114,69\text{ КБ}$$

Накладные расходы конверта происхождения: Конверт происхождения добавляет фиксированные метаданные:

• Дайджесты модели, адаптера, промпта, токенизатора и манифеста инструментов: $5\times 32\text{ байт}=160\text{ байт}$.
• Хеши окружения (дайджест контейнера, SHA Git, дайджест диффа): $3\times 32\text{ байт}=96\text{ байт}$.
• Блок параметров сэмплирования и метаданные верификатора: $256\text{ байт}$.
• Хеши промежуточных узлов дерева Меркла для 32 шагов: $(32+16+8+4+2+1)\times 32\text{ байт}=63\times 32\text{ байт}=2016\text{ байт}$.
• Цифровая подпись и обрамление конверта: $128\text{ байт}$.

Суммарные накладные расходы конверта на одну траекторию: $$S_{\text{envelope}}=160+96+256+2016+128=2656\text{ байт}\approx 2,60\text{ КБ}$$

Относительные накладные расходы хранения: $$\text{Доля накладных расходов}=\frac{S_{\text{envelope}}}{S_{\text{raw}}}=\frac{2656}{114688}\approx 2,32\%$$ По $100000$ траекториям в день суммарная сырая полезная нагрузка составляет 11,47 ГБ/сут, а криптографический конверт происхождения занимает всего 0,27 ГБ/сут.

Пропускная способность верификации: Вычисление дайджестов SHA-256 на современном оборудовании с AVX-512 или расширением криптографии ARMv8-A достигает пропускной способности свыше $1,8\text{ ГБ/с}$ на ядро ЦП. Хеширование объединенной сырой трассы и конверта, составляющих $117,34\text{ КБ}$, требует: $$t_{\text{hash}}=\frac{117,34\times 10^3\text{ байт}}{1,8\times 10^9\text{ байт/с}}\approx 6,52\times 10^{-5}\text{ с}=65,2\text{ мкс}$$ Один выделенный поток проверки может криптографически запечатывать более 15 340 траекторий в секунду, внося в конвейер приема пренебрежимо малую задержку.

Санитарная обработка секретов

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

Если наивная система сбора использует простое удаление строк или грубую замену регулярными выражениями, она порождает тонкий, но разрушительный системный сбой: синтаксическое повреждение. Современные языковые модели обучаются следовать жестким синтаксическим спецификациям, таким как корректные вызовы инструментов JSON или сбалансированные подстановки команд Bash. Если проход редактирования произвольно удаляет ключ API внутри полезной нагрузки JSON (например, превращая {"auth": "bearer ghp_secret123"} в {"auth": }), синтаксический анализатор JSON выходит из строя, либо нижестоящая политика учится выдавать синтаксически сломанные вызовы инструментов. Напротив, если высокоэнтропийные секреты оставить неотредактированными, процесс дообучения их запомнит, нарушая фундаментальную формулировку дифференциальной приватности Синтии Дворк (2006): противник, запрашивающий обученную модель, не должен иметь возможности вывести присутствие или отсутствие конкретного приватного секрета в обучающем корпусе.

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

Проход 1: детерминированное сканирование шаблонов

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

У структурированных секретов есть известные префиксы и ограничения контрольных сумм. Проход 1 применяет высокопроизводительное сопоставление с детерминированными конечными автоматами (DFA) по установленным сигнатурам секретов, включая идентификаторы ключей доступа AWS (AKIA[0-9A-Z]{16}), персональные токены доступа GitHub (ghp_[A-Za-z0-9_]{36}), токены API Slack и заголовки PEM приватных ключей OpenSSH (-----BEGIN OPENSSH ...-----).

Неструктурированные секреты — например, сырые пароли баз данных, закодированные в base64 бинарные токены или произвольные шестнадцатеричные ключи — не имеют предсказуемых префиксов. Проход 1 обнаруживает такие строки, вычисляя эмпирическую энтропию Шеннона $H(S)$ по скользящему окну символов длины $W$ (обычно $W=32\text{ символов}$):

$$H(S)=-\sum _{i=1}^{k}p(c_i){\log }_{2}p(c_i)$$

где $p(c_i)$ — наблюдаемая частота символа $c_i$ из алфавита $\Sigma$ внутри окна. Обычный исходный код и естественный текст имеют энтропию между $2,5$ и $3,8\text{ бит/символ}$ из-за неравномерного распределения частот в человеческом языке и ключевых словах языков программирования. Случайные криптографические ключи, пароли и хеши в base64 приближаются к максимальной энтропии и стабильно дают $H(S)\ge 4,5\text{ бит/символ}$. Любая подстрока, превышающая эмпирический порог $H_{\text{threshold}}=4,5$ и не являющаяся существующим хешем коммита Git или известным дайджестом компилятора, помечается для редактирования.

Проход 2: контекстно-зависимое распознавание именованных сущностей (NER)

Не все чувствительные данные обладают высокой энтропией. Персональные данные (PII), включая имена сотрудников, корпоративные адреса электронной почты и топологию внутренней сетевой инфраструктуры, имеют низкую энтропию, неотличимую от обычной прозы. Проход 2 пропускает потоки наблюдений на естественном языке через локальную высокопроизводительную модель распознавания именованных сущностей (NER), например квантованный классификатор токенов DistilBERT или RoBERTa.

Помимо классификации сущностей, проход 2 сверяет сетевые координаты со спецификациями приватного IPv4 по RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), уникальными локальными адресами IPv6 по RFC 4193 (fc00::/7) и внутренними корпоративными полностью определенными доменными именами (FQDN, например *.corp.internal). Выявленные имена хостов и подсети помечаются для замены, чтобы политика агента не выучила топологию внутренних стейджинговых кластеров.

Проход 3: дифференциальное маскирование токенов с сохранением синтаксиса

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

<REDACTED_SECRET:HMAC-SHA256(K_salt, secret)[:12]>

Эта стратегия замены сохраняет три критически важных системных инварианта:

• Синтаксическая корректность: поскольку подстановка происходит внутри узла строкового литерала AST, кавычки, управляющие символы, закрывающие фигурные скобки и запятые в массивах остаются полностью сбалансированными.
• Референциальная прозрачность (согласованность кореференций): поскольку псевдоним выводится из хеша с ключом от исходного секрета с использованием соли набора данных $K_{\text{salt}}$, одинаковые секреты на разных шагах одной траектории получают одинаковые псевдонимы. Если агент выдает токен аутентификации на шаге 3 и повторяет его в заголовке curl на шаге 7, нижестоящая модель наблюдает согласованное повторное использование переменной, сохраняя причинную логику демонстрации без раскрытия исходного секрета.
• Стабильность длины токенов: границы токенизатора нижестоящей системы могут резко сдвигаться, если длинные строки заменяются произвольными заполнителями. Форматирование псевдонима фиксированной ширины минимизирует искусственное искажение авторегрессионных окон внимания модели.

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

  // Шаг траектории 04: выполнить аутентифицированный запрос к API
  {
    "tool_name": "execute_bash",
-   "command": "curl -H 'Authorization: Bearer ghp_99AxL002KzQ891mB18' https://api.internal.net/v1/keys",
-   "stdout": "{\"status\": \"success\", \"api_key\": \"sec_live_99814421bfae\"}"
+   "command": "curl -H 'Authorization: Bearer <REDACTED_SECRET:4f8a2b1c9e01>' https://api.internal.net/v1/keys",
+   "stdout": "{\"status\": \"success\", \"api_key\": \"<REDACTED_SECRET:7a9c3d1e2f45>\"}"
  }

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

Ограждение от лицензионного загрязнения

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

Если конвейер сбора без разбора принимает траектории, собранные на программном обеспечении под условиями сильного копилефта — таком как GNU General Public License (GPLv2, GPLv3) или Affero General Public License (AGPLv3), — и использует эти траектории для обучения с учителем (SFT) или прямой оптимизации предпочтений (DPO), получившиеся веса модели рискуют столкнуться с юридическими претензиями в отношении обязательств по производным работам. Хотя юридическая граница того, являются ли параметры модели производной работой от обучающих данных, остается предметом активных судебных споров, эксплуатационная инженерия требует строгой профилактической изоляции: корпоративные модели должны сохранять чистую, поддающуюся аудиту юридическую родословную.

Идентификаторы SPDX Стандарт System Package Data Exchange (SPDX) задает машиночитаемый синтаксис для объявления лицензий программного обеспечения (например, SPDX-License-Identifier: Apache-2.0). Современные AST-парсеры извлекают эти строки заголовка, чтобы автоматизировать классификацию лицензий на уровне репозитория.

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

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

Когда агент работает в репозитории уровня 3 или 4, конвейер сбора активирует отслеживатель меток недоверенности (taint tracker) на уровне AST. Если окно наблюдений агента захватывает сырой исходный код из файла с копилефтом, любое последующее действие генерации кода $a_t$, которое демонстрирует высокое перекрытие n-грамм ($n\ge 7$) или изоморфизм поддерева AST с наблюдением, помечается. Конвейер отмечает конверт метаданных траектории явным флагом загрязнения (license_taint: RECIPROCAL_COPYLEFT) и отделяет трассу в карантинный раздел озера данных. Корпоративные обвязки обучения затем могут применять фильтры исключения наборов данных на этапе компиляции, гарантируя, что коммерческие политики обучаются исключительно на разрешительных кодовых базах уровня 1.

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

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

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

Проверка гигиены разбиения выборки

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

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

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

Векторы загрязнения окружения

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

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

В агентном исполнении, однако, утечка данных — это средовое явление, а не лексическое (Kaufman et al., 2012). Траектория агента $\tau =(s_0,a_0,o_0,a_1,o_1,\dots ,a_T,o_T)$ привязана к фикстуре задачи $F=(S_0,{\mathcal{M}}_{\text{tool}},P_{\text{task}})$, где $S_0$ — начальный снимок окружения, ${\mathcal{M}}_{\text{tool}}$ — манифест инструментов, а $P_{\text{task}}$ — постановка задачи на естественном языке. Загрязнение возникает, когда фикстура оценки переносит структурные инварианты из обучающего распределения по любому из четырех различных измерений среды выполнения:

1. Топография кодовой базы и репозитория: иерархическое дерево файлов, графы импорта модулей, скрипты сборки (Makefile, CMakeLists.txt, pyproject.toml) и история коммитов. Политика, которая встречает репозиторий $R$ во время обучения, сохраняет неявную параметрическую память о том, где находятся служебные функции, в каких файлах лежит основная бизнес-логика и как вызывается исполнитель тестов. При оценке на $R$ она полностью обходит исследовательский поиск и порождает целенаправленные операции с файловой системой, которые не может воспроизвести в незнакомой системе.
2. Особенности поведения имитационных API: синтетические бэкенды инструментов и имитационные HTTP-сервисы, построенные для защиты конвейера сбора от ограничений частоты и недетерминированных сторонних API. Заглушки часто реализуют упрощенные схемы ответов, опускают кратковременные HTTP-ошибки или возвращают детерминированные полезные нагрузки для граничных случаев. Политика, которая сталкивается с этим поведением, запоминает идеализированный контракт заглушки и успешно проходит оценку только потому, что фикстура оценки использует ту же искусственную заглушку.
3. Диагностические и сигнатуры ошибок: форматирование, трассировки стека и шаблоны предупреждений, которые выдают инструменты выполнения. Когда среда выполнения Python выбрасывает исключение или компилятор выдает ошибку, конкретная формулировка часто отражает точные версии компилятора, установленные линтеры или особые обертки журналирования. Если обе выборки работают на одинаковых базовых слоях контейнера с одинаковыми бинарными файлами инструментов, политика учится переобучаться под локальные особенности компилятора, а не разбирать стандартные ошибки языка.
4. Обвязка тестов и артефакты верификации: конкретные утверждения, фикстуры и имитационные входные данные, которые использует поэтапный каскад верификаторов ($V_1,V_2,V_3$). Если модульные тесты, с помощью которых траектория допускается в обучающий набор, разделяют вспомогательные функции, генераторы тестовых данных или структуры утверждений с обвязкой оценки, модель учится стилю тестов, а не лежащей в основе спецификации.

# Наблюдаемая трасса сбоя: коллапс из-за запоминания окружения
# Задача: найти и исправить разыменование нулевого указателя в незнакомом репозитории
[Runtime Step 1] Action: ReadFile(path="src/utils/compat/string_helpers.py")
[Runtime Step 1] Result: ERROR - FileNotFoundError: [Errno 2] No such file or directory
[Runtime Step 2] Action: ReadFile(path="src/utils/compat/shims.py")
[Runtime Step 2] Result: ERROR - FileNotFoundError: [Errno 2] No such file or directory
[Runtime Step 3] Action: ReadFile(path="src/core/compat.py")
[Runtime Step 3] Result: ERROR - FileNotFoundError: [Errno 2] No such file or directory
[Runtime Step 4] Exhausted step budget (T_max=30). Task Failed.

Трасса выше показывает эмпирическую сигнатуру загрязнения окружения. Агент не выдал исследовательской команды (например, find, git ls-files или grep), чтобы картировать структуру каталогов чужого репозитория. Вместо этого он выдал уверенные, галлюцинированные действия ReadFile, нацеленные на конкретные вложенные пути. Эти самые пути существовали в обучающем репозитории, где решалась аналогичная задача разбора строк. Поскольку обучающий корпус вознаграждал быстрый доступ к файлам без предшествующих действий поиска, политика усвоила выбор пути как безусловную рефлекторную ассоциацию, что обеспечивает полный операционный паралич при встрече с незнакомой структурой каталогов.

Дисциплина иерархического разбиения

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

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

Основной границей сдерживания является семейство репозиториев. Семейство репозиториев включает не только отдельный Git-репозиторий, но и все его восходящие форки, нисходящие производные и родственные библиотеки, которые поддерживает та же организация. Многие организации разработки ПО поддерживают десятки микросервисов на общей архитектурной основе: одинаковые фреймворки журналирования, общие загрузчики конфигурации и единообразные обвязки тестирования. Размещение repo-auth в обучающей выборке, а repo-billing — в оценочной нарушает изоляцию окружения. Оба сервиса разделяют внутренние библиотечные соглашения организации, создавая незамеченный мост для структурного загрязнения. Конвейер разбиения должен построить граф замыкания по организации и зависимостям, гарантируя, что никакие два репозитория, разделяющие транзитивную внутреннюю зависимость, не окажутся по разные стороны границы «обучение–оценка».

Второй границей является семейство схем инструментов. Если каждая траектория обучающей выборки взаимодействует с файловой системой через инструмент ReadFile(path: str, offset: int, limit: int), модель, оцениваемая на идентичных сигнатурах, будет выглядеть умелой. Однако эта умелость может быть крайне хрупкой. Если среда выполнения меняет сигнатуру на Read(file: str, line_start: int, line_count: int) или требует RPC-интерфейс, который объединяет поиск и просмотр в единый дескриптор, переобученная модель испытает катастрофический развал схемы вызовов инструментов. Оценочные выборки должны намеренно резервировать отдельные семейства схем инструментов:

$${\mathcal{M}}_{\text{tool}}^{\text{eval}}=\{{\mu }_1^{\prime },{\mu }_2^{\prime },\dots ,{\mu }_k^{\prime }\}\text{где}\forall {\mu }^{\prime }\in {\mathcal{M}}_{\text{tool}}^{\text{eval}},{\mu }^{\prime }\notin {\mathcal{M}}_{\text{tool}}^{\text{train}}$$

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

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

Абляции эмпирической смеси данных

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

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

Успешность нижестоящих задач в зависимости от состава корпуса траекторий: эмпирическая доля прохождения бенчмарка как функция доли демонстраций восстановления при фиксированном бюджете обучения в $10^9$ токенов; оптимальная смесь с 30 % восстановления дает пик успешности 73,2 % на сложных многошаговых задачах.

Рассмотрим три варианта обучающих смесей, каждая из которых откалибрована под одинаковый вычислительный бюджет в $10^9$ токенов:

1. Некурированные прогоны: сырые траектории, которые допущены только по прохождению терминальных верификаторов ($V_3$) и содержат произвольные исследовательские блуждания, избыточные операции и неэффективные циклы инструментов.
2. Только безупречные демонстрации: траектории, в которых каждый шаг оптимален, порожденные сильнейшими передовыми моделями или экспертами-людьми, которые выполняют кратчайшие решения без ошибок.
3. Смесь с дополнением восстановлением: отобранный баланс из 70 процентов безупречных траекторий и 30 процентов структурированных демонстраций восстановления (синтезированных техниками расхождения и отката к контрольной точке, описанными в «Курировании демонстраций восстановления»).

Количественная динамика этого компромисса прослеживается на «Успешности нижестоящих задач в зависимости от состава корпуса траекторий» для трех различных режимов бенчмарка:

• На однократных модульных задачах (зеленая кривая) доминируют безупречные демонстрации; увеличение доли восстановления за $20\%$ незначительно снижает качество (с $83,4\%$ до $64,1\%$ при $60\%$ восстановления), поощряя ненужные исследовательские проверки.
• На возмущенных сбоях окружения (красная пунктирная кривая), где среда выполнения намеренно внедряет отказы в правах, кратковременные обрывы сети и мутации схем, политики, обученные без демонстраций восстановления, проваливаются почти поголовно (доля прохождений $15,2\%$ при $0\%$). По мере роста доли демонстраций восстановления к $60\%$ устойчивость монотонно растет до $64,2\%$.
• На реалистичных сложных многошаговых репозиториях (синяя кривая) качество образует перевернутую U-образную границу Парето. При базовом варианте только с безупречными демонстрациями ($0\%$ восстановления) успешность задыхается на уровне $41,0\%$, поскольку непреднамеренные ошибки запускают неконтролируемый дрейф накопления. По мере введения траекторий восстановления качество резко растет и достигает эмпирического пика $73,2\%$ именно при балансе $30\%$ восстановления и $70\%$ безупречных траекторий. За этой точкой перегиба избыток траекторий восстановления разбавляет импульс прямого выполнения, заставляя модель чрезмерно диагностировать рутинные операции, и успешность падает до $50,0\%$ при $60\%$ восстановления. Таким образом, доля восстановления $30\%$ обеспечивает оптимальное операционное равновесие.

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

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

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

Экономическую стоимость одной пригодной траектории, $C_{\text{usable}}$, мы формализуем в уравнении «Стоимость пригодной траектории»:

$$C_{\text{usable}}=\frac{C_{\text{generation}}+C_{\text{verification}}+C_{\text{sanitization}}}{N_{\text{accepted}}\cdot (1-\text{LeakageRate})}$$

где $N_{\text{accepted}}$ — сырое число кандидатных траекторий, успешно прошедших каскад верификаторов, а $\text{LeakageRate}\in [0,1)$ — доля принятых траекторий, которые должны быть удалены для сохранения строгого разделения окружения между обучающей и оценочной выборками.

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

Экономическая стоимость загрязненного выхода

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

Параметры конвейера:

• Вычисления генерации: вывод модели стоит $\$0,75$ за миллион токенов ($10^6$ токенов). Каждая попытка прогона потребляет в среднем 40 000 токенов (с учетом системных промптов, истории контекста и выводов инструментов).

• Стоимость сэмплирования на задачу: генератор исследует $K=5$ параллельных попыток прогона на каждую фикстуру задачи. Таким образом, каждая задача потребляет: $$C_{\text{generation}}=5\times (40000\times 10^{-6}\times \$0,75)=5\times \$0,030=\$0,150$$

• Стоимость верификации: каждая сгенерированная попытка, достигшая терминального состояния, выполняется внутри эфемерной песочницы microVM через трехступенчатый каскад верификаторов ($V_1,V_2,V_3$). Выделение microVM и выполнение в среднем стоят $\$0,020$ за проверенный прогон. При 5 попытках: $$C_{\text{verification}}=5\times \$0,020=\$0,100$$

• Вычисления санитарной обработки: криптографическое хеширование, разбор AST и фильтрация энтропии секретов стоят $\$0,005$ за попытку: $$C_{\text{sanitization}}=5\times \$0,005=\$0,025$$

• Валовая стоимость на задачу: $$C_{\text{task}}=C_{\text{generation}}+C_{\text{verification}}+C_{\text{sanitization}}=\$0,150+\$0,100+\$0,025=\$0,275$$

• Выход и допуск: из каждых 100 попыток задач каскад верификаторов успешно находит хотя бы одну валидную траекторию в 20 задачах ($N_{\text{accepted}}=20$ на 100 задач). Номинальная стоимость одной принятой траектории до аудита составляет: $$C_{\text{nominal}}=\frac{100\times \$0,275}{20}=\frac{\$27,50}{20}=\$1,375\text{ за траекторию}$$

Сравнение:

• Режим A (нестрогое разбиение): команда разбивает задачи случайно на уровне траекторий. Аудит гигиены разбиения после сбора показывает, что из 20 принятых траекторий 5 происходят из семейств репозиториев и схем инструментов, пересекающихся с отложенным оценочным набором ($\text{LeakageRate}=0,25$). Эти 5 траекторий необходимо отбросить, чтобы не загрязнить оценку. $$C_{\text{usable}}^{(\text{A})}=\frac{\$27,50}{20\cdot (1-0,25)}=\frac{\$27,50}{15}=\$1,833\text{ за пригодную траекторию}$$

• Режим B (строгое иерархическое разбиение): команда обеспечивает строгое разбиение по кодовым базам и семействам схем до приема задач ($\text{LeakageRate}=0,00$). Все 20 принятых траекторий юридически пригодны для использования в разных выборках. $$C_{\text{usable}}^{(\text{B})}=\frac{\$27,50}{20\cdot (1-0,00)}=\$1,375\text{ за пригодную траекторию}$$

Вывод: Утечка на уровне 25 процентов увеличивает эффективную единичную стоимость обучающих данных на: $$\frac{\$1,833-\$1,375}{\$1,375}=+33,3\%$$ Для промышленного прогона, нацеленного на 50 000 пригодных траекторий, режим A впустую расходует $22 917 на потерянные циклы вывода и вычислений исключительно из-за очисток гигиены разбиения ниже по потоку. Строгое разбиение заранее — экономическая необходимость, а не просто академическая формальность.

Фикстуры задач определяют воспроизводимые начальные состояния песочницы; поэтапные каскады верификаторов отсеивают мнимые завершения; курирование демонстраций восстановления прививает поведенческую устойчивость; неизменяемое отслеживание происхождения обеспечивает юридическую и эксплуатационную целостность; а иерархическая гигиена разбиения предотвращает иллюзию обобщения. Однако в промышленной среде инженерии агентов эти архитектурные механизмы не могут работать как разрозненные ручные скрипты или ad-hoc диагностические процедуры. Их нужно сплавить в автоматизированную, непрерывно работающую, самобалансирующуюся обвязку сбора, способную превращать сырые недетерминированные выполнения агентов в ценные активы адаптации политики. Как соединить эти разрозненные компоненты в единую, версионированную, сквозную архитектуру сбора данных?

Сквозной синтез сбора траекторий

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

Промышленное курирование траекторий требует синтеза воспроизводимых фикстур, поэтапной верификации, курирования восстановления и санитарной обработки в единый версионированный конвейер данных, оцениваемый по эмпирическому выходу и метрикам переноса на задачи. Если инженерная организация воспринимает сбор траекторий как неформальный набор офлайн-скриптов оболочки или ad-hoc парсеров журналов, полученный набор данных неизбежно страдает от классических режимов отказа, описанных у Sculley et al. (2015): «джунглей конвейеров», скрытых зависимостей данных и петель обратной связи, в которых исторические ошибки агента усиливаются, а не гасятся. Заимствуя основные принципы проектирования научных репозиториев данных — в частности, неизменяемое хранилище с однократной записью, непрерывный аудит происхождения и автоматизированную проверку качества данных, — промышленный конвейер сбора должен функционировать как компилятор среды выполнения с замкнутым контуром. Он принимает недетерминированные сырые журналы выполнения из журнала упреждающей записи (WAL) супервизора агента и блока управления агентом (ACB), передает каждую кандидатную трассу по нарастающей последовательности проверок физических инвариантов, очищает чувствительные эксплуатационные данные и выдает криптографически запечатанные, изолированные по разбиению обучающие корпуса.

Сквозная архитектура сбора траекторий и удержание потока: замкнутый жизненный цикл курирования данных (сверху), переводящий сырую телеметрию WAL среды выполнения через каскады верификаторов, разделители ролей, AST-маскирование секретов, криптографическую маркировку происхождения и изоляцию разбиений обратно в переобучение адаптации политики; в паре с эмпирическими кривыми удержания конвейера (снизу), показывающими, как агрессивная фильтрация верификации снижает выход принятого корпуса до $12,8\%$, одновременно поднимая долю прохождения нижестоящих задач с $11,2\%$ до пикового значения $42,5\%$.

Как показано в «Сквозной архитектуре сбора траекторий и удержании потока», промышленная архитектура сбора объединяет шестиступенчатый жизненный цикл приема (верхняя панель) с эмпирическими кривыми «выход–качество» (нижняя панель):

• Жизненный цикл приема (сверху): сырые трассы среды выполнения, поступающие из журнала упреждающей записи супервизора (ступень 1), проходят через многоуровневые верификаторы (ступень 2), которые устраняют некорректный синтаксис и обход тестов. Выжившие распределяются по поведенческим архетипам (ступень 3, с целью $70\%$ безупречных и $30\%$ траекторий восстановления вместе с добытыми трудными негативными примерами), очищаются трехпроходным AST-маскированием (ступень 4), устраняющим утечку учетных данных (${\Lambda }_{\text{leak}}=0,00\%$), запечатываются HMAC-дайджестами Меркла (ступень 5) и распределяются по непересекающимся по семействам репозиториев разбиениям (ступень 6), прежде чем питать замкнутый маховик переобучения.
• Эмпирическое удержание конвейера (снизу): сопровождающая количественная системная кривая сопоставляет выход принятого корпуса $\eta$ с долей прохождения нижестоящих задач $P_{\text{task}}$ в пяти конфигурациях конвейера, разобранных в «Оценочной карте качества набора данных». Обучение непосредственно на нефильтрованных производственных журналах (опасность нефильтрованного журнала) сохраняет выход $100,0\%$, но снижает компетентность модели до недопустимых $11,2\%$ прохождения из-за авторегрессионного подражания непреднамеренным циклам. Введение статической фильтрации ($V_1$) отсекает синтаксические дефекты, снижая выход до $58,2\%$ и поднимая долю прохождения до $18,6\%$. Активация механических песочниц microVM ($V_1\to V_2$) агрессивно отсеивает обманщиков тестов и циклы таймаутов, снижая выход до $17,4\%$ при росте прохождения до $27,4\%$. Решающий прорыв происходит с добычей восстановления ($V_3$), где трассы самовосстановления дают перегиб производительности на $+9,4\%$ (прохождение $36,8\%$ при выходе $14,1\%$). Наконец, полностью синтезированный сборщик достигает пикового обобщения на нижестоящих задачах ($42,5\%$ прохождения) при весьма селективном выходе принятых данных $12,8\%$, что подтверждает: качество данных и структурное разнообразие, а не сырой объем, определяют скорость маховика агентов.

Жизненный цикл приема: от журнала WAL среды выполнения до разбитого корпуса

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

Ступень 1: захват сырого выполнения

Конвейер сбора начинается в супервизоре среды выполнения агента. Как установлено в архитектуре хоста, непривилегированная модель агента работает при нулевых неявных полномочиях и взаимодействует с окружением исключительно через опосредованные удаленные вызовы процедур (RPC). Каждая сборка промпта, декодированный выходной токен, вызов инструмента, поток стандартного вывода и изменение файловой системы песочницы последовательно дописываются в журнал упреждающей записи (Write-Ahead Log) только для добавления, который опирается на блок управления агентом (ACB).

Когда эпизод завершается — по явному завершению задачи, исчерпанию шагов ($T\ge T_{\max }$), неустранимому сбою песочницы или вмешательству супервизора, — среда выполнения упаковывает сессию в сырую полезную нагрузку траектории ${\tau }_{\text{raw}}$. Этот конверт содержит:

1. Исходную спецификацию задачи $P_{\text{task}}$ и входной контекст.

2. Идентификатор начального снимка окружения $S_0$ (например, адресуемый по содержимому хеш образа контейнера или идентификатор снимка microVM).

3. Манифест схем интерфейса инструментов ${\mathcal{M}}_{\text{tool}}$, предоставленный во время выполнения.

4. Полную хронологическую последовательность состояний, действий, наблюдений и меток времени выполнения: $${\tau }_{\text{raw}}=\left(s_0,a_0,o_0,t_0,s_1,a_1,o_1,t_1,\dots ,s_T,a_T,o_T,t_T\right)$$

5. Итоговую разность файловой системы ${\Delta }_{\text{fs}}$, порожденную в эфемерном рабочем пространстве с копированием при записи.

Среда выполнения передает ${\tau }_{\text{raw}}$ по высокопроизводительным очередям сообщений (например, Apache Kafka или буферам потоковой передачи gRPC) в развязанные воркеры приема конвейера, гарантируя, что свертывание песочницы и выполнение агента на хосте никогда не блокируются обратным давлением обработки данных.

Ступень 2: поэтапный каскад верификации

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

• Ступень $V_1$ (статическая валидация схемы и синтаксиса): работает исключительно в памяти ЦП с задержкой менее миллисекунды ($c_1\approx 0,5\text{ мс}$). $V_1$ разбирает сырую стенограмму, чтобы проверить ее корректность. Он подтверждает, что каждое действие модели соответствует JSON-схеме ${\mathcal{M}}_{\text{tool}}$, проверяет, что файловые патчи соответствуют синтаксису unified diff, и убеждается, что правки кода компилируются или разбираются в абстрактное синтаксическое дерево (AST) без синтаксических ошибок. Трассы с некорректными токенами, галлюцинированными идентификаторами инструментов или обрезанными управляющими блоками немедленно отбрасываются.
• Ступень $V_2$ (герметичное выполнение в песочнице): трассы, пережившие $V_1$, переходят в контейнеризованные песочницы ($c_2\approx 5\text{–}30\text{ с}$), где итоговая разность рабочего пространства ${\Delta }_{\text{fs}}$ применяется к исходной чистой фикстуре $S_0$. Верификатор запускает уже существующие модульные тесты, линтеры и проверки типов. Важно, что верификатор проверяет безопасность разности: агент не должен был менять фикстуры тестов, отключать правила линтинга или добавлять тривиальные сквозные утверждения.
• Ступень $V_3$ (аудит динамической нестабильности и мутаций): чтобы устранить ложноположительные результаты от недетерминированных наборов тестов, $V_3$ запускает набор тестов на $K$ независимых затравках ($K\ge 3$) при ограничении ЦП и изоляции сети. Кроме того, внедряются семантические property-тесты и проверки мутаций, чтобы убедиться, что патч агента действительно устраняет лежащую в основе проблему, а не подгоняется под поверхностные утверждения.

Ступень 3: поведенческая разметка ролей

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

Движок синтеза относит принятые траектории к трем структурным поведенческим категориям, подробно описанным в «Таксономии ролей курируемых траекторий»:

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

Для траекторий восстановления конвейер проставляет индекс расхождения $t_{\text{div}}$, на котором агент отклонился в состояние ошибки, и точку перегиба восстановления $t_{\text{rec}}$, на которой агент выявил первопричину и начал корректирующее действие. Эти метаданные позволяют последующим ступеням курирования извлекать целевые подтраектории, сосредоточенные исключительно на переходе «ошибка — восстановление».

# Эмпирическая трасса сбоя верификации: обнаружение подмены набора тестов
def verify_diff_integrity(patch_diff: str, fixture_manifest: dict) -> bool:
    """Отклоняет патчи, которые меняют инфраструктуру валидации или отключают утверждения."""
    for line in patch_diff.splitlines():
        # Обнаружить изменение запечатанных наборов тестов или конфигураций CI
        if line.startswith("--- a/") or line.startswith("+++ b/"):
            filepath = line[6:].strip()
            if filepath in fixture_manifest["protected_test_files"]:
                return False  # Обнаружена подмена тестов: агент изменил эталонные данные
        # Обнаружить ленивое подавление утверждений в изменяемом коде приложения
        if line.startswith("+") and any(cheat in line for cheat in [
            "pytest.mark.skip", "pragma: no cover", "unittest.skip", "assert True"
        ]):
            return False  # Обнаружен обход утверждения
    return True

Ступень 4: многопроходное редактирование

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

Воркер санитарной обработки выполняет детерминированный многопроходный протокол редактирования:

1. Детерминированное сканирование высокоэнтропийных токенов: сканирует все строковые поля, применяя пороги энтропии Шеннона в сочетании с известными шаблонами секретов (например, стандартные префиксы регулярных выражений для облачных учетных данных, заголовки приватных SSH-ключей, bearer-токены). Найденные секреты заносятся в таблицу символов подстановки для каждой трассы ${\mathbf{\Sigma }}_{\text{secret}}$.
2. Согласованная замена с сохранением контекста: каждый чувствительный литерал $s_k\in {\mathbf{\Sigma }}_{\text{secret}}$ заменяется структурно корректным, семантически нейтральным фиктивным литералом, который сохраняет лежащий в основе синтаксис. Ключ доступа AWS (AKIAIOSFODNN7EXAMPLE) отображается в синтетический токен, соответствующий RFC (AKIA00000000EXAMPLE000), так что нижестоящие валидаторы формата не падают. Важно, что замена глобально согласована по всем шагам траектории $\tau$, поэтому ссылки на переменную совпадают с ее объявлением.
3. Нормализация JSON и кода с сохранением AST: приводит все пробельные символы, ключи JSON и блоки кода к каноническому виду (например, стандартный отступ, отсортированные ключи словаря). Это удаляет случайные недетерминированные особенности форматирования, которые вносит среда выполнения хоста, гарантируя, что политика не тратит емкость модели на усвоение переходных артефактов пробелов.

Ступень 5: криптографическая маркировка происхождения

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

Движок происхождения вычисляет составной хеш происхождения SHA-256: $$H_{\text{lineage}}=\text{SHA-256}\left(H_{\text{trajectory}}\Vert {\Theta }_{\text{base}}\Vert S_0\Vert {\mathcal{M}}_{\text{tool}}\Vert K_{\text{pipe}}\right)$$ где $H_{\text{trajectory}}$ — хеш содержимого очищенной последовательности взаимодействий, ${\Theta }_{\text{base}}$ задает веса модели-генератора и гиперпараметры температуры, $S_0$ — неизменяемый дайджест корневой файловой системы контейнера, ${\mathcal{M}}_{\text{tool}}$ — сериализованная спецификация инструментов, а $K_{\text{pipe}}$ — версионный коммит самого конвейера сбора. Траектория записывается в неизменяемое объектное хранилище (например, S3 с Object Lock или хранилище blob только для чтения), индексированное по $H_{\text{lineage}}$, и сопровождается неизменяемым манифестом метаданных.

Ступень 6: разбиение по семействам репозиториев

Финальная ступень назначает помеченную траекторию в оценочное разбиение: обучающее, валидационное или отложенное тестовое. Стандартное случайное разбиение ($k$-fold или равномерная выборка по траекториям) для агентных систем совершенно неприемлемо. Если агент выполняет три разные задачи над репозиторием django/django, а две задачи отправить в обучающее разбиение, а одну — в тестовое, возникает серьезная утечка данных: модель запоминает структуры каталогов репозитория, имена вспомогательных функций, соглашения тестов и структуры моков баз данных.

Конвейер обеспечивает непересекающееся по семействам репозиториев разбиение. Все фикстуры задач, полученные из программного проекта, его организационных форков и тесно связанных внутренних зависимостей, назначаются одним атомарным блоком в одно разбиение. Пусть $\mathcal{F}$ — множество всех фикстур задач, а ${\mathcal{G}}_{\text{repo}}(f)$ сопоставляет фикстуре ее корневое семейство кодовых баз. Функция разбиения должна удовлетворять условию: $$\forall f_i\in {\mathcal{D}}_{\text{train}},\forall f_j\in {\mathcal{D}}_{\text{test}}⟹{\mathcal{G}}_{\text{repo}}(f_i)\cap {\mathcal{G}}_{\text{repo}}(f_j)=\varnothing$$ Кроме того, анализируются графы транзитивных зависимостей, чтобы гарантировать, что общие внутренние библиотечные утилиты не перекидывают мост через границу разбиения.

Экономика пропускной способности конвейера

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

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

Формальные математические метрики

Мы определяем четыре основные системные метрики, которые управляют конвейером сбора:

1. Выход траекторий ($\eta$): отношение числа проверенных, полностью очищенных и принятых траекторий к общему числу сырых эпизодов, запущенных средой выполнения:

$$\eta =\frac{N_{\text{accepted}}}{N_{\text{generated}}}=\prod _{i=1}^{M}p(V_i\mid V_{<i})$$ где $p(V_i\mid V_{<i})$ — условная доля прохождения ступени верификации $V_i$ при условии, что трасса прошла все предыдущие ступени. В производственных средах разработки программного обеспечения типичный выход лежит в диапазоне от $\eta =0,05$ до $\eta =0,20$. Аномально высокий выход ($\eta >0,50$) почти всегда указывает на излишнюю мягкость верификатора или обман тестов.

2. Коэффициент нестабильности ($R_{\text{flake}}$): частота, с которой одинаковые патчи рабочего пространства дают расходящиеся результаты верификации в независимых прогонах оценки: $$R_{\text{flake}}=\frac{N_{\text{inconsistent}}}{N_{\text{verified}}}=\frac{{\sum }_{j=1}^N\mathbb{I}\left(0<{\sum }_{k=1}^K{V}_3({\Delta }_{\text{fs}}^{(j)},{\text{seed}}_k)<K\right)}{N}$$ Когда $R_{\text{flake}}>0,02$ (больше 2 процентов), конвейер приостанавливает автоматический прием, поскольку недетерминированные тесты позволяют некорректным траекториям загрязнять обучающий корпус, одновременно отбрасывая корректные пути восстановления.

3. Покрытие редактирования и граница утечки (${\Lambda }_{\text{leak}}$): эмпирическая доля немаскированных чувствительных токенов, просочившихся в выходное хранилище, измеряемая с помощью офлайн-процесса вставки канареек: $${\Lambda }_{\text{leak}}=\frac{C_{\text{detected\_canaries}}}{C_{\text{injected\_canaries}}}$$ Здоровый конвейер поддерживает ${\Lambda }_{\text{leak}}\equiv 0$ относительно синтетических канареек, внедренных в сырой поток выполнения.

4. Множитель вычислений верификации ($Q_{\text{verify}}$): суммарные циклы вычислений ЦП и GPU, затраченные на верификацию, песочницы и санитарную обработку, относительно вычислений, затраченных на авторегрессионную генерацию токенов при исходном прогоне агента: $$Q_{\text{verify}}=\frac{{\text{FLOPs}}_{\text{verification}}}{{\text{FLOPs}}_{\text{generation}}}$$ Поскольку верификация опирается главным образом на быстрые CPU-microVM и статический анализ, а не на плотные тензорные ускорители, поддержание $Q_{\text{verify}}<0,10$ по совокупной стоимости оборудования гарантирует, что курирование данных не доминирует в бюджете инфраструктуры.