文档已经上传,AI 为什么还答不对?按这张表逐层排查

文件上传成功以后，销售问了一句报价，AI 回答得很顺。但把答案发给客户之前，业务负责人发现：数字抄对了，适用条件没了。

漏掉起订量、计价单位或运费条件，一段流畅的回答就可能变成一项无法兑现的承诺。

假设广东大湾区一家企业准备做销售资料问答。当前有效报价表写着：“A 型号，500 件起订，12 元／件，含税、不含运费。”这是练习场景，不代表真实客户项目。

销售问：“客户要 100 件，多少钱一件？包运费吗？”

合适的回答应说明：现有报价适用于 500 件起订，不能据此确定 100 件的单价；资料写明不含运费。若系统回答“每件 12 元，包运费”，可以沿着下面五层定位原因。

第一层：源文档本身是否可靠

先确认报价表由谁维护、哪个版本有效、是否适用于这个型号和订单条件。

如果文件互相冲突，又没有版本优先规则，就找业务负责人确认。不能让模型自行选择“看起来更合理”的一份。即使回答忠于文档，也不能证明文档本身准确。

权限也要先划清：只在提问者获准访问的资料范围内检索和拼接内容，不能指望生成答案时再隐藏敏感信息。

这一层应留下原文位置、版本和业务负责人确认的适用条件。

第二层：解析后有没有丢失关系

打开系统实际提取的文字，对照原表检查：“12 元”有没有保留“每件”？“500 件起订”是否仍与 A 型号对应？运费说明有没有变成缺少归属的散句？

尤其要检查表头、合并单元格和脚注。文件名出现在列表里，还不能证明这些关系已经保留。

若提取结果缺少起订量，就先修复解析或资料组织方式。要求模型“仔细回答”，补不回没有传给它的信息。

第三层：检索是否找到了正确证据

保存这次问题实际检索出的片段，看有没有当前有效的报价和完整条件。分块时，也要检查报价与适用条件是否被拆散。

再用“小批量采购”“A 型号起订量”等常见问法复测，观察相关依据能否被找到。

如果正确内容存在于解析结果，却没进入检索结果，就从这一层查起。只改答案措辞，还没有解决证据缺席的问题。

第四层：模型实际收到的内容是否完整

找到片段之后，还要检查最终送给模型的内容：报价、起订量和运费说明是否一起进入请求？有没有被截断？是否混入旧版或无权查看的资料？

“检索列表里找到了”和“模型实际收到了”是两件需要分别核对的事。两处保留记录，才能追踪证据在哪一步发生变化。

第五层：回答有没有超出依据

完整证据已经送达，再检查回答是否遵守条件。

例子中，系统可以说明现有报价的适用范围，但不能把 500 件的价格直接套到 100 件，也不能补出包邮承诺。引用了出处，还要核对出处是否支持对应结论。

资料不足或版本冲突时，应说明限制，转给指定负责人确认；超出授权范围的问题应拒绝提供相应信息。

随文排查记录单

按条填写，直接复制到工作记录即可：

• 问题原句：________
• 提问者角色及可访问范围：________
• 预期答案与原文位置：________
• 实际错误及业务影响：________
• 源文档版本、单位与适用条件：________
• 解析后保留／丢失了什么：________
• 实际检索出的片段：________
• 实际送给模型的内容：________
• 回答中缺失或无依据的表述：________
• 修复负责人、改动与复测结果：________

每次先围绕一个明确故障修改，再用同一问题复测。同时保留普通提问、条件不满足和资料无答案的样例，检查其他情况有没有受影响。测试记录也应保存在获准访问的位置。

这条路径用于缩小排查范围，问题可能同时发生在多个环节。FDE 要把错误原因、修复责任和验证结果连接起来，才能让系统持续可用。

下一篇转向企业验收：供应商演示很顺，项目就能通过吗？我们会把“不通过”的条件写进验收单。

现在挑一个答错的问题，按记录单标出证据最早在哪一层出现缺失或不一致。

参考资料

解析与表格结构：Microsoft：Document Intelligence layout model（https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/layout?view=doc-intel-4.0.0）

分块与检索上下文：Anthropic：Contextual Retrieval（https://www.anthropic.com/research/contextual-retrieval）

分别检查检索和回答：Microsoft：RAG evaluators（https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/rag-evaluators）