泉州企业建站模板,电商网站开发环境怎么写,郑州大学科技园手机网站建设,典型的网站开发人员对 RAG 应用程序进行原型设计很容易#xff0c;但要使其高性能、健壮且可扩展到大型知识语料库却很困难。
本指南包含各种提示和技巧#xff0c;以提高 RAG 工作流程的性能。我们首先概述一些通用技术 - 它们按照简单到复杂的顺序进行排列。然后#xff0c;我们将更深入地研…对 RAG 应用程序进行原型设计很容易但要使其高性能、健壮且可扩展到大型知识语料库却很困难。
本指南包含各种提示和技巧以提高 RAG 工作流程的性能。我们首先概述一些通用技术 - 它们按照简单到复杂的顺序进行排列。然后我们将更深入地研究每种技术、该技术解决的用例以及如何使用 LlamaIndex 实现它
RAG 系统的终极目标是优化系统的检索和生成性能让 LLMs 能够准确回答来自更复杂的数据集的更多 query而不会产生幻觉。
构建生产级 RAG 系统的通用技术总结
以下是构建生产级 RAG 的一些主要注意事项
1️⃣ 用于检索的文本块不一定要与用于LLM生成的文本块相同
在信息检索阶段通常将文档分割成较小的文本块以提高检索的准确性和效率。然而在让 LLM 生成回答时可能需要更大的文本块来提供充分的上下文信息。因此针对检索和生成过程应采用不同的文本分块策略以优化各自的效果。
2️⃣ 嵌入应存在于不同的潜在空间中而不是直接使用原始文本的嵌入
原始文本可能包含无关的填充词或噪音直接对其进行 embedding 可能会引入偏差。为了获得更准确的文本表示可以考虑对文本进行预处理如去除停用词、提取关键信息或者对 embedding 模型进行微调以生成更有意义的 embedding 向量。
3️⃣ 如果检索未能返回正确的上下文可能需要动态加载或更新数据本身
当检索结果不理想时问题可能出在数据源本身过时或不完整。此时动态地加载新数据或更新现有数据可以改善检索效果确保LLM使用最新且相关的信息来生成回答。
4️⃣ 设计具有可扩展性的处理流程
原型阶段的系统延迟可能较高这在生产环境中是不可接受的。应从易于使用但延迟较高的模块开始逐步优化各个组件以降低延迟提升系统的性能和可扩展性满足生产级应用的需求。
5️⃣ 以层次化的方式存储数据
为每个文档存储摘要和具体的文本块可以构建一个层次化的数据结构。这种方法允许在需要快速概览时获取摘要信息而在需要深入细节时访问具体的文本块提高了数据检索和处理的效率。
6️⃣ 在生产环境中健壮的数据管道尤为重要尤其是当源数据不断变化时
如果数据仅需加载一次数据管道的稳定性影响较小。然而当源数据频繁更新时必须确保数据管道的可靠性和稳定性以防止数据不一致或系统故障。
7️⃣ RAG不仅适用于问答还可用于摘要等其他任务应根据用例调整文本块大小
在生成摘要时可能需要处理所有相关的文本块以涵盖完整的信息而在问答场景中只需检索特定的文本块即可。因此应根据具体的应用场景和需求调整文本块的大小和分割方式。
8️⃣ 基于嵌入的检索对实体查找效果不佳混合搜索可结合关键词查找的优势和额外的上下文
对于查找特定实体如人名、地名等精确匹配的需求纯粹依赖嵌入可能无法获得最佳结果。混合搜索方法将关键词匹配与嵌入检索相结合既利用了精确匹配的优势又提供了上下文信息从而提高了检索效果。
将用于检索的 chunk 与用于 synthesis 的 chunk 分离
更好地检索的关键技术是将用于检索的 chunk 与用于 synthesis 的 chunk 分离。 检索到的质量最好的 chunk 可能与最适合用于 synthesis 的 chunk 不同。例如原始文本块可能包含 LLM 给定查询的更详细答案所需的详细信息。但是它可能包含冗余的词或信息这可能会使 embedding 表示产生偏差或者它可能缺少全局上下文并且在相关查询出现时根本无法检索。
解决方案
1. 嵌入文档摘要该摘要链接到与文档关联的数据块。
这有助于在检索 chunk 之前整合更多相关的文档而不是直接检索 chunks可能在不相关的文档中。
相关资源Table Recursive Retrieval、Document Summary Index
2. 嵌入一个句子然后扩展到句子周围的内容。
这允许更细粒度地检索相关上下文embedding 巨大的 chunk 会导致 LLM“迷失在长文本中”但也确保了 LLM 能看到足够长的上下文。
相关资源Metadata Replacement Postprocessor
大型文档集的结构化检索 标准 RAG 流程top-k 检索 基础的文本拆分的一个大问题是随着文档数量的增加它表现不佳 - 如果您有 100 个不同的 PDF。在这种情况下中给定一个 query你可能希望使用结构化信息来帮助进行更精确的检索例如如果您提出一个仅与两个 PDF 相关的问题请使用结构化信息来确保返回的内容来自这两个 PDF。
解决方案
有几种方法可以为生产质量的 RAG 系统执行更结构化的标记和检索每种方法都有自己的优点/缺点。
1. 元数据过滤器 自动检索用元数据标记每个文档然后存储在向量数据库中。在推理期间使用 LLM 筛选符合条件的元数据然后再查询向量数据库。
✅ 优点 主流向量数据库支持。可以通过多个维度过滤文档。 缺点 可能很难定义正确的标签。标签可能不包含足够的相关信息无法进行更精确的检索。此外使用标签进行搜索主要基于关键词匹配无法理解词语的深层含义或上下文关系因此无法进行语义层面的查找。
2. 存储文档的层级结构摘要 - 原始文本块 递归检索 首先嵌入文档摘要并为每个文档建立一个摘要与分块的映射。在检索时先在文档级别找到相关内容然后再深入到更细的文本块层次。
✅ 优点 支持文档级别的语义查找通过摘要嵌入系统可以进行语义匹配而不仅仅依赖于关键词从而获得更有深度和关联的搜索结果。 缺点 无法通过结构化标签进行关键词查找关键词匹配有时能更精准地找到特定信息而语义查找较为泛化可能无法替代关键词的精确性自动生成摘要的成本较高要为大量文档生成和维护准确的摘要非常耗时、昂贵尤其在处理大型数据集时更为明显
根据任务动态检索数据块 RAG检索增强生成不仅适用于回答特定事实问题通常通过 top-k 相似度检索优化还广泛涵盖了多种查询需求。用户可能提出各种类型的问题例如关于具体事实的问答如“这家公司2023年的多元与包容计划是什么”或“叙述者在Google的经历是什么”还可能需要对整个文档进行总结如“能给我一个这篇文档的高层次概述吗”甚至进行比较如“你能对比X和Y吗”。这些不同的查询需求表明RAG应用不仅仅局限于事实问答而是扩展到了更多的检索和生成任务。构建 RAG 系统时为适应多样化的需求可能需要灵活配置不同的检索和生成方法以确保在各种场景下都能提供最佳的回答。
解决方案
LlamaIndex 提供了一些抽象的 core 来帮助完成基于特定任务的检索包括 router 模块以及 data agent 模块。这还包括一些高级查询引擎模块。这还包括链接结构化和非结构化数据的其他模块。你可以使用这些模块进行联合问答和总结甚至可以将结构化查询与非结构化查询相结合。
Core Module Resources
Query engineAgentsRouter
Detailed Guide Resources
Sub-Question Query EngineJoint QA-SummaryRecursive Retriever AgentsRouter Query EngineOpenAI Agent CookbookOpenAIAgent Query Planning
优化上下文嵌入
这与上面“Decoupling chunks used for retrieval vs. synthesis” 中描述的动机有关。我们希望确保 embedding 的内容经过优化以便更好地检索到正确数据语料。基于通用场景预训练的模型可能无法捕获实际应用案例中数据的显著特征。
解决方案
除了上面列出的一些技术之外我们还可以尝试微调 embedding 模型。我们可以使用无标签的非结构化文本语料进行微调。
在此处查看相关指南Embedding Fine-tuning Guide 参考内容
Building Performant RAG Applications for Production - LlamaIndex
https://www.youtube.com/watch?vZj5RCweUHIk
https://x.com/jerryjliu0/status/1692931028963221929?s20
