假设你要为一位极其挑剔的美食评论家筹备一场“综合能力测试宴”。这场宴席绝不能只端上一道菜：他可能爱吃川菜的麻辣，也欣赏粤菜的清鲜；你得准备前菜、主菜、甜品，还得悄悄安排几道“陷阱菜”——比如一道烧焦的牛排，看他能否敏锐地指出火候问题。这套心思，正是 LLM 评估数据集构建的本质：为模型设计一场周密的能力考卷。考卷怎么出？先设计题型与难度（任务设计），再分渠道采购食材（数据来源），制定统一菜谱规范后厨（标注规范），请品控组逐批试菜把关（质量控制），检查菜式是否覆盖八方食客（覆盖度分析），最后给每版菜单编号留档（版本管理）。沿着这套流程，你就能构建出一份公正、全面、可复现的模型“考卷”。

岗位关联

掌握评估数据集的构建方法，是 AI 从业者建立“可信任模型度量衡”的核心能力——没有高质量的考卷，再强的模型也只是自说自话。

目录
  1. 可视化演示
  2. 任务设计规划
  3. 数据来源构建
  4. 标注规范制定
  5. 质量控制流程
  6. 覆盖度分析
  7. 版本管理策略
  8. 构建流程规范
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示LLM评估数据集构建方法的核心机制，通过源头/管道/节点/终端四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

LLM评估数据集构建方法：评估数据 评估数据集的任务类型与难度梯度 三种数据来源混合构建策略 核心机制可视化 LLM评估数据集构建方法整体架构与关键组件

任务设计规划

筹备“能力测试宴”的第一步，是定菜单。有经验的餐厅绝不会只靠一道招牌菜打天下，而是按“凉菜—热菜—汤—甜品”的节奏铺开，再配上微辣、中辣、特辣三档。评测数据集的设计同理：首先要确定考哪些任务类型——摘要、数学、代码、推理、开放问答各占几道；其次要给每道题定难度档位；最后还要埋几道“陷阱菜”，比如有歧义的问法、误导性前提、超出训练分布的刁钻问题，这些在行话里叫作边缘案例（edge cases）。

如果菜单只追求“菜多”，不讲究荤素搭配和辣度分层，评论家吃完只会觉得味觉迟钝、根本区分不出厨师水平。评测集也是一样：如果只放简单的常识问答，那么 7B 模型和 70B 模型都会轻松拿满分，考卷彻底失效。一份合格的考卷，必须让菜鸟、熟手和大师都各有发挥空间。

任务设计通常从四个维度展开。多任务覆盖要求考卷横跨多种能力域，防止模型只擅长某一类题；难度梯度保证不同水平的模型都能被拉开差距；边缘案例专门对付模型在常见数据分布上的过拟合；评估维度则回答“拿什么分数”的问题——准确率、流畅性、安全性还是有帮助性。实际操作中，团队会先用一个小规模试测来量化每道题的难度系数：

定好菜单格式后，后厨才能有的放矢——下一步是准备食材，也就是数据来源。

Dj=1−RjNj\displaystyle D_j = 1 - \frac{R_j}{N_j}
$R_j$ 是试测中答对第 $j$ 题的人数，$N_j$ 是试测总人数。$D_j$ 越接近 1，说明越少人答对、题目越难；越接近 0，说明题目太简单。
  1. 统计作答总量$N_j$ 表示第 $j$ 题累计参与试测的样本总数，它是难度计算的基数。
    NjN_j
  2. 统计答对人数$R_j$ 表示这 $N_j$ 个样本中模型回答正确、与参考答案一致的个数。
    RjR_j
  3. 换算难度系数用 $1$ 减去通过率 $\dfrac{R_j}{N_j}$，就得到介于 0 到 1 之间的难度值。
    Dj=1−RjNjD_j = 1 - \frac{R_j}{N_j}

数据来源构建

菜单定了，接下来是采购。主厨为招牌菜亲自去农场挑有机蔬菜，成本高但品质稳定；大批量食材找供应商统一配送，出菜快却偶尔有残次品；此外，后厨还会留心客人吃剩的菜，研究真实胃口。评测数据集的三个来源恰好对应这三种采购方式：人工标注、模型生成、真实用户日志采样。

