你的 LLM 解数学题老出错？——这篇论文说"RAG 不是没用，是你塞错语料了"
- 关联论文：2605.03344
如果你用 LLM 解过 AIME 这种数学竞赛题，或者让它写 LiveCodeBench 那种真实代码题，你大概率遇到过这种场面：
- 你给它看题，它算一步就卡住；
- 你塞几篇官方解题手册进去当 RAG，它还是算不对；
- 你换个更强的模型，效果是好了——但还是同一个模型在同一个 benchmark 上，涨不动。
你大概率以为："推理题 RAG 帮不上忙，因为瓶颈在算力 / 模型，不在知识"。
但 2026 年 7 月这篇叫 RAG over Thinking Traces（arXiv 2605.03344）的论文，正面反驳了这个假设：
RAG 在推理题上看起来没用，不是因为 RAG 本身不行，而是因为被检索的"语料"错了——把"知识文档"换成模型自己生成的思维痕迹（thinking traces），RAG 就能稳定地、跨模型地提升推理表现。
更狠的是——配套的开源工具 T3 直接放 GitHub 了（github.com/Narabzad/t3），你今天就能在自己代码里跑一遍。
今天这篇科普用 5 分钟把它讲透：为什么"换语料"比"换模型"更值钱？这件事对推理型 LLM 应用意味着什么？
一、为什么"推理题 RAG 没用"是默认共识
在讲这篇论文之前，我们先说清楚：为什么过去两年大家都默认"RAG 在推理题上没用"？
逻辑链条是这样的：
- RAG 的核心叙事是："检索 = 找外部知识，知识补全 = 解知识密集型任务"；
- 所以 RAG 在"开放域问答 / 文档总结 / 知识图谱查询"上效果好，因为这些任务的瓶颈是"知识"；
- 但数学竞赛、代码题、形式逻辑这些推理型任务，瓶颈是"模型算 / 推"，不是"知识"；
- 所以大家默认：给推理题塞文档 RAG 没意义。
这个共识在过去两年几乎没被挑战过。社区投入的方向是"更大的模型 / 更长的 thinking / 更好的 RL"——所有努力都在"模型本身上"。
但这篇论文指出：这个共识有个被忽视的盲点——
当模型（尤其是 thinking model）解题时，会留下大段的中间思考轨迹——搜索、试错、假设、折回。这些轨迹本身就是一个高质量检索库，因为它记录了"解这类题的人都走过什么弯路、问过什么中间问题"。
你塞官方手册 RAG 没效果，是因为手册是"通解"，不是"中间思路"。真正能辅助下一道题解的，是"上一道题解时模型卡在哪、改了哪步、为什么这么改"——而这些恰好就是 thinking trace 的内容。
二、这篇论文的反直觉结论：换语料 > 换模型
论文的核心反直觉结论非常直接：
把 RAG 的语料从"知识文档"换成"思维痕迹"（thinking traces），再用 T3 工具把它们整理成结构化、可检索的形态，RAG 就能在 AIME 2025–2026、LiveCodeBench、GPQA-Diamond 上稳定地、跨模型地提升推理表现。
具体来说：
- 用 Gemini-2-thinking 生成的 traces 作 corpus，去辅助 Gemini-2.5-Flash 在 AIME 2025–2026 上相对涨 56.3%；
- 同一个 traces 库，去辅助 GPT-OSS-120B 涨 8.6%；
- 去辅助 GPT-5 涨 7.6%——GPT-5 是比生成 trace 的 Gemini-2-thinking 更晚 / 更强的模型，效果不是来自"老师教学生"式的过拟合，而是真正可迁移的推理辅助。
这件事的颠覆性在于：跨模型也能涨，意味着 thinking traces 是模型无关的中间产物——一个团队内的 traces 库，可以被多家不同 reasoning model 的服务共享，边际成本极低。
三、T3 怎么 work：三种变换路线
如果你直接把原始 thinking trace 当文档塞进 RAG，效果不会好——因为原始 trace 又长又冗余，还混着自问自答。
论文提出了一个叫 T3（Trace Transformation for Retrieval） 的离线转换器，给出三种互补的变换路线，可以组合使用：
变换 1：结构化（Structured）
把长 trace 拆成显式段落：
问题重述 → 子目标 → 关键中间事实 → 候选路径 → 错误与回退 → 最终结论
让 embedding 模型能对齐到细粒度语义。
变换 2：紧凑化（Compact）
删除自反问、重复尝试、纯寒暄等冗余 token，保留"决策性"步骤。目的是让单条 trace 的信噪比更高、索引更小。
变换 3：诊断化（Diagnostic）
这是论文自己强调最关键的洞察——在每一步后追加一个简短的元注释：
"为什么这么走 / 错在哪 / 哪步是关键岔路"
这是给后续检索器、reranker 用的"诊断语义"，让 query 能命中"岔路"而不是"通解"。
这三步合在一起的收益：原始 trace 不够、变换后才有价值。论文做了消融实验，逐项去掉每种变换，都能观测到增益下降——验证了"原始 trace 不够、变换后才有价值"。
四、完整的 Pipeline 长这样
# 1. 离线：建库
traces = []
for p in seed_problems:
traces += thinking_model.solve(p, n=N, temperature=T) # 多采样
structured = T3.structured(traces) # 拆段
compact = T3.compact(structured) # 去噪
diagnostic = T3.diagnose(compact) # 加注释
index.add(diagnostic) # corpus 入库
# 2. 在线：推理
q = user_problem
hits = index.search(q, k=K, rerank=True)
prompt = f"<problem>\n{q}\n</problem>\n<reference_traces>\n"
+ "\n---\n".join(hits) + "\n</reference_traces>"
answer = reasoning_model.generate(prompt)
关键是：检索侧用的是标准 dense retrieval + reranking——论文没强调自研检索器，复用了社区 SOTA 管线。生成侧可以是同一个模型，也可以是更新的、更强的模型，这套机制完全不挑模型。
五、为什么这件事对 2026 年的 LLM 推理应用至关重要
如果你是下面任一种角色，这篇论文几乎是必看：
- 推理型 LLM 应用负责人（数学辅导、代码助手、复杂问答）：这是直接能落地的工程范式，不是理论空谈；
- RAG 系统工程师：一个被忽视的"换语料"杠杆，性价比极高——你可能不需要更好的 embedder，你需要的是更好的 corpus；
- AI for math / AI for code 研究者：新的训练 / 评测范式参考；
- 教学产品 / 解题讲解类开发者：诊断化 trace 天然适合"讲思路"，对教学产品是直接能用的形态；
- 多模型团队：一个 trace 库统一服务多模型，边际成本极低，不必每家各自建库。
最关键的一句话：别再只往向量库里塞 doc 了——
如果你的下游任务是"让 LLM 写代码 / 解题 / 多步推理"，让模型自己先跑一遍当种子，把 trace 入库，再 RAG，收益往往比塞手册大。
六、三处落地风险别踩
风险 1：trace 生成成本是最大瓶颈
要有一个能跑出像样 thinking trace 的强 thinking model 当"老师"，冷启动成本不低。建议先用 Gemini-2.5-Flash 本身生成初版 traces，再人工 / 自动过滤高质量子集。
风险 2：诊断化 trace 的质量决定上限
T3.diagnose() 生成的"为什么错 / 哪步是岔路"注释完全依赖 LLM——注释错了或太泛化，检索命中后反而误导生成模型。需要对 diagnostic text 做人工抽检（每类问题抽 20 条），不合格就打回 prompt 工程。
风险 3：跨模型效果有选择性
AIME 上 GPT-5 只涨 7.6%，说明对强推理模型的边际增益已经较小。不要对所有模型都预期 50%+ 的增益——基准越强，trace 辅助效果越有限。
风险 4：trace 库的 Bad case 放大效应
诊断化 trace 把"犯过的错"显式化了——如果某类问题的错误 trace 被高频检索，而 reranker 质量不够好，生成模型会系统性复刻错误。需要对高频低质 trace 做降权或下架。
风险 5：56.3% 数字的语境
解读中的"相对 +56.3%"是相对增幅（而非绝对精度），且具体基准 / 子任务需对照原文 Table——不要直接拿这个数字做产品性能承诺。
七、写在最后
这篇论文最有价值的，不是 56.3% 这个数字，也不是 T3 这个工具，而是它给"RAG 在推理题上没用"的默认共识松了绑：
RAG 在推理题上看起来没用，不是因为 RAG 本身不行，而是因为被检索的"语料"错了。
把语料从"知识文档"换成"模型自己生成的思维痕迹"，再用 T3 做结构化 / 紧凑化 / 诊断化变换——RAG 就能稳定地、跨模型地提升推理表现。
下次有人跟你说"RAG 对推理任务没用"，你可以问三个问题：
「你的 RAG 语料是文档，还是模型的 thinking traces？」 「你的 traces 有没有做结构化 / 紧凑化 / 诊断化变换？」 「你的 reranker 质量能扛住 trace 库的 bad case 放大吗？」
——三个问题就能判断对方是真的试过 RAG-on-traces，还是只用过"塞手册"这种朴素 RAG。
延伸阅读
- 论文：arXiv 2605.03344（RAG over Thinking Traces）
- 开源仓库：github.com/Narabzad/t3（T3 转换器 + 建库 + 检索完整 pipeline）
- 同方向工作：Self-RAG / Self-Refine / STaR（在线反思派，互补）/ Prompt caching（重复利用派，可叠加）
- 工程模板：thinking model 选 Gemini-2-thinking-flash，embedder 选 BGE-M3，trace 库按 domain 分区是性价比最高的起步组合
三个标题变体
- 你的 LLM 解数学题老出错？——这篇论文说"RAG 不是没用，是你塞错语料了"
- 别再往向量库里塞文档了！用模型自己的思维痕迹做 RAG，推理任务也能涨 56.3%
- RAG 在推理题上不是没用——一篇论文告诉你：换语料 > 换模型，T3 把 thinking traces 整理成"可检索的解题思路"
小红书风格卡片文案（可直接发布）
🤖 你的 LLM 解数学题总出错？
RAG 没用？也许是你塞错语料了 📄
2026 年 7 月这篇论文（arXiv 2605.03344） 正面反驳了一个被默认了两年多的共识：
RAG 在推理题上看起来没用，不是因为 RAG 本身不行 而是因为被检索的"语料"错了
过去大家都默认： - RAG = 找外部知识 - 数学 / 代码 / 逻辑题瓶颈在算力，不在知识 - 所以给推理题塞文档 RAG 没意义 ❌
但这篇论文给了一个反直觉洞见 💡：
当模型（尤其是 thinking model）解题时 会留下大段的中间思考轨迹 ——搜索、试错、假设、折回 这些轨迹本身就是一个高质量检索库！
你塞官方手册 RAG 没效果 是因为手册是"通解"，不是"中间思路" 真正能辅助下一道题解的 是"上一道题解时模型卡在哪、改了哪步、为什么这么改" 恰好就是 thinking trace 的内容 ✨
效果有多炸 📈：
用 Gemini-2-thinking 生成的 traces 作 corpus 去辅助其他 reasoning model：
🔹 Gemini-2.5-Flash：AIME 2025–2026 相对 +56.3% 🚀 🔹 GPT-OSS-120B：相对 +8.6% 🔹 GPT-5：相对 +7.6%
跨模型也能涨 —— 一个团队内的 traces 库 可以被多家不同 reasoning model 的服务共享 边际成本极低 💰
关键工具 🔧：T3（Trace Transformation for Retrieval）
三种变换路线可组合：
1️⃣ 结构化：把长 trace 拆成"问题重述 → 子目标 → 关键中间事实 → 候选路径 → 错误与回退 → 最终结论" 2️⃣ 紧凑化：删除自反问 / 重复尝试，保留"决策性"步骤 3️⃣ 诊断化：在每步后追加"为什么这么走 / 错在哪 / 哪步是岔路"元注释 —— 论文自己强调最关键的洞察
最爽的是——T3 已经开源 🎉
GitHub：github.com/Narabzad/t3
你今天就能在自己代码里跑一遍
工程落地点 🛠️：
1️⃣ 别再只往向量库里塞 doc —— 让模型自己先跑一遍当种子，把 trace 入库再 RAG 2️⃣ 变换比检索更值钱 —— 90% 的失败是"语料形态不对"，不是 embedding 不够强 3️⃣ trace 库按 domain 分区 —— 避免跨域污染（math / code / science 分开建索引） 4️⃣ 诊断化 trace 要做人工抽检 —— 每类问题抽 20 条，注释不合格就打回 prompt 工程 5️⃣ 高频低质 trace 必须降权 —— 避免 bad case 被检索后系统性放大错误
⚠️ 必须警惕的边界： - trace 生成成本是最大瓶颈，需要强 thinking model 当老师 - 诊断化 trace 质量完全依赖 LLM，注释错了反而误导生成 - 对强推理模型（如 GPT-5）边际增益已经较小（仅 7.6%），别预期所有模型都 50%+ - 56.3% 是相对增幅，具体基准 / 子任务需对照原文 Table - trace 库版权与合规问题在商业产品场景需要确认
📎 论文 ID：2605.03344
💬 评论区聊聊：你用过 RAG 解推理题吗？换成 thinking traces 后效果怎么样？🤔