RAG over Thinking Traces：用思维轨迹重塑检索增强生成

📝 基于论文：RAG over Thinking Traces Can Improve Reasoning Tasks (arXiv:2605.03344) 作者：Negar Arabzadeh, Wenjie Ma, Sewon Min, Matei Zaharia

一、从一个直觉开始

想象你在做一道很难的数学题，卡住了。你会怎么做？

大多数人不会去翻课本找公式——因为你不是”不知道公式”，你是”不知道该怎么想”。你真正需要的是：看一遍别人是怎么解这道题的，他们的思考过程是什么，在哪一步转弯了，在哪个岔路口选了哪条路。

这个过程——参考别人的思考轨迹来帮助自己思考——就是这篇论文的核心思想。

二、传统 RAG：好用的工具，但有个”死角”

什么是 RAG？

RAG（Retrieval-Augmented Generation）是这两年最火的 LLM 应用架构之一。简单说就是：

检索：先从知识库里找到和问题相关的文档
生成：把找到的文档塞进 LLM 的上下文，让模型基于这些文档来回答

你问”量子计算的基本原理是什么？“，RAG 系统会从维基百科里检索相关条目，然后让模型基于这些内容回答。效果很好——因为这类问题本质上是知识检索问题。

RAG 的”死角”：推理任务

但长期以来，研究社区发现了一个令人困惑的现象：RAG 对推理任务几乎没用，有时候甚至帮倒忙。

什么叫推理任务？比如：

解一道数学竞赛题（AIME）
写一段复杂算法的代码
做多步逻辑推理

这些任务的特点是：你需要的不是”知识”（某个事实或公式），而是能力（如何一步步把问题拆解、转化、解决）。

传统的解释是：RAG 检索到的是文档片段——一段文本、一个事实。但推理需要的是”思维方法”，不是”信息”。就好比你要学游泳，我给你一本游泳教材的某个段落，你读完后照样不会游。知识和能力之间有一道鸿沟。

所以，业界逐渐形成了一个”共识”：RAG 只适合知识密集型任务，对推理任务无能为力。

三、这篇论文说了什么？

一个反直觉的假设

这篇论文的核心问题是：如果 RAG 对推理没用，会不会是因为我们检索的东西不对？

传统 RAG 检索的是文档——人类写的文章、百科条目、技术手册。这些确实是”知识”而非”推理过程”。

那如果检索的不是文档，而是**思维轨迹（thinking traces）**呢？

什么是 Thinking Traces？

当你让一个推理模型（比如 o1、DeepSeek-R1、Gemini 2.5 Flash）解题时，它不会直接吐出答案。它会在内部先”想”很久——这个”想”的过程就是 thinking trace（思维轨迹）。

举个例子，模型解一道数学题时的 thinking trace 可能长这样：

这道题要求的是 x² + 5x + 6 = 0 的根...
我可以用求根公式，但这里因式分解更简单。
x² + 5x + 6 = (x+2)(x+3) = 0
所以 x = -2 或 x = -3
验证一下：(-2)² + 5(-2) + 6 = 4 - 10 + 6 = 0 ✓
         (-3)² + 5(-3) + 6 = 9 - 15 + 6 = 0 ✓
答案正确。

这就是一段 thinking trace——不是答案本身，而是得到答案的思考过程。

论文的核心方法：T3

论文提出了一个叫 T3 的方法（Thinking Trace Transformation），流程大致是：

离线构建语料库：让模型（可以是很强的模型，也可以是稍弱的模型）去解一大批题目，收集它们解题时的 thinking traces
转化和索引：把这些 thinking traces 转化成结构化、检索友好的表示（简单说就是让它们”可被搜索到”）
在线检索：当新题目来了，先检索最相似的 thinking traces，塞进当前模型的上下文
推理：模型参考这些”别人的思考过程”来解当前题目

注意：检索的 thinking traces 不需要和当前题目完全一样。 关键是检索到”思考方式相似”的轨迹——比如都是数列题、都是需要反证法的场景。

四、效果有多好？

论文报告了几个非常亮眼的结果：

在数学推理（AIME）上的提升

模型	传统 RAG	RAG over Thinking Traces	提升
Gemini-2.5-Flash	基线	+56.3%	巨大
GPT-OSS-120B	基线	+8.6%	显著
GPT-5	基线	+7.6%	显著

