AI 问答库
一句话回答
绝大多数企业知识库先用 RAG，不要上来就微调。RAG 决定模型「能看到什么」，让答案可溯源、文档改了当天生效、还能按人做权限隔离；微调决定模型「怎么说话」，能统一语气和输出格式，但教不会新知识。两者不互斥：常见做法是 RAG 打底，等评测集暴露出稳定的风格或格式问题，再考虑叠加微调。
把需求拆成两句话就清楚了：「模型不知道这件事」是知识问题，归 RAG；「模型知道，但答得不像我们公司的人」是表达问题，归微调。绝大部分被描述成「模型不够懂我们业务」的抱怨，拆开之后其实是检索没做好 —— 文档没切对、没有元数据过滤、召回的段落不相关。这类问题微调解决不了，因为微调不会凭空补上模型没见过的最新合同条款。
| 对比维度 | RAG（检索增强） | 微调（Fine-tuning） | 实务建议 |
|---|---|---|---|
| 注入新知识 | 擅长，检索到就能用 | 不可靠，容易记混或遗忘 | 知识类需求默认选 RAG |
| 知识更新速度 | 改文档即生效，无需重训 | 需要重新训练并重新上线 | 制度、价格、库存类内容必须走 RAG |
| 答案可溯源 | 能返回原文段落与出处 | 无法给出处，只能给结论 | 合规、法务、医疗场景刚需 |
| 权限与数据隔离 | 可在检索层按人/部门过滤 | 权重里的知识无法按人屏蔽 | 有分级授权要求时只能选 RAG |
| 输出风格与格式 | 靠 prompt 约束，长了会漂 | 擅长，稳定复现固定结构 | 格式反复出错时再考虑微调 |
| 单次改动成本 | 低，改数据或改切分策略 | 高，要重新准备数据与训练 | 需求还在变化期就别急着微调 |
三种情况值得认真考虑微调。一是输出结构必须百分百稳定，比如每次都要吐出字段固定的 JSON 给下游系统消费，靠 prompt 约束总会偶发漂移。二是行业表达习惯特殊，通用模型「翻译腔」明显，比如工业工艺文档、中医病历、法律文书。三是 system prompt 已经膨胀到几千 token，每次调用都要重复付这部分成本，把规则蒸馏进权重能显著降低单次开销。这三种都有个共同前提：你已经有一批人工确认过的高质量样本，而不是把历史工单原样倒进去。
第一步，收集 50–100 个业务同事真实问过的问题，写好参考答案，这是评测集，也是后面一切判断的依据。第二步，只做 RAG，把文档切分、元数据、召回排序调到评测集上的表现明显收敛、不再靠改一处就大幅波动。第三步，人工看错例分类：召回不到对应段落是检索问题，继续优化 RAG；召回对了但答得不合规矩，才是微调的候选。第四步，如果确实要微调，用可私有部署的开源家族（Llama 4 / Qwen 3.x / DeepSeek V4 / GLM-5.x）做 LoRA 类轻量微调先验证，别一开始就全参数训练。
适用边界
同义问法