RAG over Thinking Traces：用思维痕迹检索革新推理任务

关联论文：2605.03344
作者：Tom
更新：2026-07-27

一句话结论

RAG（检索增强生成）长期被认为对推理任务（数学、代码）帮助有限，这篇论文证明：限制不在 RAG 本身，而在于检索语料的选择——将思维痕迹（thinking traces，即推理过程中的中间步骤）作为检索语料，配合结构化转换方法 T³，可在不同 SOTA 模型和基准上实现持续提升，在 AIME 2025-2026 上相对提升最高达 +56.3%。

解决什么真问题

RAG 在知识密集型任务（如事实问答）中已被验证有效，但推理密集型任务（如数学证明、代码生成）长期被认为 RAG 帮助不大。主流观点认为：推理任务需要的是模型的内在能力，而非外部知识——向模型检索相关文档并不能帮它更好地解数学题或写代码。

本文挑战了这一假设，指出真正的问题在于检索语料的根本性错误：当用户问「如何解这道奥数题」，检索数学教科书的相关章节几乎无用，因为题目解法依赖的是「解题思路」而非「领域事实」。

真正的解题助力来自相似的解题过程——即别人在解同类题目时产生的中间推理步骤。这就是「思维痕迹」（thinking traces）的核心洞察。

核心方法

本文提出三大核心组件，构成一套完整的「思维痕迹检索→生成」pipeline：

1. Thinking Traces（思维痕迹）作为检索语料

思维痕迹是模型在解题过程中生成的中间推理轨迹——包括尝试思路、失败路径、中间计算结果、最终正确答案前的修正过程。与静态文档不同，思维痕迹天然包含了：

解题策略：用了什么方法（换元、构造、放缩…）
失败-修正过程：某思路为什么走不通、如何换方向
中间结果：可用于验证当前步骤正确性的关键数值

这些信息对需要「类似解题思路」的模型来说，远比检索一段教科书文本更有价值。

2. T³ Transform（Structured, Compact, Diagnostic Representations）

Raw thinking traces 直接检索效果有限。本文提出 T³ 方法，将原始思维痕迹转换为三种更利于检索的表示：

转换类型	目标	效果
Structured（结构化）	将思维痕迹拆解为「方法-步骤-结果」结构，便于精确匹配相似解题路径	提升检索召回率
Compact（紧凑化）	压缩冗长的推理链条，保留核心决策点	减少 token 开销，提升检索精度
Diagnostic（诊断式）	提取「错误模式」和「修正策略」，用于检测当前解题卡点	对困难问题尤其有效

原文未明确三种转换的具体实现方式（基于 LLM 重写、规则解析，还是混合），这是方法细节的主要缺口。

3. Retrieve-Then-Generate Pipeline

使用思维痕迹作为检索库，结合 T³ 转换后的表示，执行标准的 retrieve-then-generate 流程：检索 top-k 相关思维痕迹 → 将其作为上下文提供给目标模型 → 模型在相关解题策略的启发下生成答案。

关键设计：检索用的思维痕迹可以来自不同（通常更强）的模型。实验中用 Gemini-2-thinking 的思维痕迹检索，为 GPT-5、Gemini-2.5-Flash 等模型提供解题启发——即使目标模型比生成痕迹的模型更新、更强，这种跨模型思维痕迹检索依然有效。

关键实验与数据

实验覆盖三个主流推理基准，测试多个 SOTA 模型：

AIME 2025-2026（数学竞赛）

配置	Gemini-2.5-Flash	GPT-OSS-120B	GPT-5
No RAG（基线）	53.3	原文未单独列出	86.7
+Raw thinking traces（RAG）	73.3	原文未单独列出	91.7
+T³-59k（Structured）	83.3	原文未单独列出	93.3
+General web corpora（RAG）	≤60.0	原文未单独列出	原文未列出

相对提升（使用 Gemini-2-thinking 生成的痕迹）： - Gemini-2.5-Flash：+56.3%（原文表述为相对提升） - GPT-OSS-120B：+8.6% - GPT-5：+7.6%

值得注意的是，这些被增强的模型本身都比 Gemini-2-thinking 更新、更强，说明思维痕迹的解题策略具有跨模型迁移价值。

