测试集怎么构建的？ground truth 谁标注的？如果标注有错怎么办
P1 · evaluation · 🏢 腾讯
1️⃣ 考察意图
面试官想考察你构建评估体系时的工程严谨性和质量控制意识。这不是背概念题，而是系统设计 + debug 类型。刁钻点在于：多数人只会说“人工标注”，但面试官要听的是如何系统性降低标注噪声，以及发现错误后的完整流程机制。答好了能展示你从“跑通流程”到“可信评估”的硬实力，包括数据飞轮、交叉验证、主动学习等实战经验。
2️⃣ 标准答
构建一个可靠的测试集，我遵循六步流程，核心是让 ground truth 可追溯、可纠错、可迭代。
第一步：确定评估范围和粒度
- 明确测试集覆盖的业务场景（如：多轮对话、长文档问答、跨语言检索）和难度分布（简单/中等/困难各占 30%/40%/30%）。
- 定义评估粒度：是只测最终答案的准确率，还是同时测检索召回率、生成忠实度、延迟等。粒度越细，标注成本越高，但 debug 越精准。
第二步：设计 query 池（LLM 生成 + 人工筛选）
- 用 LLM（如 GPT-4）基于业务文档生成 3 倍于目标量的候选 query，prompt 中注入多样性约束（如“至少 20% 是推理型问题，10% 是时间敏感型”）。
- 人工筛选：剔除重复、歧义、超出知识范围的 query。坑：LLM 生成的 query 常带有“幻觉倾向”，比如问“2025 年 Q3 财报”，但文档只到 2024 年，必须人工过滤。
第三步：标注 ground truth 和支持证据
- 标注人员（通常是领域专家或经过培训的标注员）为每个 query 提供标准答案 + 支持证据片段（文档中的具体段落或行号）。
- 工程取舍：只标答案不标证据，后续无法定位检索错误；标了证据但证据不唯一（如多个段落都相关），则采用多数投票或专家仲裁。这里 trade-off 是：标注证据成本增加 40%，但 debug 效率提升 3 倍。
第四步：覆盖多样性——对抗“数据偏置”
- 按query 类型（事实型、推理型、对比型、否定型）、文档来源（不同部门、不同语言）、难度分层抽样。
- 引入对抗样本：比如故意包含拼写错误、同义词替换、指代不明的 query，测试系统的鲁棒性。实际落地的坑：对抗样本比例过高（>20%）会导致测试集偏离真实分布，建议控制在 10% 以内。
第五步：质量审查——交叉验证 + 主动学习
- 交叉验证：每个 query 至少由 2 人独立标注，不一致的（如答案不同或证据不同）提交给第 3 人仲裁。一致性率（Cohen's Kappa）低于 0.8 的批次退回重标。
- 主动学习：用模型预测结果与标注结果对比，找出“高置信度但错误”的样本（即模型认为简单但实际标错的），优先复审。这能高效发现标注错误，尤其是边界案例。
第六步：持续迭代——数据飞轮
- 测试集不是静态的。每次模型迭代后，收集bad case（模型答错但用户反馈正确的），经过人工验证后加入测试集。
- 定期（如每季度）用新数据替换 10% 的旧 query，防止过拟合。关键：替换时要保留历史版本，以便回溯模型退化原因。
如果标注有错怎么办？
- 发现机制：① 交叉验证不一致的自动标记；② 模型在测试集上表现异常（如某个子类准确率骤降），反向排查标注；③ 用户反馈（线上日志）与 ground truth 冲突时，触发人工复审。
- 修正流程：错误标注被确认后，立即修正并更新版本号（如 v2.1 → v2.2），同时记录错误原因（如“标注员误解了否定词”），用于后续培训。坑：不要直接覆盖旧版本，否则无法复现历史评估结果。建议用 git 管理测试集，每次修改都 commit。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，测试集构建流程，包括范围确定、query 生成、ground truth 标注、多样性覆盖；第二，质量控制机制，核心是交叉验证和主动学习，确保标注一致性率在 0.8 以上；第三，错误处理完整流程，发现错误后不直接覆盖，而是版本化管理并追溯根因。总结一句：测试集不是一次性产出，而是需要持续迭代的数据飞轮。”
4️⃣ 高频追问 & 应对
追问 1：你提到交叉验证，但标注成本很高，怎么平衡？
成本控制的关键是分层抽样。对简单 query（如事实型、答案唯一）只单标，对困难 query（如推理型、多跳）双标 + 仲裁。另外，用主动学习优先复审模型预测与标注不一致的样本，能减少 30% 的无效双标。如果预算极低，可以先用 LLM 生成候选 ground truth，人工只做“校验”而非“从零标注”，成本可降低 50%，但需要设置置信度阈值（如 LLM 自评分数 > 0.9 才免检）。
追问 2：如果标注员和模型都错了，但用户认为正确答案是另一个，怎么办？
这是典型的ground truth 争议。处理原则是：以业务目标为准。比如客服场景，用户满意度是最终指标，那么用户反馈的答案应作为“黄金标准”覆盖原有标注。操作上：建立争议仲裁池，由产品经理、领域专家、标注组长三方投票决定。同时，将这类案例加入测试集的“特殊标签”，用于评估模型的用户对齐能力。
追问 3：测试集需要多大？200 条够吗？
200 条是最小可行规模，适合快速验证。但若要统计显著（如比较两个模型的准确率差异），需要至少 500-1000 条，且每个子类（如不同 query 类型）至少 30 条。经验法则：测试集大小 = 模型参数量的 0.1% 左右（如 7B 模型用 7000 条）。但更重要的是质量：200 条高质量、覆盖全面的测试集，远好于 2000 条有噪声的。
5️⃣ 避坑 · 常见错误答法
- ❌ “测试集用 LLM 自动生成 ground truth 就行，又快又便宜。” → ✅ “LLM 生成 ground truth 只能作为初稿，必须经过人工校验，否则会引入模型自身的偏见和幻觉，导致评估结果虚高。”
- ❌ “标注错误直接删掉那条数据，重新标。” → ✅ “错误标注是宝贵信号，应保留并分析根因（如标注指南模糊、query 歧义），用于改进流程，而不是简单删除。”
- ❌ “测试集建好就不用动了。” → ✅ “测试集需要持续迭代，每季度更新 10%，并保留历史版本，否则模型会过拟合到固定测试集，失去泛化评估意义。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“数据飞轮”角度切入，强调你如何用线上 bad case 反哺测试集，并量化了标注一致性率从 0.7 提升到 0.85 的效果。
- 如果你只做过传统 NLP：用“分类任务测试集”类比，说明你理解标注噪声对 F1 分数的影响，并迁移了交叉验证和主动学习的经验。
- 如果你是校招无项目：聚焦“论文复现”，比如复现 DPR 论文时，自己构建了 200 条 query 的测试集，并手动标注了支持证据，发现了原始论文中 3 处标注错误。
- 《RAGAS: Automated Evaluation of Retrieval Augmented Generation》
- 《Active Learning for Annotation Error Detection》
- 《The Role of Test Sets in Evaluating LLMs: A Survey》
- 《Cohen's Kappa: A Measure of Inter-Rater Reliability》
- 《Data Version Control (DVC) for ML Pipelines》