AI evaluation 怎样区分事实性与格式性评分

AI evaluation 中，事实性评分判断回答里的断言是否有可信依据，格式性评分判断输出是否满足约定的结构、字段和类型。两者应分别记录：能被 JSON 解析的答案可能把日期写错，事实正确的文字也可能无法被下游接口接收。不要只用一个平均分掩盖其中一类失败。

可参考 Hugging Face Lighteval 的指标文档：https://huggingface.co/docs/lighteval/metric-list。格式契约可用 JSON Schema 表达，官方入口为 https://json-schema.org/。下面给出一套任务级评分记录方法，不依赖某个评估平台的默认字段，也不把自定义指标称为行业统一标准。

先把输出契约与事实依据分开保存

先准备三份互相独立的材料：输出契约规定怎么交付，参考材料说明根据什么判断内容，原始响应保存模型实际上交付了什么。不要先修复响应再覆盖原文，否则格式失败会在报告中消失。

以一条完全虚构的内部设备目录为例：设备名为“青禾记录器”，发布日期为 2025-04-16，接口为 USB-C。任务要求返回一个对象，字段只能是 name、release_date、connector，三个值都是字符串，日期须符合任务约定的 YYYY-MM-DD 写法。这些信息只是教学材料，不是现实产品参数。

这时就应决定分母：总共评了多少条请求，哪些请求有可用参考材料，哪些输出可以提取断言。材料缺失、空响应和评估器异常不能悄悄从样本集合里消失。

格式评分只回答能否按约定消费

对于这个例子，可以把格式通过写成三个同时满足的条件：完整响应是合法 JSON；顶层对象包含且只包含约定字段；各字段类型和日期写法符合契约。若契约禁止 Markdown 围栏，围栏外的说明文字也属于格式问题，不能由评估器替模型默默删除。

JSON Schema 的 properties 用于声明属性规则，必填字段另用 required 声明；如果不允许其他字段，需要明确 additionalProperties 的约束。仅写出 properties，不意味着所有字段都必填，也不意味着额外字段自动被禁止。

下面的输出结构满足上述字段与类型要求，但发布日期不受参考材料支持：

{
  "name": "青禾记录器",
  "release_date": "2025-04-18",
  "connector": "USB-C"
}

这里不应因为日期错误就判格式失败：2025-04-18 仍然符合约定的日期写法。格式判定解决的是“结构与表示能不能用”，日期是否等于资料中的发布日期是事实问题。若要求真实有效的日历日期，还需在契约中单独明确相应规则，不能把字符串类型检查当作完整日期检查。

格式结果可以记录为 pass 或 fail，同时保留原因，例如“缺少 connector”“connector 类型错误”“出现额外字段”。在字段错误很有诊断价值时，再记录字段级错误；不要把字段通过比例直接冒充整条响应合规率。

事实评分要落到可核对的断言

事实判定先拆出可检查的主张，再逐一对照材料。FActScore 的原始论文采用原子事实与知识来源支持关系来衡量长文本事实精度；这里借鉴的是拆分思路，并未声称复现其完整算法或基准结果。

对于上面的 JSON，可以得到三个主张：设备叫青禾记录器、发布日期是 2025-04-18、接口是 USB-C。按虚构参考材料，名称和接口受支持，日期与材料矛盾。教学示例的受支持主张占比为 2/3；这是手工推演，不是模型评测实测值。

建议在本任务中保存三种状态：supported 表示材料足以支持，contradicted 表示材料有明确相反依据，insufficient 表示材料不足以判断。第三类不等于现实世界一定为假。若指标定义为“参考材料支持率”，insufficient 不计入受支持分子，但仍需单独报告数量。

另外，回答只给设备名称也可能得到很高的主张支持比例，因为它没有输出其他可错的主张。这不代表任务完成得好。还应对任务要求的三项信息记录覆盖情况；没有输出断言时，不要把零分母记为满分，可记为不可评分并单列空回答。

选择评分工具时，封闭字段任务可使用明确的标准答案或允许值集合；开放式解释需要证据段落和清晰的评审准则。Lighteval 列出的 exact_match 衡量预测与 gold 的匹配，不能不加说明地把字符串相等率当作所有任务的事实性指标。同义表达、日期规范化和允许别名，都应在比较之前固定规则，而不是看到结果后再改口径。

把两类结果汇总成可解释的报告

一条记录至少保留格式状态、事实状态、覆盖情况和错误原因。对同一批样本，可把两个维度交叉展示：

事实暂时不可评分的样本要另列，不能强塞进这四格。例如非法 JSON 无法由结构化提取器读取时，可以记录“格式失败、事实不可评分”；若允许人工直接阅读原文判断事实，应在评估设计阶段就规定这条备用路径，并始终保留格式失败。

最基本的汇总可以这样定义：格式合规率等于格式通过请求数除以全部请求数；可评分覆盖率等于有事实判定的请求数除以全部请求数；端到端通过率等于格式通过且事实、任务覆盖均达标的请求数除以全部请求数。事实不可评分项不属于端到端通过分子，但也不要擅自把它们称为事实错误。

如果只在格式通过子集中统计事实成绩，也可以作为诊断指标，但必须明确命名为“格式通过子集的事实成绩”，同时报告子集大小。否则一个经常输出坏格式的模型可能因为大量困难样本被排除，看起来反而更好。

用失败样本决定下一步改哪里

完整工作流可以保持简短：固定任务与材料版本，冻结输出契约，保存原始响应，分别记录格式和事实判断，再按同一个样本 ID 汇总。修改提示词或模型后，沿用同一批样本和评分定义，才能解释差异来自哪里。

格式失败集中在额外说明文字时，优先处理输出约束；事实失败集中在错误日期时，优先查证据、字段映射和回答依据。若同时修改生成规则、标准答案和评分器，就无法分清改善来自模型还是评分口径变化。自动评审模型给出的判断也不是事实本身，涉及歧义的样本应保留证据与争议状态。

JSON 合法是否等于格式评分通过？

不一定。合法 JSON 仍可能缺字段、类型不符、顶层结构错误或包含不允许的额外字段。具体以事先固定的契约为准。

事实正确但格式失败，要不要把事实分清零？

不必把两个维度混成一个。可以保留事实判定，同时将端到端结果记为不通过；若无法可靠读取事实，应记不可评分并报告覆盖率。

参考材料没有提到某个主张，就一定是幻觉吗？

不能直接这样下结论。它说明该主张在当前材料范围内缺少支持，是否违反任务要求还取决于是否允许使用外部知识。报告应写清事实判断的证据范围。

参考资料：JSON Schema 对象约束、Lighteval 指标列表、FActScore 原始论文。本文的三态标签与汇总口径是用于解释的任务设计建议，不是上述工具默认行为的声明。