AI 幻觉早已不是模型演示时的娱乐效果。当它出现在对话机器人、AI 客服、代码辅助工具、RAG 知识库问答和 Agent 自动执行链路里一次看似合理的错误输出可能直接变成错误决策、错误调用甚至安全事件。更值得警惕的趋势是攻击者不再只依赖传统 prompt 注入去“撬开”系统而是借助模型对虚构内容的高置信输出把幻觉内容当作攻击载体。对于 AI 应用开发者和安全工程师来说问题已经从“模型会不会编”升级为“模型编了之后系统会不会照做、怎么拦截、怎么兜底”。下面从幻觉的产生机制讲起再分别在输入侧、输出侧、Agent 执行链三个位置给出防护思路最后给出可量化的评测、排查和回归方法。1. 先理解 AI 幻觉为什么模型会一本正经地胡说八道1.1 幻觉的通俗含义与技术定义通俗地说AI 幻觉就是模型生成了流畅、自信、但事实不成立的内容。它不是在说“我不知道”而是在用和真实事实几乎相同的语气给出一个不存在的数据、不存在的引用、不存在的函数参数或不存在的操作结果。技术定义上可以把幻觉理解为“生成内容与已知事实、用户提供证据或真实世界状态不一致”。在学术讨论中还会进一步区分“事实性幻觉”和“忠实性幻觉”前者指模型输出与客观事实不符后者指模型输出与用户给定的上下文或任务意图不符。对工程团队来说这两类问题都需要处理但处理方式不同。事实性幻觉常见于通用问答、法律、医疗、金融等依赖外部事实的场景忠实性幻觉常见于 RAG 知识库问答、文档摘要和 Agent 工具调用场景。做防护设计时应把这两类分开评估因为前者的兜底手段往往是外部知识校验后者的兜底手段往往是上下文约束和执行前验证。1.2 从生成机制看幻觉产生的四个常见原因从大模型的工作机制看幻觉很难被单一原因解释清楚常见原因可以归纳为四类。第一训练目标侧重流畅性而非事实性。语言模型在预训练阶段学习的是词与词之间的条件概率分布目标是预测下一个 token而不是维护一个可查询的事实数据库。这个机制决定了模型天然会把“常见但未必正确”的表达方式当作优先输出。第二解码策略会放大高置信错误。即使模型对某个错误 token 的置信度只有 0.3如果采样过程中其他候选更低这个错误 token 仍然可能被选中。低温或贪心解码可以减少随机性但不能消除概率分布本身对错误表达的偏好。第三上下文缺失或上下文冲突。如果用户输入的问题超出模型已学知识或者检索到的文档本身互相矛盾模型会在无法确定真相的情况下强行生成一个“看起来合理”的回答。第四检索错误被当成了事实。RAG 场景里如果召回片段与问题不相关、切片切断了重要信息或者排序模型把错误文档排在前面模型会把该错误文档中的内容当作“证据”输出。这时候错误源头不在生成模型而在检索链路。1.3 安全视角为什么一句胡编会升级成一条攻击路径在安全视角下问题不在于模型“说了错话”而在于系统“默认相信了这句错话”。多数 LLM 应用的设计链路是模型输出 - 业务逻辑 - 用户展示或工具执行。中间如果缺少事实校验和风险操作确认幻觉输出就会直接从“文本错误”升级为“系统动作”。这里要区分两类风险。一类是内容风险比如 AI 客服把不存在的退款政策告诉用户AI 编程工具生成存在安全缺陷的代码AI 产品经理把虚构的竞品数据写入分析报告。另一类是执行风险比如 Agent 根据模型生成的虚构参数调用了删除接口、发送了邮件或者触发了下游系统变更。对攻击者来说后者更有价值因为攻击面不再只是“让模型说错话”而是“让模型替自己执行一个预设的错误动作”。注意这里提到的攻击利用模式只用于防御侧识别和拦截不涉及任何可利用的指令构造细节。安全意识的核心是知道系统在哪里可能被信任关系击穿而不是学会怎么击穿它。2. 防御侧要识别的三类幻觉滥用模式2.1 虚假权威内容把伪造引用包装成可信材料第一类滥用发生在内容生成场景。模型的输出往往带有权威语气当它捏造引用、法规、产品参数或论文出处时读者很难仅凭文本判断真假。攻击者可以利用这种特性批量生成带有虚假来源的误导性材料用于舆情、客服欺骗或影响自动化审核系统。从防御视角看这类问题主要在输出侧拦截。生产系统必须能够区分“模型生成的文本”和“有依据的事实声明”。最简单的做法是要求模型在涉及具体数字、日期、人名、法规条款时输出证据编号并在后端用检索结果或外部数据库校验。校验不通过时宁可返回“无法确认”也不要返回一段流畅的假话。2.2 错误代码与配置建议问题隐藏在 AI 编程工具里第二类滥用与 AI 编程工具相关。模型在生成代码时可能给出结构完整、语义错误或存在安全问题的代码比如绕过校验的 SQL 拼接、错误的正则、不安全的默认权限配置。攻击者可以通过精心构造的提示词让助手在项目上下文中生成带有明显缺陷的补丁。如果开发者过度信任代码助手不做 review 和静态扫描这份缺陷代码就会进入仓库。防御要点有两层。第一层是在开发流程上建立强制门禁AI 生成的代码与手写代码走同样的审查、静态扫描和测试流水线。第二层是在 IDE 插件或 CI 侧识别“来自代码助手的变更”提高审查优先级。不要因为代码来自“AI 助手”就默认它经过了质量保证。2.3 自动执行链中的越权动作伪造参数触发工具调用第三类滥用最危险发生在 Agent 场景。Agent 的核心特征是“模型输出会触发工具执行”模型在 planning 时生成工具名称和参数如果系统直接把参数交给工具执行攻击者就可以利用幻觉输出构造一个“模型以为正确、业务上完全错误”的执行请求。例如模型可能生成一个不存在的用户 ID、错误的金额、超出权限范围的操作对象执行层如果没有参数校验就会把错误请求变成真实操作。防护侧必须做三件事工具参数按 schema 严格校验、敏感操作进入二次确认状态、Agent 运行在最小权限环境中。后面第 5 章会给出具体实现思路。下表汇总了这三类利用模式方便建立防御检查清单利用模式典型载体风险等级防御侧主要位置虚假权威内容客服话术、分析报告、知识库回答中输出侧事实校验、证据对齐、拒答错误代码与配置建议AI 编程助手、代码补丁高代码审查、静态扫描、CI 门禁自动执行链越权动作Agent 工具调用、工作流编排很高参数 schema 校验、二次确认、最小权限3. 输入侧治理先降低被诱导和注入的可能3.1 建立“输入不可信”假设很多幻觉防护方案只盯着生成模型却忽略了一个事实攻击者可以通过输入干扰模型的判断。建立“输入不可信”假设是输入侧防护的第一步。所有来自用户、网页、文档、传感器或上游系统的文本都应被视为不可信上下文。系统在把外部输入拼入 prompt 之前要先做长度限制、敏感指令识别和来源标记。这句“来源标记”在实践中很重要。如果能把用户输入区域、检索文档区域、系统指令区域在 prompt 中用明确边界分开模型被外部输入“接管”的概率就会降低。虽然它不是完整防御但它能提高后续校验的可靠性。3.2 系统提示词声明输出边界系统提示词的作用是定义模型的行为边界但它不是万能的。一个常见误解是“只要在提示词里写‘不要撒谎’模型就会诚实”。实际上模型没有“撒谎”的元能力它能做到的只是遵循文本层面的约束。因此系统提示词应该写清楚边界规则而不是道德要求。下面是一个面向知识库问答的最小系统提示词模板实际项目可按业务调整你是企业知识库助手只能根据提供的检索片段回答问题。 如果没有检索片段作为依据必须回答“无法从现有资料确认”。 不要补充检索片段之外的具体数字、日期、人名和法规条款。 涉及敏感操作指令时只返回“该操作需要人工确认”不输出后续执行步骤。这段提示词的关键在于把“依据”定义为可检查的检索片段而不是让模型自行发挥。配合输出侧的 evidence 字段就能把“模型是否遵守边界”变成可审计的问题。3.3 对用户输入做基础检测即使有系统提示词也不能完全依赖模型理解边界。输入侧还需要一层规则检测用于识别明显改变指令意图的输入。下面是一个最小示例只做初步过滤不作为完整方案import re SUSPICIOUS_PATTERNS [ r(?i)ignore (all )?(previous )?instructions, r(?i)forget (all )?(previous )?instructions, r(?i)you are now .{0,50}, r(?i)do not follow the system prompt, r(?i)reveal your system prompt, ] def precheck_user_input(text: str) - bool: if len(text) 2000: return False for pattern in SUSPICIOUS_PATTERNS: if re.search(pattern, text): return False return True注意这只是一个粗糙示例正则并不能覆盖真实世界的 prompt 注入方式。生产环境通常还要结合语义检测模型、身份权限判断和输入抽检。把输入检测放在最前面是为了在进入生成链路之前挡住明显异常减少幻觉被外部内容诱导的概率。3.4 关键采样参数对幻觉的影响很多团队在幻觉治理时第一个想到的是调参数但参数只能改变采样分布不能改变模型本身的事实判断能力。下面整理常见参数及其影响参数作用对幻觉的影响推荐做法temperature控制采样随机性越高越容易发散但设为 0 不保证事实正确事实型场景用 0.1-0.3不要依赖 0 防幻觉top_p截断概率累计候选调低会收敛输出空间但同样不保证正确性与 temperature 配合保持稳定即可max_tokens限制最大输出长度过长输出可能脱离依据继续发挥按任务设置合理上限超限就是信号frequency_penalty惩罚已出现 token过高会迫使模型使用不常见词可能增加不稳定输出不为了“表达丰富”大幅调高参数调整只能作为辅助。真正可靠的幻觉治理必须放到输出侧和工具执行侧去解决。4. 输出侧治理把自信的假话变成可审计的真话或拒绝回答4.1 强制结构化输出保留校验字段输出侧防护的第一步是让模型输出结构化数据而不是一段连续文本。结构化输出可以强制模型填写answer、confidence、evidence_ids、unsupported等字段后端再针对这些字段做校验。{ answer: 本市 2025 年公积金缴存比例上限以当地最新通知为准, confidence: 0.62, evidence_ids: [doc_001, doc_002], unsupported: false }这里要说明两个容易误解的地方。第一confidence字段是模型自己给出的它反映的是模型内部概率感并不是事实置信度不能作为唯一依据。第二evidence_ids必须由后端根据检索结果映射不能只信任模型输出的字符串。结构化的价值在于让校验逻辑有明确的输入而不是让校验逻辑去解析自由文本。注意confidence字段代表模型的内部概率感不代表事实置信度。任何情况下都不能把它当作“回答正确”的充分条件。4.2 RAG 场景做引用对齐在 RAG 场景最有效的幻觉治理手段之一是“答案必须能在检索片段里找到依据”。具体做法是先让模型答题再把回答拆成句子与检索片段做相似度或实体对齐低于阈值的句子视为未被证据支持。def verify_evidence(answer: str, evidence_chunks: list[dict], threshold: float 0.6) - bool: answer_sentences [s.strip() for s in answer.split(。) if len(s.strip()) 8] for sentence in answer_sentences: best_score 0.0 for chunk in evidence_chunks: score compute_similarity(sentence, chunk[text]) best_score max(best_score, score) if best_score threshold: return False return Truecompute_similarity在实际项目中可以用 embedding 模型计算向量相似度也可以结合实体抽取判断关键人物、时间、数字是否一致。这个函数只是说明思路生产环境要补充更多细节比如排除无信息量短句、处理口语转述、设置多阈值分级。引用对齐不能只做一次。如果模型给出了多个证据编号但证据内容互相冲突校验也应该判定不通过。比较稳妥的方式是证据冲突时直接拒答而不是让模型“合并出一个答案”。4.3 用独立校验器抽检关键内容另一种输出侧手段是引入独立校验器。需要注意独立校验器不一定是“另一个大模型”。在很多场景里规则引擎、知识库检索、数据库查询比模型更可靠。对于关键实体可以用规则校验。比如回答中出现的金额、日期、电话、邮箱、工号先用正则或实体识别抽取再去权威数据源比对。比对不上的标记为高风险。如果确实要用大模型作为判官需要避免三个问题判官与生成模型使用同一套参数和 prompt 风格容易继承相同的幻觉偏好判官可能因为“讨好”倾向放过明显错误判官本身也会被用户的诱导内容带偏。因此 LLM 判官的输出只能作为辅助信号不能直接作为“事实正确”的结论。对判官判为“正确”的高风险问题仍应抽样人工复核。4.4 不满足条件时选择拒绝回答输出侧最后一道关卡是拒绝回答。很多团队在设计 LLM 应用时只关注“回答质量”却忽视了“有权利不回答”。当校验分数低于阈值、检索片段为空、用户问题涉及敏感操作时系统应该返回固定话术而不是让模型硬答。if not verify_evidence(answer, chunks, threshold0.6): return {answer: 无法从现有资料确认请补充有效依据后再提问。, refuse: True}拒绝回答看似“能力变弱”实际上是在保护系统可信度。对生产系统来说一句诚实的“不能确认”远比一段流畅的虚构内容更有价值。拒答策略也可以分级别完全无证据时拒答有部分证据但置信度低时提示“请核实”证据冲突时提示“资料存在矛盾”。5. Agent 与工具调用侧执行前必须过一道闸门5.1 为什么 Agent 会放大幻觉Agent 系统的风险在于“从文本决策到真实动作”的链路变短了。模型生成call_tool(send_email, {to: xxx, body: ...})如果系统不理解to字段是否真实、body是否含有敏感内容就直接执行幻觉就会从“文本错误”变成“系统事故”。放大效应来自三个方面。第一Agent 的 plan 由模型生成错误 plan 会一路向下执行第二工具返回值会成为下一轮生成的上下文错误返回值会继续污染后续决策第三长链路中每一步的错误都在累计最后一步可能已经看不出最初的事实依赖。因此必须在工具调用入口处拦截而不是等 Agent 执行完再回顾。5.2 工具调用网关模式工具调用网关是 Agent 执行链路的“哨兵”。所有模型生成的工具调用都先经过网关校验再把通过校验的请求交给真实工具。网关至少要做四件事工具名白名单、参数必填校验、参数类型校验、风险等级判断。TOOL_SCHEMAS { send_email: { required: [to, subject, body], type_checks: {to: str, subject: str, body: str}, risk: medium, }, delete_project: { required: [project_id, confirm_reason], type_checks: {project_id: str, confirm_reason: str}, risk: high, }, } def validate_tool_call(tool_name: str, arguments: dict) - dict: schema TOOL_SCHEMAS.get(tool_name) if not schema: return {ok: False, reason: unknown_tool} for field in schema[required]: if field not in arguments or arguments[field] in (None, ): return {ok: False, reason: fmissing_parameter:{field}} expected_type schema[type_checks].get(field) if expected_type and not isinstance(arguments[field], expected_type): return {ok: False, reason: fwrong_type:{field}} if schema[risk] high: return {ok: True, need_confirm: True} return {ok: True, need_confirm: False}这段示例的核心思想是不要把模型输出直接当成“可信参数”而是把工具调用当作外部 API 请求一样对待。真实系统还可以扩展枚举校验、范围校验、权限校验、频率限制和变量替换检查。5.3 敏感操作二次确认高风险的 Agent 操作必须进入确认状态。常见的做法是把工具调用变成状态机PENDING - APPROVED - EXECUTED。模型生成调用后系统先创建一条待确认记录包含工具名、解析后的参数、调用来源和上下文快照然后等待人工或授权系统确认。只有确认通过才真正执行工具。这段设计要解决的是“模型自信地说错”的场景。即使参数校验全部通过业务语义也可能错误二次确认给了决策者一个纠错机会。确认页面或接口需要展示“模型原始输出”和“解析后的结构化参数”方便审查。待确认操作删除项目 demo-project 参数 project_id: demo-project confirm_reason: 用户要求清理测试环境 来源Agent session-20250801-004 风险等级高 确认方式需要项目管理员批准生成这样的确认记录后系统可以把它接入审批流或消息通知。没有确认状态的敏感操作应该直接从工具白名单中移除。注意二次确认不能只确认“是否执行”还要展示“模型原始输出”和“解析后的结构化参数”否则审查者只能看到被模型美化后的结果。5.4 权限收窄与沙箱隔离Agent 权限应该是“按任务最小授权”而不是“模型能调用什么就都给”。可以考虑给不同的对话场景配置不同的工具集合和权限范围场景允许的工具权限范围是否需要确认普通知识问答检索、文档读取只读否数据分析数据查询、报表生成只读 临时计算资源否客服工单处理创建工单、查询工单业务账号最小权限是敏感字段脱敏后台运维操作部署、删除、改配置独立运维账号无生产写权限是必须审批代码执行类 Agent 还应运行在沙箱容器中限制网络、内存、磁盘和系统调用。即使模型生成了错误代码或攻击性命令沙箱可以把影响范围限制在最小环境内。6. 把幻觉从“感觉问题”变成“可量化指标”评测与回归6.1 构造幻觉评测集幻觉治理不能靠人工上线前试几条问题。要建设一个可以重复运行、可以对比版本的评测集让“幻觉变多还是变少”成为一个可量化数字。评测集至少包含四类样本类型说明示例问题方向事实型答案可查证依赖外部数据某产品最新版本号、某法规实施日期统计型答案依赖明确数据容易编造数字某地区人口、某指标同比时效型答案随时间变化模型旧知识容易过期当前年份政策、最新 API 文档反事实型题干包含不可能前提观察模型是否无条件接受“如果某接口返回空是否还能确认成功”构造样本时每一条都要记录问题、期望答案或期望行为、提供的检索上下文、模型版本、评测标签。没有明确标签的问题不要放入评测集否则判分结果会不稳定。下面是一个最小评测样本的 JSON 示例[ { id: eval_001, type: factual, question: 某产品最新版本号是多少, context: 该产品 3.2 版本于 2025 年发布。, expected: 3.2 } ]6.2 用规则判分和 LLM 判官跑评测评测打分可以采用“规则 判官”的组合。规则判分适合检查硬性错误比如数字是否与给定上下文一致、是否出现不应出现的名词。LLM 判官适合评价答案与问题的相关性和忠实度但需要先校准。下面是一个最小评测脚本重点展示流程而不是完整实现def evaluate_hallucination(dataset): total len(dataset) hallucinated 0 for item in dataset: answer call_model(item[question], item.get(context, )) label judge_with_rules(item, answer) if label hallucination: hallucinated 1 return { tested: total, hallucinated: hallucinated, hallucination_rate: hallucinated / total if total else 0, }判分结果要区分“错误类型”比如事实错误、依据缺失、答非所问、拒答不当。只统计一个整体错误率会掩盖问题。实际项目可以在 JSON 里输出错误分类明细。6.3 把幻觉率加入 CI 门禁评测集跑通后下一步就是把结果变成发布门禁。每次提示词版本、模型版本、检索策略或后处理逻辑变更都要重新跑评测超过阈值就阻断发布。result evaluate_hallucination(dataset) if result[hallucination_rate] 0.03: raise SystemExit( fhallucination rate {result[hallucination_rate]:.2%} exceeds 3%, block release )命令行运行方式可以按项目情况设计例如python evaluate_hallucination.py --dataset data/hallucination_eval.json --threshold 0.03阈值要按业务场景设定。客服、医疗、法律、金融场景应该更严格内容生成、营销文案场景可以适当放宽但必须设置上限。门禁只负责拦截明显劣化不能替代持续监控。6.4 线上监控与反馈闭环门禁解决的是“发布前”线上监控解决的是“发布后”。生产环境需要对每次模型输出做抽样记录保存 prompt、检索片段、模型参数、输出结果和校验分数。当校验分数低于阈值或用户点了“答案有问题”时把样本写回评测集形成事实库。线上监控还要关注“幻觉率随时间的漂移”。外部知识在变化模型输出分布也会变化。建议按周或按版本对比幻觉率发现异常时回看链路上哪一层发生了变化动态调整阈值。7. 幻觉安全问题的排查链路与常见坑7.1 排查链路从现象倒推到根因遇到“AI 回答看起来很专业但内容完全错误”的线上问题建议按以下链路排查不要一上来就怀疑模型本身。先确定一下问题现象是数字错误、引用不存在还是触发了不该触发的操作。然后按以下顺序定位复现同一问题记录完整 prompt 和上下文确认不是偶发抖动。检查用户输入是否包含诱导性内容是否绕过了输入检测。若是 RAG 场景检查检索命中的文档、切分方式、排序分数确认证据是否真实相关。检查系统提示词边界确认模型是否被允许“自由发挥”关键内容。对比模型版本和采样参数确定是否有版本升级或参数调整。检查输出侧校验逻辑确认evidence对齐、拒答策略是否生效。若是 Agent 场景检查工具调用网关日志确认参数校验、二次确认是否被跳过。每一步都要有日志。没有日志的场景排错会变成猜谜。建议在链路起始就记录 request_id把所有阶段日志串起来。grep request_id20250801-004 app.log | head -507.2 常见坑这些做法并不能真正防住幻觉错误做法为什么没用推荐做法把 temperature 调到 0 防幻觉低温度只降低多样性不纠正事实性错误把温度稳定在 0.1-0.3事实校验交给后处理提示词写“不要撒谎”模型没有“是否撒谎”的元能力用依据来源、拒答规则和字段约束定义行为让模型“引用来源”但不验证模型可能生成不存在的引用引用编号必须映射到真实检索片段校验后再展示用同一个模型既生成又判分判官会继承相同的偏好和错误模式独立判官 规则校验 高风险问题人工复核Agent 拿到参数直接执行模型输出是概率采样不是可信业务参数工具 schema 校验、风险分级、二次确认只测正常问题不测诱导问题攻击者不会按正常问题路径走评测集加入对抗样本、越权样本、矛盾上下文样本这些坑在真实项目中非常常见而且往往不是单个因素导致而是多个环节都没有防护最终叠加成一次严重事故。7.3 上线前防御清单在发布一个 LLM 应用之前可以按这份清单逐项检查是否对用户输入做不可信假设并配置输入检测。系统提示词是否明确输出边界、依据来源和拒答规则。关键数字、日期、人名、法规是否走外部校验。RAG 场景是否有引用对齐校验证据冲突时是否拒答。工具调用是否经过 schema 校验是否有风险分级。敏感操作是否进入二次确认是否记录确认人。Agent 运行环境是否最小权限代码执行是否沙箱隔离。是否建设幻觉评测集幻觉率是否进入 CI 门禁。线上是否有全链路日志是否保存 prompt、检索、输出快照。是否有线上抽检和用户反馈回写评测集的通道。这份清单适用于大多数对话、RAG 和 Agent 场景。不同业务可以根据风险等级增加审查项比如金融场景增加金额一致性校验医疗场景增加专业术语复核。从一线实践看AI 幻觉治理最核心的一步是改变团队认知不要把幻觉当成“模型偶尔犯傻”而是当成“系统缺少事实校验能力的必然表现”。一个值得投入的方向是把幻觉评测和工具调用网关做成 AI 应用的公共组件而不是每个项目临时拼凑。下一步可以从 RAG 检索质量评估、Agent 可观测性和提示词版本管理这几个方向继续深入。对新手来说最有价值的练习是拿一个小型知识库 QA 项目把输入检测、引用对齐、拒答逻辑、评测集和 CI 门禁完整跑一遍再用诱导输入验证一次很快就能理解幻觉风险是如何被系统性地放大的。