“我幻觉故我在。”如果你在 Hacker News 或者技术社区刷到过这个标题多半会先笑一下然后停下来想几秒。这个句式借用了笛卡尔的“我思故我在”但把“思考”换成了“幻觉”。乍看像一句玩笑话但它其实精准戳中了当前大模型最让人头疼、也最值得深思的一个特性AI 会一本正经地编造事实。很多刚接触大模型开发的工程师第一次被幻觉坑到的场景都差不多让模型根据公司内部文档生成一份周报结果它把某个项目进度写得煞有介事实际上那个项目还没立项让模型写一段 SQL它生成了一个根本不存在的表名让模型解释某个开源库的 API它给出的用法和真实文档完全对不上。这时候你的第一反应通常是“模型是不是坏了”但如果你真正去读模型原理和技术讨论会发现事情没那么简单。这篇文章想围绕“Life Of AI: I hallucinate. Therefore I am”这个标题认真聊一聊 AI 幻觉这件事。我不会只停留在“幻觉是错误”这个层面而是会把幻觉放到大模型的工作原理、工程实践和产品设计三个维度去拆解。读完这篇文章你会理解幻觉为什么无法被彻底消除、它在哪些场景下会造成严重问题、哪些场景下反而是模型能力的体现以及在实际项目里应该用什么工程手段去检测和缓解幻觉。1. 这篇文章真正要解决的问题先说一个判断幻觉不是大模型的 bug而是大模型当前工作方式的必然结果。你可以通过工程手段降低幻觉出现的概率但你无法在架构不变的情况下彻底消灭它。理解这一点比学会某个具体的提示词技巧更重要。为什么这件事值得专门写一篇文章因为现在 AI 应用已经进入了工程化阶段越来越多的团队开始把大模型接入核心业务链路。Chatbot 答错一道常识题用户笑一笑就过去了但如果是智能客服给出了错误的退换货政策、AI 编程助手生成了存在安全漏洞的代码、法律 AI 助手引用了一个根本不存在的判例问题就严重得多。幻觉从一个学术概念变成了一个实打实的工程风险。很多团队在项目初期并不会把幻觉当回事因为他们测试的时候用的是精心设计的 Prompt模型的输出看起来非常合理。但一旦进入生产环境输入变得多样化、上下文变长、用户开始故意刁难模型幻觉就会以各种意想不到的方式冒出来。这时候再回头补课代价往往比想象中大得多。这篇文章适合以下几类读者正在用大模型开发应用的工程师尤其是做 RAG、Agent、智能客服方向的人。需要给团队制定 AI 使用规范或评测流程的技术负责人。对大模型感兴趣想理解“AI 为什么说胡话”的产品经理和测试人员。被 AI 幻觉坑过、想搞清楚底层原因的技术爱好者。我会从原理讲到实践最后给出一个可以在自己项目里落地的幻觉检测与缓解方案。建议收藏备用尤其是第五到第八节遇到实际问题时可以直接回来查。2. “我幻觉故我在”从笛卡尔到大模型的本质“I hallucinate. Therefore I am.” 这句话的精妙之处在于它把大模型的“存在方式”重新定义了。笛卡尔说“我思故我在”是在寻找一个不可怀疑的基点我可以怀疑一切但我正在怀疑这件事本身是确定的。而大模型呢它不思考它在做的事情是——基于上下文预测下一个最可能出现的 Token。这个预测过程天然就包含了“创造”的成分。要理解 AI 幻觉就必须先接受一个事实大模型本质上是一个极其复杂的概率系统。它不是一个数据库不是搜索引擎也不是一个严格按照规则推理的逻辑引擎。它学习的是海量文本中的统计规律然后在生成时按照概率采样一个词一个词地往外蹦。这就引出了一个关键结论模型输出内容的“真实性”从来不是它生成时的直接目标。模型的目标是“生成一段在统计上很像人类会写的文本”。如果它在训练数据里见过大量“某产品在 2025 年发布”的句式当用户问“某产品什么时候发布”它就会倾向于生成一个看起来合理的年份哪怕这个年份是编的。“我思故我在”对应的是确定性而“我幻觉故我在”对应的是概率性。大模型不会因为“想清楚”而存在它因为“预测并生成”而存在。而预测这件事永远伴随着错误率。有一个类比可以帮助理解把大模型想象成一个特别擅长即兴表演的演员。它接受过大量“剧本”训练知道什么样的台词听起来合理什么样的剧情走向符合逻辑。但当你给它一个没有背过的题目时它不会说“我不知道”它会基于自己的经验现场编一段。编得好你感觉这演员真有才华编得不好就成了幻觉。所以幻觉的本质可以概括为模型在训练目标、有限知识和生成方式三重约束下给出的“最优猜测”与事实不符。3. 幻觉的分类与工程影响在实际项目中谈论“幻觉”太笼统因为不同类型的幻觉对业务的影响完全不同。按经验可以把幻觉分成四类幻觉类型表现典型场景危害程度知识性幻觉模型编造不存在的实体、数据、事件产品问答、行业分析高逻辑性幻觉推理过程跳跃结论与前提矛盾数学题、代码逻辑中高指令性幻觉模型没有按用户指令执行自行发挥格式转换、内容提取中上下文性幻觉忽略或曲解上下文中的关键信息长文档问答、多轮对话高知识性幻觉是大家最熟悉的。比如问模型“某某开源项目是谁发起的”模型可能给出一个真实存在但完全无关的人名因为它在训练数据里见过类似格式的问答。这类幻觉在垂直领域尤其危险因为模型对专业领域的知识覆盖度远不如通用领域。逻辑性幻觉在代码生成场景中表现突出。模型可能生成一段语法完全正确、但业务逻辑完全错误的代码。更麻烦的是它能给出一个煞有介事的解释让你以为它真的考虑过边界条件。指令性幻觉在 Agent 场景中越来越常见。当你让 Agent“只提取指定的三个字段”时它可能额外输出一个四字段的表因为它觉得四个字段更完整。这种幻觉不涉及事实错误但会破坏流程的稳定性。上下文性幻觉是最隐蔽的。在长文档问答中如果文档里同时出现了两个版本的方案描述模型可能会混在一起生成一个既不是 A 也不是 B 的答案。这种错误很难通过检索质量来规避因为信息确实在上下文里只是模型没有正确组织。从工程角度看幻觉导致的直接后果是信任成本上升。为了避免 AI 输出错误信息团队必须在模型外层增加校验、过滤、人工审核等机制。这些机制本身需要开发成本、运行成本和延迟成本。所以评估一个 AI 应用能不能落地不只是看模型能力更要看本地能不能用工程手段把幻觉风险压到业务可接受的范围。4. 核心原理为什么模型会一本正经地编造事实前面说了幻觉是概率系统的必然结果这一节再从技术角度稍微展开讲清楚三个具体原因。对工程师来说理解原因才能对症下药。4.1 训练目标不是“求真”大模型训练时采用的损失函数本质上是在优化“预测下一个 Token 的准确率”。它没有单独一项叫做“事实性损失”。监督微调阶段虽然用人工标注的数据做了对齐但数据的覆盖面有限模型无法学会“区分我知道和不知道”。换句话说模型从来没有被训练成“不知道就承认不知道”。它被训练成“尽最大可能给出一个合理的回答”。这个“合理”指的是语言上的自然流畅不是事实上的正确。4.2 知识存储方式是分布式的大模型没有数据库表没有知识图谱它的知识是以参数形式分布在神经网络里的。当它回答一个问题时它不是在“查询知识”而是在“根据问题激活相关参数模式”。这种方式的好处是泛化能力强坏处是知识之间会产生干扰。比如模型可能在训练数据里看过“苹果公司总部在库比蒂诺”也看过“苹果是一种水果”当问题比较模糊时模型可能把两种信息混淆。这种混淆在人类身上也会发生但人类的记忆有明确的上下文索引而模型的参数没有这种索引。4.3 解码策略为了“多样性”牺牲了“确定性”生成阶段通常使用 Top-p 或 Temperature 采样目的是让输出不那么死板增加多样性。但多样性本质上就是不确定性。同一个问题Temperature 设成 0.7跑五次可能得到五个版本其中有些版本是幻觉有些不是。这里有一个工程上常见的两难Temperature 设得太低输出变得机械、重复、缺乏创造性设得太高幻觉频率明显上升。你需要根据业务场景取一个平衡而不是追求某一个极端值。理解了这三个原因你就能明白为什么“提升模型能力”和“解决幻觉”不是一回事。模型能力再强它的生成机制仍然基于概率采样它仍然会在知识边界处编造。你可以做的是让模型更少地进入它不知道的区域以及在它进入后通过工程手段识别出来。5. 动手实验用最小示例复现一次 AI 幻觉纸上谈兵没有意义。下面我们做一个可控复现实验目的是亲眼看看幻觉是怎么产生的以及 Temperature 参数对幻觉频率的影响。假设你已经在本地装好了 OpenAI SDK 或者兼容 OpenAI 接口的国产大模型 SDK文心、通义、DeepSeek 都可以接口格式基本一致。以下代码使用 Python 编写核心逻辑是让模型回答一个大概率超出其知识范围的问题。# 文件路径hallucination_demo.py # 依赖安装pip install openai from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://api.your-provider.com/v1 # 按你的服务商配置OpenAI 官方可去掉 ) def ask_model(prompt: str, temperature: float) - str: response client.chat.completions.create( model你的模型名称例如 gpt-4o-mini 或 qwen-plus, messages[ {role: system, content: 你是一个乐于助人的助手。}, {role: user, content: prompt} ], temperaturetemperature, ) return response.choices[0].message.content if __name__ __main__: # 故意问一个模型不可能知道精确答案的问题 prompt 请介绍一本书《AI 幻觉大全》的作者和第一章的标题。 print( Temperature 0.2 ) for i in range(3): print(f第 {i1} 次回答: {ask_model(prompt, temperature0.2)}) print(- * 40) print( Temperature 0.9 ) for i in range(3): print(f第 {i1} 次回答: {ask_model(prompt, temperature0.9)}) print(- * 40)运行这段代码你大概率会看到两类结果模型承认自己不知道这本书并建议你查询资料。模型非常流畅地编造了作者的名字和章节标题语气笃定像真事一样。第二种结果就是典型的幻觉。你会注意到Temperature 越高编造的概率越大而且编造的内容“发挥空间”更大。这个实验虽然简单但它揭示了两个工程要点幻觉不是偶发异常而是模型在特定条件下稳定出现的输出行为。同样的 Prompt同一模型不同参数会产生不同结果。所以在生产环境中固定生成参数是基础要求不能每次调用都临时调整。6. 幻觉检测如何在系统里发现幻觉检测幻觉是降低幻觉危害的第一步。幻觉检测不是 100% 准确的但足够在多数场景下把风险降一个量级。目前常用的检测方法有三类6.1 基于事实库的规则校验如果模型输出可以结构化为事实三元组、关键实体、数值等就可以用规则去比对。比如让模型生成“某某公司成立于某年”你用一个公司信息库做校验年份对不上就判定为幻觉。这种方案适合垂直领域、输出结构固定的场景。优点是准确率高缺点是需要维护事实库且只能覆盖可枚举的事实。6.2 基于 LLM-as-a-Judge 的语义一致性检测用一个更强的模型或者同一个模型去判断两个回答是否语义一致。方法是对同一个问题生成多次回答或者让回答内容与检索到的文档片段做对照然后由 Judge 模型判断是否存在矛盾。下面是一个简化示例展示如何让 Judge 模型判断单条回答与参考文档是否一致# 文件路径judge_consistency.py from openai import OpenAI client OpenAI(api_keyyour-api-key) def check_consistency(reference: str, answer: str) - str: prompt f 你是一个严格的事实一致性检测员。请判断“回答”中的内容是否与“参考文档”一致。 只输出“一致”或“不一致”不要输出其他内容。 参考文档 {reference} 回答 {answer} response client.chat.completions.create( model你的模型名称, messages[{role: user, content: prompt}], temperature0.0, # 判题模型建议低温度 ) return response.choices[0].message.content.strip() if __name__ __main__: reference 根据公司公告XX 产品将在 2025 年 6 月上线支持多人协作和离线模式。 answer XX 产品将在 2025 年 6 月上线主要功能包括多人协作。 print(check_consistency(reference, answer))Judge 模型温度必须设成 0否则判题结果也会不稳定。这种方法适合有一定开发能力的团队因为需要设计 Prompt、处理输出格式并且要评估 Judge 模型本身的判题准确率。6.3 基于概率与不确定性分析模型在生成低概率 Token 时往往意味着它在“猜”。可以获取生成 Token 的 logprob设置一个阈值当平均 logprob 低于某个值时触发人工审核。这个方案的缺点是需要模型 API 支持返回 logprob不是所有服务商都开放这个接口。而且 logprob 与幻觉并不完全线性相关只能作为辅助信号。实际项目中建议采用分层检测第一层规则校验拦截可枚举的结构化错误。第二层LLM Judge 做语义一致性检测。第三层低置信度问题转入人工审核。7. 降低幻觉的工程方案与完整示例检测是发现问题缓解是减少问题的发生。下面分享四个在项目中验证过有效的方案。7.1 检索增强生成RAGRAG 是当前降低幻觉最主流的方案。核心思路是在自己的知识库中检索与问题相关的片段把片段拼接进 Prompt让模型基于这些片段回答而不是完全依赖参数里的知识。这种方式不是消除幻觉而是把模型回答的“依据”从内部参数转移到外部资料上。模型仍然可能编造但编造空间被大幅压缩。一个最小可用的 RAG 流程可以这样实现# 文件路径simple_rag.py # 依赖安装pip install openai from openai import OpenAI client OpenAI(api_keyyour-api-key) # 模拟一个极简知识库 knowledge_base [ 公司规定请假天数大于等于 3 天需要提前两天提交申请并获得直属上级审批。, 公司规定笔记本电脑使用年限达到 4 年可以申请更换。, 公司规定每月最后一个工作日为设备维护日所有员工需要保存工作并关闭电脑。, ] def simple_search(query: str, docs: list) - str: 简化的检索函数实际项目请使用向量数据库或 Elasticsearch。 query_words set(query.replace(?, ).split()) best_doc None best_score -1 for doc in docs: score len(query_words set(doc.replace(?, ).split())) if score best_score: best_score score best_doc doc return best_doc or 未找到相关资料 def rag_answer(question: str) - str: context simple_search(question, knowledge_base) prompt f 请基于以下资料回答问题。如果资料中没有相关信息请直接回答“资料中未找到相关信息”不要自行推测。 资料 {context} 问题{question} response client.chat.completions.create( model你的模型名称, messages[{role: user, content: prompt}], temperature0.3, ) return response.choices[0].message.content if __name__ __main__: print(rag_answer(我想请假 4 天需要提前几天申请))这个示例中的检索函数只是示意真实项目中应该使用向量检索。但核心思想是一样的先检索再回答并把“资料中没有相关信息”作为显式选项给模型。7.2 显式拒答提示很多模型的幻觉来自“过度顺从”。用户问什么它就答什么即使它不知道也要给一个答案。通过在 System Prompt 中明确允许模型拒答可以显著降低低质量编造。可以这样写 System Prompt你是一个企业知识库助手。 回答规则 1. 只有资料或上下文中明确包含的信息才能作为回答依据。 2. 如果问题超出你的知识范围请直接回答“这个问题我暂时没有可靠答案”。 3. 不允许猜测、推测或编造事实。 4. 回答时标注信息来源例如“根据《员工手册》第 3 章”。不要小看这条提示。模型的对齐训练让它倾向于“有帮助”你需要在提示词中明确“知道边界也是一种帮助”。7.3 少样本示例Few-shot给模型一两个“拒绝编造”的对话示例让它模仿。比如用户公司团建经费标准是多少 助手抱歉我没有在《员工手册》中找到团建经费的具体标准。建议你咨询行政部或查看 OA 系统里的最新通知。 用户年假可以累积到明年吗 助手根据《员工手册》第 5 章年假不可跨年度累积请在当年 12 月 31 日前使用完毕。这种方式的原理是让模型在生成时有一个“行为锚点”尤其是当示例展示了“承认不知道”并不是错误回答后模型的拒答概率会明显上升。7.4 降低 Temperature 与限制输出长度把 Temperature 从 0.7 降到 0.2 或 0.1能减少无根据的自由发挥。虽然会牺牲一些多样性但在知识问答、代码生成、信息提取等场景下稳定性优先于多样性。同时限制 max_tokens 也能间接降低幻觉风险。输出越长模型越容易在后面开始“编圆”。如果你只需要一个短结论不要给模型留太多发挥空间。8. 幻觉评测如何量化你的系统靠不靠谱平时“感觉模型回答变好了”不够工程落地需要量化指标。推荐建立一个小型评测集里面包含三类样本有明确答案的问题可以判断对错。知识范围内但模型容易混的问题。超出知识范围、期望模型拒答的问题。对每一条样本人工标注期望的“回答模式”问题类型样例合格标准有明确答案公司年假标准回答中包含正确标准容易混淆和 A 功能相比B 功能的区别不混入 C 功能的描述超出范围公司明年营收预测明确拒答不编造数字评测时可以用一个独立的评测脚本批量调用系统并根据输出判断是否通过# 文件路径eval_hallucination.py from openai import OpenAI client OpenAI(api_keyyour-api-key) test_cases [ { question: 公司年假标准是什么, keyword: 根据员工手册, expect_refuse: False }, { question: 公司明年营收预测是多少, expect_refuse: True }, ] def run_eval(): passed 0 for case in test_cases: response client.chat.completions.create( model你的模型名称, messages[{role: user, content: case[question]}], temperature0.2, ) answer response.choices[0].message.content if case.get(expect_refuse): ok (没有可靠答案 in answer) or (未找到 in answer) else: ok case.get(keyword, ) in answer passed 1 if ok else 0 print(f问题: {case[question]}) print(f回答: {answer}) print(f判定: {通过 if ok else 未通过}) print(- * 40) print(f得分: {passed}/{len(test_cases)}) if __name__ __main__: run_eval()这个脚本非常简陋但结构可以复用。建议每调整一次 Prompt、模型版本或参数都跑一遍评测集用评分说话而不是靠肉眼观察几条测试结果。9. 常见问题与排查方法在实际项目中团队经常会遇到下面这些问题。整理了一个排查表可以直接对照处理。问题现象可能原因排查方式解决方案RAG 后仍然幻觉检索到的上下文与问题无关打印检索结果检查召回内容优化向量索引、增加 rerank模型拒绝所有问题System Prompt 太严格检查被拒的问题是否确有答案调整拒答条件增加判断依据同一个问题有时答对有时答错Temperature 过高多次运行并对比 logprob调低 Temperature 到 0.2 以下模型编造引用或链接知识边界外请求检查输出中引用来源增加引用校验或强制不提供链接长文档问答中混淆两个实体上下文过长注意力分散分段检索并限制上下文长度对文档做摘要或分块处理评测得分一直上不去评测集设计不合理检查标注是否有歧义建立清晰的评分标准这里单独强调一下 RAG 的检索质量问题。在很多项目里幻觉的真正原因不是模型不行而是检索结果太差。如果检索出来的上下文本身就包含不相关内容模型很容易被带偏。比如用户问“请假规则”检索结果却混进了一条“报销规则”模型就可能把报销规则也当成请假规则来讲。解决这个问题靠调 Prompt 是没用的应该去优化检索链路比如用混合检索、做轻量级 rerank 或调整分块粒度。另一个常见问题是“模型回答太保守”。有些团队把提示词写得太严格结果模型对自己明明知道的事也回答“没有资料”。这种情况不是幻觉问题而是拒答过度。要平衡建议在评测集中同时加入“应拒答样本”和“应回答样本”分别看拒答准确率和回答准确率。10. 最佳实践与工程建议结合多个项目的落地经验给出以下建议。10.1 从设计上假设模型会出错不要把大模型当作可靠的知识源而是把它当作一个“擅长表达但需要监督的实习生”。所有关键输出都要有校验层。具体来说知识问答场景强制模型标注信息来源。代码生成场景把生成结果接入单元测试和代码扫描而不是直接信任。数据提取场景用正则或 JSON Schema 校验输出格式格式不符就重试或降级。高风险决策场景加入人工审核环节。10.2 保留完整的日志与可追溯性每条模型请求都要记录模型名称、版本、Temperature、Prompt、上下文、输出、耗时。这不仅是排查问题的依据也是后续评测和优化的数据基础。很多团队只在出问题时才想到日志但那时没有数据可以追溯只能靠猜。10.3 建立 Prompt 和模型版本管理项目中会频繁调整 Prompt 和模型版本。建议把 Prompt 视为代码纳入 Git 管理。每次修改 Prompt 或切换模型都跑一遍回归评测。否则你很可能出现“昨天还好好的今天突然变差了”的情况而根本不知道是哪次变更造成的。10.4 安全边界与最小权限思维如果你在做 Agent 或自动化流程要特别警惕“幻觉导致误操作”。例如 Agent 根据幻觉生成了一个不存在的文件路径然后直接执行删除操作后果会很严重。建议所有 Agent 的写操作和删除操作默认设置为需人工确认状态。使用工具调用前对工具参数做 Schema 校验。在生产环境设置频率限制和操作白名单。所有变更先在小范围灰度观察输出质量后再全量放开。10.5 关注模型版本更新对幻觉率的影响同一个 Prompt升级模型版本后幻觉率可能上升也可能下降。不要假设新版本一定更好。每次升级前都要跑评测集用数据说话。在部分场景中宁可继续使用旧版本也不要为了“新”而升级。11. 关于“AI 会不会永远幻觉下去”的思考回到文章标题“I hallucinate. Therefore I am”。如果未来模型不再幻觉了那它还是我们现在说的“AI”吗一个不会幻觉的模型意味着它只能输出完全确定的、可验证的内容。它不再是一个生成模型而变成了一个查询系统。这当然更安全但也意味着它失去了创造性——包括写诗、编故事、头脑风暴、提出假设这些能力。你会失去“幻觉”同时也会失去“想象力”。所以对于工程应用来说目标不是“消灭幻觉”而是“在需要创造力的地方允许幻觉在需要准确性的地方控制幻觉”。同一套底层模型通过不同的 Prompt、参数和外挂机制完全可以做到两种模式切换。比如一个面向内部员工的知识问答系统严格模式可以设定为“只允许引用 RAG 检索到的内容”而一个创意文案助手则可以把自由度调高让模型发挥。从技术演进看更现实的路径是用模型自我一致性校验、外部工具调用、知识图谱对接等方式把幻觉的后果限制在可控范围内。模型还是那个会“即兴发挥”的模型但系统架构可以在它周围建起围栏。12. 总结与后续学习方向这篇文章从“我幻觉故我在”这个表达切入讲了 AI 幻觉的原理、分类、工程影响和缓解方案。核心结论是幻觉不是单纯的 bug而是概率生成系统的固有属性。工程上要做的是理解它、检测它、限制它而不是指望它彻底消失。如果你正在做 AI 应用开发下一步可以按这个顺序实践先搭一个最小评测集量化当前系统的幻觉水平。用第五节的示例复现一次幻觉感受参数的影响。如果你的场景是知识问答优先做 RAG并确保检索质量达标。在关键输出链路上加入规则校验或 LLM Judge。记录日志、管理 Prompt 版本让每一次变更都可回溯。值得继续深入的方向包括向量检索与重排的工程优化、基于 logprob 的幻觉置信度分析、Agent 场景下的工具调用安全、模型微调对幻觉率的影响。每个方向都可以单独写一篇长文展开。幻觉不该是 AI 的耻辱而是它另一种存在的证据。你接受它但你也要管住它这才是 AI 工程化的真实状态。