微调还是 RAG？企业知识场景的选型框架与成本对比，一篇定方案

「我们买的是通用模型，怎么让它懂公司的业务？」——这个问题一抛出来，团队通常立刻分成两派。微调派觉得把内部文档喂进去训练一轮才是正道；RAG 派坚持外挂检索才是知识场景的标准答案。两边都能举出成功案例，也都能举出失败案例，讨论三轮也定不下来。我们团队先后落地过两条路线，最后沉淀出一个先分需求类型、再看六个维度的选型框架，这篇文章把它讲清楚。

先分清两类需求，再谈技术选型

讨论微调还是 RAG 之前，先回答一个更根本的问题：你希望模型「知道更多事实」，还是「更会干活」？这两类需求的正确解法完全不同：

知识型需求：回答内容依赖具体事实——制度查询、产品手册、客服 FAQ、法规检索。事实会持续更新、必须可溯源，这类需求选 RAG。
能力型需求：回答的格式、语气、行业话术、任务模式需要定制——固定的 JSON 抽取格式、特定风格的营销文案、领域术语的表达习惯。这类需求考虑微调。

举两个我们真实遇到的例子。第一个：客服团队要求助手准确回答「X 型号商品的保修期是多久」——保修政策每季度调整，这就是典型的知识型需求，任何一次微调都会在下一次政策更新时立刻过期。第二个：法务要求合同风险摘要固定输出「条款定位、风险等级、修改建议」三段式格式，通用模型十次里有三次自由发挥——这是典型的能力型需求，几百条格式样本做一次轻量微调就能稳定下来。同一个「让模型懂业务」，拆开看其实是两类完全不同的工程问题。

判断方法很简单：把你期望的正确答案列出来，如果答案随业务数据变化（上新了产品、改了制度），是知识型；如果答案长期稳定但通用模型就是「不对味」，是能力型。

六个维度对比，成本账要算总账

维度	RAG	微调（LoRA/QLoRA）
知识更新	改文档即生效，分钟级	重训模型，天级起步
事实可溯源	可附引用出处，可核查	答案无法定位来源，易幻觉
启动成本	中：向量库 + 检索链路工程	中高：数据标注 + 训练 + 评测
持续成本	每次请求多一次检索开销	推理成本与底座模型一致
数据要求	原始文档即可开工	需要成对指令数据，几千条起步
典型失败模式	检索没召回、切片不合理	灾难性遗忘、学进错误知识

成本上有个常见误区：只算训练那几小时电费。QLoRA 微调一个 7B/8B 模型，几千条样本、一张 24G 显卡、几个小时，训练本身确实便宜；真正的成本在几千条高质量指令数据的标注（这是人力大头）和每轮迭代的评测回归。RAG 的成本则在工程链路搭建与检索质量调优上。两条路线都便宜的部分是代码，贵的部分都是数据与运营。

我们的落地经验是给一个决策顺序：先上 RAG 跑两到四周，积累真实问答的 badcase；如果 badcase 集中在「内容不对、没查到」，继续优化检索，不要碰微调；如果集中「内容对但格式乱、语气飘」，再做小成本的格式微调。多数团队做完第一步就会发现，问题根本没到需要微调的程度。

实操：两条路线的最小可运行方案

路线 A：最小 RAG 链路，验证「知识型需求」是否真的只需检索：

python

# pip install openai chromadb —— 最小 RAG：检索 + 引用式回答
from openai import OpenAI
import chromadb

llm = OpenAI()  # 任何 OpenAI 兼容端点
col = chromadb.PersistentClient(path="./kb").get_or_create_collection("docs")

def rag_answer(question: str) -> str:
    # 用 Embedding 模型编码问题并召回最相关的文档片段
    emb = llm.embeddings.create(model="text-embedding-3-small", input=question).data[0].embedding
    docs = col.query(query_embeddings=[emb], n_results=4)
    context = "\n---\n".join(docs["documents"][0])
    # 要求模型只依据资料回答，并标注引用编号便于核查
    resp = llm.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content":
            f"仅依据参考资料回答，并标注引用了哪几段。\n资料：\n{context}\n\n问题：{question}"}],
    )
    return resp.choices[0].message.content

路线 B：QLoRA 微调，用于格式与话术定制。推荐用 LLaMA-Factory，单卡可跑，配置即代码：

yaml

# LLaMA-Factory 训练配置：QLoRA 单卡 24G 可跑
model_name_or_path: Qwen/Qwen3-8B
stage: sft
finetuning_type: lora
lora_target: all
quantization_bit: 4          # QLoRA：4bit 量化底座 + LoRA 适配器，显存减半以上
dataset: kb_style_3k         # 3 千条人工精标的「问题-标准答案」对
template: qwen
output_dir: saves/qwen3-8b-lora
per_device_train_batch_size: 2
gradient_accumulation_steps: 8   # 等效 batch 16，小卡稳定训练
num_train_epochs: 3
learning_rate: 1e-4
cutoff_len: 4096

bash

# 训练与验证
llamafactory-cli train qwen3_lora.yaml
llamafactory-cli chat --model_name_or_path Qwen/Qwen3-8B \
  --adapter_name_or_path saves/qwen3-8b-lora

无论走哪条路线，训练/上线前先冻结一份 100~200 条的评测集（问题 + 标准答案要点），每轮变更后跑一遍对比，这是两条路线共同的「安全带」。

评测集的构建也有讲究：样本要覆盖高频问题、边界问题与对抗问题三类。高频问题保证主流体验，边界问题（如「两款产品的条款冲突时以哪个为准」）暴露检索与推理短板，对抗问题（如故意写错的型号名）则检验鲁棒性。规模不必贪大，一百条精心挑选的样本比一千条随手抓的样本更有分辨力。

避坑总结

拿微调当知识注入：微调教的是「怎么答」，不是「知道什么」。把事实写进权重既不可靠也不可更新，还放大幻觉——模型会用自信的语气编造它没学扎实的细节。事实性内容一律走检索。
没有评测集就开训：先冻结 100 条 golden 问答再动第一行训练代码，每轮训练后跑分对比基线。否则学习率、epoch 的调整全是玄学，越调越差也不知道。
指令数据重量不重质：几千条低质量样本不如五百条人工精标。成对数据里的错误答案会被模型放大学习，训练前的数据抽检比训练后的调参更值钱。
RAG 效果差就急着换方案：八成的问题出在切分粒度与召回质量上。按语义段落切而不是按固定字数硬切，召回后加重排序（rerank），这两步做完大多数「RAG 不好用」的结论都会被推翻。
忘了权限这回事：RAG 检索层必须做文档级权限过滤，否则 A 部门员工能问出 B 部门的薪资制度。微调路线同理——把全员文档都训进模型后，权限控制就永久失效了。

微调还是 RAG 不是站队问题，而是需求分类问题：知识更新快、要溯源、要控权限，选 RAG；格式要稳定、话术要统一、任务模式要固化，再上微调。先检索后微调、先评测后动手，这个顺序能帮你省下大部分预算。

免责声明

本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。

微调还是 RAG？企业知识场景的选型框架与成本对比，一篇定方案 ​

先分清两类需求，再谈技术选型 ​

六个维度对比，成本账要算总账 ​

实操：两条路线的最小可运行方案 ​

避坑总结 ​

微调还是 RAG？企业知识场景的选型框架与成本对比，一篇定方案

先分清两类需求，再谈技术选型

六个维度对比，成本账要算总账

实操：两条路线的最小可运行方案

避坑总结