大模型微调和知识库的区别

团队要做垂直场景的问答或写作助手，常见的卡点是要么数据一直在变、要么语气总不对、要么答不出内部术语，于是开始纠结微调和知识库选哪个。这篇不讲概念定义，只给一套能对着自己需求打勾的判断顺序：先看知识变化频率和答案是否需要引用来源，再看是改知识还是改行为，最后落到怎么小成本试跑和验证。

团队做垂直场景的问答或写作助手，最常见的卡点有三种：数据一直在变、语气总不对、内部术语答不出来。三种卡点混在一起，就会开始纠结微调和知识库到底选哪个。这篇不讲概念定义，只给一套能对着自己需求打勾的判断顺序。

顺序大概是：先看知识变化频率和答案要不要引用来源，再看本质是改知识还是改行为，最后落到怎么小成本试跑、怎么用同一套问题集验证。全程别急着训练，很多需求用检索就能兜住。

先分清你要改的是「知识」还是「行为」

知识型需求，指内部文档、产品参数、政策条款这类随时会变的内容；行为型需求，指固定口吻、固定输出格式、固定判断口径。前者用检索增强（RAG，Retrieval-Augmented Generation，检索增强生成）更省事，因为改文档就等于改答案；后者才轮到微调上场，因为格式和语气是模型参数里的习惯，不是文档里能查出来的。

• 知识型：内容每周都可能改，答案需要能追到具体文档，优先考虑 RAG。
• 行为型：输出必须固定字段、固定句式、固定标签，微调更容易压住。
• 混合型：检索兜住知识，微调兜住格式，两条链路各管一段，不要指望一条搞定。
• 什么情况下不适用：如果需求本身是「答得准但模型没见过这个概念」，别急着微调，先把检索链路做通。

一张对照表，对着你的需求打勾

下面这张表不用逐项全中，勾中越多，对应那条路越值得优先试。核心是看「变化频率」和「是否需要引用」两列，它们基本能定方向。

如果四列里三列都指向 RAG，就先别碰微调；反过来三列指向微调，也别把检索链路当成万能药。两边平手时，先做 RAG，因为迭代一次的成本更低、反馈更快。

成本与资源别只算训练那一笔

两条路的账都容易被低估。微调不只是训练一次的费用，还包含数据清洗、标注、验证，以及每次基座模型换代后的重训；RAG 不只向量化一次，还包含文档切分、检索服务、重排和存储的常驻开销。具体数字会随供应商和方案变动，到 价格追踪（/price-watch） 和 工具目录（/tools） 里的成本测算项核对当时的数字，再决定先投哪边。

微调一次性投入

数据清洗、标注、训练、验证，以及后续基座换代带来的重训。

RAG 常驻投入

文档切分、向量化、检索服务、重排、存储，按调用量持续产生。

隐性成本

两条路都需要一套评测问题集，否则改完不知道是变好还是变坏。

什么情况下不适用这套算法：如果只是给少量文档做一次性查询，直接把内容塞进长上下文可能比搭完整检索链路更省，这时候两套方案都不必上。

小成本试跑和验证顺序

1. 先搭最小检索问答拿真实问题集跑一遍，把答错的问题分成「没检索到」和「检索到了但表述不合规」两类。前者补检索，后者才是微调的信号。
2. 微调先用小样本适配做一次小规模适配器训练，只验证输出格式和风格是否稳定，别一上来就全量重训。
3. 固定同一套问题集对比分别跑纯提示词、加 RAG、加微调三个版本，对比失败类型分布，而不是只看单次主观感受。
4. 把结论写回选型表哪类问题被哪条链路解决，记录在表格里，下一轮迭代直接照表判断。

验证阶段最容易被带偏的是「只看成功案例」。准备一份包含边界问题、内部术语、格式要求的问题集，逐条记录失败原因，比看整体感受靠谱得多。跑完记得把数据和失败分布归档，方便下次对照。

先让检索把知识答对，再决定要不要微调让表述合规，顺序反了通常白花一轮预算。