构建基本的 RAG (Retrieval-Augmented Generation，检索增强生成) 流水线仅仅是开始。为了在规模化应用中提供准确、可信赖且响应迅速的答案，我们需要更先进的技术。本文将深入探讨 RAG 系统的优化、评估和部署，这些都是将优秀系统打造成卓越系统的关键。我们将着重介绍查询增强、元数据过滤、重排序等优化技术，组件级和端到端评估策略，以及延迟与准确性的权衡、缓存策略等部署技巧，最终构建高性能的 RAG 应用。
优化：提升检索质量是关键
高效的 RAG 系统依赖于精密的检索优化，以确保生成模型能够获得最相关的信息。检索过程的质量直接决定了后续生成结果的准确性。以下介绍几种关键的优化技术，包括利用 HyDE 进行查询增强、元数据过滤和重排序，它们能够显著提升检索上下文的质量。
查询增强：HyDE (Hypothetical Document Embedding) 的应用
用户查询往往存在模糊或简短的问题，这可能导致检索结果不佳。查询增强 旨在通过修改或扩展用户查询，来提供更多上下文或澄清信息。HyDE（Hypothetical Document Embedding，假设文档嵌入）是一种有效的查询增强技术。
HyDE 的核心思想并非直接嵌入用户查询并寻找相似的文档，而是先利用大型语言模型 (LLM) 根据用户查询生成一个假设性的答案。这个假设性答案通常包含更丰富的语义信息和上下文，从而能更好地检索到相关的文档。例如，当用户查询“最新的人工智能研究进展”时，HyDE 会先生成一个关于人工智能最新进展的假设性文档，然后基于该文档的嵌入向量进行检索。
相比传统的检索方法，HyDE 的优势在于能够捕捉查询背后的深层含义，特别是对于零样本场景，效果更为显著。但需要注意的是，如果 LLM 生成的假设性答案不准确，可能会导致检索到不相关的文档。因此，在使用 HyDE 时，需要针对特定的用例和数据集，仔细调整 LLM 的指令，并通过测试数据集评估生成答案的质量。
元数据过滤：精准检索的利器
元数据过滤 允许我们根据文档的结构化信息（如发布日期、作者、类别、来源等）进行更精确和高效的搜索。例如，在一个法律文档搜索系统中，我们可以使用元数据过滤来筛选出特定年份、特定法庭的判决书。
有效的元数据过滤需要从用户查询中提取相关的元数据。我们可以利用 LLM 来解析自然语言查询，并识别出相关的元数据字段，并将其输出为结构化的 JSON 格式。例如，给定查询 “2023年谷歌的收入是多少？” 和元数据字段 {“company”, “year”}，LLM 可以提取出 {“company”: “Google”, “year”: 2023}。
在向量搜索系统中，有三种主要的元数据过滤策略：
- 预过滤 (Pre-Filtering)：在向量相似度搜索之前应用元数据条件。系统首先过滤知识库中的文档，得到一个满足特定元数据条件的子集，然后从该子集中检索 top-K 个文档。预过滤能够提高结果的相关性，但当数据集非常大时，进行过滤后的暴力搜索会比较慢。例如，用户查询“2023年发表的关于可再生能源的文章”，系统首先会过滤出2023年发表的文档，然后在这些文档中进行向量搜索。
- 后过滤 (Post-Filtering)：在进行向量搜索之后应用元数据约束。系统首先检索出 top-K 个最相似的文档，然后根据元数据标准过滤这些文档。后过滤速度比预过滤快，但可能会返回少于 top-K 个文档，甚至没有文档。为了避免这种情况，需要增加 top-K 的数量，但这也会降低搜索速度。例如，用户搜索“人工智能的进展”，系统检索出top 100 个最相似的文档，然后过滤出在同行评审期刊上发表的文档。
- 单阶段过滤 (Single-Phase Filtering)：将元数据约束直接集成到向量搜索过程中。这种方法可以同时考虑向量相似度和元数据条件，通常能够实现更高效和准确的检索。例如，用户查询“欧洲最近的气候变化影响研究”，系统会同时考虑查询的语义相似性，并过滤出标记为“欧洲”地区且发布日期在过去两年的文档。
重排序 (Reranking)：精益求精
在初始检索阶段后，系统会得到一组与查询大致相关的文档。重排序 阶段旨在优化这些文档的排序，优先考虑与用户查询最相关的文档。这也有助于过滤掉不相关的文档，确保 LLM 接收到最佳的上下文，以便生成最佳的响应。
在 RAG 流水线中，使用深度学习技术进行重排序已经变得越来越流行。其中，交叉编码器 (cross-encoder) 是一种广泛采用的架构。与双编码器模型 (bi-encoder) (例如嵌入模型) 不同，交叉编码器在一个单独的神经网络中联合处理用户查询和检索到的文档对，直接预测它们的相关性分数。交叉编码器能够利用查询和文档之间更丰富的 token 级别交互，从而实现更准确的排序。
尽管交叉编码器具有更高的准确性，但由于其成对处理方法，计算速度往往比双编码器慢。相比之下，双编码器的速度更快，因为可以预先计算并存储嵌入，使其成为快速、大规模检索的理想选择。
一种有效的策略是将这两种方法结合起来，首先使用双编码器进行快速检索，然后使用交叉编码器进行重排序，从而在性能和效率之间取得平衡，尤其是在处理大型和多样化的知识库时。
评估：确保 RAG 系统的可靠性
评估对于确保 RAG 系统的各个组件（检索器和生成器）都能良好运行至关重要。全面的评估包括：
- 检索器质量：它是否能可靠地获取准确、相关的信息？
- 生成器质量：在给定相关上下文的情况下，它是否能产生正确且连贯的答案？
- 端到端有效性：最终答案是否准确、相关并忠实于其来源？
组件级别评估
分别评估各个组件有助于识别问题所在，从而进行有针对性的改进。
- 检索器评估：检索器的职责是获取相关的文档，可以把它看作是系统的记忆。它不需要理解问题，只需要提供正确的“事实”。例如，如果有人问“谁赢得了2022年世界杯？”，检索器应该返回提及“阿根廷”和/或“2022年决赛”的文档。评估指标包括召回率 (Recall@K) 和平均倒数排名 (MRR)。
- 生成器评估：独立评估生成器 (LLM) 可以揭示其在给定正确上下文时生成准确答案的能力。一个测试方法是：为生成器提供完美的输入 (例如，手动选择的段落)，然后观察它的响应效果。可以使用 BLEU、ROUGE、BERTScore 或 Exact Match / F1 等自动指标将答案与参考答案进行比较。还可以让人工或模型来验证答案的正确性和连贯性。
如果生成器在使用理想上下文时表现良好，但在使用实际检索到的文档时表现不佳，则可能需要改进检索器。相反，即使使用完美的上下文，结果仍然很差，则表明生成器或其提示结构存在问题。
端到端评估
最终，需要将整个查询-检索器-生成器流水线作为一个整体进行评估。端到端评估需要考虑多个维度，并衡量最终答案是否有帮助、准确以及是否以来源为依据。
端到端评估可以考虑这些维度的综合评分或仪表板。例如，TRIAD 框架强调上下文相关性 (检索质量)、忠实度和答案相关性，并将它们作为 RAG 评估的三大支柱。
在实践中，可以报告类似以下结果：“对于我们的测试集，答案相关性 = 0.85，忠实度 = 0.92，流畅度 = 5/5 (人工评估)”，从而获得一个整体的评估。
值得注意的是，人工评估对于端到端质量通常是不可或缺的。人工可以发现自动化指标遗漏的细微问题。例如，人工可以判断答案即使有上下文支持，仍然不完整或对用户没有实际用处。因此，许多团队会结合使用自动化指标和定期人工审核 (专家或众包工作者) 来评估答案的正确性、有用性和清晰度等标准。
由于人工评估的成本很高，因此通常只在部分输出上进行，或者用于验证自动化指标。对于关键领域，强烈建议在部署重大更改之前进行人工评估。
LLM 作为裁判 (LLM-as-a-Judge)
一种越来越流行的 RAG 输出评估方法是使用大型语言模型作为评估者，即“LLM 作为裁判”。这种方法解决了传统指标 (如 BLEU 或 ROUGE) 的局限性，以及人工评估的高成本问题。通过提示 LLM (通常是与生成模型相同或更强大的模型) 来评估答案的质量。
这种方法包括：
- 直接评分：要求模型对答案的相关性、事实性或流畅度进行评分。
- 成对比较：LLM 选择对同一问题的两个答案中较好的一个，从而实现 A/B 测试。
这些评估是无参考的、可扩展的且一致的，使其成为持续监控的理想选择。尽管 LLM 裁判可以在规模上复制人类推理，但它们并非完美，应与偶尔的人工审核结合使用。将信息检索指标 (如召回率和精确率) 与基于 LLM 的评估器相结合，可以为评估大多数实际场景中的 RAG 性能提供强大而平衡的方式。
实用工具和技术
已经出现了一些开源工具，可以帮助轻松地实现上述评估策略，例如 RAGAS、TruLens、ELI5 等。这些工具包实现了带有反馈功能的评估技术，例如使用 LLM 检查答案相关性或忠实度，并以编程方式记录分数。RAGAS (Retrieval-Augmented Generation Assessment Schema) 是一个专门的评估工具包，旨在评估 RAG 流水线的完整性能，包括生成的文本质量，以及检索到的上下文对输出的贡献程度。
RAGAS 通过结合四个核心指标来提供更全面的评估：上下文精确度、上下文召回率、忠实度和答案相关性。这些指标共同作用，可以诊断性能问题是源于检索、生成还是它们的交互方式。
RAGAS 的优势之一在于其对开发人员的简单性：它抽象出了复杂的操作，例如声明分解和基于 LLM 的上下文相关性评分。因此，团队可以轻松地将其集成到工作流程中，而无需从头开始构建自定义评估器。除了静态评估之外，RAGAS 还支持受 Evol-Instruct 启发的合成测试生成，从而无需人工干预即可创建复杂、多样且真实的查询集。它甚至允许进行聊天式评估，使其非常适合对话代理。
RAGAS 还包括用于生产监控的工具，可帮助团队持续跟踪指标随时间变化的趋势。这支持指标驱动的开发 (MDD) 循环，包括测试、测量、调整和重新部署功能，从而可以系统地改进 RAG 系统。
部署：优化性能和用户体验
在生产环境中部署 RAG 流水线涉及到实际的考虑，而不仅仅是初始设置。关键的部署问题包括平衡延迟与准确性、实施高效的缓存策略以及选择适当规模的模型和嵌入。
延迟与准确性权衡
部署 RAG 系统总是需要在响应准确性和系统延迟之间进行权衡。用户期望获得准确的答案，但过长的响应时间会给用户体验带来负面影响。
关键考虑因素包括：
- 模型大小：较大的模型通常提供更高的准确性，但代价是增加延迟。需要对各种模型大小进行基准测试，并选择在准确性提升和可接受的响应时间之间提供最佳平衡的模型。
- 重排序成本：重排序器可以显著提高相关性，但会增加延迟。考虑仅在需要时应用重排序器。如果需要，默认应用轻量级重排序器，仅在用例非常复杂时才应用更重的模型。
- 批处理和并行性：使用批处理进行检索和生成，以便同时处理多个请求，从而在不显著增加延迟的情况下提高吞吐量。
- 流式响应：逐步向用户流式传输生成的 token，从而减少感知到的延迟，即使总处理时间保持不变。
应该始终定义明确的延迟目标 (例如，90% 的查询在 3-4 秒内获得响应)，然后进行相应的监控和优化，并始终使用真实的用户查询进行测试。
缓存策略
有效的缓存可以显著减少冗余计算，并提高整体系统性能。常见的缓存层包括：
- 嵌入缓存：存储经常出现的查询的嵌入，以避免重新计算向量表示。
- 检索结果缓存：缓存常见查询的 top-K 个检索结果，以便在重复查询发生时直接从缓存中检索。
- 生成答案缓存：对于具有确定性答案的静态查询 (例如，历史事实)，直接缓存最终生成的答案。
采用可靠的缓存失效策略，以确保数据的时效性，特别是在知识库更新后。可以使用 Redis 或具有适当驱逐策略 (例如，最近最少使用 LRU) 的内存缓存等工具来有效地管理效率。
选择合适的嵌入和模型规模
为嵌入和语言模型选择合适的规模对部署效率有很大影响：
- 嵌入维度：较小的嵌入 (例如，384 维) 速度更快、成本更低，但可能缺乏细微差别。较大的嵌入 (例如，768 或 1024 维) 可以捕获更丰富的语义，但计算成本更高。根据检索准确性对嵌入维度进行实证测试，以找到最佳平衡。
- 嵌入模型：选择与你的领域对齐的嵌入 (通用 vs. 领域特定)，以提高检索性能，而不会增加延迟。
- 语言模型大小：部署能够实现令人满意的性能的最小 LLM。通常，微调中等大小的模型比使用大型通用模型表现更好。密切关注有关多语言和多模态技能的基准测试。
还应定期重新评估模型选择，因为新技术可能会以更低的成本提供更好的准确性。
通过周到地管理延迟、利用智能缓存以及仔细选择模型规模，部署的 RAG 系统可以高效地提供准确、及时的响应，从而提供卓越的用户体验。
超越静态上下文：MCP (Model Context Protocol)
模型上下文协议 (MCP) 是 Anthropic 在 2024 年推出的一项新的开放标准，用于将结构化的外部上下文输入到语言模型中。MCP 通常被描述为“AI 的 USB-C”，它用一致的、类似 JSON 的模式取代了随意注入原始文本的做法。它在 RAG 系统中迅速受到欢迎，因为它能够清晰、可靠地集成检索到的知识、参考资料甚至工具，从而使流水线更模块化、可解释和可互操作。
MCP 的核心遵循客户端-服务器架构。主机应用程序充当 MCP 客户端的编排器，并与多个 MCP 服务器通信，每个服务器都以标准化格式公开特定的功能或数据源。这些服务器可以访问本地数据 (例如，文件、数据库) 或外部 API，并将结构化的结果发送回主机。这种模块化设置使得可以安全、一致地集成各种上下文源变得容易。
MCP 的一个关键优势在于它使用了结构化的上下文块，其中每个检索到的文档都表示为一个具有以下字段的对象：
content：文本段落。例如：“黎巴嫩是世界上最古老的国家之一，拥有超过 5000 年的文字记录历史。”source：唯一的文档 ID 或 URL。例如：“lebanon_history.pdf”relevance_score：可选的排名分数。例如：0.961metadata：其他标签，如作者、主题或日期。例如：{“category”: “history”, “pub_date”:”2025-06-05”}
不是将纯文本转储到提示中，而是将这些块作为列表传递，从而允许 LLM (通过系统提示或微调进行指导) 单独解释每个单元。这确保了提示的一致性，而与源的数量无关，并简化了提示工程：可以添加或删除字段 (例如，摘要、时间戳)，而不会破坏格式。
MCP 为 RAG 工作流带来了三个核心优势：
- 可解释性：上下文是可追溯的，具有与来源和元数据的清晰链接，有助于调试和信任。
- 一致性：标准化的提示格式可以带来更可靠的模型行为，并减少提示工程开销。
- 灵活性：它支持复杂的设置，如多跳检索、多代理流水线和工具增强的查询。
在以下情况下应考虑使用 MCP：
- 集成来自多个来源或工具的上下文。
- 构建多步骤或基于代理的 RAG 工作流。
- 需要在生成的输出中实现可审计性或可解释性。
MCP 的开放标准已经被主要参与者采用。Hugging Face 推出了关于 MCP 的学习资源和博客教程，而 LangChain 和 LlamaIndex 等框架正在集成它，以支持结构化的工具使用和检索。
简而言之，MCP 正在迅速成为下一代 RAG 系统的支柱，为模型使用外部上下文的方式带来秩序、清晰度和可扩展性。
总结
在本文中，我们探讨了构建和维护高效 RAG 系统的最佳实践。我们从优化技术开始，这些技术可以提高检索质量和答案相关性。假设文档嵌入 (HyDE) 允许系统生成伪答案，从而实现更好的语义搜索，而元数据过滤使用结构化标签 (如日期、主题或作者) 缩小搜索范围。我们还讨论了重排序方法，特别是交叉编码器，它可以优化检索到的文档的初始集合，以优先考虑最相关的文档。
接下来，我们介绍了评估策略，以确保系统可靠地运行。至关重要的是，要分别和一起评估检索器和生成器。对于检索器，召回率 @K 和 MRR 等指标有助于评估是否获取了正确的文档。对于生成器，ROUGE 或基于事实的评分等指标可以确定模型基于上下文的回答效果如何。RAGAS 和人工审核或 LLM 作为裁判等工具可以对实际性能进行更细致的端到端评估。
成功的 RAG 系统需要在延迟和准确性之间取得平衡。较小的模型速度更快，但可能会牺牲一些质量，而重排序器可以提高结果，但会降低速度。此外，缓存频繁出现的查询、嵌入或最终答案可以大大提高响应能力。为嵌入和生成任务选择正确的模型规模有助于在资源限制内保持性能。
最后，我们介绍了模型上下文协议 (MCP)，这是一种将检索到的信息传递给 LLM 的结构化方式，有助于确保响应的清晰性、灵活性和一致性。
总而言之，这些实践为在生产环境中构建可扩展、可靠和高性能的 RAG 应用程序奠定了坚实的基础。现在可以构建高级 RAG 流水线了。