1. AI 内容核查怎么做：智能内容 AI 核查系统实践

[!abstract] 速览
文章聚焦百度 AI 内容核查系统的构建实践，指出 AIGC 内容事实错误隐蔽、难以覆盖的核心问题。
作者提出五条核查原则：主张是最小核查单位、证据以权威性为第一排序因素、搜索与推理交替、不同类型内容走不同路径、模型判关系规则做决策。
系统采用多阶段小模型流水线，将原本数百行的 Prompt 拆分为六个窄任务，降低成本并提升可维护性。
实践表明，系统在知识百科、内容问答等业务中有效降低了核查成本，提升了准确率。

百度内容核查团队的一手实践：把 AIGC 内容拆成最小可验证主张、按权威性排序证据、搜索与推理交替、由规则下结论。
五条核查原则 + 多阶段小模型流水线（数百行 Prompt 拆成六个窄任务，DSPy 优化 + 蒸馏 + 样本回流），已在五类业务降本落地，做事实核查的团队可直接借鉴。

1.1. 主要内容

要点	说明
AI 内容核查的核心难点在于事实错误隐蔽且难以批量覆盖	文章指出，AIGC 内容的错误往往藏在局部、限定条件或多个数字之间的关系里，单看每一句都有出处，人工抽查无法覆盖大量数据，简单规则也无法识别。
构建五条核查原则确保系统方法论的科学性	主张最小化、证据权威化、搜索推理交替、类型分流、模型判关系规则决策五条原则，为后续系统设计和实现提供了清晰指导。
多阶段小模型流水线显著降低核查成本	将原本数百行的 Prompt 拆分为六个窄任务，每个阶段交给小模型或规则处理，既降低了 token 消耗，又便于问题归因和针对性优化。
DSPy 和模型训练技术驱动持续迭代提升	通过 DSPy 自动优化 Prompt、模型蒸馏生成训练数据、强化学习实现自主检索学习，以及样本回流闭环，实现了系统效果的持续改进。
系统通过配置化和多核查器支持不同业务场景	支持快速核查、专业核查、近线核查三种核查器，实现“快速核查 → 专业核查”漏斗和海量数据的近线处理，满足不同准确率、延时和成本需求。

AIGC 内容里的事实错误越来越隐蔽：前几段都对，最后一句张冠李戴；检索结果里对的错的都有，模型挑了不权威的那条。
我们建设了一套内容 AI 核查系统，核心做法是把内容拆成最小的可验证主张，以权威证据为准逐条判断，让模型只判断证据与主张的关系，由规则给出结论。
在此基础上，我们用多阶段小模型流水线把核查成本降下来，覆盖海量批量数据。
系统已在知识百科、内容问答等五类业务落地。

全文 4682 字，预计阅读时间 6 分钟

1.2. 核查难在哪

先看几个线上真实出现过的错误：

△ 五类线上事实错误案例，以及核查每类错误所需的能力

这些错误有个共同点：单看每一句都“有出处”，错误藏在局部、藏在限定条件里、藏在多个数字之间的关系里。
人工抽查覆盖不了这么大的量，简单规则也识别不出来。

业界常见的做法有两类。
一类依赖模型自身知识，比如多次采样看一致性、看输出的不确定性，但模型不知道的事实就验证不了，多次调用成本也高。
另一类结合检索做验证，引入了外部证据，可搜索排在前面的结果是“和问题最相关”的，不一定是“权威且正确”的。
开源框架方面，通用 RAG 框架缺少多轮“搜索 + 推理”的能力，专门的研究项目大多维护不活跃，没有能直接用到生产的方案。

除了效果，还有工程上的约束：成本要撑得住海量且持续增长的数据，效果提升不能只靠换更大的模型，系统还要留出持续迭代的空间。

1.3. 核查思路：五条原则

我们的核查方法可以归结为五条原则。

1.3.1. 主张是最小核查单位

长文本里的错误通常只出现在局部，整段判断容易被前文的正确内容“带过去”。
我们先按文档结构拆段，再把每段拆成原子主张：一条主张只讲一个事实，主体完整，时间、地点补全。
例如“它于 2019 年发布”要补全成“某型号手机于 2019 年发布”。
每条主张独立检索、独立判断。

