浅入理解RAG

RAG—检索增强生成

• 先从外部知识库中检索（Retrieval） 出和用户问题相关的资料
• 把检索到的资料作为增强（Augmented） 上下文，和用户的问题一起给到大模型
• 大模型基于这些真实的资料来生成（Generation） 回答

 让大模型基于真实、可更新的知识来回答问题的技术方案。它和微调、Prompt Engineering 等技术是互补的，而不是替代关系。

 

索引阶段（离线）：文档加载→文档切割→文本向量化→存入向量数据库

查询阶段（在线）：用户提问→问题向量化→向量检索→构造增强Prompt→大模型生成回答

 

 

 

RAG可靠性流程

0.问题分类  (Adaptive RAG)

做什么：由前置小模型来对问题初步分类，简单问题无需走RAG复杂检索生成链路

目的： 合理分类，提高响应效率，减轻RAG处理压力。

 

 

1.预处理 (QueryRewrite)    

做什么：

模型rewrite，将用户问题改写成正式/标准语句（适用于普通用户客服，电商等场景）；

HyDE，让模型预生成一个答案，再用答案的向量检索（适用于LLM熟悉的领域，可预生成答案，不适用于冷门知识）；

多角度改写，同一个提问扩展成3-5个表述分别检索，再将检索结果合并。

 

目的：减少由于用户提问口语化，用词不准确，或缺少上下文导致向量检命中率低。

 

2.多路召回 (向量检索+BM25检索)

做什么：向量检索+BM25检索并行跑，再用RRF算法合并排序

目的：单一向量检索容易对专词失真，单一BM25检索无法语义匹配

 

3.重排序(Rerank)

做什么：将检索结果和用户问题再一起喂给大模型进行判断匹配程度，重新打分排序

目的：提高排序准确性，提高召回质量，减少噪音

 

(Corrective RAG流程)

将检索到的结果交给LLM挨个打分，判断结果质量。

质量高的直接将结果喂给大模型进行下一步，

质量低的说明知识库中不存在该问题，走降级处理，通过web网络搜索

 

 

4.Prompt拼装

做什么：强调根据资料回答，不要自由发挥；鼓励承认不确定，回答诚实，避免误导

目的：提高模型回答精准度，减少幻觉

 

 

5.模型生成，质量检查，结果溯源

做什么：让大模型回答结果标注出资料出处；让模型自我审视，判断答案是否与问题正相关？答案是否依赖于知识库？答案是否能满足用户需求？

目的：便于追踪，参考原始文档，验证答案

 

 

扩展：

GraphRAG：  答案散落在多个文档chunk中，GraphRAG将散落文档关联成知识图谱，再基于图谱推理和检索。成本较高

Text-to-SQL RAG：  结构化表格类数据，直接通过Text-to-SQL RAG来处理，将用户问题转化为sql脚本执行查询。 需要注意sql注入等安全问题。

Agentic RAG ： AI Agent 来自动调度，根据问题自主决定每一步该怎么做，使用什么工具，检索什么内容。核心是 Agent Loop 循环。

多模态 RAG：  处理图表、流程图、架构图、产品照片等多模态数据。多模态 RAG 的做法是把图片、表格和文本统一到一个向量空间里，这样检索时就能跨模态匹配。

 

 

 

 

 

RAG切分

切的太大会导致检索精确度降低，消耗token。

切的太小会导致上下语义丢失。

 

0.基于字符串长度和token切分    会破坏语义

1.基于标点符号的—降级递归切分    按双换行符，单换行符，句号，逗号层级进行切分，最大限度保留语义。

2.引入重叠窗口    切分的chunk2的开头和chunk1的末尾重叠10%，尽量避免语义割裂

3. 父子块切分  大段落存redis，小段落存向量库       先切分大段落，存入redis，并记录大段落id—parentId。 再将大段落切分成小段落，写入向量库，并关联parentId。  当检索时，先找向量库匹配到小段落，再根据parentId匹配redis中大段落作为最终结果。

4.语义切分   先将文档按标点句子切分，再对每个句子进行 Embedding 计算，计算相邻句子的相似度，相似度高语义相近合并成一个chunk。

5.LLM切分   基于LLM智能切分，token消耗量高，效率低。

 

 

元数据注入

在切分环节，可增加元数据注入，例如文档标题，章节名，页码，时间等拼在切片前，使chunk具有完整全局语义。

 

 

Re-rank  重排序

正常检索阶段使用Embedding 模型，计算query语句和chunk的向量相似度。由于信息压缩损失(大量文字压缩成一串向量)，缺乏用户意图感知(chunk提前计算好)，导致这种方式匹配度不高。

 

Re-rank 使用的是 Cross-Encoder（交叉编码器）

把查询和文档拼在一起，让模型同时匹配两者，进行深度的交互分析。  缺点是效率过低，token消耗大

 

最佳实践：两阶段检索

第一阶段用 Bi-Encoder（向量检索）快速从全部文档中筛出 Top-50 或 Top-100 候选文档，这一步追求的是速度和召回率，宁可多捞一些，不能漏掉相关的。

