你的黄金评估集（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》，逐字记录的示例就是从评估集中提取的。它们在技术上经过了匿名化处理——更改了姓名，掩盖了账号——但对话的底层结构是完整的。任何了解该客户的人都能认出这是他们与支持团队的对话。这在多家公司都发生过，典型的复盘结果包括收到下架通知，以及与客户的隐私办公室进行一场艰难的谈话。
共同点在于，这些都不是离奇的数据外泄场景。它们是日常的工程活动——调试、撰写方法论、训练模型、讲述市场故事——这些活动通过评估集时没有任何控制闸门，因为团队根本没有建立控制闸门。
真正需要落地的纪律
弥合差距的工作并不光鲜，其核心在于将分类和生命周期规则推向上游，直到 trace（追踪记录）转化为 eval case（评估案例）的那一刻，而不是等到 eval case 已经存在于 JSON 中后再去处理下游。
存储对等性是首要的。eval bucket 需要与生产 trace bucket 相同的访问控制——相同的 SSO、相同的审计日志、相同基于租户 ID 的行级过滤。“工程共享”是一个错误的默认设置。如果 CI 任务需要读取数据，该任务应该获得一个具有限定范围的服务账号，且仅能访问脱敏后的派生视图，而不是直接访问规范存储（canonical store）。这在技术上不需要任何成本，只需要与平台团队开个会来设置 ACL。之所以默认情况下没有实现，是因为没有人提交工单。
脱敏必须在晋升（promotion）阶段进行，而不是在发布（publication）阶段。大多数团队的本能是在发布时——即 eval 集离开团队时——进行脱敏。那已经太晚了。当你发布时，eval 集已经复制到了笔记本电脑、CI 日志、导出文件和快照中。脱敏策略需要在 trace 被晋升为 eval case 的那一刻触发。姓名、电子邮件、电话号码、账号，任何符合 PII（个人身份信息）模式的内容在 case 提交到存储之前都必须被剥离或令牌化。规范的“正确答案”是针对脱敏后的查询编写的，而不是原始查询。原始 trace 仍留在受控的 trace 存储中；eval 集永远不应持有未经脱敏的版本。
这比在最后进行脱敏需要更多的工作，因为它迫使你做出决定：如何为一个姓名和金额已被替换为占位符的查询编写标注答案？有时答案不依赖于 PII，脱敏也就没问题。但有时答案是“客户应获得 437.22 美元的退款”，而金额正是测试的核心。在这种情况下，占位符策略需要是确定性的——同一个客户名始终对应同一个令牌，相同的金额始终对应同一个令牌——这样答案就可以引用占位符而不会丢失意义。大多数团队会发现，这是一个真正的工程项目，而不是调用一行库函数就能解决的。
数据保留必须符合客户声明的保留期限。如果客户合同或 DPA（数据处理协议）规定 trace 保留 90 天，那么从这些 trace 派生出的 eval case 也不能永久存在。这是团队经常违反的规则，因为 eval case 的全部意义就在于它是用于回归测试的永久资产。这种矛盾的处理让人感到不适：要么在底层 trace 到期后，必须从合成数据重新生成 eval case；要么 eval 策略需要在客户合同中明确豁免，声明派生的 eval case 的持久化时间可以长于原始 trace。无论采用哪种方式，在监管机构问询之前，这项政策必须以书面形式存在，而不是用耸耸肩来应对。
删除操作必须端到端贯通。当客户行使删除权（right to erasure）时，删除操作需要扩散到派生的 eval case，而不只是生产 trace 存储。大多数团队的删除流水线涵盖了 trace 存储、数据仓库、分析导出和嵌入索引，然后就戛然而止了。eval bucket 不在列表中，因为它从未被归类为客户数据。将其添加到列表中只需要修改一行脚本，但实际上需要一个为期一周的项目来连接血缘关系（lineage），以便脚本知道哪些 eval case 派生自哪个客户的 trace。
工程团队未曾察觉的法律界限
合同层是成本变得昂贵的地方。标准数据处理协议通常会写道：“处理者仅为提供服务之目的处理客户数据。”每家主流 AI 厂商的 DPA 都有类似表述——OpenAI、Anthropic、Google，以及律师粘贴到每个 B2B SaaS 协议中的样板。
构建 eval 集并不是“提供服务”。它更接近于“改进模型”或“开发新产品”，在 GDPR 以及诸如《欧盟 AI 法案》等下游法规中，这些属于截然不同的目的。客户从未同意过这些目的。即使 eval 集仅供内部使用且从未泄露给其他客户，也不会改变这一法律定性。GDPR 第 5(1)(b) 条下的“目的限制”原则是关于数据处理的目的，而不是数据暴露给哪些受众。
这种情况在两种场景下会变得尖锐。首先，当客户仔细阅读合同时——通常是因为他们的隐私办公室正在进行年度审计——并注意到厂商的 eval 流水线不在任何列出的目的范围内。其次，当客户终止服务并启用删除条款时。厂商的标准回答通常是“我们已在 30 天内删除了所有客户数据”。如果 eval 集不在删除扩散列表中，那么该声明就是虚假的。在涉及 GDPR 的合同语境下，虚假陈述不是客户服务问题，而是监管风险。
解决办法是将 eval 集的派生作为 DPA 中一个明确的处理目的，并获得明确的同意或合同依据，制定明确的保留规则，并在删除条款中明确说明处理方式。在签约时主动提出这些条款的谈判筹码，远比在客户离开六个月后，还得事后解释为什么你的黄金数据集（golden dataset）中仍包含他们的查询要高得多。
应当重塑评估管线的核心认知
这个问题之所以成为新挑战，是因为传统的 QA 测试数据并非取自实时客户，且没有预先附带模型的正确答案。单元测试使用的是手工编写的输入。集成测试使用的是合成的固定数据（fixtures）。最接近的类比是 VCR 等工具中记录的 HTTP fixtures —— 它们捕捉了交互的一方并频繁轮换。这种 fixture 关注的是系统，而不是客户。
LLM 评估从两端打破了这一假设。输入是真实的客户查询，因为评估的意义就在于针对真实的分布进行测试。输出是标记好的正确答案，通常由领域专家根据客户的实际情况审核生成。这种组合形成了一个结构化的产物，既捕捉了客户的提问，也记录了公司认为正确的响应，这比其中的任何单一维度都更加敏感。
安全团队并不习惯将测试数据视为隐私边界。对于“我们要建立一个回归测试套件”的安全审查几乎为零。而对于“我们正在采样生产数据，为其标记正确答案，并将其作为随代码库分发的永久语料库进行存储”的安全审查本应长达数页，但没人提出这种要求，因为它在需要审查的类别中并不显眼。
走在前面的团队会将评估管线构建为数据平台的一个分支，而不是工程生产力工具的一个分支。他们将评估存储与生产追踪（trace）存储放在一起，继承其管控措施，附加相同的保留和删除策略，并将评估存储桶视为带有额外标签层的客户数据存储。没能提前意识到这一点的团队，在未来两到四年内的某个时刻会发现，他们的“黄金数据集”成了监管机构询问“目的限制”时的甲号证物，而“我们将其视为工程数据”这个回答并不是监管机构想听到的。
这一教训最简短的版本是：一个评估用例就是一个附带有衍生作品的客户查询。这两个部分都是敏感的。从它们被提升（promotion）的那一刻起就应当妥善对待，否则就准备好解释你为什么没这么做。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
