AI知识库总是答非所问，是模型不行还是文档检索出了问题？

一、先把“回答不好”变成可复现的问题

请业务人员记录真实提问，不要事后把问题改成与文档标题一致的问法。一次故障记录至少包含用户身份、提问时间、原始表述、实际回答、预期依据和错误影响。例如同样问“如何申请退款”，订阅产品和项目制服务可能适用不同条款；不说明产品和合同版本，所谓标准答案也不可靠。先让系统询问缺失条件，可能比增加检索片段更有效。

把问题分成有明确依据、需要跨段组合、条件不完整、资料冲突、没有依据和权限受限几类。测试中保留俗称、编号、缩写和口语问题，并把调试集与验收集分开。若每轮都拿同一组演示问题调试，结果越来越好可能只是适配了这些问题，不能说明新员工或客服面对新问题时仍能得到可靠帮助。

二、沿着原文件到片段检查信息是否丢失

逐级查看源文件、解析文本和索引片段。扫描页可能漏识别负号，跨页表格可能丢掉币种与表头，附件中的例外条件可能与正文分开。常见问题不是“大模型不懂业务”，而是它最终看到的文本已经没有业务条件。对于合同、产品说明和制度文件，应保留页码、条款编号、适用对象、有效期和可追溯来源，不能只有一串没有出处的向量片段。

用单条制度做演示时，可以故意把“适用新客户”与费率表拆开，观察系统是否错误应用到全部客户。这是测试设计，不是知华客户实测结果。修复时比较按标题分段、父子片段和必要的上下文补全；不要简单认为段越长越完整。长片段还可能把不同版本、无关附件和互相矛盾的规则一起送入模型。

三、区分没有召回和召回后排序靠后

如果正确原文已在索引中，先看它是否进入候选结果。型号、单号、专业术语可对照关键词检索，含同义表达的问题可对照语义检索，再根据样本比较混合方案。正确片段根本没进入候选集，后续重排无法凭空恢复它；若候选已有依据，但被大量相似材料挤出上下文，才更适合检查重排、去重和元数据过滤。

Dify等平台提供检索测试、混合检索和重排等能力，但有这些开关不等于打开后一定更准。记录每轮改变的变量、候选数量、相关性和延迟，使用同一验收集复测。不要同时更换模型、切分和索引后只报告最终结果，否则难以确定哪一步真正有效，下一次知识更新出问题也无法快速回退。

四、原文正确时，检查生成是否改变了条件

将最终送入模型的上下文与回答逐句核对：是否遗漏例外条件、混淆时间范围、把建议说成承诺，或把两个产品的规定合并。回答应区分依据、推断和待确认事项，引用尽量对应具体结论。只有引用链接而没有内容对应关系，不能作为可信度证明。上下文存在相互冲突的有效规则时，应展示冲突并交给负责人确认。

“请不要胡编”不能替代权限、数据治理和验证。对于缺乏依据的问题，允许明确说无法确认；对于业务用户确实需要结果的任务，提供补充资料、转人工或查询正式系统的路径。还要避免过度拒答：把所有问题都拒绝可能减少错误，却没有产生业务价值，正确拒答与有依据任务的完成率应分别评估。

五、用明确分母的评测表代替笼统准确率

下面仅是计算示例，不是客户成绩：100个测试问题中，80个有授权依据，12个本来就没有答案，8个无访问权限。如果在80个可回答问题中找到72个的正确证据，则这组样本的证据召回覆盖为72/80；如果最终有60个回答满足业务要求，则有依据问题的回答达标为60/80。这两个比例不相同，均不能推出另外20个问题处理正确。

另外统计无答案问题的合理拒答、权限受限问题的数据泄露、引用可核对性和人工修改工时。关键风险应单列，不能被平均分掩盖。样本较小时只把结果当作该测试集的观察，不推广成所有未来输入的准确率。验收保留每题结果、错误原因、模型和索引版本，便于业务复核与下一轮回归。

六、知识更新、撤权和上线责任决定长期效果

源系统发布新版本、删除文件或调整部门权限后，索引与缓存应在约定窗口同步，失败要告警并保留重试记录。只上传新增文件却不处理旧版本失效，会使同一问题逐渐出现多个答案。测试员工离职、跨客户查询和引用附件下载，确保权限覆盖原文、检索、缓存与导出，而不是只在聊天页面隐藏按钮。

优化服务应交付问题清单、对照配置、解析样本、评测集、运行说明和遗留风险。业务负责人维护内容有效性，技术方维护同步、索引和回归。报价按资料复杂度、可复现条件、接口与运行责任评估，不按“调几个参数”估算。若基础知识缺失或业务规则尚未统一，先治理资料往往比重新采购模型更有价值。

官方资料与核对范围

参考资料核对日期：2026-09-12。平台能力会随版本、套餐、地区和权限变化；资料用于说明技术能力，不代表搜索量、知华客户成果或原厂合作资质。

• Dify官方：知识处理、检索测试与重排能力