本系列目录

《带你自学大语言模型》系列部分目录及计划，完整版目录见：带你自学大语言模型系列 —— 前言

第一部分 走进大语言模型（科普向）

• 第一章 走进大语言模型

• • 1.1 从图灵机到GPT，人工智能经历了什么？——《带你自学大语言模型》系列

  • 1.2 如何让机器说人话？万字长文回顾自然语言处理（NLP）的前世今生 —— 《带你自学大语言模型》系列

    … …

第二部分 构建大语言模型（技术向）

• 第二章 基础知识

• • 2.1 大语言模型的训练过程 —— 《带你自学大语言模型》系列

  • 2.2 大模型算法基础：Transformer —— 《带你自学大语言模型》系列

  • 2.3 大模型硬件基础：AI芯片（上篇） —— 《带你自学大语言模型》系列

  • 2.4 大模型数据基础：预训练阶段数据详解 ——《带你自学大语言模型》系列

  • 从LLaMa 3 技术报告，再看LLM构建过程 ——《带你自学大语言模型》系列（番外）

• 第三章 预训练

• 第四章 微调和对齐

• 第五章 部署和推理

第三部分 大语言模型应用

• 第六章 检索增强生成（RAG）
• • 6.1 RAG 技术概览，从AI搜索谈起（本篇）

… …

欢迎关注同名公众号【陌北有棵树】，关注AI最新技术与资讯。

写在前面

有个现象还挺有趣的，大模型风风火火了一年多，如今大家都不约而同卷到了AI搜索这一个赛道里，从Perplexity、Genspark，到国内的秘塔、Kimi、简单搜索、腾讯元宝。

好奇宝宝可能要问了，为什么会发生这样的聚集？因为，「信息检索与整理」是与大模型目前能力匹配的一个应用场景，并且用户有较强的需求，并且传统搜索的体验已经太多年没有变化，且充斥广告，用户期待新的体验。这个结论其实在ChatGPT刚出来的时候，就有相应的观点了，那个时候就在说，Google处在了比较危险的位置。或许有的时候，创新也好颠覆也好，真的不应该去挑战常识，通过逻辑和常识得出的结论，需要做的就是积蓄和等待…

而AI搜索的底层技术，其实就是RAG。这个系列本来的计划是先把模型层面的知识写完，再去写应用层面的，当时我的原因是在大模型能力没有触到天花板时，上层技术的迭代更新太快，比如Langchain就是个例子…

但是目前来看，RAG 所直面的大模型的实时信息不足、幻觉这两个问题，目前只靠在模型侧是很难解决的，所以RAG 无论如何应该都会是大模型上层不可或缺的基础设施了。

尤其是AI搜索这么卷的当下，我们急需将RAG本身带来的问题解决，才能对AI搜索结果带来质的飞跃，同时我们也在做AI搜索相关的产品，如果对别人来说，RAG只是纸上谈兵，对我们来说，RAG所有被提及的问题，我们都真真切切的遇到了。

并且在为这篇文章收集资料、查阅相关的论文时，我发现我们之前内部讨论的问题与思考，同样在另一个地方、以另一种形式表述着，虽然命名方式和话语体系有差别，但其实本质上都在思考同样的问题，这种感觉还挺奇妙的…

所以虽然大模型基础还没写完，我还是想先把RAG的系列开起来。

说实话，RAG的基础架构并不复杂，按照 Native RAG 的基础方式搭一个demo出来，是十分快捷和方便的，但这离真正能投入到生产环境中使用，就差的太远了，这就是所谓的“一周出demo，半年用不好”，每个步骤做的不精细，都会影响最终的效果，同时每个步骤的优化现在也都有大量的研究在进行。

本节6.1.1 聊聊AI搜索，是非技术向的，6.1.2~6.1.6 是RAG技术向的，大家按需取用即可。

本节目录

• 6.1.1 从AI搜索谈起

• • 6.1.1.1 AI搜索的现状
  • 6.1.1.2 AI搜索在做的是什么

• 6.1.2 RAG概述

• • 6.1.1.1 RAG是什么
  • 6.1.1.2 为什么需要RAG？是否会被取代？
  • 6.1.1.3 RAG待解决的问题有哪些？

• 6.1.3 RAG分类

• • 6.1.2.1 Naive RAG
  • 6.1.2.2 Advanced RAG
  • 6.1.2.3 Modular RAG

• 6.1.4 检索阶段

• • 6.1.4.1 检索源

  • 6.1.4.2 索引优化

  • 6.1.4.3 查询优化

• 6.1.5 生成阶段

• • 6.1.5.1 对文档块重新排序
  • 6.1.5.2 文本选择和压缩

• 6.1.6 RAG 能力增强

• • 6.1.6.1 迭代检索
  • 6.1.6.2 递归检索
  • 6.1.6.3 自适应检索

• 参考文献

6.1.1 从AI搜索谈起

6.1.1.1 AI搜索的市场现状

目前市面上AI搜索的玩家，我觉得与其分三类不如分两类：之前有沉淀的公司和从零起步的公司。