人工标注由受过训练的人类标注员逐条编写和判定，质量最高、成本也最高，适合产出权威答案（ground truth），比如数学题的最终结果、法律条文的对错判断。模型生成指用能力更强的模型批量产出题目和答案，速度快、覆盖面广，但会有幻觉和重复，必须再经过过滤和人工抽检。真实用户日志记录了用户在实际产品中的提问和反馈，最贴近生产环境，但存在噪声、隐私和分布偏移问题，需要清洗与脱敏。

聪明的做法不是只依赖一种渠道，而是像配菜一样按权重混合。例如核心能力题用 60% 人工标注保证权威性，拓展题用 30% 模型生成摊薄成本，再用 10% 用户日志贴近真实需求：

食材齐了，但十个厨师烧同一道菜可能烧出十个味——得先把菜谱写明白，也就是标注规范。

S=αS人工+βS生成+γS日志,α+β+γ=1\displaystyle S = \alpha S_{\text{人工}} + \beta S_{\text{生成}} + \gamma S_{\text{日志}}, \quad \alpha + \beta + \gamma = 1
三种来源的样本集合按比例 $\alpha,\beta,\gamma$ 混合，三者之和恒为 1，保证总样本规模可控、来源比例透明。
  1. 定义人工分量$S_{\text{人工}}$ 代表从人工标注题库中抽取的样本集合，是质量基石。
    S人工S_{\text{人工}}
  2. 定义生成与日志分量$S_{\text{生成}}$ 与 $S_{\text{日志}}$ 分别对应模型生成样本和用户日志样本。
    S生成+S日志S_{\text{生成}} + S_{\text{日志}}
  3. 权重归一约束$\alpha + \beta + \gamma = 1$ 保证比例不溢出，实际配比应写入数据集文档。
    α+β+γ=1\alpha + \beta + \gamma = 1

标注规范制定

有了食材，后厨仍可能乱套：有人放三勺盐，有人放半勺。餐厅会编一本标准菜谱，让每个学徒照着做，再安排试吃校准，遇到口味分歧就请主厨仲裁。对应到评估数据集，就是标注规范制定：标注指南、标注者培训、标注工具与争议仲裁。

标注指南（annotation guideline）把每类任务的判定标准写成可执行条款，例如“答案包含正确结论但推理过程有误”到底算不算对，“模型拒绝回答”算不算安全。标注者培训让新人先标注一批“练兵题”，通过复盘差异来对齐认知。标注工具负责批量分发与回收样本，减少人工搬运造成的错误。争议仲裁规定分歧样本由资深标注员或规则委员会最终定夺，避免悬而未决。

如何量化“后厨是否统一”？业内最常用的指标是 Cohen's Kappa 系数。它不像简单一致率那样只数“两人相同的比例”，而是扣掉了两人纯靠瞎猜也能碰上的部分：

菜谱统一后，每批菜出锅还得过品控组这一关。

κ=Po−Pe1−Pe\displaystyle \kappa = \frac{P_o - P_e}{1 - P_e}
$P_o$ 是两名标注者的观测一致率，$P_e$ 是随机情况下也会一致的期望概率。$\kappa$ 越接近 1 说明一致性越高，通常要求不低于 0.6 才视为合格。
  1. 计算观测一致率$P_o$ 是两名标注者在同一批样本上给出完全一致标签的比例，直接统计即可。
    Po=一致的样本数总样本数P_o = \frac{\text{一致的样本数}}{\text{总样本数}}
  2. 计算偶然一致率$P_e$ 由各类别的先验概率相乘后求和得到，代表“蒙也能蒙对”的比例。
    Pe=∑kpk2P_e = \sum_{k} p_k^2
  3. 归一化得到 Kappa分子是超出偶然的真实一致性，分母是理论上还能提升的空间。
    κ=Po−Pe1−Pe\kappa = \frac{P_o - P_e}{1 - P_e}

质量控制流程

后厨每出一批菜，品控小组长会随机抽几盘试菜，记下口味偏差；再换一位品控交叉品尝复核；评分不达标的整批打回重做。这四个动作，正是评估数据集质量控制的标准动作：抽样检查、交叉复核、缺陷修复与一致性度量。