主张粒度还有一个好处：相同或高度相似的主张可以复用结果，热点事实不用反复核查。

1.3.2. 证据以权威性为第一排序因素

核查的依据是外部证据，模型自身的知识只做辅助。
证据的质量决定了核查的上限，而质量的第一指标是权威性。

数据源按权威程度分成多个等级，从政府官网这类绝对权威的来源，到主流媒体，再到无权威性的来源。
每个垂类维护自己的权威站点表。
检索时先查高权威源，不够再逐级放宽。
来源之间冲突时高权威优先，低权威来源只做风险提示。
同一内容被多个不同域名转载，会被当作互证信号。

1.3.3. 搜索与推理交替

很多事实要多跳才能确认。
“某城市最高楼有多高”，要先确定最高的建筑是哪座，再查它的高度。
我们参考 Search-R1 和 ReAct 的思路，让模型在推理中发现知识缺口时主动检索，拿到结果后继续推理，直到不再需要外部知识。

检索 Query 也不直接用原句。
主张会先被改写成适合检索的 Query，并单独处理时间限定这类容易召回失败的信息。

1.3.4. 不同类型的内容走不同的路

不是所有内容都需要最贵的通用链路。
主张会先按垂类分流：通用事实走多轮搜索，电话号码查权威库，歌词和章节做结构化匹配，链接做有效性校验。
纯观点、主观评价这类没有可核查事实的内容，在入口就被过滤掉。

1.3.5. 模型判关系，规则做决策

早期让模型直接输出“正确 / 错误 / 不确定”，遇到两个问题。
一是同一输入多次运行结果不一致，结果会“闪烁”。
二是不同业务对“正确”的标准不一样：医疗要求权威来源，旅游可以接受多方印证，模型分不清该用哪套标准。

改造后，模型只判断证据和主张之间的关系，在支持、部分支持、矛盾、无关、信息不足五类里选一个。
业务结论交给规则映射：

△ 模型判出的关系叠加证据条件，再映射为业务结果

规则再结合来源等级、证据数量、是否高风险领域，输出正确 / 错误 / 争议 / 无权威来源的业务标签。
这样业务之间的差异变成了配置差异，判定也更稳定。
原来写在 Prompt 里、靠模型“自觉”遵守的要求也变成了代码里的硬规则。

[!warning] 高风险领域的判定兜底
例如灾害伤亡、医疗、法律、金融等高风险领域，模型判“矛盾”但置信度不高时，不直接判错，而是降级为“无法验证”并进入复核队列。

△ 改造前模型直接给结论；改造后模型只判断证据与主张的关系，由规则引擎映射成业务标签

1.4. 系统全貌

△ 一次核查请求经过解析、校验、判定三段，每段上方标出对应的核查原则，底部是效果迭代闭环

一次核查请求依次经过三段，上面五条原则落在各段里：

阶段	做什么
解析	过滤不需要核查的内容，按垂类把文本拆成原子主张，再复核一遍，去掉主体错位、信息丢失的主张。
校验	把主张改写成检索 Query，按权威等级逐级检索，证据按内容去重后按来源等级取最相关的几条。
判定	模型判断证据与主张的关系，规则输出业务标签。

判定结果会进入右侧的迭代闭环：抽样分析、按阶段归因、针对性优化，新版本上线后开始下一轮（见第五节）。

1.4.1. 三种核查器，按场景组合

不同业务对准确率、延时和成本的要求不同，系统提供三种核查器，它们对外接口一致，可以自由组合：

△ 交互式与业务流量走“快速核查 → 专业核查”漏斗，海量批量数据走近线核查

△ 专业核查、快速核查、近线核查的做法与适用场景

线上常见的组合是“漏斗”：先走快速核查，只有出现矛盾标签的内容才升级到专业核查做深度复核。
大部分没有问题的内容在第一层就结束，成本集中花在真正有疑点的数据上。
海量批量数据则交给近线核查。

