企业把智能体接进生产系统的比例已达 79.8%，但只有 17% 能把单个场景的成功复制到三个以上。多数「能跑但不好用」的知识库问答系统，问题不在模型，而在检索链路里十来个全用默认值的决策点。长上下文替代不了检索的四个理由也很直白：贵、慢、文档更新后无法即时生效、答案说不清出自原文哪一段。

切块是最先失效的一环。块里不带标题，问「图书馆几点关门」就匹配不上原文里的规则段落；块切得太小会让结论和前提分处两块；重叠太大则同一段话的多个拷贝一起被召回占坑，看起来拿到三条证据其实只有一条。可操作的判据是随机抽 20 个问题，人工确认答案所在原文是否被切碎，超过 20% 就该调大块或改为按段落切。

双路检索的分数合并有个隐蔽缺陷：BM25 分数能到十几二十几，余弦相似度永远在 0 到 1 之间，直接相加等于让关键词一路说了算。更隐蔽的是归一化函数里的全等分支——如果这一次所有候选分数恰好相同，归一化会把它们统一压成 0，再叠加「分数大于 0」的过滤条件，整条检索链返回空且不报错。改用 RRF 按名次计分可以自然绕开量纲问题。

门槛设成「大于 0」等于没设。沾上一个「的」字也算命中，系统就会用三段最不相关的原文拼出一个像模像样的回答——这比模型自编更危险，因为每句话都有出处。把绝对下限提到 0.12，并检查第一名与第二名的分差是否小于 0.05，是成本最低的两道闸门。评测集至少攒 30 条问答对，必须包含「库里根本没有」这一类，否则每一次调参都只是在赌。