LLM 最让人不安的特性，是它会一本正经地胡说。
问它一个不存在的历史事件，它给你编得有鼻子有眼，时间地点人物俱全，全是假的。问它某个 API 的用法，它给你一个看起来很合理的函数签名，参数、返回值都写得规规矩矩，但这个 API 根本不存在。更可怕的是，它的语气极其自信，没有任何「我不确定」的信号。
这就是幻觉，LLM 应用的头号风险。在企业场景里，一个幻觉的回答可能导致用户基于错误信息做决策，轻则体验差，重则出事故。所以幻觉治理是任何严肃 LLM 应用必须面对的问题。这篇讲怎么把幻觉压到可控范围。
先理解幻觉为什么会产生
图：幻觉的三个根因——预测机制、训练数据噪声、讨好倾向，三者共同决定了幻觉是 LLM 的固有特性而非 bug。
治理之前先理解病因。幻觉不是 bug，是 LLM 工作机制的副产品。
LLM 的本质是「预测下一个最可能的 token」。它不是在「回忆事实」，而是在「生成统计上最合理的下一段话」。当它没有确切知识的时候，它会生成「看起来合理」的内容，而不是承认不知道。因为它训练的目标就是生成流畅的文本，流畅不等于准确。
训练数据也有问题。互联网上的信息本身就有错的、过时的、矛盾的，模型把这些都学进去了，分不清哪些可靠哪些不可靠。而且模型有「讨好」的倾向，它倾向于给出一个回答而不是说不知道，因为训练时「有用的回答」比「我不知道」更受奖励。
理解了这些，就知道幻觉没法彻底消除，因为它是模型能力的另一面。能流畅生成内容的同一个机制，也会生成流畅的错误内容。治理的目标不是消灭幻觉，是把它控制在可接受的范围内，并让系统在幻觉发生时有兜底。
第一道防线，用约束让模型别瞎编
图：幻觉治理的四道防线，对应预防、发现、拦截三层策略，投入产出比从左到右递减但可靠性递增。
最直接的治理手段，是在 prompt 层面强约束。
明确告诉模型，「只基于提供的上下文回答，上下文里没有的内容，直接说不知道，不要编造」。这个约束不是万能的，模型有时候还是会编，但有了它，幻觉率会明显下降。没有这个约束，模型会混合自己的参数知识，哪些来自上下文哪些是它编的，你分不清。
降低温度。temperature 控制输出的随机性，温度越高模型越「放飞」，越容易生成创造性的（包括编造的）内容。对事实性要求高的场景，把温度调低甚至设为 0，让模型更「保守」地选择最可能的输出。代价是回答会单调一些，但准确性优先。
给模型一个「不知道」的选项。很多幻觉是因为模型觉得必须给个答案。在 prompt 里明确「如果不确定，回答『我没有足够的信息来回答这个问题』是完全可以的，甚至鼓励的」。给模型退路，它就不会硬编。
角色设定也有帮助。让模型扮演一个「严谨的、会承认不确定性的专家」，比让它扮演一个「无所不知的助手」，幻觉率低。因为后者的人设本身就鼓励它什么都说得头头是道。
第二道防线，RAG 把知识外置
图：RAG 把知识从模型参数中外置，模型角色从「知识来源」转变为「阅读理解」，答案来自可控文档从而有据可查。
约束能压住一部分幻觉，但治标不治本。模型不知道就是不知道，你怎么约束它还是可能编。真正治本的方向是 RAG，把知识从模型参数里外置出来。
RAG 的思路是，不让模型用自己的参数知识回答，而是先检索相关的外部文档，把文档作为上下文喂给模型，让它基于文档回答。模型的角色从「知识来源」变成「阅读理解和表述」。
这从根子上降低了幻觉，因为答案来自你提供的、可控的文档，不是模型脑子里那些不可控的参数知识。只要文档是对的，基于文档的回答就有据可查。
但 RAG 不是万能的。如果检索没召回正确的文档，模型还是会基于错误的上下文回答。如果召回的文档本身有错，错误会传递。所以 RAG 的质量依赖检索质量，这也是为什么前面花篇幅讲 RAG 的四级管线，每一级都在提升检索的准确性。
RAG 和约束要配合用。RAG 提供知识来源，约束确保模型只用这个来源不自己编。两个一起，幻觉率能压到比较低的水平。
第三道防线，溯源让幻觉可发现
即使做了约束和 RAG，幻觉还是会发生。这时候需要的是，让幻觉能被发现。
溯源是关键。让模型在回答里标注信息来源，比如「根据文档 X 的第 Y 段，答案是 Z」。有了来源，用户可以核实，也能快速发现哪些回答是无源之水（很可能是幻觉）。
实现上，要求模型在引用任何事实时附带引用标记。没有引用标记的断言，可信度就要打折。这逼着模型「要么有据要么不说」，而不是随意生成。
置信度也是一个信号。虽然 LLM 的置信度不直接等于正确性，但可以通过一些方式估计，比如让模型自评「我对这个回答有多确定」，低置信度的回答要格外警惕。更可靠的方式是用多次采样，同一个问题问几遍，如果答案高度一致，相对可信，如果每次都不同，说明模型在这个问题上不确定，很可能有幻觉。
第四道防线，后处理校验
回答生成之后，还可以做一层校验，过滤掉明显的幻觉。
事实校验。对于涉及硬事实的回答（数字、日期、名称），用一个独立的校验环节比对。比如模型说「某产品发布于 2020 年」，拿这个事实去可信数据源查一下，对不上就标记或拦截。这适合垂直领域，事实集合可枚举的场景。
一致性校验。同一个问题换几种问法问模型，如果答案矛盾，说明模型在这个问题上不可靠，要做人工复核。
规则过滤。某些场景下，可以用规则识别明显的幻觉模式。比如模型编造的 API 通常有特定格式，编造的引用通常查不到对应的论文，这些可以用规则抓一部分。
一个分层治理的思路
把这几道防线组合起来，形成分层的幻觉治理。
第一层预防，约束加 RAG，从源头降低幻觉发生率。这是投入产出比最高的一层，做好了能挡住大部分幻觉。
第二层发现，溯源加置信度，让发生的幻觉能被识别。完全防住不现实，但能发现就能处理。
第三层拦截，后处理校验，在高风险场景下做最后一道把关。对准确性要求极高的场景（医疗、法律、金融），这层不能省。
不是所有场景都需要把幻觉压到极致。闲聊机器人有点幻觉无所谓，医疗问答的幻觉可能致命。治理的力度要匹配业务的风险容忍度，低风险场景轻量治理够用，高风险场景要层层把关。一刀切要么过度（成本爆炸），要么不足（风险失控）。先想清楚你的场景能容忍多少幻觉，再决定治理投入多少。
幻觉是 LLM 的固有特性
最后建立一个正确的预期。
幻觉不是会被「解决」的问题，它是 LLM 这种技术路线的固有特性。只要模型还是基于「预测下一个 token」的机制，幻觉就存在。下一代模型会更好，但不会消除。
所以幻觉治理不是一个一次性的项目，是一个持续的工作。模型升级了要重新评估幻觉率，新场景上线要重新设计治理策略，线上监控要持续捕捉新的幻觉模式。
把幻觉当成一个要长期管理的不确定性，而不是一个要消灭的 bug，心态就对了。能管理好不确定性的系统，才是生产可用的 LLM 应用。