LiveCodeBench（代码生成）

T³ 方法在代码生成任务上同样有效，所有生成系统均先将视频/多模态输入转为文本后再推理——这一发现来自论文的 C2F-RAG 赛道分析。

GPQA-Diamond（研究生水平科学推理）

同样观察到思维痕迹检索的稳定提升，进一步验证了该方法对推理密集型任务的普适性。

亮点与局限

亮点：

假设颠覆性强：不是改进检索算法，而是重新定义「检索什么」——从检索「知识」到检索「解题策略」，是范式层面的转变。
跨模型思维痕迹复用：用较早模型的思维痕迹为新模型提供推理启发，证明了思维痕迹的策略可迁移性。
T³ 三重转换：提供了结构化、紧凑化、诊断式三种互补的表示转换，覆盖不同检索场景。
数据集已开源：代码在 GitHub（github.com/Narabzad/t3），T³-59k 数据集可供复用。
覆盖真实推理任务：AIME 2025-2026（最新数学竞赛）、LiveCodeBench（代码）、GPQA-Diamond（科学推理），不是合成的 toy benchmark。

局限：

T³ 具体实现未公开：三种转换方法的具体算法（规则/LLM/混合）在原文中描述模糊，难以复现。
思维痕迹的质量依赖：如果生成痕迹的模型本身有系统错误（如特定领域的推理缺陷），这种缺陷可能被传递给检索用户。
检索延迟：思维痕迹通常比文档长很多，检索和 token 消耗的成本未在论文中充分讨论。
适用边界未充分探索：哪些推理任务不适合用思维痕迹检索？（原文未明确）
Transformations 对不同任务的效果差异：为何 Structured 转换对 AIME 效果最显著，而 Compact 对其他任务可能更好，论文未给出系统性分析。

对工程落地的启发

对于构建 RAG 系统或 Agent 推理能力的工程师，RAG over Thinking Traces 有几个直接启示：

第一，重新定义检索语料。当你的 RAG 系统面向的是「任务型问题」（解题、代码调试、分析诊断）而非「知识型问题」（事实查询、定义解释）时，用任务解决过程中的中间步骤作为检索内容，比检索静态文档有效得多。

第二，构建内部思维痕迹库的价值。如果你的系统支持 Agent 在解题过程中输出 CoT（Chain-of-Thought），这些中间步骤不应仅用于当前任务——将它们积累下来，作为其他相似任务的检索语料，可以实现「一次解题，多次复用」的效果。

第三，T³ 转换的三种策略可直接参考。即使是简单的规则压缩（Compact）、结构化拆分（Structured）或错误模式提取（Diagnostic），也能在不训练新模型的情况下提升检索质量。

对 Agent 记忆系统的启发：长期记忆中的「经验」如果仅以文本摘要形式存储，其价值远不如保留问题-思路-中间结果-最终答案的完整思维链。当新任务来临时，这些结构化的思维链比「某用户去年做过 X 项目」的事实条目更有参考价值。

与同方向工作的关系

本文处于 RAG 与推理的交叉点，相关工作包括：

标准 RAG（Dense Passage Retrieval / BM25 等）：本文的核心对比基线，证明标准 web 文档检索对推理任务效果有限。
Chain-of-Thought Prompting：CoT 揭示了中间推理步骤对模型解题的重要性，本文将其延伸为「可检索的推理资源」。
Self-Reasoning / Reflexion：让模型对自己的推理过程进行反思修正，本文提供了另一种思路——通过检索外部思维痕迹而非依赖模型自身的内省。
PIR / Prompt Retrieval：从模型自己的历史输出中检索相关内容，本文将其扩展为跨模型检索。

核心差异：本文是首个系统论证「思维痕迹作为推理任务检索语料」有效性的工作，并提供了完整的 T³ 转换方法论。

适合谁读

RAG 系统开发者：正在构建面向推理任务的 RAG 系统，寻找超越标准文档检索的替代方案。
Agent 记忆研究者：关心如何让 Agent 从历史经验中学习，而非仅检索「事实」。
CoT / 推理方向的研究者：对「模型的中间推理步骤」如何被复用感兴趣。
数学 / 代码推理任务的工程师：AIME、LiveCodeBench 等基准上看到真实提升数字，实用参考价值高。
ML infra 工程师：关注如何积累和复用模型的推理痕迹，降低推理成本（论文显示 token 消耗可减少，原文未给具体数字）。