这三种形态也是系统一路演进过来的。
专业核查准确率高，但多轮交互的 token 随轮数近似平方增长，长尾延时偏高；快速核查链路短，但把所有判断压在一次超大模型推理里，成本撑不起大规模数据。
近线核查就是为了解决规模问题而做的，下一节展开。

1.5. 规模化：从一个大 Prompt 到小模型流水线

1.5.1. 一次推理做六七件事的问题

快速核查的 Prompt 有数百行，写满了权威来源表、证据数量门槛、同名实体处理、时效性降级等规则，等于要求模型在一次推理里同时完成六七件事。
这带来三个问题：

问题	表现
只能用最大的模型	换成小模型，效果断崖式下降。
错了不知道错在哪	主张没拆对、Query 没搜到、证据被截断、判别本身出错，最后都只表现为“结论错了”。
改一处坏一片	调整一条规则要动整个大 Prompt，经常按下葫芦浮起瓢。

1.5.2. 拆成六个窄任务

大模型的能力没法让小模型直接替代，但大模型做的那件“大事”可以拆成若干件小模型能做好的“小事”，其中能确定化的部分再下沉为代码。

△ 一个数百行 Prompt 拆成六个窄任务，每个阶段交给小模型、规则或两者组合

△ 六个窄任务各自做什么，分别交给谁

“模型判关系，规则做决策”在这里发挥了关键作用：判别 Prompt 从数百行缩到十几行，输出只有标签、分数和理由，数 B 参数的小模型也能稳定遵循。
证据也先压缩再判别，每条主张只取最相关的几条证据，既省 token 又降噪声。

1.5.3. 用闲时 GPU 承接主力流量

[!tip] 用闲时 GPU 承接主力流量
核查是典型的“量大、可延迟”任务。AIGC 数据成批到达，存量内容需要全量巡检，一批实验数据就可能有百万量级。
这类任务不需要秒级返回，但需要高吞吐和低单价。
搜索系统有大量推理卡在低峰期是空闲的，只要每个阶段的模型能压到数 B 参数，就能用这些资源承接主要流量。

我们对拆分后的几类任务分别做了模型横评，规律很清晰：任务越窄，能胜任的模型越小。
垂类识别这类分类任务，数 B 参数的模型就能完全识别正确；句子切分用中等尺寸的模型效果最好，Thinking 类模型更慢，效果却没有明显优势；推理判别难度最高，是小模型化的主要攻坚点。

目前小模型已在近线 GPU 上正式部署，承接免审、拆主张、Query 泛化、判别等阶段的主力流量。
在线大模型仍然保留，但换了位置：作为蒸馏小模型的教师、评测时的对照组，以及疑难样本的复核者。

1.5.4. 拆完之后，问题能归因了

拆分还有一个比省成本更重要的收益：每条 bad case 都能定位到具体阶段。
下面是某一轮人工抽样的问题分布：

△ 某一轮人工抽样的问题分布：打分判别约一半、主张提取约三分之一、Query 泛化较少、证据截断个例

在原来的黑盒方案里，这些问题只能笼统地记成“判错了”。
有了归因，后面的优化才能有的放矢。

1.6. 效果迭代：让核查越用越准

核查效果没法一次做到位，靠的是持续迭代。
我们按成本从低到高用三种手段：先做 Prompt 自动优化，到顶后再训练模型，两者所需的数据都来自样本回流闭环。
这套方法对小模型尤其重要，因为小模型的单点能力弱，需要持续把效果追上来。

1.6.1. DSPy：把 Prompt 从“手写”变成“编译”

多个垂类乘以多个阶段，每个组合都要一套 Prompt。
手工调 Prompt 改一处常常影响别处，在大模型上调好的 Prompt 换到小模型上效果也难以预期。

DSPy 换了一种思路：只声明任务的输入输出，给定标注数据和评估指标，由优化器自动搜索指令措辞和示例。
我们在一个“规则藏在数据里”的分类任务上对比了几种优化器（推理模型都是数 B 参数的小模型）：

△ 几种优化器在分类任务上的效果对比

这组实验规模不大，但趋势和业务上的观察一致：

