RAG、微调还是长上下文:如何选型?
面试第一道开篇题,常以「为什么不直接微调/把文档塞进 prompt,要用 RAG?」起手,本质是问**「什么场景该用什么知识注入方式」。三者不互斥**,而是互补:RAG 负责「外部可更新知识」,微调负责「行为/风格/领域语感」,长上下文负责「一次性给定的少量材料」。本篇讲面试答法;RAG 流水线见 RAG 与检索增强,微调底座见 LoRA 低秩适配与微调,上下文预算见 Token 计算与成本。
一句话答法
RAG = 知识随时变、需溯源;微调 = 改变行为/输出风格/固化知识;长上下文 = 一次性、量不大、要逐字引。 三者经常组合:RAG 拉知识 + 微调调行为 + 长窗口做"装得下"的兜底。
核心差异对比
| 维度 | RAG | 微调(Fine-tuning / LoRA) | 长上下文(Long Context) |
|---|---|---|---|
| 本质 | 检索 + 拼接上下文 | 改模型参数,固化进权重 | 一次性塞进 prompt |
| 知识更新 | 改索引即可,分钟级 | 要重训,小时~天级,旧权重作废 | 改 prompt,即时 |
| 成本 | 向量化+检索算力,边际低 | 训练算力贵;数据准备贵 | 推理 token 贵,长度平方增长 |
| 溯源/可解释 | 强:能给出引用片段 | 弱:答对答错难归因 | 强:原文就在 prompt |
| 幻觉风险 | 中:受检索质量左右 | 低-中:训练过则答得稳 | 中-高:模型仍会"忽略"中间段 |
| 典型场景 | 客服 KB、政策手册、企业 wiki | 风格统一、领域术语、复杂指令遵循 | 单文档摘要、长报告分析、代码库阅读 |
| 失效模式 | 召不回/召错段 → 答非所问 | 灾难性遗忘、过拟合、训练-推理漂移 | 上下文"中间丢失"、成本爆炸、延迟 |
面试话术:先答"为什么不全用 RAG / 全用微调",再答"什么时候用哪个",最后答"经常组合"。
选型决策树
你到底想解决什么?
│
├─ 知识会变 / 要可溯源 / 量很大(>模型上下文)
│ → RAG(必要时叠 Hybrid + Rerank)
│
├─ 想改"模型怎么回答"而不是"答什么"
│ ├─ 风格/语气/格式统一 → 微调(LoRA 即可)
│ ├─ 复杂指令遵循/工具用法固化 → 微调
│ └─ 领域专有输出结构(法律条款、医学报告)→ 微调 + RAG 拉事实
│
├─ 一次性任务、量不大(几篇报告/一个 PR),要逐字引用
│ → 长上下文(配合结构化提示)
│
└─ 既要最新知识,又要稳定风格
→ RAG(知识) + 微调(行为),几乎不直接靠长上下文
三个常被追问的"为什么"
1. 为什么不直接微调,把知识全学进去?
| 理由 | 解释 |
|---|---|
| 知识会变 | 产品文档每天改、政策每月更新,重训频率跟不上 |
| 学不进也学不好 | LLM 对"事实型"知识记忆不稳定,参数容量被行为/语感占满,再灌事实容易灾难性遗忘 |
| 可解释性 | 出错时 RAG 能定位"哪一段召错了",微调只能"再训一遍试试" |
| 合规/审计 | 金融、医疗要"答的依据是什么",RAG 给引用,微调给不出 |
| 冷启动数据 | 高质量问答对少;RAG 只需要文档,微调要 QA pair / SFT 数据 |
一句话: 知识进 RAG,行为进微调。把"答什么"和"怎么答"分开治理。
2. 为什么不把文档全塞进长上下文?
| 理由 | 解释 |
|---|---|
| 成本 | 长上下文按 token 收,百万 token 一次调用可以烧掉几美元;RAG 只送 top-k 几段 |
| 延迟 | attention 近似算法虽好,百万级仍慢,长尾 P95 不可控 |
| "中间丢失" | Lost-in-the-Middle 现象:模型对首尾记得清,中间段容易被忽略 |
| 检索精度 | top-k 检索是"显式挑过",长上下文是"全堆上去",噪声多 |
| 更新成本 | 改一处要重传整个 bundle,RAG 只改索引 |
但长上下文有它的"专属阵地":
- 单文档/少量文档的逐字引用、跨段总结("总结这份 200 页合同的所有违约条款")
- 代码库整体阅读、PR diff 评审
- 多模态长视频/长音频理解
- 一次性 PoC、不想搭检索
3. 为什么不直接全用 RAG?
RAG 也不是银弹:
| 场景 | RAG 不擅长的点 |
|---|---|
| 强格式/强风格 | "请按本公司口吻回复",靠检索片段学不到语气 |
| 跨文档归纳 | "整个知识库讲哪几个主题" → GraphRAG 或长上下文 |
| 私域术语/代号 | 没进索引就查不到;微调可让模型"知道"这些术语 |
| 工具调用规范 | 工具 schema 多、要选对,RAG 拉文档不如微调"内化" |
实战组合(高区分度答法)
大多数生产系统不是单选,而是叠加:
┌──────────── RAG(知识随时变/要溯源)────────────┐
│ │
用户问题 ── 路由 ─┼─ 微调过的 LLM(行为/风格/工具用法已固化) ── 输出 │
│ │
└──── 长上下文(本轮一次性的少量材料) ────────────┘
| 组合 | 典型产品 |
|---|---|
| RAG + 微调 | 企业客服(知识库 + 统一话术);代码助手(私有代码检索 + 编码风格微调) |
| RAG + 长上下文 | 文档问答(召回 5~10 段 + 完整 PDF 长窗口兜底) |
| RAG + 微调 + 长上下文 | 复杂 Agent(检索 + 行为风格 + 单文档细读) |
面试加分点: 主动说"我不会先选 RAG 或微调,而是先看知识更新频率和答错能不能溯源。可溯源 + 常变 → RAG;行为风格 → 微调;一次性的 → 长上下文。三者经常同时用。"
关键指标怎么选(配套考量)
| 方案 | 关键指标 |
|---|---|
| RAG | 检索 Recall@k、MRR、faithfulness、拒答率 —— 见 如何优化 RAG 检索效果、AI 应用测试与效果评估 |
| 微调 | 训练 loss / 验证 loss / 风格一致性评分 / 任务通过率;警惕灾难性遗忘(用通用 benchmark 复测) |
| 长上下文 | 大海捞针(needle-in-a-haystack)、位置偏差、首尾命中率;单请求成本 |
没有"哪种最好",只有"哪种在该业务约束下成本-质量-可控性最划算"。
常见误区(踩雷点)
| 误区 | 解释 |
|---|---|
| "微调万能,把知识学进去" | 事实型知识参数化不稳健;更新成本高,容易答非所问还难溯源 |
| "长上下文能替代 RAG" | 贵、慢、有"中间丢失";一次任务可以,常态化服务不行 |
| "RAG 一定比微调新/先进" | 解决不同问题;RAG 补知识、微调补行为,目标不同 |
| "三者只能选一个" | 现代系统几乎都是组合拳;面试官想听你说明组合的边界 |
| "Embedding 越好 RAG 越好" | 召回只解决"找得到",精排、chunk、prompt 同样关键;别忽略评测闭环 |
面试速记
- 本质区分: RAG 答"答什么",微调答"怎么答",长上下文答"这一份怎么用"。
- 决策顺序: 知识更新频率 → 要不要溯源 → 输出风格是否统一 → 一次性 vs 常态化。
- 组合优于单选: 客服 = RAG(知识) + 微调(话术);文档问答 = RAG + 长上下文兜底。
- 成本敏感: 长上下文按 token 收费,RAG 按检索算力收费,微调按训练算力+数据标注收费——三套账分开算。
- 反问加分: "这套知识多久变一次?""要溯源吗?""风格必须统一吗?"——拿这三个问题做开场,比直接给答案更显成熟。
答题模板(可背)
这个问题本质是"知识注入方式选型",我会先按 知识更新频率 × 是否需要溯源 × 输出风格一致性 三个维度切。 知识高频变、要溯源 → RAG,代表场景是政策问答、客服 KB; 想改"怎么回答"而不是"答什么"——风格、复杂指令、工具用法 → 微调(一般 LoRA 起步); 一次性的少量材料、要逐字引用 → 长上下文,比如单文档总结、PR 评审。 真正生产系统几乎都是 RAG + 微调 或 RAG + 长上下文 组合,极少单选。 还要注意成本:长上下文按 token 收费,百万 token 单次很贵;微调要数据+算力+迭代;RAG 边际成本低但要持续维护索引。
参考链接
| 主题 | 链接 |
|---|---|
| RAG 流水线 | RAG 与检索增强 |
| RAG 检索优化 | 如何优化 RAG 检索效果 |
| LoRA 微调 | LoRA 低秩适配与微调 |
| 上下文预算 | Token 计算与成本 |
| 框架选型 | RAG 与框架选型 |
| GraphRAG(跨文档) | GraphRAG 概览与查询 |
| 评测闭环 | AI 应用测试与效果评估 |