RAG推理篇：机制、算法与性能优化全面解析_AI热点日报

2025年RAG技术发展聚焦于增强大语言模型的推理能力。以DeepSeekR1为代表，通过强化学习生成的思考链显著提升了模型的推理与计算能力。主流技术路线包括优化Agent框架、改进模型结构及结合启发式搜索。诸多工程化方案如Searcho1、PIKE-RAG和AgenticReasoning，借助迭代分解问题与动态检索来构建高质量推理链，但普遍面临评估搜索质

探索2025年的RAG技术革新：深度解析LLM的推理与决策能力

2025年初，DeepSeek R1带来的冲击直接将我们对LLM推理与决策能力的预期提前了大半年——这种节奏变化确实耐人寻味。如何让LLM具备更强的推理能力，已成为当前最热门的研究方向之一。随之而来的问题是：随着LLM推理能力的进化，RAG技术需要做出哪些调整？这正是我们撰写本文的初衷。

先澄清一个概念。中文里的“推理”对应两个英文词：一个是Inference（与Training相对），另一个是Reasoning，指对已知信息进行演绎和综合，推导出新知识与结论的过程。今天我们要讨论的推理，毫无疑问指的是后者——它是真正驱动LLM释放更大价值的核心动力。其实推理并非R1首次引入，LLM自身的推理能力早在2024年的Agent系统中就已广泛应用。流行的Agent框架通常包含四大模块——Plan、Memory、Action、Tool，以及若干设计模式，其中最知名且最易实现的便是ReAct。那么，基于过去LLM的推理，与R1带来的推理相比，能力上究竟有何差异？答案就藏在R1引入的思考链（Chain of Thought）中。简单总结，推理的实现有以下几条技术路线：

路线一：利用提示词实现Agent框架，例如基本的ReAct。其实即使没有R1，LLM也具备一定的推理能力，但它需要跟随用户指令。ReAct的含义就是直接让LLM进行Reasoning + Action。Reasoning阶段利用LLM生成分析步骤，解释任务上下文或状态，为下一步行动提供逻辑依据；Action则依据推理结果生成工具调用请求，如搜索、API调用、数据库检索等，将推理转化为行动。Reasoning和Action每一步都基于前一步的观察结果，这是一个逐步迭代的过程。不过，ReAct的执行是线性的，每一步紧密依赖前一步的输出——如果前一步出错，后续步骤就会受影响。Function Call解决的是类似问题，但它要求LLM在训练时包含Function Call相关内容，对模型有一定要求。值得注意的是，在许多Agent框架中，RAG的角色被低估了，导致ReAct的威力未能充分释放，Agent在实际应用中往往停留在基本任务规划层面，未能充分体现LLM的价值。这也是为什么在2024年Claude的博文中提到，实际场景中Agent的效果反而不如人工界定的工作流。

路线二：改进模型本身——这正是R1采用的路线。R1已证明通过强化学习训练、鼓励模型合成CoT推理轨迹并从中学习的巨大价值。CoT能显著提升LLM的计算能力，而计算能力正是推理的基础。CoT通过将一个复杂问题分解为多个中间步骤，增加了模型进行计算和信息处理的步骤数。可以这样理解：CoT为模型提供了更多串行计算的机会，从而提升了整体计算能力。更长的CoT链条，让模型在每一步都能进行更精细的推理，逐步逼近正确答案。

路线三：对模型结构本身进行扩展，例如RAG，添加记忆模块，并借助Agent机制。这条路线与路线一非常接近，区别主要在于是否将RAG放在足够重要的位置。RAG代表着数据基座——只有基于数据制定思考和推理计划，才能更有针对性地提问和回答，避免路线一单纯依赖LLM和简单工具、在高级场景面前束手无策的困境。

根据相关研究，推理本质上是一种在求解空间中进行搜索的过程。在RAG层面体现推理的一个重要手段，是结合启发式搜索与增量微调。以ReAct为例，LLM把问题分解成一系列逻辑子问题，但这种分解具有局限性——基于ReAct的模式容易陷入局部最优，导致推理能力偏弱。这是因为ReAct每一步的选择都依赖局部信息，一旦选错搜索路径，后续步骤很难调整。因此，一种思路是引入蒙特卡洛树搜索（MCTS）作为启发式搜索，通过奖励模型或奖励函数评估搜索路径的质量，解决局部最优问题。已有研究尝试结合RAG和MCTS提供类似o1的推理能力，区别在于有的借助奖励函数，有的借助奖励模型，因此需要引入对模型的增量微调。不过，MCTS的计算量巨大，它通过平衡探索和利用，在不确定的搜索链路上寻找最优路径，而且还需要确定的奖励函数或模型。这导致在工程实现上，很难提供通用的解决方案。但在一些垂直场景中，RAG + MCTS的组合已开始出现案例，比如通过准备足够的自然语言和SQL的映射作为RAG知识库，并设计定制的奖励规则，从而结合MCTS提供不需要微调LLM的Text2SQL方案。

