“ 一个是上个月的文章,一个是llamaindex昨天发的,内容差不多,放一起了。内容其实应该都见过,基本都是唠叨很久的东西了
https://blog.llamaindex.ai/a-cheat-sheet-and-some-recipes-for-building-advanced-rag-803a9d94c41b
为了让 RAG 系统被视为成功(能够提供有用和相关的答案给用户问题),实际上只有两个高层次的要求:
- 检索必须能够找到与用户查询最相关的文档。
- 生成必须能够充分利用检索到的文档来足够回答用户的查询。
检索的高级技术必须能够找到与用户查询最相关的文档。
以下我们简要描述了一些更复杂的技术,以帮助实现第一个成功需求。
“ 原文包含代码
- 块大小优化:由于LLMs受上下文长度限制,在构建外部知识数据库时需要对文档进行分块。太大或太小的块可能会导致生成组件出现问题,从而导致不准确的响应。
- 结构化外部知识:在复杂的场景中,可能需要比基本的向量索引更加结构化地构建外部知识,以便在处理合理分离的外部知识源时进行递归检索或路由检索。
- 利用知识图谱构建外部知识
https://docs.llamaindex.ai/en/stable/examples/query_engine/knowledge_graph_rag_query_engine.html
- 混合搜索
https://docs.llamaindex.ai/en/stable/examples/vector_stores/elasticsearch_auto_retriever.html
- 构建融合检索器
https://docs.llamaindex.ai/en/stable/examples/retrievers/simple_fusion.html
- 微调用于检索的嵌入模型
- 转换查询嵌入(HyDE)
生成的高级技术必须能够充分利用检索到的文档。
与前一节类似,我们提供了一些属于这一类别的复杂技术的例子,可以描述为确保检索到的文档与生成器的LLM(语言模型)良好对齐。
- 信息压缩:LLM不仅受上下文长度限制,而且如果检索到的文档包含太多噪音(即无关信息),可能会导致响应降级。
- 结果重新排名:LLM(大型语言模型)遭受所谓的“中间丢失”现象,即LLM倾向于关注提示的极端部分。基于此,有益的做法是在将检索到的文档传递给生成组件之前对其进行重新排名。
同时解决检索和生成成功要求的高级技术
在这个小节中,我们考虑使用检索和生成的协同作用来实现更好的检索以及更准确地生成用户查询的响应的复杂方法。
- 生成器增强检索:这些技术利用LLM固有的推理能力,在执行检索之前,对用户查询进行细化,以更好地指示需要提供有用响应的内容。
- 迭代式检索生成器RAG:对于一些复杂情况,可能需要多步推理来提供对用户查询有用且相关的答案。
RAG评估
- 答案相关性和上下文相关性
- 忠实度
- 检索评估
- 使用BatchEvalRunner进行批量评估
https://pub.towardsai.net/advanced-rag-techniques-an-illustrated-overview-04d193d8fec6
这篇文章有点长,懒得翻译了,进阶主要包含这几点
- Hierarchical indices
如果您需要从许多文档中检索信息,您需要能够高效地在其中进行搜索,找到相关信息,并在单个答案中综合这些信息,并引用来源。在处理大型数据库时,一种高效的方法是创建两个索引——一个由摘要组成,另一个由文档片段组成,并分两步进行搜索,首先通过摘要筛选出相关文档,然后仅在这个相关组内部进行搜索。
- Hyde
- context enrichment
- sentence window retrieval : 小片段上下扩充
- auto-merging retriever :存储父块、子块,找到子块扩展到父块
- hybird search
- reranking & filtering
- query 改写
- 答案的参考引用
- chat engine: 上下文、环境信息维护
- query routing
query routing是LLM驱动的决策步骤,根据用户查询决定下一步该做什么 - 选项通常是进行总结,对某些数据索引进行搜索,或尝试多种不同的路线,然后将它们的输出综合成一个单一的答案。query routing还用于选择索引,或者更广泛地说是数据存储,以确定要发送用户查询的位置 - 无论是有多个数据源,例如经典的向量存储和图数据库或关系型数据库,还是有索引的层次结构 - 对于多文档存储,一个非常经典的情况是例如摘要索引和另一个文档块向量索引。
定义query routing包括设置它可以做出的选择。通过LLM调用执行路由选项的选择,并以预定义格式返回其结果,用于将查询路由到给定的索引,或者如果我们正在谈论支系行为,则将其路由到子链甚至其他代理
- Agents in RAG
让我们来看看多文档代理方案——这是一个非常复杂的设置,涉及在每个文档上初始化一个代理(OpenAIAgent),能够进行文档总结和经典的问答机制,并且有一个顶级代理,负责将查询路由到文档代理并进行最终答案的综合。
每个文档代理都有两个工具——一个向量存储索引和一个摘要索引,并根据路由的查询决定使用哪一个。对于顶级代理来说,所有文档代理都是相应的工具。
这个方案展示了一个先进的RAG架构,每个涉及的代理都做出了许多路由决策。这种方法的好处是能够比较不同的解决方案或实体,这些解决方案或实体描述在不同的文档和它们的摘要中,以及经典的单个文档摘要和问答机制 - 这基本上涵盖了最常见的与文档集合聊天的用例。
- Response synthesiser
这是任何RAG管道的最后一步 - 根据我们仔细检索的所有上下文和初始用户查询生成答案。最简单的方法就是将所有获取的上下文(超过某个相关阈值)与查询一起连接并一次性输入LLM。但是,总是有其他更复杂的选项,涉及多次LLM调用以完善检索到的上下文并生成更好的答案。响应合成的主要方法包括:
-
通过逐块发送检索到的上下文到LLM来迭代地完善答案
-
总结检索到的上下文以适应提示
-
基于不同的上下文块生成多个答案,然后将它们连接或总结起来。