英国内政部难民审核翻车给 AI Agent 落地带来的事实核查启示

最近英国内政部（Home Office）在处理难民庇护申请时出现的一起误判案例，给所有 AI 开发者敲了警钟。简单来说，内政部在审核过程中采信了 AI 生成的虚假事实，导致申请被错误拒绝，最终被法官判定为失误。这个案例最核心的痛点在于：在严肃的行政决策场景中，如果过度信任大模型的总结能力而缺失了“事实核查”环节，AI 的幻觉将直接转化为严重的程序失误。

从技术底层来看，这种情况通常发生在直接使用通用大模型进行文档分析时。模型为了维持输出的流畅度，在检索不到确切答案时会倾向于“一本正经地胡说八道”。对于法律、医疗等高容错率要求的工作流，单纯依赖 Prompt 引导是不够的，必须在架构上强制执行 RAG（检索增强生成）并引入严格的引用校验。

要在实战中规避此类问题，我建议在构建审核类 AI Agent 时，从以下三个技术维度进行约束：

首先是强制要求引用来源，将“不可推断”写入系统级指令。很多开发者习惯于让 AI “总结全文”，但这给了模型发挥想象力的空间。正确的做法是在 System Prompt 中明确：每一句结论必须对应原文的页码或段落，禁止出现无出处的推断。

例如，可以采用如下的约束逻辑：
You are a strict document analyst. For every claim you make, you MUST provide a direct quote from the source text and its exact location (page/paragraph). If the information is not explicitly stated in the provided text, you must respond with "Information not found" instead of inferring.
通过这种方式，将 AI 的角色从“创作者”强制转变为“搬运工”，从源头上压制幻觉。

其次，必须引入交叉验证（Cross-Verification）机制，打破单点依赖。不要试图让一个模型完成从“提取事实”到“得出结论”的所有工作，因为模型在自我验证时往往存在认知偏差。一个更稳健的架构应该是：由模型 A 负责从文档中提取关键事实，随后将提取结果与原文片段一同交给模型 B，由模型 B 专门负责对比两者的逻辑一致性。只有当模型 B 确认事实无误后，结论才能进入最终审核环节，形成一个闭环的校验链路。

最后，在 API 调用层面优化参数，压制随机性。在处理此类严肃任务时，绝对不能使用较高的 Temperature。建议将 Temperature 设定为 0 或 0.1，尽可能让模型输出最确定性的 Token。同时，可以通过分析 Logprobs（对数概率）来监控模型对某个结论的置信度，如果某个关键判断的置信度低于预设阈值，系统应自动触发人工介入，而不是直接输出结果。

这个案例告诉我们，AI Agent 的落地不能只追求“效率提升”，而应将“确定性”放在首位。AI 只能作为辅助决策的工具，绝不能成为最终裁决的唯一依据。在任何可能影响个人命运的决策流中，必须建立一套从 Prompt 约束、架构校验到参数控制的完整防御体系。