大模型复杂任务评测体系构建与实践指南

一、为什么需要针对复杂任务做专项评测

通用基准分数能反映模型在标准化题目上的平均水平，却难以回答更具体的问题：模型能否完成工程师和研究人员日常面对的复杂工作。一份医学课件需要结构清晰、术语准确、图文对应。一段科学计算脚本需要参数合理、代码可运行、结果符合物理直觉。这类任务通常包含多步推理、多模态输入输出和外部工具调用，单选题或短问答无法覆盖其难度。

因此，评测应围绕业务中的真实任务展开。厂商公布的宣传指标可以作为参考，但不能替代面向自身场景的测试。评测结果的价值取决于两点：任务是否代表目标场景，评分过程是否能被第三方复核。

二、任务样本的选取原则

好的样本集是评测可信的基础。选取时建议遵循以下五条原则：

1. 代表性：任务来自目标用户的真实工作流，覆盖主要使用场景。
2. 难度分层：包含简单、中等、困难三档。若全部样本都处于模型能力之外或之内，评测无法区分模型之间的差异。
3. 可验证性：每条任务都要有明确的完成标准，便于评分。
4. 独立性：样本不应出现在模型的训练数据中，否则分数会虚高。可以使用内部未公开的任务，并记录样本的创建时间。
5. 规模：每个任务类别建议不少于 30 条样本，以便做统计分析。单条样本的结论容易受随机性影响。

以“医学课件生成”为例，可以拆解为三个子任务：根据指南文本生成大纲，把大纲转化为分页内容，为每一页配备准确的图示说明。每个子任务都能独立打分，也能观察错误在哪一步累积。同理，“科学计算与可视化脚本生成”类任务可以拆分为参数设定、代码实现和结果图表三个环节。

三、设计可量化的评分标准

打分是评测中最容易失真的环节。推荐采用分维度的评分表（rubric），每个维度给出明确的判定条件，并约定分值含义。

以文档生成任务为例，可以设置四个维度：

• 事实准确性：关键数据、术语和结论与参考材料一致，按 0 到 5 分打分。
• 结构完整性：输出是否包含任务要求的全部章节和页面。
• 指令遵循：页数、格式、语言等显式约束是否满足。
• 可用性：内容能否被目标用户直接使用，还是需要大幅修改。

对于包含代码的任务，可以增加“执行通过率”和“结果与预期的偏差”两个客观指标。客观指标优先，主观评分作为补充。

下面的示例展示如何把各维度的分值加权汇总为百分制分数：

from statistics import mean
RUBRIC_WEIGHTS = {
    "accuracy": 0.4,
    "completeness": 0.3,
    "instruction_following": 0.2,
    "usability": 0.1,
}
def weighted_score(scores: dict[str, float]) -> float:
    """每个维度取 0-5 分，返回加权后的 0-100 分。"""
    total = 0.0
    for dim, weight in RUBRIC_WEIGHTS.items():
        value = scores.get(dim)
        if value is None or not 0 <= value <= 5:
            raise ValueError(f"维度 {dim} 缺失或超出范围: {value}")
        total += weight * value
    return round(total / 5 * 100, 2)
def aggregate(task_scores: list[float]) -> dict:
    return {
        "n": len(task_scores),
        "mean": round(mean(task_scores), 2),
        "min": min(task_scores),
        "max": max(task_scores),
    }
if __name__ == "__main__":
    sample = {"accuracy": 4, "completeness": 5,
              "instruction_following": 3, "usability": 4}
    print(weighted_score(sample))  # 输出 82.0

权重应在测试开始前确定，并在整个评测过程中保持不变。评分员需要盲评，即不知道输出来自哪个模型。至少安排两名评分员独立打分，并用 Cohen’s kappa 等一致性指标检验打分标准是否清晰。一致性偏低时，应先修订评分说明，再重新打分。

四、执行流程与可复现性

评测结果只有能被重复获得，才有参考价值。执行时应注意以下几点：

1. 固定推理参数：温度、最大输出长度和系统提示词要统一。所有被测模型使用同一套设置。
2. 记录版本信息：保存模型标识、调用时间和接口版本，便于事后追溯。
3. 多次采样：随机性较强的任务，同一题目应采样多次，报告均值与标准差。
4. 统一工具环境：若允许调用外部工具，需固定工具清单、权限和超时设置。
5. 保存原始输出：保留完整的模型回复，方便复核评分，也方便以后用新的标准重新打分。

五、结果解读与统计

• 报告不确定性：同时给出标准差或置信区间。几分的差距可能只是随机波动，不能直接视为能力差异。
• 检验差异是否显著：对两个模型在同一批样本上的得分做配对检验，例如 Wilcoxon 符号秩检验。
• 分层汇报：按难度档位分别给出结果。总分平均值可能掩盖模型在困难样本上的短板，而这些短板往往是业务中最需要关注的部分。
• 归类失败案例：把错误分为知识错误、推理错误、格式错误和工具调用错误等类型。错误分布比总分更能指导后续改进。

六、常见误区

• 样本泄露：任务若在公开网络上长期存在，模型可能已经接触过，分数会偏高。
• 评分标准随结果调整：应先确定标准，再开始打分。事后修改标准会让结论失去可信度。
• 只看总分：忽略错误类型和难度分布，容易得出片面结论。
• 把单次结果当作稳定能力：同一模型多次运行的结果可能有明显波动。
• 过度外推：在某一类任务上的结论，不能直接推广到其他任务类型。

七、落地建议

建议把评测流程做成可重复运行的流水线，主要环节包括：任务库管理、批量调用、自动检查、人工盲评和报告生成。任务集和评分标准都应纳入版本管理，每次模型或提示词调整后，用固定的回归样本集重新运行，观察关键指标的变化。

此外，评测体系本身也需要定期维护。模型能力提升较快时，旧任务的区分度会逐渐下降，应定期补充新的困难样本，并淘汰已经饱和或已泄露的样本。这样评测结果才能持续反映真实的业务能力。