AI 幻觉怎么减少：从成因、案例到上线前的校验

客服机器人不能凭空编出政策例外，报表助手不能随口给出合计值，智能体也不能靠猜测决定修改哪位客户的记录。所谓智能体，就是用模型选择行动、调用工具的软件。落地时的目标很明确：没有依据的答案或操作，不能从应用中放行。

核验日期：2026 年 10 月 17 日。 核验依据为文中链接的模型厂商指南、API 文档、研究案例和法院记录。下文案例均注明出处；校验器和每周清单是实施建议，并非生产环境的实测结果。

什么是 AI 幻觉？它为什么会出现？

大语言模型把错误或缺乏依据的陈述当作答案输出，就是大模型幻觉。LLM 指大语言模型，即通过训练学习文本中的规律、据此生成语言的模型。即使某句话在其他场景中属实，只要你提供的文档无法支持它，对当前任务来说，它仍然没有依据。

可以把模型想成一位熟练的撰稿人，正根据桌上的材料补完一份简报。它能写出一段看似可信的缺失内容，但这并不能证明那段内容应该出现在公司的记录里。

预测通顺的文本，不等于核实事实

OpenAI 于 2025 年 9 月 5 日发布的语言模型为何产生幻觉的研究文章解释了一个关键问题：预训练学习的是如何预测文本，并不是每条陈述都附有真假标签。那些罕见、又没有规律可循的事实，尤其难以从文本规律中还原。后续训练可以改善模型行为，但表达流畅始终不是真实性的保证。

对开发者来说，这意味着产品政策、账户状态和库存信息都应该存放在应用能够读取的权威来源中。把模型“记住”的答案当作数据库，就会引入本可避免的故障。

上下文缺失或过时，答案就会留下空白

模型可能从未收到客户所需的事实。上传的文档可能已经过时，搜索可能找到了错误的产品版本，账户查询也可能失败。Anthropic 在关于 Claude 回答错误的说明中，明确将缺少近期信息列为产生混淆的原因之一。

这里要区分两种事故：助手凭空编造政策，是生成环节出了问题；助手准确复述了过期政策，是信息源管理出了问题。客户得到的都是错误答案，但修改提示词既不能让过期文档重新有效，也修不好失败的账户查询。

只奖励“答出来”，就会鼓励猜测

OpenAI 指出，只看准确率的评测可能会奖励猜测，而不是承认不确定。如果你的成功指标把每次完整作答都算作成功、把每次转交处理都算作失败，同样会落入这个陷阱。

客户要求承诺送达日期时，需要的是权威的物流预计时间。如果承运方尚未提供这一信息，明确说明缺少什么，才是有用的结果。测试和运营看板都应该认可这种处理方式。

大模型幻觉有哪些表现？先抓住四类错误

按照应用需要校验的对象来划分错误。这些类别会有交叉，但能帮助小团队找到具体的校验位置。

**编造事实：**博士论文题目的案例来自 OpenAI 自己的研究记录。模型熟悉一个名字，并不意味着知道缺失的论文题目。放到业务中，类似的问题就是因为同类产品有某项功能，就编造自家产品也具备这项能力。

**数字错误：**同一篇研究中的出生日期案例说明，日期看起来再精确，也不能充当证据。在应用中，要区分没有依据的数值和计算失误。数量应从记录中读取，合计值交给普通代码计算，再让模型解释它拿到的结果。

虚假引用：2024 年 3 月 20 日 United States v. Cohen 一案的法院意见书记载了来自 Google Bard 的三个不存在的判例。Google Bard 是 Google 当时对其生成式助手的命名。其中一条所谓的引用是 United States v. Figueroa-Florez。案件名称和引用格式看起来像真的，并不意味着背后有真实的判例依据。

工具参数错误：Berkeley Function Calling Leaderboard 的作者展示了一次调用：要求的利率是 5%，传入的参数却是 annual_interest_rate: 5，而正确的小数表示应为 0.05。两个值都是数字，单靠类型检查无法区分。这是参数语义错误；并非每一次错误的工具调用都属于事实编造，但执行前都应纳入同一套审查。

如何减少 AI 幻觉，把错误拦在客户看到之前？

在生成前后加入证据和校验，再明确任一环节缺失时系统该怎么做。开发者负责校验机制，运营人员负责权威信息源和升级处理路径。

用最新、相关的信息支撑回答

检索增强生成，即 RAG，会搜索外部材料，并把相关段落提供给模型，让“撰稿人”有据可写。Anthropic 的 Contextual Retrieval 说明解释了为什么检索片段周围的语境也很重要：孤立的摘录可能省略它所描述的公司、时期或对象。

