大规模RAG实施蓝图

RAG对于大型语言模型应用至关重要，它通过检索相关信息并传递给LLM来提高准确性和减少幻觉。大规模RAG面临扩展挑战，需要关注可搜索单元定义、检索策略选择、排序策略定义以及多个用例的影响，AI搜索平台需支持自动分块、高查询量处理和灵活的索引管道。

译自：A Blueprint for Implementing RAG at Scale^[1]

作者：Kai Borgen

检索增强生成（RAG）^[2]对于大多数大型语言模型（LLM）^[3]应用至关重要，因为它将公司特定的信息带入生成过程中。如果您计划在您的组织中部署生成式AI^[4]，您几乎肯定需要RAG。如果做得好，它可以提高准确性，减少幻觉，并让LLM基于您自己的专有数据进行推理。这个概念听起来很简单：找到与用户查询相关的信息，并将其传递给LLM，以便它可以生成更好的答案。但与往常一样，细节决定成败。

生成式AI的兴起，尤其是Agentic AI^[5]，正在推动RAG进入更苛刻的企业用例，大型组织面临着严峻的扩展挑战。大规模的RAG意味着在海量、多样化的数据集上进行机器速度的检索，以及检索和生成之间快速、高效的协调。随着数据量的增长，保持结果的相关性、新鲜性和速度变得越来越困难（而且成本高昂）。当您同时为大量用户提供服务，或支持需要执行深度、多步骤研究的多轮代理交互时，更是如此。

解决相关性问题

当您拥有数百万（如果不是数十亿）个文档，并且需要在十分之一秒内为数千（如果不是数百万）个用户提供服务时，您究竟该如何找到最相关的信息？这个任务可以通过逐步细化来简化：

步骤 1：定义您的可搜索单元

您的可搜索单元（通常称为“块”）在RAG中至关重要。它是您将传递给LLM的信息单元。您将搜索这些单元，以找到提供给LLM的最佳信息。正确地进行设置会影响检索准确性、延迟以及最终的LLM响应质量。

这不仅仅是关于token限制；而是关于使块的大小和结构与用户将提出的问题类型对齐。例如，事实层面的查询可能受益于更小、更精确的块，而更广泛的或基于推理的查询可能需要更长的文本跨度来保持上下文。块应尊重语义边界，如段落或列表项，并且重叠的窗口可以帮助维持跨中断的连续性。添加元数据（如来源、章节、日期）也有助于在管道中进行更好的过滤和排序。没有一刀切的规则——有效的分块取决于您的内容、查询模式和规模——因此请将其视为值得测试和调整的设计决策。

步骤 2：选择您的检索策略

您的检索策略决定了您如何找到相关的块来传递给LLM。它是使RAG工作的核心。您应该使用语义、关键词还是混合方法来找到最佳的文档或块？哪种嵌入模型适合您的领域？这些决策决定了您的系统理解和呈现相关信息的方式。

语义检索（使用向量嵌入）擅长捕捉意义，但当精确的术语或领域特定的短语很重要时，像BM25（最佳匹配25）这样的关键词方法可以在精度上胜过语义检索。混合搜索——结合两者——通常可以提供两全其美的效果。您选择的嵌入模型也很重要：轻量级模型速度更快，但可能会丢失细微差别，而更大的模型提供更丰富的语义，但成本和延迟更高。检索不仅仅是找到相关内容——而是以您的应用程序要求的速度和规模这样做。平衡准确性、吞吐量和成本是关键，尤其是当您的用户（或代理）依赖于跨数十亿文档的快速、可靠的答案时。

步骤 3：定义您的排序策略

排序决定了哪些检索到的块被传递给LLM以及以什么顺序传递。这是您在模型开始生成之前提高相关性的第二次机会。一个像样的RAG解决方案将检索许多可能有用的文档，但并非所有文档都应该显示给LLM。为了做出这个决定，您需要一种方法来组合不同的评分信号：关键词匹配、语义相似度、元数据过滤器等等。弄清楚如何手动权衡这些信号几乎是不可能的，尤其是在大规模的情况下。这就是为什么大多数生产就绪的RAG系统使用机器学习排序来根据真实用户行为或反馈优化质量。多阶段排序管道可以通过连续的过滤器和评分器来优化结果，但即使是一个简单的学习模型也可以显著改善哪些内容进入提示以及LLM的响应效果。

步骤 4：解决多个用例的影响

RAG系统很少只服务于一种类型的用户或工作流程。一些查询来自需要快速、可读答案的人类用户；另一些查询来自AI代理或编排层，它们可以容忍更多的延迟，以换取更深入、更上下文丰富的结果。Agentic 检索——其中LLM自主执行搜索——具有与人工搜索不同的特征。LLM可以处理更多的上下文，不介意较慢的响应，并且可以按顺序发出许多查询来解决单个任务。设计一个从同一后端为人类和机器提供服务的系统需要在延迟、排序深度和检索量方面进行权衡。关键是要认识到并非所有查询——或用户——都是相同的，并且您的架构应该足够灵活，以便根据调用的用例进行调整。

AI搜索平台支持

为了支持大规模的复杂RAG工作负载，AI搜索平台必须做的远不止基本的关键词或向量匹配。它需要智能地处理海量的、不断增长的文档语料库，包括无法批量传递给LLM的非常大的或非结构化的文档。这意味着支持自动分块，将大型文档分解为有意义的、可检索的单元，并对这些块以及整个文档进行排序，以确保仅返回最相关的内容。

该平台还必须水平扩展以处理高查询量，即使在负载下也能支持低延迟检索，并允许频繁更新内容和排序逻辑，而无需重新索引整个数据集。索引管道应该足够灵活，可以集成元数据、嵌入和自定义特征，并且速度足够快，以最小的延迟保持系统的新鲜度。

最终，该平台必须在性能、准确性和适应性之间取得谨慎的平衡，以便它可以从同一基础设施为实时、面向用户的体验和复杂的agentic工作流程提供服务。

Vespa创建了RAG蓝图^[6]，这是基于我们从大规模部署RAG中学到的经验。它以免费的Python notebook和示例应用程序的形式提供，更深入地介绍了这些要点的实现，提供了一个动手、模块化的配方，涵盖了关键的设计决策——如分块、检索、机器学习排序和性能调整——这些决策都基于真实的经验。无论您是刚开始还是正在优化现有的系统，该蓝图都为构建生产就绪、可扩展的RAG应用程序提供了坚实的基础。