评估数据集是附带正确答案的客户数据

你的黄金评估集（Golden eval set）是一个你的安全团队甚至不知道其存在的隐私边界。它是通过对生产环境的 Trace 进行采样构建的，这意味着它是一系列精心挑选的真实客户查询集合——通常包含姓名、电子邮件、账号、愤怒的通话记录、输入了一半的信用卡卡号——并配有标准正确回复，最后提交到评估流水线读取的任何存储桶中。

最后一部分正是评估数据具有独特危险性的原因。原始的生产 Trace 之所以敏感，是因为它记录了客户所说的话。而评估案例则以一种全新的方式变得敏感，因为它记录了客户所说的话 加上标注的正确答案。这个标签是一个衍生作品，由某人（通常是标注员或领域专家）有目的地添加。它标志着“这是标准答案”。它赋予了 Trace 原始日志从未有过的生命力——日志保留策略最终会将 Trace 轮转删除，但评估案例现在成为了一个永久的测试 fixture（固定数据），团队致力于保持其测试通过（keeping green）。

大多数团队对待评估数据集的方式就像对待单元测试的 fixture 一样：共享的工程资产，权限控制宽松，有时会提交到代码库中，有时会直接粘贴到方法论博客文章的附录里。当面临“这是客户数据吗？”这个问题时，这些处理模式都经不起推敲。答案是肯定的，其影响会级联到存储、访问、保留、删除和合同等方面，而团队通常没有为此预留预算。

评估流水线中隐藏的隐私绕过

生产数据处于真实的访问控制保护之下。客户支持工具需要 SSO 和审计日志。数据仓库具有与租户 ID 绑定的行级安全性。提取 Trace 以调试 P1 问题的值班工程师必须在工单中说明读取理由。这并非英雄之举，只是任何过了 B 轮融资的公司被迫建立的基准成熟度。

评估流水线绕过了这一切。以下是典型的路径：一个链路追踪平台——Langfuse、LangSmith、Helicone 或内部封装工具——捕获每个 prompt 和 completion。工程师查看最近的 Trace，找到模型表现不佳的案例，将它们复制到带有“正确答案”列的 Google 表格中，手动标注几百条，然后将它们作为 JSON 导出到团队共享的 eval-data 目录中。该目录拥有 engineering-shared 权限，这意味着每个拥有笔记本电脑的人都可以读取它。CI 任务在每次模型升级时都会加载它。同样的 JSON 最终出现在外包人员的本地代码副本中，因为他们正在调试一个不稳定的回归问题。

在这条链路中的任何环节，都没有人重新评估这些数据是否仍应被所有能克隆代码库的人访问。评估集继承的是工程团队的访问权限，而非客户数据的访问权限。在“生产 Trace”和“测试 fixture”的界限处，数据分类被丢弃了。一旦它被标记为 fixture，肌肉记忆就会接管：fixture 会被提交到代码库，fixture 会在集成期间与供应商共享，当你向全员展示回归测试的工作原理时，fixture 会被复制到幻灯片中。

架构上的失败是结构性的，而非恶意的。团队构建了一个系统，在这个系统中，一旦 Trace 变成“测试案例”，它就不再被视为客户数据。公司中所有其他的隐私控制都位于某种分类的下游，而评估流水线静默地剥离了这种分类。

评估集究竟在何处泄露

泄露面比大多数团队想象的要宽。以下是反复出现的模式。

外包笔记本电脑。 聘请顾问来修复不稳定的 CI 套件。他们克隆了代码库，评估 JSON 也随之而去，现在真实的客户查询正存放在一台机器上，而公司对此机器没有资产记录，没有远程擦除权限，也没有离职减权流程。当服务结束时，没有人知道评估集是否已被删除，因为根本没人知道它曾经存在过。

模型卡片（Model Card）附录。 团队为内部博客文章或公开论文撰写基准测试方法。为了使方法论具体化，他们包含了“10 个代表性示例”。其中两个示例包含本应脱敏但未脱敏的客户姓名，因为在发布前没有人进行 PII 扫描——评估集一直被视为工程数据，而工程数据不会经过脱敏审核。

微调训练语料库。 这是代价最惨重的失败。评估数据和训练数据存储在相邻的存储桶中，使用类似的命名约定，一个急于求成的工程师编写的微调脚本匹配到了错误的目录。模型现在正在它自己的测试集上进行训练。除了受污染的基准测试带来的方法论灾难（2025 年关于数据集泄漏的 Kernel Divergence Score 研究将其定义为一个可衡量的科学问题）之外，法律立场更加糟糕：原本“为了提供服务”而捕获的客户查询现在被用于训练模型——这完全属于另一类处理行为。

基准测试博客文章。 市场部门想要一个故事。应用团队产出了《我们的 Agent 如何在真实客户支持查询中击败 GPT-5》，逐字记录的示例就是从评估集中提取的。它们在技术上经过了匿名化处理——更改了姓名，掩盖了账号——但对话的底层结构是完整的。任何了解该客户的人都能认出这是他们与支持团队的对话。这在多家公司都发生过，典型的复盘结果包括收到下架通知，以及与客户的隐私办公室进行一场艰难的谈话。

共同点在于，这些都不是离奇的数据外泄场景。它们是日常的工程活动——调试、撰写方法论、训练模型、讲述市场故事——这些活动通过评估集时没有任何控制闸门，因为团队根本没有建立控制闸门。

真正需要落地的纪律

加载中…