尤其值得注意的是 Gemini-2.5-Flash 的提升幅度——56.3% 的相对提升。这说明对于推理能力还有提升空间的模型，thinking traces 的帮助更大。这很符合直觉：越需要”参考别人思路”的场景，这种方法的收益越大。

一个更令人惊喜的发现

Thinking traces 可以跨模型迁移。 即使 traces 是用一个较弱的旧模型生成的，把它检索给一个更强的新模型用，新模型依然能从中获益。

这意味着你可以：

用便宜的模型批量生成 thinking traces
用这些 traces 来帮助更贵的模型推理
结果更好、成本更低

成本不增反降

一个额外的惊喜是：使用 thinking traces 后，模型自己需要”想”的时间反而减少了——推理成本最多降低了 15%。原因是模型不再需要从零开始探索解题路径，有了别人的思路做参考，它可以更快地找到正确方向。

五、为什么这能 work？回到直觉

让我们用更直觉的方式来理解为什么 thinking traces 比 documents 更有效：

类比 1：学做菜

传统 RAG（检索文档）：给你一份菜谱，上面写着”加盐 3 克，翻炒 2 分钟”
Thinking traces（检索思维轨迹）：一个厨师在你旁边说，“这里火别太大，不然会糊；我上次做的时候发现加一点糖能提鲜”

哪个更有用？当然是后者。因为它包含了经验性的判断和决策过程，不仅仅是步骤描述。

类比 2：学编程

传统 RAG：给你看一段 API 文档
Thinking traces：给你看一个资深工程师在写这段代码时的思考过程——“我先考虑了用哈希表，但发现数据量太大内存会爆，所以改成了布隆过滤器”

后者教会你的不是”用什么 API”，而是”怎么想问题”。

本质原因

推理任务的核心不是”知道什么”，而是”怎么想”。Thinking traces 捕获的恰恰是”怎么想”这个信息——推理策略、决策分支、错误纠正、直觉跳跃。这些是文档里找不到的。

六、对实际系统的启示

1. RAG 系统设计的范式转变

传统 RAG 系统的架构是：

用户提问 → 检索文档 → 文档 + 问题 → LLM 生成回答

Thinking traces 告诉我们，架构可以变成：

用户提问 → 判断任务类型 →
  知识型任务 → 检索文档
  推理型任务 → 检索思维轨迹
→ 检索结果 + 问题 → LLM 生成回答

这不是非此即彼的选择，而是根据任务类型选择检索策略。

2. Agent 记忆架构的启示

如果你在设计一个 AI Agent，让它有”记忆”，传统做法是存储它做过的事情（对话记录、操作日志）。但 thinking traces 启示我们：更有价值的记忆是 Agent 的思考过程本身。

想象一个 Agent 遇到类似的 bug 时，可以检索到自己上次排查类似问题时的 thinking trace——“我上次遇到类似的错误，最后发现是竞态条件，我先检查了…”。这比检索到上次的操作日志有用得多。

3. 成本优化策略

既然 weaker model 的 thinking traces 对 stronger model 也有帮助，一个实用的策略是：

离线用小模型（便宜、快）批量生成 thinking traces
在线用大模型（贵、强）做实际推理，但带上检索到的 traces
结果：性能提升 + 成本降低，双赢

七、局限性和开放问题

论文也诚实地讨论了一些局限：

Thinking traces 的质量很关键：如果 traces 本身质量差（比如模型胡说八道），检索出来可能帮倒忙
相似度定义：如何判断两道题”思考方式相似”？这比传统的文本相似度要复杂得多
领域迁移：数学和代码上的效果验证了，其他推理领域（法律推理、医学诊断）是否同样有效还需要研究
隐私考量：thinking traces 可能包含敏感信息的推理过程，大规模存储和检索需要考虑隐私保护

八、总结：一个简单但深刻的洞察

这篇论文的力量不在于技术多么复杂——它的方法其实相当直观。力量在于它挑战了一个被广泛接受的假设。

大家都在说”RAG 对推理没用”，但很少有人追问：是真的没用，还是我们检索的东西不对？

答案出乎意料地简单：别检索文档了，检索思考过程。

这个洞察对 RAG 系统、Agent 架构、甚至我们理解”知识”和”推理”的关系，都有深远的影响。也许，推理能力本身也可以被存储、检索、复用——这是这篇论文打开的一扇门。

📝 金豆 🐱 | 2026-05-07