抽样检查是第一道闸门：几万条样本不可能逐条人工复核，按比例随机抽取即可，抽中率一般与批次规模挂钩。交叉复核要求至少两名标注者独立标注同一批样本，用差异来暴露规则漏洞——如果两人对“这段话算不算广告”分歧极大，说明指南写得不够清楚。缺陷修复把问题样本回炉，更新指南并重新标注，形成闭环。整个过程围绕一致性的量化结果运转，上节的 Kappa 就是核心仪表盘。

逐批验收时，团队会用抽样合格率做通行证。只有合格率达标，这批样本才允许进入评测集：

品控通过，菜式摆上桌前还要再看看：整桌菜到底覆盖了多少种口味？

p^=n合格n\displaystyle \hat{p} = \frac{n_{\text{合格}}}{n}
$n$ 是从批次中随机抽取的质检样本数，$n_{\text{合格}}$ 是其中通过评审标准的数量。$\hat{p}$ 若低于阈值（如 0.95），整批退回重新标注。
  1. 确定抽样规模$n$ 是根据批次总量与置信度确定的随机抽样个数，太少不具代表性。
    nn
  2. 统计合格数量$n_{\text{合格}}$ 是这些样本中通过评审标准、无标注缺陷的数量。
    n合格n_{\text{合格}}
  3. 计算合格率$\hat{p}$ 是批次的整体质量估计，低于验收阈值时整批返工。
    p^=n合格n\hat{p} = \frac{n_{\text{合格}}}{n}

覆盖度分析

假设餐厅面向全国游客：有人无辣不欢，有人只吃清淡；同一道红烧肉上了十次虽然凑数，却会让食客反感。评测集也一样：要检查任务覆盖是否齐全、难度分布是否均衡、领域是否多样、重复样本是否太多。

任务覆盖评估考卷是否包含目标能力清单里的每一项，比如分类、抽取、推理、代码生成；难度分布检查题目是否过度集中在某一档——全是简单题会让指标虚高，全是难题则无法反映真实应用水平；领域均衡关注业务比重，例如金融问答占比太低，评测结果就对金融场景失去参考价值；冗余去重用文本指纹或 embedding 相似度把近乎相同的题目合并，防止某类题“刷屏”导致指标失真。

覆盖度的量化非常直观，就是把“任务类型 × 难度 × 领域”画成一张三维网格，然后数数考卷点亮了多少格子：

检查完毕，菜单要印成活页、编好版本号，才不会三个月后说不清当时上的是哪版菜。

C=∣T已覆盖∣∣T目标∣\displaystyle C = \frac{|T_{\text{已覆盖}}|}{|T_{\text{目标}}|}
$T_{\text{目标}}$ 是目标网格的全部格子数，$T_{\text{已覆盖}}$ 是评测集中至少有一条样本落入的格子数。$C$ 越接近 1，考卷越全面。
  1. 枚举目标矩阵$T_{\text{目标}}$ 由任务类型、难度档位与业务领域三轴叉乘得到。
    T目标={任务}×{难度}×{领域}T_{\text{目标}} = \{\text{任务}\} \times \{\text{难度}\} \times \{\text{领域}\}
  2. 统计实际命中$T_{\text{已覆盖}}$ 是评测集样本实际命中（至少一条）的格子集合。
    T已覆盖⊆T目标T_{\text{已覆盖}} \subseteq T_{\text{目标}}
  3. 求覆盖度比率$C$ 越接近 1 代表死角越少，空白格子就是要补的漏考知识点。
    C=∣T已覆盖∣∣T目标∣C = \frac{|T_{\text{已覆盖}}|}{|T_{\text{目标}}|}

版本管理策略

常去的老顾客都懂：餐厅换季改菜单后，上次那道惊艳的菜可能已经下架。有经验的餐厅会给菜单编号：v1.0 是第一版，加新菜变成 v1.1，菜系彻底翻新则升到 v2.0。顾客只要报出版本号，服务员就能完整复现当时的体验。评估集同理，必须有严格的版本管理。

语义化版本采用“主版本。次版本。补丁”三段式：主版本升级代表评测口径发生不兼容变化，例如从“只看最终答案”改为“逐步推理都要正确”；次版本升级代表新增题型、扩充样本而不破坏旧题语义；补丁升级只修正错别字、损坏样本等小问题。变更日志（CHANGELOG）逐条记录每版改了什么、为什么改，让团队能追溯指标跳变的根因。评估集演进管理控制样本淘汰与新增的节奏，防止模型在公开评测集上“背题”产生数据污染。回滚机制保证新版本发布后若出现异常，能一键退回上一版，不影响正在进行的实验。

