大模型幻觉问题属于业务应用风险吗

做企业内部工具或对外产品时，模型答错一句，到底算技术瑕疵还是业务事故？很多人卡在这里：想上线又怕背锅，想强控又不知道控到哪。这篇给一套可落地的判断口径——先分清幻觉造成的损失算在谁头上，再看场景能不能扛、要不要加人工复核与回退路径，最后给出上线前的自查清单。适合产品负责人、技术选型者和要签字上线的人。

做企业内部工具或者对外产品时，模型答错一句话，到底算技术瑕疵还是业务事故？很多团队卡在这个点上：想上线又怕背锅，想强控又不知道控到哪儿。其实这两个词不在一个层面上——幻觉是模型层的现象，业务风险是损失归属的问题。同一句错话，出现在内部草稿里和出现在对外客服窗口里，性质完全不同。

这篇给一套能落地的判断口径：先把损失算在谁头上分清楚，再看场景扛不扛得住、要不要加人工复核和回退路径，最后给一份上线前能签字自查的清单。适合产品负责人、技术选型者，以及要签字上线的人。

先问一句：这句错的损失算在谁头上

判断幻觉是不是业务风险，第一个动作不是看模型多强，而是看这句错话造成的损失落在谁身上。落在客户、合作方、监管那边，就是业务风险；落在自己团队返工成本里，多数只是质量成本。同一句「这个条款支持随时退款」，写在内部讨论稿里没人当真，发到客户群里就是另一回事。

• 输出是否直接对外：直接触达客户、合作方、监管的，权重高
• 错了之后能否被对方发现：对方没能力识别，就默认它是「对的」
• 发现前会不会已经产生动作：下单、发函、扣款、签约这类不可逆动作，一旦触发就很难收
• 三者都偏向「不可逆 + 对外」时，才够得上业务风险；内部头脑风暴、文案初稿、翻译润色这类，通常只算质量成本

按场景分档：哪些场景它是风险，哪些只是烦

把业务场景按「出错后果」分档，比按技术难度分档更有用。分完之后你会发现，真正需要重管控的场景其实不多，大多数场景只需要轻量兜底。分档不是为了限制上线，而是让资源花在真正会出事的地方。

有一类情形不适用上面的分档：如果业务本身只是给人做参考、最终由人拍板决定，那么把它归到业务风险就过度了。硬上重管控，反而拖慢迭代、让一线绕开系统自己找工具，风险更大。

怎么把它写进验收：可量化的三条线

验收条款如果只写「输出准确」，等于没写。要把它拆成三条能抽检、能追责的线，每条都对应一个具体动作，而不是一个感觉。具体数值随模型和业务变化，别抄别人的数字，到 /benchmarks 和 /crowd-radar 看当期口径，再定自己的线。

1. 定关键字段准确率线对结构化输出里的金额、日期、编号这类字段单独设抽检口径，不跟文风、可读性混在一个分里打总分
2. 定必须拒答线资料不足、超出知识范围、涉及对外承诺时，要求模型说「查不到」而不是猜；同时监控拒答率，避免一刀切摆烂
3. 定兜底线每条输出能追到来源，人工复核能在同一界面完成，出错能撤回或更正

三条线里最容易被忽略的是拒答率。只压幻觉、不监控拒答，模型会学会少说话，用户问十句它答三句，业务价值也跟着掉。两条线要一起看。

降风险的动作顺序：别一上来就微调

很多团队一发现幻觉就想去微调或者换模型，顺序反了，钱花了主要问题还在。事实型幻觉大多能靠前面几步压下去，微调是最后手段，不是第一手段。

• 第一步检索与提示约束：先给可靠资料、明确边界，多数事实型幻觉在这一步就能压住
• 第二步引用与校验：要求输出带出处，对结构化字段做程序化校验，不符合直接拦
• 第三步流程改造：把关键动作改成人工确认后执行，而不是模型直连执行
• 第四步再考虑微调或换模型；顺序反了，容易花钱还没解决主要问题

这几步要落成一份检查项，配合 /safety 的合规视角一起过一遍。如果场景本身跨多个档位，按最高那档来排动作，别按最低档省事。

上线前给负责人看的一页纸

签字的人不关心你用了什么架构，只关心出事之后怎么收场。一页纸写清三件事就够：最坏后果、发现时间、能不能撤回。写不清楚，说明这个场景还没准备好上线。

把这些跟 /models/deploy 的测算结果一起留档，方便复查时对照。留档不是为了追责，是为了下一次上线能少走一遍弯路。