易术研究 | 从 Naive RAG 到模块化 RAG的演变

大语言模型（LLM）的崛起让自然语言处理取得突破，但也暴露出幻觉（hallucination）和知识时效性不足等问题。例如，模型可能自信地生成错误信息，或因训练语料限制无法回答最新的业务问题。这些缺陷在企业应用中尤为棘手：企业场景下用户提出的很多问题涉及最新的行业动态、专业知识或企业内部资料，超出了模型静态训练知识的覆盖范围。

检索增强生成（Retrieval-Augmented Generation, RAG）的提出正是为了解决上述难题。RAG在LLM生成回答前引入了一个外部知识检索步骤：模型会先根据用户问题从企业知识库或数据库中检索相关资料，将检索到的证据与原始提问一起提供给LLM用于作答。通过这一机制，LLM不需要重新训练就能访问外部最新的、领域特定的信息，从而提高回答的准确性和可信度。尤其在知识密集型任务中，RAG能够显著降低模型胡编乱造的概率，并支持持续的知识更新和扩充，实现对新信息的及时整合。

RAG自提出以来迅速成为大模型应用的主流架构之一。在实际场景中，许多对话型产品和企业知识问答系统几乎都建立在RAG思路之上。这背后有几个原因：第一，RAG方案实用且易于实现，企业无需耗费巨资微调超大模型，只需构建检索库就能让模型利用最新知识回答问题；第二，RAG输出的答案往往可以附带来源依据（例如引用文档片段），增强了结果的可追溯性，这对企业合规和决策尤为重要；第三，RAG架构灵活可控，开发者可以方便地更新知识库或调整检索策略，以应对业务需求变化，而不必频繁训练模型。正因如此，RAG已经成为在企业落地大模型时广受青睐的技术范式。

朴素 RAG：最早期的 RAG 模式可视为简单的“检索-阅读”流程。首先，系统对企业内部的文档资料进行索引处理：将文档拆分成便于处理的知识块并计算向量表示，构建向量检索库。接着，当用户提出查询时，系统利用相似度匹配在向量库中执行检索，取回与查询语义接近的 top K 个文本块。最后，将这些检索到的内容与原始问题一并拼接作为提示输入给LLM，令其根据提供的上下文信息生成回答。这种朴素RAG不涉及复杂的流程控制，也缺少额外的优化步骤，主要依赖向量检索的结果直接喂给模型。因此实现成本低且通用性强，在早期已展示出优于纯LLM的性能。然而，它也埋下了诸多隐患，后文将详述其局限。

高级 RAG：随着应用需求提升，研究者针对朴素RAG暴露的问题引入了增强型的模块和策略，形成“高级”RAG。高级RAG在检索前、检索中和检索后各阶段都进行了专项改进：例如，在检索前增加查询预处理模块，自动将用户原始问题改写得更加清晰或扩展出相关子查询，以弥补直接检索的不足；在检索中优化嵌入模型（通过领域微调或采用动态上下文感知Embedding）来提高召回的相关性；在检索后增加结果过滤和重排序步骤，利用重排算法将更相关的内容靠前，并压缩无关内容以适配LLM的上下文窗口限制。同时，高级RAG往往引入一些新机制来改进知识整合：比如避免简单拼接多个文档导致的冗余和风格不一致问题，可采用摘要压缩技术提取关键信息，或引导LLM在回答时仅引用必要内容。通过这些改进，高级RAG相对朴素版本在检索精度、效率和生成质量上都有明显提升，对复杂任务有更强的适应能力。

模块化 RAG：在更复杂和多样的企业场景下，RAG体系进一步演进为模块化架构。模块化RAG并非单指某个固定流程，而是强调将RAG流程拆解为松耦合的功能模块，像搭积木一样灵活组合。相比高级RAG只是对既定流程加以优化，模块化思路允许增添全新的模块并重组流程。典型的模块化RAG体系中，除了基本的“索引-检索-生成”模块外，还可以包括：独立的查询理解/重写模块（预检索）、候选结果处理模块（后检索，例如排序、过滤、合并）、长短期记忆模块（用于缓存常见问答或对话历史）、路由与决策模块（根据查询类型选择不同检索策略或数据源），以及负责协调各模块工作的编排（Orchestration）模块。借助这些模块的组合，RAG系统可以实现更丰富的功能，例如同时执行混合检索（将向量语义检索与关键词检索结合）、迭代检索（递归地细化查询，多轮获取深层信息）或对接外部工具/API（如查询数据库、调用计算程序），从而更好地满足复杂查询需求。模块化RAG突出一个“灵活定制”的理念：开发者能够按需添加、移除或替换模块，调整它们的连接方式，打造最适合企业应用场景的检索生成系统。更重要的是，不同模块还可以独立优化和训练，甚至各模块间支持端到端联合调优，使整体系统性能进一步提高。需要指出的是，朴素RAG与高级RAG其实可以被视作模块化RAG在特定约束下的两种“子集”——高级RAG是模块化思想的早期形态之一，而朴素RAG则是高级RAG的极简特例。因此，模块化RAG代表了RAG体系走向成熟的一般方向。

