完整题目
为什么在大模型应用中引入检索增强生成（RAG）？在哪些具体场景下，RAG相比纯监督微调（SFT）更具优势？
本文目录
为什么引入RAG
RAG的核心价值是解耦知识存储与模型参数，解决大模型固有缺陷：
- 知识时效性：模型参数冻结后无法感知新知识，RAG通过实时检索外部库解决
- 幻觉问题：生成内容可溯源到检索文档，大幅降低"一本正经胡说八道"
- 训练成本：SFT需要重新训练模型，RAG只需更新知识库，边际成本极低
- 可解释性：能展示"参考了哪些资料"，满足合规审计需求
RAG vs SFT 的适用边界
| 维度 | RAG更适合 | SFT更适合 |
|---|---|---|
| 知识特性 | 频繁更新、领域专精 | 通用能力、长期稳定 |
| 数据规模 | 海量文档（TB级） | 高质量指令对（万级） |
| 响应形式 | 需要引用来源 | 需要风格/人格化 |
| 延迟要求 | 可接受百毫秒级检索 | 极致低延迟 |
RAG更具优势的具体场景
1. 动态知识场景
- 金融政策解读、医药说明书查询、客服知识库——知识每天更新，SFT追不上
2. 长尾专业领域
- 法律条文检索、企业内部文档问答——训练数据稀缺，但文档库完整
3. 高可信要求的问答
- 医疗诊断辅助、投资分析报告——必须给出参考依据，不能"脑补"
4. 多租户隔离场景
- SaaS服务不同企业客户——各客户数据隔离在各自知识库，同一模型服务多方
一句话总结
RAG用"查资料"替代"背知识"，在知识动态、来源重要、成本敏感的场景下，是比SFT更灵活的工程选择。两者并非互斥，实践中常先RAG打底，再SFT优化生成风格。
学习建议
掌握RAG与SFT的基本原理，对比其在知识更新、数据隐私和推理可解释性方面的差异，结合实际应用场景理解优势。
换一种问法，检查是否真正理解
场景切入
假设你正在做企业客服系统，客户每天咨询的产品政策经常更新，比如促销规则、退换货条款。你是选择定期微调模型，还是用RAG？为什么？
层层追问
你怎么看大模型的幻觉问题？……常用的缓解方法有哪些？……那RAG和SFT在这上面有什么本质区别？……什么时候你宁愿用RAG而不是花精力做SFT？
直球架构
请你对比RAG和纯SFT，从知识更新、幻觉控制、训练成本、可解释性四个维度讲一下各自优劣，并给出RAG明显占优的两种具体场景。
练习口述回答 · 约4分钟
- 问题本质：模型知识来源的取舍
- RAG优势：解耦存储，低成本应对动态知识
- RAG vs SFT边界：知识更新 vs 风格固化
- 具体场景：金融政策、客服退款、企业合规
- 落地风险：检索质量决定上限，需混合检索+重排
- 收尾：RAG打底+SFT优化，非互斥
这道题其实问的是：在模型的知识来源上，我们是让模型把知识记在脑子里，还是给它配一本随时能翻的书？本质是知识存储与模型参数要不要解耦的问题。
先说为什么引入[[RAG]]。最核心的原因就是，模型参数一旦训完就冻住了，新知识进不来，而且模型会自己编造内容，也就是[[Hallucination]]。RAG的思路很简单，我不指望你背下所有知识，我给你一个外部知识库，你遇到问题先去查，查到了再回答。这样知识更新只需要改数据库，不用重新训练模型，成本低得多，而且回答能溯源到具体文档，可信度高。
那RAG和[[SFT]]的边界在哪呢？我的理解是，RAG擅长处理频繁变化的知识，SFT擅长固化模型的表达风格和行为模式。举个例子，一个电商客服场景，满减政策可能每周调整，如果用SFT，每次政策变动都得收集数据重新微调，根本来不及；用RAG，直接把最新政策文档丢进知识库，模型检索后回答，当天就能生效。反过来，如果希望客服的语气更亲切、更符合品牌调性，那就适合用SFT去固化这种风格，因为风格是长期稳定的。
具体到场景，我重点说两个。第一个是金融政策解读，比如央行突然发了一个新规，RAG能立刻把新规文档索引进去，用户问“房贷利率怎么调”，模型检索后给出带原文引用的回答。第二个是企业内部SOP与合规文档查询，不同部门、不同版本的文件堆在一起，员工问“报销流程”，RAG能精准定位到最新版SOP，并且告诉你是第几章第几条。
但这里有个坑，RAG的效果上限取决于检索质量。如果知识库里的文档切分太粗糙，或者[[Embedding]]模型选得不好，检索出来的内容驴唇不对马嘴，那模型再强也白搭。常见失败场景是：用户问的问题很口语化，比如“我上次买的那个耳机坏了咋办”，但知识库里全是“售后政策2024版”这种正式标题，检索召回率很低。我的做法是，上线前一定要做[[Hybrid Search]]，把[[BM25]]关键词检索和向量检索结合起来，再配合[[Rerank]]，把最相关的片段顶到前面。
另外说一个我特别关注的点：当知识库频繁更新时，[[Vector Database]]的增量索引和一致性怎么保证？比如客服知识库每天有几百条修改，你不能每次重建索引，但增量插入又可能让检索精度下降。我倾向于用双索引策略，一个base索引定期全量重建，一个delta索引处理实时增量，查询时合并结果，再按时间戳去重。
所以整体来看，我不会把RAG和SFT对立起来。真实落地往往是RAG打底，保证知识最新、来源可查，然后再用SFT优化生成风格和指令遵循能力。我更倾向于把RAG看作一个低成本、高灵活性的知识接入方案，而SFT是锦上添花的人格化打磨。