导读
AIGC 内容里的事实错误越来越隐蔽：前几段都对，最后一句张冠李戴；检索结果里对的错的都有，模型挑了不权威的那条。我们建设了一套内容 AI 核查系统，核心做法是把内容拆成最小的可验证主张，以权威证据为准逐条判断，让模型只判断证据与主张的关系，由规则给出结论。在此基础上，我们用多阶段小模型流水线把核查成本降下来，覆盖海量批量数据。系统已在知识百科、内容问答等五类业务落地。
01 核查难在哪
先看几个线上真实出现过的错误：
这些错误有个共同点：单看每一句都”有出处”，错误藏在局部、藏在限定条件里、藏在多个数字之间的关系里。人工抽查覆盖不了这么大的量，简单规则也识别不出来。
业界常见的做法有两类。一类依赖模型自身知识，比如多次采样看一致性、看输出的不确定性，但模型不知道的事实就验证不了，多次调用成本也高。另一类结合检索做验证，引入了外部证据，可搜索排在前面的结果是”和问题最相关”的，不一定是”权威且正确”的。开源框架方面，通用 RAG 框架缺少多轮”搜索 + 推理”的能力，专门的研究项目大多维护不活跃，没有能直接用到生产的方案。
除了效果，还有工程上的约束：成本要撑得住海量且持续增长的数据，效果提升不能只靠换更大的模型，系统还要留出持续迭代的空间。
02 核查思路：五条原则
我们的核查方法可以归结为五条原则。
1. 主张是最小核查单位
长文本里的错误通常只出现在局部，整段判断容易被前文的正确内容”带过去”。我们先按文档结构拆段，再把每段拆成原子主张：一条主张只讲一个事实，主体完整，时间、地点补全。例如”它于 2019 年发布”要补全成”某型号手机于 2019 年发布”。每条主张独立检索、独立判断。
主张粒度还有一个好处：相同或高度相似的主张可以复用结果，热点事实不用反复核查。
2. 证据以权威性为第一排序因素
核查的依据是外部证据，模型自身的知识只做辅助。证据的质量决定了核查的上限，而质量的第一指标是权威性。
数据源按权威程度分成多个等级，从政府官网这类绝对权威的来源，到主流媒体，再到无权威性的来源。每个垂类维护自己的权威站点表。检索时先查高权威源，不够再逐级放宽。来源之间冲突时高权威优先，低权威来源只做风险提示。同一内容被多个不同域名转载，会被当作互证信号。
3. 搜索与推理交替
很多事实要多跳才能确认。”某城市最高楼有多高”，要先确定最高的建筑是哪座，再查它的高度。我们参考 Search-R1 和 ReAct 的思路，让模型在推理中发现知识缺口时主动检索，拿到结果后继续推理，直到不再需要外部知识。
检索 Query 也不直接用原句。主张会先被改写成适合检索的 Query，并单独处理时间限定这类容易召回失败的信息。
4. 不同类型的内容走不同的路
不是所有内容都需要最贵的通用链路。主张会先按垂类分流：通用事实走多轮搜索，电话号码查权威库，歌词和章节做结构化匹配，链接做有效性校验。纯观点、主观评价这类没有可核查事实的内容，在入口就被过滤掉。
5. 模型判关系，规则做决策
早期让模型直接输出”正确 / 错误 / 不确定”，遇到两个问题。一是同一输入多次运行结果不一致，结果会”闪烁”。二是不同业务对”正确”的标准不一样：医疗要求权威来源，旅游可以接受多方印证，模型分不清该用哪套标准。
改造后，模型只判断证据和主张之间的关系，在支持、部分支持、矛盾、无关、信息不足五类里选一个。业务结论交给规则映射：
规则再结合来源等级、证据数量、是否高风险领域，输出正确 / 错误 / 争议 / 无权威来源的业务标签。这样业务之间的差异变成了配置差异，判定也更稳定。原来写在 Prompt 里、靠模型”自觉”遵守的要求也变成了代码里的硬规则。例如灾害伤亡、医疗、法律、金融等高风险领域，模型判”矛盾”但置信度不高时，不直接判错，而是降级为”无法验证”并进入复核队列。
03 系统全貌
△ 一次核查请求经过解析、校验、判定三段，每段上方标出对应的核查原则，底部是效果迭代闭环
一次核查请求依次经过三段，上面五条原则落在各段里：
1. 解析：过滤不需要核查的内容，按垂类把文本拆成原子主张，再复核一遍，去掉主体错位、信息丢失的主张。
2. 校验：把主张改写成检索 Query，按权威等级逐级检索，证据按内容去重后按来源等级取最相关的几条。
3. 判定：模型判断证据与主张的关系，规则输出业务标签。
判定结果会进入右侧的迭代闭环：抽样分析、按阶段归因、针对性优化，新版本上线后开始下一轮（见第五节）。
**三种核查器，按场景组
不同业务对准确率、延时和成本的要求不同，系统提供三种核查器，它们对外接口一致，可以自由组合：
线上常见的组合是”漏斗”：先走快速核查，只有出现矛盾标签的内容才升级到专业核查做深度复核。大部分没有问题的内容在第一层就结束，成本集中花在真正有疑点的数据上。海量批量数据则交给近线核查。
这三种形态也是系统一路演进过来的。专业核查准确率高，但多轮交互的 token 随轮数近似平方增长，长尾延时偏高；快速核查链路短，但把所有判断压在一次超大模型推理里，成本撑不起大规模数据。近线核查就是为了解决规模问题而做的，下一节展开。
04 规模化：从一个大 Prompt 到小模型流水线
一次推理做六七件事的问题
快速核查的 Prompt 有数百行，写满了权威来源表、证据数量门槛、同名实体处理、时效性降级等规则，等于要求模型在一次推理里同时完成六七件事。这带来三个问题：
- 只能用最大的模型。换成小模型，效果断崖式下降。
- 错了不知道错在哪。主张没拆对、Query 没搜到、证据被截断、判别本身出错，最后都只表现为”结论错了”。
- 改一处坏一片。调整一条规则要动整个大 Prompt，经常按下葫芦浮起瓢。
拆成六个窄任务
大模型的能力没法让小模型直接替代，但大模型做的那件”大事”可以拆成若干件小模型能做好的”小事”，其中能确定化的部分再下沉为代码。
“模型判关系，规则做决策”在这里发挥了关键作用：判别 Prompt 从数百行缩到十几行，输出只有标签、分数和理由，数 B 参数的小模型也能稳定遵循。证据也先压缩再判别，每条主张只取最相关的几条证据，既省 token 又降噪声。
用闲时 GPU 承接主力流量
核查是典型的”量大、可延迟”任务。AIGC 数据成批到达，存量内容需要全量巡检，一批实验数据就可能有百万量级。这类任务不需要秒级返回，但需要高吞吐和低单价。搜索系统有大量推理卡在低峰期是空闲的，只要每个阶段的模型能压到数 B 参数，就能用这些资源承接主要流量。
我们对拆分后的几类任务分别做了模型横评，规律很清晰：任务越窄，能胜任的模型越小。垂类识别这类分类任务，数 B 参数的模型就能完全识别正确；句子切分用中等尺寸的模型效果最好，Thinking 类模型更慢，效果却没有明显优势；推理判别难度最高，是小模型化的主要攻坚点。
目前小模型已在近线 GPU 上正式部署，承接免审、拆主张、Query 泛化、判别等阶段的主力流量。在线大模型仍然保留，但换了位置：作为蒸馏小模型的教师、评测时的对照组，以及疑难样本的复核者。
拆完之后，问题能归因了
拆分还有一个比省成本更重要的收益：每条 bad case 都能定位到具体阶段。下面是某一轮人工抽样的问题分布：
在原来的黑盒方案里，这些问题只能笼统地记成”判错了”。有了归因，后面的优化才能有的放矢。
05 效果迭代：让核查越用越准
核查效果没法一次做到位，靠的是持续迭代。我们按成本从低到高用三种手段：先做 Prompt 自动优化，到顶后再训练模型，两者所需的数据都来自样本回流闭环。这套方法对小模型尤其重要，因为小模型的单点能力弱，需要持续把效果追上来。
DSPy：把 Prompt 从”手写”变成”编译”
多个垂类乘以多个阶段，每个组合都要一套 Prompt。手工调 Prompt 改一处常常影响别处，在大模型上调好的 Prompt 换到小模型上效果也难以预期。
DSPy 换了一种思路：只声明任务的输入输出，给定标注数据和评估指标，由优化器自动搜索指令措辞和示例。我们在一个”规则藏在数据里”的分类任务上对比了几种优化器（推理模型都是数 B 参数的小模型）：
这组实验规模不大，但趋势和业务上的观察一致：
- MIPROv2 容易把训练集里的个别样例写进指令，泛化差；GEPA 通过反思错例总结出能泛化的判定规则。
- 反思模型和推理模型可以分开选。线上推理用小模型控制成本，离线反思用最强的模型挖规则，等于把大模型的能力”编译”进了小模型的 Prompt。
目前 GEPA 已覆盖免审判断、分垂类主张提取、主张复核、Query 泛化四个阶段。以 Query 泛化为例，难点在时间信息：带上年份经常召回不到，去掉年份又可能召回到别的年份。这类取舍很难用一条手写规则覆盖，交给 GEPA 从错例中归纳，再由代码兜底，检索不到证据的 Query 比例显著下降。
模型训练：Prompt 到顶之后
对调用量大、任务边界清晰的阶段，我们训练专用小模型：
- 垂类分类模型：识别主张属于哪个垂类并分流（见第二节原则 4）。结合主张解析的整体优化，主张识别准确率相比基线大幅提升。
- Query 改写模型：提升多跳、隐式事实的召回，训练数据来自业务反馈。
- 大模型蒸馏：用大模型离线生成各阶段的训练样本，人工修正复合句拆分、同名实体、时间数字细节等高频错误，再加入”不要从证据中扩展主张”这类负例。
- 强化学习：基于 VERL 复现了 Search-R1 的训练流程，让模型自己学会何时搜、搜什么。
样本回流：闭环怎么转起来
这条闭环能转起来，靠的是阶段拆分。没有归因，样本只能标”对 / 错”，没法分发到具体阶段的训练集。
几轮迭代下来，我们还发现问题分布会转移。第一轮主张提取是主要矛盾，引入 DSPy、按垂类拆分之后，判别阶段成了新的瓶颈。每一轮的投入方向都跟着数据走。
06 HarmonyOS开发简介
多轮搜索：让模型持有状态，而不是历史
专业核查的多轮”搜索 + 推理”准确率最高，但每一轮都把之前所有的检索结果重新喂给模型，输入 token 随轮数近似平方增长。我们做了三处改造：
- 模型持有状态，而不是历史全文。 模型的输入是”目标 / 已确认事实 / 待解决问题 / 下一步动作”这样的状态，不再是每轮的原始检索结果。
- 能并行的意图一起检索。 比如第一轮分析出要验证 A、B、C 三个论点，把三者一起检索，比串行执行时模型反复看到 A、B 的结果要省得多。减少轮数同时降低成本和延时。
- 检索结果进入上下文前先精简。 单轮检索结果按句子裁剪，多轮历史做摘要，下一轮只带结论不带原文。
改造后多轮累积 token 从随轮数平方增长降到线性增长；单轮裁剪后 token 明显下降，准确率无损。
性能治理
配置化与多模态
系统从早期按功能拼接的脚本，改造成了可配置的阶段编排：每个业务一份配置，声明用哪些阶段、什么模型和 Prompt，阶段实现在业务之间共享。新业务接入主要是写配置和 Prompt，不用改主流程代码。
07 业务落地
08 几点体会
- 核查的依据是证据，模型自身的知识只做辅助。 证据的权威性决定了核查的上限，所以权威分级和检索策略要放在和模型同等重要的位置。
- 以主张为单位核查。 长文里的错误大多是局部的，拆到最小主张逐条判断，才不会被正确内容掩盖。
- 模型给特征，规则做决策。 一个设计同时解决了结果闪烁和多业务标准不一致两个问题。
- 小模型能不能用，先看任务够不够窄。 把能确定化的业务规则从 Prompt 挪进代码，模型只做语义判断，小模型就能胜任。
- 能归因，才能迭代。 阶段拆分让每个 bad case 都有明确的去处，Prompt 优化和模型训练才有针对性的数据。
