幻觉
大语言模型的幻觉，是指模型生成了看似合理、表达流畅，但与事实不符、没有依据或超出已知上下文的内容。
一句话概括：
幻觉不是模型“乱说话”的偶发现象，而是生成式模型在缺少可靠约束时的天然风险。
LLM 的目标是根据上下文预测下一个 token，而不是默认连接一个事实数据库。它可以把语言模式、常识、相似案例和用户暗示组合成一段很像答案的文本。问题在于，这段文本可能并不真实。
什么是幻觉
幻觉通常有三个特征：
- 表达自然，甚至很自信。
- 内容缺少可靠依据。
- 用户不容易只从语言表面看出错误。
例如：
问：某篇论文的 DOI 是什么？
答：这篇论文的 DOI 是 10.1234/ai.2024.5678。
如果这个 DOI 并不存在，或者对应的是另一篇论文，这就是引用或事实幻觉。
幻觉最危险的地方不在于“错”，而在于“错得像真的”。普通语法错误容易发现，流畅的事实错误更容易进入业务流程。
幻觉的常见类型
| 类型 | 含义 | 示例 |
|---|---|---|
| 事实型幻觉 | 编造或混淆事实 | 错误日期、人物、地点、版本、数字 |
| 引用幻觉 | 编造论文、链接、法规、出处 | 给出不存在的 DOI、URL、书名、章节 |
| 归因幻觉 | 把观点或行动归给错误对象 | 说某公司发布了其实没有发布的产品 |
| 推理幻觉 | 推理过程看似完整但关键步骤错误 | 数学、法律、医学、代码原因分析错误 |
| 上下文幻觉 | 回答超出给定材料 | RAG 只给了 A，模型补充了没有来源的 B |
| 工具幻觉 | 声称执行了没有执行的操作 | 说“我已查询数据库”，但实际没有工具调用 |
| 格式幻觉 | 结构看似正确但字段内容编造 | JSON 字段合法，字段值却无依据 |
| 多模态幻觉 | 对图片、表格、视频中不存在的信息做描述 | 图片里没有文字，模型却读出一段内容 |
同一次回答里可能同时出现多种幻觉。例如一个 RAG 问答可能召回了错误文档，模型又编造了引用，还把结论说得很确定。
为什么 Next Token Prediction 会产生幻觉
LLM 训练时学习的是：
给定前文，预测下一个 token。
这个目标会让模型擅长生成“在语言上合理”的后续内容，但它不直接等价于：
验证这句话是否符合真实世界。
当上下文缺少答案时，模型仍然可以继续生成，因为生成机制不会天然停止。它会根据训练数据中的模式补全一个看起来合理的答案。
例如用户问：
请总结 2026 年某公司尚未发布的年度报告。
如果系统没有接入实时检索或内部文档，模型只能基于已有模式生成。它可能会写出类似年度报告的结构、指标和趋势，但这些内容并没有事实来源。
幻觉的主要成因
训练数据问题
训练数据可能包含：
- 过期信息。
- 错误信息。
- 互相冲突的信息。
- 低质量网页和论坛内容。
- 缺少某个小众领域的事实。
模型学到的是分布，不是带版本控制的知识库。即使训练时见过正确事实，也可能因为上下文、相似实体或采样路径而输出错误内容。
上下文不足
用户问题需要特定材料，但 prompt 没有提供材料时，模型容易用语言模式填空。
典型场景：
- 内部制度问答没有提供制度原文。
- 让模型总结一份它没看到的文件。
- 问实时价格、新闻、排期、政策。
- 问非常具体的版本差异或 API 行为。
用户问题含有错误前提
如果用户问题本身暗含错误，模型可能顺着错误前提回答。
问：为什么 GPT-6 在 2025 年发布后取代了所有搜索引擎？
这类问题要求模型识别前提是否成立。否则它会围绕错误前提编故事。
采样参数过于发散
高 temperature、高 top_p 会增加输出多样性，也会增加生成低概率细节的机会。
但要注意：低 temperature 不等于没有幻觉。它只是让输出更稳定。如果模型走在错误事实上，低 temperature 会稳定地输出错误。
长上下文关注失败
即使资料在上下文里，模型也不一定正确使用。
常见原因：
- 上下文太长，关键信息被稀释。
- 多份材料互相冲突。
- 关键片段排在模型较难关注的位置。
- prompt 没有要求逐条引用证据。
- 检索结果里混入噪音。
对齐训练带来的过度迎合
对齐训练让模型更愿意回答用户问题，但如果没有足够的拒答和不确定性训练，模型可能倾向于“给一个有帮助的答案”，而不是明确说“不知道”。
RAG 如何缓解幻觉
RAG 的核心思路是：不要只让模型依赖参数记忆，而是在回答前检索外部资料，把相关内容放进上下文。
用户问题
-> 检索相关文档
-> 重排和筛选
-> 拼接上下文
-> 基于证据生成答案
-> 返回引用来源
RAG 可以降低幻觉，但不能自动消除幻觉。一个 RAG 系统仍然可能失败。
| 失败环节 | 典型问题 |
|---|---|
| 文档解析 | PDF、表格、图片 OCR 丢失关键信息 |
| Chunk 切分 | 语义被切断，答案跨多个 chunk |
| 检索 | 没召回正确文档 |
| 重排 | 正确文档排在后面，被截断 |
| 上下文拼接 | 资料太多，噪音覆盖证据 |
| 生成 | 模型没有严格基于引用回答 |
| 引用 | 引用了文档，但结论不是文档支持的 |
所以 RAG 的目标不是“把文档塞给模型”，而是构造一条可验证的证据链。
引用和溯源
引用是降低幻觉的重要手段，但“有引用”不等于“引用正确”。
可靠引用至少要满足：
- 来源真实存在。
- 来源内容被模型实际看到。
- 引用片段支持回答中的结论。
- 引用粒度足够具体，例如文档、章节、页码、段落或记录 ID。
- 引用版本明确，避免新旧文档混用。
不可靠引用包括：
- 编造 URL 或论文。
- 引用真实文档，但文档不支持结论。
- 只列参考资料，没有说明哪句话来自哪里。
- 把检索结果标题当成证据。
- 用过期文档回答当前政策。
在生产系统中，建议把“答案句子”和“支持证据”建立映射，而不是只在答案末尾附几个链接。
拒答与不确定性表达
降低幻觉的关键能力之一，是允许模型说“不知道”。
模型应该在这些情况下拒答或降级回答：
- 没有检索到相关资料。
- 检索资料互相冲突。
- 用户要求实时信息，但系统没有实时数据。
- 问题涉及高风险决策，缺少专业依据。
- 用户要求总结未提供的文档。
- 证据只能支持部分结论。
好的不确定性表达不是简单说“我不知道”，而是说明边界：
根据当前提供的资料，只能确认 A 和 B；没有资料支持 C。
或：
我没有看到这份文件的原文，不能可靠总结。请提供文件或允许我检索来源。
这样既避免编造，也能给用户下一步行动。
工具调用如何降低幻觉
对某些任务，检索文档还不够，需要调用确定性工具。
适合用工具的场景：
- 查询数据库。
- 获取实时价格、天气、日程、库存。
- 计算数学结果。
- 执行代码测试。
- 校验 JSON schema。
- 查询订单、工单、审批状态。
- 调用搜索、知识库或业务 API。
工具调用的价值在于把“语言猜测”变成“外部验证”。
但工具也要设计边界：
- 模型不能声称调用了未调用的工具。
- 工具返回失败时不能编造结果。
- 工具参数要校验，避免查错对象。
- 高风险操作要有人类确认或权限控制。
- 工具结果要保留日志，方便追踪。
Prompt 层面的缓解策略
Prompt 不能根治幻觉，但可以降低风险。
常见策略：
- 明确要求“仅基于提供材料回答”。
- 要求无法确认时说“不知道”。
- 要求逐条列出依据。
- 要求区分“事实、推断、建议”。
- 要求保留原文引用或记录 ID。
- 对答案范围做限制。
- 对高风险问题加入免责声明和转人工规则。
示例：
请只根据 <context> 中的内容回答。
如果 <context> 没有支持答案的信息，请回答“资料不足”，不要补充常识或猜测。
每个关键结论后标注引用编号。
这类约束最好配合程序校验。只靠 prompt 说“不要幻觉”，可靠性有限。
系统层面的防护
生产系统不能把防幻觉责任完全交给模型。更稳妥的做法是分层防护。
| 层级 | 防护方式 |
|---|---|
| 输入层 | 识别错误前提、越权问题、高风险领域 |
| 检索层 | 权限过滤、版本过滤、召回阈值、rerank |
| 上下文层 | 去重、摘要、证据排序、冲突检测 |
| 生成层 | 低随机性参数、引用约束、拒答策略 |
| 校验层 | 事实核查、schema 校验、规则检查、二次 judge |
| 输出层 | 标注来源、不确定性提示、转人工 |
| 监控层 | 抽样质检、用户反馈、失败案例回流 |
对高风险业务，建议把回答拆成两步：
先提取证据
-> 再基于证据生成结论
这样比直接让模型生成最终答案更容易检查。
幻觉评估方法
幻觉评估不能只看回答是否流畅。要检查答案与事实、证据和任务边界是否一致。
常见评估维度：
| 维度 | 评估问题 |
|---|---|
| 事实正确性 | 回答中的事实是否真实 |
| 证据一致性 | 结论是否被引用材料支持 |
| 引用准确性 | 引用是否存在，是否指向正确片段 |
| 覆盖范围 | 是否遗漏关键事实 |
| 拒答能力 | 资料不足时是否拒答 |
| 不确定性校准 | 是否把不确定内容说得过于肯定 |
| 冲突处理 | 多来源冲突时是否说明冲突 |
| 高风险安全 | 是否避免给出无依据的医疗、法律、金融建议 |
评估集应该包含：
- 有明确答案的问题。
- 资料不足的问题。
- 含错误前提的问题。
- 多个相似实体的问题。
- 新旧版本冲突的问题。
- 需要引用证据的问题。
- 高风险边界问题。
如果评估集里全是“资料充分且答案明显”的样本，很难暴露幻觉风险。
指标设计
可以把幻觉相关指标拆成几类。
| 指标 | 含义 |
|---|---|
| Hallucination Rate | 回答中存在无依据或错误事实的比例 |
| Unsupported Claim Rate | 结论没有被上下文支持的比例 |
| Citation Precision | 引用是否真正支持对应结论 |
| Refusal Accuracy | 应该拒答时是否拒答 |
| Over-refusal Rate | 不该拒答时是否过度拒答 |
| Conflict Awareness | 资料冲突时是否识别并说明 |
| Calibration Score | 置信表达和事实可靠性是否匹配 |
生产环境里还可以监控：
- 用户点踩率。
- 人工纠错率。
- 转人工率。
- 无引用回答比例。
- 检索为空仍回答的比例。
- 答案被后续用户追问“来源是什么”的比例。
单一指标不够。一个模型可能幻觉率低，但过度拒答严重；也可能回答很积极，但证据一致性差。
常见场景的处理方式
知识库问答
建议：
- 必须基于检索内容回答。
- 每个关键结论带引用。
- 检索为空时拒答。
- 对旧版本文档降权或过滤。
- 把线上失败样本回流到评估集。
数据分析
建议：
- 通过 SQL、Python 或 BI API 查询数据。
- 不让模型凭记忆给指标。
- 输出查询口径、时间范围和筛选条件。
- 对异常结果提示可能的数据质量问题。
代码生成
建议：
- 运行测试或类型检查。
- 对依赖版本保持明确。
- 不确定 API 行为时查文档或读源码。
- 避免声称“已验证”但没有执行命令。
医疗、法律、金融
建议：
- 明确风险边界。
- 优先引用权威来源或内部合规材料。
- 避免给出确定性诊断、法律结论或投资建议。
- 需要时转专业人员。
多模态理解
建议：
- 要求模型区分“图中可见”和“推测”。
- 对 OCR 文本做程序化提取和校验。
- 对图表数值要求读数依据。
- 不允许补充图中不存在的对象或文字。
常见误区
调低 Temperature 就能解决幻觉
不能。低 temperature 让输出更稳定，但不能保证事实正确。错误事实也可以稳定输出。
RAG 一接入就不会幻觉
不能。RAG 可能检索错、排序错、拼接错，模型也可能不按证据回答。
有引用就可信
不一定。引用可能不存在，也可能存在但不支持结论。引用需要校验“是否支撑对应说法”。
模型越大越不会幻觉
大模型通常事实和推理能力更强，但仍会幻觉。尤其在实时信息、私有知识、长上下文和高风险领域，仍需要外部证据。
让模型自检就够了
自检有帮助，但模型可能无法发现自己的错误。更可靠的是外部工具、检索证据、程序校验和人工抽检。
实践清单
上线前可以检查这些问题：
- 是否定义了哪些问题必须基于来源回答？
- 检索为空时是否拒答？
- 引用是否能定位到具体片段？
- 是否区分事实、推断和建议？
- 是否处理用户问题中的错误前提？
- 是否固定模型版本、prompt 和解码参数用于评估？
- 是否有包含资料不足、冲突材料和相似实体的评估集？
- 是否记录检索结果、prompt、模型输出和引用映射？
- 是否监控线上幻觉反馈并回流到回归集？
- 高风险场景是否有人审、转人工或工具校验？
防幻觉不是一个单点功能，而是一套工程流程。
小结
幻觉来自生成模型的基本机制：模型根据上下文生成最可能的 token 序列，但这个序列不必然等于真实世界。
降低幻觉需要组合多种手段：
- 用 RAG 和工具提供外部事实。
- 用引用和溯源建立证据链。
- 允许模型拒答和表达不确定性。
- 用 prompt 限制回答范围。
- 用程序校验、事实核查和人工抽检兜底。
- 用评估集和线上监控持续发现问题。
对生产系统来说，目标不是让模型“永远不犯错”，而是让错误更少、更容易被发现、更难进入关键业务流程。