RAG 应用的原型构建很简单，但要使其具备高性能、稳健性并能够扩展到大型知识库则很困难。
本指南包含多种技巧和窍门，可帮助您提升 RAG 工作流的性能。我们首先概述一些通用技术——它们大致按照从最简单到最具挑战性的顺序排列。然后，我们将更深入地探讨每种技术、它解决的用例以及如何使用 LlamaIndex 来实现它！
最终目标是优化您的检索和生成性能，以便在更复杂的数据集上准确、无幻觉地回答更多查询。
构建生产级 RAG 的通用技术#
以下是构建生产级 RAG 的一些重要考量
解耦用于检索的块与用于合成的块
- 优化上下文嵌入
- 针对大型文档集的结构化检索
- 根据任务动态检索块
- 我们在生产级 RAG 网络研讨会中讨论了这些以及更多内容。查看此推文串以获取更多综合细节。
解耦用于检索的块与用于合成的块#
提升检索效果的一项关键技术是解耦用于检索的块与用于合成的块。
动机#
用于检索的最佳块表示形式可能与用于合成的最佳考量不同。例如，一个原始文本块可能包含 LLM 根据查询合成更详细答案所需的细节。然而，它可能包含填充词/信息，从而偏离嵌入表示，或者缺乏全局上下文，在相关查询到来时完全不会被检索到。
关键技术#
利用这一思路主要有两种方式：
1. 嵌入文档摘要，并将其链接到与该文档相关的块。
这有助于在检索块之前在高层级检索相关文档，而不是直接检索块（这些块可能来自不相关的文档）。
资源
表格递归检索
这允许更细粒度地检索相关上下文（嵌入巨大的块会导致“中间丢失”问题），同时也确保有足够的上下文用于 LLM 合成。
元数据替换后处理器
表格递归检索
动机#
标准 RAG 栈（top-k 检索 + 基本文本拆分）的一个大问题是，随着文档数量的增加（例如，如果您有 100 个不同的 PDF 文件），其表现不佳。在这种情况下，给定一个查询，您可能希望使用结构化信息来帮助进行更精确的检索；例如，如果您询问一个仅与两个 PDF 文件相关的问题，可以使用结构化信息来确保返回这两个 PDF 文件，而不仅仅是与块的原始嵌入相似性。
关键技术#
对于生产级 RAG 系统，有几种方法可以执行更结构化的标记/检索，每种方法都有其优缺点。
1. 元数据过滤器 + 自动检索 为每个文档添加元数据标签，然后存储在向量数据库中。在推理时，除了语义查询字符串外，使用 LLM 推断正确的元数据过滤器来查询向量数据库。
优点 ✅：主流向量数据库支持。可以通过多个维度过滤文档。
- 缺点 🚫：难以定义正确的标签。标签可能不包含足够的关联信息用于更精确的检索。此外，标签代表文档层级的关键词搜索，不支持语义查找。
- 资源：2. 存储文档层级结构（摘要 -> 原始块） + 递归检索 嵌入文档摘要，并映射到每个文档的块。首先在文档层级获取，然后再到块层级。
优点 ✅：允许在文档层级进行语义查找。
- 缺点 🚫：不支持通过结构化标签进行关键词查找（语义搜索可以更精确）。此外，自动生成摘要可能很昂贵。
- Chroma 自动检索
表格递归检索
动机#
RAG 不仅仅是针对特定事实的问答，而 top-k 相似度对此进行了优化。用户可能会提出范围广泛的查询。朴素 RAG 栈处理的查询包括询问特定事实的查询，例如“告诉我这家公司 2023 年的多元化和包容性（D&I）倡议”或“叙述者在 Google 期间做了什么”。但查询也可能包括总结，例如“你能否给我这份文档的高级概述”，或者比较，“你能否比较/对比 X 和 Y”。所有这些用例可能需要不同的检索技术。
关键技术#
LlamaIndex 提供了一些核心抽象，可帮助您执行针对特定任务的检索。这包括我们的 router 模块以及我们的 data agent 模块。这也包括一些高级查询引擎模块。此外还包括连接结构化和非结构化数据的其他模块。
您可以使用这些模块进行联合问答和总结，甚至可以将结构化查询与非结构化查询相结合。
核心模块资源
详细指南资源
子问题查询引擎
动机#
这与上面“解耦用于检索的块与用于合成的块”中描述的动机相关。我们希望确保嵌入针对您的特定数据语料库进行了优化，以实现更好的检索。预训练模型可能无法捕捉与您的用例相关的数据的显著特性。
关键技术#
除了上面列出的一些技术外，我们还可以尝试微调嵌入模型。我们实际上可以在非结构化文本语料库上以无标签的方式进行此操作。
查看我们的指南：
嵌入微调指南
