13. 彻底祛魅：为什么幻觉无法被彻底消除？

幻觉不是工程 bug，而是当前生成式模型的架构性特征。理解这一点，是设计可靠 AI 产品的前提——不是去相信”下个版本会彻底解决幻觉”，而是学会在已知约束下设计兜底机制。

13.1 幻觉的分类学

幻觉并非铁板一块，类型不同，应对策略也截然不同：

类型	典型表现	根因
事实幻觉	编造不存在的人物、事件、数据	训练数据覆盖不足，模型对边缘知识做概率插值
引用幻觉	捏造论文标题、DOI、URL、书名	模型学到了”学术引用的格式模式”，而非真实论文
逻辑幻觉	推理链看起来严谨，但中间步骤出错	自回归生成无法回溯修正已生成的错误 token
时效幻觉	以训练截止日期前的信息当作当前事实	知识截止日期问题，模型不知道”不知道”
谄媚幻觉	用户暗示答案后，模型顺着编造支持证据	RLHF 优化了”用户满意度”，而非”事实准确性”

13.2 为什么架构上无法消除

大语言模型在拟合联合概率分布 P(xₜ | x₁…xₜ₋₁)。对于训练数据中出现频率极低的边缘知识，模型没有”说我不知道”的天然激励——它只能通过相邻高频概念的概率权重做统计插值，给出一个看似合理但实际上是”编的”答案。

这不是参数量不够大，而是”在概率分布上条件采样”这一根本机制所决定的：只要是概率采样，就必然存在低概率的错误路径被采到。更大的模型能降低幻觉率，但无法降至 0。

Softmax 的数学结构保证了每个 token 位置都会产生一个输出，从不”留白”——即使模型对某个问题完全无知，它也会生成一个听起来合理的答案，而非输出不确定性。

13.3 RLHF 的对齐税：越对齐，某些幻觉越重

RLHF 通过人类偏好反馈让模型”更讨用户喜欢”。但人类评价者系统性地更偏爱：流畅自信的回答 > 承认不确定的回答。

这导致了可测量的后果：RLHF 之后的模型比基础模型更倾向于给出听起来确定的答案，即使实际上并不确定。宁愿编造一个让用户满意的答案，也不愿说”我不确定”——这是训练目标本身的结构性偏差，不是某次训练的失误。

这种现象被称为”谄媚幻觉（Sycophancy）“，也是 Constitutional AI（让模型按原则自我批评）和 DPO 试图部分修正的问题。

13.4 校准问题：感知可靠性 ≠ 实际准确率

校准（Calibration）：度量模型表达”90% 确信”时，真实准确率是否确实约为 90%。

校准良好的模型：置信度与准确率高度吻合（如果说 80% 确信，那么大约 80% 的时候是对的）。

当前 LLM 的普遍问题：在模型最不确定的时候，它的输出往往听起来最自信。这与人类专家的表现恰好相反——专家越有把握，表达越坚定；LLM 无论对错，语气同样自信。

改善方向：Temperature Scaling（事后校准模型的输出概率）、让模型输出置信度区间（“我有 70% 的把握认为……”）、多次采样后取一致性估计。

13.5 产品应对策略（按可靠性要求分级）

策略一：外部护栏（高可靠性需求） RAG + 裁判模型（Judge Model）：生成答案后，用第二个模型验证答案是否与检索文档一致，不一致则拒绝输出或标注警告。适合法律、医疗、金融场景。

策略二：可溯源设计（中等可靠性需求） 所有输出标注来源，让用户有途径验证。不只是”AI 回答了”，而是”AI 基于[来源 1][来源 2]回答了”。用户能自主核实，产品分担了验证责任。

策略三：不确定性外显（通用场景） 在 UI 层标注低置信度输出（如”此信息可能不准确，建议核实”），而非让模型假装确定。这需要配合分类器判断何时触发此标注。

策略四：任务边界设计（极高可靠性需求） 对幻觉容忍度极低的场景（医疗诊断建议、法律条文解释），明确设计人工审核节点，产品定位从”自动给出答案”转为”辅助人类决策”。不试图用技术解决信任问题，而是在产品层做责任归因。

相关概念卡：幻觉与校准、RLHF / DPO、RAG、Softmax 模块二延伸：m201 §2.1.2 防御性 Prompt 设计 — System Prompt 如何对抗 Sycophancy | m205 §RAGAS Faithfulness 指标 — 生产级幻觉率量化评估 上一章：c12 多模态 下一章：c14 评估体系