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型曲线”对位于文档开头和结尾的信息提取效果很好但如果关键信息藏在中间模型往往会像“眼瞎”了一样忽略掉。这样一来如果文档太长关键信息在中间就更容易被忽略了。所以我们选择切块说起切块其实策略有很多比如固定大小切块egchunkSize 300 overlap 0、重叠分块egchunkSize 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 是一个大学问。