Trace as State：让推理轨迹成为长上下文的条件状态
《Trace as State: Reasoning Traces as Conditional States for Long-Context Transformers》中文技术学习文档
先看结论：创新点不是“更多思考”，而是“更早提供状态”
在相同模型、相同长上下文、相同轨迹文本 T 下，仅改变 T 位于上下文之前还是之后，前置方案在绝大多数实验格上更好。
理论给出的是确定性、精确、单遍处理器的最坏情形分离；它不能直接证明现实 Transformer 的提升完全由“内存复杂度下降”造成。
问题从哪里来：输入顺序与推理顺序不一致
因果 Transformer 在位置 i 只能读取前缀 1…i。但很多长上下文任务的关键状态——当前目标、已解析指代、搜索边界、被排除的假设——要到读完整段材料并开始推理后才逐渐明确。
早期表示已经形成
目标、线索、搜索边界
无法反向改写早期表示
一个直观例子
假设上下文是一条 25 万 token 的图边列表，问题最后才要求“找出节点 X 的全部父节点”。首遍读取边列表时，模型还未充分建立“X 是当前目标、需要维护前驱集合”的任务状态。问题虽然在末尾能指导后续回答，却不能改变前面边列表在同一因果 pass 中已经形成的表示。
论文在所有主实验中都把问题 q 放在末尾；严格比较的实际顺序是 [T, x, q] 与 [x, T, q]。
理论依据：条件先到，处理器只需维护一条状态路径
3.1 因果状态更新处理器
给定信息序列 C = (c₁, …, cₙ)、有限状态空间 S 和固定更新规则 U，处理器按输入顺序更新状态：
条件 z ∈ S 决定初始状态 s₀ = z。当顺序是 [z, C]，处理器已经知道从哪条状态路径开始，只需保存当前 sᵢ。
边读边沿已选中的一条路径更新；工作状态只需表示一个 S 中的值。
读完 C 仍不知道初始状态；最坏情况下要保留 C 对所有可能 z 的作用。
3.2 指数级差异如何得到
令 |S| = 2ᵇ。条件优先只需标识当前状态，因此使用约 b bits。条件滞后时，序列可能对应从 S 到 S 的任意函数；这样的函数共有 |S||S| 个，区分它们需要：
|S| = 4 时，条件优先需要 2 bits；条件滞后要区分 4⁴ = 256 个残余映射，需要 8 bits。3.3 理论的适用边界
证明针对确定性处理器，不直接覆盖随机采样模型。
要求对所有输入精确，不讨论容错近似所需的更小状态。
晚条件设置不能回看 C；而论文方法正是用新 pass 主动重读。
作者把有限上下文、有限精度的因果 Transformer 视作因果状态更新处理器：工作状态包含位置、各层 KV 项以及其他持续的输入相关推理缓冲区。但这是一种抽象对应，不是对某个具体模型参数规模的定量下界。
Trace as State：读、算、反馈、重读
独立读取与推理
模型对同一问题运行 ntr 次，每次得到推理轨迹 rⱼ 与可见答案 aⱼ。
把轨迹冻结成文本状态 T
固定序列化器 π 按来源顺序拼接轨迹，加入固定说明、编号和边界标签；答案不进入 T。
状态前置后重读上下文
新 pass 接收 [T, x, q]。轨迹中的目标、线索与中间判断在模型重新读取 x 时已经可见。
用相同 T 做位置对照
Trace Append 接收 [x, T, q]；两组只有轨迹相对长上下文的位置不同。
T 能影响第二遍上下文 token 的因果处理过程。
T 能指导后续推理与答案，但不能改变此前已形成的 x 表示。
论文采用的轨迹块
<first_run_reasoning_traces>
[Trace 1]
{r1}
[Trace 2]
{r2}
...
[Trace n]
{rn}
</first_run_reasoning_traces>
主实验每题首遍运行 5 次，并把 5 条轨迹全部放入第二遍。单条轨迹超过 50,000 字符时仅保留前 50,000 字符并追加省略号；序列化说明明确警告轨迹可能出错，需要回到原始上下文核验。
实验设计：严格控制“同一 T，不同位置”
| 维度 | 设置 | 为什么重要 |
|---|---|---|
| 模型 | DeepSeek V4 Pro Preview、Qwen 3.7 Max、GLM-5.2 | 来自不同提供方与不同长上下文架构 |
| GraphWalks 256K | 200 题 × 5 次；BFS / Parents；EM、集合 F1 | 要求在长边列表上维护遍历或前驱状态 |
| MRCRv2 8-needle | 256K / 512K；200 题 × 5 次；EM、SequenceMatcher | 把最终请求绑定到更早的正确请求-响应实例 |
| NUB-1M Season 2 | 400–700K token 小说；20 题 × 5 次；模型判分准确率 | 长篇小说中的复杂阅读理解 |
| 无效输出 | 阻断、超长、格式错误、缺失、非终止、内容过滤均记 0 | 避免只统计成功响应造成乐观偏差 |
| 公平对照 | 同一 x、同一 T、同一模型，仅交换 T 与 x | 直接检验“状态何时可见” |
reasoning_effort 参数。核心结果：位置优势在状态维护型任务上最明显
下表保留论文 Table 2 的全部主结果。每个数值均为 5 次重复平均后的百分数；同一模型与指标内的最佳值以粗体显示。
| 模型 / 条件 | GW BFS | GW Parents | MR 256K | MR 512K | NUB | ||||
|---|---|---|---|---|---|---|---|---|---|
| EM | F1 | EM | F1 | EM | Seq. | EM | Seq. | Acc. | |
| DeepSeek · First | 31.6 | 36.4 | 29.2 | 46.5 | 53.8 | 78.5 | 45.4 | 63.6 | 60.0 |
| DeepSeek · Append | 41.8 | 48.3 | 43.0 | 65.3 | 66.6 | 79.6 | 49.4 | 66.9 | 71.0 |
| DeepSeek · State | 58.8 | 65.9 | 81.8 | 91.3 | 76.8 | 88.7 | 52.6 | 73.3 | 73.0 |
| Qwen · First | 60.0 | 68.1 | 60.8 | 87.2 | 79.8 | 83.1 | 36.2 | 43.7 | 37.0 |
| Qwen · Append | 60.4 | 70.4 | 71.0 | 91.7 | 84.0 | 87.1 | 40.4 | 47.4 | 49.0 |
| Qwen · State | 63.8 | 71.7 | 96.4 | 99.1 | 88.4 | 91.3 | 46.8 | 52.5 | 51.0 |
| GLM · First | 55.8 | 70.7 | 66.4 | 88.5 | 40.2 | 48.2 | 42.6 | 52.0 | 43.0 |
| GLM · Append | 60.0 | 75.8 | 83.2 | 92.7 | 40.0 | 58.3 | 44.6 | 59.9 | 65.0 |
| GLM · State | 63.4 | 75.0 | 100.0 | 100.0 | 61.2 | 71.9 | 55.4 | 70.1 | 66.0 |
Trace as State 相对 Trace Append 的 EM 提升
单位：百分点；条形最大值按 40 点归一化，仅用于比较代表性 EM 差值。
严格同 T 对照的 24 个 GraphWalks / MR 指标单元中，20 个问题簇 bootstrap 95% 区间完全高于 0。
GLM-5.2 的 GraphWalks BFS F1：Append 75.8，State 75.0，低 0.8 点；但该任务 EM 仍由 60.0 提升到 63.4。
消融实验：为什么不能只归因于“多读一遍”或“看到答案”
作者在 DeepSeek V4 Pro Preview + GraphWalks 256K 上加入多种控制。Parents 子任务的差距最能说明问题。
| 条件 | 提示顺序 | Parents EM | Parents F1 | 解释 |
|---|---|---|---|---|
| First pass | [x, q] | 29.2 | 46.5 | 单遍基线 |
| Oracle@5 | 事后挑 5 次中最佳 | 50.0 | 75.0 | State 仍超过事后最优首遍答案 |
| Question First | [q, x, q] | 53.0 | 64.6 | 问题本身确实可充当一部分任务状态 |
| Re2 | [x, q, x, q] | 50.0 | 68.9 | 重读有效，但不等于带状态重读 |
| Answer Feedback | [a, x, q] | 45.4 | 58.0 | 最终答案承载的状态少于完整轨迹 |
| Random Trace | [Trand, x, q] | 14.2 | 31.3 | 泛化“脚手架格式”无效，错误状态反而伤害 |
| Trace Only | [T, q] | 43.8 | 67.3 | 轨迹有信息，但不能替代原上下文 |
| Trace Append | [x, T, q] | 43.0 | 65.3 | 轨迹能指导最后回答，但来得太晚 |
| Trace as State | [T, x, q] | 81.8 | 91.3 | 任务相关状态在重读前已经可用 |
ntr = 1…5 的嵌套实验中，性能总体随轨迹数量上升，且每个数量下 State 都高于 Append。它提示可以把“收集多少条状态候选”作为 inference scaling 参数。如何正确理解：轨迹是状态代理，不是模型真实内部状态
推理轨迹可以携带目标、已找到证据、候选路径、排除项等任务相关信息，并在下一 pass 中影响计算。
相同文本在上下文前后的位置并不等价；因果注意力使“何时可见”成为能力变量。
轨迹可能不完整、带偏见或包含错误。论文明确把它称为 textual proxy，没有把它等同于隐藏状态或形式化条件 z。
不能据此断言模型“理解了自己全部推理过程”，也不能把输出的思考文本当作忠实可解释性证据。
本质上是“跨 pass 的外部递归”
工程实现：优先使用可审计的结构化状态
很多线上 API 不开放原始私有推理轨迹。工程上更稳妥的做法，是让首遍显式输出一个可保存、可校验、可裁剪的“任务状态摘要”，而不是依赖隐藏思维链。
推荐的状态字段
- 任务目标与最终约束
- 已定位证据及来源位置
- 已解析实体与指代关系
- 候选结论与置信度
- 待验证假设与冲突项
- 第二遍的读取 / 搜索策略
必须加的防护
- 把状态声明为“不可信提示”，要求回原文复核
- 给证据保存稳定 ID，不复制无法追踪的片段
- 过滤提示注入与敏感数据
- 限制状态长度并保留高价值字段
- 记录状态来源、模型版本与生成时间
- 用同一状态做 Prefix / Append A/B 测试
# 伪代码：用“显式状态摘要”实现可部署版本
states = []
for seed in range(n_traces):
result = model.generate(
prompt=[long_context, question],
output_schema=TaskStateAndAnswer,
seed=seed,
)
states.append(result.task_state)
state_prefix = serialize_and_filter(states)
# 关键位置：状态必须在长上下文之前
final = model.generate(
prompt=[
"以下状态可能有误，必须依据原文逐项核验：",
state_prefix,
long_context,
question,
]
)
return final.answer何时值得使用
| 场景 | 适配度 | 原因 |
|---|---|---|
| 超长图结构、日志、代码库、合同集合 | 高 | 任务状态在首遍中逐步形成，第二遍可按目标重读 |
| 多证据绑定、跨章节指代、排除式检索 | 高 | 状态可记录实体绑定、候选与排除项 |
| 短上下文、单点检索、直接分类 | 低 | 额外完整 pass 的成本通常大于收益 |
| 高实时交互 | 低到中 | 需要权衡首遍并行数和第二遍重读时延 |
| 上下文不可重复发送或高度敏感 | 谨慎 | 重复传输扩大成本与数据治理范围 |
对 Agent 开发的启发：把状态放到“下一轮读环境”之前
首遍记录目标模块、调用链、失败假设；第二遍将状态前置，再重读相关文件或仓库索引。
首遍形成证据表、术语映射和冲突列表；第二遍按该状态重新扫描材料并核验引用。
首遍从日志中发现时间窗和故障组件；第二遍以它们为状态重新读取原始日志。
与常见 Agent Memory 的区别
Memory 关注跨任务或跨轮保存什么；Trace as State 更关注同一个长任务中，已发现的状态应该在下一次处理原始上下文的哪个位置出现。二者可以组合：Memory 负责持久化，State Prefix 负责在新的因果 pass 开始前注入。
局限、成本与尚未回答的问题
| 问题 | 影响 | 后续应怎么验证 |
|---|---|---|
| 闭源模型与动态接口 | 模型版本、默认输出上限和缓存策略可能变化，难做完全复现 | 开放脚本、固定快照、报告延迟与价格 |
| 理论与实证之间仍有距离 | 最坏情形证明不能确认现实任务的因果机制 | 设计可控合成任务，直接测状态容量与顺序 |
| 任务覆盖有限 | 仅 3 个长上下文任务族，未测试多轮 Agent | 加入代码仓库、日志、网页操作和工具使用任务 |
| NUB-1M 仅 20 题 | 置信区间更宽，1–2 点差异证据较弱 | 扩大题量并采用人工 / 多裁判一致性 |
| 成本与时延显著增加 | 需要多个来源运行 + 完整第二遍，且可能降低 KV cache 复用 | 报告准确率 / 成本前沿，做选择性触发 |
| 轨迹会放大错误 | Random Trace 明显低于基线，说明错误状态可能系统性误导重读 | 加入状态校验、证据引用、置信门控与冲突合并 |
| 未比较更强的压缩状态 | 原始轨迹冗长，首 50K 字符截断也未必保留最重要状态 | 比较摘要、结构化状态、检索式状态与同 token 预算 |
论文附录报告了各提供方返回的 cached input、missed input 与 output token。结果表明成本形态强依赖提供方缓存策略，不能简单把前置状态视作“只多一点提示词”；它通常意味着重新处理整段长上下文。
建议的学习与复现实验
自己推导 |S| = 4 的例子
列出 4 个状态到自身的全部函数数量，解释为什么晚条件必须区分 256 种响应轮廓。
从 20–50K token 的日志或代码开始
构造需要先发现目标、再回看证据的问题；首遍只输出显式结构化状态。
冻结同一份状态文本
比较 [T,x,q]、[x,T,q]、[x,q,x,q]、[a,x,q]；不能为不同条件重新生成 T。
按问题配对，先平均重复再 bootstrap
同时统计准确率、无效输出、输入缓存、未命中输入、输出 token、首 token 延迟和总时延。
加入选择性触发与状态压缩
仅当首遍低置信、长上下文确需状态维护时启动第二遍；比较结构化状态与原始轨迹的成本收益。
论文来源与数据口径
主要来源：arXiv:2609.02702 — Trace as State，版本 v1，提交于 2026-09-02。
内容范围：正文、附录中的证明构造、Prompt / State 模板、GraphWalks 难度分层、置信区间和 token 用量。
数值规则：实验值均逐项转录自论文 Table 2、Table 3、Table 5；文中“百分点”为百分数直接相减，不是相对增长率。
代码状态：截至 2026-09-10，论文及 arXiv 条目未给出官方实现仓库，因此工程代码为依据方法描述整理的可部署伪代码，不代表作者官方实现。