RAG检索增强生成：从"能用"到"好用"，中间差了五个关键环节

上一篇讲了RAG知识库构建，这篇接着聊——知识库建好了，RAG就一定能用吗？远远不够。 从用户提问到大模型回答，中间还有路由、检索、重排序、生成、后处理五个环节，每个环节做不好，最终效果都会翻车。这篇文章把我对RAG检索增强生成的理解写清楚，全是实战中想明白的逻辑。

---

一、Query路由：问题都走错门了，后面全白搭

用户问一个问题，RAG系统第一步不是去检索，而是判断该去哪个知识库找答案。这就是Query路由。

以银行为例，至少有6类知识库：

知识库	存什么
账户类	余额、交易记录、还款等私有信息
产品类	信用卡、贷款、理财产品介绍
流程规则类	挂失、换卡、开卡的办理流程
公告通知类	系统维护、利率调整等公告
FAQ类	客服电话、网点地址等高频问题
公开搜索引擎	外部新闻、舆情、行业对比

用户问题	应路由到	为什么
"银行卡里还有多少钱"	账户类	查余额，需要访问账户数据
"适合年轻人的理财产品"	产品类	产品推荐
"卡丢了怎么挂失"	流程规则类	操作流程
"上周是不是系统维护了"	公告通知类	历史公告
"客服电话多少"	FAQ类	通用高频问题
"你们是不是又被央视点名了"	公开搜索引擎	舆情，内部库没有

我的观点：Query路由是RAG系统的"第一道门"，走错了后面全白费。 很多人抱怨RAG效果差，其实是路由没做好——用户问信用卡问题，系统却去查了房贷知识库，能找对才怪。

---

二、检索：两种思路，各有所长

2.1 倒排索引：关键词精准匹配

倒排索引就是提前建好"词→文档"的映射表，搜索时直接查索引，不用遍历所有文档。

假设3篇文档：

• ID1: "我喜欢吃苹果"
• ID2: "我不喜欢吃梨"
• ID3: "苹果和梨都是水果"

倒排索引长这样：

关键词	包含该词的文档
苹果	[ID1, ID3]
梨	[ID2, ID3]
水果	[ID3]

用户搜"苹果"，直接命中ID1和ID3，不用读全文。速度快、精准，但不理解语义——搜"怎么退钱"找不到"退款流程"。

2.2 结构化数据检索：自然语言转SQL

用户问："我3月份用招商银行信用卡消费最多的是哪一笔？"

RAG不是去文档里翻，而是把自然语言转成SQL：

SELECT merchant, amount, date FROM transactions WHERE card_type = '招商银行信用卡' AND date >= '2024-03-01' AND date < '2024-04-01' ORDER BY amount DESC LIMIT 1;

关键认知：不是所有问题都该走语义检索。 查余额、查订单、查交易记录——这些是结构化数据查询，走SQL远比向量检索精准。

---

三、Reranker：检索的"二审法官"

关键词检索匹配词，向量检索理解意图，但两者都会召回一些不相关的内容。Reranker的职责是对召回结果重新打分排序，把最相关的推到最前面。

用户问："信用卡最低还款怎么算？是不是每次都能只还一点？"

关键词检索召回Top3：

1. ✅ 最低还款额通常为账单的10%，部分银行为5%
2. ✅ 只还最低还款，剩余金额按日计息，年化约18%
3. ❌ 信用卡挂失后，应尽快致电客服申请补卡

向量语义检索召回Top3：

1. ✅ 最低还款适用于暂时无法全额还款的客户，但会收取利息
2. ⚠️ 还款额不足最低还款会影响征信
3. ✅ 最低还款额通常为账单的10%

Reranker重排序后：

片段	得分	说明
最低还款额通常为账单的10%	0.91	直接回答核心问题
只还最低会产生利息	0.89	补充关键信息
最低还款不享受免息	0.86	补充关键信息
未按最低还款可能影响征信	0.63	相关但非核心
信用卡挂失……	0.18	无关，排到最后

