nemo_gym.models.token_capture.builder
nemo_gym.models.token_capture.builder
Build trainable trajectories from a frozen token capture.
The consumer freezes a TokenCaptureSnapshot before passing its TokenEntry records here.
The builder can return multiple trajectories when a rollout contains independent call chains.
Each current record states whether the call starts a root, continues a verified parent, or has unresolved ancestry. The builder verifies every resolved parent against the child’s prompt tokens before joining the calls. An unresolved call begins a separate fragment. The builder never infers a parent across that boundary.
prefix_merging uses token-prefix matching only when a verified parent is absent from the frozen snapshot.
For example, capture can filter a parent that generated no tokens.
In that case, prefix matching may reconnect the child to a verified surviving ancestor.
The build does not depend on capture order.
prefix_merging processes entries by increasing prompt length because a parent’s prompt is shorter than its child’s.
Loss masks follow token provenance. Policy-generated tokens have a mask value of 1 and retain their captured log probabilities. Prompt tokens have a mask value of 0.
Module Contents
Classes
Functions
Data
API
Describe what the build kept, dropped, or could not resolve.
The consumer converts these fields into run metrics. Typed fields prevent renamed keys from appearing as zero values on dashboards.
Require one log probability for each generated token.
A trainer cannot use a chain with mismatched token and log-probability counts.
Avoid building a token-prefix index when every parent is present.
Every supported entry carries a request-time parent decision. Only missing-parent recovery needs the trie.
Index cumulative token sequences for linear-time parent lookup.
Whether refusal was the harness’s next request after the delivered terminal call and did not fit.
Two conditions. The refusal carries the context-window code: an output-token parameter the
engine rejected (code is None) says nothing about the conversation’s length, so it is
reported in metrics["engine_refusals"] but sets no verdict. And the refused request
continued the delivered terminal call: its request-time lineage names that call, or a call
whose full token sequence is identical to it (a retry twin), and no twin of the terminal call
was served at or after the moment the refusal was recorded. A twin served at or after the
refusal is a successful re-serving of the call the refused request continued, so the harness
recovered from the refusal and the retained twin’s own ending stands. The ordering reads the
whole twin group, whichever twin attribution retained, so the verdict does not depend on
which twin drew the smaller call id when attribution could only name them by content. A
refusal on another branch of the rollout, one that continued an earlier call the harness
later moved past, and one whose parent could not be resolved leave the verdict alone.
Known limitation: an auxiliary request the harness sends after the session completed (a
summary or title call, or an end-of-session compaction) can carry the terminal call’s whole
history, so it continues the terminal call in lineage too. The capture cannot tell such a
request from the harness’s next turn: a context-window refusal of it marks the rollout
incomplete although the harness finished on its own, and delivery then replaces a
harness completed status with that verdict.
The twin comparison reads the calls’ token sequences from out.entries on demand, so a
build without refusals compares nothing.
Rebuild full prompts for delta records by walking their parent chains.
Return full-prompt entries and call ids with broken chains.
Find this call’s parent.
New records preserve the request-time parent decision.
Token-prefix matching recovers a resolved link whose parent is absent from this build.
This can happen when the parent had an empty generation and was filtered out.
note reports why the recorded link was not used as recorded.
Whether two calls’ full token sequences, prompt and generation together, are identical.
Require each generated item to extend all preceding tokens.
The preceding tokens include the prompt and all prior generations.
Raise AssertionError when the response is not contiguous.
Project a chain into Responses output items with contiguous prompts.
Preserve captured assistant text and tool calls. Put the contiguous prompt on the item that carries each generation. Each generated item’s prompt extends the previous generated item. Preserve text for downstream scoring. Create a token-only item only when a call has no captured content items.
Rebuild the main chain as a Responses object whose output items are contiguous.
The result is a Gym-native Responses payload.
It contains object: "response", output items, and usage.
Token fields describe one unbroken sequence across the rollout.
The sequence combines items from multiple model calls.
When the delivered chain’s terminal call stopped for length or content_filter, the
payload carries status: "incomplete" with the matching incomplete_details.reason
(max_output_tokens or content_filter), the verdict the Responses converter gives a
chat completion that ended the same way. The finish reason is recorded by the local capture
path (capture_tokens); under worker custody the ledger row carries it and
staging.rebuild.LinearizedRow.incomplete_reason applies the same mapping.
finish_reason_resolved=False withholds the verdict: terminal attribution passes it when
the terminal call was chosen among token-identical retries that recorded different finish
reasons, so the status would otherwise depend on which twin drew the smaller call id. The
withholding covers the finish-reason verdict only; a refusal that ended the chain still sets
the status, because the refusal record names the call it continued and its verdict never
depended on the twins’ finish reasons.
engine_refusals are the frozen snapshot’s engine refusals. A refusal of the request that
continued the delivered terminal call, refused for the context window, also makes the payload
incomplete with reason max_output_tokens: the harness’s next request did not fit, so
the rollout ended at the model’s limit although its last served call completed
(_engine_refusal_ended_the_chain states the two conditions). A refusal the harness recovered
from, with a call served after it (a token-identical retry of the terminal call that was
served at or after the refusal included), a refusal on another branch of the rollout, a refusal
of an output-token parameter, and one whose parent is unknown do not change the verdict. A
refusal and a served length stop give the same status; the consumer’s
metrics["engine_refusals"] tells them apart.
Chain frozen snapshot entries with the named strategy.
terminal_call_id anchors chain selection for prefix_merging.