一、一句话先说清楚什么是大模型幻觉大模型幻觉Hallucination就是模型生成了看似合理、语气自信、但实际上事实错误或与给定信息矛盾的内容。翻译成人话——大模型在一本正经地胡说八道。问你一个可能亲身经历过的场景你让 GPT 写一段调用某个 API 的代码它煞有介事地给出了一个函数名client.createSuperResource(params)参数、返回值、异常处理一应俱全看起来专业极了。你复制粘贴进去一跑——AttributeError: Client object has no attribute createSuperResource。翻一遍官方文档压根没这个方法。这就是幻觉。它不是 Bug不是崩溃不是拒绝回答——它是模型编了一个看起来完全合理的东西而且自己深信不疑。更准确地说幻觉有三个核心特征流畅性——语言通顺、结构完整、语气自信看不出任何出错的痕迹虚假性——内容与事实不符或与用户提供的上下文矛盾无意识性——模型并非有意欺骗它自己也不知道答案是错的第三点最关键模型不是在撒谎它是在做梦。它没有恶意只是把概率最高的下一个词拼了出来恰好拼出了一条不存在的事实。二、幻觉到底有多严重先看几组数据OpenAI 内部测试显示GPT-4 在事实性问答上的幻觉率约为3%~5%听起来不高但意味着每 20 个问题就有 1 个可能被编造的答案误导在代码生成场景研究显示 LLM 生成的代码中约30%~50%存在不同程度的 API 幻觉虚构函数名、参数、返回值结构一项面向开发者的调查显示72%的受访者表示曾因 LLM 幻觉导致代码 Bug 或生产事故在医疗、法律等高风险领域幻觉可能导致错误诊断、错误法律建议后果不堪设想2023 年有一个著名案例美国律师 Steven Schwartz 使用 ChatGPT 撰写法律文书ChatGPT 虚构了 6 个不存在的判例连案号、判决日期、法官名字都编得有模有样律师直接提交给了法庭。结果被法官发现律师面临 disciplinary hearing。这个案例完美诠释了幻觉的可怕之处它专骗信任它的人。越是缺乏专业背景验证能力的人越容易被幻觉忽悠。三、幻觉的分类不是所有说错都叫幻觉学术界通常把幻觉分为两大类理解这个分类非常重要——因为两类幻觉的成因和解法完全不同。3.1 事实性幻觉Factual Hallucination模型输出了与现实世界事实不符的内容。典型表现爱因斯坦于 1921 年获得诺贝尔物理学奖获奖理由是相对论。——前半句对后半句错实际获奖理由是光电效应不是相对论Python 的list.sort()方法返回排序后的新列表。——错它原地排序返回NoneHTTP 状态码 418 表示服务器内部错误。——错418 是 Im a teapot一个愚人节彩蛋这类幻觉的特点是答案可以被外部事实验证对错。模型可能记住了一部分事实但把细节张冠李戴了。3.2 忠实性幻觉Faithfulness Hallucination模型的输出与用户提供的上下文/输入文档矛盾即使输出本身在现实世界可能是对的。典型表现你给模型一篇论文摘要让它总结。模型在总结里加入了论文没提到的结论——这在现实中可能是对的但相对于你的输入是幻觉你让模型只根据以下代码回答问题模型回答时引入了代码中不存在的函数行为RAG 系统中模型无视检索到的文档编造了一个文档里没有的答案这类幻觉在 RAG 和文档问答场景中最为致命——你以为模型在阅读理解实际上它在自由发挥。维度事实性幻觉忠实性幻觉矛盾对象现实世界事实用户提供的上下文验证方式查百科、文档、搜索引擎对比输入文档与输出高发场景开放问答、知识聊天RAG、文档摘要、代码分析解法侧重RAG 检索、知识更新、联网搜索指令约束、注意力引导、引用溯源四、为什么大模型会产生幻觉六大根因理解了幻觉是什么接下来要回答一个更本质的问题为什么模型明明很聪明为什么还会犯这么低级的错误根因1大模型的本质就是概率猜下一个词这是最根本的原因。大语言模型的底层机制是next-token prediction下一个词预测给定前面的词预测下一个最可能出现的词。关键在于模型并不知道自己在说什么。它只是在计算概率分布。当它生成到爱因斯坦获得诺贝尔奖的理由是这句话时相对论和光电效应都是高概率候选词。如果相对论的概率恰好略高因为爱因斯坦和相对论的共现频率极高模型就会选相对论——哪怕事实是光电效应。换句话说模型优化的是语言的统计合理性而非事实的准确性。当两者冲突时统计合理性往往胜出——因为模型就是这么训练的。根因2训练数据本身就有错大模型的训练数据来自互联网——维基百科、Reddit、Stack Overflow、新闻网站……这些数据里充斥着错误信息过时的技术文档、被踩的高赞错误回答、以讹传讹的冷知识、刻意编造的虚假信息。模型不知道哪些信息是对的、哪些是错的。它只是把所有数据压缩进了权重里。如果训练数据中Python sort 返回新列表这种错误说法出现了 10 万次模型就会认为这是对的。更麻烦的是知识冲突同一个问题训练数据里可能有互相矛盾的答案。模型最终学到的是一个平均化的结果——而这个平均结果可能恰好是错的。根因3长尾知识覆盖不足大模型对高频知识如Python 是什么HTTP 200 表示成功掌握得很好因为这些在训练数据中出现次数极多。但对长尾知识如某个小众库的某个冷门 API、某个公司内部工具的使用方法训练数据中可能只有寥寥几条甚至完全没有。面对长尾问题模型有两条路承认不知道——但大多数模型没有经过知之为知之不知为不知的训练默认行为是努力回答用已有知识合理推测——把高频模式套到长尾问题上生成一个看起来合理但实际不存在的答案模型的默认行为是第二条路。这就是为什么越冷门的问题幻觉率越高。根因4知识有截止日期大模型的知识来源于训练数据而训练数据有截止日期。GPT-4 的训练数据截止到 2023 年 4 月Claude 4 截止到 2025 年初。任何截止日期之后发生的事情模型不可能知道。但模型不会说这件事发生在我的知识截止日期之后我不知道。它会用截止日期之前的模式去外推生成一个看起来合理的答案。比如你问2025 年发布的 React 20 有什么新特性模型可能根据 React 18 的更新模式编造出一套React 20 新特性——Concurrent Mode 改进了、Suspense 支持了新 API……每一条都看起来有理有据但全部是编的。根因5指令与上下文冲突时的自由发挥当你通过 RAG 或系统提示给模型提供了上下文但模型的参数化知识训练时学到的与上下文冲突时模型有时会无视上下文选择自己记得的答案。这在 RAG 系统中特别常见你检索到了一篇 2024 年的文档说API 已废弃但模型训练数据里 2023 年的知识说这个 API 是推荐用法。模型可能会输出旧知识——因为它在训练中见过太多次了权重太强了。学术上称之为参数化知识与检索知识的冲突。研究表明当冲突发生时模型选择参数化知识的概率约为40%~60%——这个比例高得惊人。根因6采样策略引入的随机性Temperature 0 时模型从概率分布中随机采样而非始终选最高概率的词。这带来了创造性和多样性但也意味着模型有时会选到低概率但不正确的词。Temperature 越高幻觉率越高。这也是为什么代码生成场景建议 Temperature 0~0.2而创意写作场景可以到 0.7~1.0。五、幻觉的技术原理从注意力到记忆混淆前面讲了根因这里从更技术层面解释幻觉是怎么发生的。5.1 注意力分散与 Lost in the MiddleTransformer 的 Self-Attention 机制让模型能够关注输入中的不同部分。但研究表明当上下文很长时模型对中间位置的信息关注不足——这就是著名的Lost in the Middle效应。这意味着如果你把关键信息放在长文档的中间模型可能看不到它转而用参数化知识来回答——产生忠实性幻觉。5.2 知识编辑困难改不动权重里的事实大模型的知识存储在权重矩阵里呈分布式表示。一个事实如巴黎是法国首都不是存储在某个神经元里而是分散在成千上万个权重中。这导致一个严重问题你很难局部修改模型的知识。想纠正模型某个错误的事实你不能简单地改一个神经元——你可能需要重新训练整个模型。这也是为什么 Fine-tuning尤其是全量微调可能会引入新的幻觉你在修改某个知识时可能不小心碰到了相关的其他知识导致它们也变了。5.3 自我校准缺失模型不知道自己不知道理想情况下模型应该对自己的答案有一个置信度评估——如果置信度低就应该说我不确定。但大模型普遍缺乏这种不确定性校准能力。研究表明大模型的口头置信度让它说我有 90% 的把握与实际准确率之间的相关性很弱。模型说我非常确定时实际正确率可能只有 60%说我不太确定时实际可能是对的。这就是为什么你不能简单地问模型你确定吗来检测幻觉——模型的自信程度与正确程度几乎不相关。六、AI Coding 中的幻觉六大典型翻车场景对于程序员来说幻觉不是抽象的学术问题——它每天都在你的代码里发生。以下是六个最常见的幻觉翻车场景。场景1虚构 API最常见模型生成了一个不存在的 API 调用。函数名看起来合理参数类型也对返回值也说得通——但官方文档里根本没有这个方法。# 模型生成的幻觉代码 from openai import OpenAI client OpenAI() # 这个方法不存在 response client.chat.generate( modelgpt-4, messages[{role: user, content: Hello}], temperature0.7, max_retry3 # 这个参数也是编的 )实际正确的写法应该是client.chat.completions.create()且没有max_retry参数。模型把不同库的 API 风格混搭了。场景2虚构包和模块模型import了一个不存在的包或从一个存在的包里导入了一个不存在的模块/函数。# 这些包/函数都不存在 from pydantic.validators import EmailValidator # 路径编造 from fastapi.security import OAuth2BearerToken # 类名编造 import sklearn.preprocessing.PowerTransformer # 导入语法错误 不存在场景3虚构配置项模型给出的配置文件中包含了不存在的配置项。这在 Docker、Nginx、Kubernetes 配置中尤为常见。# 模型生成的 k8s Deployment 配置 apiVersion: apps/v1 kind: Deployment spec: replicas: 3 template: spec: containers: - name: app image: myapp:latest resources: limits: cpu: 1000m memory: 512Mi # 这个字段不存在 maxStartupTime: 60s场景4虚构 Git 命令和 CLI 参数模型给出了一个看起来很专业的 Git 命令但这个子命令或参数根本不存在。# git 没有 --auto-stash 参数 git rebase --auto-stash origin/main # git stash 没有 --label 参数 git stash --label work-in-progress场景5虚构依赖版本兼容性模型告诉你这个 API 在 React 18.3 中新增了但实际它可能是 19.0 新增的或者在 18.3 中已经废弃了。版本号幻觉在代码迁移建议中极为危险。场景6虚构错误原因和解决方案你贴了一段报错信息模型自信地解释了原因并给出解决方案——但原因分析是编的解决方案也南辕北辙。比模型说我不知道更可怕的是模型自信地给了一个错误方向让你白白调试 3 小时。幻觉场景危险等级最佳防线虚构 API高直接报错官方文档 单元测试虚构包/模块高import 失败pip install 验证 import 测试虚构配置项中高部署时失败schema 校验 dry-run虚构 Git 命令中命令报错--help验证虚构版本兼容性极高隐蔽 BugChangelog 版本测试矩阵虚构错误原因极高误导调试方向交叉验证 最小复现七、检测幻觉四层防线既然幻觉无法根除那核心策略就是检测 缓解。以下是四层检测防线从模型层到应用层。第一层模型自检Self-Check让模型自己检查自己的答案。核心思路是生成多个回答然后让模型或另一个模型判断它们是否一致。如果多个回答互相矛盾说明模型对这个问题的把握不大——幻觉概率高。import openai def self_check_consistency(question, n3): 生成 n 个回答检查一致性 answers [] for _ in range(n): resp openai.chat.completions.create( modelgpt-4, messages[{role: user, content: question}], temperature0.7, # 用高 temperature 生成多样化回答 ) answers.append(resp.choices[0].message.content) # 让模型判断这些回答是否一致 check_prompt f以下是针对同一问题的 {n} 个回答请判断它们在事实上是否一致。如果存在矛盾说明哪个可能是幻觉\n\n for i, ans in enumerate(answers): check_prompt f回答{i1}{ans}\n\n check_resp openai.chat.completions.create( modelgpt-4, messages[{role: user, content: check_prompt}], temperature0, ) return check_resp.choices[0].message.content这种方法叫Self-Consistency简单有效但成本是单次调用的 n1 倍。第二层外部知识验证External Verification用外部知识源来验证模型的回答——搜索引擎、知识库、API 文档。这是对抗事实性幻觉最有效的方法。def verify_with_search(claim): 用搜索结果验证模型的事实性声明 # 1. 提取模型回答中的关键事实声明 # 2. 用搜索引擎检索相关信息 # 3. 让模型判断搜索结果是否支持该声明 search_results web_search(claim) verify_prompt f请根据以下搜索结果判断这个声明是否被支持 声明{claim} 搜索结果 {search_results} 判断结果支持/矛盾/无法确定 resp openai.chat.completions.create( modelgpt-4, messages[{role: user, content: verify_prompt}], temperature0, ) return resp.choices[0].message.content这正是RAG 联网搜索的核心思路——让模型查证而非回忆。第三层引用溯源Citation Tracing要求模型在回答时标注引用来源并验证引用确实支持其声明。这对忠实性幻觉特别有效。def answer_with_citations(question, context_docs): 要求模型标注引用并验证引用确实存在 prompt f根据以下文档回答问题。每个事实性声明后必须标注来源 [doc_id]。 如果文档中没有相关信息明确说文档中未提及。 文档 {context_docs} 问题{question} # ... 调用模型 ... # 后处理检查每个 [doc_id] 引用是否真实存在于 context_docs 中 # 如果引用了不存在的 doc_id标记为幻觉第四层规则与 Schema 校验对于代码生成场景最可靠的幻觉检测是直接验证import 能否成功、函数是否存在、类型是否匹配。import ast import importlib def check_code_hallucination(code_str): 检查代码中是否存在幻觉虚构的 import / API tree ast.parse(code_str) hallucination_risks [] for node in ast.walk(tree): if isinstance(node, ast.Import): for alias in node.names: try: importlib.import_module(alias.name) except ImportError: hallucination_risks.append(f虚构的包: {alias.name}) elif isinstance(node, ast.ImportFrom): try: mod importlib.import_module(node.module) for alias in node.names: if not hasattr(mod, alias.name): hallucination_risks.append( f虚构的属性: {node.module}.{alias.name} ) except ImportError: hallucination_risks.append(f虚构的模块: {node.module}) return hallucination_risks这个方法虽然简单但在 AI Coding 场景中命中率极高——因为大部分代码幻觉就是虚构 import 和虚构属性。八、缓解幻觉从提示词到工程化的完整策略检测是事后补救缓解是事前预防。以下是从提示词层到系统层的完整缓解策略。策略1提示词层——降低幻觉的 5 个技巧1. 明确要求不知道就说不知道如果你不确定答案请直接说我不确定不要编造答案。 宁可承认不知道也不要给出可能错误的回答。这看似简单但研究显示它能将幻觉率降低20%~30%。关键是模型需要一个退路——如果你不告诉它可以说不知道它就会硬编。2. 提供参考文档并严格约束请只根据以下文档内容回答问题。如果文档中没有相关信息请说文档中未提及。 不要使用你的训练知识来补充答案。 文档 {documents}这对 RAG 场景极为关键。不加上这句约束模型有 40%~60% 的概率会用参数化知识补充答案。3. 要求逐步推理Chain of Thought请先逐步分析问题然后再给出答案。CoT 能降低幻觉因为它让模型把推理过程显式化中间步骤可以被检查。如果中间某步推理错了最终答案大概率也是错的——你可以提前发现。4. 要求标注不确定性对于每个事实性声明请标注置信度高/中/低。 低置信度的内容请额外标注建议核实。5. 要求提供引用来源对于每个事实性声明请标注信息来源文档段落号/URL。 无法标注来源的声明请标注未验证。策略2参数层——Temperature 与采样控制场景推荐 Temperature原因代码生成0 ~ 0.2最小化随机性降低虚构 API 概率事实问答0 ~ 0.3需要准确事实不需要创造性RAG 文档问答0 ~ 0.2严格遵循文档避免自由发挥创意写作0.7 ~ 1.0需要多样性幻觉影响小头脑风暴0.8 ~ 1.2鼓励发散思维一个常被忽略的参数是top_p核采样。将top_p设为 0.9~0.95 可以过滤掉概率极低的词进一步降低幻觉风险。但不要同时调高 Temperature 和调低 top_p——两者作用相反同时调会互相抵消。策略3系统层——RAG Function Calling Guardrails这三个技术是缓解幻觉的三件套在本系列前面文章中已详细讲过这里只说它们如何协同对抗幻觉RAG把外部知识注入上下文降低事实性幻觉。模型不再回忆而是阅读理解Function Calling把回答问题变成调用 API 获取准确数据从源头消灭幻觉。与其让模型猜天气不如让它调用天气 APIGuardrailsAI 护栏在输出层做校验和兜底拦截已知模式的幻觉输出三层配合的逻辑是RAG 管知识来源、Function Calling 管动作执行、Guardrails 管输出兜底。缺任何一层幻觉防线都有漏洞。策略4工程层——测试 反馈循环在 AI Coding 场景中最务实的幻觉缓解策略是把代码验证自动化生成即验证模型生成代码后立即执行 import 检查、类型检查、单元测试失败即反馈如果验证失败把错误信息反馈给模型让它修正这就是 Agent Loop 的核心思路通过即采纳只有通过所有验证的代码才最终采纳def generate_and_verify(prompt, max_retries3): 生成代码并自动验证失败则反馈修正 for attempt in range(max_retries): code llm_generate(prompt) risks check_code_hallucination(code) if not risks: # 进一步验证执行代码、跑测试 test_result run_tests(code) if test_result.passed: return code else: prompt f\n\n上一次生成的代码测试失败{test_result.error}\n请修正。 else: prompt f\n\n上一次生成的代码存在以下问题{risks}\n请修正。 raise Exception(f经过 {max_retries} 次重试仍无法生成有效代码)这个模式在 Cursor、Claude Code、Copilot 等 AI Coding 工具中已经是标配。模型不是一次性给出代码而是在一个生成→验证→修正的循环中不断迭代直到代码通过所有检查。九、常见误区与避坑指南误区1模型越大幻觉越少半对半错。大模型在高频知识上确实幻觉率更低因为训练数据更多、学得更扎实。但在长尾知识上大模型的幻觉率可能反而更高——因为它更擅长编造看起来合理的答案。小模型遇到不会的问题更容易放弃大模型则会努力编一个。误区2让模型说你确定吗就能检测幻觉不靠谱。如前所述模型的自信程度与正确程度几乎不相关。模型说我 100% 确定时实际正确率可能只有 50%。这个方法偶尔有效但不能作为可靠的幻觉检测手段。误区3RAG 能彻底解决幻觉不能。RAG 降低了事实性幻觉但引入了新的忠实性幻觉风险——模型可能无视检索到的文档。而且 RAG 本身也有问题检索结果不准、检索到了过时信息、检索结果互相矛盾……这些都会导致新的幻觉。误区4Temperature 设为 0 就没有幻觉了大幅降低但不为零。Temperature 0 时模型始终选概率最高的词但概率最高的词不一定是对的。如果模型记错了Temperature 0 也只是在稳定地输出错误答案。误区5联网搜索 无幻觉不完全。联网搜索能获取最新信息但搜索引擎结果本身可能有错SEO 垃圾、过时页面、AI 生成内容。而且模型在整合搜索结果时仍可能产生忠实性幻觉——把搜索结果的内容加工错了。十、幻觉能被彻底消灭吗这是一个需要诚实回答的问题短期内不能。原因在于幻觉是大模型底层机制的固有缺陷。只要模型还是基于 next-token prediction 的概率模型就一定会产生幻觉——因为概率最优的下一个词不一定是事实正确的下一个词。但好消息是幻觉率可以被压到极低低到在绝大多数场景下可以接受。这需要多层策略的协同模型层更好的训练数据、更好的 RLHF 对齐、更好的不确定性校准检索层更精准的 RAG、更实时的联网搜索、更可靠的知识图谱应用层Function Calling 替代猜测、Guardrails 兜底、引用溯源工程层自动验证、反馈循环、人审机制对于 AI Coding 来说还有一个天然的幻觉防火墙代码是可执行的。模型编造的 API 一运行就会报错错误信息会立刻暴露幻觉。这比聊天场景好得多——聊天的幻觉可能永远不会被发现但代码的幻觉一定会在运行时暴露。所以正确的态度不是消灭幻觉而是把幻觉当成一种可管理的风险——像处理 Bug 一样处理它检测、缓解、监控、迭代。你不会因为代码可能有 Bug就放弃写代码同理也不应该因为模型可能幻觉就放弃用 AI Coding。十一、总结最后用一张表把全文核心要点串联起来维度核心要点定义模型生成流畅、自信但事实错误/与上下文矛盾的内容分类事实性幻觉与现实矛盾 vs 忠实性幻觉与输入矛盾根因概率本质、训练数据缺陷、长尾覆盖不足、知识截止、知识冲突、采样随机性AI Coding 翻车虚构 API / 包 / 配置 / 命令 / 版本 / 错误原因检测四层模型自检 → 外部验证 → 引用溯源 → 规则校验缓解策略提示词约束 参数控制 RAG/FC/Guardrails 自动验证循环核心认知幻觉不可消灭但可管理代码可执行性是天然防火墙记住一句话大模型不是全知全能的神而是一个读过很多书但偶尔记混了的实习生。它很努力但你不应该完全信任它的每一个字——尤其是涉及事实和代码 API 的时候。验证验证再验证——这是 AI Coding 时代每个程序员的生存法则。附录彻底讲透系列文章导航本篇是「彻底讲透」系列第 18 篇以下是系列完整导航#主题一句话摘要链接1LLM大语言模型从下一个词预测到通用智能的训练全貌LLM 彻底讲透2Transformer所有大模型共享的底层架构与 Attention 机制Transformer 彻底讲透3Token大模型如何把文字切成可计算的最小单位Token 彻底讲透4Embedding把语义压缩成向量让机器理解猫和狗是近亲Embedding 彻底讲透5Fine-tuning从全量微调到 LoRA/QLoRA 的完整实战指南Fine-tuning 彻底讲透6Prompt Engineering从说人话到驱动 AI的第一门元技能Prompt Engineering 彻底讲透7Temperature一个参数如何决定模型是严谨工程师还是脑洞诗人Temperature 彻底讲透8Function Calling大模型动手调用外部世界的底层机制Function Calling 彻底讲透9Agent让 AI 从问答工具进化成能自主干活的智能体Agent 彻底讲透10MCPAI Coding 的万能接口如何让 Agent 真正拥有动手能力MCP 彻底讲透11RAG让大模型从胡说八道到言之有据的检索增强生成RAG 彻底讲透12Skill技能如何成为大模型能力的真正放大器Skill 彻底讲透13Vibe Coding当程序员不再写代码AI Coding 的终极形态Vibe Coding 彻底讲透14多模态大模型从看懂图片到生成视频的多感官协作多模态大模型彻底讲透15AI 护栏 Guardrails用一套防呆机制让 AI 真正可用AI 护栏彻底讲透16Reasoning 推理模型o1/R1/Claude Thinking 让大模型学会先想再答Reasoning 模型彻底讲透17Context Engineering管理好上下文比写好提示词更重要的核心元技能Context Engineering 彻底讲透18大模型幻觉为什么 AI 总是一本正经地胡说八道及驯服之道本文系列还在继续下一期我们将探讨更多 AI Coding 的核心概念。关注专栏不错过更新。