我的理解：关键词+向量是"广撒网"，Reranker是"精选"。 没有Reranker，大模型可能被无关内容干扰，生成质量不稳定。

---

四、生成：别让大模型"自由发挥"

检索到的内容塞进Prompt，送给大模型生成回答。但生成不是随意的，需要明确的规则约束：

核心规则

规则	说明	举例
准确简洁	直接回答核心问题	❌ "关于您的问题，我们经过详细分析……" ✅ "VIP用户积分不会过期"
不编造	文档没有就说不知道	❌ "您的信用额度是5万" ✅ "文档中未提及您的信用额度"
说人话	避免术语堆砌	❌ "依据条款3.2.1之规定" ✅ "按照规则，您可以……"
不承诺	不得说"保证收益""一定到账"	涉及风险内容要加免责声明
可溯源	标注信息来源	"具体请查看《会员积分说明》第3节"

Prompt模板

【用户问题】: {{用户的原始提问}} 
【上下文文档片段】: 
1. {{知识片段1}} 
2. {{知识片段2}} 
3. ...

大模型基于这些片段生成回答，而不是凭记忆——这就是RAG降低幻觉的核心机制。

---

五、后处理：回答生成后的三道保险

5.1 缓存——让RAG更快更便宜

把问过的题目和答案存下来，下次有人问同样的问题直接返回结果，跳过检索+生成。

效果	数据
响应速度	从5秒降到0.1秒
成本	省掉大模型调用费
一致性	同样问题同样答案

但缓存有时效性：

知识类型	缓存时长
静态知识（百科、产品介绍）	30~90天
促销活动规则	7天
物流状态	不缓存或5分钟

我的经验：缓存策略要根据业务场景定，不是越长越好。 促销活动过期了还在返回缓存的旧答案，比没有缓存更糟糕。

5.2 脱敏——合规的硬要求

大模型输出后，自动识别并替换敏感字段：

类型	原始	脱敏后
姓名	张三	张*
身份证号	420101199001012233	420101********2233
手机号	13888889999	138********9999
银行卡号	622700******1234	尾号1234

这是产品经理要定规则、技术来实现的环节。 哪些字段必须脱敏、脱到什么程度，不是技术问题，是业务决策。

5.3 评估——RAG效果怎么量化？

白盒评估：逐环节拆解打分

用户提问环节：

很多RAG失败不是模型问题，而是用户问题太模糊——"我想看看那个东西发票的事儿"。这种情况需要查询重写或追问确认。

检索环节指标：

指标	衡量什么	类比
Precision@k	找回来的里有几个是对的？	抓了5个人，有几个真是小偷？
Recall@k	该找的有没有找回来？	丢了钥匙，翻了5个地方，有没有翻对？

举个例子：知识库中有10条正确片段，检索出5条，其中3条正确、2条无关：

• Precision = 3/5 = 60%
• Recall = 3/10 = 30%

我的体会：检索环节Recall比Precision更重要。 找回来一些无关的（Precision低），Reranker还能补救；但该找的没找到（Recall低），大模型再强也编不出来。

生成环节指标：

指标	评估什么
F1 Score	是否答对了关键词/核心事实
幻觉率	生成内容是否超出检索文档的范围
可读性	语言是否自然流畅

场景化评估：不同场景，标准不同

通用维度： 准确性、完整性、清晰度、可溯源、安全合规

医疗场景——额外关注：

• 安全性：必须加"仅供参考，不能代替医生诊疗意见"
• 完整性：不能只说"多喝水"，要包含"何时该去医院"

电商客服——额外关注：

• 挽留能力：不能直接"推走用户"
• 情绪稳定：有耐心、有安抚

	不合格	合格
用户想退货	"我们无法处理，请您找快递"	"我们来协助您联系快递公司，同时可以为您加急退款或提供优惠券补偿"