尽管RAG架构为大模型注入了外部知识，但在企业知识的复杂性面前，早期朴素RAG方案的局限性很快暴露出来，驱动着RAG体系不断演进。要理解模块化RAG兴起的动因，我们需要剖析朴素RAG在企业场景中遇到的根本问题：

检索精度与语义理解不足：朴素RAG通常依赖向量相似度来检索文档碎片，这对专业领域的查询未必可靠。企业内部知识往往包含行业术语、专有名词或上下文依赖的内容，简单相似度检索可能无法深刻理解用户意图，出现检索偏差或遗漏关键信息的情况。例如，对于一个措辞复杂或含糊的提问，朴素RAG可能检索到若干表面相关但实质无关的段落，导致生成答案驴唇不对马嘴。此外，如果企业知识库规模庞大，语义接近的干扰项增多，朴素检索方法的查全率和查准率会进一步恶化。这一点在长尾问询或跨领域综合问题上尤为明显：朴素RAG难以精准理解并匹配出所有相关信息。

检索结果噪音与冗余：在朴素RAG流程中，检索来的多个文档块通常未经严格筛选就直接拼接给LLM。这种粗放做法带来的一个问题是信息噪音——某些检索块可能与问答关系不大，却占用了宝贵的上下文空间，干扰模型关注真正重要的内容。甚至不同块可能内容重复或来源于不同时间，混杂在一起使模型难以判断可信度。冗余和噪音不仅浪费上下文窗口（可能导致有用信息因为长度限制被截断），还可能引发模型的幻觉式回答或风格混乱。朴素RAG缺乏对检索结果的优选和整合手段，无法保证提供给模型的是精炼且一致的知识背景。

生成环节失控与依赖：有了外部知识并不意味着LLM就万无一失。朴素RAG在生成环节仍可能遇到Hallucination问题：模型可能基于不充分的检索内容自由发挥，生成不真实的细节。如果检索阶段未能覆盖问题所需的一切信息，LLM可能填补空白而造成谬误。此外，模型有时会过度依赖检索内容，导致最终回答几乎是拼接或复述检索片段的合集，缺乏应有的总结和推理。在多段内容提供时，如何让模型合理取舍不同来源的信息、统一表述风格，也是朴素RAG没有处理的挑战。对于企业而言，一个经常遇到的问题是：模型的回答需要既充分依据资料又有专业语气，而朴素RAG常常难以平衡这两点。

上述问题在一般场景可能只是影响准确率和用户体验，但在企业应用中，其影响被显著放大。企业知识库具有规模大、类型复杂、更新频繁等特点，朴素RAG的不足会带来一系列深层次挑战，促使我们思考架构演进的必要性：

知识源异构化： 企业知识不仅包括非结构化文本，还可能涉及数据库记录、表格、图谱乃至多媒体内容。朴素RAG单一路径的文本向量检索无法覆盖所有类型的数据需求。随着企业希望整合结构化数据（如利用知识图谱查询关系）以及半结构化数据（如表格、日志）的能力，RAG架构需要变得更加开放和多样，能够融合异构数据源提供答案。

系统透明度与可控性： 在企业环境下，结果可解释和过程可控非常重要。朴素RAG把检索和生成黑箱式串联，出了问题难以追踪原因，也无法对某一步进行干预。随着应用升级，企业希望对QA系统拥有更精细的控制——例如能够追溯每条答案引用了哪些文档，对不可信的来源进行屏蔽，或者根据场景设定不同的回答策略。这要求RAG架构具备模块可插拔和可监控的属性，方便运维人员调试和治理。

持续优化与维护成本： 朴素RAG虽然简单，但当知识库和模型不断演进时，缺少模块化设计会让维护变得困难。企业知识每周甚至每天都在更新，如何快速地将新知识纳入检索？如果想替换更优的检索算法或语言模型，缺乏清晰的模块边界会导致牵一发动全身。为降低长期成本，RAG系统需要易于扩展升级，各部分解耦以便独立优化。这种需求也推动架构从固定流程走向模块化分层，让系统具备演进的弹性。

综合来看，朴素RAG的局限本质上反映了：当知识检索与生成流程变得更复杂多变时，原有线性单块架构难以满足准确性、效率和可控性的综合要求。这成为推动RAG从Naive模式走向高级乃至模块化范式的根本动因。企业希望他们的知识问答系统既能像朴素RAG那样方便使用外部知识，又能克服其在复杂环境下的不足，于是研究者和架构师们开始寻求一种更加结构化、可管可控的解决方案——这正是模块化RAG诞生的背景。