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

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

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

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

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

1) 来源引用：模型在每条回答中附带来源文档的 id 或行号。没有来源就回答"我不知道"。幻觉下降约 80%。

2) 规则预检查：在输出落地之前用领域规则校验——订单号是 8 位吗？发票类别在白名单里吗？日期格式合法吗？这些便宜的 Python 检查能拦住大多数。

3) 人工预批：高风险动作（退款、合同签署）由 AI 提议、人工批准。AI 自动处理约 95%；剩下 5% 异常路由给你审查。

三者合用：在独立第三方审计中，幻觉率下降到 2% 以下。

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

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

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

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

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

哪些任务的幻觉风险最高

并非每一项AI任务都承担着同等的风险，因此你的护栏（guardrail）预算也不应该被平均分配。开放式生成——起草一封客户邮件、总结一次会议、撰写营销文案——为创造力留出了空间，但幻觉恰恰就藏在这个空间里：捏造的统计数据、虚构的引言、公司从未做出过的承诺。这是风险最高的一类，因为没有一个固定的“正确”输出可供核对，只有一个可接受结果的范围。

数字与财务数据提取紧随其后。从发票中提取总额、计算折扣、提取税号——这里的错误既隐蔽（数字看起来很合理）又代价高昂（它直接影响资金流转）。法律及类医疗性质的陈述——合同义务、合规声明、剂量或安全相关的措辞——属于同样的高风险层级：一旦出错一次，造成的后果不是尴尬，而是法律责任。

在光谱的另一端，针对固定模式（schema）的结构化提取——把简历解析成姓名/邮箱/技能、把工单归入12个类别中的一个、给交易打上商户代码标签——风险相对较低。模型编造的空间更小，因为输出空间是受限的，而且很容易用机械方式验证：你可以检查该类别是否存在、邮箱地址是否包含@符号、数值是否属于12个选项之一。归入一个小而封闭的集合的分类任务，表现也类似——即便模型出错，它也是在你所定义的边界内出错，这是一种本质上代价更低的失败模式。

利用这种风险梯度来决定护栏投入的方向。低风险、封闭模式的任务，往往只需轻量校验和抽样检查就能运行。高风险、开放式或涉及数字/法律的任务，则值得投入上一节所述的全套措施——引用来源、规则检查、以及人工介入——然后才能让自动化系统接触客户或账簿。