RAG 和 Fine-tuning 的核心区别

前言：这道题最容易掉进“二选一”的坑

面试官问：RAG 和微调有什么区别？很多人的第一反应是：RAG 是查知识库，微调是训练模型。这个回答没错，但不够。真正能拉开差距的回答，是能说清楚它们分别解决哪一层问题、成本在哪里、什么时候组合使用。

答：RAG 解决“说什么”，微调解决“怎么说”。RAG 不改模型参数，在推理时把外部知识检索出来；微调会用样本训练模型，让它形成更稳定的输出习惯、任务能力或行业表达。

1. 一个改参数，一个查资料

LLM 的知识本来就有两部分：一部分藏在模型参数里，来自预训练；另一部分可以来自外部知识库，在回答时临时注入。微调是把训练样本的规律写进模型参数或适配器；RAG 是把最新、私有、可追溯的资料放在外部索引中，按需检索。

所以，微调不是万能“知识灌输器”，RAG 也不是万能“准确率按钮”。微调更适合稳定行为，RAG 更适合动态知识。

2. 微调适合什么？让模型形成稳定行为

微调的核心价值，是让模型在某类任务上表现得更稳定。比如你希望模型永远返回固定 JSON 字段，客服回复永远保持某种语气，合同条款抽取永远按统一标签输出，或者分类任务总是遵循你定义的边界。

这类问题靠 Prompt 也能做，但当示例太多、格式太严格、线上输入变化太大时，Prompt 会变长、变脆弱。微调可以把大量示例训练进去，让模型少依赖长提示词，输出更一致。

微调更适合这些场景

固定输出格式：例如每次必须返回 JSON、必须包含固定字段、不能多说废话。

固定语气和风格：例如金融客服、医疗助手、企业内部机器人需要统一话术。

特定任务行为：例如分类、抽取、纠错、转写、风控标签判断。

低延迟高并发：如果 RAG 检索链路太重，而知识相对稳定，可以用微调减少长 Prompt。

3. RAG 适合什么？让模型回答时查到正确资料

RAG 的核心价值，是把知识从模型参数里解耦出来。产品文档、内部制度、公告、客服 FAQ、数据库记录都可以放进知识库。用户提问时，系统先检索相关资料，再把这些资料作为上下文交给模型生成答案。

这带来三个直接好处：知识更新快、答案能溯源、错误好定位。文档错了改文档，Chunk 切错了调切分，召回不准就调检索，而不是重新训练整个模型。

RAG 更适合这些场景

知识变化频繁：政策、价格、库存、产品手册、业务规则经常更新。

需要来源引用：答案必须能追到具体文档、段落、时间和版本。

私有知识问答：知识不在模型训练数据里，但存在企业文档或数据库里。

权限敏感：不同用户只能看到不同文档，RAG 可以在检索层做权限过滤。

4. 对比表：别问哪个更强，要问问题属于哪一层

选型时不要从“我喜欢哪个技术”出发，而要从业务问题出发。下面这张表可以直接放到方案评审里用。

5. 最容易踩的坑：把 RAG 和微调用反

很多项目失败，不是因为技术本身不行，而是把问题归因错了。知识库问答效果差，第一反应去微调模型；输出格式不稳定，第一反应堆更多文档进向量库。这都会越调越乱。

判断方法很简单：如果模型明明拿到了正确资料却表达不稳定，偏向微调或结构化输出；如果模型表达很流畅但事实不对，先看 RAG 检索有没有把正确资料找回来。

6. 选型决策树：先问知识，再问行为

实际工程里可以按下面顺序判断：第一，看知识是不是经常变；第二，看是否需要追溯来源；第三，看输出格式和语气是否稳定；第四，看团队有没有训练数据和训练能力。

7. 成本不是只有钱，还有迭代速度和排错成本

微调的成本主要在训练前：准备数据、清洗标注、训练、评测、上线回滚。RAG 的成本主要在运行时：检索、重排、Prompt 拼装、向量库维护、权限过滤。

如果知识一天变好几次，用微调会被迭代拖死；如果任务固定、知识稳定、并发很高，微调可以减少长 Prompt 和检索链路。