语义化版本可以写成统一形式：

版本号印好，整个后厨的流程还要写进 SOP，才能让好手艺可复制。

V=M.m.p(M≥0, m≥0, p≥0)\displaystyle V = M.m.p \quad (M \ge 0,\ m \ge 0,\ p \ge 0)
版本号由主版本 $M$、次版本 $m$、补丁 $p$ 三段整数组成。升哪一位，取决于这次改动是否破坏旧的评测口径。
  1. 主版本号 M评价标准、任务定义发生不兼容变化时 $M$ 加 1，同时 $m$ 与 $p$ 清零。
    M→M+1M \rightarrow M + 1
  2. 次版本号 m新增题型或扩充样本、但不改变旧题判定语义时 $m$ 加 1。
    m→m+1m \rightarrow m + 1
  3. 补丁号 p修正错别字、修复损坏文本等不影响测试口径的小改动时 $p$ 加 1。
    p→p+1p \rightarrow p + 1

构建流程规范

一家米其林餐厅最值钱的，除了菜，还有流程：定期复盘客群需求、按小步快跑迭代出新菜、每道菜出厂前过三重验收、所有配方和心得记录成档。新人来了照章办事，餐厅才能稳定出品。数据集的构建也一样，需要一套可重复的工程规范。

需求分析阶段明确评测对象、目标能力与资源预算，形成一份任务矩阵，避免做到一半才返工改方向。迭代开发按照“设计→标注→质检→分析→修订”的小周期滚动推进，每轮只交付一小批样本，及时暴露问题，而不是憋一个大版本再一次性验收。验收标准把覆盖度、Kappa、抽样合格率等指标写进准入条件，全部达标才允许发布。文档记录则覆盖标注指南、变更日志、样本统计与已知局限，让后人能站在前人的肩膀上继续迭代。

综合验收时，不同指标的重要性并不相同——安全类的权重通常高于趣味题，因此常用加权评分作为最终的发布闸门：

至此，“能力测试宴”从定菜单、采购、出菜、品控到版本留档，形成了一条完整流水线。再回头看那句话：一份好考卷，胜过十场空谈——评估数据集，就是 LLM 世界里最公正的那杆秤。

Q=∑k=1nwkqk∑k=1nwk\displaystyle Q = \frac{\sum_{k=1}^{n} w_k q_k}{\sum_{k=1}^{n} w_k}
$q_k$ 是第 $k$ 项验收指标（覆盖度、一致性、规模等）的得分，$w_k$ 是其权重。加权平均 $Q$ 达到阈值才能发布。
  1. 定义验收维度$q_k$ 是第 $k$ 项指标的实际得分，例如覆盖度 0.92、Kappa 0.78。
    qk∈[0,1]q_k \in [0, 1]
  2. 设置权重$w_k$ 反映指标的重要性，安全与核心能力项的权重高于边缘性指标。
    wk>0w_k > 0
  3. 加权平均判定$Q$ 达到预发布阈值（如 0.85）时数据集才允许正式发布。
    Q=∑k=1nwkqk∑k=1nwkQ = \frac{\sum_{k=1}^{n} w_k q_k}{\sum_{k=1}^{n} w_k}

AI 应用场景

大模型发布前的“体检中心”

阶段：模型评估与回归测试

解决的问题：传统做法靠工程师拍脑袋挑几十道题临时测试，转正后无人维护，模型升级后能力回退也发现不了。用混合来源构建的评估数据集，把“体检”固化下来，每次 release 前自动跑一遍。

具体案例：某大模型团队按“推理 40%、代码 30%、安全 20%、对话 10%”配比构建评测集，人工标注核心题、模型生成扩展题，并纳入历史线上故障案例（用户日志）。每次发版跑全量评测，某次新模型虽然在常规题上分数更高，却在安全边缘案例上大跌，团队据此在上线前成功拦截了风险。

RAG 智能客服的“考卷定制”

阶段：应用效果评估与优化

解决的问题：RAG 客服系统上线后，传统方式只看人工抽检满意率，难以量化“检索是否准确、答案是否有依据”。用真实用户日志采样 + 人工标注的方式构建垂直领域评估集，可以持续监控答案准确率与引用正确率。

