人工智能（十八）- 大模型幻觉生产风险治理

大模型"幻觉"（Hallucination）通常被解释为：模型生成了一段看似流畅、连贯、甚至很有说服力的内容，但其中包含与事实不符、与上下文不一致，或者无法被可靠依据验证的信息。

通俗地说，它就是"一本正经地胡说八道"。

但如果从工程角度看，幻觉的问题不只是"模型答错了"。真正危险的是：模型会用非常确定的语气输出一个未经证据支撑的结论，而调用方很难在第一时间区分这是事实、推测，还是编造。

在聊天场景里，这可能只是一次错误回答；但在后端系统里，如果大模型被接入代码生成、知识库问答、告警分析、故障排查、客服机器人、运维自动化等链路，幻觉就会变成系统可靠性风险。

例如：

AI 助手生成一个看似合理但实际上不存在的 Spring 注解；
根据几行日志直接判断"数据库连接池耗尽"，但没有连接池指标、线程栈和数据库侧证据；
在 RAG 问答中引用了过期接口文档；
给出一条危险的运维命令，却没有说明前置条件和回滚方案；
在 SQL 优化建议中忽略事务隔离级别、锁等待和索引选择性。

这些问题的共同点是：模型输出看起来很像专业建议，但缺少可验证的事实基础。

一、什么是大模型幻觉？

大模型幻觉可以理解为：

模型生成了语义连贯、表达自信，但与真实事实、输入上下文或可靠证据不一致的内容。

这里有三个关键词。

1.1 语义连贯

幻觉内容通常不是乱码。它往往逻辑顺滑、术语正确、格式整齐，甚至能给出步骤、代码和解释。这也是它难以识别的原因。

如果一个回答明显胡乱拼接，工程师很容易警觉；但如果它像一份正常的技术方案，就可能被误用到代码、文档或生产决策中。

1.2 表达自信

大模型默认倾向于完成任务。当用户提出问题时，它通常会生成一个完整回答，而不是频繁说"我不知道"。

这在普通问答里能提升体验，但在高风险场景里会放大问题：模型的不确定性没有被清晰暴露出来。

1.3 缺少证据支撑

工程系统最关心的不是模型说得像不像，而是：

这个结论来自哪里？
是否能追溯到文档、日志、指标、数据库记录或代码？
是否有反例？
是否能被测试验证？

如果答案无法被证据支撑，就不能直接进入生产决策链路。

二、幻觉的常见类型

幻觉不是单一问题。不同类型的幻觉，对应的治理手段也不同。

2.1 事实性幻觉

事实性幻觉是指模型生成的内容与现实事实冲突。

例如，询问某个技术组件的版本特性，模型给出一个并不存在于该版本中的功能；或者在解释某个 Java API 时，把不同版本、不同框架中的概念混在一起。

在后端工程中，常见表现包括：

编造不存在的配置项；
混淆 Spring、Spring Boot、Spring Cloud 的能力边界；
把不同 JDK 版本的特性混用；
对中间件默认参数给出错误解释；
把某篇旧文档里的行为当成当前版本行为。

这类幻觉通常需要通过官方文档、源码、版本说明或测试用例验证。

2.2 编造型幻觉

编造型幻觉是指模型虚构不存在的对象、引用、方法、论文、类库或案例。

例如：

java 复制代码

@TransactionalRetry(maxAttempts = 3)
public void updateOrderStatus(Long orderId) {
    // ...
}

这段代码看起来像 Spring 风格，但 @TransactionalRetry 并不是 Spring Framework 提供的标准注解。

类似问题在 AI 代码生成中很常见：模型会根据已有命名风格"补全"一个看似合理的 API。如果开发者没有校验，很容易浪费排查时间，甚至把错误设计继续包装成自定义方案。

2.3 推理型幻觉

推理型幻觉不是某个事实点错误，而是模型在多步推理中出现跳跃。

比如一次线上接口超时，已知信息只有：

应用侧 P99 延迟升高；
数据库 QPS 有波动；
Redis 命中率下降；
部分接口出现线程池排队。

