大模型评测数据集怎么建设和管理？怎么防止测试集泄漏？
面试怎么回答
评测集决定上线决策，是核心数据资产。建设上从线上日志分层抽样真实问题，加入用户反馈的错误、专家设计的核心和边界场景、对抗样本，并按场景、难度、能力维度检查覆盖。每条样本有输入、期望结果或评判标准、场景难度来源等元数据和审核状态。管理上版本化，每次评测记录版本保证可比；业务和数据变化后定期复核过期的标准答案；分成冒烟、回归、完整三层；控制访问权限。防泄漏要在微调前把训练数据和评测集做精确和近似去重，评测题不能当 few-shot 示例，保留只用于最终验证的隐藏测试集，持续补充新问题，分数异常提升时先排查泄漏。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
团队做了好几个大模型应用，每个都有自己的测试题：放在某人的 Excel 里、写在代码里、存在评测平台上，格式不一、来源不明、有没有过期也没人知道。面试官问评测集的建设和管理，想看你能不能把评测集当成核心数据资产来治理。
评测集为什么是核心资产
- 模型换版本、提示词改动、检索策略调整，好不好全靠它判断；
- 评测集质量差，就会做出错误的上线决策；
- 好的评测集需要长期积累，是团队的竞争力。
建设：来源和覆盖
- 真实问题：线上日志抽样，按场景和频率分层抽取，保证和真实分布接近；
- 困难样本：用户反馈的错误、人工发现的失败案例；
- 专家设计：核心业务场景、边界情况、合规要求；
- 对抗样本：注入、越权、歧义问题；
- 覆盖矩阵：按场景 × 难度 × 能力维度（检索、推理、计算、拒答）检查覆盖情况。
每条样本要有什么
- 输入（问题、上下文、用户角色）；
- 期望结果或评判标准（标准答案、必须包含的要点、应该调用的工具、应该拒答）；
- 元数据：场景、难度、来源、创建人、创建时间、依赖的数据版本；
- 审核状态。
管理：像数据一样治理
- 版本化：评测集有版本号，每次评测记录用的是哪个版本，结果才可比；
- 有效性维护：业务规则、数据、知识库变化后，部分标准答案会过期，需要定期复核。依赖数据的样本记录数据快照或版本；
- 分层：冒烟集、回归集、完整集，满足不同频率的评测需求；
- 权限：评测集，尤其是隐藏测试集，访问要受控。
防止泄漏
泄漏指评测集的内容进入了训练数据或提示词，导致分数虚高：
- 训练数据去重：微调前把训练数据和评测集做精确和近似去重；
- 不进提示词示例：评测集的题目不能被拿去当 few-shot 示例；
- 隐藏测试集：保留一部分只有少数人能访问、只用于最终验证的测试集，平时调优不使用；
- 定期更新：持续加入新的真实问题，长期不变的测试集容易被「针对性优化」；
- 关注异常：某个版本的分数突然大幅提升，先检查是否有泄漏。