1. 项目概述当AI开始“编故事”最近在跟几个做AI应用开发的朋友聊天大家不约而同地都提到了一个让人又爱又恨的问题大模型时不时会“一本正经地胡说八道”。比如你让它写一段代码它可能会引用一个根本不存在的库函数你让它总结一篇论文它可能会捏造几个看似合理的引用来源甚至你让它帮你规划一下周末行程它都能给你推荐一个已经倒闭多年的餐厅。这种现象在圈内我们通常称之为“幻觉”。简单来说AI幻觉就是指大语言模型生成的内容听起来头头是道、逻辑自洽但实际上与事实不符或者完全是无中生有。这可不是什么“创意涌现”而是一个实实在在的技术缺陷尤其是在需要高可靠性的场景比如代码生成、法律咨询、医疗问答或者金融分析里幻觉带来的风险是巨大的。想象一下一个基于大模型的自动代码审查工具如果它“幻觉”出一个错误的修复方案可能会导致线上服务崩溃一个AI辅助的专利检索系统如果它“编造”了不存在的在先技术可能会让整个专利申请无效。所以今天我们就来深入聊聊这个事儿。我会结合自己这几年在AI应用开发、模型微调和部署中踩过的坑拆解一下大模型为什么会“胡说八道”以及我们作为开发者、产品经理或者使用者有哪些实实在在的方法可以识别、缓解甚至利用这种现象。无论你是刚开始接触大模型的新手还是正在为自家产品的幻觉问题头疼的资深工程师希望这篇内容都能给你带来一些启发。2. 幻觉的根源不只是数据问题要解决问题首先得理解问题是怎么来的。很多人一提到幻觉第一反应就是“训练数据不干净”。这没错但这只是冰山一角。大模型产生幻觉是一个系统性工程问题涉及到从数据、模型架构到推理过程的每一个环节。2.1 数据层面的“先天不足”训练数据是模型的“粮食”粮食出了问题模型自然长不好。这里有几个关键点数据噪声与矛盾互联网上的数据浩如烟海但质量参差不齐。同一个事实在不同的网页、论坛、书籍里可能有不同的表述甚至相互矛盾。模型在学习时会试图“记住”所有这些模式。当它遇到一个模糊的提示时可能会从记忆中提取出多个矛盾的片段然后以一种看似合理的方式拼接起来这就产生了幻觉。比如关于某个历史事件的日期如果训练数据里既有A版本又有B版本模型在生成时可能会随机选择一个或者干脆“创造”一个介于两者之间的新日期。数据覆盖不全与分布偏移模型只能学会它“见过”的东西。对于训练数据中极少出现或者从未出现过的知识长尾知识模型缺乏可靠的依据只能依靠其强大的模式匹配和生成能力去“猜”。这种猜测往往基于语义相似性而非事实。例如你问一个2023年之前训练的模型“ChatGPT-4o是什么”它很可能会根据“ChatGPT”和版本号模式生成一段关于“ChatGPT第四代优化版”的虚构描述因为它没见过真实的GPT-4o数据。数据标注的主观性与偏差即使是人工标注的数据也难免带有主观性。比如在情感分析中对一段话是“积极”还是“消极”的判断可能因人而异。模型学习了这种带有偏差的关联后在生成内容时可能会强化这种偏差甚至创造出符合偏差但不符合事实的叙述。实操心得在做领域微调时数据清洗和去重是第一步但往往也是被低估的一步。我常用的方法是“交叉验证清洗法”对于关键事实性数据准备多个来源进行比对。如果某个说法只在单一来源出现且与其他高质量来源冲突宁可将其剔除或降权。虽然这会损失一些数据量但能显著提升生成内容的可信度。2.2 模型架构与训练过程的“内在倾向”大模型本质是一个基于概率的生成机器它的设计目标就是生成“看起来像”训练数据中自然语言的文本序列。自回归生成的“贪婪”与“随机”模型在生成下一个词时会根据上文计算所有可能词的概率分布。常用的采样策略如贪心搜索总是选概率最高的词或核采样从高概率词中随机选都是为了生成流畅的文本。但问题在于流畅不等于正确。模型可能会为了保持句子的语法和语义连贯性而选择一组概率高、搭配起来通顺但整体事实错误的词序列。它更像一个追求局部最优的“故事大王”而不是一个追求全局真实的“考据学家”。注意力机制的“过度泛化”Transformer架构的核心是注意力机制它让模型能够关注输入中不同部分的关系。然而这种强大的关联能力也是一把双刃剑。模型可能会过度依赖某些表面的、统计上的相关性而不是真正的因果或事实关系。例如在训练数据中“苹果”和“公司”经常一起出现模型可能会过度强化这种联系以至于在回答“苹果是什么”时倾向于生成“一家科技公司”而忽略了其作为一种水果的基本事实。参数化知识的“记忆模糊”模型的知识是以数十亿甚至上万亿参数的形式分布式存储的。当被问及一个具体事实时模型并不是去“查找”一个数据库而是激活一系列相关的参数模式来“重建”答案。这个过程类似于根据记忆画一幅画难免会有细节的模糊、混淆甚至创造。对于非常具体、精确的信息如精确的数字、专有名词的拼写这种重建过程极易出错。2.3 提示与交互的“诱导失误”很多时候幻觉是被我们用户“问”出来的。模糊、矛盾或误导性的提示如果你问一个模型“请告诉我爱因斯坦在发明相对论时他的猫叫什么名字” 模型知道爱因斯坦和相对论是强关联也知道很多人养猫它可能会“合成”出一个名字比如“米粒”因为它要努力完成“生成一个符合上下文的名字”这个任务即使这个事实根本不存在。这就是一个典型的被诱导产生的幻觉。多轮对话中的错误累积在长对话中模型没有真正的记忆它依赖的是整个对话历史作为上下文。如果在前几轮对话中用户或模型自己无意中引入了一个错误信息这个错误会作为“事实”进入后续对话的上下文导致模型在此基础上继续生成使得幻觉像滚雪球一样越来越大。这种现象也叫“幻觉传播”。对“自信”的误判大模型通常会被设计成以非常肯定、专业的口吻回答问题即使它并不确定。它很少会说“我不知道”或“这个信息在我的训练数据里没有”。这种设计是为了用户体验但却掩盖了模型的不确定性让用户误以为一个编造出来的答案也是可信的。3. 核心解法从预防到治理的全链路策略知道了原因我们就可以对症下药了。解决幻觉没有银弹它是一个需要从数据、模型、应用层多方下手的系统工程。下面我结合一些实际项目经验聊聊几个核心的解决思路。3.1 数据与训练阶段打好地基高质量、高覆盖的领域数据构建对于企业级应用通用大模型往往不够用。我们需要进行领域适应。这里的核心是构建专属的高质量数据集。不仅仅是收集数据更要进行精细的清洗、去重、去噪和标注。对于关键事实要建立“事实核查”流程最好能引入领域专家进行审核。数据量不在多而在精。一个经过精心清洗的10万条领域数据其效果可能远胜于一个包含噪声的百万条通用数据。指令微调与对齐优化通过指令微调我们可以明确告诉模型我们期望的行为。例如我们可以构造大量的“诚实回答”样本对当模型不知道答案时就输出“根据我的知识我无法确认该信息”。通过强化学习基于人类反馈进行微调可以进一步让模型学会权衡“生成流畅答案”和“生成真实答案”。虽然RLHF实施成本高但对于减少有害内容和事实性幻觉效果显著。检索增强生成这是目前应对事实性幻觉最有效、最流行的技术之一简称RAG。其核心思想是“让模型说它有依据的话”。具体流程是知识库构建将可靠的、结构化的知识如产品文档、技术手册、论文库、权威网站内容进行切片、向量化存入向量数据库。检索当用户提问时先将问题向量化从向量数据库中检索出最相关的若干知识片段。增强提示将检索到的知识片段和用户问题一起组合成一个新的提示交给大模型生成最终答案。生成模型基于提供的可靠知识进行生成并在答案中引用来源。这样做的好处是显而易见的答案有了依据可追溯可验证。即使模型在理解或重组知识时仍有小瑕疵但大方向不会偏离事实。我在部署企业内部知识问答系统时RAG架构将幻觉率降低了大约70%。注意事项RAG也不是万能的。检索质量是关键如果检索到的片段本身不相关或不准确会引发“垃圾进垃圾出”的问题。需要精心设计文本切片策略如按语义、按章节、优化检索模型不仅仅是简单的余弦相似度可以结合关键词、元数据过滤和设计提示词模板明确要求模型基于给定上下文回答。3.2 推理与应用阶段设立护栏在模型生成答案的过程中和之后我们也可以设置多道“安检门”。提示词工程精心设计的提示词是成本最低的干预手段。一些有效的技巧包括角色设定“你是一个严谨的科学家只根据已知事实回答问题。”步骤引导“请按以下步骤思考1. 理解问题核心。2. 检索你知识库中的相关事实。3. 如果找到确切依据请组织答案并引用如果没找到请直接说不知道。”输出格式约束“请以JSON格式输出包含‘答案’和‘置信度’两个字段如果置信度低于80%请在答案中注明‘此信息可能存在不确定性’。”少样本示例在提示词中给出几个“好答案”和“坏答案”包含幻觉的例子让模型通过上下文学习到你的期望。后处理与验证一致性校验对于同一个问题用不同的随机种子或稍微改写的提示词让模型生成多个答案然后比较这些答案在核心事实点上是否一致。如果不一致则触发人工审核或返回“答案不确定”的提示。事实核查对于生成答案中提到的关键实体人名、地点、时间、数据、事件和引用可以调用外部权威API如维基百科、学术数据库、企业知识图谱进行快速验证。这相当于给模型的输出加了一道自动校对。置信度评分一些模型或技术如基于模型自身概率的校准、或专门训练的验证模型可以为生成的每个陈述或片段输出一个置信度分数。我们可以设定一个阈值低于阈值的输出需要特别标注或拦截。人工审核与反馈闭环在关键应用场景如内容发布、客服回答、代码合并必须保留最后一道人工审核防线。同时要将人工发现的幻觉案例收集起来形成一个“反幻觉”数据集用于后续的模型迭代优化形成一个持续改进的闭环。3.3 模型选择与架构创新选择“更老实”的模型不同的开源大模型在幻觉倾向上有差异。一些经过严格指令对齐和RLHF训练的模型如某些版本的Llama、Qwen在“诚实回答”方面表现会更好。在项目选型时可以设计专门的评测集包含大量诱导性、模糊性问题来测试候选模型的幻觉率而不仅仅是看它的通用能力得分。探索新的模型架构学术界和工业界也在从底层探索减少幻觉的模型架构。例如分离知识与推理一些研究尝试将模型的“记忆模块”存储事实知识和“推理模块”进行逻辑运算分离开让知识检索变得更可控、可解释。可追溯的生成让模型在生成每一个重要陈述时都“标注”出它所依赖的内部“记忆”位置或外部证据类似于写论文加引用。约束解码在生成过程中实时检查部分生成的文本是否与一个外部的、可信的知识图谱相冲突如果冲突则强制调整后续的生成方向。4. 实战构建一个抗幻觉的智能问答系统理论说了这么多我们来看一个具体的实战案例如何为一个技术社区构建一个抗幻觉的编程问答助手。这个助手需要能准确回答关于特定编程语言、框架和库的问题绝不能胡编乱造API用法。4.1 系统架构设计我们的核心思路是RAG 严格验证。系统架构如下用户提问 - 查询理解/重写 - 向量检索 - 知识片段召回 - 大模型生成 - 答案验证 - 最终输出知识库构建数据源官方文档Python, React, Spring等、Stack Overflow高赞问答需筛选、权威技术博客、经典开源项目的README和源码注释。处理流程下载官方文档按章节/API进行切片。对Stack Overflow问答提取问题和被采纳的答案去除无关内容。使用文本嵌入模型如text-embedding-3-small或开源的BGE模型将每个文本切片转换为向量。将所有向量和对应的原始文本、来源元数据如“Python 3.11官方文档-内置函数章节”存入向量数据库如Chroma, Pinecone, 或本地部署的Milvus。检索优化单纯的向量相似度检索可能召回不相关片段。我们采用混合检索策略密集检索使用向量相似度召回语义上最接近的片段。稀疏检索同时使用BM25等传统算法基于关键词匹配进行召回。将两者的结果进行融合重排优先选择同时被两种方法召回的片段或者使用学习到的排序模型进行最终排序。提示词模板设计你是一个严谨的编程助手必须严格根据提供的上下文信息回答问题。如果上下文信息不足以回答问题请直接说“根据提供的资料我无法回答这个问题”不要编造信息。 上下文信息 {context} 用户问题{question} 请基于以上上下文给出准确、简洁的答案。如果答案涉及代码请确保代码片段来自上下文或与上下文描述严格一致。生成与后处理将检索到的Top-K个相关片段和用户问题填入提示词模板发送给大模型如GPT-4, Claude 3或本地部署的Qwen-Max生成答案。关键步骤答案验证对生成答案中出现的所有函数名、类名、库名、关键参数在检索到的上下文片段中进行字符串匹配验证。如果发现答案中出现了上下文里完全没有提及的API或用法系统会标记该答案为“高风险”并触发以下操作之一1) 直接拒绝返回提示“信息不足”2) 在答案前添加显著警告“请注意以下部分信息未在提供的资料中找到明确依据请谨慎参考。”4.2 效果评估与迭代部署后我们如何知道系统是否有效构建测试集收集一批历史真实用户问题并请专家标注标准答案。同时故意设计一批容易诱发幻觉的问题如“请告诉我Django框架中pandas.read_excel函数的用法”这混淆了两个不相关的库。定义评估指标事实准确率答案核心事实与标准答案一致的百分比。幻觉发生率答案中包含无依据陈述的百分比。拒答率对于无法回答的问题系统正确说“不知道”的百分比。A/B测试将新系统与一个直接使用通用大模型无RAG的基线系统进行对比。通过线上小流量实验对比两者的用户满意度、问题解决率和后续的纠错反馈数量。踩坑实录在初期我们只用了向量检索发现对于一些非常具体的API名称如tf.keras.layers.Bidirectional如果用户拼写略有错误或使用了缩写检索效果会急剧下降。后来引入基于关键词的稀疏检索作为补充并加入了查询纠错和扩展模块将“tf bidirect layer”纠正并扩展为“tensorflow keras bidirectional layer”召回率得到了显著提升。另一个坑是上下文长度限制有时检索到的相关片段很长全部塞进提示词会超长。我们后来改用了“摘要引用”的方式先让一个小模型对长片段生成摘要将摘要和原文索引一起给大模型如果需要细节大模型可以“请求”查看某个索引对应的原文片段。5. 开发者工具箱识别与缓解幻觉的实用技巧作为一线开发者在日常使用大模型无论是通过API还是本地部署时有哪些可以立刻上手的技巧来应对幻觉呢5.1 提问的艺术如何问得更安全要求提供引用/来源直接在问题中要求“请根据[某官方文档]回答”或“请给出你的信息来源”。对于支持长上下文的模型你甚至可以先把权威资料贴给它再让它基于此回答。分解复杂问题不要一次性问一个庞大复杂的问题如“设计一个电商系统”。将其分解成多个子问题“电商系统的用户模块数据库表该如何设计”逐个击破。这样模型更容易聚焦也便于你分步验证。使用对比和确认当你对某个答案不确定时可以换一种问法再问一次或者让模型从反面论证。例如“你刚才说这个方法效率是O(n)你能解释一下为什么不是O(log n)吗” 或者 “有没有其他替代方案它们各自的缺点是什么”设定回答的边界明确告诉模型知识的截止日期和范围。例如“请基于2023年之前的公开信息回答。”5.2 代码生成的防幻觉实践代码生成是幻觉的重灾区以下方法亲测有效单元测试驱动生成不要只让模型生成一个函数。给出函数的功能描述和一组单元测试用例。让模型生成能通过这些测试的代码。这能极大约束模型的输出。# 你的提示词 请编写一个Python函数 find_max_subarray_sum输入是一个整数列表 nums返回该列表中连续子数组的最大和。 请确保你的代码能通过以下测试 assert find_max_subarray_sum([-2,1,-3,4,-1,2,1,-5,4]) 6 assert find_max_subarray_sum([1]) 1 assert find_max_subarray_sum([5,4,-1,7,8]) 23 利用IDE插件进行实时验证使用像Cursor、Copilot这样的智能编程助手时不要盲目接受所有建议。对于它生成的稍复杂的代码块尤其是涉及不熟悉的库时立刻利用IDE的代码分析、跳转到定义、查找引用等功能进行快速验证。分步生成与审查让模型先输出思路或伪代码你审查通过后再让它生成具体代码。或者让它只生成核心算法部分而由你来编写接口定义和错误处理。5.3 选择合适的工具与模型对于事实性任务优先使用具备联网搜索或RAG能力的工具如Perplexity、ChatGPT开启联网搜索、或你自己搭建的RAG应用。它们能提供来源让你可以追溯和判断。了解不同模型的“性格”通过实践你会发现有些模型如Claude在拒绝回答不确定问题上更“诚实”而有些模型如早期的一些开源模型则更“乐于助人”以至于经常编造。根据任务性质选择模型。本地部署模型时务必搭配RAG框架如果你用Ollama、vLLM等工具部署私有模型强烈建议结合LlamaIndex、LangChain等框架构建本地知识库。让模型在“开口”前先“查资料”。6. 未来展望与幻觉共舞幻觉是大语言模型与生俱来的特性源于其概率生成的本质。完全消除幻觉在可预见的未来可能是一个不切实际的目标。我们的目标不是创造一个永不犯错的“神谕”而是管理幻觉的风险并将其控制在可接受、可追溯的范围内。未来的方向可能会集中在以下几个方面可解释性与透明度模型需要学会“示弱”和“展示工作过程”。不仅给出答案还能给出置信度、推理链和依据的来源。让用户能够像审阅一篇带有参考文献的论文一样审阅AI的产出。动态知识更新模型的知识需要能够像我们人类一样持续、低成本的更新而不是每隔几个月重新训练一次。更高效的持续学习、知识编辑技术将是关键。人机协同的新范式AI的角色将更倾向于一个“强大的副驾驶”或“研究助理”它负责快速检索、整理信息、提出多种可能性草案而人类负责最终的判断、决策和创意升华。接受AI会犯错但通过工具和流程设计让人类能高效地发现和纠正这些错误。作为开发者我们需要建立一种新的心智模型不再把大模型当作一个全知全能的答案引擎而是把它看作一个拥有海量知识但偶尔会记忆混乱、富有创造力但需要约束的超级实习生。我们的工作就是为这位“实习生”设计好工作流程、提供可靠的参考资料、并建立有效的审核机制。只有这样我们才能最大限度地发挥其潜力同时将“胡说八道”的风险降到最低。