跳至主要內容

微调还是 RAG——企业 AI 最常问的问题，老张的判断

老张2026/4/30大约 6 分钟

微调还是 RAG——企业 AI 最常问的问题，老张的判断

适读人群：企业 AI 技术负责人、AI 工程师 | 阅读时长：约 12 分钟 | 核心价值：清晰的决策框架，不是"视情况而定"

我被问过这个问题至少三十次了。

每次我的回答都是一样的开头："这取决于几个关键问题，让我问你几件事。"

然后有人就烦了，说："你别跟我说情况，就告诉我该用哪个。"

好，这篇文章我就不说"情况"了。我给出具体条件，每个条件下的明确答案。如果你不耐烦，可以直接跳到最后的决策表。

先把概念说清楚

RAG（检索增强生成）：不改变模型本身，在用户提问时实时检索相关文档，把检索结果塞进 prompt，让 LLM 基于这些文档回答。

Fine-tuning（微调）：用你的数据继续训练模型，改变模型的权重，让模型"学会"你的知识或风格。

这两个技术解决的问题不完全一样，但有大量的重叠区域，重叠区域里很多人都选错了。

RAG 什么时候就够了

RAG 适合的核心场景是：知识是外部的、动态的、需要被引用的。

场景 1：知识库问答

企业有产品文档、合规手册、技术规范，用户需要基于这些文档问问题。

这里用 RAG 有几个明显优势：

  • 文档更新直接更新向量库，不需要重新训练
  • 回答可以附带原文引用，用户可以核查
  • 知识范围清晰，不容易"发挥"
# RAG 的核心逻辑，只需要这些
from qdrant_client import QdrantClient
from openai import OpenAI

openai_client = OpenAI()
qdrant_client = QdrantClient(host="localhost", port=6333)

def rag_query(question: str, collection: str = "company_docs") -> str:
    # 1. 把问题转成向量
    question_embedding = openai_client.embeddings.create(
        input=question,
        model="text-embedding-3-small"
    ).data[0].embedding
    
    # 2. 检索最相关的文档块
    results = qdrant_client.search(
        collection_name=collection,
        query_vector=question_embedding,
        limit=5
    )
    
    context = "\n\n".join([r.payload["content"] for r in results])
    sources = [r.payload.get("source", "未知来源") for r in results]
    
    # 3. 基于检索结果生成回答
    response = openai_client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {
                "role": "system",
                "content": "你是企业知识库助手。只基于提供的文档内容回答问题，如果文档中没有相关信息，说明无法找到。"
            },
            {
                "role": "user",
                "content": f"文档内容：\n{context}\n\n问题：{question}"
            }
        ]
    )
    
    answer = response.choices[0].message.content
    return f"{answer}\n\n来源：{', '.join(set(sources))}"

场景 2：实时数据查询

股票价格、新闻、产品库存——任何需要实时数据的场景，模型的知识截止日期决定了微调没有意义，RAG（或 Tool Use）才是正解。

场景 3：知识量大但使用频率低

你有一个 100 万字的法律合同库，偶尔查询。微调这点知识进模型的权重，成本远超收益。

结论：如果你的需求是"让 LLM 基于你的数据回答问题"，先试 RAG。70% 的企业 AI 需求 RAG 就能解决。

Fine-tuning 真正值得做的场景

微调不是给模型"装入知识"的——那是 RAG 干的事。微调是改变模型的行为模式和输出风格。

场景 1：输出格式必须严格固定

你需要 LLM 每次都输出特定 JSON 结构，或者特定的回复格式，而且不能依赖 prompt 来约束（因为用户输入不可控）。

通过微调，可以把格式要求"烧进"模型，稳定性远高于 prompt engineering。

