模块化 RAG 系统中使用推理模型的应用评估-首席AI分享圈

🚀邀请体验：中国首家 AI IDE 智能编程软件 Trae 中文版下载，不限量使用 DeepSeek-R1 和 Doubao-pro!

本文将介绍 Kapa.ai 近期在检索增强生成（Retrieval-Augmented Generation，简称 RAG）系统中，对 OpenAI 的 o3-mini 等推理模型进行探索的总结汇报。

模块化 RAG 系统中推理模型的实际应用评估-1

Kapa.ai 是一款由大型语言模型（LLM）驱动的 AI 助手，它可以通过 RAG 流程与知识库集成，从而回答用户提出的技术问题，并处理技术支持工单。

构建并维护一个稳定、通用的 RAG 系统并非易事。许多参数和设置都会影响最终输出结果的质量，并且这些因素之间还存在复杂的相互作用：

提示词模板
上下文大小
查询扩展
分块
重排序
等等

在对 RAG 系统进行调整，特别是集成新模型时，重新审视和优化这些参数对于保持良好的性能至关重要。然而，这项工作不仅耗时，还需要丰富的经验才能做好。

像 DeepSeek-R1 和 OpenAI 的 o3-mini 等新型推理模型，通过内置的思维链（Chain-of-Thought，简称 CoT）提示来“思考”问题，逐步推理，甚至在必要时进行自我修正，从而取得了令人瞩目的成果。据报道，这些模型在需要逻辑推理且答案可验证的复杂任务上表现更佳。相关阅读：DeepSeek R1 在 RAG 中的应用：实践经验总结、项目级代码生成结果出炉！o3/Claude3.7领跑，R1跻身第一梯队

因此，Kapa.ai 提出一个设想：如果推理模型能够分解复杂问题并进行自我修正，那么是否可以将它们应用于 RAG 流程中，处理查询扩展、文档检索和重排序等任务？通过构建一个信息检索工具箱并将其交给推理模型，或许可以建立一个更具适应性的系统，减少人工调整参数的需求。

这种范式有时被称为模块化检索增强生成（Modular Retrieval-Augmented Generation，简称 Modular RAG）。本文将分享 Kapa.ai 近期在重构标准 RAG 流程为基于推理模型的流程方面的研究成果。

假设

Kapa.ai 探索这一思路的主要目的是简化 RAG 流程，并减少对人工微调参数的依赖。RAG 流程的核心组件是稠密嵌入和文档检索。一个典型的高级 RAG 流程如下：

接收用户提示。
预处理查询以改进信息检索。
通过向量数据库中的相似性搜索找到相关文档。
对结果进行重排序，并使用最相关的文档。
生成回复。

模块化 RAG 系统中推理模型的实际应用评估-1

流程中的每一步都通过启发式方法进行优化，例如过滤规则和排序调整，以优先处理相关数据。这些硬编码的优化定义了流程的行为，但也限制了其适应性。

为了让推理模型能够利用 RAG 流程的各个组件，Kapa.ai 需要对系统进行不同的设置。不再定义一个线性的步骤序列，而是将每个组件作为一个独立的模块，供模型调用。

模块化 RAG 系统中推理模型的实际应用评估-1

在这种架构中，具有推理能力的模型不再遵循固定的流程，而是可以在更大程度上动态地控制自己的工作流程。通过利用工具，模型可以决定何时以及以何种频率运行完整检索或简化检索，以及使用什么检索参数。如果成功，这种方法有可能取代传统的 RAG 编排框架，如 LangGraph。

此外，一个更加模块化的系统还可以带来一些额外的好处：

可以在不彻底改造整个流程的情况下，替换或升级单个模块。
更清晰的职责分离使得调试和测试更易于管理。
可以测试和更换不同的模块（例如，具有不同嵌入的检索器）以比较性能。
模块可以针对不同的数据源独立扩展。
它有可能允许 Kapa.ai 构建针对特定任务或领域定制的不同模块。