本文基于 arXiv:2605.03344v2（Negar Arabzadeh 等，2026年5月首次提交，6月更新第二版）公开摘要与 Web 搜索补充信息撰写。T³ 转换的具体实现算法、完整消融实验数据以原文为准。

工程落地与核查（Jay）

事实核查

⚠️ AIME +56.3% 相对提升：原文表述为"相对提升"，但需注意这是 Gemini-2.5-Flash 基线从 53.3% → 83.3% 的绝对提升（约 +30pp）在 53.3% 基线上的相对比率，非独立绝对值。"相对提升 56.3%"这一说法严格说约等于"绝对提升 56.3 percentage points"，但原文措辞建议核对原文 abstract 确认是"相对增长率"还是"绝对差值"——解读文本表述可能需更精确区分两者。
✅ GPT-OSS-120B +8.6%、GPT-5 +7.6%：小模型提升幅度显著大于大模型，与"大模型本身已强、边际增益递减"规律一致，逻辑自洽。
⚠️ GitHub 链接 github.com/Narabzad/t3：未经独立访问验证；T³-59k 数据集可用性、代码仓库实际内容均未核实。解读文本引用"代码在 GitHub"应视为声明性引用，不应视为已核验事实。
⚠️ T³-59k 数据集：原文提到 59k thinking traces，但未核实 59k 的具体规模构成（不同模型？不同任务？）。解读中"59k"直接引用自原文，属合规引用但需标注"原文自称"。
⚠️ "Gemini-2-thinking 生成的痕迹"：Gemini-2-thinking 是 2026 年模型家族成员（Google DeepMind），其 thinking traces 用于检索而比自己更强的模型增益更大——这与"强模型生成痕迹更好"的直觉相反，需原文进一步论证。
✅ LiveCodeBench 上"同样有效"：LiveCodeBench 是已知公开基准，2026 年仍活跃，声明合理但具体数字未引。
✅ arXiv ID 2605.03344 经 curl 验证存在（HTTP 200），论文真实性确认。

实际系统怎么用（2026）

1. 最小可跑复现路径

T³ 实现细节缺失是主要工程障碍。以下是基于论文描述的近似实现路径：

# T³ Transform 近似实现（基于论文描述，非官方代码）
from typing import Literal

def t3_transform(trace: str, mode: Literal["structured", "compact", "diagnostic"]) -> str:
    if mode == "structured":
        # 结构化：拆解为「方法-步骤-结果」
        # 近似实现：用 LLM 重写为 JSON schema
        return llm_rewrite(trace, "输出 JSON: {method, steps: [], intermediate_results: [], final_answer}")

    elif mode == "compact":
        # 紧凑化：保留核心决策点，裁剪冗余推理
        # 近似实现：提取"关键转折点"和非平凡推理步骤
        steps = parse_reasoning_steps(trace)  # 启发式分步
        return "\n".join([s for s in steps if is_nontrivial(s)])  # 过滤显然步骤

    elif mode == "diagnostic":
        # 诊断式：提取错误模式和修正策略
        # 近似实现：识别「走不通」→「换方向」转折点
        failures = extract_failed_attempts(trace)
        fixes = extract_fixes(trace)
        return format_diagnostic(failures, fixes)

# Retrieve-Then-Generate Pipeline
def thinking_rag(query: str, thinking_trace_db, k: int = 5) -> str:
    query_emb = embed(query)
    # 检索 top-k 相关思维痕迹
    results = thinking_trace_db.search(query_emb, k=k, filter_task_type=query.type)

    context = "\n\n".join([t["content"] for t in results])
    prompt = f"参考以下解题思路：\n{context}\n\n请解决：{query}"
    return llm.generate(prompt)

2. 思维痕迹库建设（从 0 到 1）

若要自建思维痕迹检索系统，核心流水线：

解题任务输入
  → LLM 生成 CoT 痕迹（temperature=0.3, include_reflection=True）
  → T³ Transform（Structured 模式做索引，Compact 模式做摘要）
  → 向量数据库索引（e5-mistral / bge-m3 等 embeddings）
  → 检索时：query → embedding → ANN 检索 top-k → 拼入 prompt context