---

六、微调 vs RAG vs Prompt：怎么选？

这是做AI产品最常被问到的问题。先看一个类比：

方法	类比
RAG	考试带小抄，边查边答
微调	改了大脑，变得能做之前做不到的事
Prompt	提醒自己"用某种口气说话"

维度对比

维度	RAG	微调	Prompt
知识来源	外部知识库，实时检索	模型内部记忆	模型已有知识
要不要训练	❌ 不训练	✅ 要训练	❌ 不训练
更新频率	知识库一改就生效	训练后静态，更新需重训	改Prompt就行
成本	低	高	最低

场景选择

任务类型	推荐方法	为什么
问政策、查手册、答更新文档	RAG	外部知识需求高，行为改动需求低
控车、调灯、设备指令	微调	行为改动需求高，泛化模型理解不了
改语气、改格式	Prompt	简单调整，不需要训练

我的建议：能不做微调就不做微调，能用RAG先验证效果。 绝大部分公司搞不起微调——没有标注数据、没有高性能显卡、没有训练部署经验。先用RAG+通用模型快速上线原型，效果不够再针对性微调。

RAG降低幻觉的原理

模型	机制	风险
纯微调模型	基于训练参数"记忆"回答	可能编造，脱离实际
RAG模型	先检索真实文档，再基于文档生成	有据可依，幻觉显著降低

用户问："如何申请公积金贷款？需要什么材料？"

• 微调模型："请携带身份证、户口本和结婚证前往柜台"——听起来对，其实可能不需要结婚证
• RAG模型：先检索贷款指南文件，再引用内容回答——来源明确，准确率高

当然，高精度场景可以RAG+微调配合使用，不是非此即彼。

四个微调的典型场景

1. 准确率要求极高的生产级应用（医疗、法律、金融）——微调让模型"考取专业证书"
2. 定制独特风格/语气/结构——电商客服必须礼貌、有情绪缓冲
3. 处理边缘案例或冷门问题——老旧设备报错、少数民族语义，泛化模型没见过
4. 大模型压缩成小模型——用GPT-4生成数据训练7B小模型，降低部署成本

---

七、一个容易被忽视的坑：索引字段设置

在Coze等平台上配置结构化数据检索时，只有被设为索引的字段才会参与匹配，其他字段查不到。

比如产品表：

产品名称	品牌	型号	售价	售后政策
空气炸锅	美的	MZ-230	399元	7天无理由，保1年
电热水壶	九阳	JY-K123	199元	只换不修1年

如果只设"产品名称"为索引字段：

• "MZ-230的售后怎么处理？" → ❌ 查不到（型号不在索引中）
• "九阳的电热水壶退货流程？" → ❌ 查不到（品牌不在索引中）
• "399那个锅能换吗？" → ❌ 查不到（价格不在索引中）

我的提醒：索引字段的选择直接决定检索的覆盖范围。 在配置时要站在用户的角度想——用户会用什么方式来问？把可能被问到的字段都纳入索引。

---

写在最后

RAG从"能用"到"好用"，我总结了一个完整链路的检查清单：

环节	关键动作	翻车后果
Query路由	判断该去哪个知识库	走错门，后面全白费
检索	关键词+向量混合检索	该找的没找到
Reranker	对召回结果重新打分排序	无关内容干扰大模型
生成	用规则约束大模型输出	编造、跑题、不合规
缓存	按业务场景设时效	过期信息仍在返回
脱敏	自动替换敏感字段	隐私泄露、合规风险
评估	逐环节量化指标	无法定位问题在哪

RAG系统的效果，从来不取决于最强的那个环节，而是最弱的那个。 把每个环节都做到位，系统才能真正从"能用"变成"好用"。

如果非要排一个优先级：检索质量（路由+召回）> 生成质量（规则+约束）> 后处理（缓存+脱敏）。因为检索是源头，源头错了后面再怎么补都是空。