摘要：在人工智能飞速发展的今天，大型语言模型（LLMs）的强大能力已无需赘言。但你可能也遇到过这样的困惑：为什么模型有时会“胡编乱造”，给出似是而非的答案？为什么在面对特定领域，比如公司内部文档、法律条文或医学报告时，模型的表现总是差强人意？
9 种 RAG 架构，助你打造真正“聪明”的 AI 应用
在人工智能飞速发展的今天，大型语言模型（LLMs）的强大能力已无需赘言。但你可能也遇到过这样的困惑：为什么模型有时会“胡编乱造”，给出似是而非的答案？为什么在面对特定领域，比如公司内部文档、法律条文或医学报告时，模型的表现总是差强人意？
答案可能不是需要一个更大的模型，而是需要一个更“聪明”的路径，来为模型提供它所需的“证据”。这个路径，就是我们今天的主题——检索增强生成（Retrieval-Augmented Generation, RAG）。
RAG 的核心思想，在于它不是让模型凭空生成答案，而是先从海量数据中检索出相关的“证据”片段，再将这些证据喂给模型，让它基于事实进行回答。正如原文所说，RAG 的成败，完全取决于你“获取了什么”以及“如何将其组织到提示词中”。
今天，我们将深入探讨 9 种不同类型的 RAG 架构，它们就像一个工具箱，每一种都针对特定的数据类型、应用场景和性能要求而设计。读完这篇文章，你将能够像一个经验丰富的工程师一样，为你的项目选择最合适的 RAG 策略，从而显著提升你的 AI 应用的准确性、可靠性和实用性。
任何 RAG 之旅都应从最简单的“基准线”开始。向量-唯一基线 RAG是其中最基础的架构。
工作原理： 它的原理非常直观：将你的文档切分成小块，然后将每个小块都转换成一个“向量”（即一串数字，代表其语义信息）。所有这些向量都被存储在一个专门的向量索引中。当用户提出问题时，系统会计算问题的向量，并在索引中找到与问题向量最相似的几个文档块（通常是“Top-k”个），然后将这些文档块作为“证据”放入提示词中，交给大模型生成答案。
适用场景： 这种架构最适合处理文档较小、词汇中立、且对性能要求不高的场景。它是快速构建原型和测试想法的理想选择。
优势与局限：
优势： 简单、延迟最低、运行成本低廉。局限： 容易错过精确的术语、版本号和具体数字；当出现同义词时，检索效果可能会“漂移”。实战建议： 如果你刚开始尝试 RAG，就从这里起步。如果发现模型开始“幻觉”，或者引用来源总是“差一点点”，那么是时候考虑升级了。
如果说向量-唯一 RAG 是广撒网，那么**重排序 RAG（Rerank RAG）**就是在捕捞后，再进行一次精细的筛选。
工作原理： 它首先使用一个快速的检索器（比如向量或混合检索）来快速找到一批“候选”文档块，比如 50 个。然后，它会引入一个更“聪明”的交叉编码器（cross-encoder）。这个编码器会同时考虑用户的问题和每个候选文档块，对它们进行重新打分，并最终挑选出最相关的 5 到 10 个文档块，作为最终的“证据”喂给大模型。
适用场景： 这种架构特别适用于那些对准确性要求极高的场景，例如受监管行业的问答、客户支持等。在这些领域，“第一句话”的正确性至关重要。
优势与局限：
优势： 在不改变文档分块方式的前提下，能够显著提升答案质量；能有效减少无关的引用。局限： 会增加额外的延迟，通常每个重新排序 10 个文档块会增加约 10-40 毫秒的延迟，这需要在预算中进行考虑。实战建议： 选择一个轻量但智能的重排序器；可以批量处理输入；并限制每个文档块的长度。
仅仅依靠向量匹配有时是不够的。对于日志、代码、政策文件等包含大量精确令牌（如 ID、错误代码）的文档，**混合检索（Hybrid RAG）**提供了完美的解决方案。
工作原理： 它将两种不同的检索方法结合在一起：
词法检索（Lexical Search）：例如使用 BM25 算法，它擅长基于关键词的精确匹配。向量检索（Vector Search）：它擅长基于语义相似度的匹配。这两种检索结果会被以某种方式（如分值融合或倒数排名融合）合并在一起，得到一个更全面、更精准的候选集。
适用场景： 特别适合处理那些既有精确令牌又有描述性文本的文档，例如：代码库、系统日志和复杂政策文档。
优势与局限：
优势： 能够恢复那些仅靠向量搜索容易错过的精确匹配；有效减少“差一点点”的错误答案。局限： 需要维护两个独立的索引；需要更多的调优工作。实战建议： 可以从简单的排名融合开始，而不是自定义权重。如果对精度有极高要求，可以在融合结果上再进行一次重排序。
有时，一个文档块的向量可能无法准确捕捉到其所有细微之处。多向量/晚期交互（Multi-Vector / Late-Interaction）RAG旨在解决这个问题。
工作原理： 它不像传统方式那样为整个文档块生成一个向量，而是为每个“令牌”（token）生成一个单独的向量。这种方法允许在令牌粒度上进行匹配，也被称为“晚期交互”。
适用场景： 非常适合处理那些包含大量密集技术文本的长篇文档，或者一个页面中包含多个意图的场景。
优势与局限：
优势： 在段落级别上实现了更高的召回率和准确性。局限： 索引会更大；需要专门的工具支持；占用更多内存。实战建议： 当标准向量检索总是能找到正确的页面，但却无法定位到正确的具体部分时，就应该考虑使用这种架构了。
对于那些结构清晰、层级分明的文档，如手册、规格说明书或法律文书，分层/树状（Hierarchical / Tree）RAG能提供一种优雅的解决方案。
工作原理： 这种架构的核心思想是在正确的粒度上进行检索。它首先会选择最佳的文档或章节，然后再从其中仅检索出最佳的子块。这种自上而下的方法，就像在一棵树上寻找信息一样。
适用场景： 特别适合处理手册、规格说明书和法律文件等具有清晰标题或目录结构的文档。
优势与局限：
优势： 有效减少令牌数量和噪音；能保持上下文的连贯性。局限： 需要更多的预处理工作；要求文档具有干净的标题或目录结构。实战建议： 可以利用文档的标题自动构建一个树形结构；将节点的嵌入独立存储；并使用“自上而下”的逐步细化方法进行检索。
在许多场景中，信息不仅仅是文本，它们之间存在着复杂的关系。例如，“谁和谁一起工作”、“供应链中的上下游”等。**图 RAG（Graph RAG）**就是为了处理这类问题而生。
工作原理： 它首先从你的文档库中构建一个知识图谱，其中包含了“实体”和它们之间的“关系”。然后，它利用图遍历算法来选择路径和相邻节点，并检索出支持这些关系和路径的原始文本段落。
适用场景： 适用于那些包含复杂关系信息的场景，例如：组织结构图、供应链关系、系统架构图或生物医学论文等。
优势与局限：
优势： 能够解释为什么一个段落是相关的；能处理“多跳”问题，即需要跨越多个信息点才能回答的问题。局限： 知识图谱的构建成本较高；需要进行实体识别和关系提取；运维更复杂。实战建议： 可以从一个轻量级的实体图开始，包含人、团队、系统、日期等基本实体。用图来约束检索范围，而不是完全取代它。
在企业应用中，数据往往不是一团混沌的文本，它们带有结构化的元数据，比如租户、产品、版本或司法管辖区等信息。**元数据感知/结构化 RAG（Metadata-Aware / Structured RAG）**就是将这些结构化信息与向量检索结合起来。
工作原理： 它将向量检索与元数据过滤相结合。或者，它可以将部分查询分派给SQL数据库，以获取事实性信息，然后再将这些信息与文本片段进行融合。
适用场景： 最适合那些具有严格行级约束、且事实性信息存储在表格中的企业应用。
优势与局限：
优势： 实现了确定性的范围限定，减少了数据泄露的风险；通过调用 SQL，答案能保持实时更新。局限： 查询规划变得更复杂；需要了解数据模式。实战建议： 可以先设计一个简单的路由：如果问题涉及数字或日期，先调用 SQL 数据库；否则，进行文本检索，然后再将结果合并。
有时，用户的问题本身就含糊不清或过于宽泛。查询重写与扩展（Query Rewrite & Expansion）RAG旨在通过“计划”问题来提高检索效果。
工作原理： 它将一个模糊的查询，转化为几个更精确的子查询，比如使用同义词、实体或时间范围。然后，对每个子查询都进行一次检索，最后对结果进行去重和重排序。
适用场景： 非常适合处理那些模棱两可或包含多个维度的查询，例如“比较不同地区的套餐限制”。
优势与局限：
优势： 在不增加检索数量（k）的情况下提高召回率；对用户不同的提问方式有更强的鲁棒性。局限： 会增加请求次数；必须进行去重，以避免重复的上下文。实战建议： 将重写次数限制在 3-4 次；强制要求来源多样性，以确保检索到不同文档或章节的内容。
对于那些追求极致完整性和准确性的任务，例如撰写长篇报告或深入研究报告，**反馈循环/迭代 RAG（Feedback-Loop / Iterative RAG）**提供了终极解决方案。
工作原理： 它首先生成一个草稿答案，然后从草稿中提取出缺失的事实，将其作为后续查询。系统会再次进行检索，并用新获取的信息来修正和完善答案。这就像一个“检索链”（Chain-of-Retrieval）。
适用场景： 最适合那些对答案完整性要求极高、且可以接受较高延迟的长篇回答和报告。
优势与局限：
优势： 最终准确性最高；能够捕获到答案中的矛盾之处。局限： 延迟会增加 2-3 倍；需要设置保护机制以避免无限循环。面对如此多的选择，如何快速做出决定？以下是一个简明的“决策树”：
场景推荐架构理由原型开发，普通文本向量-唯一基线 最快、最简单的基准线 受监管支持，精确答案重排序 RAG 质量提升显著，操作复杂性低 查询中包含日志/代码/ID混合（BM25+向量） 能够恢复精确的令牌匹配 长文档，混合意图多向量或分层 RAG 实现段落级别的精度 多跳“谁/为什么/哪里”问题图 RAG 图遍历能匹配推理过程 需要租户/版本限定的答案元数据/SQL RAG 确定性的范围限定 模糊或多维度问题查询重写（+重排序） 提高召回率，减少噪音 报告，深入研究迭代 RAG 优先考虑完整性而非单次延迟
检索器：内存中的检索器通常只需 5-15 毫秒，而远程检索器则需要 20-60 毫秒。重排序：对 50 个候选进行重排序，通常需要约 20-60 毫秒。大模型生成：这是总时间中占比最大的部分。通过使用分层细化和更少、更好的文档块，可以有效减少令牌数量，从而降低生成时间。图/SQL 查询：每次跳跃会增加 5-40 毫秒，但通常是值得的，因为它们可以有效地缩小搜索范围。在添加任何“巧妙”的架构之前，一定要先预算好端到端的总延迟。
有效的评估方法基础性（Groundedness）：引用的内容是否真的存在于原文中？归因多样性（Attribution diversity）：避免所有答案都只引用同一页的内容。与“黄金标准”的编辑距离：对于结构化问题，这是一种有效的评估方法。延迟 p95：不要只优化平均延迟（p50），而忽视了用户体验最差的延迟（p95）。基于用户任务的 A/B 测试：用户任务的成功率比纯粹的“答案相似度”指标更重要。原文作者给出了一个非常实用的“80/20”配方，它结合了混合检索和重排序的优点，通常能在不牺牲太多延迟的情况下，在大多数企业场景中胜过单纯的向量搜索。
分块：根据语义边界（如标题）将文档分块，每个块最大不超过 512-800 个令牌。索引：将这些文档块同时存储在BM25和向量索引中，并保留其元数据（如文档、章节、版本）。查询时：同时运行 BM25 检索（k=25）和向量检索（k=25）。使用排名融合将结果合并到 50 个唯一的候选文档块中。使用一个紧凑的交叉编码器对这 50 个候选进行重排序，最终选取最佳的 8 个。构建提示词：将这 8 个文档块，每个不超过 120 个令牌，并附带引用信息，一起组合成提示词。可选的优化：如果答案置信度较低，可以进行一次单步的迭代优化，针对缺失的实体再次进行检索。这种模式在大多数企业场景中，可以在不破坏延迟的情况下，显著提升纯向量搜索的性能。
RAG 不是一个单一的技术，而是一个庞大的“家族”。正确的选择取决于你的文档类型、你的用户需求，以及你对延迟的容忍度。
如果你感到无从下手，就从最简单的方式开始（向量-唯一），进行测量，然后逐步升级：混合 → 重排序 → 分层 → 图/SQL → 迭代。每一步都会通过更精心地选择“证据”，来为你赢得更高的准确性。
希望这篇指南能帮助你更好地理解和应用 RAG 技术，从而打造出真正“聪明”、可靠且实用的 AI 应用。
来源：高效码农
