审批人换了之后，企业 AI 测试如何保留可比性

2026年10月30日，微软研究院介绍了合成企业评估环境，其中已经包含随时间演变的组织历史。原始公告

本文讨论一个更窄的验收问题：审批人按规定更换之后，团队如何保留测试的可比性，并区分应当改变的答案与仍应稳定的业务事实？这是 Open Market Notes 的分析，不是认为微软遗漏了时间维度。以下公司与流程均为假设示例，并非已披露的部署案例。

先固定一次判断所处的组织状态

假设一家设备供应商的销售助理要回答：“这个客户的折扣现在由谁批准？”旧邮件记录着业务主管的意见，新的部门通知把审批责任移交给区域负责人。还有一份尚未生效的流程草案，提出下个月再次调整权限。三份文件都可能真实存在，文字也都说得通。

如果测试只保存一个问题和一个姓名作为标准答案，就会把组织判断压缩成字符串匹配。测试记录至少需要说明提问时间、规则生效时间、员工身份，以及哪些材料在当时可以被看见。否则，模型答出了不同姓名，团队无法判断是检索错了、时间理解错了，还是标准答案已经过期。

这里有一个常被忽略的区别：文件的上传时间、内容描述的事件时间和政策的生效时间，可能分别落在三天。把最新上传的文件一律当成最新规则，会让一次补录历史资料改变现行流程。本文建议在测试中专门安排这样的冲突，而不要让所有日期天然对齐。

保存变化，而不只是不断增加材料

一套可维护的测试环境，可以有稳定的起点，再附上明确的变化记录。例如，第一版只包含原审批关系；第二版加入责任移交，但保留旧邮件；第三版再加入未来生效的草案。每次变化只修改少量条件，就能观察回答在哪一步开始失去依据。

这并不要求把现实公司完整复制一遍。相反，过多装饰性的细节会增加维护负担，而未必提高判断价值。若主要风险是生效日期冲突，就优先保留日期、文件状态与授权关系。餐厅名字、员工兴趣等无关信息可以很少。真实性应当服务于要检验的错误，而不是成为生成数据越多越好的理由。

变化记录还需要写出预期保持不变的部分。审批负责人改变，不代表客户报价也应改变；项目改名，不代表历史合同自动失效。如果更新测试时同时重写所有背景，系统的一次退步可能被新的答案掩盖。保留一些跨版本仍应成立的判断，有助于辨认这种情况。

身份变化会改变可回答的范围

微软的产品说明将访问范围与用户权限关联。产品说明 对采用类似访问模型的企业助理而言，测试中的“用户是谁”因此不能只是一个显示名称。

继续上述假设：销售人员可能可以读取已经发布的折扣政策，却无权查看讨论中的重组文件。系统在技术上遵守了访问边界，仍可能因为缺少决定性材料而无法给出确定姓名。好的测试应允许它解释依据不足、请求核实或转交负责人，而不是强迫每一题都有一个完整答案。

也需要检验相反方向。用户调离项目之后，旧聊天里曾经出现过的内容是否仍被当作当前可用依据？这不是对某个产品漏洞的指控，而是一项值得设置的测试条件。把同一个问题放在身份变更前后执行，可以检查团队实际配置出来的工作流程。测试结果应记录所用身份与配置，不能推广成所有租户的结论。

从测试环境到真实工作，还需要一段有边界的试用

NIST 的 AI 风险管理框架把测量与部署情境联系起来。框架原文 本文据此提出的实施判断是：合成测试适合先排除已知的逻辑错误；真实试用则需要回答这些错误是否覆盖了本公司的主要任务。

一种有限度的做法，是挑选一个低风险团队和一种可撤回的工作，只让助理提出建议，由现有负责人审核。记录被退回的理由，区分来源缺失、政策冲突和用户需求不清，然后把具有代表性的失败改写为不含客户资料的测试条件。这里说的是一种设计方案，不是对生产数据进行任意复制的许可；数据使用仍需单独满足机构的授权与保护要求。

试用也有取样偏差。愿意参加的团队可能文档更整齐，任务更熟悉，审核人也更有耐心。一个部门顺利运行，不能直接推出其他部门具备同样条件。团队应先说明哪些工作被纳入、哪些未被覆盖，以及停止试用的触发条件，再解释成功率。

维护责任应当进入验收成本

组织一直变化，测试也需要有人更新。业务负责人判断规则含义，技术人员保存版本和执行结果，审核人员确认标准答案是否仍然适用。如果这些责任被默认交给“模型团队”，测试库可能在无人明确负责的情况下逐渐脱离现实。

因此，评估合成企业环境的价值时，可以同时看两个问题：它是否帮助发现了原先遗漏的错误，团队能否以可承担的成本保持它有效。后者不宜只用生成一批资料花了多久来衡量，还应包括修改答案、处理争议和回查旧结果所需的时间。

对准备部署企业助理的团队，更有用的交付物是一份带适用范围的测试记录：哪一版组织状态、哪一种身份、哪一组任务得到了怎样的结果，哪些变化需要重测。它不能保证未来不出错，却能在规则和人员变化时，告诉团队上一份通过记录在哪里开始失去解释力。