如果模型直接判断"根因是数据库慢查询"，这就是典型的推理跳跃。

合理的分析应该区分：

已知事实；
可能原因；
需要补充的证据；
下一步验证动作。

对后端排障来说，推理型幻觉尤其危险，因为它会把团队带向错误排查路径。

2.4 上下文型幻觉

上下文型幻觉是指模型忽略或误读了用户提供的上下文。

例如用户明确说明：

当前服务使用的是 JDK 8，不考虑升级。

模型却建议使用 JDK 17 的语言特性。或者用户提供了接口定义、错误日志和配置片段，模型只抓住其中一部分信息，生成了与上下文不一致的结论。

这种问题在长 Prompt、长日志、长文档分析中更常见。上下文越长，约束越多，模型越可能漏掉某些关键条件。

2.5 工具与 RAG 链路幻觉

很多团队会用 RAG（Retrieval-Augmented Generation，检索增强生成）降低幻觉风险。基本思路是：先从知识库中检索相关材料，再让模型基于材料回答。但 RAG 并不等于"事实保证器"。RAG 链路可能在多个环节出错：

文档本身过期；
文档切片破坏语义；
向量召回命中了相似但不相关的内容；
重排模型没有把真正相关文档排到前面；
上下文拼接时被截断；
模型没有严格基于检索内容回答；
引用编号和实际内容不匹配。

所以 RAG 能降低一部分事实性幻觉，但也会引入新的工程问题：检索失败导致的错误回答，会被包装成"有依据的回答"。

2.6 多模态幻觉

在多模态模型中，幻觉还会出现在图像、音频、视频理解里。

例如图片中是猫，模型描述成狗；图片中没有某个物体，模型却说看到了；或者对截图中的配置、表格、监控面板识别错误。

如果多模态模型用于巡检、审核、告警解释或截图分析，就需要额外做结果校验和人工复核。

三、为什么大模型会产生幻觉？

幻觉不是简单的"模型不聪明"，而是由模型机制、训练数据、推理策略和工程链路共同导致的。

3.1 大模型生成的是"可能的文本"，不是事实查询结果

大语言模型的核心能力是基于上下文预测后续 Token。它学习的是语言模式、知识关联和表达方式，但它本身不是一个强一致的事实数据库。

这意味着：

它可能知道某类问题通常怎么回答；
它可能生成符合语法和上下文的内容；
但它不天然保证每个事实点都经过外部验证。

所以，当问题超出模型知识边界，或者上下文证据不足时，模型仍然可能生成一个"看起来合理"的答案。

3.2 训练数据存在边界

训练数据会带来几个问题：

数据过期

框架版本、中间件行为、云厂商产品、开源项目 API 都在变化。模型可能掌握的是旧版本知识。
数据冲突

不同文章、文档、问答社区中的内容质量参差不齐。模型可能学习到相互矛盾的表达。
长尾知识不足

企业内部框架、私有 SDK、历史包袱、定制化中间件通常不在公开训练数据里。
上下文缺失

同一个技术结论在不同版本、不同配置、不同业务约束下可能完全不同。模型如果缺少上下文，就容易过度泛化。

3.3 对齐训练会提升可用性，但不等于事实校验

经过指令微调和偏好对齐后，模型通常更擅长理解用户意图，也更愿意给出清晰、完整、有帮助的回答。

但"有帮助"不等于"事实正确"。

在某些场景下，模型可能为了满足用户问题，给出一个完整方案，而不是主动暴露不确定性。对于工程系统来说，这需要通过 Prompt、系统边界和校验机制来约束。

比如可以要求模型：

没有依据时明确说明"不确定"；
区分事实、推测和建议；
给出每个关键结论的依据；
避免基于缺失信息直接下结论。

3.4 解码策略会影响幻觉概率

模型生成时通常会使用 temperature、top-p 等参数控制输出随机性。一般来说：

temperature 较低，输出更稳定，但不代表一定正确；
temperature 较高，输出更发散，适合创意类任务，但事实性风险更高；
即使 temperature 设置为 0，也不能保证没有幻觉。

