识别 AI 幻觉：B2B 团队的 3 道防护栏

AI 幻觉在真实 B2B 工作流中是什么样子

幻觉指模型生成的答案听起来很确定但其实是错的。在 B2B 中通常以三种典型形态出现：(1) 在客服查询中编造一个不存在的订单号；(2) 在合同摘要中"引用"一段实际并不在合同里的日期；(3) 在发票分类中超出定义集合，生造一个新类别。

三种共享同一模式：当模型找不到真实锚点时，它会填补空白。问题在于输出看起来很有把握——即便错了。"AI 错了"不能落地为动作；要知道错在哪里、为什么错。下面三道护栏就是做这件事。

三道护栏：来源、规则、人工

来源检查：展示支持回答的文档及段落；确认内容确实支持该结论，而非仅有引用。来源缺失或相互矛盾时，转交审核。

规则检查：在应用代码中验证订单是否存在、用户权限、金额和允许的分类。格式正确不代表事实正确。

人工审批：付款、退款或发送具有约束力的信息前，授权人员应看到完整、确定的输出。输出改变后必须重新批准。这些措施没有通用成功率。用正确、错误和无来源的案例测试：无效输出应被阻止，审核队列应送达负责人。

在上线前构建评估（eval）流程

仅凭肉眼查看输出结果是无法捕捉幻觉率的；你需要一个测试集。构建一个由50到200个已知正确答案的真实案例组成的“黄金测试集”，并确保它涵盖边缘情况——缺失数据、模糊的查询、超出范围的请求。在每次修改提示词或更换模型之前都要用它来测试模型，而不仅仅是在上线时测试一次。

追踪两个独立的数字：准确率（模型是否给出了正确答案）和弃权率（模型在应该说“不知道”时是否正确地说了“不知道”）。一个从不弃权的模型看起来很自信，但风险更高；一个弃权过于频繁的模型令人厌烦，但更安全。合适的阈值取决于一个错误答案的代价相对于一个被回避的答案的代价有多高。

对抗性测试与常规场景测试同样重要——有意向模型输入专门设计用来诱发幻觉的查询：关于不存在实体的问题、把两条记录混在一起的请求、要求模型对源文档进行超出范围推断的提示词。如果它无法在受控测试中体面地出错，它在生产环境中也无法体面地出错。

把这当作一个持续运行的流程，而不是一次性的关卡。每当你修改提示词、更换模型，或增加新的文档来源时，都要重新运行评估集，并在部署前将新的准确率和弃权率数据与你的基准进行比较。这与传统软件中的回归测试遵循同样的纪律——只不过测试的对象是判断力，而不是逻辑。

哪些任务的幻觉风险最高

不要只按自由文本或结构化文本划分风险。有效分类中的错误会计记录同样可能造成损失。应评估影响、可逆性、数据敏感度及依赖输出的人员。仅生成草稿的流程不应拥有联系客户或转移资金的同等权限。