Agent Output Validation & Fact-Checking/ 智能体输出校验与事实核查

智能体输出校验与事实核查（Output Validation & Fact-Checking）是在 Agent 生成最终答案后、交付给用户之前，增设一层自动化「事实把关」机制——通过规则引擎、外部知识库交叉验证、或二次 LLM 审查等手段，系统性地检测和修正输出中的幻觉、事实错误和逻辑矛盾，确保 Agent 的每一句断言都经得起推敲。

输出校验层按成本和深度分为三种形态，实际生产中通常是三者组合使用：

**1. 基于规则的静态校验（Rule-Based Validation）——最轻量级**

用正则、JSON Schema、Pydantic 等校验输出的格式和结构是否合规。例如：日期格式是否正确、引用的 URL 是否可达、数值范围是否合理、引用来源是否在可信域内。优点：零额外 LLM 调用成本、确定性执行、毫秒级延迟。缺点：只能校验「格式」和「结构」，无法判断「内容是否真实」。

**2. 外部知识库交叉验证（External Knowledge Cross-Referencing）——中间重量级**

Agent 输出中声称的「事实」由校验层提取关键断言，调用搜索 API、知识图谱或权威数据库进行独立核实。例如：Agent 说「Python 3.12 引入了 PEP 701」，校验层自动查询 Python 官方文档验证。常用工具包括 Google Fact Check Tools API、Wikipedia API、自建 RAG 知识库召回比对。这种方式能有效检测「显性幻觉」（捏造事实），但对「隐性幻觉」（真实事实的错误推论）效果有限。

**3. 二次 LLM 审查（LLM-as-Judge）——最深度但成本最高**

用一个独立的、不同模型（甚至不同厂商）的 LLM 作为「审查官」，对 Agent 的输出进行逐句审查：识别幻觉、检测逻辑矛盾、评估置信度。可结合 Chain-of-Verification（CoVe）技术——让审查 LLM 先生成验证问题，再逐一回答验证，最后比对结论。关键原则：审查 LLM 必须与生成 LLM 来自不同厂商，避免「同一模型给自己打高分」的偏差。

核心设计模式：**校验管道（Validation Pipeline）**——按成本和速度从小到大串联，规则层先过（零成本拦截格式错误），知识库层再筛（低成本过滤显性幻觉），最后 LLM-as-Judge 兜底（高成本处理疑难案例）。

• **测试一：幻觉注入测试——度量检出能力**

• 操作：准备 50 个涵盖时间、地点、人物、技术参数的「虚假断言」测试用例（如将正确事实「GitHub 成立于 2008 年」篡改为「GitHub 成立于 2005 年」），让 Agent 处理后输出这些断言，再运行校验层验证能否识别

• 工具：HaluEval 基准数据集（https://github.com/RUCAIBox/HaluEval）+ 自定义 Pytest 测试套件；TruthfulQA（https://github.com/sylinrl/TruthfulQA）作为补充

• 指标：幻觉召回率（Recall ≥ 90%）、误报率（正确内容被错误标记的比例，Precision ≥ 85%）、F1 分数

• **测试二：跨模型一致性验证——发现隐藏偏差**

• 操作：用 GPT-4、Claude、DeepSeek 三个模型各跑一次同一批输入，校验层提取每个模型输出的关键事实断言，比对三者是否一致。不一致的自动标记为「待人工审查」

• 工具：LangSmith（https://smith.langchain.com）追踪多模型输出 + 自建一致性比对脚本（diff + 语义相似度）

• 指标：模型间一致性分数（三模型全一致的断言占比 ≥ 80%）、不一致案例中实际存在幻觉的比例

• **测试三：逻辑自洽性检查——预防前后矛盾**

• 操作：让 Agent 输出一个含多步骤推理链条的长回答（如分析某系统的性能瓶颈并提出优化方案），校验层用 NLP 提取推理链条中的前提和结论，检验是否存在前后矛盾

• 工具：Z3 Theorem Prover（https://github.com/Z3Prover/z3）做逻辑可满足性检验；spaCy + 自定义关系抽取脚本

• 指标：逻辑矛盾检出率（≥ 95%）、端到端校验延迟（< 2s，不影响用户体验）

1. **校验层自己也会「犯傻」——审查者的幻觉**：用 LLM-as-Judge 做审查时，审查 LLM 本身也可能产生幻觉，比如错误地「纠正」了原本正确的内容，或者对正确事实产生过度怀疑。解决方案：至少用两个不同厂商的模型做交叉审查（如 GPT-4 + Claude），两个审查官一致认为有问题的才标记；对关键事实（如医疗建议、法律条文）必须走外部知识库验证而非纯 LLM 判断。

1. **校验延迟影响用户体验——慢比错更致命**：加入完整的校验管道后，端到端延迟可能翻倍甚至更多（原始推理 3s + 规则校验 0.1s + 知识库验证 1s + LLM 审查 3s = 7s），用户体感明显。解决方案：按场景分级——闲聊/娱乐场景跳过校验（或仅规则层），技术问答启用规则+知识库，医疗/金融/法律建议启用全量三级管道。同时支持流式返回「初稿→确认版」渐进展示。

1. **隐性幻觉难以检测——最危险的「看起来对」**：显性幻觉（捏造不存在的事实、错误的数字）相对容易通过知识库验证检出，但隐性幻觉（真实事实的错误组合、片面引用导致误导性结论）极难自动化检测。例如 Agent 说「某药厂的不良反应报告在 2020 年增加了 30%」（真实数据），然后推论「因此该药厂产品质量下降」（错误归因——可能是报告制度变更导致）。解决方案：在校验规则中增加「因果推断检测」维度，对包含「因此」「所以」「导致」「说明」等因果关联词的陈述做额外审查，必要时请求人工确认。

• Anthropic - Measuring Faithfulness in Chain-of-Thought Reasoning: https://www.anthropic.com/research/measuring-faithfulness-in-chain-of-thought-reasoning

• HaluEval: 大规模幻觉评估基准（RUCAIBox）: https://github.com/RUCAIBox/HaluEval

• OpenAI - Improving Factuality in Language Models: https://openai.com/index/improving-factuality/

• LangChain Blog - Self-Checking Agent Outputs: https://blog.langchain.dev/self-checking-agent-outputs/