为什么 AI 会胡说
很多人第一次接触大模型时，会把“AI 胡说”理解成模型不够聪明。
但在真实应用里，幻觉不只是智力问题。它更像一个系统可靠性问题：模型生成机制、上下文质量、Prompt 约束、检索结果、工具返回值、产品交互和业务边界，都会影响最终输出。
对前端工程师来说，理解幻觉不是为了研究模型内部公式，而是为了回答几个工程问题：
- 哪些场景不能直接相信模型文本？
- 哪些错误可以靠 UI、数据和工具降低？
- 什么时候应该拒答、追问或转人工？
- 如何让用户知道答案依据来自哪里？
- 如何在上线后持续发现质量退化？
如果把 AI 当成一个“会返回字符串的接口”，幻觉会变成线上事故。如果把它当成一个“需要可靠性设计的非确定性组件”，就能用工程方法把风险压低。
什么是幻觉
幻觉指的是模型输出了看起来合理、语气自信，但缺乏事实依据、上下文依据或业务依据的内容。
它不一定表现为荒唐答案。更危险的是那些很像真的回答：
- 编造不存在的 API 参数。
- 引用一篇看似真实但不存在的论文。
- 把用户没有提供的信息当成事实。
- 对工具结果做过度推断。
- 在权限不足时假装已经完成操作。
- 用旧知识回答一个已经变化的问题。
所以幻觉不是“模型乱说一句话”这么简单。它是输出和依据之间断开了。
当最终回答不能被上下文或外部事实支持时，就进入了幻觉风险区。
为什么模型容易编出答案
大模型的核心行为是根据上下文生成下一个 token。它学到的是语言、知识、模式和任务行为的统计规律，而不是像数据库一样按主键查询事实。
这带来一个关键差异：传统程序在缺数据时通常会报错、返回空数组或抛异常；模型在缺数据时仍然可能生成“最像答案的答案”。
如果用户问：
模型本身不知道你的公司数据。除非系统提供了数据库查询、报表工具或上下文片段，否则它只能猜、拒答或说明无法确定。一个可靠系统应该把它导向后两种行为，而不是让它自由补全。
这也是为什么“让模型更聪明”不能单独解决幻觉。模型能力提升可以减少一部分错误，但只要系统没有给足依据、没有定义边界、没有验证输出，幻觉仍然会发生。
前端熟悉的类比：未受控输入
前端工程师可以把模型输出类比成用户输入。
用户输入可能为空、超长、格式错误、包含脚本、选择了不存在的枚举项。我们不会因为表单来自自家页面，就直接信任它。我们会做校验、转义、权限检查、错误提示和日志记录。
模型输出也一样。
它可能：
- 格式不符合 schema。
- 引用了不存在的数据。
- 把可选字段当成必填事实。
- 把建议说成已经执行。
- 对业务规则理解错误。
- 在边界场景下编出一个“合理补全”。
区别是，用户输入通常看起来像输入；模型输出看起来像答案。它的语气更容易让人放松警惕。
可靠的 AI 应用不会把模型输出当成真相，而是把它当成“候选结果”，再根据场景决定是否需要校验、引用、工具执行或人工确认。
幻觉的四种常见类型
第一类是事实幻觉。模型给出不存在、不准确或过时的事实。
例如它说某个 npm 包支持一个并不存在的配置项，或者把一个产品已经下线的功能描述成仍然可用。事实幻觉在技术问答、政策说明、医疗法律、金融分析里尤其危险。
第二类是引用幻觉。模型给出看似可信的来源、链接、论文、文档标题或法规条款，但这些来源并不能支持它的结论，甚至根本不存在。
在 RAG 应用里，引用幻觉也可能表现为“引用了检索到的文档，但答案其实不是文档里说的”。这比没有引用更迷惑，因为用户会以为有来源就可信。
第三类是推理幻觉。模型拿到了部分事实，但推导过程跳步、偷换概念或过度概括。
例如工具返回“用户最近 7 天登录 1 次”，模型却总结为“用户已经流失”。这不是事实字段错了，而是结论超出了证据。
第四类是工具幻觉。模型声称调用了工具、完成了操作、读取了数据，或者基于一个并未成功的工具结果作答。
例如前端显示“已为你创建日程”，但后端工具其实失败了。这个问题不是普通文本错误，而是动作状态和 UI 状态错位。
幻觉通常从哪里来
幻觉的来源可以按链路拆开看。
用户输入含糊时，模型会倾向于补全意图。补全有时提升体验，有时制造错误。比如“帮我总结这个合同”，但用户没有上传合同，系统应该追问或提示缺文件，而不是泛泛讲合同摘要。
Prompt 边界不清时，模型不知道什么时候该拒答、什么时候该引用来源、什么时候必须调用工具、什么时候只能输出结构化 JSON。
上下文缺失时，模型会用训练中学到的一般模式填空。上下文污染时，它可能被旧历史、错误摘要、无关检索片段带偏。
检索错误时，RAG 不但不能降低幻觉，反而会给模型一组错误依据。模型很擅长把噪声组织成连贯文本。
工具失败时，如果系统没有把失败状态清楚传给模型和前端，模型可能继续沿着“任务已完成”的方向生成。
界面设计也会放大幻觉。如果 UI 只展示最终答案，不展示来源、工具状态、置信边界和用户可操作的纠错入口，用户很难判断答案是否可靠。
可靠性设计的第一原则：承认不确定
很多 AI 应用一开始会追求“永远回答”。这在 Demo 里好看，在产品里危险。
可靠系统应该允许模型说：
- 我没有足够信息。
- 当前资料无法支持这个结论。
- 需要你补充文件或字段。
- 我可以给出一般建议，但不能确认具体事实。
- 这个操作需要你确认后才能执行。
这不是降低智能感，而是提高可信度。
前端可以把不确定性设计成明确状态，而不是失败文案：
模型不应该独自承担所有可靠性责任。UI、状态机、后端校验和日志都应该参与。
降低幻觉的工程手段
第一，给模型提供足够且干净的上下文。
如果答案必须来自某份文档，就不要只说“参考知识库”，而要把相关片段、标题、时间、权限和来源 ID 放入上下文。上下文越明确，模型越不需要猜。
第二，把自由文本问题变成受控流程。
例如报销助手不要让模型直接判断“能不能报”，而是先抽取费用类型、金额、日期、发票状态，再调用规则引擎，最后由模型解释规则结果。
第三，使用结构化输出和 schema 校验。
模型适合生成候选 JSON，但 JSON 必须通过 Zod、JSON Schema 或后端 DTO 校验。格式不合法就重试、修复或降级，不要让半结构化结果进入业务流程。
第四，为事实回答加来源约束。
资料问答可以要求每个关键结论绑定 source id，并在后端验证 source id 是否来自本次检索结果。更进一步，可以做句子级引用校验或 answer-grounding 检查。
第五，让工具结果成为事实源。
余额、订单、权限、库存、日程、账单这类信息不应该让模型凭记忆回答。模型负责理解意图，系统负责查工具，最终答案必须基于工具结果。
第六，为高风险场景加入人工确认。
发邮件、删除数据、修改权限、创建订单、提交审批，都不应该由模型一句话直接完成。模型可以准备草稿和参数，用户确认后系统执行。
前端应该暴露哪些可靠性信号
可靠性不是后端内部指标，也会体现在界面上。
一个 AI 回答组件可以考虑展示：
- 正在检索、正在调用工具、正在生成的阶段状态。
- 引用来源、文件名、段落或数据更新时间。
- 工具执行成功或失败状态。
- “无法从当前资料确认”的边界提示。
- 用户反馈入口，如有帮助、无帮助、事实错误、引用错误。
- 重新生成、补充上下文、转人工等后续动作。
这些设计不是为了让界面变复杂，而是为了让用户能判断“这条回答该怎么用”。
如果答案用于写作润色，可以宽松一些。如果答案用于合规判断、财务计算或生产操作，就必须让依据和状态可见。
常见坑
第一个坑：把幻觉当成 Prompt 文案问题。
Prompt 很重要，但只改 Prompt 无法弥补缺数据、错检索、工具失败和权限混乱。很多幻觉要在系统设计层解决。
第二个坑：以为接了 RAG 就不会幻觉。
RAG 只是把外部资料放进上下文。检索召回错、排序错、切片错、资料过期，都会让模型基于错误上下文生成更自信的错误。
第三个坑：只要求模型“不要编造”。
这类指令有帮助，但不够。你还需要定义缺信息时的行为、引用格式、工具调用条件、校验规则和失败降级。
第四个坑：把引用当装饰。
如果引用不能被点击、不能映射到真实文档、不能支持对应句子，它只是可信度包装。引用系统需要后端数据结构和校验。
第五个坑：上线后不记录失败样例。
幻觉很难靠开发阶段一次性消灭。线上用户会问出你没想到的问题。没有日志和反馈闭环，就无法持续改进。
小结
AI 会胡说，不是因为它“故意骗人”，而是因为它会在不确定、缺依据或边界不清时继续生成看似合理的文本。
前端工程师需要把模型看成非确定性组件：它能理解语言、组织信息、生成方案，但它的输出必须被上下文、工具、schema、引用、权限和用户确认共同约束。
可靠性设计的目标不是让模型永不犯错，而是让错误更少、更早暴露、更容易定位，并且不会悄悄变成真实业务动作。