知识库优化的正确顺序：先改文档，最后才动参数
知识库答不准，大部分人的第一反应是调参数、换模型。
这个顺序是反的。 按我们做项目的经验，收益从高到低是：改文档 > 改切块 > 改检索方式 > 换模型 > 调参数。而大部分人是从最后一项开始的。
这篇按正确的顺序讲。
具体的配置项名称和取值范围以 FastGPT 官方文档为准，各版本会有差异。这篇讲的是优化思路和优先级。
第零步：先把问题定位准
优化之前必须先分清是哪一类问题，否则是在瞎试。
方法：把检索和生成分开看。 输入一个答错的问题，直接看系统召回了哪些片段，不看最终答案。
- 召回的片段里根本没有正确答案 → 检索问题，看第一到第四步
- 召回的片段里有正确答案，但回答不对 → 生成问题，看第五步
这一步花五分钟，能省下几天的乱试。 跳过它直接调参数是最常见的浪费。
第一步：改文档（收益最高）
这是最被低估、也最有效的一步。
按用户的问法写
内部文档写「差旅费报销标准」，用户问「出差住宿能报多少」。字面没有重叠，语义上也不算特别近。
最省事的办法是直接把用户的常见问法写进文档。 一句话的事，比调任何参数都见效。
怎么知道用户会怎么问？去看真实的提问记录。 上线一周的对话日志比任何猜测都准。
补上同义词和行业黑话
在你看来「工单」和「报修单」是一回事，模型未必这么认为。专业领域尤其明显。
直接在文档里写「工单（也叫报修单、维修申请）」，这一步解决的问题比换 embedding 模型还多。
清掉过期内容
新旧两版制度都在库里，系统会随机挑一个答，而你无法预测。用户拿到作废的规定，比拿到「我不知道」危险得多。
这不是技术优化，但它对可信度的影响最大。
第二步：改切块
切块要解决的矛盾很简单：切太碎，一个完整的意思被拆散；切太大，一个片段混了好几个主题，相似度被稀释，还把无关内容塞进了上下文。
不同文档类型的合适切法不同：
- 规章制度、技术规范：按条目切。固定长度会把一条规定拦腰截断。
- FAQ、问答手册：一组问答就是一个自然的块。
- 叙述型长文：按段落或语义切，注意上下文依赖。
验证方法非常朴素：随便挑几个切好的片段自己读一读。你自己读不懂的，模型也读不懂。 这个标准比任何参数都管用。
特别注意上下文依赖：「上述三种情况均需提前申请」这类句子，单独拿出来毫无意义。要么在切块时保留上文，要么改写文档。
第三步：改检索方式
到这一步才开始动系统配置。
向量检索的结构性弱点：认语义，不认字面。
你问「XX-2024 号文件的规定」，向量检索会给你一堆语义相近的文件——因为在它眼里「XX-2024」和「XX-2023」几乎一样，都是「某个编号的文件」。编号、型号、人名、专有名词，这类精确匹配它天生不擅长。
全文检索正好相反：认字面不认语义。
两者结合通常比换模型见效快，而且不需要重建索引。如果你的文档里有大量编号、型号、专有名词——制度文件、产品手册、技术规范都是这样——收益会很明显。
重排序也在这一层：召回之后再排一次序，把最相关的顶上来。当你发现「正确答案确实被召回了，但排在很后面」时，这一步最有价值。
第四步：换 embedding 模型
放到第四步是因为它代价最大：换了模型，之前建的所有向量全部作废，整个知识库要重建索引。
不同模型产生的向量在不同的空间里，互相之间没有可比性。
什么情况才值得换：用文档里的原话能查到，换个说法就查不到——这说明模型没建立起同义关系，而且你已经试过在文档里补同义表述了。
换之前一定要先用小样本测。 别直接在生产库上换。
详见 embedding 模型怎么选。
第五步：调参数和提示词
召回数量：太少可能漏掉正确答案，太多引入噪音。需要按实际情况试。
相似度阈值：太高换个说法就召回不到，太低等于没过滤。
提示词：如果召回是对的但答案不对，问题在这里。要明确要求「只依据提供的资料回答，资料里没有的就说不知道」。
建一个测试集，一次投入长期受益
不管做哪一步优化，都需要一个客观的判断依据，否则改完了不知道是变好还是变坏。
做法：
- 收集 20-30 个真实问题（让业务同事写，不要自己想）
- 人工标出每个问题的答案在哪个文档片段
- 每次改动后跑一遍，看正确片段有没有被召回、排第几
这个测试集的价值远超一次性使用：换模型要用它、调切块要用它、做项目验收也能用它、系统上线后做回归也靠它。
做一次，用很久。 这是知识库项目里投入产出比最高的一件事。
优化要有节奏：一次只改一件事
这是方法层面的一条，但它决定了前面所有步骤有没有意义。
一次改多个地方，你就不知道是哪个起了作用。 同时换了模型、调了切块、改了召回数量，效果变好了——下次遇到类似问题，你不知道该复制哪一步。效果变差了，更不知道该回退哪一个。
正确的节奏：
- 跑一遍测试集，记下当前的基准
- 只改一个地方
- 再跑一遍测试集，对比
- 变好就留下，变差就回退，记录下来
听起来慢，实际上比反复瞎试快得多。而且做几轮之后你会积累出这类文档的经验，下个项目直接用。
还有一点：改动要记下来。 三个月后系统出问题，你需要知道当初为什么这么配。没有记录的话，接手的人（可能就是三个月后的你自己）只能从头试一遍。
有些问题优化不了
说完能改的，说说改不动的：
需要跨多个文档做推理的问题。 「对比一下 A 部门和 B 部门的报销标准有什么不同」——这需要分别检索、理解、对比。检索机制本身是找相似片段，不是做分析。这类需求要在应用层设计流程，不是调知识库能解决的。
答案不在文档里。 很多组织的真实情况是知识从来没被写下来过。上系统只是把这个问题暴露出来了——这时候要补的是资料，不是参数。
需要精确计算的问题。 「我工作三年能休几天年假」——如果制度里写的是规则而不是结果，模型算错的概率不低。这类问题应该用工具调用去算，不是让模型推。
完整的排查方法见 Dify 知识库检索不准怎么排查，文档整理方法见知识库项目七成工作量在文档。
如果优化到最后发现平台给的调整空间就是不够——需要针对文档结构做定制的切块和检索策略——那已经到了平台边界，见低代码 Agent 平台的能力边界。这类活我们做，可以聊聊。