完整题目
大模型在生成过程中可能出现‘幻觉’现象，即生成不符合事实的内容。请从数据、模型架构、推理策略和外部工具等方面分析可能的缓解方法。
本文目录
答案要点
- 数据层面：高质量数据筛选、知识图谱注入、对抗性数据增强
- 模型架构层面：检索增强生成、知识编辑、约束解码
- 推理策略层面：采样温度控制、Self-Consistency、Chain-of-Verification
- 外部工具层面：搜索引擎调用、代码执行验证、多模型交叉验证
数据层面
- 高质量预训练数据：加强事实性数据清洗，过滤低质、冲突信息
- 知识图谱注入：将结构化知识（如海尔产品知识库）与文本联合训练
- 对抗性数据增强：构造"事实-幻觉"对比样本，提升模型辨别能力
模型架构层面
- 检索增强生成（RAG）：动态检索外部知识库，将检索结果作为上下文约束生成
- 知识编辑：用ROME、MEMIT等方法精准修正模型中的事实错误
- 约束解码：在解码层加入事实一致性约束，限制低概率幻觉token
推理策略层面
- 降低采样温度：减少随机性，greedy或低temperature采样
- Self-Consistency：多路径采样投票，过滤不一致输出
- Chain-of-Verification（CoVe）：让模型先生成、再主动验证、最后修正
外部工具层面
- 工具调用验证：对接搜索引擎、数据库、代码执行器核实关键事实
- 多模型交叉验证：用多个模型独立回答，不一致时触发人工或检索
- 事实溯源机制：要求模型标注信息来源，便于事后核查
核心思路：幻觉无法根除，需多层防御——数据打底、架构约束、推理校验、工具兜底，根据场景成本灵活组合。
换一种问法，检查是否真正理解
场景切入
假设你在做一个电商客服机器人，用户问“这款羽绒服充绒量多少”，它答了200g，但实际是150g。这种张冠李戴的幻觉挺常见的。你从数据、模型、推理到工具，会怎么一步步堵住这些漏洞？
层层追问
大模型生成的内容有时候会瞎编，你怎么看这个幻觉问题？……那如果从数据源头开始改进呢，比如清洗数据或者加知识图谱？……除了数据，模型架构上有什么招数吗，比如检索增强？……推理的时候能做什么？……实在不行，是不是得靠外部工具兜底？
直球架构
请系统性地分析大模型幻觉的缓解方案，从数据、模型架构、推理策略、外部工具四个层面分别给出关键技术，并说明各自适用场景和局限性。
练习口述回答 · 约4分钟
- 幻觉本质是事实一致性难题，无法根除但要层层防御
- 数据层面：高质量筛选与知识图谱注入，成本高但治本
- 模型架构层面：RAG与约束解码，适合动态知识场景
- 推理策略层面：Self-Consistency与Chain-of-Verification，做最后校验
- 外部工具层面：搜索与代码执行兜底，适合高精度场景
- 落地取舍：多层组合，根据场景成本灵活配置
这道题其实问的是，大模型生成的东西怎么保证它不瞎编。[[幻觉]]本质上是模型在事实一致性上出了问题，不可能彻底根除，但我们可以从数据、架构、推理和工具几个层面层层设防，把风险压到可接受的范围。
先说数据层面。这里最根本的思路是 让模型在训练阶段就见更多真东西。比如做高质量数据筛选，把网上那些矛盾、过时、明显错误的信息过滤掉。另一个方向是注入[[知识图谱]]，把结构化的知识，比如企业产品规格、政策条款，跟文本一起训练。这样模型对事实的敏感度会高很多。但这里有个坑：数据清洗成本非常高，而且知识图谱覆盖不全的话，反而可能让模型对没见过的实体更爱瞎编。所以数据层适合做基础打底，但 不能完全依赖它。
再讲模型架构层面。现在最主流的做法是[[RAG]]，检索增强生成。比如客服场景，用户问“这个订单为什么还没退款”，模型不是凭记忆硬答，而是先去知识库里检索退款规则和订单状态，然后把检索结果当上下文来生成。这样生成的内容就有依据了。RAG 特别适合知识频繁更新的场景，比如电商大促期间满减政策天天变。但 RAG 也不是万能药，检索质量差的话，上下文喂错了反而放大幻觉。所以落地时我通常会配合[[重排]]，用[[Cross-Encoder]]把检索结果再精排一遍，把不相关的滤掉。
推理策略层面，这里有个简单但有效的方法叫[[Self-Consistency]]。就是让模型对同一个问题生成多条回答，比如温度设0.7跑五次，然后看哪些答案互相一致，不一致的说明可能有问题。还有一个更高级的变体叫[[Chain-of-Verification]]，让模型先粗答一轮，然后自己针对每个事实点问自己“这个数字对吗”，再根据验证结果修正。这个思路说白了就是 让模型自己当自己的质检员。但代价是推理成本翻了好几倍，延迟会很高，所以适合离线或对实时性要求不高的场景。
最后是外部工具兜底。遇到关键事实，比如金额、日期、法律条款，可以直接调搜索引擎、数据库或者代码执行器来验证。比如在金融风控场景，模型生成一个合同条款，我会让它通过[[Function Calling]]去调用底层的合规数据库，返回真实条文。这相当于给了模型一个“查字典”的能力。但工具调用也有前提，就是工具的接口要稳定、返回要可靠，否则工具本身出错反而引入新幻觉。
说到这，其实有个很有意思的点：RAG 和微调在缓解幻觉上的边界在哪？比如知识频繁更新的场景，RAG 明显更灵活；但如果是模型对某个领域的常识性错误，比如“海尔是德国的”，用知识编辑方法比如 ROME 直接改模型参数可能更彻底。这个取舍我还在实践中摸索，不同场景权重不一样。