有一次同事把一段产品说明丢给聊天机器人，让它“压缩成三句话”。返回的文案很顺，术语也像模像样，只是多出了一个并不存在的功能。把原文和输出并排看，问题才显出来：它没有胡乱拼接词句，而是沿着一个看似合理的方向补全了空白。这类体验，大概就是人们常说的模型幻觉。
“幻觉”这个词容易让人想到机器在“看见”什么。实际使用时，它更像是语言模型在概率上找了一条顺滑的路：根据上下文预测下一个片段，拼出一个读起来连贯、结构完整的回答。训练目标并不直接保证每句话都能被外部事实验证，因此当问题缺少明确依据、上下文含糊，或者用户期待一个确定答案时，模型可能用貌似肯定的语气填补不确定。
流利为什么会掩盖错误
人读文本时，会同时判断语气、结构、细节是否对得上。生成式回答往往语气稳定，段落衔接自然，还会主动给出解释，这会降低阅读者的警惕。我的判断是，模型幻觉难处理的地方不只在“错”，还在“错得像经过整理”。它不总以明显破损的形式出现，有时是一个多出来的限定条件，有时是一个被悄悄替换的概念。
这也解释了为什么单靠“多看一遍”不够。人工复核当然重要，但如果复核者没有回到原始材料，仍然容易被行文逻辑带着走。对企业内容来说，把事实来源、生成过程和发布责任分开记录，比事后追问“它为什么这么说”更可操作。
把不确定性放回流程里
一些工程手段能降低风险：检索增强让回答先找到可引用的材料，工具调用把计算和查询交给外部程序，结构化输出则限制自由发挥的空间。不过这些方法并不能把模型幻觉清零。检索结果可能不完整，工具返回也可能被误读，模型仍会在材料之间做并不稳妥的推断。
所以更现实的做法，不是要求模型“永不犯错”，而是让它在不该确定的时候留下余地。比如在提示中要求标注依据、区分事实与推测；在系统层面设置引用检查、敏感字段校验和人工签发；在对外发布前，把关键数字、名称、承诺性表述单独核对。这些动作听起来不新，却能把问题从“信不信一句话”拉回到“这句话有没有来源”。
我也不太赞成把模型幻觉简单理解成技术故障。它更像生成式系统的一种边界表现：当语言流畅度被放在显眼位置，事实约束就需要额外设计。对使用者而言，重要的不是记住某个神奇提示词，而是养成一种阅读习惯：先看结论有没有依据，再看表达是否顺滑。顺序反过来，就容易被流畅本身说服。