模型幻觉风险

做落地应用时，最怕的不是模型答得慢，而是它一本正经地编：编条款、编接口名、编数字，还说得特别像真的。这篇不聊概念定义，直接按「成因—高危场景—缓解动作」走一遍，告诉你什么时候该加校验、什么时候靠提示词就够，以及哪些做法其实没用。

做落地应用时，最怕的不是模型答得慢，而是它一本正经地编：编条款、编接口名、编数字，还说得特别像真的。幻觉不是模型「坏了」，而是它按概率补全的下一个词恰好看起来很合理。你要做的不是消灭它，而是分清哪些回答可以放过去、哪些必须拦下来。

这篇按「成因—高危场景—缓解动作—上线闭环」走一遍，告诉团队什么时候靠提示词就够，什么时候必须加程序校验，以及哪些看起来管用其实没用的做法。下面所有关于模型与价格的对比，都可以到站内页面看当时的数字，别照抄别人截图。

幻觉是怎么冒出来的：先分清四类成因

同一个「编」，背后原因可能完全不同。搞清楚你的场景落在哪一类，才能选对缓解手段。用错方向的话，参数调到天亮也没用。

知识缺口型

训练语料里本来就没有、或者已经过时，模型只能靠模式补全一段看似合理的答案；这类靠提示词基本治不好，得补资料。

任务错配型

让它做精确计算、逐字引用、长链路推理，它擅长的是「像」而不是「对」；把计算交给代码，把引用交给原文检索。

提示诱导型

问题里带预设、要求必须给答案、上下文塞了错误前提，模型会顺着往下编；先检查你自己的提问方式。

解码与采样型

温度、top-p 偏高，或强制输出复杂结构，都会放大自由发挥的概率；到 /ai-dict/category/tips 对照参数术语，确认你调的是哪个旋钮。

判断方法很直接：把你失败的回答翻出来，看是「资料里根本没有」「任务本身不适合模型」还是「你的提示词在逼它必须答」。绝大多数团队的问题集中在后两类，因为这两类不用换模型就能改。

哪些场景先别信：按后果分三档

幻觉的风险不取决于发生频率，而取决于错了之后能不能被人拦住。同一条错误回答，放进聊天窗口和自动写进订单系统，后果差着量级。先给场景分档，再决定投入多少校验成本。

分档标准就一条：看这条输出有没有「自动进入下游系统或被外部看到」的通道。有，就归高危。注意这个判断会随业务变化失效——今天只是内部问答，明天接进客服机器人，档位立刻上升，得重新评一次。

• 对外报价、合同条款、合规解释：默认高危，不能让模型直接出终稿。
• 自动填表、自动调接口、自动发消息：只要没人复核就是高危。
• 内部检索问答：中危，但要能在答案里标出出处，方便人工核。
• 草稿类创作：低危，别过度工程化。
• 边界情况：用户能直接截图外传的场景，一律按高危处理。

缓解手段排序：从便宜到贵挨个上

很多团队一上来就想微调，其实提示词和上下文这两层最便宜、见效也最快。按下面的顺序做，前面的挡住大部分问题，最后才轮到烧钱的方案。

1. 收紧提示限定「不知道就说不知道」，要求给出依据出处，把开放问答改成带约束的选项。验证方式：把历史上编造的问题喂回去，看是否会主动说不知道。
2. 补上下文用检索把相关资料塞进窗口，比指望模型记住更靠谱。选嵌入模型可以到 /embeddings 对照，注意有些服务商的模型列表和价格会调整，以站内当时显示为准。
3. 加结构约束要求输出 JSON 或固定字段，把自由文本变成可程序校验的字段，缺失就报错而不是让它猜。验证方式：故意去掉一个必填字段，看管线会不会拒绝。
4. 才考虑微调有稳定领域语料和明确格式要求时再考虑，可参考 /stacks/fine-tuning 的服务商与 /training 的流程口径；没有评估集就别动手。

如果前三步做完还是经常编，先别急着换更贵的模型，去 /rankings 看看同类任务的上手反馈，再对比 /price-watch 的价格变动，确认是能力问题还是你的用法问题。

上线后的校验闭环：把幻觉变成可发现的错误

上线前做的那点测试，永远盖不住真实流量的花样。关键是让错误能被发现、能被定位、能被回退，而不是指望不出错。

抽样比例和回归集规模没有通用答案，取决于你的业务量和对错误的容忍度。可以去 /tools/speed-test 这类工具页确认自己当前的调用与响应情况，再定灰度节奏。

• 把「模型说不知道」当成正常结果，不要惩罚它，否则它会开始编。
• 错误日志里记清是资料缺失、任务错配还是提示诱导，方便归因。
• 每次换模型或改提示词，回归集必须重跑，别只看新功能表现。
• 给高危输出准备兜底话术，出错时至少不会让用户拿到假结论。

幻觉没法清零，但可以做到「编了能被发现、发现了能回退」——这才是上线标准。