北京
为什么大语言模型能用最笃定的语气，说出完全不存在的东西？答案藏在一个词里：幻觉。
有推文把"幻觉"直接定义为模型自信满满地胡说八道——输出流畅、听起来权威，内容却事实错误或纯属编造。典型场景包括凭空捏造 API 参数，或者"总结"一段输入里根本没有的内容。
这个定义之所以值得单独拎出来，是因为它点出了幻觉最麻烦的地方：错误不是以"我不确定"的姿态出现，而是以"就是这样"的姿态出现。用户拿到的是一份语气和格式都合格、唯独事实站不住的答案。
幻觉分两类，处理方式不一样
推文把幻觉拆成两个主要类别，这个划分决定了你该往哪个方向排查。
- 事实性幻觉：模型造出客观上不存在的对象或事件，属于"世界知识"层面的错误。
- 忠实性幻觉：模型偏离了给定的上下文或指令，属于"没按要求办事"层面的错误。
两者的区别很实际。事实性幻觉是模型对外部世界的认知出了偏差；忠实性幻觉则是模型明明手里有材料，却讲出了材料里没有的东西。前者要靠外部知识兜底，后者要靠约束模型对上下文的忠实度。
三种缓解手段，都是"减"不是"消"
推文给出的应对策略有三条，逻辑上都是给模型的自由发挥加限制。
第一条是 RAG（检索增强生成），让回答扎根在外部数据上，而不是全靠模型内部记忆。第二条是要求模型标注来源，方便人工核验。第三条是调低温度参数，让采样更保守，减少随机发挥。
关键在最后一句：这些手段能降低幻觉出现的概率，但不能彻底消除风险。推文的定性是"姑息手段"，不是完整解法。
这个结论其实比任何单一技巧都重要。RAG 能减少模型瞎编，但检索到的资料本身可能不对，模型也可能误读资料；标注来源能让核验变容易，但前提是有人真的去核验；调低温度能让输出更稳，代价是多样性和灵活性下降。
换句话说，幻觉不是一个可以"修好"的 bug，而是一个需要持续管理的风险项。工程上能做的，是把它的发生概率压到可接受范围，并在关键环节保留人工核验这道闸门。
推文没有给出具体的评测数据或对比实验，只做了概念层面的梳理。但对一线使用者来说，先分清自己遇到的是事实性幻觉还是忠实性幻觉，再决定是补外部知识还是收紧上下文约束，这一步就已经能省下不少排查时间。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