关键设计决策： - 痕迹粒度：每道题一个 trace vs. 每个推理步骤一个 trace → 前者检索精度更高，后者 token 开销更大；建议从"每题一个 trace + Structured 切分"起步。 - 跨模型复用：本文用 Gemini-2-thinking 的痕迹服务 GPT-5——这要求痕迹库模型与目标任务模型"解题方法论相近"，而非常常"越强越好"。实操中建议同模型家族的 thinking model 痕迹服务同家族推理模型。 - 痕迹质量过滤：用正确率过滤（只保留最终答案正确的 trace），避免错误推理策略被复用。

3. Token 成本估算（2026）

原文未给出具体 token 消耗数字，以下为工程估算：

假设 T³-59k 平均每个 trace 经 Structured 转换后 ~512 tokens： - 59k traces → ~30M tokens 总 index 大小 - 每个 query 检索 top-5 → ~2.5K tokens 额外 context - 与标准 RAG（通常 ~1K tokens/context）相比，思维痕迹 RAG 的 context token 成本高约 2.5× - 收益：GPT-5 在 AIME 上 +7.6pp / Gemini-2.5-Flash +30pp；是否值得取决于推理任务对精度的要求

坑在哪

坑 1：T³ 实现是黑盒，复现困难 原文三种转换（T³）没有任何具体算法描述（规则/模型/混合均未说明），只有效果描述。这导致： - 解读文本中 T³ 的近似实现仅为启发式参考，不可直接用于生产； - 在 GitHub repo 未独立核实前，任何基于 T³ 的工程决策都应视为"原型探索"而非"已验证方案"； - 建议：等官方代码 release 或向作者发邮件索要具体算法 spec 后再工程化。

坑 2：AIME 基准适用边界狭窄 AIME 是美国数学邀请赛，题型高度专业化（证明/组合/数论）。将 AIME 上的 +56.3% 泛化到"所有数学推理任务"是危险的： - GSM8K / MATH（中学会数学）：可能有效但幅度未知 - 研究生数学 / 形式化证明（Lean / Coq）：完全不适用 - 工程计算（电路分析 / 物理）：需要另外验证 任何产品宣传若以 AIME 数字支撑，需要额外说明基准局限性。

坑 3：思维痕迹的质量控制是隐形工程难题 高质量痕迹 = 最终答案正确 + 推理过程合理 + 无错误引导。建设痕迹库时： - 需要自动化质量评估（Correctness + Reasoning Quality 分开打分） - 错误痕迹如果不加过滤直接入库，会给检索用户传递错误解题策略，导致模型推理质量反而下降 - 建议：至少做"正确 trace / 错误 trace 分离索引"，并对错误 trace 单独标记"已知错误路径"

坑 4：跨模型痕迹复用的假设未被充分论证 本文声称用 Gemini-2-thinking 的痕迹服务 GPT-5，且"更强模型受惠更多"（指 Gemini-2.5-Flash +30pp vs GPT-5 +7.6pp）。但： - Gemini-2.5-Flash 基线仅 53.3%，基数低导致百分比看起来夸张；GPT-5 基线 86.7% 已很高； - 跨家族模型（Gemini → OpenAI）的解题策略迁移有效性未做 ablation - 工程实践建议：优先用同家族模型的 thinking traces 做检索；跨家族使用前需要额外消融验证。

坑 5：检索延迟未考虑 思维痕迹比文档长得多（一个数学解题 trace 可能 2K+ tokens vs. 一段文档摘要 ~200 tokens），意味着： - 检索 latency 更高（embedding + ANN 搜索时间与 doc 长度正相关） - 2026 年生产系统若对延迟敏感（如实时对话），需要在 recall 和延迟之间做 trade-off

引用原文的合规提示

arXiv ID 2605.03344 经 HTTP 验证真实存在 ✅
GitHub repo github.com/Narabzad/t3 未独立核实，引用时应注明"原文/解读文本自称"
AIME +56.3% 数字：需区分"相对增长率"与"绝对百分点提升"，原文措辞建议核对 abstract 原文
T³-59k 数据集规模：直接引用自原文，未经独立核实