说到这里，有必要提一下RAGFlow的最新版本。它只关注路线三，而且只关注如何提供通用方案，如何在基本RAG基础之上进一步解锁推理功能，让RAG可以在用户自有数据上，提供自己的R1或o1。不过，采用启发式搜索和增量微调、以强化学习为基础的手段，并不在RAGFlow当前的能力规划——当然，这仅仅是2025年春季的演进路线。

在整理各路工业和学术路线之前，先回答一个问题：是否基本的RAG直接接上R1或o1，就能具备推理能力了？答案当然没那么简单。虽然基于内部数据提供的素材，利用R1或o1可以直接生成推理链，产生更好的答案，但有一个问题不容忽视：这个答案的思考过程并非R1或o1基于RAG返回的数据，而是仍然来自模型本身的思考——打个比方，就是用户提问，搜索素材，然后思考。那么，根据这些素材思考的过程是否充分，就是个很大的疑问，因为推理模型只能根据这些素材去思考。

下面进入正题，看看各路工作是怎么做的。

从Search o1到PIKE-RAG：一个工程化的思路

首先是一个叫O1 Embedder的工作。它试图通过训练得到一个具备推理能力的Embedding模型，确保能同时生成高质量的思考内容和精准检索的能力。具体做法是，准备包含查询、LLM生成的思考内容以及相关文档的数据集，用来训练Embedding模型。这个模型给定文本，可以返回Embedding，也可能返回思考内容。所以它不是普通的Embedding模型，而是一个既包含Embedding，也包含Decoder结构的文本生成组件。必须承认，这种探索是有意义的，但推理能力如果脱离了LLM，无异于放弃了整片森林。

接下来是Search o1，这个名字一听就知道是专门在RAG基础之上提供推理能力的。Search o1的工作流程包含两条主线：一条是推理链，另一条叫Reason-in-Documents，两者协同工作。推理链由推理模型生成，具体步骤包括：

初始化推理链：通过理解和分解问题，提供问题背景和推理总体要求，提出具体需要解决的问题。
逐步生成推理步骤：把复杂问题分解成多个小问题或推理步骤；基于已知信息（模型内部知识和已检索到的知识）逐步生成推理步骤；每一步推理都生成逻辑上连贯的句子或段落，逐步推进问题解决。
检测知识缺口：在推理过程中，模型可能会遇到知识不足的情况，比如不确定某个概念的定义、不清楚某个过程的具体细节、需要最新信息等。此时，模型会生成一个检索查询。
根据检索查询触发外部检索。
根据外部知识检索的结果进行凝练，把知识注入到推理链，继续推理。

Reason-in-Documents则主要解决另一个问题：在RAG推理中直接使用检索到的文档可能导致冗余信息过多，干扰推理的连贯性。它独立于主推理链运行，对检索到的文档进行深度分析和精炼，提取和当前推理步骤相关的有用信息。

Search o1的工作很完整，可以说是纯工程性的学术工作。相比RAG直接套R1的做法，Search o1最大的不同在于引入了迭代——通过迭代推理来反复修正，得到高质量的问题，才能找到高质量的答案。但这里有两个核心问题：

如何判断当前的思考是高质量的？
如何决定当前迭代可以终止？

这两个问题很难解决，或者说其实没有完全解决。但这并不代表这种工程式的工作不work。

来自微软的PIKE-RAG，同样依赖LLM对用户问题进行思考和任务分解，生成多个子问题。不同的是，它依赖GraphRAG来精炼，具体做法是在知识图谱上对多个子问题进行搜索，然后汇总多个子问题的答案，得到多跳回答的结果。PIKE-RAG的特点是知识感知的任务分解——任务分解过程会考虑知识库的内容，确保分解的问题能有效引导检索和推理过程。如果知识库中存在特定的知识结构，任务分解就会生成与这些结构匹配的原子问题。具体来说，PIKE-RAG通过迭代方式构建推理链，每次迭代中，系统会根据当前子问题检索知识片段，并根据检索到的知识更新推理链。每次迭代，系统会从生成的原子问题中选择最相关的一个，检索对应的知识片段，这些片段逐步积累，形成推理链。当系统认为已经积累了足够的知识片段，或者进一步分解不再需要时，推理链构造就会终止。PIKE-RAG和Search o1非常接近，都是工程性工作的代表。

