有位朋友做产品文档，最近养成了一个新习惯：凡是模型给出的时间、版本号、引用出处，他都要回头查一遍。问他为什么，他说不是不信，而是被坑过一次——那份看起来条理清楚的说明里，有一句“根据某份内部规范”，写得笃定，实际上那份规范并不存在。
这就是「模型幻觉」最日常的样子。它不总是胡言乱语，恰恰相反，它常常出现在语法正确、逻辑顺滑、语气自信的句子里。人读着舒服，就容易放过。
它更像“补全”，而不是“撒谎”
把模型想象成一个读了很多文本、极擅长接话的人。它的任务是让下一段话看起来合理，而不是先确认事实再开口。当上下文里缺一块信息，它倾向于用最像样的内容把空补上。补得越自然，越难被察觉。
所以模型幻觉有个讨厌的特点：它和正常输出长得几乎一样。错得很离谱的答案反而安全，人一眼就能否掉；真正麻烦的是那些只错了一点点、又恰好落在你不熟悉的领域里的内容。你不知道自己不知道，于是把它当成已知。
这也解释了为什么同一个模型，在写营销文案时显得可靠，在问具体条款、精确数字、人物关系时却容易出问题。前者本来就允许模糊，后者需要锚点，而锚点不在它的生成逻辑里。
哪些场景最容易踩到
- 需要精确引用的时候。书名、页码、法规条目、论文作者，这类内容一旦被“顺口编出”，外表和真引用没有区别。
- 信息稀薄的长尾问题。越冷门，可参考的文本越少，模型越依赖想象式补全。
- 多轮对话的后半段。前文埋下的一个错误假设，会被后面几轮不断继承和放大。
- 带格式要求的输出。表格、清单、结构化字段会让人产生“已经核对过”的错觉，其实格式规整和内容真实是两件事。
还有一种隐蔽情况：模型把几个都真实存在的片段拼在一起，得到一个不存在的整体。单看每个零件都对，合起来却错了。这种错误最难靠抽查发现，因为抽查的人往往也在看零件。
把它当能力问题，不如当流程问题
很多团队的第一反应是换模型、调提示词、加一句“不要编造”。这些做法有用，但有限。模型幻觉不是可以通过一句指令彻底关闭的开关，它更像一种需要被管理的误差。与其期待它归零，不如设计一套能承接误差的流程。
比较务实的做法有几条。把事实性内容和表达性内容分开处理，需要准确的部分留给可核验的来源，让模型负责组织语言而不是充当资料库。要求它在不确定时明确说明不确定，而不是给出一个完整答案。对关键输出设置人工复核点，复核的人要知道自己该查什么，而不是通读一遍觉得通顺就放行。
还有一个容易被忽略的动作：记录。把每次发现的模型幻觉记下来，注明场景和触发方式。时间久了，这张清单比任何通用建议都管用，因为它对应的是你们自己的业务边界。
边界感比准确率更值得讨论
我们习惯用“准不准”来评价模型，但实际使用中，更关键的问题往往是“在这里用它合不合适”。有些任务容错空间大，幻觉带来的成本只是多改两遍；有些任务一旦出错就要返工、解释、甚至对外更正，成本完全不同。
所以面对模型幻觉，比较诚实的态度是承认它存在，并且承认它不会因为技术进步就彻底消失。能做的，是在它出现的地方留出缓冲：让人知道哪些结论需要核实，让流程在关键节点停一下，让使用者对“过于顺滑的答案”保持一点警觉。
那位朋友后来把核查变成了固定步骤。他说现在反而更愿意用模型了，因为他不再指望它从不出错，而是知道自己会在哪儿接住它。这大概就是和模型幻觉相处的合理方式——不是消灭它，而是不让它悄悄溜过去。