设想一个很常见的内部问答场景：员工问“出差住宿标准有没有例外条款”，系统很快给出几条看似完整的说明，语气平稳，格式也像模像样。等行政同事去核对原文，才发现其中一条把适用范围说反了。回答没有明显语法错误，也没有“我不知道”的犹豫，这正是模型幻觉让人头疼的地方——它不像故障提示，更像一份写得很顺的草稿。
错误被语言包装之后
模型并不天然掌握“事实”，它更擅长根据上下文生成看起来合理的续写。当问题需要精确引用制度、产品参数或版本说明时，生成能力越流畅，越容易把不确定的推断包装成确定结论。模型幻觉并不只发生在冷门问题上，也可能出现在检索没有命中、上下文互相冲突、提问本身带有错误预设的时候。
- 问题超出已有资料范围，模型仍按相似句式补全。
- 检索到的文档片段不完整，关键限定条件被省略。
- 多轮对话里，前文一个未经确认的假设被后续回答当成事实。
- 提示词要求“给出明确答案”，系统便压缩了本应保留的不确定性。
它和普通答错不完全一样
普通错误往往容易定位：字段缺失、接口超时、文档过期，都能在链路里找到原因。模型幻觉隐蔽，因为输出本身可能自洽，甚至附带看似合理的解释。产品侧如果只展示最终答案，不展示引用来源、检索命中情况和置信提示，使用者就很难判断这句话是“查到的”还是“编出来的”。把回答拆成结论、依据和不确定性三部分，能让使用者知道该核对什么。
也要承认边界：并非所有偏差都该被叫作模型幻觉。资料本身过时、权限配置不当、问题描述含糊，都会造成错误输出。把所有问题都归因于模型，会掩盖工程链路里的其他漏洞；反过来，只靠一句“仅供参考”也不能替代校验。
使用者需要保留一点慢
在内容生成、客服辅助、代码补全和知识库问答里，模型幻觉的代价并不相同。低风险场景可以把它当草稿工具，高风险场景则需要把引用、复核和人工确认嵌入流程。对普通使用者来说，一个实用的习惯是追问“依据在哪里”，并把关键结论回到原始材料里核对；对产品设计者来说，少一点笃定语气，多一点可追溯信息，往往比再华丽的回答更接近可信。
流畅不是证据，完整也不等于正确。模型可以帮我们更快抵达候选答案，但收尾那一步核实，仍然需要有人愿意停下来。