具体案例：某金融客服团队从近三个月用户日志中采样 5000 条真实提问，人工标注标准答案与判定规则，再叠加大模型生成的 2000 条多轮追问边缘案例。评估结果显示模型在“利率计算”类问题上引用错误率高达 18%，团队据此优化了检索重排序策略。

内容安全合规筛选

阶段：安全评测与合规审计

解决的问题：暴力、歧视、诱导等违规内容在普通评测样本中占比极低，传统随机采样很难覆盖，合规审查形同虚设。以边缘案例和安全性为优先维度构建评测集，才能有效守住红线。

具体案例：某内容平台构建“安全红线评测集”，将对抗性变体（谐音、emoji 替代、多轮诱导）作为核心题型，质量门要求安全维度 Kappa 不低于 0.85、覆盖度不低于 0.95。每轮模型迭代后发布新版本，通过变更日志追踪安全指标变化，确保新模型不突破合规底线。

Python 演示

python75 行
from collections import Counter  class EvalDatasetBuilder:    """评估数据集构建器: 混合采样, 难度分级, 一致性检查, 覆盖度报告"""     def __init__(self, task_pool):        self.pool = task_pool          # 候选任务池        self.item_map = {}             # 已入选题目字典        self.queue = []                # 待处理队列        self.version = (1, 0, 0)       # 语义化版本 vM.m.p     def sample_from_sources(self, quota_map):        # 按配额从三种来源抽样, quota_map: {来源: 数量}        for src, num in quota_map.items():            picked = [t for t in self.pool if t["source"] == src][:num]            self.queue.extend(picked)        return len(self.queue)     def assign_difficulty(self, pass_rate):        # 按通过率分档: >=0.7 easy, >=0.4 mid, 否则 hard        if pass_rate >= 0.7:            return "easy"        if pass_rate >= 0.4:            return "mid"        return "hard"     def check_consistency(self, ann_a, ann_b):        # 两名标注者一致率与 Cohen's Kappa 的简化计算        n = len(ann_a)        if n == 0:            return 1.0, 1.0        agree = sum(1 for x, y in zip(ann_a, ann_b) if x == y) / n        pe = 0.5  # 二分类随机一致的简化期望        kappa = (agree - pe) / (1 - pe)        return agree, kappa     def coverage_report(self, domain_list):        # 统计各领域覆盖情况, 返回覆盖度与缺失清单        covered = Counter(t["domain"] for t in self.item_map.values())        missing = [d for d in domain_list if covered[d] == 0]        rate = (len(domain_list) - len(missing)) / len(domain_list)        return {"coverage": rate, "missing": missing}     def bump_version(self, major=False, minor=False):        # 语义化版本推进: 大版本/次版本/补丁        a, b, c = self.version        if major:            self.version = (a + 1, 0, 0)        elif minor:            self.version = (a, b + 1, 0)        else:            self.version = (a, b, c + 1)        return self.version  def main():    pool = [        {"id": "q01", "source": "人工标注", "domain": "推理", "pass": 0.8},        {"id": "q02", "source": "模型生成", "domain": "代码", "pass": 0.5},        {"id": "q03", "source": "用户日志", "domain": "问答", "pass": 0.3},        {"id": "q04", "source": "人工标注", "domain": "安全", "pass": 0.9}    ]    builder = EvalDatasetBuilder(pool)    builder.item_map = {t["id"]: t for t in pool}    builder.sample_from_sources({"人工标注": 2, "模型生成": 1, "用户日志": 1})    print("队列规模:", len(builder.queue))    print("难度分档:", builder.assign_difficulty(0.45))    print("一致率与Kappa:", builder.check_consistency([1, 0, 1], [1, 1, 1]))    print("覆盖度报告:", builder.coverage_report(["推理", "代码", "问答", "安全", "数学"]))    print("版本推进:", builder.bump_version(minor=True))  if __name__ == "__main__":    main()
目的：用一个可运行的「评估数据集构建器」演示混合采样、难度分档、标注一致性、覆盖度统计与版本推进的完整流程。
  1. builder.sample_from_sources({"人工标注": 2, "模型生成": 1, "用户日志": 1})按配额从三种来源采集样本，模拟混合配比。
  2. picked = [t for t in self.pool if t["source"] == src][:num]从候选池中筛选指定来源的题目并截取配额数量。
  3. kappa = (agree - pe) / (1 - pe)扣除偶然一致后的真实一致性，是质量门的核心仪表盘。
  4. covered = Counter(t["domain"] for t in self.item_map.values())按领域统计样本分布，为覆盖度分析提供数据。
  5. rate = (len(domain_list) - len(missing)) / len(domain_list)计算覆盖度，missing 清单直接指出漏考领域。
  6. self.version = (a + 1, 0, 0)主版本升级时清零次版本与补丁，符合语义化版本规则。
  7. if __name__ == "__main__":保证模块可被导入复用，也能直接运行演示。