做客服功能时，应先选定权威政策库，并为内容附上产品、地区、生效日期和访问权限等元数据。在生成答案前，先按这些字段筛选。检索取消规则时，要把例外条件一起取回；一段脱离适用条件的文字，可能被用来支撑错误的承诺。

账户的实时信息应从应用数据库或服务中读取。要判断某位客户的订单是否已经发货，文档搜索很难替代实际查询。查询失败时，应返回不可用状态，不能悄悄用通用知识补上答案。

先从简单的检索流程做起。只有当问题需要跨来源继续搜索时，再采用允许模型自主选择后续检索步骤的 agentic RAG。追加搜索也需要停止规则，并接受同样的信息源校验。

排查问题时，关键是确认正确的证据有没有送到模型手里。将来源 ID 和版本与答案一同保存，运营人员才能区分：是检索漏掉了证据，还是模型加入了没有依据的内容。

把“我不知道”设计成应用状态

Anthropic 的减少幻觉指南建议允许模型表达不确定，用原文引述支撑工作，标明依据，并删除没有支持的主张。把这些建议落实为明确的响应约定。

为模型设置清晰的结果状态，例如 answered、needs_clarification 和 insufficient_evidence。没有答案时，不要为了填满必填字段而逼模型编造。界面应把每种状态转化为有用的下一步：提出一个聚焦的追问，说明缺少哪条记录，或携带已检索到的上下文转交处理。

一条实用指令可以这样写：“仅使用所提供的政策和账户记录。如果记录不足以确定答案，请指出缺少的信息。不要根据相似案例推断是否符合条件。”测试这条指令时，要加入证据缺失的情形，不能只测容易回答的问题。

“无法确定”与出于安全原因拒答、工具超时或未授权请求不是同一类状态。日志中应分别记录，才能让对应的负责人处理。

让代码能够核验引用

引用应该指向应用已经掌握的证据。由检索环节分配来源 ID，再由服务器将 ID 解析为获准使用的 URL。不要让模型凭记忆编制参考文献或目标网址。

需要分别检查三个方面：

• **来源是否存在：**被引用的来源 ID 必须属于本次请求获准使用、且已提供给模型的材料。
• **引文是否准确：**引用的文字必须出现在作答时使用的那个确切版本中。
• **能否支持主张：**该段文字是否足以证明这条主张适用于这位客户的情况。

前两项可以直接用代码检查。第三项需要领域规则、可信的结构化字段，或单独审查主张与证据的对应关系。在文档里找到“符合条件”几个字，并不能证明某位客户就符合条件。

Anthropic 的引用文档介绍了与文档关联的引用机制，可帮助定位证据。来源指针有助于审计答案，但不能据此断定来源是否最新、是否权威，或是否得到了正确解读。

用结构化输出约束格式，再校验具体值

结构化输出会用 schema 约束响应，明确允许哪些字段和取值类型，让应用更容易编写检查逻辑。OpenAI 的 Structured Outputs 指南明确提醒：输出仍然可能包含错误；如果响应约定没有提供合适的兜底方式，不兼容的输入还可能诱发幻觉。

执行工具调用前，要校验操作、必填参数、单位、允许的值、记录是否存在，以及调用者权限。租户和已认证用户的身份应由应用代码确定。适当情况下，可以让模型从获准访问的记录中做选择；但模型给出的客户 ID，绝不能作为访问权限的证明。

即便工具调用成功，给客户的回复也必须符合实际结果。如果工具返回的是待处理状态或错误，就不能宣称取消已经完成。最终消息应以工具返回的状态为准。本站的 AI 智能体安全护栏指南进一步介绍了相关的操作边界。

大模型幻觉检测：一个可以直接运行的校验示例

对于范围明确的事实字段，可以把模型给出的值与获准使用的记录核对，再由应用自行生成最终答案。就这个字段而言，这比判断任意一段文字“听起来是否一致”更可靠。

下面的 Python 示例使用的是演示用的客服政策测试数据，并非真实业务政策。将它保存为 verify_answer.py，运行 python3 verify_answer.py 即可。它只使用标准库，不调用任何 API。

# Records must be filtered for the caller's access and policy scope
# before reaching this function. These are illustrative fixtures.
records = {
    "support-policy": {
        "text": "The support channel for this workspace is email.",
        "current": True,
        "fields": {"support_channel": "email"},
    }
}