第二阶段再用 Cross-Encoder（Re-rank）对这 50-100 个候选文档做精细化重排序，获取Top5-10。

 

 

向量数据库核心原理

核心思路是用空间换时间，通过提前构建索引结构，让检索的时候不需要遍历所有向量。

 

三种索引

HNSW： 多层导航

IVF：先分区，分桶，再检索

PQ： 压缩存储

 

 

多路召回

向量检索，单路召回具有局限性。适用于语义相近的检索，不适用于精准匹配。

（用户搜索「iPhone 15 Pro Max 256GB」，结果向量检索把「iPhone 14 Pro Max 512GB」也搜出来了）

 

多路检索召回策略：
1.向量检索  通过embedding模型将文本转成稠密向量，通过相似度搜索来召回，擅长语义匹配。

2.关键词检索/BM25  基于词频，文档频率计算相关性。

 

各路召回的结果需要合并去重，并按综合相关性排序。融合的方法有很多，最常用的是 RRF（倒数排名融合），根据chunk在不同召回路中的排名来评判

具体流程：

1. 用户提问后，同时发起两路检索：

• 向量检索：把问题转成向量，在向量数据库中搜索 Top-K 个相似文档
• BM25 检索：把问题分词后，在倒排索引中搜索 Top-K 个相关文档

2. 用 RRF 算法合并两路结果，得到综合排序
3. （可选）对合并后的结果做 Re-rank 精排
4. 取最终 Top-N 个文档送入大模型

 

 

 

RAG评估

RAG召回质量与生成质量评估指标

一、召回质量评估指标

1. 召回率（Recall）
- 衡量：找得全不全
- 定义：相关文档中被成功召回的比例
- 关注点：有无遗漏关键信息

2. 精确率（Precision）
- 衡量：找得对不对
- 定义：召回结果中正确文档的占比
- 关注点：返回的文档是否相关

3. 排序质量（Ordering / Ranking）
- 衡量：排得合不合理
- 定义：高度相关文档是否排在前面
- 常见指标：MRR、NDCG、Hit Rate

二、LLM生成结果质量指标

1. 忠实度（Faithfulness）
- 衡量：是否忠于召回文档
- 定义：生成内容有无编造、捏造事实
- 关注点：幻觉（Hallucination）程度

2. 答案相关性（Answer Relevance）
- 衡量：是否正面回答用户问题
- 定义：生成内容切题程度，有无跑题
- 关注点：回答是否解决用户需求

3. 上下文相关性（Context Relevance）
- 衡量：召回的上下文是否被有效利用
- 定义：生成内容与召回文档的关联紧密程度
- 关注点：模型是否忽略了关键上下文或引入了无关内容

 

 

 

降低大模型幻觉的关键

 所谓幻觉（Hallucination），简单来说就是大模型自信地说出一些听起来很专业但实际上是编造的内容。

 

产生原因：

1.训练数据中可能包含错误信息、偏见或过时的知识。或者不存在的专业/定制化知识。

2.大模型的训练目标是「预测下一个 token」，它追求的是生成流畅、连贯的文本，而不是确保每句话都是正确的。

3.用户提示词诱导幻觉

 

降低幻觉方式：

1.RAG  让大模型有答案可依据

2.Prompt工程约束   限定知识范围，防止随意编造； 要求标注来源，让回答有依据，也方便追溯校验； 鼓励承认不确定，避免误导； 让LLM先给出思考过程，确保思考没问题再生成。

3.对模型输出验证   用另一个模型交叉验证；用规则引擎验证关键数据；同一问题多次回答验证；

4.领域微调   如果发现模型在某个特定领域（比如医疗、法律、金融）的幻觉率特别高，可以考虑用高质量的领域数据对模型进行微调。

 

 

• 第一道防线：Prompt 工程约束。零成本、立即生效，所有场景都应该做。
• 第二道防线：RAG 检索增强。中等成本，提供事实依据，是需要准确知识的场景的标配。
• 第三道防线：输出验证。额外增加延迟和成本，但在高风险场景（医疗、法律、金融）中不可或缺。
• 第四道防线：领域微调 + 不确定性量化。成本最高，但在特定领域效果最好，适合对准确性要求极高的场景。

 

 

 

 

 

RAG—更新知识库

监听文档更新  —>  构建chunk 

1.监听文档更新：  

方式一：定时轮询执行

方式二：文档更新通知策略

根据文档最后更新时间初步筛选。 根据文档摘要计算内容hash值，比较hash是否变更。

 

2.构建chunk

全删全插，不可局部更新chunk  (由于文档更新后chunk切分的边界会变化，不可对chunk进行单独更新)

先删除文档对应的所有旧chunk，再新增文档对应的所有新chunk。 

 

 

灰度发布

可先不删除旧chunk，将旧chunk和新chunk分别标记为新、旧。

检索时根据配置按照新chunk检索，出现问题可回滚至旧chunk检索。

验证无误再删掉旧chunk。