一类是在之前有积累和沉淀的公司，这包括内容沉淀和模型沉淀。

内容可以说是决定AI搜索效果的关键因素。内容沉淀不能单说传统搜索引擎公司，近年来小红书、抖音也都在蚕食传统搜索的份额，也都沉淀了大量内容。

模型沉淀来讲，大公司都有自己的大模型，同时一些大模型厂商也直接下场做AI搜索，国外以OpenAI，国内以天工AI、Kimi为代表，据目前可获取的信息来判断，OpenAI 的SearchGPT 采用的是 “自建部分索引库+Bing API+实时网络爬虫” 来弥补内容缺失这一短板。

其实不难看出，有一些玩家是既有内容沉淀又有模型沉淀的，基本都是大厂。这里我们主要看国内，像百度、字节是显而易见的，其实还有两个容易被忽视，腾讯也是有搜狗浏览器，同时公众号、微信读书也都是优质资源，阿里也有夸克搜索。简单搜索、豆包、腾讯元宝、夸克AI搜索，是目前几家拿出的产品。

另一类是从零起步的公司，国外以Perplexity、Genspark为代表，国内主要以快找找、秘塔、问小白等为代表。如前文所说，大厂其实无论在内容和技术上都有优势，那创业公司的机会在哪里？

Perplexity其实给出了一个版本答案，目前Perplexity 的估值超过 30 亿美元，在近期的访谈里，Perplexity 的 CEO Aravind Srinivas 在访谈中说 他们的目的不是取代谷歌，而是在做谷歌看不上的事情，他们也并不想做一个谷歌，谷歌最初的愿景是「让信息变得对所有人都可访问」，而 Perplexity 是想做「知识的起点」。

或许，真正能让创业者有机会的地方在于，原来市场中的巨头要么看不清发展趋势给了你先机，要么看清了也没办法采纳和直接使用。巨轮在航行时，转弯和掉头都是麻烦的，同时意味着也是缓慢的，这才给了创业者机会。创新工厂汪华曾经说过：“当互联网进入某个领域或者改造某个领域时，旧的堤坝被抹平、新的堤坝还没建起来的那一瞬间，才是创业者的机会”。但，这个时间窗口很短。

6.1.1.3 AI搜索究竟在做什么？

这个问题，做AI搜索始终是要想清楚的，每个人看法可能不一样，我就说说我的。

AI搜索，其实做的是搜索的下一步。

从功能上看，虽然叫“AI搜索”，但其实现在的AI产品，呈现出来都是搜索后“总结”的结果，这是把搜索往后做了一步。这个呈现形式 Perplexity是先行者，后面的产品都是在“借鉴”。

“搜索”本身是一个过渡性的工具，用户搜索的目的不同，其实触达的场景也应该不同，学习场景、购物场景、工作场景、生活场景、娱乐场景，都可以做的更垂直、更精细，传统搜索引擎一刀切的全用一套方式实现，的确见效快，但这也为后来各垂类内容平台瓜分搜索流浪埋下了伏笔。

既然每个场景导向的目的和要做的事情都完全不同，那么是否到了从通用搜索转向精细化垂类搜索的转型时刻呢？

Perplexity 的 CEO Aravind Srinivas 在访谈中说，“Perplexity 更像是一个知识发现引擎”，他希望这是知识的起点，所以下方会有一系列的关联问题，这是 Perplexity 留给用户继续探索的入口，这整个逻辑链条是顺的，在我看来这适合学习场景，虽然别的场景也能用，但一定是学习场景用着最顺手。

那直接照搬复刻一个 Perplexity 在国内是否行得通？行得通但现在已经太卷了，这条赛道已经塞满了人，而且论“借鉴”速度和效果，小公司肯定比不过大厂的资源。所以必须要有差异化。

秘塔的着力点目前看来聚焦在专业领域的搜索了，从他最开始就在右侧展示大纲，再到扩展出“文库”“学术”模块，以及增加了书架，也都是在朝着专业方向演进，他还有一个点是可以导出到秘塔写作猫，专业领域的搜索，下一步是写作，这个逻辑链条也是顺的。在我看来这是工作或研究场景。

所以我觉得要想清楚的是，搜索的下一步，究竟是什么？还有哪些场景能做？是用户真实场景下想要做什么，而不是我们以为的用户想要做什么。

我还想提一个老生常谈的，雷军的互联网七字诀“专注、极致、口碑、快”。

专注于必要的“最小切口”，因为资源有限，用尽量少的产品满足用户最关注的需求。但需求要有一定普遍性，这决定了产品的未来市场前景。一开始聚焦到用户的一个迫切的需求，更容易找到用户群，容易跟用户说清楚，推广也会简单，验证也更明确。“克制贪婪，少就是多”，听起来是特别显而易见的道理，但背后是对行业发展和用户需求的精准洞察，是清晰的产品和战略思路，是基于对产品力的超凡自信。

