大模型微调和知识库怎么排查，怎么做和怎么选

模型答得不对，第一反应往往是「要不要微调一下」，但很多问题其实出在知识库没搭好或者检索没配对。反过来也有人拼命堆知识库，结果该学的格式和语气始终学不会。这篇给一套能照着走的排查顺序：先定位问题属于哪一类，再决定走微调还是知识库，最后给出两条线各自的最小验证做法。

模型答得不对，很多人的第一反应是「要不要微调一下」。但实际情况往往是知识库没搭好，或者检索那一段没配对。反过来也有团队拼命堆知识库，格式和语气却始终学不会，因为那本来就不是知识库该管的事。所以排查的第一步不是动手，是先判断这次失败属于哪条线。

下面这套顺序可以直接照着走：先用对照实验定位问题类型，再分别走知识库线和微调线各自的排查步骤，最后用一张表决定先做哪个。每一步都给了验证动作，改完一项测一次，别一次改三处。

第一步：先分清是「不知道」还是「不会做」

「不知道」指的是模型缺事实、缺内部信息，答案在外部文档里；「不会做」指的是它知识够，但输出的格式、语气、判断口径不对。这两类问题的解法完全不同，混在一起排查只会白费力气。先把手头的失败样本按类型分开归档，再谈改什么。

• 事实缺失：答案存在于某份文档，但模型没提到或说错，归知识库线
• 检索没命中：文档在库里，但召回阶段没把相关段落捞出来，也归知识库线
• 格式不对：内容对但结构、字段、语气不符合要求，归微调线
• 推理步骤错：多步计算或条件判断走偏，先看提示词和拆解方式，别急着微调

归档之后做一组对照实验：同一个问题，先直接问模型一次；再把正确答案的原文整段贴进上下文，再问一次。贴进去就答对了，说明模型本身会用，问题出在知识库或检索；贴进去还是错，才轮到考虑微调或者换模型。这一步能省掉大量无效试验。

知识库这条线：按「切分—嵌入—召回—重排」顺序查

知识库失效的原因是有先后顺序的，从上往下查效率最高。切分是最常见也最容易被忽略的一环：段落被硬切断、表格被拆散、标题和正文混在同一块里，后面的嵌入和召回做得再好也救不回来。先把文档按语义块重切一遍，再测一次。

1. 重切文档按标题层级和自然段落切，表格整块保留，单块别太长也别太短；切完抽几块人工读一遍，确认单独拿出来也讲得通
2. 核对嵌入模型中文语料用偏英文的嵌入模型，召回质量会明显下降；到 /embeddings 对照当时的榜单，按语种和领域挑，别只看总榜
3. 查召回数量与顺序召回到了但没进上下文，多半是条数设太少，或者截断时把关键段挤掉了；把召回条数调大测一轮，看漏答是否减少
4. 考虑加重排召回的相关段落进了上下文但模型没用上，往往是排序靠后；加重排模型后同一批问题再跑一遍对比
5. 最后才动生成前面三步都稳定了，再调提示词和生成参数；固定几条问句做回归，改一项测一次

这条线要避免的坑是一次改多处。切分、嵌入、召回条数、重排全换一遍，效果好了也不知道是哪一项起的作用，坏了更没法回退。把它当成流水线，一站一站过。

微调这条线：什么情况才值得做，最小验证怎么做

微调擅长的是「稳定输出某种风格、格式、判断口径」，不擅长灌新知识。把内部文档塞进微调数据里，模型往往既记不牢，文档一更新又全过期，维护成本反而更高。判断标准很简单：你要的是它「换个说法」，还是「多知道一件事」。

• 适合微调：输出结构固定、字段严格、语气统一、按内部口径做分类判断
• 不适合微调：知识天天更新、需求还在变、只是想让回答更详细
• 最小验证先从几百条真实样本起，覆盖真实输入的长相和边界问法
• 验证集必须留出完全没见过的问法，否则测出来的是记忆不是泛化

跑完必须做三方对照：原始模型、原始模型加知识库、微调后的模型，用同一批用例打分。只看一个指标容易被带偏，比如格式分数上去了但事实准确率掉了。三方对照能让你看清微调到底换来了什么、又付出了什么。

怎么选：一张对照表和上线后的观察点

判断口径可以简化成三问：答案依赖的是外部事实还是内部习惯；这些事实会不会经常变；错一次的代价能不能靠人工兜住。三问的答案基本就能指向该走哪条线。

上线后持续盯住失败样本的新增类型。知识库线和微调线各留一份回归集，任何一侧改完都跑一遍，避免一边的改动把另一边刚修好的问题又带回来。成本和时间别凭印象，到 /compute/finetune 和 /stacks/fine-tuning 看当时的数字和可选服务商。