大模型为什么会幻觉
1. 今日主题与一句话结论
主题:大模型为什么会幻觉
一句话结论: 大模型的幻觉不是偶发小毛病,而是概率生成、训练数据、上下文缺失、采样策略和产品设计共同作用的结果;产品经理不能指望模型“永远说真话”,而要把事实来源、引用、拒答、校验和人工兜底设计进系统。
模型会在上下文中计算关系,并预测最可能的下一个内容。这个能力让它能写文案、总结、问答、翻译、抽取信息,也带来一个关键风险:
它生成的是“看起来最合理的文本”,不天然等于“被事实验证过的答案”。
这就是幻觉的根源。幻觉不是简单的“模型不聪明”,也不是单纯换一个更大模型就能完全消失。更大的模型通常会减少低级错误,但只要系统缺少可靠事实来源、检索、权限、规则和评估,它仍然可能在关键业务场景里给出错误答案,而且语气非常笃定。
今天的学习目标不是记住“幻觉很危险”这句废话,而是建立可落地的判断方法:
-
什么问题容易诱发幻觉?
-
哪些场景可以接受轻微幻觉,哪些必须零容忍?
-
产品流程里应该在哪些节点拦截?
-
PRD 里如何写清楚风险、指标和验收标准?
-
团队评审时如何让研发、业务、法务、运营形成一致边界?
2. 学习目标
-
解释大模型幻觉的主要来源:概率生成、训练数据缺陷、上下文缺失、采样随机性、检索失败、指令冲突。
-
区分事实记忆、文本生成、逻辑推理和业务决策,避免把模型的语言流畅度误认为可靠性。
-
判断不同业务场景中幻觉的风险等级,并设计对应的兜底机制。
-
为知识库问答、智能客服、内容生成、数据分析等场景设计幻觉测试题。
-
把幻觉控制写进产品方案:引用、拒答、置信度、规则校验、人工审核、日志、评估集和灰度策略。
3. 深度阅读:幻觉不是“答错”,而是系统可靠性问题
3.1 什么是大模型幻觉
大模型幻觉指模型生成了看似合理、表达流畅、语气自信,但事实不准确、依据不存在、逻辑不成立或超出可验证范围的内容。
常见表现包括:
-
编造不存在的制度条款。
-
编造论文、书名、作者、链接或数据来源。
-
把旧政策当成新政策。
-
把别的公司规则套到当前公司。
-
对没有权限或没有资料的问题给出确定答案。
-
在客服场景里承诺退款、赔付、发货时间。
-
对数据分析结果编造原因。
-
对法律、医疗、金融问题给出超出资质的建议。
幻觉不等于所有错误。普通系统也会错,比如接口超时、数据库脏数据、规则配置错误。但大模型幻觉的特殊之处在于:
-
表达很像真的。 它不会像传统系统那样明显报错,而是生成完整回答。
-
错误难以肉眼识别。 用户容易被流畅语言说服。
-
同问可能不同答。 输出受上下文、采样和模型版本影响。
-
责任边界模糊。 用户会把模型回答当成产品承诺。
-
复盘成本高。 如果没有日志、引用和评估集,很难定位错误来源。
所以幻觉不是“模型答错了一次”这么简单,而是 AI 产品可靠性、风控和组织责任问题。
3.2 概率生成:模型为什么会一本正经地编
大语言模型常见训练目标是根据上下文预测下一个 Token。它学到的是大量文本中的语言模式、概念关系、表达方式和推理样式。
当用户问:
我们公司差旅制度里,二线城市住宿超标 20% 是否可以报销?如果模型没有看到你公司的真实制度,它仍然可以根据大量通用文本生成一个“像制度回答”的文本:
一般情况下,住宿费用超出标准 20% 以内,经直属领导审批后可以报销。这句话很像真实制度,也符合很多企业常见写法。但它可能与你公司制度完全不一致。模型并不是故意骗人,而是在缺少事实依据时继续完成语言任务。
产品经理需要记住一个判断:
模型默认倾向于给答案,而不是默认停下来验证事实。
这就是为什么 AI 产品要主动设计拒答、追问和引用。不要把“请准确回答”写进 Prompt 后就认为风险消失了。Prompt 是约束,不是事实来源。
3.3 训练数据缺陷:模型知道的东西不等于你的业务事实
模型训练数据来自公开文本、授权数据、代码、网页、书籍、问答、合成数据等。即使训练数据规模很大,也有几个天然问题:
-
数据可能过时。
-
数据可能互相矛盾。
-
数据可能包含错误。
-
数据未必覆盖你的公司制度、商品规则、合同版本。
-
数据中的表达频率不等于事实正确性。
-
模型训练后不会自动知道你的最新业务变化。
这对企业 AI 项目影响很直接。比如:
-
公司 2026 年 7 月更新了报销制度,模型训练数据不可能自动知道。
-
平台活动规则昨天变了,模型不会自己同步。
-
商品售后政策按类目、店铺、订单状态变化,模型不能凭常识判断。
-
客服工单里有用户个案,模型没有权限也没有上下文。
所以企业里几乎所有“事实型回答”都不能只依赖模型记忆。可靠做法是:
用户问题-> 权限校验-> 检索当前有效资料-> 模型基于资料生成回答-> 引用来源-> 不足则拒答或转人工这就是 RAG 的基本价值。它不是让模型更会聊天,而是把回答锚定到可追溯资料。
3.4 上下文缺失:资料没给够,模型会补
很多幻觉不是模型本身不知道,而是产品设计没有给足上下文。
例如客服系统里用户问:
我这单可以退款吗?模型要可靠回答,至少需要:
-
用户身份。
-
订单状态。
-
商品类目。
-
是否发货、签收、使用。
-
是否参与活动。
-
退款政策。
-
优惠券和积分规则。
-
是否存在异常风控。
如果系统只把用户这句话发给模型,模型只能按通用退款话术生成,很容易出现错误承诺。
这类问题在 PRD 中必须拆清楚:
| 问题 | 需要的上下文 | 缺失时应做什么 |
|---|---|---|
| 能否退款 | 订单状态、售后政策、风控结果 | 查询系统,查不到则转人工 |
| 能否报销 | 制度版本、金额、城市、审批记录 | 要求补充信息或引用制度 |
| 数据为什么下降 | 指标口径、维度拆解、实验记录 | 给出假设,不给确定归因 |
| 合同风险是什么 | 合同原文、标准条款、法务规则 | 标注风险点,不做法律结论 |
上下文缺失时,好的 AI 产品不应该“硬答”。它应该追问、拒答、转人工或给出不确定提示。
3.5 采样与随机性:为什么同一个问题会答得不一样
大模型生成时通常不是永远选择概率最高的下一个 Token,而是会根据温度、top-p 等采样参数在多个候选中选择。这样做可以让输出更自然、更有创造性,但也会带来不稳定。
不同任务对随机性的容忍度不同:
| 场景 | 随机性容忍度 | 建议 |
|---|---|---|
| 广告文案创意 | 高 | 可以生成多版本 |
| 标题改写 | 中 | 允许变化,但要规则校验 |
| 用户访谈摘要 | 低 | 要忠实原文,不应自由发挥 |
| 制度问答 | 很低 | 必须基于引用 |
| 退款判断 | 零容忍 | 走规则系统,不由模型判断 |
产品经理要把采样策略纳入功能设计。创意任务可以鼓励多样性;事实任务要降低随机性,并把模型输出限制在资料范围内。
3.6 检索失败:有 RAG 也会幻觉
很多团队以为接了 RAG 就不会幻觉,这是错误判断。RAG 只是降低幻觉的关键手段,不是自动保证正确。
RAG 失败常见原因:
-
文档质量差。 扫描件、图片、表格、旧版 PDF 混在一起。
-
分块不合理。 一个条款被切断,模型拿不到完整条件。
-
召回不准。 用户问法和文档措辞差异大,检索不到。
-
重排失败。 找到了相关文档,但最关键片段排在后面。
-
版本冲突。 新旧制度都被检索出来。
-
权限过滤缺失。 用户看到了不该看的资料。
-
引用不支持结论。 模型引用了段落,但结论是自己补出来的。
所以 RAG 产品要评估两件事:
检索是否找到了正确资料?回答是否忠实于资料?前者是检索质量,后者是答案忠实度。只看“回答看起来不错”是不够的。
3.7 指令冲突:Prompt 写得越多不一定越安全
很多团队遇到幻觉后,会不断在 Prompt 里加规则:
请不要编造。请基于资料回答。如果不知道就说不知道。请务必准确。请严格遵守制度。这些规则有价值,但不能无限堆。Prompt 过长会带来维护困难,也可能产生指令冲突。
例如同一个 Prompt 里同时写:
-
必须回答用户问题。
-
不确定时不得回答。
-
要用亲切语气安抚用户。
-
不得承诺退款。
-
遇到投诉要积极解决。
当用户情绪激烈地要求退款时,模型可能优先执行“安抚”和“积极解决”,输出模糊承诺。
更稳的设计不是把所有安全责任压到 Prompt,而是分层控制:
规则系统:确定性判断权限系统:决定能看什么检索系统:提供事实资料模型:理解和生成后处理:校验格式、禁词、引用人工:处理高风险和不确定场景Prompt 是系统的一部分,不是系统本身。
3.8 幻觉风险分级:不是所有错误都同等严重
AI 产品不能只写“降低幻觉”。必须区分风险等级。
| 风险等级 | 示例 | 后果 | 产品策略 |
|---|---|---|---|
| 低 | 文案措辞不够准确 | 人工修改即可 | 可生成多版本,保留编辑 |
| 中 | 摘要遗漏部分观点 | 影响判断效率 | 显示来源,支持回看原文 |
| 高 | 制度问答编造条款 | 员工按错规则办事 | 强制引用,资料不足拒答 |
| 很高 | 客服承诺退款赔付 | 客诉、损失、合规风险 | 不允许模型最终决策 |
| 极高 | 医疗、法律、金融建议 | 重大责任风险 | 专业审核,严格免责声明和转人工 |
这张表应进入 AI 功能 PRD。没有风险等级,研发无法设计兜底,测试无法验收,业务上线后也不知道什么问题必须回滚。
3.9 幻觉控制的产品设计原则
幻觉控制不是单点功能,而是一组产品原则。
第一,回答必须有事实边界。 系统要定义哪些问题可答、哪些问题不可答、哪些问题只能给参考信息。
第二,关键结论要有来源。 知识问答、制度问答、合同摘要、客服政策解释都应显示引用或原文片段。
第三,资料不足时允许“不回答”。 不回答不是失败,错误回答才是失败。产品指标不能只追求回答率,还要看正确率、拒答率和转人工质量。
第四,高风险动作必须工具或人工确认。 退款、赔付、改价、发券、发邮件、删除数据、提交审批,不应由模型直接执行。
第五,输出要可追溯。 保留用户问题、检索片段、模型版本、Prompt 版本、输出、用户反馈和人工处理结果。
第六,评估集要持续更新。 幻觉控制不是上线前测一次,而是用真实问题不断扩充测试集。
3.10 幻觉指标怎么设计
AI 功能不能只看满意度。对幻觉风险较高的功能,至少要监控:
-
答案准确率。
-
引用准确率。
-
引用支持率:引用内容是否支撑结论。
-
无依据回答率。
-
错误承诺率。
-
拒答正确率。
-
转人工准确率。
-
高风险问题拦截率。
-
用户负反馈率。
-
人工复核通过率。
其中最容易被忽略的是“引用支持率”。很多系统会给出引用,但引用只是相关,不一定支持结论。
例如引用原文说:
超标准住宿需提前审批。模型回答:
只要直属领导口头同意即可报销。这就是引用不支持结论。测试时必须专门抓。
3.11 PRD 里如何写幻觉控制
一个合格的 AI 功能 PRD,不应该只写“模型基于知识库回答”。至少要写清:
-
可回答范围:哪些问题属于当前功能。
-
不可回答范围:哪些问题必须拒答或转人工。
-
输入依赖:需要哪些业务数据和知识资料。
-
资料优先级:制度、FAQ、订单系统、人工记录谁更权威。
-
引用要求:哪些答案必须给来源。
-
拒答规则:何时说不知道、何时追问。
-
高风险动作:哪些动作必须人工确认。
-
评估指标:准确率、引用支持率、幻觉率、转人工率。
-
日志与复盘:记录哪些信息。
-
灰度与回滚:什么错误触发暂停或降级。
这会让 AI 项目从“接模型试试”变成可验收、可上线、可复盘的产品工程。
4. 案例一:制度问答中编造报销规则
业务背景
一家国内互联网公司希望用 AI 做内部制度助手,覆盖差旅报销、采购申请、请假、合同审批等问题。员工可以在企业 IM 里直接问:
我去深圳出差,酒店超了标准 80 元,经理微信同意了,可以报销吗?业务希望减少财务和行政重复咨询,同时提升员工查制度效率。
相关角色
-
员工:希望快速知道能不能报销。
-
财务:负责制度解释和报销审核。
-
行政:负责差旅标准维护。
-
HR 或制度管理员:负责制度版本发布。
-
产品经理:负责问答范围、风险边界、验收指标。
-
研发/AI 工程:负责文档接入、检索、模型调用、日志。
-
法务/内控:关注制度合规和审计责任。
原始流程
员工查制度文档-> 找不到或看不懂-> 问财务/行政-> 财务询问城市、金额、审批情况-> 人工判断是否符合制度-> 员工提交报销-> 财务审核痛点:
-
员工不知道该看哪份制度。
-
制度正文、附件和城市标准表分散。
-
新旧制度容易混淆。
-
财务重复回答高频问题。
-
员工会把“咨询答复”当成报销承诺。
幻觉发生方式
如果系统只把员工问题交给模型,模型可能回答:
深圳出差住宿超标 80 元,若直属经理已审批,一般可以正常报销。建议在报销单中上传微信审批截图。这个回答看起来合理,但可能完全错误。真实制度可能规定:
-
超标必须在出差前走 OA 审批。
-
微信同意不算有效审批。
-
不同职级有不同住宿标准。
-
深圳一类区域和二类区域标准不同。
-
超标金额无论多少都需要部门负责人和财务负责人审批。
幻觉的根因不是模型不会写,而是系统没有拿到权威资料和审批记录。
AI 改造流程
员工提问-> 身份与权限校验-> 问题结构化:城市、费用类型、超标金额、审批方式-> 检索当前有效制度、城市标准表、审批要求-> 检查是否存在必要字段缺失-> 生成带引用的回答-> 若缺少审批记录或条件不完整,则追问或转人工-> 记录问答、引用、反馈和人工复核结果数据与系统依赖
-
当前有效差旅制度。
-
历史制度版本和生效日期。
-
城市住宿标准表。
-
组织架构和职级。
-
OA 审批记录。
-
报销系统规则。
-
财务人工答疑记录。
-
员工权限和部门信息。
方案架构
企业 IM -> 问题解析 -> 场景识别:差旅报销 -> 字段抽取:城市/金额/审批/时间 -> 权限校验 -> RAG 检索 -> 制度正文 -> 附件标准表 -> 审批要求 -> 业务规则校验 -> 是否缺字段 -> 是否高风险 -> 模型生成 -> 结论 -> 引用 -> 需补充信息 -> 财务转人工 -> 日志与评估集沉淀关键指标
-
自助解决率。
-
财务人工咨询量下降。
-
引用准确率。
-
引用支持率。
-
制度版本命中率。
-
无依据回答率。
-
高风险问题转人工率。
-
员工满意度。
-
报销审核驳回率变化。
主要风险
-
模型引用旧制度。
-
模型把“可咨询”说成“可报销”。
-
审批记录未查询到却给确定结论。
-
用户无权限查看某些制度。
-
员工截图或描述不完整。
-
财务审核口径与知识库不同步。
复盘结论
制度问答适合用 AI,但不能把模型回答等同于制度结论。产品设计上必须区分:
-
AI 可以解释制度。
-
AI 可以提示需要哪些材料。
-
AI 可以引用当前制度条款。
-
AI 不应替代报销审核系统做最终判断。
上线时不要只测“能不能回答”,要重点测“资料不足时能不能拒答”“引用是否支持结论”“高风险问题是否转人工”。
5. 案例二:智能客服错误承诺赔付
业务背景
一个电商平台在大促期间接入 AI 客服,目标是降低人工咨询量。高频问题包括物流延迟、退款、优惠券、发票、售后维修、活动价保。
用户问:
我的订单说昨天到,今天还没到,你们是不是要赔我?不赔我就投诉。相关角色
-
消费者:希望获得明确解决方案。
-
AI 客服:负责初步接待和低风险问题回答。
-
人工客服:处理投诉、赔付、异常订单。
-
运营:负责活动规则和服务承诺。
-
售后/物流团队:负责订单状态和异常处理。
-
产品经理:负责客服流程、风险分级、指标。
-
法务/合规:关注承诺、赔付和平台规则。
原始流程
用户咨询-> FAQ 机器人尝试命中-> 命不中转人工-> 人工查询订单和物流-> 判断是否符合赔付或补偿-> 回复用户并创建工单大促期间人工压力大,平台希望 AI 先承担更多对话。
幻觉发生方式
如果 AI 客服为了安抚用户,直接回答:
很抱歉给您带来不便,您的情况符合延迟配送赔付规则,我们会为您补偿 10 元优惠券。这就是高风险幻觉。它可能违反实际规则:
-
订单是否承诺时效不确定。
-
物流延迟是否由平台责任导致不确定。
-
商品类目是否支持赔付不确定。
-
用户是否已享受其他补偿不确定。
-
优惠券发放需要工单或人工审批。
这种错误不只是答错,会直接形成用户预期和平台责任。
AI 改造流程
用户消息-> 情绪与投诉风险识别-> 订单状态查询-> 物流状态查询-> 服务承诺规则检索-> 风险分级 -> 低风险:解释规则、查询进度 -> 中风险:创建工单、提示等待处理 -> 高风险:转人工,不承诺赔付-> 回复生成-> 日志记录与质检数据与系统依赖
-
订单系统。
-
物流轨迹。
-
商品类目和店铺规则。
-
平台服务承诺。
-
赔付规则和优惠券发放规则。
-
用户历史补偿记录。
-
工单系统。
-
客服质检系统。
方案架构
用户会话 -> 意图识别 -> 催物流 -> 索赔 -> 投诉威胁 -> 风险分类 -> 工具调用 -> 查订单 -> 查物流 -> 查服务承诺 -> 查补偿记录 -> 回复策略 -> 解释规则 -> 引导工单 -> 转人工 -> 禁止项校验 -> 不承诺赔付 -> 不承诺到达时间 -> 不编造规则 -> 质检与复盘关键指标
-
自助解决率。
-
人工接管率。
-
高风险问题识别率。
-
错误承诺率。
-
投诉升级率。
-
用户满意度。
-
单会话成本。
-
平均响应时间。
-
赔付工单人工复核通过率。
主要风险
-
AI 为安抚用户而承诺赔付。
-
AI 编造物流到达时间。
-
活动规则和赔付规则过期。
-
订单系统查询失败但模型继续回答。
-
用户通过诱导话术要求 AI 给承诺。
-
高峰期为了降低人工接管率而放大自动处理范围。
复盘结论
智能客服的目标不是“尽量不转人工”,而是把正确的问题交给正确的处理路径。对赔付、投诉、退款审批这类高风险事项,AI 可以做信息收集、规则解释和工单分流,但不应做最终承诺。
这里的产品指标要避免单一追求自助解决率。如果自助解决率上升,但错误承诺率、投诉升级率也上升,项目就是失败的。
6. 动手实操任务
任务:设计 10 条容易诱发幻觉的问题
请选择一个你熟悉的业务场景,例如:
-
企业制度问答。
-
智能客服。
-
商品文案生成。
-
合同摘要。
-
运营数据分析。
-
销售跟进助手。
设计 10 条容易诱发幻觉的问题,并标注风险。
建议覆盖以下类型:
-
资料缺失型:问题需要资料,但系统可能没有。
-
版本冲突型:新旧规则可能不同。
-
权限限制型:用户不应看到某些信息。
-
高风险承诺型:涉及退款、赔付、审批、价格。
-
诱导编造型:用户要求模型给不存在的依据。
-
数据归因型:模型可能编造原因。
-
边界模糊型:问题介于可答和不可答之间。
-
多条件判断型:需要多个字段共同决定。
-
引用错配型:资料相关但不支持结论。
-
情绪压力型:用户要求立即给确定答复。
按下面模板输出。
| 编号 | 测试问题 | 幻觉诱因 | 正确处理方式 | 风险等级 | 验收标准 |
|---|---|---|---|---|---|
| 1 | 我的超标住宿经理同意了,能报销吗? | 缺审批记录、制度条件复杂 | 追问/检索制度/提示需财务审核 | 高 | 不得直接承诺可报销 |
验收标准
合格:
-
至少设计 10 条问题。
-
每条问题说明幻觉诱因。
-
每条问题写出正确处理方式。
-
至少覆盖 3 个不同风险等级。
优秀:
-
能把测试问题转成上线前评估集。
-
能定义“通过/失败”的验收标准。
-
能指出哪些问题必须转人工,哪些可以拒答,哪些可以基于引用回答。
7. 测试题与参考答案
理解题
1. 为什么大模型会产生幻觉? 参考答案:因为大模型主要按上下文预测最可能的后续文本,不天然验证事实。训练数据可能过时或错误,上下文可能缺失,采样会带来随机性,检索也可能失败,因此模型可能生成看似合理但不准确的内容。
2. 幻觉为什么比普通系统错误更难处理? 参考答案:因为幻觉通常表达流畅、语气自信,用户难以识别;同问可能不同答;如果没有引用和日志,很难追溯错误来源;在业务场景中还可能形成承诺和责任风险。
3. 为什么 RAG 不能彻底消除幻觉? 参考答案:RAG 依赖文档质量、分块、召回、重排、权限和版本管理。即使检索到相关资料,模型也可能引用不支持结论的内容。因此仍需评估检索准确率和答案忠实度。
4. 为什么不能用 Prompt 完全解决幻觉? 参考答案:Prompt 可以约束模型行为,但不能提供真实事实,也不能替代规则系统、权限系统、检索系统和人工审核。Prompt 过长还可能产生冲突和维护问题。
5. 幻觉控制中为什么“拒答”是必要能力? 参考答案:资料不足、高风险、无权限或超出范围时,拒答比错误回答更安全。AI 产品不能只追求回答率,还要衡量拒答正确率和转人工准确率。
应用题
6. 一个企业制度问答助手如何降低幻觉? 参考答案:应接入当前有效制度,做权限校验、文档分块、检索与重排;回答必须带引用;资料不足时追问或拒答;高风险报销和审批问题转人工;记录日志并建立幻觉评估集。
7. 智能客服遇到用户要求赔付时应该如何设计? 参考答案:先识别高风险意图,查询订单、物流、服务承诺和补偿记录;AI 可以解释规则和创建工单,但不得直接承诺赔付。赔付、退款、投诉升级应转人工或由规则系统判断。
8. 当日产出模板
8.1 幻觉测试题库 v1
| 编号 | 场景 | 用户问题 | 所需事实来源 | 幻觉诱因 | 期望处理 | 失败表现 | 风险等级 |
|---|---|---|---|---|---|---|---|
| 1 | 制度问答 | 制度文档/审批记录 | 引用回答/追问/拒答/转人工 | 编造条款/无依据承诺 | 高 |
8.2 AI 回答风险分级与兜底表
| 风险等级 | 问题类型 | 允许模型直接回答吗 | 必要机制 | 触发兜底 |
|---|---|---|---|---|
| 低 | 文案风格建议 | 可以 | 可编辑、多版本 | 用户不满意 |
| 中 | 摘要与信息抽取 | 有条件可以 | 原文引用、可回看 | 低置信或用户质疑 |
| 高 | 制度政策解释 | 仅可基于引用 | RAG、引用、拒答 | 无资料或版本冲突 |
| 很高 | 退款、赔付、审批 | 不可以 | 规则系统、人工确认 | 涉及金额或承诺 |
| 极高 | 医疗、法律、金融建议 | 不可以 | 专业人员审核 | 任何具体决策建议 |
8.3 PRD 幻觉控制清单
功能名称:可回答范围:不可回答范围:必须引用的问题类型:必须拒答的问题类型:必须转人工的问题类型:需要调用的业务系统:资料版本优先级:高风险动作列表:评估指标:灰度策略:回滚条件:日志字段:9. 延伸阅读资料
-
Transformer 直觉。重点回看“概率生成”和“上下文关系”。
-
Embedding 与语义检索。理解 RAG 为什么能降低幻觉,以及为什么检索质量会影响答案质量。
-
NIST AI Risk Management Framework:用于建立 AI 风险识别、测量和治理思路。
-
业务内部资料:制度文档、客服质检记录、报销驳回案例、赔付投诉案例。这些比通用文章更适合做幻觉测试集。
文章分享
如果这篇文章对你有帮助,欢迎分享给更多人!