极致到自己能力的极限，做到别人做不到的高度。对专注的核心目标不惜心力、不惜代价地投入，是实现极致突破的关键。无限追求最优解，是最大的竞争优势，最优解本身往往并不在于性能指标，而是源自基于用户需求的更简化或者更集成的实现方法。

口碑既是品牌策略，也是增长策略。好产品不一定能带来口碑，便宜的产品不一定能带来口碑，又好又便宜的产品也不一定能带来口碑，只有超过预期的产品才能带来口碑。

快既是一种竞争策略，也是一个团队的底层核心能力，做产品要洞察快、决策快，面对用户的反馈时，要响应快、改善快。

6.1.2 RAG概述

6.1.2.1 RAG是什么

要说回技术了。前面说了AI搜索是目前少数大模型可落地的场景之一，那么AI搜索落地需要的核心技术，就是下面要介绍的RAG了。

RAG，全称Retrieval-Augmented Generation（检索增强生成），也就是通过外部检索来增强内容生成。RAG的最早提出是在 2020年5月，到大模型时代才开始被广泛提及。具体来说，RAG通过从外部的知识库中检索出相关的信息，然后将这些信息融合到生成的文本中，以此来弥补大模型的幻觉问题、知识更新问题。

RAG不是只用在搜索领域，准确来说，它应该是在大模型之上的基础设施层，专业知识问答、AI搜索、信息订阅推送等等，与信息提取总结相关的产品，都一定会用到RAG。

RAG的基本流程如下图：

6.1.2.2 为什么需要RAG？是否会被取代？

其实自大模型以来，RAG就不断被讨论和质疑，最开始是拿微调和RAG比，后来拿长文本和RAG比，这里我也简单分析一下。

RAG的存在，是为了解决大模型的痛点，那么它是否会被取代，就要看大模型这个痛点是否是长期存在。

第一，信息实时性问题，大模型是提前预训练出一个基础模型，用户的Query都是基于这个基础模型做推理，但是他的训练数据是存在截止日期的，导致模型对于最新事件的了解有限。

第二，幻觉问题，这是大模型的最关键的一个问题了，因为大模型本质是一个词语的概率模型，它只会从概率最大的角度来判断下一个最可能的词是什么，这是模型运行的机理导致的，就目前来看无法从模型层面完全解决。

第三，信息隐私问题，一旦数据作为训练或微调数据放进通用大模型，就一定会有概率被输出出来，这一点也是无法只从模型层面解决的。

就上面三个问题来看，RAG的确是大模型上层的不可或缺的一环。

再来说说RAG和微调，二者各有优劣势，只是分别适用于不同的场景，而且现在二者也有融合的趋势。

RAG适合于需要快速更新知识、对实时性要求不是特别高、以及对高度可解释性或准确性有要求的场景。例如，问答系统、文档生成等复杂且知识密集的任务。

微调更适合数据量较小但质量高的领域，对模型效果有较高要求且可以承担相应计算资源消耗的场景。例如，特定领域的应用，如金融领域的细分场景

再有就是长文本是否取代RAG，目前大模型的上下文长度不断扩展，那么摆在眼前的一个值得探讨的问题就是：如果可以将足够长的文档直接作为prompt输入给大模型，是否还有RAG的必要？

这个问题可以从两方面来思考：第一，根据目前的效果来看，一次性传递过长的上下文，会显著影响大模型的推理速度，而相比之下，RAG的方式是提高效率的。第二，基于 RAG 的生成可以快速定位原始参考资料，帮助用户验证生成的答案。换句话说，整个检索和推理过程是可观察的。如果仅依赖长上下文，生成的过程仍然是一个黑盒。

所以，未来的发展方向肯能是长文本与RAG结合，使其能够解决更加复杂的问题和需要阅读大量材料才能回答的整合和摘要问题。

6.1.2.3 RAG本身待解决的问题有哪些？

之所以被频繁质疑和讨论，是因为RAG技术本身也存在许多待解决的问题。

知识问答类产品可能一周就能做出演示版，但要达到好用的程度可能需要半年时间。现有的 RAG 基础流程存在许多需要优化的问题，包括检索文档内容解析错误、边缘案例处理不当、解析速度慢、知识库更新耗时长、机械分块丢失语义信息、目标检索内容召回不全、召回结果排序困难、答案生成存在遗漏等。

在澳大利亚学者Scott Barnett等人论文[20]中，总结出RAG的“七重罪”，其实这七个点，正是使用RAG的系统都会面临到的，对RAG的研究也应该focus在这些问题上

【1】Missing Content（内容缺失）

提出了无法从当前可用文档中回答的问题。比较好的情况下，RAG 系统会以类似“对不起，我不知道”之类方式来响应；然而，有些时候 LLM 会依赖自身不准确的知识来回答，可能给出错误的答案。

【2】Missed the Top Ranked Documents（检索到的 Topk 文档缺失）