def validate(result, sources):
    keys = {"status", "field", "value", "source_id", "quote"}
    if not isinstance(result, dict) or set(result) != keys:
        return False
    if result["field"] != "support_channel":
        return False
    if result["status"] == "unknown":
        return all(result[k] is None
                   for k in ("value", "source_id", "quote"))
    if result["status"] != "answered":
        return False
    if not all(isinstance(result[k], str)
               for k in ("value", "source_id", "quote")):
        return False
    source = sources.get(result["source_id"])
    if source is None or source["current"] is not True:
        return False
    quote = result["quote"].strip()
    return (
        bool(quote)
        and quote in source["text"]
        and result["value"]
        == source["fields"].get(result["field"])
    )


proposal = {
    "status": "answered",
    "field": "support_channel",
    "value": "chat",
    "source_id": "support-policy",
    "quote": "The support channel for this workspace is email.",
}

if not validate(proposal, records):
    print("Hold: evidence or value check failed.")
elif proposal["status"] == "unknown":
    print("I cannot confirm the support channel from these records.")
else:
    print(f"Your support channel is {proposal['value']}.")

模型给出的 chat 会被拦下，即使它引用的原文确实存在。如果值是 email，则能通过这一范围有限的校验。确定答案的是可信字段，而不只是引文匹配。

**必须看清它的边界：**这个校验器无法判断自由文本解释是否属实、政策负责人是否录入了正确事实，或上游的访问权限筛选是否生效。它的 unknown 分支只验证响应形式是否被允许，并不判断这次不作答是否必要。这些问题要交给其他检查和评测。对于影响重大的固定事实，用可信数据填充模板，可能就完全不需要生成了。

评测既要奖励答对，也要认可该停就停

评测，也称 eval，是按照预期行为对应用进行的可重复测试。应围绕客户实际遇到的错误建立评测，并在模型、提示词、检索索引、工具 schema 或政策变更时运行。

分别记录这些结果：有依据的正确答案、没有依据的答案、恰当的不作答、不必要的不作答，以及无效的拟执行操作。只看一个平均值，会掩盖改进究竟来自更好的证据，还是仅仅因为系统拒绝回答了更多问题。

精确值、来源是否属于授权集合、必填字段、权限和工具结果，交给普通代码检查。涉及语言判断的问题，例如某段原文是否支持一种改写，可以交给模型裁判，并用人工审核过的示例校准其判断。LLM 裁判本身也是会犯错的模型，不能充当独立的事实来源。

Promptfoo 是一款评测工具，其模型评分断言包括相对于参考答案的事实准确性，以及对所提供上下文的忠实度。这个区分很有用：回答可以完全符合一份过期文档，却不符合今天的实际情况。先明确怎样才算通过，再参考 Promptfoo 指南搭建测试框架。

每条测试轨迹都要把请求、检索证据、拟用参数、实际执行后的工具结果和最终回复保存在一起。用例失败时，这份记录能告诉你该从哪里修。即使模型裁判给文字打了高分，引用缺失或参数无效也必须明确判为失败。

哪些“解决方案”被高估了？

RAG 不能让每个答案都变成真的。 检索到了有用的段落，模型仍可能读错；引用与原文一字不差，原文也可能早已过时。检索和生成要分开测试，信息源集合也要有明确的负责人。

更大的上下文窗口不能替代信息源筛选。 Anthropic 的上下文工程指南提醒，随着上下文变长，召回率和精确率可能下降。应放入相关规则、例外条件和必要的账户证据。把所有文档都塞进提示词，不等于建立了内容更新机制。

另一个模型说“看起来没问题”，本身不算核验。 要给审查者真实证据和清晰标准。缺少独立证据时，两个模型意见一致，可能只是保留了同一个没有依据的假设。

合法的 JSON 不是答案正确的证明。 schema 可以要求填写来源 ID 和数值参数，但应用仍然需要确认来源确实存在，而且数字的含义正确。

真正需要关注的边界，是信息源回答不了哪些问题、校验机制验证不了哪些字段，以及哪些操作无法安全撤销。不存在一个通用的幻觉率，能告诉你某个具体工作流是否已经可以上线。

小团队本周就能执行的清单

如果功能会向客户作出事实性承诺，或修改业务记录，就应该立即着手。如果它只是起草材料，且已经有负责人逐项对照来源审核，可以先建立评测集、改进现有审核，再考虑复杂的自动化架构。如果确定性的查询已经能返回权威字段，可能根本不需要模型。

以下是建议的起步计划，并不代表做完一周工作就能证明系统具备生产环境可靠性。

第一个周一，就从最近的一次错误回答开始，保存它的完整轨迹。判断证据是缺失、过期、被误读，还是被绕过。加入能拦住这类错误的最小检查，再把这次事故固化为永久回归用例。

AI 幻觉常见问题

想获取构建可靠 AI 工作流的实用指南，可以订阅邮件通讯。