Amadeus的知识库 | 传统检索不懂语义？大模型知识有限？—— RAG检索增强生成来帮忙！

一、引文

相信大家在网上冲浪时经常会听到 RAG 这个专业名词，在去年的一段时间内 RAG 这个概念爆火，许多企业都尝试使用 RAG 技术来搭建内部知识库，一些电商平台也会借此来搭建一个智能客服。那么 RAG 到底是什么呢，它跟大模型有什么联系，又跟我们传统的检索有什么区别，看完这一篇博客你将会了解 RAG 技术的大致链路以及每个节点需要注意的细节，接着你就可以去找个 RAG 项目，吃透之后便可以作为你和面试官畅谈 RAG 技术实现的资本。

二、大模型的局限性

1.幻觉

“幻觉”（Hallucination）是指模型生成了看似合理、语法正确，但实际上事实错误、无意义或与现实不符的内容，简单来说就是在一本正经地胡说八道。常见表现如下：

• 事实错误：模型虚构了一个不存在的历史事件、人物生平或科学定律。例如，问它“1996年奥运会男足冠军是谁”，它可能自信地回答一个错误的国家。

• 虚假引用：模型编造论文标题、书籍、法律条文或代码库。你让它列出某领域的参考文献，它给出的链接和书名看起来非常专业，但搜索后发现根本不存在。

• 逻辑矛盾：在长文本生成中，模型前后的逻辑不一致，或者推导过程完全错误。

• 指令偏离：模型完全忽略了用户的约束条件，生成了与要求无关的内容。

大模型之所以产生幻觉，一个是由于它那“概率预测机”的本质决定的，它并不知道什么是“真理”，只是一味追求文本在统计学上的“流畅性”和“合理性”。当然其中的原因还有很多，比如说大模型预训练数据时的数据虚拟与现实交织，RLHF 强化学习训练也有一定影响，可能会养成迎合人类喜好的习惯，即便靠它原有的知识不具备回答问题的能力也会编造答案硬答。不过大模型的幻觉倒也不全是坏处，在一些文学创作领域中，这种“瞎扯”的能力也可以被视作一种创造力。但在一些严肃领域，如医疗、法律、金融等场景下，大模型的幻觉是万万不能的。

2.知识时效性

我们知道大模型是需要通过海量数据进行预训练的，而它所接收的训练数据一定是在某个时间点以前的，过了那个时间点再发生的事情，它是不知道的。如果问它近期的事件，它可能会根据旧数据生拉硬拽，这其实也算大模型幻觉的一大诱因。

3.知识来源的不可信

在我们知道了大模型的幻觉问题后，其实难免会对它给出的回答产生质疑。而大模型的回答又不可追溯其源泉，也就没有了验证和追责的依据了。

4.私有场景的尴尬

我们知道大模型预训练数据都是网上公开的数据，如果说你想问他一些企业内部的数据，它是不知道的。

三、传统检索的困境

看到了上面大模型的局限性，我们可能会想到使用传统检索来代替，因为传统检索没有幻觉，如果知识更新了那就同步到数据库就行，想追溯知识来源也只是往表里面加个字段的事情，私有数据也可以存到数据库里面。

可是传统检索有一个最大的弊端，那就是它无法理解语义。如果用户问了一个问题，传统检索只能按照模糊匹配的方式进行检索，一旦用户换了个问法可能就哑火了（具体可以参照本专栏讲 if-else 和传统 NLP的那篇）。

四、RAG应运而生

综合考虑大模型和传统检索的局限性，我们就可以想到把二者结合起来，这样一来我们的 RAG 就诞生了。

1.简介

RAG (Retrieval-Augmented Generation，检索增强生成)是一种将强大的信息检索 (Information Retrieval, IR)技术与生成式大语言模型 (LLM)相结合的框架。

RAG 的核心思想是：在让 LLM 回答问题或生成文本之前，先从一个大规模的知识库（如数据库、文档集合）中检索出相关的上下文信息，然后将这些信息与原始问题一并提供给 LLM，从而“增强”其生成能力，使其能够产出更准确、更具时效性、更符合特定领域知识的回答。

2.核心流程

RAG 的核心流程大致可以分为六步，文档导入解析清洗 -> 把文档分块 -> 块状文档向量化 -> 建立向量数据库索引 -> 把用户问题向量化后拿到库里面去检索 -> 最后依据找到的文档拼凑上下文回答。

（1）导入

第一步通常是把你建立知识库需要的文档导入到你的后端代码里面，然后你的后端代码才能对文档进行分块。不过分块操作一般是建立在对纯文本进行分块，所以在这中间还需要对文档进行解析。用户上传的文档格式可能千奇百怪，PDF、Markdown、Word等等，我们需要先把他们解析成纯文档。除此之外可能还需要对一些噪声进行清洗处理，比如说一些无意义的页眉页脚、广告、乱码等。如果涉及到图片，里面传递的信息还需要使用 OCR 之类的技术进行提取。