问题的答案在文档中，但是检索得分不够高，无法返回给用户。考虑 LLM 支持的上下文窗口大小以及计算开销的影响，通常会选择合适的 k 值，当然，如果上下文窗口很大，不计成本，则可以使用尽量大的 k，比如 Gemini-1.5 Pro 支持数百万 Token 的上下文。

【3】Not in Context - Consolidation strategy Limitations（未在上下文中-融合策略限制）

文档从数据库中检索到了，但检索到的多个文档可能需要合并，因为融合策略的问题，答案文档并未真正的加入到 LLM 的上下文中。

【4】Not Extracted（未提取到）

问题的答案也存在于上下文中，但 LLM 没有从中正确提取答案。通常，当 LLM 的指令遵循能力比较差，或者上下文中包含太多噪音或相互矛盾的信息时容易出现这种问题。

【5】Wrong Format（错误的格式）

要求 LLM 以某种格式（例如表格、列表、JSON）提取信息，而 LLM 没有很好地遵循该要求。

【6】 Incorrect Specificity（不正确的特异性）

答案在响应中返回，但不够具体或过于具体，无法满足用户的需求。当 RAG 系统设计人员对给定问题有期望的结果时可能发生这种情况。例如针对教师对学生的场景，应该在答案中包含特定的教育内容，而不仅仅是答案；或者当用户不确定如何提问或者过于笼统时，也会发生这种问题。

【7】Incomplete（不完整）

生成的答案不是不正确，而是不够完整，即使这些信息已经在上下文中，但依然会遗漏一些。例如，“文档 A、B 和 C 中涵盖的要点是什么？”，更好的方式是分别提出这些问题。

6.1.3 RAG分类

下述的三种分类，不是并列关系，而是递进关系，后一个的出现，是为了解决前一个的缺陷，接下来分别细说。这里是Yunfan Gao等人论文[2] 的一张图，时间原因来不及重画了，先贴原图。

6.1.3.1 Naive RAG

Naive RAG 就是传统的RAG，包括索引、检索和生成阶段。

索引阶段

首先对不同格式数据进行处理（如 PDF、HTML、Word 和 Markdown），将其转换成统一的纯文本格式。随后对文本进行分割，这主要是为了适应语言模型的上下文限制。然后，这些文本块被编码成向量并存储在向量数据库中。索引阶段对于在随后的检索阶段中启用高效的相似性搜索至关重要。

检索阶段

收到用户查询后，系统会使用与索引阶段相同的模型将用户的query转换成向量，然后计算查询向量与索引语料库中块向量的相似度得分。从而优先检索与查询最相似的前K个块。这K个块就是后面被用来扩展上下文所使用的。

生成阶段

这阶段主要是将用户的query向量和选定的文档块向量转换成一个连续的提示词，传给大模型。

这个阶段看起来非常简单，搭建这样一个系统也是十分简单，但是在实践过程中，却遇到了下面这几个关键的问题。

1、在检索阶段，这个阶段的挑战主要在精确度和召回率方面，会导致选择到与query不匹配或者不相关的文档块，错过关键信息。

2、在生成阶段，由于模型存在的幻觉问题，会产生与检索回的上下文无关，甚至是错误的内容。这对输出的质量和可靠性的影响是巨大的。

3、面对复杂问题时，基于原始查询的单一检索可能不足以获取足够的上下文信息。当从多个来源检索到类似信息时，可能会遇到冗余，导致重复的响应。确定各个段落的重要性和相关性，并确保风格和语调的一致性，增加了进一步的复杂性。

6.1.3.2 Advanced RAG

Advanced RAG 是为了解决 Naive RAG 的一些限制，引入了一些改进方法。主要是通过使用前检索和后检索策略来提高检索质量。为了解决索引问题，Advanced RAG通过使用滑动窗口方法、细粒度分割和整合元数据来改进其索引技术。此外，它还采用了几种优化方法来简化检索过程。

前检索过程

在这个阶段，主要关注点是优化索引结构和原始查询。优化索引的目标是提高被索引内容的质量。这涉及策略：增强数据粒度、优化索引结构、添加元数据、对齐优化和混合检索。而查询优化的目标是使用户原始问题更清晰，更适合检索任务。常见的方法包括查询重写、查询转换、查询扩展等技术，相关的详细内容在“6.1.4.3 查询优化”进行说明。

后检索过程

在检索到相关上下文后，最重要的是要有效地将检索到的内容与查询集成。后检索过程中的主要方法包括重新排列块和上下文压缩。

重新排列就是将检索到的最相关的内容排到最前面，这个在许多框架中都已经进行了集成，比如 LlamaIndex[3]、LangChain[4]和HayStack[5] 等。

上下文压缩：将所有相关文档直接输入LLMs可能会导致信息过载，用不相关内容稀释对关键细节的关注。为了缓解这一点，后检索工作集中在选择关键信息，强调重要部分，并缩短要处理的上下文。

6.1.3.3 Modular RAG

Modular RAG 是基于传统Naive RAG和Advanced RAG技术的进一步发展，旨在通过引入更多功能模块来增强信息检索和生成能力。这种范式允许用户根据具体需求灵活配置和替换各个模块，从而提供更大的灵活性和适应性。