• MIPROv2 容易把训练集里的个别样例写进指令，泛化差；GEPA 通过反思错例总结出能泛化的判定规则。
• 反思模型和推理模型可以分开选。线上推理用小模型控制成本，离线反思用最强的模型挖规则，等于把大模型的能力“编译”进了小模型的 Prompt。

目前 GEPA 已覆盖免审判断、分垂类主张提取、主张复核、Query 泛化四个阶段。
以 Query 泛化为例，难点在时间信息：带上年份经常召回不到，去掉年份又可能召回到别的年份。
这类取舍很难用一条手写规则覆盖，交给 GEPA 从错例中归纳，再由代码兜底，检索不到证据的 Query 比例显著下降。

1.6.2. 模型训练：Prompt 到顶之后

对调用量大、任务边界清晰的阶段，我们训练专用小模型：

方向	做法与作用
垂类分类模型	识别主张属于哪个垂类并分流（见第二节原则 4）。结合主张解析的整体优化，主张识别准确率相比基线大幅提升。
Query 改写模型	提升多跳、隐式事实的召回，训练数据来自业务反馈。
大模型蒸馏	用大模型离线生成各阶段的训练样本，人工修正复合句拆分、同名实体、时间数字细节等高频错误，再加入“不要从证据中扩展主张”这类负例。
强化学习	基于 VERL 复现了 Search-R1 的训练流程，让模型自己学会何时搜、搜什么。

1.6.3. 样本回流：闭环怎么转起来

△ 核查结果经抽样分析和人工复核后按阶段归因，分三路优化，新版本双跑对比后上线，再开始下一轮

这条闭环能转起来，靠的是阶段拆分。
没有归因，样本只能标“对 / 错”，没法分发到具体阶段的训练集。

几轮迭代下来，我们还发现问题分布会转移。
第一轮主张提取是主要矛盾，引入 DSPy、按垂类拆分之后，判别阶段成了新的瓶颈。
每一轮的投入方向都跟着数据走。

1.7. 工程实现

1.7.1. 多轮搜索：让模型持有状态，而不是历史

专业核查的多轮“搜索 + 推理”准确率最高，但每一轮都把之前所有的检索结果重新喂给模型，输入 token 随轮数近似平方增长。
我们做了三处改造：

[!note] 多轮搜索的三处改造

• 模型持有状态，而不是历史全文。模型的输入是“目标 / 已确认事实 / 待解决问题 / 下一步动作”这样的状态，不再是每轮的原始检索结果。
• 能并行的意图一起检索。比如第一轮分析出要验证 A、B、C 三个论点，把三者一起检索，比串行执行时模型反复看到 A、B 的结果要省得多。减少轮数同时降低成本和延时。
• 检索结果进入上下文前先精简。单轮检索结果按句子裁剪，多轮历史做摘要，下一轮只带结论不带原文。

改造后多轮累积 token 从随轮数平方增长降到线性增长；单轮裁剪后 token 明显下降，准确率无损。

1.7.2. 性能治理

△ 性能治理的四类问题、做法与效果

1.7.3. 配置化与多模态

系统从早期按功能拼接的脚本，改造成了可配置的阶段编排：每个业务一份配置，声明用哪些阶段、什么模型和 Prompt，阶段实现在业务之间共享。
新业务接入主要是写配置和 Prompt，不用改主流程代码。

1.8. 业务落地

△ 知识百科、内容问答、数据筛选、内容质量评估、交互式核查平台五类业务的落地效果

1.9. 几点体会

[!important] 几点体会

• 核查的依据是证据，模型自身的知识只做辅助。证据的权威性决定了核查的上限，所以权威分级和检索策略要放在和模型同等重要的位置。
• 以主张为单位核查。长文里的错误大多是局部的，拆到最小主张逐条判断，才不会被正确内容掩盖。
• 模型给特征，规则做决策。一个设计同时解决了结果闪烁和多业务标准不一致两个问题。
• 小模型能不能用，先看任务够不够窄。把能确定化的业务规则从 Prompt 挪进代码，模型只做语义判断，小模型就能胜任。
• 能归因，才能迭代。阶段拆分让每个 bad case 都有明确的去处，Prompt 优化和模型训练才有针对性的数据。