Agentic Reasoning与LevelRAG：Agent化的进一步探索

再来看看Agentic Reasoning框架，从论文标题就能看出，它是利用Agent框架来实现Deep Research。Agentic Reasoning的核心思想是让LLM在推理过程中像人类一样动态调用外部工具，获取信息、执行计算和规划思路。推理模型在处理问题时，会根据当前推理上下文判断是否需要调用外部工具，生成相应请求。这个框架包含三个内置Agent：

思维导图Agent：推理模型生成推理链时，它会将推理链中的实体和逻辑关系提取出来，构建一个动态更新的知识图谱。当推理模型需要澄清逻辑关系或查询特定信息时，通过知识图谱检索相关信息，辅助推理。
Web Search Agent：推理模型在过程中如果需要来自Web Search的信息，会生成查询请求，Web Search Agent收到请求后调用Web Search API检索内容，结果整合到推理链中。
Coding Agent：主要用来生成代码。推理模型如果需要执行计算任务，Coding Agent会根据提示词生成Python代码并执行，结果以自然语言形式返回并整合到推理链中。

可以看出，Agentic Reasoning和Search o1基本是同类，只是增加了Coding Agent来执行一些计算任务。

最新的LevelRAG，和以上几个工作也基本类似，只是称呼不同：执行思考和问题分解的叫High-Level Searcher，执行具体搜索的叫Low-Level Searcher。概念清晰，结构直观。

OmniThink：从问答到报告生成

来自浙大和阿里通义的OmniThink，同样是一个Deep Research类的工作，但它并非基于推理的问答系统，而是基于推理的报告生成——旨在通过模拟人的思考过程，以RAG为基座生成高质量的长文本内容。它的工作过程分为三个阶段：

通过迭代的扩展和反思，构建信息树和概念池。信息树是层次化的知识表示，用来组织和存储与写作主题相关的所有搜索到的信息；概念池是动态更新的知识集合，存储OmniThink对写作主题当前的理解，包含从信息树中提取的核心观点以及通过思考过程得到的见解。
基于概念池生成文章大纲。
根据大纲生成文章内容，并通过语义相似性检索相关信息，最终得到完整文章。

从输入主题开始，OmniThink通过Web搜索引擎检索与主题相关的初始信息，构建信息树的根节点，形成初始概念池。接下来，分析信息树的所有叶子节点，判断它们是否需要进一步扩展。对于需要扩展的节点，基于当前概念池生成子节点，每个子节点代表当前节点的一个具体方面或子主题，然后为每个子节点检索相关信息并添加到信息树的相应位置。反思阶段会对新检索到的所有叶子节点的信息进行分析、过滤和综合，提取核心观点并整合到概念池中，指导下一步扩展。这是一个迭代过程，直到满足以下条件之一：获取的信息足够丰富，可以用于文章生成；达到预设的最大检索深度。

至此可以看出，从Search o1开始的这些工作都是纯工程实现，没有引入任何算法和模型上的创新。它们的核心都是以LLM和迭代为基础，不断生成合适的问题或主题。但它们都面临同样的问题：推理链的质量如何评估？迭代式反思如何终止？

RAG-Gym与DeepRAG：强化学习与模仿学习的尝试

RAG-Gym，看名字就与强化学习有莫大关系。它的核心思想是把问答任务建模为一个嵌套的MDP（马尔可夫决策过程）：外层MDP控制和检索环境的交互，内层MDP控制LLM的Token生成，外层MDP的奖励模型基于最终预测的正确性。RAG-Gym是真正基于强化学习的Agent，采用监督微调等方式训练Agent，奖励模型的训练目的是让Agent知道哪些查询和推理是高质量的，从而引导Agent做出更好的决策。训练数据的收集，是通过收集智能体的决策轨迹，然后标注其中的高质量数据得到的。RAG-Gym能解决上面提到的问题——通过强化学习评估质量，并决定迭代终止。

