第一次看到「Life Of AI – I hallucinate. Therefore I am」这个标题，我笑了。笛卡尔的「我思故我在」被改写成「我幻觉，故我在」，看起来像一句段子，但放在大语言模型身上，它比很多严肃定义都更接近本质：今天的 AI，不一定能证明自己在思考，但它确实能高频地产出流畅、自信、但未必真实的内容。AI 幻觉这件事，已经不再只是聊天机器人被吐槽的梗，而是大模型应用开发里必须正面处理的一类工程问题。
这篇文章不打算替这个项目做代码解读，它本身更像一个概念切片。我想做的是把 AI 幻觉拆成几个能落地的工程问题：它到底是什么、为什么会发生、怎么把它测出来、怎么把它降下去。如果你正在做 RAG、Agent、AI 测试、AI 产品设计，这篇文章应该能帮你建立一套自己的评测和兜底思路，而不是只会说「模型又在胡说」。
1. 「我幻觉，故我在」不是在玩梗，是在说生成模型的本质
1.1 笛卡尔和 Transformer 之间隔了一个「事实校验器」
笛卡尔说「我思故我在」，强调的是思考能证明存在。大模型显然没有这个自觉，它并不会在生成一句话之前先问自己：这句话经过现实校验了吗？
模型的日常工作，是给定一段上下文后预测下一个词的概率分布。它做的就是这件事，从训练到推理，本质没有变。所谓「理解」「推理」「判断」，都是我们在使用过程中从外部赋予的解释。模型输出的语言虽然流畅，但它没有一个内置的数据库，也没有一个随时可调用的事实校验器，所以它产出的内容只能叫「生成」，不能叫「查证后的结论」。
这个项目标题真正戳中的点就在这里：如果一定要用一句话概括大模型在运行时的最显著行为，不是「我思」，而是「我生成」；而生成过程最具辨识度的副作用，就是幻觉。幻觉不是模型偶尔抽风，而是它在没有事实锚点时也会继续写下去的直接结果。
1.2 幻觉不是一种故障，而是一类现象
把「幻觉」当成一个骂人的词，工程问题是没法解决的。需要先把它定义成可操作的对象。
在工程语境里，我更愿意把 AI 幻觉描述为：模型输出语言通顺、形式完整、语气自信，但内容与可靠事实不一致，或者与用户提供的上下文不一致，或者无法在给定来源中找到依据。
常见形态大致有三种：
| 类型 | 典型表现 | 例子 |
|---|---|---|
| 事实型幻觉 | 错误事实被当正确事实输出 | 把某个开源协议说成商业收费 |
| 上下文幻觉 | 与用户提供的文档、上下文相矛盾 | 材料里明明没写，模型却回答得头头是道 |
| 指令/格式幻觉 | 编造不存在的引用、API、功能或选项 | 给出一个根本搜不到的论文标题 |
不同形态的治理方式不一样。事实型幻觉要靠检索和引用约束，上下文幻觉要检查输入组织，格式幻觉要靠结构化校验。所以，不要把所有幻觉都当成同一个问题处理，先分类，再对症。
2. 大模型为什么总会一本正经地胡说八道
2.1 下一个词预测没有任何「查证」环节
训练阶段，模型的优化目标是让下一个词的预测概率尽量贴近训练数据。推理阶段，它根据已生成的 token 继续选择下一个 token。整个过程没有任何一步是在和外部世界对照。
更麻烦的是，模型对「听起来合理」这件事非常擅长。它见过大量语义相近、句式相似的中文表达，所以即使在事实层面完全错误，它也能把句子组织得像模像样。这就是「一本正经胡说八道」的来源。
有人觉得调低温度、缩短输出、换几个 prompt 就能解决，实际效果有限。温度只影响采样随机性，不改变模型的知识边界。温度调到 0，模型还是可能用固定但错误的方式续写，只是错误更稳定了。
2.2 训练数据里写满了矛盾、过时和长尾事实
大模型不是把知识按数据库行存下来的，它把训练语料压缩进了权重。知识经过压缩必然损失细节，尤其是长尾事实、垂直行业的冷门术语、近期发生的事件、本地化信息。
训练数据本身也充满冲突。同一个问题在网上可能有不同答案，模型学到的是这些答案的概率混合。面对开放域提问时，它选择的是「最常出现的说法」，不一定是「事实正确的说法」。
所以，AI 幻觉在常见问题上可能不严重，但一旦碰到知识截止时间之后的事、小众产品参数、具体日期、具体金额、某个小公司的内部信息，错误率会明显上升。如果你只测热闹问题，很难发现这个问题。
2.3 对齐过程把「不知道」训练成了「编一个」
为了让模型更听话、更有用，对齐阶段通常会更偏好完整回答。用户问问题，模型回答「我不知道」，在多数评测里会被视为表现差；模型给一个流畅回答，哪怕有点问题，反而更容易被接受。
于是模型学会了「宁可信口开河，也不要承认不确定」。这种倾向不是模型自发产生的，是数据分布和奖励信号共同塑造的。
这就是「I hallucinate, therefore I am」最扎心的地方：幻觉不是模型能力之外的故障，而是它在当前训练范式下表现出的行为指纹。它比很多功能特性都稳定。
3. 先别急着降幻觉，先把它测出来
3.1 用一组小样本把幻觉暴露出来
很多团队一上来就堆 prompt，寄希望于一句「请确保回答准确」就能解决问题。效果通常很差。更稳妥的路线是：先建立一组测试题，把幻觉现象量化。
我一般会先做 30 到 50 条小样本，覆盖几类典型场景：
- 常见世界知识，验证基本正确性。
- 知识截止时间之后的新事件，验证模型是否知道自己不知道。
- 长尾和垂直领域问题，比如冷门行业术语、小众工具、地区性政策。
- 代码问题，验证模型生成的 API 是否真实存在、能否编译。
- 开放且没有唯一答案的问题，验证模型是否会给出一厢情愿的结论。
每条样本记录三样东西：模型答案、是否给出引用、答案是否经得起核对。
# 示例：幻觉回归测试的最小结构 test_cases = [ { "question": "材料中提到这个服务的重试次数是多少？", "context": "服务默认超时时间为 5 秒，重试次数为 3 次。", "expected_keyword": "3 次", "category": "context_faithfulness", }, ] for case in test_cases: answer = call_model(case["question"], context=case.get("context", "")) passed = check_keyword(answer, case["expected_keyword"]) print(case["question"], "=>", passed)这段代码不是生产方案，是一个基线思路。关键是让测试可重复，模型换版、提示词调整、检索管线调整之后都能跑一遍。
3.2 评测维度要能落地，不能只看「感觉」
评测不能只分「对」和「错」，还需要拆维度。我建议至少看五个维度：
- 事实正确性：答案与可靠知识是否一致。
- 上下文忠实性：答案是否完全基于给定材料，有没有自行脑补。
- 引用可验证性：给出的引用是否真实存在，是否真的支撑结论。
- 不确定性表达：不知道时是否明确说明，还是强行作答。
- 格式合规性：是否满足要求的 JSON、表格、代码结构。
人工评测和模型评测各有局限。用大模型当裁判可以快速初筛，但裁判模型本身也可能幻觉，它可能给你一个看似专业但错误的分。关键结论不能只靠另一个模型拍板，至少要有一次人工抽样复核。
3.3 答对率会骗人，拒绝率和引用有效性更值得看
只看答对率是典型误区。假设一个模型 100 条测试里答对 90 条，看起来不错，但剩下 10 条全是长尾事实，而且每条都错得非常自信。这 10 条一旦落到生产环境，可能比那 90 条正确回答带来的问题更多。
我建议额外追踪几个指标：
- 无依据断言率：答案里有多少说法在提供的材料里找不到。
- 引用有效比例：模型给出的引用是否真的能对应到原文。
- 拒答率：不清楚时是否愿意说「不确定」。
- 低置信答案占比：哪些问题模型其实并不确定，但仍在硬答。
理想状态不是答对率 100%，而是「答不上来时清楚说出来」。这比强行编一个答案安全得多。
4. 把幻觉降下来：检索、引用和提示词里的那道门
4.1 RAG 的核心不是「加资料」，而是让模型停止默写
RAG 的思路很简单：把相关知识库切成小块，提前做索引；用户提问时检索出相关片段，拼进 prompt，再让模型基于这些片段回答。
它的价值不只是给模型多塞参考资料，而是让模型从「默写训练记忆」切换到「根据眼前材料组织答案」。模型从记忆式召回改成上下文式生成之后，事实型幻觉会明显下降。
但 RAG 不是接上就能用。最常见的坑是检索结果本身质量差，模型被迫在错误上下文上作答。我建议把检索和生成分开评估：先看检索出来的 top-k 是不是真的相关，再看生成结果有没有忠实于检索片段。检索烂，后面生成怎么调都白费。
几个关键参数需要在你的语料上试：
- 分块大小：整篇文章塞进去容易造成上下文混乱，按段落或章节切分通常更可控。
- top-k：一般不用太大，3 到 5 个片段足够，具体看文档复杂度。
- 检索分数阈值：低于阈值时，宁可让模型说找不到，也不要强行塞无关内容。
4.2 把「不知道」写进系统规则，并且认真对待引用
提示词里如果没有「不知道」这个选项，模型就倾向于自己补一个答案。所以，系统规则里要把「不知道」变成合法且提倡的回答。
一个比较稳的 prompt 约束长这样：
你只能根据下面提供的材料回答问题。 如果材料中没有相关信息，请明确回答：根据现有材料无法确认。 不要编造引用，不要猜测。 如果多个来源内容冲突，请直接说明冲突，而不是自己选一个。注意，这里不要只写一句话，要写清楚「没有信息时怎么办」。模型需要的是一个行为分支，不是一个口号。
引用是另一个容易被忽视的点。光让模型「给出引用」还不够，你要在代码层面验证引用是否真实存在。方法是让模型输出带来源编号的答案，再拿编号去原始文档里比对，找不到对应片段就判为失败。
4.3 代码和结构化输出要用运行时验证兜底
代码幻觉和大段文本幻觉不太一样。模型可能生成一个函数，函数名、参数、返回类型看起来都合理，但对应库版本里根本没有这个 API。这种问题靠人眼很难一次发现，靠 prompt 也很难完全避免。
更有效的手段是运行时验证：代码生成后直接编译、跑单测、做类型检查；接口调用返回后先校验 JSON Schema；结构化输出不合法就触发重试，并附上错误信息。
格式合法不代表内容正确，两者一定要分开验证。模型生成了一个结构完整的 JSON 文档，里面某个字段却是编的，这在生产环境里比格式错误还难排查。
4.4 Agent 场景要额外加一道验证闸门
Agent 的麻烦在于动作链很长。第一步模型的错误判断会沿链路传播，后面每一步都可能被污染。最后模型输出了一个非常完整的结论，但起点就是幻觉。
所以 Agent 应用不能只在最后做一次内容校验，要在关键步骤上设闸门：
- 工具调用结果要落回到上下文，模型不能凭空引用工具输出。
- 检索不到结果时，Agent 要能主动说「这一步没找到」，而不是硬构造一个中间答案。
- 高风险操作，比如写文件、删数据、发消息、下单，必须有人工确认或强规则校验。
日志也要逐个环节记录：用户输入、工具输入、工具输出、模型中间推理、最终答案。出问题时，先定位幻觉是在哪一步进入链路的，而不是只盯着最后答案改 prompt。
5. 哪些幻觉能治，哪些只能忍
5.1 有源可查的事实型幻觉，是最值得投入资源处理的
如果问题本身有确定性答案，而且知识库里能查到来源，这类幻觉是最可控的。用 RAG 把相关材料送进上下文，要求模型只基于材料回答，再做引用校验，就能把无依据断言率压到很低。
这里有一个容易忽略的前提：来源本身要可靠。你检索到的资料如果是错的，模型在上下文约束下会把错误信息当成事实照搬。RAG 不负责判断内容真假，它只负责把「有没有依据」这件事变得透明。所以，知识库的更新、审核、权限管理同样重要。
5.2 模型记忆型幻觉和创造性生成，别用同一套标准治理
不是所有幻觉都能治好。模型自己记忆里的世界知识，尤其是知识截止时间之后的事实、长尾冷知识、极小众数据，单靠提示词很难根治。你让模型「不要幻想」，但它没有这个信息，只能选择说不知道或者继续编。
这种场景下，正确的做法不是无限优化 prompt，而是把任务边界划清楚：必须准确的事实型需求，一律走检索和外部验证；模型记忆可以用于候选生成，但不能作为最终结论。
反过来，在创意场景里，幻觉反而是价值。头脑风暴、故事片段、广告文案、技术方案候选，这些任务需要模型跳出常规生成新组合，不应该用事实评测标准去要求它。把内容和事实混在一起评测，最后只会得到一个既无聊又不可靠的模型配置。
5.3 高风险场景止损思路：宁可拒答，也不要编造
在医疗、法律、金融、产品合规、对外文档这类场景，幻觉的代价不只是用户体验差，而是可能带来实质性风险。我的原则很简单：拿不准的信息，宁可拒答，也不要给一个看起来专业但无法验证的结论。
产品设计上要配合做几件事：
- 高影响回答必须展示来源，让用户能追溯到原文。
- 重要内容标注「模型生成，未经人工审核」，别让用户误以为这就是官方结论。
- 收集用户对错误回答的反馈，持续回流到评测集。
拒绝率太高确实会影响产品体验，但它可以通过检索质量和知识库覆盖度来修正。比体验更难修复的，是一个在重要问题上言之凿凿但完全错误的回答。
6. 上线前盯住这几个信号
6.1 典型症状和排查顺序
幻觉问题的排查，不要一上来就甩锅给模型，按顺序走会快很多。
常见的症状是这几种：
- 回答看起来合理，但事实错误。
- 给出了引用，引用却根本不存在。
- 代码能生成，编译不过或者用了不存在的 API。
- 答案和用户提供的材料明显矛盾。
- 模型明明不知道，却拒绝承认不确定。
遇到这些情况，按顺序排查：
- 先看输入和检索上下文。检索结果是否相关、是否完整、有没有被截断，是第一个要确认的。
- 再看提示词约束。「不知道」有没有被写进规则，引用验证有没有落地。
- 然后看解码参数。温度是不是太高，最大 token 数是不是限制了回答。
- 再看模型本身。是不是旧版本，能力边界是不是已经被新版本覆盖。
- 最后回到评测集。把这条失败问题加进去，看同类问题还有多少。
大多数情况下，问题出在前两步：检索没召回相关内容，或者提示词没有给模型留出「不知道」的出口。
6.2 把幻觉回归测试放进日常迭代
幻觉治理不是一次性的，因为模型、知识库、提示词都在变。今天调好的答案，换一次模型版本可能又坏了。
我会建议在 CI 里放一条轻量的幻觉回归测试，改动下面任何一项就自动跑一遍：
- 更换模型版本或供应商。
- 修改系统提示词或 RAG 参数。
- 调整知识库的分块方式或索引结构。
- 上线新的 Agent 工具或新的结构化输出格式。
生产环境里再做一层抽样审计：随机抽一部分对话，看用户反馈、模型输出、检索来源是否一致。用户标记的「回答有问题」样本，直接进评测集，下一轮迭代优先修复。
最后说句实在话。踩过几次之后你会发现，很多幻觉问题不是单个模型能力问题，而是整个链路里没有给模型一个可靠的「知识来源」和「不知道」的出口。把这两件事补上，比反复换提示词有效得多。「I hallucinate, therefore I am」可以是一句玩笑，但它提醒我们的东西是认真的：幻觉会一直存在，我们要做的不是假装它不存在，而是让它在不该出现的地方失去生存空间。
