最近调试一个内部问答工具我问模型某个冷门 Python 库的调用方式它给了我一整段看起来完全正常的示例代码函数名、参数、返回值、写法风格都对得上。我差点直接复制进项目里。直到运行报错翻官方文档才发现那个函数根本不存在。更讽刺的是它接着又“解释”了一遍报错原因语气依然非常笃定。这种经历在 LLM 时代太常见了。所以当我在 Show HN 上看到那个标题——Life Of AI: I hallucinate. Therefore I am——第一反应不是觉得好玩而是觉得它准确得有点吓人。把笛卡尔的“我思故我在”改写成“我幻觉故我在”表面是个梗内里却摸到了大语言模型运行方式的真实内核幻觉不是模型偶尔抽风而是它存在的基本方式。理解这一点比单纯学会调用 API 重要得多。1. 这个标题不是玩梗它点破了 LLM 的工作本质1.1 从笛卡尔到概率生成存在方式变了笛卡尔那句“我思故我在”是用“思考”作为不可再怀疑的起点来论证人的存在。语言模型没有这个负担它没有“我”也没有“思”。它做的只有一件事在一段上下文之后预测下一个最可能的 token。但为什么不写成“我预测故我在”因为“预测”太中性掩盖了关键事实——模型输出的不是从数据库里查到的答案而是从概率分布里采样出来的文本。当这种文本和外部事实恰好一致时我们称之为“正确回答”当它形态上像事实、实际没有对应对象时我们叫它“幻觉”。项目标题选择“I hallucinate”其实是把生成式模型最容易被忽略的结构性特征放到了台面上。它提醒我们一个大语言模型不可能做到“不产生幻觉”就像一台内燃机不可能不发热。幻觉不是附带缺陷而是生成这个动作本身的副产品。你只要让模型开口就同时在制造幻觉的可能性。1.2 幻觉不是模型“抽风”而是生成的结构性副产品很多用户对 LLM 的预期来自搜索引擎我提问你返回真实存在的页面。但 LLM 没有“查询事实”这个步骤它只有“继续生成”。训练阶段它从海量文本里压缩出语言规律推理阶段它按概率续写最像样的回答。这里就出现了一个必须接受的事实模型内部没有一个“事实表”。你问“北京是哪个国家的首都”它能答对不是因为它在内部翻到了那行记录而是因为“北京”和“中国首都”这个组合在训练语料里高频共现让它生成了正确内容。高频知识被训练语料反复强化所以答对率很高低频知识、新知识、混合噪声它就更容易按“最像的趋势”补全。这种补全一旦偏离事实就是我们看到的幻觉。它不是坏了而是模型在不确定的情况下仍然按照语言惯性完成了输出。所以后面我们要讨论的不是“怎么让幻觉归零”而是“怎么让幻觉落在可控范围”。2. 幻觉是怎么悄悄生成的2.1 表征误差训练语料里的“模糊地带”语言模型学到的不是世界而是世界在语料里的投影。真实世界里某个事实清楚明确但语料里的描述可能是含混的、矛盾的、过时的。模型压缩这个投影时会把相似写法归并到一起于是细节被平均化、边缘情况被抹平。当你问一个模型训练数据里本来就分布模糊的问题时它没有能力“想起来”只能从分布里挑一个最可能的形态。表现就是一个不存在的函数名因为它看起来很符合命名习惯一个不可能的人名因为它与上下文搭配起来很顺。幻觉从这里就开始有了苗头。2.2 上下文不足与表达压力模型不想说“我不知道”另一个常见来源是上下文不足。如果提示词里的信息不够模型缺少判断依据它的默认策略不是拒绝回答而是补充一段看似合理的推断。这背后有个容易被忽略的机制语言模型在训练时被教化成“继续文本生成”而不是“判断自己对不对”。它没有内置的“我知识库里没有这个”按钮。即使系统提示词里写了“不确定就说不知道”如果训练权重里“给出完整连续回答”的模式更占优势模型仍然可能选择编一个答案。这也是为什么“强制拒绝”不能靠一句提示词解决需要在工程链路里单独设计。2.3 采样参数、知识时效与本地部署精度幻觉程度还受三类因素影响每一个都值得单看采样参数temperature 调高输出更随机幻觉更容易出现temperature 压低输出更保守但只是降低概率做不到根除。top_p 同理它控制候选词的累计范围范围越大越可能出现意外选项。知识时效模型有训练截止时间截止之后的事件、新版本 API、新发布的库它全都没有见过。它又不会主动意识到这一点只能用截止时间附近的“印象”硬补。所以涉及新版本、新接口、新法规时幻觉率会显著上升。本地部署精度自己部署开源模型时如果为了省显存做了量化比如从 fp16 压到 int8、int4精度损失会影响输出分布推理阶段的随机性也会变大。不是说量化一定会导致幻觉但在事实型任务里尽量保留更高精度的权重并做足小样本对比。2.4 幻觉来源速查表来源触发条件典型表现常见对策表征误差领域冷门、语料冲突编造不存在的函数、人名、术语检索增强、限定领域模型上下文不足提示词信息含糊给出一段看似合理的推断补足上下文、要求引用原文采样随机高 temperature、top_p 过大创意输出跳跃、细节偏离事实任务压低 temperature知识时效训练截止时间之后的事件过时版本、已废弃 APIRAG 注入最新资料本地精度量化压缩、显存不足低频词错误、逻辑链条断裂使用高精度推理、分批处理3. 幻觉是毒药还是资产取决于场景3.1 事实型任务里幻觉是真实的成本在医疗建议、法律条文、财务数字、合规判断这类场景里一段流畅的幻觉输出可能带来直接损失。代码开发也属于高风险区模型能给出语法正确的代码但逻辑可能是错的依赖可能是不存在的。如果你把“代码能跑”当成“答案正确”很快就会被坑。工程经验里这类任务不能把 LLM 的输出直接当最终结果。要把它当草稿、当候选方案必须经过编译、测试、人工 review 或权威来源校验。流程设计上也要把“验证”做进每一步而不是在最后统一检查。3.2 创意型任务里幻觉恰恰是价值同样是“偏离事实”放到创意场景就完全反转。写文案、做头脑风暴、设计角色、编科幻设定、起名字、讲故事这些任务本来就需要跳出已知事实产出新的组合。模型的“合理编造”在这里不是缺陷而是生产能力。那个 Show HN 的标题本身就属于这种场景。它没有说“我存储了知识因此我存在”而是说“我能产生新的、甚至不存在的可能性因此我存在”。对一个创意型 AI 项目来说这个定位反而是最有价值的部分。3.3 用一个三级风险表来判断该怎么用判断一个场景能不能直接使用 LLM 输出我会先看三级风险风险等级典型场景使用方式必要措施高医疗、法律、财务、安全、合规只能辅助参考人工复核、权威源校验、禁止自动执行中代码、配置、技术文档作为草稿或脚手架编译验证、单测、人工审阅、引用来源低文案、命名、头脑风暴、娱乐直接可用人挑选、人润色、创意方向把关这个表不是绝对标准但能帮你快速建立判断低风险场景放开跑中风险场景加验证高风险场景必须在链路里塞入人工兜底。很多人踩坑不是因为模型不够强而是把中风险、高风险任务当成了低风险任务。4. 工程上如何与幻觉共处不消灭重管理4.1 从最小样例开始先跑通再谈优化不管你是做简单的 API 调用还是搭一个 Agent 应用我的建议都是从最小流程开始。单个 prompt、单条样例、一次手动检查输出。确认输入、输出、日志都正常再考虑批量、并发和复杂编排。原因很简单LLM 应用的错误是级联的。你写 30 条 prompt 一次性批量跑结果里面混了 5 条幻觉输出你很难判断是哪一步引入的。先跑通一条再小批量跑出了问题能缩小范围。这也是很多入门者最大的误区——一上来就搭了非常复杂的 Agent、RAG、多步工具调用框架结果错的时候根本不知道错在哪一环。4.2 RAG 的作用是“加锚点”不是“装滤网”很多资料把 RAG 说成是解决幻觉的方案这里要换个更准确的说法RAG 不是过滤幻觉的滤网而是给文本生成加上锚点。做法本身不复杂先把你自己的文档切块、向量化存起来用户提问时先检索出和问题相关的文本片段把这些片段连同问题一起交给模型同时要求它优先基于片段回答并给出引用来源。加入锚点之后模型输出的依据从“训练时的模糊印象”变成了“当前检索到的具体文本”。这能显著降低幻觉尤其是涉及新知识、内部资料、私有文档时。但它不能完全消除幻觉原因有三个检索本身可能不准召回的是不相关内容模型被错误信息带偏切块方式会影响召回质量块太碎丢上下文块太大容易混入噪声模型在上下文冲突时可能不遵循“只看片段”的指令仍然去使用训练时的先验知识。所以 RAG 落地时要配套做三件事检查检索结果的 top-k 相关性、在 prompt 里明确“片段中没有的内容就回答不知道”、把引用来源一起输出方便人工回查。4.3 参数与输出约束第二道控制闸如果 RAG 是第一道关卡参数和输出格式就是第二道。事实型任务里我会先把 temperature 调到 0 到 0.3 之间。调低不是让模型“变得更聪明”而是让它在每个 token 上尽量选概率最高的那个减少随机跳跃。温度越高候选分布越平越容易出现结构上合理但事实上偏移的内容。另一个更实用的小技巧是要求结构化输出。用 JSON Schema 或者明确的输出格式把回答的范围约束住。比如让模型返回一个包含answer、source、uncertainty三个字段的对象并明确告诉它source 必须来自给出的检索片段uncertainty 超过阈值就写“unknown”。这等于在格式层给幻觉设了边界。4.4 一套可复用的排查链路当模型输出不对劲时不要急着换 prompt。按下面这个顺序排查能省下大量时间看现象是事实错误、格式错误、编造内容还是信息过时先把错误分类。看输入prompt 是否含糊字段缺失系统指令有没有被用户输入覆盖看检索RAG 召回的相关性分数如何切块有没有混入无关内容引用来源对不对看参数temperature、top_p、max_tokens 在什么水平是否对当前任务过松或过紧看环境本地部署的精度是多少显存够不够是不是量化导致推理异常看模型边界这个问题是否已经超出模型的知识截止时间有没有必要换一个更合适的模型这套链路的关键是把幻觉从“无法解释的玄学”变成“可以定位的问题”。你能说出是哪一层引入的错误才有机会在哪一层修。5. 管理幻觉才是 AI 应用的分水岭5.1 接受幻觉率不会归零设计兜底机制事实是只要使用生成式模型幻觉率就不会是零。哪怕有 RAG、有引用、有参数约束依然存在模型把检索片段理解歪、或者自信地用先验知识覆盖片段内容的可能。所以工程上的核心问题不是“怎么消灭幻觉”而是“幻觉来了系统怎么兜住”。常见做法有三种一是设置置信度阈值模型不确定时直接拒绝回答二是低风险场景自动处理高风险场景转人工三是把所有输入输出和引用来源记录成日志出问题之后能复盘、能追踪。这三种做法单独看都不复杂但很多小团队第一版都不做。结果是模型上线后偶尔翻车一次业务方就判定“AI 不可用”。问题不在于幻觉本身而在于没有兜底设计。5.2 评估集、护栏、人工复核三件套长期使用 LLM 的项目我建议尽早补上三件套评估集准备一组覆盖典型问题和边缘情况的测试样例每次改 prompt、换模型、调参数时都跑一遍对比答案质量和幻觉率。没有评估集你就没法知道自己是在改进还是在回退。护栏在前置和后置环节加规则。前置判断问题领域是否允许放行后置做关键词过滤、格式校验、引用完整性检查。这不复杂但能挡住大量低级错误。人工复核高风险场景必须保留人工确认节点。所谓“人机协同”不是一句口号而是流程图上明明白白的一个审核框。用这三件套把幻觉从“不可控风险”降级成“可管理风险”这一步才是 AI 应用能不能长期跑下去的分水岭。5.3 回到标题重新定位 AI 在流程中的角色回到那个标题“I hallucinate. Therefore I am”最值得反复琢磨的地方是它改变了我们看待 AI 的方式。它不是存储知识的图书馆不是检索信息的搜索引擎更不是没有感情的数据库。它是一个擅长生成“最像样可能性”的系统。它的存在方式决定了它适合扮演的角色给出草案、提供候选、打开思路、加速初稿。而人的角色是负责验证、判断、取舍把可能性收敛成确定的现实。想清楚这一层很多产品设计的问题会变得简单。你不再期待模型永远正确而是会设计一套让错误可以被发现和修正的流程你不再抱怨“它怎么又乱编”而是会把“乱编”当成一个需要管理的行为。幻觉不是在模型背后它就在模型体内。真正有用的做法是把它放进系统设计里给每一步生成配上锚点、边界和验证回路。这样那句“我幻觉故我在”就不再是一个玩笑而是一条还算可靠的产品原则。