LifeVal 类日常任务基准怎么设计：任务选择、完成判定与评分口径

LifeVal 是 OpenAI 发布的一个基准，公开摘要的表述是：它衡量 AI 帮助人们完成日常任务的效果，例子包括寻找托儿、管理财务和处理政府文书（openai.com/index/lifeval，来源日期 2026-11-02）。摘要没有给出任务数量、完成判定方式或评分公式，因此本文不还原 LifeVal 的具体实现，而是讨论设计这类“日常任务基准”时必须先定的三件事。涉及 LifeVal 实现细节的部分，均待核实。

任务选择：先回答“谁的日常、交付出什么”#

摘要举的三类任务有共同点：信息分散在多个来源、需要跨步骤操作、结果对当事人有实际后果。这决定了它们适合测“帮忙把事情做完”，而不只是“回答一个问题”。选任务时建议用三个条件收紧范围：

• 委托真实：确实有人会把这件事交给助手，而不是研究者虚构的操作。
• 产物可交付：最终能落到表单、清单、邮件草稿或一个明确决定上，否则无法判定。
• 失败可承受：不涉及人身安全、不可逆的财务损失；需要账号权限或真实支付的环节用模拟环境替代，并在文档里写明替代了什么。

覆盖面和深度往往冲突。宁可把少量任务从提问到交付走完整条链路，也不要用大量单步问答撑样本量——后者测到的是知识，不是完成度。同时应显式列出排除项，否则读者无法判断基准的适用边界。

完成判定：结果断言优先，人工量表兜底#

判定方式决定基准能不能被复现。一个可操作的顺序是：

1. 能自动核验的写断言：表单字段是否填对、金额是否与给定材料一致、日期是否落在要求窗口内。断言要写在任务定义旁，而不是藏在评分脚本里。
2. 不能完全自动核验的用量表：公开评分维度、评分者身份、是否盲评、分歧如何裁决。只写“由专家评分”不足以支撑复现。
3. 记录失败类型：信息缺失、步骤顺序错误、越权操作、给出看似合理但错误的结论。只留一个通过/不通过，会丢掉最有诊断价值的信息。

还有一处容易含糊：部分完成不等于帮到人。结构完整但关键数字错误的答案，不应与正确但表述笨拙的答案同分；反过来，把“模型礼貌地拒绝”计为通过，会系统性抬高分数。

评分口径：先统一分母，再谈加权#

跨模型比较的前提是同一任务集、同一评分者、同一失败定义。报告里应带样本量和不确定性区间；任务数少时，几个百分点的差距可能只是噪声。

一个判分记录的演示结构（示例，未执行）

下面只是说明“判定结果应留下哪些字段”，不是 LifeVal 的实际格式，也未运行：

{
  "task_id": "demo-gov-form-001",
  "checks": [{"name": "field_match", "passed": true}],
  "failure_type": null,
  "human_score": null,
  "notes": "占位示例"
}

边界#

以上是设计同类基准时的一般方法，属于建议与推断，不代表 LifeVal 采用了其中任何一种做法。LifeVal 的任务规模、判定是否自动化、评分者构成、任务与评分脚本是否公开，本次材料均未提供，待核实。若要在自己的项目里落地，建议先把任务定义、断言和失败分类写成可评审的文档，再谈分数怎么加总。