所以在代码生成、知识库问答、故障分析等场景中，不应只依赖参数调节。更关键的是证据约束、结构化校验和系统边界设计。

3.5 上下文窗口不是无限可靠的记忆

很多人以为只要把文档、日志、代码都塞进 Prompt，模型就能正确理解，实际并不一定。长上下文会带来几个问题：

重要信息被放在模型不敏感的位置；
多个约束相互冲突；
上下文超过限制后被截断；
模型只关注局部片段，忽略全局条件；
日志、代码、配置混杂，增加理解难度。

这也是为什么工程上需要做上下文整理，而不是简单堆 Prompt。

3.6 RAG 解决了一部分问题，也引入了新的问题

RAG 的价值在于把模型回答约束到外部知识库上，尤其适合：

企业内部文档问答；
API 文档助手；
运维手册问答；
知识库客服；
规范、制度、流程类内容。

但 RAG 不是银弹。它依赖完整链路：

text 复制代码

用户问题
  -> 查询改写
  -> 向量召回
  -> 重排
  -> 上下文拼接
  -> 模型生成
  -> 引用校验
  -> 输出

任何一个环节出错，都会影响最终答案。

例如，召回阶段没有找到正确文档，生成阶段再强也只能基于错误上下文回答。此时模型可能会生成一个格式完整、引用齐全，但事实错误的答案。

四、幻觉在后端系统中的风险

对 Java 后端工程师来说，幻觉的风险不只是在聊天窗口里"答错一道题"，而是可能进入研发、运维和业务链路。

4.1 代码生成风险

AI 生成代码时，可能出现：

使用不存在的 API；
混淆不同框架的注解和配置；
忽略事务边界；
忽略并发安全；
忽略异常处理；
生成能编译但不符合业务一致性的逻辑。

例如订单状态更新场景中，模型可能给出一段看似完整的代码，但没有处理幂等、并发更新和事务回滚。

对后端系统来说，代码"看起来合理"远远不够。至少要经过：

编译检查；
单元测试；
集成测试；
并发场景测试；
代码审查；
关键业务规则校验。

4.2 线上排障风险

在故障排查中，幻觉常表现为"过早归因"。

例如：

看到接口慢，就判断是数据库慢查询；
看到 CPU 高，就判断是 GC 问题；
看到 Redis 命中率下降，就判断是缓存穿透；
看到消息堆积，就判断是消费者处理能力不足。

这些判断都可能是候选原因，但不能直接当作根因。

更好的做法是让模型按排障逻辑输出：

text 复制代码

已知事实：
- P99 延迟从 200ms 上升到 2s
- 线程池队列长度上升
- 数据库慢查询数量没有明显增加

可能原因：
- 下游服务响应变慢
- 线程池配置不足
- 外部接口超时重试放大流量

需要补充的证据：
- 线程栈
- 下游调用耗时分布
- 连接池指标
- 重试次数
- 最近发布记录

这比直接输出"根因是数据库"可靠得多。

4.3 知识库问答风险

企业内部经常会把大模型接入文档系统，用于回答：

接口怎么调用；
某个错误码是什么意思；
某个流程怎么审批；
某个系统如何上线；
某个中间件参数如何配置。

如果知识库过期、召回错误或模型没有严格基于文档回答，就可能给出错误操作指南。这类风险很隐蔽，因为用户会天然相信"知识库助手"的回答。

4.4 自动化操作风险

如果模型只是给建议，风险还相对可控；如果模型进一步接入自动化工具，就必须谨慎。例如：

自动执行 SQL；
自动变更配置；
自动扩缩容；
自动重启服务；
自动执行运维命令；
自动修改工单状态。

这类场景必须引入权限控制、审批机制、审计日志和回滚方案。模型不应直接拥有高危操作权限。

4.5 合规与审计风险

在金融、医疗、法律、企业内部管理等场景中，幻觉可能导致合规问题。工程系统需要回答：

模型为什么这样回答？
依据是什么？
用户看到了哪些内容？
是否能追溯到知识来源？
是否经过人工审核？
是否保留了版本记录？

