大模型幻觉问题有什么风险

很多人第一次被幻觉坑，是在没做校验就把模型输出直接发给客户或写进系统的时候。这篇不讲幻觉的原理，也不重复怎么修prompt，只从业务使用者角度说清：哪些场景幻觉代价最高、怎么提前识别、出了事按什么顺序排查。

很多人第一次被幻觉坑，是在没做校验就把模型输出直接发给客户、或者写进系统的时候。这篇不讲幻觉是怎么产生的，也不教你怎么改提示词，只从业务使用者的角度说清三件事：哪些场景里幻觉代价最高、上线前怎么提前识别、真出事了按什么顺序查。

先给一个基本判断：幻觉本身不是错误率问题，而是「错了谁承担后果」的问题。同一个幻觉，放在内部头脑风暴里只是让人多改两遍，放在对客报价单里就是丢单，放在合同条款里可能直接产生财务和法律责任。所以下面所有做法都围绕这个前提展开，而不是追求把幻觉降到零——那既做不到，也不划算。

先分清：哪些场景幻觉只是烦人，哪些真会出事

最省事的办法，是按「错了谁承担后果」把使用场景分三档。分档之后你才知道该在哪一层设卡点，而不是所有输出都让人过一遍——那样团队很快就会因为太累而放弃校验。

• 高风险信号一：输出会被自动执行，中间没有人看，比如直接写库、自动发邮件、自动生成工单
• 高风险信号二：内容会进入合同、报价、发票、对客承诺这类有法律或财务约束的载体
• 高风险信号三：外部读者会把它当成事实来源，比如官网文案、公开报告、对外知识库
• 不适用的情况：纯头脑风暴、翻译润色、代码补全这类天然有人工兜底的环节，按高风险标准去防只会白白拖慢效率，还容易让人产生「反正都要改」的敷衍心态

幻觉在业务里通常以这几种方式造成损失

幻觉的表现形式很多，但落到业务里真正造成损失的，基本就下面几类。认识它们的形状，比背定义有用得多。

编造事实类

虚构条款、政策、数据、引用来源，读者当场没法判断真假，往往过几天才被发现

编造接口类

写出不存在的函数、参数、字段名，看着像能跑，实际报错或者静默写错数据

事实漂移类

同一个问题多问几次答案不一致，单独看没事，落进批量任务就造成前后数据矛盾

越权承诺类

在客服、销售、法律答复场景里替公司许下不该许的承诺，比如退换规则、赔偿标准、交期

这四类里，编造接口类和越权承诺类最容易被低估。前者因为「代码看起来对」而跳过人工检查，后者因为「话说得很像真的」而被直接复制。识别方法很简单：只要输出里出现了具体数字、具体条款、具体函数签名，就默认它是可疑的，而不是默认它是对的。

落地前的校验清单与人工卡点

校验不是让人把每一句都查一遍，那样成本比自己做还高。正确的做法是按用途设卡点、按比例抽检、要求给出处、把踩过的坑存下来。下面是可直接照抄的四步。

1. 按用途设卡点只给内部看的不卡；对外发布、进系统、进合同的必须有人过一遍。卡点设在「发送前」而不是「发送后」，出事之后再补流程没有意义。
2. 抽检而不是全检批量任务按固定比例抽检，重点抽长度异常、来源引用缺失、数字密集的输出。抽检记录留档，方便后面追溯是哪一批出的问题。
3. 要求给出处凡涉及事实、价格、政策、法条的答复，一律要求模型标明依据。没有依据的，就当它没说过，宁可让模型回答「不确定」。
4. 做回归样本把踩过的坑存成一批固定问题，每次换模型或改提示词之后重跑一遍，对比差异。这批样本是你自己团队的资产，比任何通用评测都贴近实际。

这里有个常见误区：团队看到某个模型在公开评测上表现好，就默认它在自己的业务场景里也可靠。评测覆盖的是通用能力，你关心的实时数据、内部政策、精确计算这类问题，往往不在评测范围里。所以回归样本必须自己攒。

真出事了，按这个顺序排查

出事的时候最怕乱换模型。按下面四步走，能排除掉大部分其实不是模型问题的故障。

1. 先确认是幻觉还是知识过期同一个问题换几种问法、要求给出来源，看输出是否稳定复现。如果换了问法答案就变，多半是幻觉；如果答案始终一致但和最新情况不符，那是知识过期，属于另一个问题。
2. 再查输入看检索到的资料本身是否矛盾、是否被截断，上下文里有没有互相打架的内容。很多「幻觉」其实是模型忠实复述了你喂给它的错误材料。
3. 再查场景确认是不是让模型回答了超出它可靠范围的问题，比如实时行情、内部未公开政策、需要精确计算的任务。这类问题不管换哪个模型都不该直接采信。
4. 最后才考虑换模型或加检索模型本身扛不扛得住，到 /rankings 和 /benchmarks 看当时的评测口径，别凭一次事故就下结论。如果确实要换，先用回归样本跑一遍再决定。

排查过程中建议把每一步的输入、输出、时间点都记下来。不是为了追责，而是因为幻觉的复现条件往往很具体——同一段上下文、同一个问法才会触发，现场记录丢了就再也复现不出来。