
🎾 RAG的28种优化技术
1.基本RAG
流程图
步骤
文本向量化步骤
- pdf文档转换为文本格式
- 切分文本块
- 文本块向量存储到向量数据库
问答步骤
-
用户问题向量化
-
向量数据库查询
-
组装prompt
示例Prompt
你是负责问答任务的助手。根据检索到的文档回答用户问题。最多用三到五个句子,保持回答简洁。 检索到的文档 {documents} 用户问题: {question}
-
回答问题
2.幻觉检查RAG
改进点:对于从向量数据库中查找到的文本块利用LLM对文档进行过滤,对于回答的内容与进行幻觉检查。
流程图
步骤
问答步骤
-
用户问题向量化
-
查询向量数据库,得到相似文档块
-
使用LLM判断文档块与查询问题的相关性,并过滤不相关文档块
示例相关性判断Prompt
你是一名评估检索文档与用户问题相关性的评分者。 如果文档包含与用户问题相关的关键词或语义,则将其评定为相关。 无需进行严格测试,目标是过滤掉错误的检索结果。 给出 “是” 或 “否” 的二元评分,以表明文档是否与问题相关。 检索文档: {documents} 用户问题: {question}
-
组装 问题与相关文档块 prompt,提交LLM生成初步答案
-
将 答案、相关文档块一同提交给LLM,判断是否产生了幻觉
示例幻觉判断Prompt
你是一名评分者,负责评估LLM生成的内容是否以一组检索到的事实为依据/受其支持。 给出 “是” 或 “否” 的二元评分。“是” 表示答案以该组事实为依据/受其支持。 事实内容 {documents} LLM生成的内容 {pre_answer}
-
无幻觉则直接完成问答,如有幻觉,需要提交LLM重新回答
-
LLM给出参考文档块的具体信息(可选)
示例引用信息获取Prompt
你是一名用于文档搜索和检索的高级助手。系统为你提供以下内容: 1. 一个问题。 2. 基于该问题生成的答案。 3. 生成答案时所参考的一组文档。 你的任务是从提供的文档中识别并提取与生成答案内容直接对应的精确内联片段。提取的片段必须是文档中的逐字摘录,确保与文档文本完全逐词匹配。 需确保: - 每个片段均与文档中的某部分完全匹配,且完整包含在文档文本内。 - 每个片段与生成答案的相关性明确,且直接支持所提供的答案。 - 若未使用某特定文档,则无需提及该文档。 使用的文档:<docs>{documents}</docs> 用户问题:<question>{question}</question> 生成的答案:{generation}
3.优化文本块
流程图
文本分块在RAG系统中是一个非常重要的步骤,直接影响了后续的文本检索以及LLM生成答案的质量。
文本分块方法
- 固定大小分块 :
- 描述: 这是最简单的方法,按照预定义的字符数、词数或令牌(token)数来分割文本。
- 优点: 实现简单,块大小统一。
- 缺点: 可能会在句子或段落中间断开,破坏语义完整性。
- 基于句子/段落的分块:
- 描述: 以句子结束符(如句号、问号、感叹号)或段落标记(如换行符)作为分割点。
- 优点: 通常能更好地保留语义单元的完整性。
- 缺点: 句子或段落的长度可能差异很大,导致块大小不均。
- 递归分块:
- 描述: 这种方法尝试按一组预定义的分割符(如段落、句子、单词)进行分层分割。拨入首先尝试用段落换行符分割文本。如果分割后的块仍然过大,则会递归地使用句子结束符对这些大块进行进一步分割,直到块大小符合要求。
- 优点: 努力在保持语义连贯性和控制块大小之间取得平衡。
- 缺点: 实现相对复杂一些。
- 语义分块:
- 描述: 这是一种更高级的方法,文本的语义含义来划分块。利用Embedding模型来识别文本中语义相似或相关的部分,并将它们尽可能的整理到同一个块中。
- 优点: 最大程度上保留了上下文和语义的完整性,有助于提高检索质量。
- 缺点: 计算成本较高,可能需要更复杂的实现。
- 基于文档结构的分块:
- 描述: 考虑文档的内在结构,例如HTML标签、Markdown标题、表格、列表、代码块等。
- 优点: 能够很好地处理具有复杂或特定结构的文档,如网页、代码文件、结构化报告等。
- 缺点: 需要针对特定文档类型定制分块逻辑。
选择合适的文本分块方法
不同类型的文档需要不同的分块方法,实际开发中需要明确文档的类型,观察文档信息,内容结构,对上述分块方法进行调整,以更好的适应目标文档,下面介绍一些常用的文件类型及其分块方法。
- 纯文本文档(如小说、文章): 基于句子或段落的分块,或者递归分块,通常效果较好。固定大小分块也可以使用,配合重叠分块。
- 代码文件: 基于函数、类或代码块的特定分块方法会更有效。简单的按行分割或固定大小分割可能会破坏代码的逻辑结构。
- 结构化文档(如HTML、XML、Markdown): 利用文档的标签和结构(如标题、列表、表格)进行分块是理想的。这有助于将相关信息(如一个标题及其下的段落)聚合在一起。
- 表格数据: 表格需要特殊的处理。简单地按行或按字符分割可能会丢失表格的结构信息(如表头与单元格的对应关系)。理想情况下,整个表格或者表格中有意义的子部分(如几行)应该被视为一个块,或者在分块时保留表头信息。其中一个技巧是,将表格给多模态模型转为纯文本模式,以纯文本的方式进行处理。
- PDF文档: PDF文档的分块可能更具挑战性,因为它们通常是视觉优先的格式。通常情况下,需要先将PDF文档转为Markdown等结构化文档(工具如minerU),再以纯文本的方式处理。
- 问答对文档: 理想情况下,每个问题和对应的答案应该被视为一个独立的块,或者紧密关联的块。
- 多媒体描述: 对于包含图像、音频等多媒体内容的文档。音频可以使用STT(语音转文本),先转为文本,再以纯文本的方式处理。对于图像,也可以像上面的表格一样,使用多模态模型描述为纯文本,再以纯文本的方式处理,不过对于一些工程制图或较为抽象的图片,该方法就不适用了。
4.命题块
命题:指的是原子的、事实的、自包含的和简洁的,描述了一个完整的事实。
例如:
原始文本:马云,1964年9月10日出生于浙江杭州,祖籍浙江省嵊县(现嵊州市)谷来镇,汉族,中共党员,阿里巴巴主要创始人之一,阿里巴巴原首席执行官(CEO)、董事局原主席,中国人民政治协商会议第十届浙江省委员会委员。
命题文本:
马云,1964年9月10日出生;
马云,阿里巴巴主要创始人之一;
马云,祖籍浙江省嵊县(现嵊州市)谷来镇;
...
流程图
步骤
-
文本分块
-
命题生成
示例命题生成Prompt
请将以下文本分解为简单、独立的命题。确保每个命题满足以下标准: 1. 表达单一事实:每个命题应陈述一个具体事实或主张。 2. 无需上下文即可理解:命题应独立自洽,即无需额外背景即可理解。 3. 使用全称而非代词:避免使用代词或模糊指代,使用完整的实体名称。 4. 包含相关日期 / 限定词(如适用):包含必要的日期、时间和限定词,使事实精确。 5. 包含单一主谓关系:聚焦于单一主语及其对应的动作或属性,不使用连词或多个从句。
-
命题质量检查
示例命题检查Prompt
请根据以下标准评估以下命题: - 准确性:根据命题反映原文的程度从 1-10 打分。 - 清晰度:根据无需额外背景即可理解命题的容易程度从 1-10 打分。 - 完整性:根据命题是否包含必要细节(如日期、限定词等)从 1-10 打分。 - 简洁性:根据命题是否在不丢失重要信息的前提下简洁明了从 1-10 打分。 示例: 文档内容:1969 年,尼尔・阿姆斯特朗在阿波罗 11 号任务期间成为首位在月球上行走的人。 命题_1:尼尔・阿姆斯特朗是一名宇航员。 评估_1:"准确性":10,"清晰度":10,"完整性":10,"简洁性":10 命题_2:尼尔・阿姆斯特朗于 1969 年在月球上行走。 评估_2:"准确性":10,"清晰度":10,"完整性":10,"简洁性":10 命题_3:尼尔・阿姆斯特朗是首位在月球上行走的人。 评估_3:"准确性":10,"清晰度":10,"完整性":10,"简洁性":10 命题_4:尼尔・阿姆斯特朗在阿波罗 11 号任务期间在月球上行走。 评估_4:"准确性":10,"清晰度":10,"完整性":10,"简洁性":10 命题_5:阿波罗 11 号任务发生在 1969 年。 评估_5:"准确性":10,"清晰度":10,"完整性":10,"简洁性":10 格式: 命题:"{命题内容}" 原文:"{原文内容}"
-
写入向量库
5.查询重写
使查询更加具体和详细,从而提高检索相关信息的可能性。
原始问题:气候变化对环境有什么影响?
后退提示问题:气候变化,具体如全球变暖、降水模式改变、极端天气事件增多等情况,产生了哪些具体、详细且不同方面的影响?
流程图
步骤
-
用户提问
-
使用LLM对用户问题重写
示例Prompt
你是一个人工智能助手,负责对用户查询进行重构,以提升检索增强生成(RAG)系统中的检索效果。 请根据原始查询,将其改写得更加具体、详细,且更有可能检索到相关信息。 原始查询:{original_query} 改写后的查询:
6.后退提示
使查询更加具体和详细,从而提高检索相关信息的可能性。
原始问题:气候变化对环境有什么影响?
后退提示问题:人类活动对地球生态系统的影响
流程图
步骤
-
用户提问
-
使用LLM对用户问题重写
示例Prompt
你是一个人工智能助手,任务是生成更广泛、更通用的查询,以改进检索增强生成(RAG)系统中的上下文检索效果。 给定原始查询,请生成一个更具通用性的背景查询,该查询应更概括,有助于检索相关背景信息。 原始查询:{original_query} 背景查询:
7.子查询分解
将复杂查询分解为更简单的子查询,以便更全面地检索信息。
原始问题:气候变化对环境有什么影响?
子查询分解问题:
-
气候变化对陆地生态系统(如森林、草原)的结构和功能有哪些影响?
-
气候变化如何影响水资源(如冰川消融、降水模式改变、海平面上升)?
-
气候变化对大气成分和极端天气事件(如热浪、暴雨、飓风)的频率及强度有何影响?
-
气候变化对海洋生态系统(如珊瑚礁、海洋生物多样性)的具体影响表现有哪些?
- 气候变化对陆地生态系统(如森林、草原)的结构和功能有哪些影响?
- 气候变化如何影响水资源(如冰川消融、降水模式改变、海平面上升)?
- 气候变化对大气成分和极端天气事件(如热浪、暴雨、飓风)的频率及强度有何影响?
- 气候变化对海洋生态系统(如珊瑚礁、海洋生物多样性)的具体影响表现有哪些?
流程图
步骤
-
用户提问
-
使用LLM将用户提问分解为多个子问题
示例Prompt
你是一个人工智能助手,负责为检索增强生成(RAG)系统将复杂查询分解为更简单的子查询。 给定原始查询,请将其分解为2-4个更简单的子查询,这些子查询的答案组合起来能为原始查询提供全面的回答。 原始查询:{original_query} 示例:气候变化对环境有哪些影响? 子查询: 1. 气候变化对生物多样性有哪些影响? 2. 气候变化如何影响海洋? 3. 气候变化对农业有哪些影响? 4. 气候变化对人类健康有哪些影响?
8.假设文档
传统的检索方法通常难以解决短查询和更长、更详细的文档之间的语义差距。假设文档通过将查询扩展为完整的假设文档来解决这个问题,通过使查询表示更类似于向量空间中的文档表示,可能提高检索相关性。
流程图
步骤
-
用户提问
-
使用LLM生成假设文档,通常只需要生成一个假设文档即可,
chunk_size
一般与文档分块的chunk_size
相同示例Prompt
针对问题 “{query}”,生成一份直接解答该问题的假设文档。文档需内容详尽、分析深入,且字符数严格为 {chunk_size}。
9.假设问题
假设问题不是嵌入原始文本块,而是为每个块生成多个假设问题 。这些预先计算的问题模拟用户查询,从而提高与实际搜索的一致性。
流程图
步骤
-
文本分块
-
使用LLM对文本块创建假设问题
示例Prompt
分析输入文本并生成关键问题,回答这些问题即可抓住文本的要点。每个问题占一行,不使用编号或前缀。 文本: {chunk_text}
10.上下文标头
通过预置 chunk 标头来为 chunk 添加更高级别的上下文。此块标题可以像文档标题一样简单,也可以结合使用文档标题、简洁的文档摘要以及章节和子章节标题的完整层次结构。
流程图
步骤
-
文本分块
-
使用LLM生成文档摘要(上下文标头),也可以直接用章节/子章节标题
示例Prompt
说明 以下文档的标题是什么? 你的回答必须是文档的标题,不能有其他内容。请勿回复其他任何信息。 文档: {document_text}
11.相关文本块提取
在为 RAG 对文档进行分块时,选择正确的数据块大小是管理权衡的练习。大块比小块为 LLM 提供更好的上下文,但它们也使得精确检索特定信息变得更加困难。某些查询最好由小块处理,而其他查询需要非常大的块。有些疑问可以用文档中的一句话来回答,而有些疑问则需要整个章节或章节才能正确回答。大多数实际的 RAG 使用案例都面临这些类型的查询的组合。
理论上:相关块往往聚集在其原始文档中 。实际文本统计分析发现也是如此。
流程图
步骤
- 用户问题向量化
- 向量数据库搜索Top 5(实际中建议使用Top 20)相关文本块
- 依据检索到的块最大最小块索引在KV数据库中查找这些索引之间的所有块
- 这些块全部计算与问题的相关性
- 统一减去0.2(0.2为实验得出的最优值)
- 使用Kadane算法,找到相关性值和最大的子数组文本块。(这里的子数组文本块,不一定只有一个,也可以使用暴力枚举法找到多个子数组文本块)
- 组装为Prompt,提交给LLM,进行回答
12.上下文窗口增强
传统的向量搜索通常会返回孤立的文本块,这些文本块可能缺乏完全理解所需的上下文。这种方法旨在通过包含相邻的文本块来提供更全面的检索信息视图。
流程图
步骤
- 用户问题向量化
- 向量数据库搜索到相关文本块
- 依据相关文本块的索引在KV数据库中查找这些块附近的其他块,(示例中,只是查找了前后块,实际使用中,可以更大一些)
- 组装为Prompt,提交给LLM,进行回答
13.语义分块
传统的文本拆分方法通常会在任意点中断文档,从而可能中断信息和上下文的流动。语义分块通过尝试在更自然的断点处拆分文本来解决此问题,从而保持每个块内的语义连贯性。
流程图
步骤
- 文档按照句子或段落初步分块
- embedding计算分块向量,计算文本块之间的相似度,相似度较高,文本块融合,相似度较低,单独分块。(相似度高低的判断使用已完成融合的文本块的相似度标准差为判断条件)
- 写入向量数据库
14.上下文压缩
传统的文档检索系统通常会返回整段或整篇文档,其中可能包含不相关的信息。上下文压缩通过智能地提取和压缩检索到的文档中最相关的部分来解决此问题,从而实现更有针对性、更高效的信息检索。
流程图
步骤
-
用户问题向量化
-
向量数据库搜索到相关文本块
-
使用LLM压缩上下文
示例压缩上下文Prompt
根据以下问题和上下文,按原文提取上下文中与回答问题相关的部分。如果上下文无相关内容,则返回NO_OUTPUT。 注意,**请勿**编辑所提取的上下文内容。 > 问题:{question} > 上下文: {context}} 提取的相关内容:
-
组装为Prompt,提交给LLM,进行回答
15.文档扩充
与假设问题法相似,利用额外的问题生成来改进向量数据库中的文档检索。通过生成并整合与每个文本片段相关的各种问题,系统增强了标准检索流程,从而提高了找到可用作生成式问答背景的相关文档的可能性。
流程图
步骤
-
文本分块
-
分块文本问题生成
示例问题生成Prompt
使用上下文数据:{context} 生成至少 {num_questions}个关于此上下文的可能问题列表。
-
分块文本与问题同时存入向量数据库
ps:问题入向量数据库时元数据增加“原始文本块”字段
16.混合检索
传统的检索方法通常依赖于语义理解(基于向量)或关键词匹配(BM25)。每种方法都有其优缺点。融合检索旨在整合这些方法,创建一个更稳健、更准确的检索系统,从而有效地处理更广泛的查询。
流程图
步骤
- 文本分块后,需要同时创建embedding和BM25索引,一般如ES,Milvus等数据库都支持同时索引这两类
- 用户问题同时向量和bm25查找相关文档
- 向量检索和bm25检索到的文档,需要进行重排,一般采用RRF等方法,使两种得分标准化到同一个尺度。
- 组装为Prompt,提交给LLM,进行回答
ps:embedding向量又叫做,稠密向量。BM25向量又叫做,稀疏向量。
17.重排名(Rerank)
重排名能够进行更复杂的相关性评估,将查询和文档之间可能被传统检索技术遗漏的细微关系纳入考量。此过程旨在通过确保在生成阶段使用最相关的信息来提升 RAG 系统的整体性能。
流程图
步骤
-
用户问题向量查询(或混合查询)
-
检索到的文本块再使用LLM或者重排模型进行二次排名
示例LLM重排Prompt
请按1-10的评分标准,评估以下文档与查询的相关性。评估时需考虑查询的具体上下文和意图,而不仅仅是关键词匹配。 查询:{query} 文档:{doc} 相关性得分:
-
组装为Prompt,提交给LLM,进行回答
18.分层检索
分层检索通过创建双层搜索系统,从而实现更高效、更能感知上下文的检索。
流程图
步骤
- 文本按照章节或页初步分块,使用LLM对块进行总结摘要
- 将初步的分块再细分为小文本块,如使用段落或句子分块
- 将摘要和小文本块存入两个向量数据库表中,小文本块添加额外的字段保存摘要块索引
- 用户问题向量化并检索摘要表
- 用户问题向量化并检索小文本块表,过滤条件限制为摘要索引
19.父子文档检索
父子文档检索与上面的分层检索相似,不同点是,一个用摘要,一个用完整的文档或分章节作为大文本块。
流程图
步骤
- 文本按照句子或固定字符串长度拆分为小文本块
- 将文章(小于1w字可以考虑)或按大章节划分为大的文本块;将小文本块写入向量数据库,注意同时保存大文本块的索引
- 用户问题向量化,先查询小文本块,再依据绑定的索引,检索到大文本块
- 使用大文本块组装Prompt,LLM回答用户问题
20.多样性检索(飞镖靶检索)
将相关性和多样性结合到单一评分函数中并直接对其进行优化。研究显示,当数据库密集(都是某一个领域大量文档)时,简单的 RAG 表现不佳,而多样性检索的表现优于它。
流程图
步骤
- 用户问题向量化
- 检索到Top20个相关文本块(参考实际情况,调整参数)
- 最相关文档为Top1,记为已选文档,其他19个文档为候选文档。
- 惩罚这些相关性值(如果一个候选文档块与已选文档块的 embedding 过于接近,它的被选中概率就会降低)。
惩罚算法如下:
- 余弦相似度 (基于向量): 直接降低分数(1-s_max), s_max代表已选文档与候选文档的相似性值。
- 最大边界相关算法(MMR): 它会迭代地选择文档,每次选择的文档都是在与查询相关的同时,与已选文档的相似度最低的。
- **基于聚类算法:**所有初始检索到的文档块进行聚类。然后,从不同的簇中选择文档,而不是从同一个簇中选择多个非常相似的文档。
21.元数据筛选
应用各种一些传统的过滤技术来改进和提高检索结果的质量。
流程图
步骤
- 文档切块后向量化保存时,在元数据中,同时保留更多信息,如下:
- 日期
- 来源
- 作者
- 文档类型
- ...
- 用户问题向量化
- 向量数据检索时使用元数据作为过滤条件。
ps:对于有时间要求的内容,可以将文档的日期作为权重之一,惩罚或奖励相关性
22.基于反馈的检索
类似搜索引擎的排名逻辑,用户点赞的越多(浏览时间长,追问次数少等),代表其回答的质量越高,相应的代表文本块更完整的能够该问题。收集并利用用户对检索文档的相关性和质量以及生成的响应的反馈来微调检索和排名模型。
流程图
步骤
- 标准的RAG流程
- 用户界面增加对回答质量的反馈按钮
- 基于用户反馈,惩罚或奖励文本块与查询的相关性
23.
自适应检索(问题路由)
利用分治方法,将查询分为不同的类别,并针对每个类别使用定制的检索策略,同时考虑用户背景和偏好。
流程图
步骤
- 利用LLM对用户问题进行查询分类
示例分类:
- 事实:寻求具体、可验证信息的查询。
- 分析性:需要全面分析或解释的查询。
- 观点:对主观问题提出质疑或寻求不同的观点。
- 上下文:依赖于用户特定上下文的查询。
- 针对不同的分类,应用不同的策略
- 事实策略:例如幻觉检查,假设问题等方法,使回答更加的精准。
- 分析策略:例如运用子查询分解,多样性检索方法,使最终文档选择多样。
- 观点策略:例如后退提示,混合检索等发放,使回答包含更多内容。
- 上下文策略:例如上下文窗口,父子文档等方法,使回答拥有上下文信息。
24.迭代检索
执行多轮检索以改进和提高结果质量。使用 LLM 分析初步结果并生成后续查询以填补空白或澄清信息。
流程图
步骤
- 问题向量化查询到文档进行初步回答
- 使用LLM判断初步答案是否完整回答了问题,并同时检查是否产生了幻觉
- 回答不完整或有幻觉,LLM重新生成查询问题,进行下一轮检索生成
ps:设置最大迭代轮次,避免文档库不全导致无限迭代
可解释检索
无论是LLM的幻觉亦或是从用户体验的角度来说,普通的RAG对用户都是黑盒状态。这导致了一个问题,用户不清楚LLM的回答是否可信,通常用户需要进行二次交叉验证。为了解决这个问题,一种可行的方式是,RAG给出答案的同时,能够明确其内容的出处。
生成引用标签的示例Prompt(来源DeepSeek官方文档)(如上图的引用标签需要前端工程实现,这里只是让模型给出其具体的引用内容)
# 以下内容是基于用户发送的消息的搜索结果: {search_results} 在我给你的搜索结果中,每个结果都是[webpage X begin]...[webpage X end]格式的,X代表每篇文章的数字索引。请在适当的情况下在句子末尾引用上下文。请按照引用编号[citation:X]的格式在答案中对应部分引用上下文。如果一句话源自多个上下文,请列出所有相关的引用编号,例如[citation:3][citation:5],切记不要将引用集中在最后返回引用编号,而是在答案对应部分列出。 在回答时,请注意以下几点: - 今天是{cur_date}。 - 并非搜索结果的所有内容都与用户的问题密切相关,你需要结合问题,对搜索结果进行甄别、筛选。 - 对于列举类的问题(如列举所有航班信息),尽量将答案控制在10个要点以内,并告诉用户可以查看搜索来源、获得完整信息。优先提供信息完整、最相关的列举项;如非必要,不要主动告诉用户搜索结果未提供的内容。 - 对于创作类的问题(如写论文),请务必在正文的段落中引用对应的参考编号,例如[citation:3][citation:5],不能只在文章末尾引用。你需要解读并概括用户的题目要求,选择合适的格式,充分利用搜索结果并抽取重要信息,生成符合用户要求、极具思想深度、富有创造力与专业性的答案。你的创作篇幅需要尽可能延长,对于每一个要点的论述要推测用户的意图,给出尽可能多角度的回答要点,且务必信息量大、论述详尽。 - 如果回答很长,请尽量结构化、分段落总结。如果需要分点作答,尽量控制在5个点以内,并合并相关的内容。 - 对于客观类的问答,如果问题的答案非常简短,可以适当补充一到两句相关信息,以丰富内容。 - 你需要根据用户要求和回答内容选择合适、美观的回答格式,确保可读性强。 - 你的回答应该综合多个相关网页来回答,不能重复引用一个网页。 - 除非用户要求,否则你回答的语言需要和用户提问的语言保持一致。 # 用户消息为: {question}
25.微软的GraphRAG
构建图谱
此处用到的Prompt多且长,想要学习的参考Graph RAG代码库https://github.com/microsoft/graphrag/tree/main/graphrag/prompts/index
流程图
步骤
- 文本分块
- 利用LLM进行实体与关系的抽取
- 利用LLM对实体和关系进行摘要生成
- 依据实体和关系,利用Leiden算法对元素进行社区构建
- 利用LLM生成社区摘要
查询
Ps: 此处用到的Prompt多且长,想要学习的参考Graph RAG代码库https://github.com/microsoft/graphrag/tree/main/graphrag/prompts/query
全局搜索
由于基本RAG依赖语义相似度搜索文本内容。 难以处理需要聚合整个数据集中的信息以形成答案的查询。类似于“数据中的前 5 个主题是什么”之类的查询。查询中没有任何内容可以将其定向到正确的信息。
全局搜索方法通过以 map-reduce 方式使用所有社区摘要来生成答案。这是一种资源密集型方法,适用于需要从整体上了解数据的问题。
步骤:
- 用户问题逐步与每个社区摘要进行答案生成
- 利用重排序模型,对答案进行过滤
- 得到最终的答案
本地搜索
本地搜索方法通过将 AI 提取的知识图谱中的相关数据与原始文档的文本块相结合来生成答案。这种方法适用于需要从文档中获取特定实体信息的问题。
步骤:
- 实体识别:当用户提出问题时,LLM识别与查询语义相关的关键实体(人员、地点、概念等)。
- 知识图谱导航:这些已识别的实体充当知识图谱的查询入口点,查询以下内容
- 与实体相关的文本块
- 与实体相关的社区摘要
- 与实体相关的其他实体
- 与实体相关的其他实体之间的关系
- 将查询到的内容分别进行重排序
- 最后再组装Prompt,做出最终回答
DRIFT搜索
DRIFT搜索通过在搜索过程中包含社区信息,是一种新的本地搜索查询方法。这极大地扩展了查询起点的广度,并在最终答案使用更多种类的事实。最终的答案将具有全局搜索的全面性,同时又具有本地搜索的精确性。
步骤:
- 用户查询向量化检索top k社区摘要
- 生成初步答案和可能的后续问题
- 初步答案和后续问题作为用户查询进行本地搜索
问题生成
很多AI系统都会提供候选问题增强用户体验,Graph RAG特别适合这个场景。此功能获取用户查询列表并生成下一个候选问题。这对于在对话中生成后续问题或生成问题列表供调查人员更深入地了解数据集非常有用。
给定一个先前用户问题的列表,问题生成方法使用与本地搜索中采用的相同的上下文构建方法来提取相关的结构化和非结构化数据并确定其优先级,包括实体、关系、社区报告和原始文本块。然后将这些数据记录作为上下文,生成代表数据中最重要或最紧急信息内容或主题的候选后续问题。
Graph RAG常用组件
26.Self-RAG
Self-RAG动态决定是否使用检索到的信息以及如何最好地利用它来生成响应,旨在产生更准确、更相关和更有用的输出。通过实施多步骤流程,仔细评估检索信息的必要性和相关性,并评估生成的响应的质量。
流程图
步骤
-
用户问题LLM判断是否需要检索,可防止对可以直接回答的查询进行不必要的检索。
示例Prompt
给定查询“{query}”,判断是否需要检索。仅输出“Yes”或“No”。
-
有必要检索,向量数据库检索Top k
-
利用LLM或rerank模型检查文档与查询问题的相关性
示例Prompt
给定查询“{query}”和上下文“{context}”,判断上下文是否相关。仅输出“相关”或“不相关”。
-
问题与检索到的文档生成多个初步答案
-
利用LLM检查“初步答案”是否与检索文档事实不符(幻觉检查),只保留“完全支持”的初步答案
示例Prompt
根据回答“{response}”和上下文“{context}”,判断回答是否受上下文支持。输出“完全支持”、“部分支持”或“不支持”。
-
LLM评估答案对原始查询的回答程度
示例Prompt
给定查询“{query}”和回答“{response}”,将回答的实用性从1到5进行评分。
-
选择最佳答案响应
27.矫正RAG(CRAG)
矫正RAG流程是一种高级信息检索和响应生成系统。它通过动态评估和纠正检索过程,结合向量数据库、Web 搜索和语言模型的强大功能,为用户查询提供准确且上下文感知的响应,从而扩展了标准 RAG 方法。
流程图
步骤
- 用户问题检索向量库
- 判断文档块的最大相关性分数
-
0.7, 判定为 “相关” ,表示检索出的文档包含了回答用户查询需要的关键信息,此时可以启用知识精炼算法(knowledge refinement algorithm),对文档内容进行重写优化。
- <0.3, 若判定为 “不相关” ,则意味着用户查询与检索出的文档完全不相关。在 CRAG 技术方案中,会使用web搜索来检索更多外部知识。
- 0.3<=分数<=0.7,若判定为 “不确定” ,表明检索出的文档虽与需求相去不远,但尚不足以直接给出答案。需要通过web搜索来补充缺失信息。
-
- 对于需要web搜索的问题,需要先对原始问题进行改写已适用于web搜索
- 组装Prompt,完成回答
- 相关,直接使用向量数据库检索到的文档
- 不相关,使用web搜索到的文档
- 不确定,结合向量数据库文档和web搜索文档
28.Agentic RAG
尽管传统RAG在一定程度上缓解了LLM的局限性,这些局限性的根源在于传统RAG系统本质上仍是一种“流水线式”的处理模式。系统按照预设的步骤被动地执行任务,缺乏对任务本身的深入理解和主动的策略调整能力。
Agentic RAG通过在RAG流程中嵌入具备自主决策、规划、工具使用和学习能力的AI Agent,旨在赋予RAG系统前所未有的动态性、智能性和适应性。这种方式不是对RAG功能的简单叠加,更是AI领域追求更高级别自主性和智能性这一宏观趋势在信息检索与生成领域的具体体现。Agentic RAG的出现,被视为RAG发展历程中的一次“范式转变”,预示着信息系统将从被动的指令执行者向主动的问题解决伙伴演进。
本篇文章我们将Agentic RAG简单的划分为单Agent RAG和多Agent RAG(多Agent RAG 还能依据Agent的架构进一步的细分为分层Agent、矫正Agent、Agent文档工作流等)进行简单的了解。
单Agent RAG
由单个具备自主能力的AI Agent全面负责管理整个检索和生成过程。
用户问题首先提交给这个唯一的Agent。Agent分析查询,决定是否需要以及如何从外部知识源检索信息,然后处理检索到的数据,并最终将其综合到生成的响应中。在其最简单的实现形式中,这个单Agent可以扮演一个“路由器” (Router) 的角色,即根据查询的特性,决定应该从多个可用的知识源中的哪一个(或哪几个)来检索上下文信息。
这种架构相对简单,对于一些基本的、不需要复杂多步推理的应用场景而言,易于实现、部署和维护。
多Agent RAG
系统中存在一个由多个Agent组成的团队,它们通过协作来共同完成复杂的检索、分析和推理任务。这些Agent通常各具专长,能够动态地划分任务并专注于特定的子任务。
接收到的复杂任务首先被分解,然后分配给团队中合适的专门Agent。这些Agent可以并行工作,也可以串行接力。它们之间需要有效的通信机制来共享信息、中间结果和状态。例如,可以设计一个“主Agent”来协调多个专门负责不同类型信息检索的“检索Agent”(比如,人员信息检索Agent、项目信息检索Agent、财务信息检索Agent)。
多Agent架构通过任务分解和并行处理,能够显著提升处理分布式复杂任务的性能和效率。其模块化的设计也使得系统更易于扩展和维护,可以根据需要灵活地增加或替换具有特定功能的Agent。
Agentic RAG融合了我们之前介绍的大量基础的RAG技巧。
它的出现不仅仅技术演进,更深刻地触及了人工智能、信息科学乃至认知科学等多个交叉学科(Agent的工作模式更是人类社会工作模式的映射。
Agentic RAG现在已被大多数厂商采用,如OpenAI,Gemini的Deep Research,甚至于Manus,等通用Agent也是Agentic RAG的变体。