在 Modular RAG 中，系统被划分为多个独立的模块，每个模块负责不同的任务。例如，可以包括查询搜索引擎、融合多个回答、相似性检索等模块。这些模块可以根据特定问题上下文动态地组织和重新配置，以实现最佳的效果。

主要包括的模块如下：

（1）搜索模块：适应特定场景，使用LLM生成的代码和查询语言，能够在各种数据源（如搜索引擎、数据库和知识图谱）上直接搜索。

（2）融合模块：通过采用多查询策略来解决传统搜索限制，将用户查询扩展到不同视角，利用并行向量搜索和智能重新排列，揭示显式和转型知识。

（3）记忆模块：利用LLM的记忆引导检索，创建一个无界记忆池，通过迭代自我增强使文本更紧密地与数据分布对齐。

（4）路由模块：在RAG系统中进行路由，导航通过不同的数据源，为查询选择最佳路径，无论是涉及摘要、特定数据库搜索还是合并不同的信息流。

（5）预测模块：旨在通过直接通过LLM生成上下文来减少冗余和噪声，确保相关性和准确性[13]。最后，任务适配器模块使RAG适应各种下游任务，自动化提示检索用于零样本输入，并通过少样本查询生成创建任务特定的检索器。

Modular RAG 可以看做是一个多功能的工具箱，支持根据需要更换或调整工具来应对不同的问题。相比于 Native RAG 要灵活得多。通过添加新工具或改变现有工具的配合方式，进一步增强了它的适应能力，让它在处理各种任务时更加得心应手。

6.1.4 检索阶段

因为RAG依赖外部知识来增强LLMs的能力，所以数据源会严重影响最终生成的结果。在数据源的检索上，主要需要关注的内容包括：检索源、检索粒度、检索前处理以及相应嵌入模型的选择。

6.1.4.1 检索源

检索源主要要关注数据结构和检索的粒度。检索源最开始多是文本，目前已经逐渐扩展到其他半结构化数据和结构化数据。

检索源的数据结构

数据结构主要包括非结构化数据、半结构化数据、结构化数据。最初，文本是主流的检索来源。随后，检索源扩展到包括半结构化数据（如PDF）和结构化数据（如知识图谱、KG）以增强检索。

另外，除了从原始外部源检索外，还有越来越多的研究倾向于使用由LLMs自身生成的内容进行检索和增强。

【1】非结构化数据

非结构化数据比如文本，是最常用的检索来源，主要从语料库中收集。对于开放域问答任务，主要的检索来源是维基百科。除了百科全书式的数据外，常见的未结构化数据还包括跨语言文本和特定领域的数据。

【2】半结构化数据

通常指包含文本和表格信息的组合，如PDF。处理半结构化数据是相对困难的，主要包括文本分割带来的数据损坏；引入表格数据带来的搜索复杂化。

处理半结构化数据目前主要有两种方法：第一种方法是利用大模型的编码能力，在数据库执行Text-2-SQL查询，例如TableGPT [6]。第二种方法是基于文本的方法将表格转换为文本格式进行进一步分析 [7]。目前这两种方法都不是最优解决方案，这个方向还存在大量的研究机会。

【3】结构化数据

结构化的数据可以提供更精准的信息，比如知识图谱（KGs）[8]

例如， KnowledGPT [9]生成“KB”搜索查询并将知识存储在个性化的数据库中，增强了RAG模型的知识丰富性。G-Retriever [10]集成了图神经网络（GNNs）、LLMs和RAG，通过软提示LLM增强了图理解力和问答能力，并使用奖赏收集斯坦纳树（PCST）优化问题进行有针对性的图检索，这主要是为了应对LLMs在理解和回答有关文本图的问题方面的限制。

构建结构化数据库的确在结果质量上有很大的优势，但是，构建和维护结构化数据库也需要耗费更多的成本。

检索粒度

检索粒度针对不同类型的数据，也有不同的粒度。粒度的粗细对结果的影响也是不同的，粗粒度可以提供更多相关信息，但同时也带来了更多冗余信息。细粒度会增加检索负担，同时不能保证能够保证语义完整性需要的全部知识。

在文本中，检索粒度从细到粗，包括Token、Phrase、Sentence、Proposition、Chunks、Document。

在知识图谱（KG）上，检索粒度包括Entity、Triplet和sub-Graph。检索的粒度也可以适应下游任务，例如在推荐任务中检索Item IDs和Sentence pairs。

6.1.4.2 索引优化

索引阶段的主要工作是：将文档处理分割，并转换为向量，存储在向量数据库中。索引构建的质量决定了检索阶段能否获得正确的上下文。常见的索引优化策略主要包括：

分块策略

最常用的方法是根据固定数量的token将文档分割成块。但块的大小对效果

较大的块可以捕获更多上下文，但它们也会产生更多噪声，需要更长的处理时间和更高的成本。而较小的块可能无法完全传达所需的上下文，但它们的噪声较少。

