Simple RAG
它就是广义的RAG，检索增强生成是一种混合方法，它结合了信息检索与生成模型。通过结合外部知识，增强了语言模型的表现，提高了准确性和事实的正确性。
实现步骤：
1.数据采集：加载和预处理文本数据
2.分开处理：将数据分割为更小的块，以提高检索性能
3.嵌入创建：使用嵌入模型将chunk转换为数值表示
4.响应生成：使用语言模型根据检索到的文本生作为上下文生成响应
适用场景
概念验证（PoC）： 当你需要快速搭建一个原型来验证RAG的可行性时。
数据质量高且结构化： 适用于处理内容界限分明、主题单一的文档，例如公司FAQ、产品说明书的独立章节等。
用户查询直接明确： 当用户的提问通常能直接映射到文档中的某一段具体描述时。
资源有限的环境： 当计算资源、开发时间或维护成本有限时，简单RAG是成本效益最高的选择。
底层代码看链接，链接中包含更多RAG源码和介绍：https://github.com/liu673/rag-all-techniques/blob/master/README.md#Simple-RAG
Semantic Chunking
文本切分是RAG中的关键步骤，其中将大文本体分割成有意义的段落以提高检索准确性。与固定长度切分不同，语义块切分是根据句子间的相似性来分割文本的。
实现步骤：
1.数据采集：加载和预处理文本数据
2.句子级切分：先按照句子切分，以便后续比较句子间的相似度。
3.创建语义级chunk：
1.相邻句子之间计算相似度
2.根据相似度下降计算分块的断点，计算断点的方式：百分位，标准差和四分位距
3.根据断点分割文本得到chunk
4.创建chunk的向量库
5.根据query检索向量库
6.将检索出的chunk作为上下文用于语言模型生成回答
适用场景：
长篇、连贯的文档： 处理法律合同、学术论文、研究报告、技术白皮书等。在这些文档中，一个完整的观点或论证可能横跨多个句子甚至段落。
叙事性内容： 处理故事、新闻报道或会议记录，确保一个场景或一个讨论要点的完整性。
避免上下文丢失： 当固定长度的切分经常导致检索到的文本块“缺头少尾”，使得LLM难以理解时。
Context Enriched Retrieval
RAG中传统的检索方法返回孤立的文本片段，这可能导致答案不完整。为了解决这个问题，引入了上下文增强检索，确保检索到的信息包括相邻的片段，以实现更好的连贯性。
实现步骤：
1.数据采集。
2.重叠上下文分块：将chunk分割为有一定量重叠的块以保留部分上下文。
3.用嵌入模型将chunk向量化存入向量库中。
4.上下文感知检索：检索相关块，不仅选择相关块，还选择相关块的领居。
5.将检索出的chunk及其邻居作为上下文用于语言模型生成回答。
适用场景
信息密度高的文本： 如财务报表、科学文献。某个关键数据（如“净利润增长15%”）的意义完全依赖于前文（原因分析）和后文（与同期的比较）。
对话或逐步解释的文本： 在教程、操作指南中，一个步骤的理解往往需要知道上一步做了什么。
平衡检索精度和信息完整度： 当你希望检索系统能精确命中某个句子，但又担心仅凭这个句子信息不足时，这种方法是最佳折中。
Contextual Chunk Headers
标准的分块往往丢失重要的上下文，使得检索效果不佳。上下文块标题通过在每个块嵌入之前添加高级上下文（如文档标题或部分标题）来增强RAG。这提高了检索质量，防止不相关的响应。
实现步骤：
1.数据采集和处理
2.带上下文标题的块分割：提取章节标题（或使用LLM为块生成标题）并将其添加到块的开头。
3后续步骤和普通RAG处理方式一样。
适用场景
主题多样的长文档： 例如，一本用户手册可能包含“安装”、“功能介绍”、“故障排除”等多个章节。为每个块添加如“第一章：安装指南”的标题，能极大提高检索相关性。
结构化数据转换的文本： 从表格或JSON转换来的文本块，可以把列名或键名作为标题，保留其结构信息。
提高主题检索的准确性： 当用户查询的是一个宽泛的主题而非具体细节时，标题能提供强烈的信号。
Document Augmentation
通过文档增强和问题生成来改进。通过为每个文本块生成问题，这些问题也会被作为检索的依据，从而提高检索相关性质量，从而使模型提供更好的响应。
实现步骤:
1.数据采集
2. 分块处理
3.生成问题：为每个chunk生成相关的问题(当然是调用语言模型生成的问题)。
4.将生成的问题和chunk一同存储进向量库
5.根据query检索向量库，对于检索到的问题，将其转换为对应的chunk文本。
6.响应生成。
适用场景：
FAQ自动生成： 最直接的应用，文档里是答案，此方法可以生成对应的问题。
改善“措辞不匹配”问题： 当用户的提问方式与文档的陈述方式差异很大时。例如，文档说“本产品采用A7处理器”，用户可能会问“这个东西快不快？”。生成的增强问题“A7处理器的性能如何？”可以连接两者。
知识库内容稀疏： 当知识库中的信息比较零散，通过生成问题可以丰富其被检索到的“角度”
Query Transformation
通过修改用户查询，可以显著提高检索信息的关联性和全面性。
一般有三种查询转换方式：
1.查询重写：使查询更加详细和具体，从而提高检索精度
2.查询回退：生成更广泛的查询，以检索有用的上下文信息
3.子查询分解：将复杂查询拆分为更简单的组件，以实现全面检索。
实现步骤不细说了，多了个查询转换的过程。注意最后响应生成时的prompt中依然使用原始query
适用场景：
处理复杂或模糊的查询： 当用户提出一个包含多个子问题或意图不明的查询时。例如“比较一下iPhone和安卓在隐私和自定义方面的区别”。可以分解为“iPhone的隐私策略”、“安卓的隐私策略”、“iPhone的自定义能力”等子查询。
处理口语化或有错别字的查询： 可以将“那个管电脑的策略是啥来着”转换为“公司的IT设备使用管理政策是什么？”。
作为检索失败后的备用策略（Fallback）： 当第一次用原始查询检索不到任何结果时，可以触发查询转换，用一个更泛化或更规范的查询重试一次。
Reranker
实现重排序以提高RAG系统中的检索质量。重排序作为初始检索后的第二部过滤，确保使用最相关的内容进行响应生成。
实现步骤：
1.处理文档实现向量存储：从需要读取的数据一般是pdf中提取文本，然后分割文本块，文本块向量化存入向量库中。
2.创建查询嵌入并检索相关chunk：query向量化，在向量库中检索top-n(top-n一般取大一点，因为后续的重排序会再筛选一次)个相关chunk。
3.对top-n个相关chunk应用重排序：有两种方式：
1.应用LLM的重排序：使用LLM对query和每个chunk的相关性评分进行重排序。
2.基于关键词的重排序：关键词匹配的次数和关键词所在位置的简单重排序方法。
4.选择重排序后的top-k个chunk作为上下文参与语言模型的响应生成。
适用场景
-
追求高精度的所有场景： Reranker是提升RAG系统回答质量最有效和通用的方法之一，几乎适用于所有对结果准确性有要求的系统。
初始检索结果多但良莠不齐： 当向量检索召回了大量看似相关但实际存在细微差别的结果时。Reranker擅长分辨这种“细微差别”。
需要处理否定或特定约束的查询： 例如“哪些笔记本电脑不包含独立显卡？”。向量检索可能把所有提到“独立显卡”的都找出来，而Reranker能更好地理解“不包含”这个逻辑，将真正相关的结果排到前面。
Adaptive RAG
自适应检索系统可根据查询类型动态选择最优检索策略，该方法显著提升RAG系统在多样化问题场景下的响应准确性与相关性。
实现步骤：
1.处理文档提取文本，将其分块，并输入向量库。
2.使用llm对查询进行分类，分为：事实型、分析性、意见型、上下文相关型。
3.根据查询类型使用自适应检索策略文档
4.根据查询、检索到的文档和查询类型生成回答。
分别介绍一下每种查询的区别：
1. 事实型查询 (Factual Query)
这类查询旨在获取客观、具体、可验证的信息。答案通常是唯一的或有明确来源的。
例子：
珠穆朗玛峰的海拔高度是多少？
实现方式：
事实型实现没什么好说，对query重构，使其更精确更具体。
2. 分析性查询 (Analytical Query)
这类查询要求对信息进行比较、解释、总结或探究因果关系。它需要的不是单一事实，而是对事实的组织和解读。
例子：
为什么说唐朝是中国历史上最强盛的朝代之一？
实现方式：
1，对给定的分析性查询生成探索不同维度的子问题。这些子问题应覆盖主题的广度并帮助获取全面信息。一般生成三个子问题。
2.根据每个子问题检索相关chunk
3.每一个子问题起码有一个相关chunk参与prompt生成
3. 意见型查询 (Opinion-based Query)
这类查询涉及主观判断、个人偏好、建议或价值观。答案没有绝对的对错，通常因人而异。
例子：
你觉得哪款手机最适合旅行拍照？
实现方式：
1.针对给定的观点类或意见类查询，请识别人们可能持有的不同立场或观点。通常也会定义三个不同观点角度。
2.将不同的观点角度各自与query结合，得到三个不同的新query再检索。
3.每一个观点视角起码有一个相关chunk参与prompt生成
4. 上下文相关型查询 (Contextual Query)
这类查询的理解和回答严重依赖于之前的对话内容。它本身可能不完整，需要结合上下文才能明白其确切含义。
例子：
（在讨论完“流浪地球2”的剧情后）
那它的票房表现怎么样？
实现方式：
1.让llm推断当前query可能隐含或未说明的上下文信息
2.根据生成的上下信息和query合并构成新的query，利用新的query检索相关chunk
3.根据chunk和query生成响应
适用场景
开放域问答系统或通用聊天机器人： 这类系统需要处理各种各样的问题。有些是闲聊（如“你好吗？”），有些是常识（如“法国的首都是哪里？”），有些则需要从特定知识库中查找答案（如“我们公司的年假政策是什么？”）。自适应RAG可以判断出闲聊和常识问题无需检索，从而节省资源并提高响应速度。
查询复杂度不一的环境： 当用户的提问难度差异很大时。例如，对一个简单的事实查询，它可能直接执行Simple RAG；但当它识别到一个复杂的、需要比较分析的查询时，它可能会启动查询分解（Query Transformation）或重排序（Reranker）等高级策略。
成本和效率敏感型应用： 通过避免不必要的检索和计算，自适应RAG可以显著降低API调用成本和系统延迟，尤其是在大规模应用中。
Fusion RAG
实现一个融合检索系统，将语义向量检索和基于关键词的BM25检索优势相结合。这种方法同时捕获概念相似性和精确关键词匹配，提升了检索质量。
向量检索擅长捕捉语义相似性，但可能会遗漏精确的关键词匹配。
关键词搜索适合特定术语检索，但缺乏语义理解能力。
不同类型的查询在不同类型的检索方法中表现差异显著。
实现步骤：
- 从 PDF 文件中提取文本
- 使用 jieba 分词器对文本进行分词，并创建向量存储
- 使用 BM25 算法对查询进行关键词匹配
- 使用向量搜索对查询进行语义匹配
- 将两种方法的结果进行加权组合，并重新排序
- 返回最终的搜索结果
适用场景
包含大量专业术语、缩写或ID的领域： 例如医疗、法律、金融或IT领域。用户查询中可能包含必须精确匹配的词（如药品名“阿司匹林”、错误代码“404 Not Found”、法律条款号“Article 15”）。向量检索可能会忽略这些词的精确性，而关键词检索能保证找到它们。
电子商务搜索引擎： 用户可能会搜索一个精确的型号（“iPhone 15 Pro Max”），也可能搜索一个模糊的需求（“适合拍照的手机”）。融合检索可以同时满足这两种需求。
需要全面召回的场景： 在一些不能漏掉任何可能相关信息的场景（如专利检索、合规性审查），融合多种检索策略可以最大化召回率，确保结果更全面。
Hierarchical Indices
实现一种RAG系统的分级检索方法。这种技术通过两级检索方法来提高检索效果：首先通过摘要识别相关的文档部分，然后从这些文档中检索具体chunk。
为什么要这样做呢？
1.文本chunk过小时上下文丢失。
2.chunk过大时，检索到无关的信息。
3.在整个语料库中搜索效率低下。
分级检索解决了这个问题：
1.为较大的文档部分创建摘要。
2.首先检索这些摘要以确定相关部分。
3.然后仅从这些相关文档中检索详细的chunk
实现步骤：
1.从pdf中读取页面
2.为每一页创建摘要
3.对每一页做文本分割得到每一页的详细chunk
4.构建两个向量库，以存储摘要向量，一个存储chunk向量
5.检索相关摘要，得到对应的页。
6.过滤掉不相关的页，从相关页中检索详细块。
7.根据检索到的块生成回答
适用场景
处理海量、结构化的文档集合： 当知识库由成千上万份文档组成时，如整个公司的Wiki、一套完整的法律法规、或者几十本技术手册。在如此大的信息池中进行扁平化搜索，效率低且容易产生噪音。
文档内部结构清晰、层次分明： 非常适合有明确“书-章-节”或类似结构的内容。
需要“自上而下”探索式查询的场景： 当用户的问题比较宽泛，需要系统先定位到正确的“信息区域”，再深入细节时。例如，“告诉我关于数据库性能优化的信息”，系统可以先找到“性能优化”这本手册，再找到“索引优化”这一章。
Hypothetical Document Embedding
假设文档嵌入，它将用户查询转换为假设性的回答文档后再进行检索、这种方法弥补了短查询与长文档之间的语义差异。
传统的 RAG（Retrieval-Augmented Generation，检索增强生成）系统是直接对用户的简短查询进行嵌入处理，但这种方式往往无法捕捉到最佳检索所需的丰富语义信息。HyDE 通过以下方式解决了这一问题：
- 生成一个假设性文档来回答该查询
- 对该扩展后的文档进行嵌入，而非原始查询
- 检索与该假设文档相似的文档
- 从而生成更加上下文相关的回答
实现步骤：
- 从PDF文件中提取文本内容
- 分割文本为块
- 创建一个向量存储，将文本块和元数据存储为向量
- 根据用户查询，利用模型回答用户的查询（生成假设性文档）
- 为假设文档创建嵌入
- 根据假设文档检索相似的片段
- 然后利用检索到的片段构成上下文，生成回答
适用场景
解决“问题-答案”的语义鸿沟问题： 当用户的提问方式与知识库中文档的陈述方式差异巨大时。这在学术、科学或技术问答中尤其常见。
处理抽象或复杂的查询： 当问题本身很简短或抽象，但期望的答案是具体且详细的。
无监督或零样本场景： HyDE不需要任何额外的训练数据，可以直接应用于现有的RAG系统，作为一种提升检索精度的方法