同类工作还有DeepRAG，它同样将基于RAG的推理建模为MDP，通过迭代分解查询，动态决定每一步是检索外部知识还是依赖参数进行推理。DeepRAG专门解决上述推理工作的核心痛点：

子任务拆分不合理：有的问题不需要额外信息，但系统仍然盲目搜索，引入干扰。
缺乏决策机制：在什么情况下需要检索，没有智能判断的能力。

不过，DeepRAG并没有直接引入强化学习，而是采用模仿学习搭配微调，帮助模型更好地理解其知识边界。

不论是RAG-Gym还是DeepRAG，都依赖LLM的监督微调，因此落地并不容易，更多是对解决推理痛点的一种探索。

RAGFlow 0.17：一个开源Deep Research方案的落地

在RAGFlow已经发布的0.17版本中，选择了工程更友好的方式来实现。具体做法结合了Search o1、PIKE-RAG、Agentic Reasoning、LevelRAG等工作之长，是一个开源的Deep Research类工作的复现：

迭代式生成推理链。
每步推理链都会产生若干子问题，这些子问题触发搜索请求。
搜索内容包含内部数据，也可以通过用户提供的API Key直接调用Web搜索。这在很多场景中很有必要——企业内部数据往往对通用知识的描述不足，允许用户选择性调用Web搜索来补充问题潜在的上下文常识。
搜索内容还可以包含知识图谱。事实上，GraphRAG和推理是非常有效的搭档。在RAGFlow的GraphRAG实现中，不仅构造了知识图谱，还针对原文的每个Chunk，通过调用LLM生成了该Chunk可能提出的问题。这些问题保存在后台数据库中。在LLM思考和产生推理链时，这些问题以及知识图谱是重要的搜索对象，能帮助LLM生成更有效的提问，提供更丰富的素材。
由LLM判断迭代是否需要终止。如果LLM一直没有判定，则根据阈值终止迭代。
最后根据完整的推理链汇总内容，得到最终结果，实现完整的Deep Research逻辑。

下边是采用RAGFlow连接DeepSeek V3得到的推理对话结果，看起来和DeepSeek R1的结果十分类似。

在使用推理大模型的过程中，目前有这样的体会：

目前RAGFlow的推理型RAG（也就是Deep Research），连接普通LLM（如DeepSeek V3）和连接推理LLM（如R1），效果上差距不大。但R1的思考过程很长，再引入这种迭代式思考，会变得更长，所以其实不推荐直接使用R1。
并不是所有RAG都依赖R1。举例来说，有社区用户采用RAGFlow连接R1，但同时勾选了让LLM抽取关键词甚至知识图谱，这会极大增加系统入库的延迟。因为R1会对每个入库的Chunk经过长时间思考才产生输出，而这些输出仅仅是一些关键词或知识图谱的命名实体，并不需要思考来获得，这时用R1非常不合算。
这绝不是说R1没有价值。恰恰相反，当前的R1由于无法直接提供推理链的API，因此无法利用用户数据生成专有的推理链，也无法实现一边推理思考一边检索数据的模拟人类思维过程，这不能不说是R1面向企业使用的一个痛点。因此，在当前RAGFlow所做的这些工作，是在DeepSeek开放推理链API之前，让企业也能利用自己的数据受益于推理的探索。在各种场景下，接普通LLM和接推理LLM产生的结果有哪些差异，也欢迎广大社区用户给到有益的反馈。
最后，期望DeepSeek R1这样的推理模型尽快提供推理链专用API，这样可以结合大模型强大的推理能力，针对用户数据生成更有价值的推理链，解锁更大的商业价值。

通过RAGFlow的Deep Research类工作，已经可以将LLM的推理能力真正面向企业端产生实际价值。比如，可以结合健康数据、病例给出诊断建议类报告；结合经营数据、运营数据给出企业商业辅助决策；结合规章制度、案例给出判定决策辅助……诸如此类。如果说过去的RAG仍然停留在知识库、问答、客服等浅层应用，那么今天的RAG已经开启了辅助决策的大门。去年底Claude的博文中曾断言，Agent的价值还未充分发挥，因此实际场景中工作流采用更多。这个断言，随着推理能力的落地和进化，一定会发生变化——让LLM的思考充分发挥决策作用，尽量减少人工编排和Plan，是真正让AI走向普适的标志。这个标志今天已经出现，并且今年会加速进化。这也是RAGFlow如此快速推出推理能力的主要原因。推理 + 搜索，就是AI服务企业的核心依托。