最后，Kapa.ai 还希望探索这种方法是否可以帮助更有效地“短路”滥用或离题的查询。最难处理的情况通常涉及歧义，即不清楚查询是否与产品相关。滥用查询通常是故意设计的，以逃避检测。虽然更简单的情况已经可以有效地处理，但 Kapa.ai 希望推理模型能帮助更早地识别和退出更复杂的问题。

测试设置

为了试验这种工作流程，Kapa.ai 搭建了一个沙盒 RAG 系统，其中包含必要的组件、静态数据和一个以 LLM 作为裁判的评估套件。在一种配置中，Kapa.ai 使用了一个典型的固定线性流程，其中内置了硬编码的优化。

对于模块化 RAG 流程，Kapa.ai 使用 o3-mini 模型作为推理模型，在不同的策略下运行了流程的各种配置，以评估哪些方法有效，哪些无效：

工具使用： Kapa.ai 尝试让模型完全访问所有工具和整个流程，也尝试将工具使用限制为单个工具与固定线性流程的组合。
提示和参数化： Kapa.ai 测试了使用最少指令的开放式提示和高度结构化的提示。Kapa.ai 还尝试了各种程度的预参数化工具调用，而不是让模型自己决定参数。

在 Kapa.ai 进行的所有测试中，将工具调用次数限制在最多 20 次——对于任何给定的查询，模型只允许最多使用 20 次工具调用。Kapa.ai 还在中等和高等推理力度下运行了所有测试：

中等： 较短的 CoT（思维链）步骤
高等： 更长的 CoT 步骤，包含更详细的推理

Kapa.ai 总共对不同的模块化 RAG 配置进行了 58 次评估。

结果

实验结果喜忧参半。在某些配置中，Kapa.ai 观察到了一些适度的改进，最显著的是在代码生成方面，以及在有限程度上的事实性方面。然而，与 Kapa.ai 传统的手动调整的工作流程相比，信息检索质量和知识提取等关键指标基本保持不变。

在整个测试过程中反复出现的一个问题是，思维链（CoT）推理会增加延迟。虽然更深层次的推理允许模型分解复杂的查询并进行自我修正，但这是以迭代工具调用所需的额外时间为代价的。

Kapa.ai 发现的最大挑战是“推理≠经验谬误”：推理模型尽管能够逐步思考，但缺乏使用检索工具的先验经验。即使使用严格的提示，它也很难检索到高质量的结果，也很难区分好的和坏的输出。该模型经常犹豫是否使用 Kapa.ai 提供的工具，这与 Kapa.ai 去年使用 o1 模型进行的实验类似。这凸显了一个更广泛的问题：推理模型擅长抽象的问题解决，但在没有事先训练的情况下优化工具的使用仍然是一个悬而未决的挑战。

主要结论

实验揭示了一个明显的“推理≠经验谬误”：推理模型本身并不“理解”检索工具。它理解工具的功能和用途，但不知道如何使用它，而人类在使用工具后会拥有这种隐性知识。与传统流程不同，传统流程的经验被编码在启发式和优化中，推理模型必须被明确地教导如何有效地使用工具。
尽管 o3-mini 模型能够处理更大的上下文，但 Kapa.ai 观察到，在知识提取方面，它并没有比 4o 或 Sonnet 等模型有显著改进。仅仅增加上下文大小并不是提高检索性能的灵丹妙药。
增加模型的推理力度只会略微提高事实准确性。Kapa.ai 的数据集侧重于与实际用例相关的技术内容，而不是数学竞赛问题或高级编码挑战。推理力度的影响可能会因领域而异，对于包含更多结构化或计算复杂查询的数据集，可能会产生不同的结果。
该模型确实擅长的一个领域是代码生成，这表明推理模型可能特别适用于需要结构化、逻辑输出而不是纯检索的领域。
推理模型不具备工具相关的知识。