常见误区

误区评估集当然是越多越好，我见过有人直接堆了十万条题，模型照样刷高分，那肯定是题不够多。

正解评估集的质量取决于多样性、难度梯度与标注一致性，而不是单纯的数量。十万条相似题就像宴席上上了十盘红烧肉，只会撑坏食客却测不出真实水平。冗余样本不仅浪费算力，还会稀释困难样本的比重，让分数虚高。正确的做法是先做覆盖度分析，确保每个“任务×难度×领域”格子都有样本，而不是盲目扩量。

为何常见：因为大家习惯了“大数据集=好模型”的训练思维，误以为评测集也遵循同样的规模崇拜，忽略了考卷设计本身就决定了区分度。

误区用户日志是真实用户问的，比人工编的题接地气多了，拿去评测肯定最准。

正解真实日志的确贴近生产环境，但它是“未加工的食材”：包含大量噪声、重复提问、隐私信息，且分布受产品功能影响严重偏移——如果产品没有数学功能，日志里就几乎不会有数学题。必须经过清洗、脱敏、人工标注参考答案，并按混合配比补齐缺失能力域，才能作为评测样本。

为何常见：因为“真实”听起来比“人工”更客观，人们容易忽略真实数据同样存在偏差，需要同等的加工工序。

误区两个标注员 80% 的标签都一致，质量肯定没问题，不用再看其他指标了。

正解80% 的一致率可能只是“假达标”。如果题目本身很简单，两人靠常识蒙也能蒙对一半以上，光看一致率会高估质量。Cohen's Kappa 扣除了偶然一致的部分，才是真正反映标注者共识的指标。例如一致率 0.8、偶然一致概率 0.5 时，Kappa 只有 0.6，只是“中等一致”的及格线。

为何常见：因为“一致率”直观好算，而 Kappa 涉及概率计算，大家本能地回避复杂的指标，却忘了简单指标容易被偶然性欺骗。

误区数据集又不大，自己本地存一份就行了，搞版本号纯属形式主义。

正解没有版本管理的评测集是“没有编号的菜单”。几个月后新模型分数涨了，你根本说不清是因为模型变强了，还是因为偷偷改了题。语义化版本配合变更日志，才能让评测可复现、指标可追溯；遇到新版数据集出现异常时，回滚机制能保住正在进行的实验。评估集的生命周期管理，直接决定评测结果的可信度。

为何常见：因为初学者往往只在单次实验中用数据集，体会不到长期迭代中“指标漂移找不到原因”的切肤之痛。

面试题

Q1. 评估数据集构建时，为什么需要同时包含困难样本与简单样本？

单选题 · easy

  • A.让模型表现显得更强
  • B.覆盖能力梯度区分水平← 正确答案
  • C.减少人工标注工作量
  • D.加快训练收敛速度

答案：B。简单题负责验证基础能力，难题负责拉开顶尖模型的差距，就像宴席要有微辣和特辣，才能区分不同耐辣程度的食客。选项 A 是作弊心态，C 与难度设计无关，D 是训练环节的事，与评测集无关。

Q2. 下列哪种评估样本来源成本最低但噪声最大？

单选题 · easy

  • A.人工标注制作
  • B.模型自动生成
  • C.真实用户日志← 正确答案
  • D.专家人工撰写

答案：C。真实用户日志从线上直接采集，几乎零生产成本，但包含噪声、重复与隐私问题，像客人剩菜一样“真实但乱”。人工标注和专家撰写成本高、质量高，模型生成成本低但需过滤，三条路里日志的噪声最突出。

Q3. 任务设计时，“边缘案例”主要用来测试模型的什么能力？