针对块会把句子截断这个问题，目前的方法是递归分割和滑动窗口方法，通过多层检索合并全局相关信息[11]。但这个方法无法无法在语义完整性和上下文长度之间找到平衡。因此，提出了Small2Big等方法，其中句子（小）用作检索单元，前面的和后面的句子作为（大）上下文提供给LLMs[12]。

元数据附加

可以再每个文档块增加一些元数据，比如页码、文件名、作者、类别、时间戳等。这样，检索可以根据此元数据进行过滤，限制检索范围。

比如，为时间戳分配不同的权重，就可以对知识的新鲜度进行控制，从而避免过时的信息。

元数据信息除了从文档中提取，还可以人为构建。例如，添加段落摘要，以及引入假设问题。这种方法也称为Reverse HyDE。具体来说，使用LLM生成可以由文档回答的问题，然后在检索期间计算原始问题和假设问题之间的相似度，以减少问题和答案之间的语义差距。

结构化索引

通过对文档建立分层结构，来增强信息检索的效果。

分层索引结构

让文件通过父子关系进行排列，通过块链接来找到他们。每个节点中都存储数据的摘要，这有助于快速遍历数据，从而让系统可以确定要提取哪些文档块。同时，这种方法还能够减少因为提取问题产生的幻觉。

知识图谱索引

更进一步，还可以利用知识图谱构建文档的分层结构，这种方式更有助于保持一致性。知识图谱中描绘了不同概念和实体之间的联系，能够降低幻觉。这种方式的另一个优势在于，可以将信息检索过程转换为LLM可以理解的指令，从而进一步提高检索的准确性。

KGP[13]提出了一种使用KG在多个文档之间构建索引的方法，可以更好的捕捉文档和结构之间的逻辑关系。具体来说，KG由节点（代表文档中的段落或结构，如页面和表格）和边（表示段落之间或文档结构内的语义/词汇相似性）组成，有效地解决了多文档环境中的知识检索和推理问题。

6.1.4.3 查询优化

Naive RAG 面临的一个主要挑战是它直接依赖用户原始查询作为检索的基础。制定一个精确而清晰的问题很困难，轻率的问题导致检索效果不佳。有时问题本身很复杂，语言组织得不好。另一个困难在于语言的复杂性和歧义性。语言模型通常难以处理专业词汇或具有多种含义的模糊缩写。例如，它们可能无法辨别“LLM”是指大型语言模型还是法律背景下的法学硕士。

查询扩展

查询扩展就是将单个查询扩展为多个查询，这样主要能够保证生成的答案的最优相关性。具体实现上，包括多查询、子查询、连锁验证(CoVe)。

1. 多查询。通过使用提示工程通过LLMs扩展查询，然后可以并行执行这些查询。查询的扩展不是随机的，而是经过精心设计的。

2. 子查询。子问题计划的过程代表了生成必要的子问题以在组合时对原始问题进行上下文化和完全回答的过程。这种添加相关上下文的过程，在原则上与查询扩展类似。具体来说，可以使用最少到最多的提示方法[92]将复杂问题分解为一系列更简单的子问题。

3. 连锁验证(CoVe)。扩展的查询经过LLM的验证，以实现减少幻觉的效果。经过验证的扩展查询通常表现出更高的可靠性。

查询转换

查询转换是说，根据转换后的查询而不是用户的原始查询检索块。主要包括查询重写和查询路由两个方面

查询重写：现实世界中用户的查询输入不一定是最优的，所以，对查询进行重写有助于提升结果质量。最简单的方式是通过LLM对查询进行重写。也可以用专门的小模型对查询进行重写，比如RRR（Rewrite-retrieve-read）[14]

以下还有一些查询重写的实现方式：

淘宝的BEQUE[15]实施了查询重写方法，显著提高了长尾查询的召回效果，从而提高了GMV。另一种查询转换方法是使用提示工程让LLM根据原始查询生成查询，以供后续检索使用。

HyDE[17]构建假设文档（假定是对原始查询的答案）。它侧重于答案与答案之间的嵌入相似性，而不是寻找问题或查询的嵌入相似性。

使用Step-back Prompting方[16]，将原始查询抽象为生成高层次概念问题（回溯问题）。在RAG系统中，回溯问题和原始查询都用于检索，并且两个结果都用作语言模型生成答案的基础。

查询路由

根据不同的查询，路由到不同的RAG管道，这适合于为适应多样化场景而设计的多功能RAG系统。目前有以下几种方式：

元数据路由器/过滤器：第一步涉及从查询中提取关键词（实体），然后根据关键词和块中的元数据进行过滤，以缩小搜索范围。

语义路由器是另一种路由方法，它利用查询的语义信息。特定方法见语义路由器。

也可以采用混合路由方法，结合语义和基于元数据的方法来增强查询路由。

6.1.5 生成阶段