8. 最常见的生产组合：微调解决“怎么说”，RAG 解决“说什么”

企业知识库问答最常见的不是二选一，而是组合：用 RAG 检索制度、产品、工单、FAQ 等具体事实；用微调或少样本示例，让模型学会企业话术、拒答边界、JSON 格式和任务风格。

这套组合尤其适合客服、法律、金融、医疗、售后、知识库助手：事实必须来自最新资料，但表达又必须稳定、专业、合规。

9. 代码示例：一个最小 RAG 流程

下面代码不是截图，而是可复制的代码格式。它展示的是最小化思路：先检索，再把证据塞进 Prompt，最后让模型只基于证据回答。

def answer_with_rag(question: str):
# 1. 将问题转成向量
query_vector = embed(question)
# 2. 从向量库召回相关文档片段
chunks = vector_store.search(
vector=query_vector,
top_k=5,
filters={"permission": "current_user"}
)
# 3. 组装上下文
context = "\n\n".join([c.text for c in chunks])
# 4. 让模型只基于检索内容回答
prompt = f"""
你是企业知识库助手。
只能根据【参考资料】回答。
如果资料不足，直接说“当前资料无法确认”。
【参考资料】
{context}
【用户问题】
{question}
"""
return llm.generate(prompt)

10. 代码示例：微调数据长什么样

微调数据重点不是堆文档，而是给模型看“正确输入应该对应怎样的输出”。如果你想让模型稳定抽取字段，训练样本就应该围绕输入/输出对来组织。

{"messages":[
{"role":"system","content":"你是合同条款抽取助手，只输出 JSON。"},
{"role":"user","content":"乙方应在收到发票后30日内付款，逾期每日按万分之五支付违约金。"},
{"role":"assistant","content":"{\"付款期限\":\"30日\",\"违约金\":\"每日万分之五\"}"}
]}
{"messages":[
{"role":"system","content":"你是合同条款抽取助手，只输出 JSON。"},
{"role":"user","content":"甲方有权在提前15日书面通知后解除本合同。"},
{"role":"assistant","content":"{\"解除权主体\":\"甲方\",\"通知期限\":\"15日\"}"}
]}

11. 代码示例：工程里可以这样做选型判断

真实项目不会靠口号选型，可以把需求拆成几个维度，让团队先形成统一判断。

def choose_strategy(requirement):
if requirement.needs_fresh_private_knowledge or requirement.needs_citation:
if requirement.needs_strict_format_or_tone:
return "RAG + Fine-tuning"
return "RAG"
if requirement.needs_strict_format_or_tone or requirement.is_repetitive_task:
if requirement.has_high_quality_training_examples:
return "Fine-tuning"
return "Prompt / Few-shot first"
return "Prompt first, then evaluate whether RAG or Fine-tuning is needed"

12. 评测：RAG 和微调要看不同指标

RAG 答错时，先看检索有没有找对资料；微调答错时，先看样本有没有教对模型。把两者用同一套指标评测，很容易误判。

13. 知识更新：为什么动态知识优先 RAG

企业文档有一个现实问题：它们不是静态的。产品价格变、政策变、库存变、合同模板变、内部流程变。如果把这些高频变化的事实都塞进微调，就会陷入“数据一变就训练”的死循环。

14. 生产上线清单：能跑 Demo 不等于能上线

RAG 和微调都不是“一次性配置”。上线之后要持续看数据、看日志、看评测、看异常问题。尤其是 RAG，必须记录每次回答使用了哪些 chunk；微调模型也要监控格式失败、越权回答和安全边界。

15. 面试怎么答：三段式最稳

这道题的高分回答，不是背概念，而是体现工程判断。可以按“本质区别、适用场景、组合落地”来回答。

结语：RAG 和微调不是替代关系，而是分工关系

RAG 让模型查到正确资料，微调让模型以正确方式做事。知识经常变、需要引用来源，用 RAG；输出行为要稳定、格式要统一、语气要一致，用微调；企业级场景通常两者结合。

真正成熟的系统，不会纠结“哪个更强”，而是把知识层、行为层、评测层、监控层拆开设计。这样才能做到既准确，又可维护，还能持续迭代。