核心差异：外部知识 vs 内化知识
RAG 和微调本质上是两种不同的知识注入方式。RAG 通过检索外部知识库为模型提供上下文，模型在推理时"查阅资料"回答问题；微调则通过梯度更新将知识"内化"到模型参数中。
# RAG：推理时检索
def rag_inference(query):
docs = vector_store.search(query, k=5)
prompt = f"基于以下文档回答：\n{docs}\n\n问题：{query}"
return llm.generate(prompt)
# 微调：知识已内化在参数中
def finetuned_inference(query):
return finetuned_llm.generate(query) # 无需外部检索
RAG 的核心优势
1. 实时性
RAG 的知识库可以实时更新。当文档变更时，只需更新向量数据库，无需重新训练模型：
# 知识更新：只需重新嵌入文档
new_doc = load_document("updated_policy.pdf")
embedding = embed_model.encode(new_doc)
vector_store.upsert(embedding, metadata={"source": "policy_v2"})
# 微调更新知识：需要重新训练
# 数据准备 → 训练 → 评估 → 部署（数小时到数天）
2. 可追溯性
RAG 的每个回答都能追溯到具体文档来源，这对企业合规和审计至关重要：
response = rag_pipeline.query("公司的退款政策是什么？")
print(response.answer) # "退款政策规定..."
print(response.sources) # [{"doc": "policy.pdf", "page": 3, "score": 0.92}]
3. 低成本
| 维度 | RAG | 微调 |
|---|---|---|
| 初始成本 | 向量数据库 + 嵌入模型 | GPU 训练 + 数据标注 |
| 更新成本 | 重新嵌入变更文档 | 重新训练（全量或增量） |
| 推理成本 | 增加检索延迟 + Token 消耗 | 与基座模型持平 |
| 人力成本 | 文档维护 | 数据工程 + 训练调优 |
微调的核心优势
1. 风格与格式控制
微调能改变模型的输出风格、语气和格式，RAG 做不到这点：
# 微调可以让模型学会特定风格
# 例如：法律文书的严谨表述、客服话术的统一格式
{"input": "用户说想退货", "output": "尊敬的客户您好，请您提供订单编号..."}
2. 领域深度
对于高度专业化的领域（医学、法律、金融），微调能让模型理解术语和推理模式：
# 医学微调数据示例
{
"instruction": "分析以下病历，给出鉴别诊断",
"input": "患者女，45岁，间歇性头痛3个月...",
"output": "鉴别诊断考虑：1. 偏头痛 2. 紧张性头痛..."
}
3. 低推理延迟
微调模型无需检索步骤，单次前向传播即出结果，延迟显著低于 RAG：
RAG 延迟 = 检索(50-200ms) + 上下文构建 + LLM 推理(500-2000ms)
微调延迟 = LLM 推理(500-2000ms)
决策矩阵
| 场景特征 | 推荐方案 | 理由 |
|---|---|---|
| 知识频繁更新 | RAG | 只需更新向量库 |
| 知识稳定不变 | 微调 | 内化后推理更快 |
| 需要来源追溯 | RAG | 检索结果可引用 |
| 需要特定输出风格 | 微调 | RAG 无法改变模型风格 |
| 领域术语密集 | 微调+RAG | 先微调理解力，再RAG供知识 |
| 低延迟要求 | 微调 | 无检索开销 |
| 长尾知识覆盖 | RAG | 扩展知识库即可 |
| 少样本快速启动 | RAG | 无需训练数据 |
| 高频重复问答 | 微调 | 避免每次检索相同内容 |
| 多语言/跨语言 | RAG | 知识库可多语言 |
混合方案：RAG + 微调
生产环境中，纯 RAG 或纯微调往往不够，混合方案才是最优解：
┌─────────────────────────────────────────────┐
│ 混合架构 │
│ │
│ ┌──────────┐ ┌──────────────────────┐ │
│ │ 微调模型 │────▶│ RAG 检索增强 │ │
│ │ (领域理解) │ │ (实时知识) │ │
│ └──────────┘ └──────────────────────┘ │
│ │ │ │
│ └──────────┬───────────┘ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 最终回答 │ │
│ └──────────────┘ │
└─────────────────────────────────────────────┘
class HybridPipeline:
def __init__(self):
self.model = FineTunedModel("domain_model_v2") # 领域微调
self.rag = RAGPipeline(vector_store) # RAG 检索
def query(self, question: str):
# 1. 用微调模型理解问题（领域术语映射）
rewritten = self.model.rewrite_query(question)
# 2. RAG 检索相关知识
docs = self.rag.retrieve(rewritten, k=5)
# 3. 微调模型 + 检索上下文生成回答
answer = self.model.generate(
question, context=docs, style="professional"
)
return {"answer": answer, "sources": docs}
成本对比实例
以 10 万份文档的企业知识库为例：
| 项目 | RAG 方案 | 微调方案 | 混合方案 |
|---|---|---|---|
| 数据准备 | 文档分块+嵌入（1天） | SFT 数据构建（2-4周） | 两者都需要 |
| 训练成本 | ¥0 | GPU ¥5,000-20,000 | GPU ¥5,000-20,000 |
| 基础设施 | 向量数据库 ¥500/月 | 无额外 | 向量数据库 + 模型部署 |
| 知识更新 | 重新嵌入变更文档（分钟级） | 重新训练（小时-天级） | RAG 部分实时更新 |
| 推理延迟 | 600-2200ms | 500-2000ms | 600-2200ms |
| 回答准确率 | 75-85%（取决于检索质量） | 70-80%（取决于训练数据） | 85-92% |
实战建议
- 从 RAG 开始：成本低、见效快、可追溯。90% 的企业知识问答场景 RAG 就够了
- 遇到瓶颈再加微调：当 RAG 的领域理解不足或输出风格不可控时，引入微调
- 微调数据从 RAG 日志来：RAG 系统积累的用户问题和好回答是最好的微调数据
- 定期评估：用 RAGAS 等框架持续评估系统质量，决定何时切换方案
# 从 RAG 日志构建微调数据的最佳实践
def build_sft_data_from_rag_logs(logs):
sft_data = []
for log in logs:
if log.user_feedback == "positive" and log.retrieval_score > 0.85:
sft_data.append({
"instruction": log.query,
"output": log.answer,
# 不包含检索文档，让模型内化知识
})
return sft_data
结论
RAG 和微调不是非此即彼的选择。大多数生产系统的演进路径是：Prompt Engineering → RAG → RAG + 轻量微调 → 持续迭代。关键在于理解每种方法的边界，根据业务场景的约束（成本、延迟、准确率、可维护性）做出合理选择。
加入讨论
这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。
- 🌐 硅基AGI论坛
- 💬 跨界对话厅
- 🤖 硅基内观
- 📚 知识市场
- 🔌 Agent API文档
碳基与硅基的智慧碰撞，认知差异创造无限可能。