如果没有这些能力，系统很难通过审计。

五、如何缓解幻觉：不要找银弹，要设计防线

幻觉很难被彻底消灭，更现实的目标是：

降低幻觉发生概率，让幻觉更容易被发现，并阻止高风险幻觉直接影响生产系统。

5.1 Prompt 约束：低成本，但不能当作唯一防线

Prompt 是最容易上手的方式，例如：

text 复制代码

请只基于给定材料回答。
如果材料中没有答案，请回答"无法从现有材料确认"。
请区分"事实""推测"和"建议"。
每个关键结论都必须给出依据。
不要编造 API、参数、性能数据或案例。

这类约束有价值，尤其适合低风险场景。但它不是强约束。模型仍然可能忽略指令，尤其在上下文很长、任务复杂或指令冲突时。

所以 Prompt 更适合作为第一道防线，而不是最后一道防线。

5.2 RAG：降低知识型幻觉，但要治理检索链路

RAG 的核心不是"让模型更聪明"，而是让模型有依据可查。一个较稳妥的 RAG 系统，至少需要关注：

文档来源是否可信；
文档是否有版本；
切片是否保留语义完整性；
召回是否能覆盖关键问题；
是否需要重排；
上下文是否被截断；
回答是否引用了来源；
引用是否真的支持结论；
知识库更新后是否重新建索引；
是否有离线评测集。

RAG 的代价也不能忽略：

维度	影响
延迟	检索、重排、生成都会增加响应时间
成本	向量库、Embedding、重排模型、LLM 调用都有成本
维护	文档更新、索引重建、版本管理需要长期维护
稳定性	检索失败、向量库异常、文档缺失都会影响结果
可解释性	需要保证引用和答案之间真的有关联

所以 RAG 适合知识密集型问答，但不适合代替实时强一致查询。例如订单状态、库存数量、账户余额这类信息，应该查数据库或业务 API，而不是让模型根据文档猜。

5.3 工具调用：让确定性系统做确定性事情

大模型适合做语言理解、信息整理、推理辅助，不适合直接承担确定性查询。对于后端系统，应该尽量把以下任务交给工具或业务服务：

查数据库；
查缓存；
查订单状态；
查用户权限；
执行计算；
获取监控指标；
查询日志；
读取配置中心；
调用内部 API。

模型负责理解用户意图、组织答案和解释结果。

一个简单原则是：

能用确定性程序解决的问题，不要让模型自由生成。

5.4 结构化输出与校验

如果模型输出要进入系统链路，不建议直接消费自然语言。可以要求模型输出结构化结果，例如 JSON，然后做 schema 校验、字段校验和业务规则校验。例如：

json 复制代码

{
  "answer": "当前材料无法确认根因，只能判断线程池排队与延迟升高有关。",
  "confidence": "low",
  "evidenceIds": ["log-20240501-001", "metric-threadpool-002"],
  "needsHumanReview": true,
  "nextActions": [
    "查看线程栈",
    "检查下游调用耗时",
    "确认最近发布记录"
  ]
}

后端系统可以根据 confidence、evidenceIds 和 needsHumanReview 决定是否展示、降级或进入人工审核。

5.5 离线评测与回归测试

如果大模型能力进入核心业务链路，就不能只靠人工体验判断效果。建议构建评测集，包括：

高频真实问题；
历史错误案例；
容易混淆的问题；
无答案问题；
过期文档问题；
多条件约束问题；
恶意 Prompt 注入问题；
长上下文问题。

每次调整 Prompt、模型版本、切片策略、召回参数或重排模型后，都应该跑一轮回归测试。这和后端系统升级依赖、改 SQL、改缓存策略后的测试思路类似。

5.6 可观测性：没有 trace，就很难排查幻觉

线上出现幻觉后，如果只保存了最终回答，基本很难定位问题。至少应该记录：

用户原始问题；
查询改写结果；
召回文档 ID；
文档版本；
topK 结果；
重排分数；
最终拼接给模型的上下文；
模型名称和版本；
temperature、top-p 等参数；
Prompt 版本；
输出结果；
用户反馈；
是否触发兜底或人工审核。