# 微调训练数据示例：格式化输出
training_examples = [
    {
        "messages": [
            {"role": "user", "content": "分析这条用户评价：'送货速度很快，但包装有点简陋'"},
            {"role": "assistant", "content": '{"sentiment": "mixed", "aspects": {"delivery": "positive", "packaging": "negative"}, "score": 3}'}
        ]
    },
    {
        "messages": [
            {"role": "user", "content": "分析这条用户评价：'产品质量非常好，物超所值！'"},
            {"role": "assistant", "content": '{"sentiment": "positive", "aspects": {"quality": "positive", "value": "positive"}, "score": 5}'}
        ]
    }
    # 需要几百到几千条这样的例子
]

场景 2：特定领域的语言风格

法律文书写作、医疗报告生成、特定公司的品牌语气——通用 LLM 会写，但写得不像。微调用几百条领域内的样本，可以让输出风格对齐。

场景 3：降低推理成本

用 GPT-4o 做某个任务效果好，但成本太高。可以用 GPT-4o 的输出作为训练数据，微调一个更小的模型（比如 7B 开源模型）来做同样的任务。效果可能稍差，但成本降低 10-50 倍。

这是"知识蒸馏"的思路，在高并发场景下非常有价值。

场景 4：让模型"学会"专有术语和缩写

行业内部有大量通用模型不熟悉的术语。比如医院系统里的 HIS、EMR、PACS，或者某个公司内部的产品代号。通过微调，让模型正确理解这些术语的含义。

Fine-tuning 的真实成本

很多人低估了微调的成本，不只是计算成本。

成本项            RAG              Fine-tuning
-----------------------------------------------------
数据准备          文档导入即可       需要标注训练数据（贵）
初始建设成本      低                高（标注 + 训练）
更新成本          添加文档           重新训练或增量微调
推理成本          基础模型成本       基础模型成本（相同）
工程复杂度        中                高（需要训练基础设施）
调试难度          中                高（模型行为难以预测）

标注训练数据是最常被低估的成本。如果是专业领域（法律、医疗、金融），需要专家来标注，成本可能在几十万到几百万。很多企业做完这个计算发现 RAG 其实够用。

两者结合的情况

最好的架构往往是：微调 + RAG 一起用。

典型模式：

用户问题
    |
    v
微调过的模型（懂得企业语气、了解专有术语、会输出正确格式）
    |
    v
RAG 检索（提供实时的、具体的知识）
    |
    v
最终回答

模型负责"怎么说"，RAG 负责"说什么"。

# 结合微调模型和 RAG 的示意
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel
import torch

# 加载微调过的模型（基座 + LoRA 适配器）
base_model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen2.5-7B-Instruct",
    torch_dtype=torch.bfloat16,
    device_map="auto"
)
# 加载微调的 LoRA 权重（包含了企业风格和术语知识）
model = PeftModel.from_pretrained(base_model, "./company-style-lora")
tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct")

def rag_with_finetuned_model(question: str) -> str:
    # RAG 检索（获取相关知识）
    context = retrieve_relevant_docs(question)  # 假设这个函数已实现
    
    # 用微调模型生成（模型知道企业的表达风格）
    prompt = f"""基于以下公司文档，用我们公司的标准格式回答问题：

文档内容：
{context}

用户问题：{question}

请按照标准格式回答："""
    
    inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
    with torch.no_grad():
        outputs = model.generate(**inputs, max_new_tokens=512, temperature=0.3)
    
    response = tokenizer.decode(outputs[0][len(inputs.input_ids[0]):], skip_special_tokens=True)
    return response

决策表

你的核心需求推荐方案
基于内部文档问答RAG
知识需要实时更新RAG
需要引用来源RAG
固定的输出格式Fine-tuning
特定语气和风格Fine-tuning
降低推理成本Fine-tuning（小模型）
专有术语理解Fine-tuning
实时数据 + 企业风格Fine-tuning + RAG

一个简单的判断原则：如果你在想"让模型知道更多"，用 RAG。如果你在想"让模型行为不一样"，用 Fine-tuning。

不清楚的话，先上 RAG，因为它的试错成本更低。

编辑此页
最近更新:
贡献者: xiaozhangge