生成式回答评测怎样设计事实性对照样本

生成式回答的事实性评测，关键不是把问题数量堆大，而是让每条样本都能回答三个问题：回答里有哪些可核验事实、哪些材料可以支持它、判分时怎样区分矛盾与遗漏。本文给出一套适合小规模回归集和人工复核的对照样本结构。

官方资料：https://huggingface.co/docs/evaluate/

Hugging Face Evaluate 提供指标加载、Evaluator 和 EvaluationSuite 等评测入口，但“事实性”本身不能被一个通用指标完整代表。下面的字段和分数是工程上的样本设计方法，不能当成某个模型的实测成绩。

先把事实性问题拆成可核验样本

一条问题最好只围绕一个事实边界展开。例如，不要把“某个框架是什么、什么时候发布、是否适合生产”混成一道题。可以改成“该框架的官方文档把哪项能力定义为默认行为”，这样参考来源和判分对象更清楚。

样本至少保留 question、atomic_claims、reference_answer 和 evidence_boundary。其中 atomic_claims 是可以单独判断真假的最小陈述；reference_answer 不必写成唯一措辞，而要列出必须覆盖的事实；evidence_boundary 则说明哪些官方页面、版本或时间范围可以作为依据。

{
  "question": "Evaluate 文档中的指标是怎样被加载和计算的？",
  "atomic_claims": [
    "指标可以通过 evaluate.load 加载",
    "计算时需要传入与指标匹配的预测和参考数据",
    "指标说明应包含使用限制"
  ],
  "reference_answer": {
    "must_include": ["加载入口", "输入关系", "限制说明"],
    "acceptable_variants": ["调用 load 后再 compute", "先确定指标类型再准备字段"]
  },
  "evidence_boundary": {
    "source": "官方 Evaluate 文档",
    "scope": "API 用法与指标选择，不推断模型事实性分数"
  }
}

严格 JSON 不应插入注释，所以解释放在字段旁边：must_include 约束必答事实，acceptable_variants 允许不同表达，scope 防止评测者把文档用法扩大成模型能力结论。图1是这组字段的静态说明图，不是网页截图。

参考答案要写事实，不要只写一段标准话术

如果参考答案只有一段长文本，评测者很容易把“措辞不同”误判成“事实错误”。更稳的做法是把答案拆成事实原子，并为每个原子记录支持证据、允许的缺省状态和风险级别。

事实原子可以分为三类：必须正确的核心事实、回答更完整时才加分的补充事实、没有证据就不应主动扩展的边界事实。对于会随版本变化的内容，要把版本或观察范围写进样本，不要让旧答案永久充当标准。

对照集还要故意加入容易混淆的负样本：把相邻产品的能力混在一起、把示例配置说成默认配置、把“文档没有说明”说成“官方明确支持”。负样本不是为了刁难模型，而是为了让评测真正区分谨慎回答和流畅编造。

不要用一个总分掩盖事实风险

事实性判分至少拆成支持、矛盾、遗漏和无依据四类。支持表示回答与证据一致；矛盾表示回答直接违背证据；遗漏表示没有覆盖必须回答的事实；无依据表示回答新增了证据边界之外的断言。四类结果不能简单相加后只留下一个总分。

def classify_claim(claim, evidence, required):
    # 这是判分示意：实际系统需要人工或受控评审器确认语义关系。
    if claim in evidence:
        return "supported"
    if claim in evidence.get("contradictions", []):
        return "contradicted"
    if claim in required:
        # 没有出现必须事实时，调用方应把缺口记为 omission，而非猜测答案。
        return "omitted"
    # 证据边界之外的新断言先标记为 unsupported，避免被流畅表达掩盖。
    return "unsupported"

上面的函数只是把结果标签固定下来，不会自动理解自然语言，也没有声称已经运行过模型。实际评测记录还应保留原始回答、抽取后的事实单元、证据引用、评审者和复核状态，方便之后解释一次分数为何变化。

把样本风险和复核记录一起留下

同一组样本用于多次模型回归时，最容易丢的是上下文：问题当时对应哪个版本，参考答案为何这样写，某条回答是模型错误还是证据已经变化。建议为每条记录保存 dataset_version、source_snapshot、claim_labels、review_status 和 review_note。

汇总时先按风险级别看矛盾和无依据，再看整体覆盖率；高风险样本可以设置人工复核门槛，低风险样本再交给自动指标做趋势观察。Evaluate 的指标和 Evaluator 适合承担一致的计算入口，但样本切分、证据边界和人工复核仍是业务方自己的责任。

事实性样本需要多少条才够

没有固定数字。先覆盖核心任务、版本边界和高风险负样本，再按线上错误类型补充；少量但结构清楚的样本，通常比大量重复问法更适合定位变化。

可以只用自动评审器吗

不建议。自动评审器可以提高初筛效率，但对证据冲突、版本变化和边界断言仍应保留人工抽查，尤其是高风险事实。

为什么不直接用准确率

准确率适合标签明确且粒度一致的任务；生成式回答可能同时包含正确、遗漏和无依据陈述。拆成事实原子后，才能知道总分变化究竟来自哪一种风险。

官方资料

Evaluate 文档入口：https://huggingface.co/docs/evaluate/index

指标选择说明：https://huggingface.co/docs/evaluate/choosing_a_metric

Evaluator 说明：https://huggingface.co/docs/evaluate/base_evaluator

EvaluationSuite 说明：https://huggingface.co/docs/evaluate/evaluation_suite