排查时可以沿着链路看：

text 复制代码

  -> 问题是否明确？
  -> 查询改写是否改变了原意？
  -> 检索是否召回正确文档？
  -> 重排是否把相关文档排前面？
  -> 上下文是否被截断？
  -> Prompt 是否要求基于证据回答？
  -> 模型是否忽略证据？
  -> 后处理是否拦截失败？

这套链路比单纯调 Prompt 更重要。

六、常见坑

6.1 以为 RAG 可以消灭幻觉

RAG 只能提供外部依据，不能保证模型一定正确使用依据。如果检索错了、文档旧了、引用不匹配，RAG 也会产生幻觉。

6.2 只调低 temperature

降低 temperature 可以让输出更稳定，但稳定不等于正确。错误答案也可以很稳定。

6.3 把 Prompt 当成权限系统

Prompt 不是安全边界。如果模型接入了高危工具，比如执行 SQL、重启服务、修改配置，必须依赖真实的权限控制、审批机制和审计系统，而不是只在 Prompt 里写"不要执行危险操作"。

6.4 不记录检索上下文

很多线上问题无法复盘，是因为系统只记录了用户问题和模型回答，没有记录当时召回了哪些文档。没有检索上下文，就很难判断问题出在知识库、检索、重排、Prompt，还是模型生成阶段。

6.5 用大模型替代业务查询

例如用户问：

我的订单现在是什么状态？

正确做法是调用订单服务查询实时状态，而不是让模型根据历史对话或文档推断。模型可以解释状态含义，但不应该编造状态。

七、最佳实践建议

可以把大模型幻觉治理拆成几层防线。

第一层：输入约束

明确任务边界；
拆分复杂问题；
避免把无关上下文全部塞进 Prompt；
对高风险任务要求模型先列出缺失信息。

第二层：知识约束

使用可信知识库；
文档加版本；
定期清理过期内容；
对关键文档做人工审核；
对召回结果做重排和过滤。

第三层：输出约束

要求结构化输出；
区分事实、推测和建议；
强制引用来源；
无依据时必须拒答或降级；
高风险内容进入人工审核。

第四层：系统校验

JSON Schema 校验；
业务规则校验；
引用 ID 校验；
权限校验；
操作前二次确认；
高危操作审批。

第五层：可观测性与评测

保存完整 trace；
建立离线评测集；
记录用户反馈；
监控无依据回答率；
监控人工驳回率；
模型和 Prompt 变更后做回归测试。

八、什么时候适合用大模型，什么时候不适合？

场景	是否适合	原因
文档摘要	适合	可以基于明确材料生成
FAQ 问答	适合	可结合 RAG 和引用校验
日志初步分析	适合，但需人工确认	可辅助整理线索，但不能直接判定根因
代码解释	适合	对理解代码有帮助
自动生成核心业务代码	谨慎	必须经过测试和评审
实时订单状态查询	不适合直接生成	应调用业务 API
财务、医疗、法律结论	高风险	需要权威来源和人工审核
自动执行运维命令	高风险	需要权限、审批、审计和回滚

一句话总结：

大模型适合做辅助理解和表达，不适合在没有校验的情况下直接承担事实源和执行权。

九、总结

大模型幻觉不是一个简单的"回答错误"问题，而是当前生成式 AI 在事实 grounding、上下文理解、推理可靠性和不确定性表达上的综合限制。

从工程角度看，关键不是追求"完全没有幻觉"，而是建立一套可控机制：

让模型知道边界；
让回答有依据；
让不确定性暴露出来；
让高风险输出被拦截；
让线上问题可以追踪和复盘。

RAG、Prompt、微调、工具调用、结构化校验、人工审核都不是银弹。它们更像不同层次的防线，需要根据业务风险组合使用。

对于 Java 后端工程师和架构师来说，接入大模型时应该把它看成一个"不稳定但有价值的智能组件"，而不是一个天然可信的事实源。

真正成熟的 AI 工程化系统，不是让模型永远不犯错，而是让错误不会轻易进入生产决策链路。