在检索之后，直接将所有检索到的信息输入到LLM进行问题回答并不是一个好的做法。如果输入给大模型过多的冗余信息，会干扰大模型最终的生成效果。因此，在RAG系统中，我们通常需要对检索到的内容进行进一步处理。主要包括对文档块的重排序和文本压缩。

6.1.5.1 对文档块重新排序

把最相关的结果突出出来，这样的设计既作为增强器又作为过滤器，可以为模型提供更精准的输入[18]。重新排序目前主要有两种方法，基于规则或基于模型。基于规则一般采用预定义的指标，主要考虑多样性、相关性和MRR。基于模型可以采用专门用于排序的模型（比如Cohere rerank或bge-raranker-large）或者通用大语言模型。

6.1.5.2 文本选择和压缩

在RAG过程中，不一定文本越长越好，多长的上下文反倒会引入更多噪声，降低大模型对关键信息的感知。

LLMLingua使用小型语言模型如GPT-2 Small或LLaMA-7B，检测并移除不重要的标记，将其转换为一种对人类来说难以理解但对LLMs却很好地理解的形式。这种方法无需对LLMs进行额外训练，同时平衡了语言完整性和压缩比。PRCA通过训练一个信息提取器来解决这个问题。同样，RECOMP采用相似的方法，通过对比学习训练一个信息压缩器。每个训练数据点包括一个正面样本和五个负面样本，编码器在这个过程中使用对比损失进行训练。除了压缩上下文外，减少文档的数量也有助于提高模型答案的准确性。

Ma等人论[19]中，提出了一种“过滤器-重新排序器”范式，这种模式结合了大模型和小模型各自的优势，小模型作为过滤器，大模型用于重新排序。研究表明，指示LLMs重新排列SLMs识别出的具有挑战性的样本，可以在各种信息提取（IE）任务中取得显著改进。

还有一种方法可以用于提升最终生成的内容的质量：先通过LLM来评估检索到的内容，然后再生成最终答案。

6.1.6 RAG 能力增强

在有些情况下，只进行一次检索-生成，对于复杂问题是不够的，所以，目前很多研究在尝试用多次检索的方式来优化最终效果

6.1.6.1 迭代检索

迭代检索是基于初始查询和多次查询的所有文本，重复搜索知识库，为大语言模型提供更全面的知识输入。

迭代检索其核心思想是在生成答案的过程中，通过多次重复进行检索和生成的过程，逐步提高生成内容的质量和准确性。

具体来说，迭代检索涉及以下几个步骤：

()初始查询：首先，基于用户的原始问题或输入，系统会进行一次初步的检索操作，从知识库中获取相关信息。

生成回答：利用从知识库中检索到的信息，结合大语言模型（LLM）的能力，生成一个初步的回答。

反馈与改进：生成的回答会被用来改进后续的查询。例如，如果生成的回答存在不足之处，可以利用这些不足来构建更精确的查询，以便在下一轮检索中获得更有针对性的信息。

重复循环：上述过程不断重复，每次迭代都会根据当前生成的内容来优化下一次的检索查询，并利用新检索到的信息来改进生成的内容，直到满足预设的标准或条件为止。

这种迭代方式的优势在于能够逐步丰富和细化生成内容的上下文信息，从而提高生成结果的鲁棒性和准确性。例如，在需要多步推理的复杂任务中，通过多次迭代可以更好地整合分散在不同文档中的信息，避免因单次检索而遗漏重要细节。

此外，迭代检索还可以帮助缓解大模型在生成过程中可能出现的“幻觉”问题，即生成不准确或无关的信息。通过不断更新和优化检索查询，可以确保生成内容更加符合实际情况和用户需求

6.1.6.2 递归检索

递归检索通过多次迭代和逐步细化的方式，目的是提升文档检索的准确性和生成答案的质量。

它从原始文档节点开始，逐步扩展出更多粒度更小的文档节点，从而在最终生成答案时能够更加精确地捕捉到相关信息。

具体来说，递归检索分为两个主要步骤：初始检索和后续扩展。在初始阶段，系统会从大规模的知识库中检索出与查询内容相关的初步文档块。这些文档块可能包含关键语义信息，但不一定完全符合需求。随后，在后续阶段，系统会对这些初步结果进行重写和扩展，捕获更多的上下文信息，并提供给语言模型以生成更丰富的回答。

这种两步检索方法不仅提高了检索的准确性，还平衡了效率和丰富度之间的关系。例如，LlamaIndex库就展示了如何利用递归检索来实现高效的文档检索和生成。

6.1.6.3 自适应检索

在传统的RAG系统中，通常会先从大量数据源中检索相关信息，然后将这些信息作为上下文输入到大语言模型（LLM）中进行生成。然而，这种方法并不总是最优的，因为过度依赖外部信息可能会导致生成结果的质量下降，尤其是在模型本身已经具备足够参数化知识的情况下。

自适应检索的核心思想是根据问题的复杂性和查询的具体需求动态调整检索策略，以达到最佳的生成效果和计算效率。