单选题 · easy

  • A.生成速度稳定性
  • B.模型参数量规模
  • C.对抗过拟合能力← 正确答案
  • D.数据清洗完整性

答案：C。边缘案例是“陷阱菜”，专门用有歧义、误导性或分布外的刁钻问题，测试模型在常见数据分布之外是否还能正确应对，本质是检验模型是否过度拟合常见模式。其余选项都与任务设计中的边缘案例无关。

Q4. Cohen's Kappa 系数主要用于衡量评估数据集构建中的哪个环节？

单选题 · mid

  • A.衡量模型生成速度
  • B.衡量标注一致性程度← 正确答案
  • C.衡量数据集规模大小
  • D.衡量模型参数量多少

答案：B。Kappa 是质量控制环节的核心仪表盘，它扣除了偶然一致后评估标注者之间的一致性，就像品控组两次试菜口味是否统一。它不关心模型的速度、参数或数据总量，只盯着标注质量的稳定性。

Q5. 语义化版本 v2.1.3 中，"1"表示什么含义？

单选题 · mid

  • A.主版本号升级
  • B.次版本号即新增内容← 正确答案
  • C.补丁号修复小问题
  • D.构建号用于持续集成

答案：B。v2.1.3 三段分别是主版本 2、次版本 1、补丁 3。次版本号代表新增题型或扩充样本但不破坏旧题语义，相当于菜单 v2 推出后加了几道新菜。A 说的是 2，C 说的是 3，D 在语义化版本中不存在。

Q6. 两名标注者的一致率为 0.8，偶然一致概率为 0.5，则 Kappa 为多少？

单选题 · mid

  • A.0.5
  • B.0.4
  • C.0.3
  • D.0.6← 正确答案

答案：D。Kappa = (0.8 − 0.5) / (1 − 0.5) = 0.6。直观理解：两人一致的 80% 里，有 50% 是瞎猜碰上的，真正反映共识的只有 30%，而这 30% 占理论提升空间（50%）的六成，所以是 0.6。选项 D 对应计算错误，A 是偶然一致率本身，B、C 是误算。

Q7. 评估集版本从 3.0.0 升级到 4.0.0，最可能发生了什么变化？

单选题 · hard

  • A.修复了若干小问题
  • B.新增部分评估题目
  • C.评估标准不兼容变化← 正确答案
  • D.重新打包发布而已

答案：C。主版本号加一，代表评价口径发生了不兼容变化，例如从“只看最终答案”改为“推理过程也必须正确”。这相当于菜单整体翻新，菜品风格都变了，而非小修小补。A 对应补丁，B 对应次版本，D 不属于版本升级的合理理由。

Q8. 构建混合评估数据集的常见数据来源有哪些？

多选题 · easy

  • A.人工标注制作← 正确答案
  • B.模型自动生成← 正确答案
  • C.真实用户日志← 正确答案
  • D.随机噪声数据

答案：ABC。三种标准来源是人工标注（权威高质量）、模型生成（快速覆盖）、用户日志（真实接地气），三者按 $\alpha+\beta+\gamma=1$ 混合。随机噪声既无语义也无真实需求，只会污染评测结果，不是有效来源。

Q9. 下列哪些属于评估数据集质量控制的手段？

多选题 · mid

  • A.抽样检查质量← 正确答案
  • B.交叉复核标注← 正确答案
  • C.设置 Kappa 阈值← 正确答案
  • D.无限增加样本量

答案：ABC。质量控制四板斧是抽样检查、交叉复核、缺陷修复与一致性度量（Kappa 阈值就是量化标准），像品控组抽样试菜并换人复核。无限增加样本量只解决数量不解决质量，甚至可能引入更多冗余噪声。

Q10. 关于评估数据集的覆盖度分析，下列说法正确的有哪些？

多选题 · hard

  • A.检查难度分布是否失衡← 正确答案
  • B.用 embedding 相似度去重← 正确答案
  • C.以任务×难度×领域为网格← 正确答案
  • D.覆盖度越高模型一定越强

答案：ABC。覆盖度分析用三维网格计算 $C = |T_{已覆盖}| / |T_{目标}|$，同时关注难度分布均衡与冗余去重（相似度合并重复题）。但覆盖度只描述考卷本身的全面性，与模型能力无关——考卷出得好不等于考生考得好。