（2）切块

拿到文档的纯文本后要对其进行切块，首先我们先搞清楚为什么非进行切块不可。要知道我们最后是要拿着用户问题去库里面找能提供答案的文档拼凑上下文的，如果不切块相当于每次大模型都拿着整个文档的文本作为上下文去回答用户问题。一来大模型的上下文窗口是有限的，如果这个文档太长可能塞不进去，如果擅自截断导致跟答案相关的关键内容丢失，反而大模型无法正确回答用户问题。即便塞得进去整个文档，但其实这么一大篇文档真正和答案相关的只有一小部分，其他的片段噪声太大可能影响生成的答案质量，而且据研究发现大模型存在 “Lost in the Middle” 现象，简言之模型的性能呈现出一条“U型曲线”：对位于文档开头和结尾的信息提取效果很好，但如果关键信息藏在中间，模型往往会像“眼瞎”了一样忽略掉。这样一来如果文档太长，关键信息在中间就更容易被忽略了。所以我们选择切块！

说起切块其实策略有很多，比如固定大小切块（eg：chunkSize = 300 overlap = 0）、重叠分块（eg：chunkSize = 300 overlap = 50）、递归分块（先尝试用最大的分隔符切，切完如果某个块还是太大，就换一个更小的分隔符继续切，直到所有块都在 chunkSize 以内。）、语义分块（先把文本按句子进行划开，如果两个句子的向量相似度较低，说明语义发生明显转折可以在此切分）、混合分块（多种策略结合，如递归 + 语义）。

注意：在切块之后，向量化之前我们还可以对每个文档快进行元数据标记，也就是记录它的来源、权限、位置等信息，便于大模型对它的回答标记引用文档，有效避免幻觉问题和进行知识来源的追溯。

（3）向量化

文档切块之后，我们要使用 Embedding 模型将文本转为高维向量，需要注意选用的 Embedding 模型必须和检索时的模型一致。这一步也是 RAG 流程的关键节点，为什么在检索的时候大模型拿着用户问题知道去找哪个知识库的哪个文档的哪个部分呢，其实就是把用户问题和文档都向量化，计算它们的向量相似度得出的，这也是它区分传统检索理解语义的关键。

（4）索引

索引这步就是把文档转换得到的向量存到专门的向量数据库里面，因为向量数据库与传统的数据库不同，它不仅能够存储海量的向量，而且还可以提供强大的向量相似度检索能力，其内部提供的IVF、HNSW等索引算法能够帮你快速定位到用户问题向量相似的多个文档块向量。

（5）检索

这一步就是把用户问题用相同的 Embedding 模型转换成向量，拿着这个向量去向量数据库搜索与它相似的几个文档块向量。

（6）回答

这一步就是把搜索到的文档块向量和用户问题向量对应的文档打包发送给大模型，拼凑上下文，然后大模型基于上下文回答问题。

3.RAG适用场景

最近在网上也经常刷到 RAG 技术过时的说法，该观点持有者的一大理由就是当下的通用Coding Agent现在已经摒弃了 RAG 技术，转而走文件系统索引 + AST语法树解析，比如OpenClaw的代码助手直接读取整个项目的文件结构、分析函数调用关系，比把代码切成块转向量检索的准确率高几个量级，根本不会出现传统 RAG 乱匹配上下文的问题。

现象是对的，但由此而生的观点却不正确。技术选型从来都只是看场景，从来没有什么技术会突然“完全过失”。这种现象传递出的信号只是在通用Coding Agent场景下，传统的向量检索 RAG 被更适合代码的检索方案替代了而已。但只要是涉及到私有场景，RAG 还是刚需，比如公司内部自研的框架、私有组件的文档、历史遗留项目的知识沉淀，这些模型预训练见都没见过的内容，还是得靠 RAG 或者知识库检索来注入。

五、总结

经过本篇文章的讲解，相信大家对 RAG 的诞生原因以及它的大致链路有了一定了解。但 RAG 可不是仅此而已，上面我只是对六大节点的大致过程进行了一个概述，补充了一点点细节，但每个节点其实都还有很多要下的苦功夫。除去那六大节点，我们可能还得考虑诸如文档具体怎么解析、用户问题口语化怎么进行重写增强检索效果、多轮对话怎么实现、用户一个问题多个意图怎么对其进行拆分、大模型又怎么识别用户意图再做相应操作、纯向量检索效果不好怎么搭配其他类型的检索进行优化、数据检索时的鉴权怎么实现，还有重排序、会话记忆、引导澄清、效果监控等等诸多问题。如果大家真的想搞好 RAG，最好的方式就是去开源社区找个优秀的 RAG 项目，结合 AI 弄清它的全链路逻辑，而不是止步于跑个 demo。相信大家在这个实践过程中就会明白 RAG 是一个大学问。