自适应检索通过动态选择最合适的检索时机和内容来解决这一问题。例如，对于简单的问题，可以直接由模型自身回答；而对于复杂的问题，则需要依赖RAG进行更深入的信息检索和筛选。此外，自适应检索还可以根据问题的频率和复杂度进行优化，允许模型直接回答高频率问题，并对低频率问题引入RAG。

自适应检索的一个关键优势在于它能够平衡计算效率与答复质量。与传统的单步或多步检索方法相比，自适应检索能够在简单和复杂查询之间实现有效的平衡，从而提高整体系统的性能。例如，Adaptive-RAG可以根据查询复杂度动态调整策略，真正贴合实际应用需求。

总之，自适应检索通过灵活调整检索策略，不仅提升了生成效果，还提高了系统的效率和实用性。

写在最后

本节是RAG系列的一个开篇，篇幅原因，里面涉及的技术点还没有详细展开，后续会再单独对其中的关键技术点深入写。

参考文献

[1] Lewis P, Perez E, Piktus A, et al. Retrieval-augmented generation for knowledge-intensive nlp tasks[J]. Advances in Neural Information Processing Systems, 2020, 33: 9459-9474.

[2] Gao Y, Xiong Y, Gao X, et al. Retrieval-augmented generation for large language models: A survey[J]. arXiv preprint arXiv:2312.10997, 2023.

[3] https://www.llamaindex.ai

[4] https://www.langchain.com/

[5] V. Blagojevi, “Enhancing rag pipelines in haystack: Introducing diversityranker and lostinthemiddleranker,” https://towardsdatascience.com/enhancing-rag-pipelines-in-haystack-45f14e2bc9f5, 2023.

[6] L. Zha, J. Zhou, L. Li, R. Wang, Q. Huang, S. Yang, J. Yuan, C. Su, X. Li, A. Su et al., “Tablegpt: Towards unifying tables, nature language and commands into one gpt,” arXiv preprint arXiv:2307.08674, 2023.

[7] Z. Luo, C. Xu, P. Zhao, X. Geng, C. Tao, J. Ma, Q. Lin, and D. Jiang, “Augmented large language models with parametric knowledge guiding,” arXiv:2305.04757, 2023.

[8] M. Gaur, K. Gunaratna, V. Srinivasan, and H. Jin, “Iseeq: Information seeking question generation using dynamic meta-information retrieval and knowledge graphs,” in Proceedings of the AAAI Conference on Artificial Intelligence, vol. 36, no. 10, 2022, pp. 10 672–10 680.

[9] X. Wang, Q. Yang, Y. Qiu, J. Liang, Q. He, Z. Gu, Y. Xiao, and W. Wang, “Knowledgpt: Enhancing large language models with retrieval and storage access on knowledge bases,” arXiv preprint arXiv:2308.11761, 2023.

[10] X. He, Y. Tian, Y. Sun, N. V. Chawla, T. Laurent, Y. LeCun, X. Bresson, and B. Hooi, “G-retriever: Retrieval-augmented generation for textual graph understanding and question answering,” arXiv preprint arXiv:2402.07630, 2024.

[11] Langchain, “Recursively split by character,” https://python.langchain.com/v0.1/docs/modules/data_connection/document_transformers/recursive_text_splitter/ 2023.

[12] S. Yang, “Advanced rag 01: Small-tobig retrieval,” https://towardsdatascience.com/advanced-rag-01-small-to-big-retrieval-172181b396d4 2023.

[14] X. Ma, Y. Gong, P. He, H. Zhao, and N. Duan, “Query rewriting for retrieval-augmented large language models,” arXiv preprint arXiv:2305.14283, 2023.

[15] W. Peng, G. Li, Y. Jiang, Z. Wang, D. Ou, X. Zeng, E. Chen et al., “Large language model based long-tail query rewriting in taobao search,” arXiv preprint arXiv:2311.03758, 2023.

[16] H. S. Zheng, S. Mishra, X. Chen, H.-T. Cheng, E. H. Chi, Q. V. Le, and D. Zhou, “Take a step back: Evoking reasoning via abstraction in large language models,” arXiv preprint arXiv:2310.06117, 2023.

[17] L. Gao, X. Ma, J. Lin, and J. Callan, “Precise zero-shot dense retrieval without relevance labels,” arXiv preprint arXiv:2212.10496, 2022.

[18] S. Zhuang, B. Liu, B. Koopman, and G. Zuccon, “Open-source large language models are strong zero-shot query likelihood models for document ranking,” arXiv preprint arXiv:2310.13243, 2023.

[19] Y. Ma, Y. Cao, Y. Hong, and A. Sun, “Large language model is not a good few-shot information extractor, but a good reranker for hard samples!” ArXiv, vol. abs/2303.08559, 2023. [Online]. Available: https://api.semanticscholar.org/CorpusID:257532405

[20] Scott Barnett, Stefanus Kurniawan, Srikanth Thudumu, Zach Brannelly, Mohamed Abdelrazek, “Seven Failure Points When Engineering a Retrieval Augmented Generation System,” arXiv preprint arXiv:2401.05856, 2024.