构建适用于生产环境的高性能RAG应用
构建一个RAG应用程序的原型很容易，但要使其性能优异、健壮且能够扩展到大型知识库则很困难。
本指南包含各种提升RAG工作流性能的技巧与诀窍。我们首先概述一些通用技术——这些技术大致按照从最直接到最具挑战性的顺序排列。 随后我们将更深入地探讨每项技术、其适用的使用场景，以及如何通过LlamaIndex实现它！
最终目标是优化您的检索和生成性能，以便能够准确回答更复杂数据集上的更多查询，且不产生幻觉。
以下是构建生产级RAG的一些关键考量因素
- 用于检索的块与用于合成的块之间的解耦
- 针对大型文档集的结构化检索
- 根据任务动态检索数据块
- 优化上下文嵌入
我们在生产级RAG网络研讨会中讨论了这一点以及更多内容。 查看这条推文串获取更多综合详情。
用于检索的文本块与用于合成的文本块解耦
Section titled “Decoupling Chunks Used for Retrieval vs. Chunks Used for Synthesis”提升检索效果的一个关键技术是将用于检索的文本块与用于合成的文本块分离开来。
用于检索的最佳文本块表示可能与用于合成的最佳考量有所不同。 例如，原始文本块可能包含LLM根据查询合成更详细答案所需的细节。然而， 它可能包含会影响嵌入表示的无用词/信息，或者可能缺乏全局上下文， 导致相关查询出现时完全无法被检索到。
利用这一理念主要有两种方式：
1. 嵌入文档摘要，该摘要链接到与文档相关的片段。
这有助于在检索文档块之前先进行高层次的相关文档检索，而不是直接检索可能位于无关文档中的文档块。
资源：
2. 嵌入一个句子，然后链接到该句子周围的窗口。
这允许更细粒度地检索相关上下文（嵌入大块内容会导致“迷失在中间”问题），同时确保为LLM合成提供足够的上下文。
资源：
标准 RAG 堆栈（top-k 检索 + 基础文本分割）的一个主要问题是，随着文档数量增加时表现不佳 - 例如当您拥有 100 个不同的 PDF 文件时。 在这种情况下，针对特定查询您可能需要利用结构化信息来实现更精准的检索；举例来说，如果某个问题仅与两个 PDF 文件相关， 通过结构化信息确保这两个 PDF 能够被检索出来，而不仅仅是依赖文本块的原始嵌入相似度。
有几种方法可以为生产质量的RAG系统执行更结构化的标记/检索，每种方法都有其自身的优缺点。
1. 元数据过滤器 + 自动检索 为每个文档添加元数据标签并存储至向量数据库。在推理阶段，使用大语言模型推断正确的元数据过滤器，结合语义查询字符串来查询向量数据库。
- 优点 ✅: 在主流向量数据库中受支持。可通过多维度筛选文档。
- 缺点 🚫：可能难以定义正确的标签。标签可能不包含足够的相关信息以进行更精确的检索。此外，标签代表文档级别的关键词搜索，不允许进行语义查找。
资源： 2. 存储文档层级结构（摘要 -> 原始块） + 递归检索 嵌入文档摘要并映射到每个文档的块。首先在文档级别获取，然后在块级别获取。
- 优点 ✅: 允许在文档级别进行语义查找。
- 缺点 🚫：不允许通过结构化标签进行关键词查找（可能比语义搜索更精确）。此外，自动生成摘要可能成本较高。
资源
RAG 不仅仅是针对特定事实的问答，而 top-k 相似度正是为此优化的。用户可能提出的查询范围非常广泛。朴素 RAG 栈处理的查询包括询问具体事实的问题，例如“告诉我该公司在 2023 年的多元化与包容性举措”或“叙述者在谷歌工作期间做了什么”。但查询也可能包括摘要任务，例如“你能给我这份文档的高层概述吗”，或者比较任务“你能比较/对比 X 和 Y 吗”。所有这些用例可能需要不同的检索技术。
LlamaIndex 提供了一些核心抽象来帮助您执行特定任务的检索。这包括我们的路由器模块以及我们的数据智能体模块。 这还包括一些高级查询引擎模块。 这还包括其他结合结构化和非结构化数据的模块。
您可以使用这些模块进行联合问答和摘要生成，甚至可以将结构化查询与非结构化查询相结合。
核心模块资源
详细指南资源
这与上文“用于检索与合成的块解耦”中描述的动机相关。 我们希望确保嵌入向量针对在您的特定数据语料库上实现更优检索而进行优化。 预训练模型可能无法捕捉与您的用例相关的数据显著特性。
除了上述列出的一些技术外，我们还可以尝试微调嵌入模型。 实际上，我们可以在无标签的方式下，对非结构化文本语料库进行这种操作。
请在此处查看我们的指南：