Agent 评估中的「数据泄漏「问题如何应对

Agent 评估中的「数据泄漏「问题如何应对

1️⃣ 考察意图

考察对评估公正性的理解。刁钻点：LLM 的训练数据可能包含 benchmark 答案，导致评估分数虚高。

2️⃣ 标准答

数据泄漏的三种形式：

1. 直接泄漏：Benchmark 数据被包含在 LLM 训练集中。如 HumanEval 的代码在 GitHub 上公开，可能被爬取进训练数据
2. 间接泄漏：LLM 训练数据中包含 benchmark 的"解题思路"或"类似题"。如 SWE-bench 的 GitHub PR 在训练数据中
3. 评估集污染：自建评估集的数据通过日志、对话等方式泄漏到 LLM 的训练数据中

检测方法：

• Membership Inference：测试 LLM 对 benchmark 题目的"记忆程度"。给 LLM 题目的前半部分，看它能否精确生成后半部分（如果能，说明在训练数据中见过）
• 时间分割：用 benchmark 发布后的新数据测试。如 SWE-bench 的 Issue 是 2023 年的，用 2024 年的新 Issue 测试可以避免泄漏
• 对比测试：同一个任务，用原始版本和"改写版本"（同义改写但答案不变）测试。如果原始版本分数显著高于改写版本，说明有泄漏

应对策略：

最佳实践：

1. 自建评估集严格隔离——只有评估团队可访问，不进训练数据
2. 公开 benchmark 用"改写版本"测试——将题目同义改写但保持答案不变
3. 定期用新数据测试——每季度新增 10-20% 任务
4. 报告评估时注明 LLM 版本和评估日期——不同版本的 LLM 可能有不同的泄漏程度

3️⃣ 答题模板

"数据泄漏三种形式：直接泄漏（benchmark在训练数据中）、间接泄漏（类似题在训练数据中）、评估集污染（自建集通过日志泄漏）。检测：Membership Inference（测试记忆程度）、时间分割（用新数据）、对比测试（原始vs改写）。应对：私有评估集严格隔离、动态生成新题目、季度更新10-20%、报告注明LLM版本。核心认知：公开benchmark的分数都有泄漏风险，私有评估集是唯一可靠方案。"

4️⃣ 高频追问

追问 1：GPT-4 在 HumanEval 上的 90%+ 分数有多少是泄漏的？

难以精确量化。证据：(1) HumanEval 的代码在 GitHub 上公开，GPT-4 训练数据包含 GitHub 代码；(2) 用改写版本测试（同义改写题目描述但答案不变），GPT-4 分数从 91% 降到 85%——说明约 6% 是泄漏的；(3) 用全新的 HumanEval-like 题目（同格式但新题目），GPT-4 约 80%——说明约 11% 是泄漏的。但 80% 仍然很高，说明 GPT-4 的代码能力确实强，泄漏只是部分原因。

追问 2：怎么用 LLM 动态生成新评估题目？

流程：(1) 用 GPT-4 根据原题目的模式生成新题目（如 HumanEval 的函数级编程题）；(2) 用 GPT-4 生成参考答案；(3) 运行参考答案验证正确性——通过单元测试的保留，不通过的丢弃；(4) 人工抽检 10%——验证题目质量和答案正确性。挑战：GPT-4 生成的新题目可能与原题目太相似（不够多样），或难度分布不均匀。需要人工审核和调整。

追问 3：Agent 评估比 LLM 评估更难防泄漏吗？

是的。原因：(1) Agent 评估需要环境（如 Web 网页、代码库），环境本身可能在训练数据中——如 SWE-bench 的 GitHub PR；(2) Agent 评估是交互式的，LLM 可能在多步交互中"回忆"起答案；(3) Agent 评估的任务通常是真实世界的（如真实网页操作），难以"改写"——你无法改写真实网页。解法：(1) 用私有环境（如自建仿真网站）；(2) 用时间分割——用最近的、不太可能在训练数据中的任务；(3) 接受一定程度的泄漏，但在报告中注明。

5️⃣ 避坑

• ❌ "公开 benchmark 分数高就够了" → ✅ "公开 benchmark 可能有数据泄漏。需要用私有评估集或改写版本验证。"

6️⃣ 简历呼应

• 有评估经验：从"防泄漏策略"切入，描述你设计的私有评估集和防泄漏机制
• 校招无项目：在 HumanEval 上对比原始版本和改写版本的分数差异
• "Evaluating LLMs on Contaminated Benchmarks" (2024) / "Data Contamination in LLM Evaluation" (Yang et al., 2023)