先分清两种「答不准」
第一种：没找到。资料里有答案，但检索没命中。
第二种：找错了。命中了旧版本、或者命中了另一份文件里相似但不同的条款。
这两种问题的修法完全不同。先分类再动手，否则调提示词调一整天，一点用都没有。
坑一：切块太粗，检索到的是「一整章」
把一份 50 页的制度整篇塞进去，检索时只能定位到「这一章相关」，模型拿到一大段文字，自己挑着答。挑错了你也不知道。
正确做法是按语义完整的最小单位切：一条制度切一条，一个流程切一步。切块的判断标准很简单——切出来的这一段，脱离上下文还能不能独立读懂。
坑二：版本太多，旧文件没下架
这是最隐蔽的坑。三年前的报销制度还在库里，和新制度一起被检索到，模型不知道哪个有效，运气好答新的，运气不好两个都答，客户当场就发现问题。
知识库不是网盘，入库必须有生效日期和下架机制。我们做 POC 时会把「同一问题有多少个版本的答案」列出来，通常客户自己看了都吓一跳。
坑三：没有拒答阈值，什么都敢答
业务方最怕的不是答不上来，是答错了还理直气壮。很多项目的默认设置是「尽量给出回答」，结果资料里根本没有的问题，模型也要编一个。
要明确两件事：
- 检索相似度低于阈值就拒答，转人工；
- 拒答不是失败，拒答率是要写进验收指标的。
我们的 POC 评测集里，会专门放一批「资料里没有答案」的问题，看系统能不能老实说不知道。
坑四：拿模型当搜索引擎
「你帮我找一下合同里关于违约金的条款」——如果每次都让模型自己从头读全文，慢且贵，还容易看漏。
正确的链路是检索在前、生成在后：先用检索定位到原文片段，模型只负责把这段原文组织成人话，并且标明出处。模型不做检索，检索也不做生成。
一个能落地的检查清单
上线前拿这五条自查：
1. 每个问题能不能回溯到原文？回溯不到就是没做好。
2. 有没有「资料里没有」的测试问题？系统会不会拒答？
3. 同一问题存在几个版本的答案？旧版本下架了没有？
4. 切块能不能独立读懂？
5. 答错了谁负责、怎么改？有没有人工核对入口？
这五条过不了，先别谈准确率——准确率是结果，这五条是原因。
本文为方法说明。文中指标为方案设计指标，可在 POC 中验证，不作为对客户效果的承诺。