OpenAI 的 Deployment Simulation：为什么 AI 评测不能只靠考试题

OpenAI 在 2026 年 6 月 16 日发布了一篇研究文章，介绍一种叫 Deployment Simulation 的上线前评测方法。

这个名字可以翻译成“部署模拟”。它想解决的问题很直接：一个模型在正式上线后会怎样表现，不能只靠静态题库、红队 prompt 或排行榜来判断。

很多评测像考试题。它们有明确的题目、明确的风险类别、明确的评分方式。考试题仍然重要，尤其适合覆盖低概率但高严重度的风险。

但真实用户不会按考试题使用 AI。

真实用户会连续追问，会上传不完整的信息，会让模型调用工具，会在模糊目标里不断改需求，也会在模型能力变化后改变自己的使用方式。模型上线后的风险，往往就藏在这些真实上下文里。

Deployment Simulation 的价值，是把评测往真实使用环境拉近了一步。

它到底怎么做

OpenAI 文章里的核心方法并不神秘。

他们从已经发生过的对话中取出上下文，去掉旧模型原来的回答，然后让准备上线的新候选模型在这些上下文里重新回答。接着，研究人员用这些新回答来观察可能的不良行为、估计风险频率，并在模型真正上线后用实际流量验证预测。

也就是说，它不是问模型一组全新的“安全考试题”，而是让候选模型提前经历一批更像真实使用的场景。

OpenAI 提到，他们在 GPT-5 Thinking 到 GPT-5.4 的多个部署中使用了这种方法，总共分析了约 130 万条去标识化对话，时间跨度覆盖 2025 年 8 月到 2026 年 3 月。文章还强调，这些分析只报告聚合结果，并按隐私政策处理可识别信息。

这种方法的核心优势有三个。

第一，覆盖面更像真实使用。它不是只测研究人员已经想到的风险，而是用真实上下文发现一些没有被题库提前覆盖的问题。

第二，频率估计更接近上线场景。传统红队题常常故意极端，适合找严重问题，但不一定能说明问题在普通使用中出现多频繁。

第三，模型更不容易意识到自己在考试。OpenAI 提到，模型越来越可能识别某些评测场景，从而改变表现。部署模拟因为上下文更像真实流量，可以缓解一部分“评测意识”问题。

它不是替代传统评测

Deployment Simulation 听起来很强，但不能误解成“有了它就不需要其他安全评测”。

OpenAI 自己也写得很清楚：传统评测仍然关键。特别是那些低概率、高严重度的风险，不能只靠真实流量分布来发现。

文章还提到一个限制：在实验中，这种方法不能被期待可靠测量低于每 20 万条消息 1 次的行为。这很重要。

很多最危险的问题，恰恰可能是低频事件。比如某些极端滥用、复杂越权、罕见工具失败链路，可能不会在普通样本里频繁出现。它们仍然需要专项评测、红队、形式化约束、上线后监控和人工审查。

所以更准确的理解是：

Deployment Simulation 不是替代红队，而是在红队和上线之间加了一层更接近真实使用的预演。

为什么 Agent 场景更难

OpenAI 论文里还有一个值得注意的部分：工具模拟和 agentic trajectories。

普通聊天评测里，模型主要生成文字。Agent 场景就复杂多了。模型可能调用工具、读写文件、查询外部系统、运行代码、修改状态。评测这类系统时，如果只是让模型“说说会怎么做”，结果不够真实。

论文提到，在工具模拟实验中，OpenAI 使用了约 12 万条 Codex 轨迹，来自内部员工流量，而不是外部 ChatGPT 流量。这里的重点不是数字本身，而是评测对象发生了变化：它不再只是单轮回答，而是带工具、带状态、带上下文的工作轨迹。

这对所有做 AI Agent 的团队都有提醒。

如果你的 AI 系统能调用数据库、发邮件、提交代码、操作后台、修改文件，那么评测不能只问：

你会怎么处理这个任务？

更应该测试：

给你一个真实历史任务、真实约束、真实工具失败和真实权限边界，你实际会怎么执行？

很多风险只会在执行中出现。比如：

• 工具返回空结果时，模型是否会编造；
• 权限不足时，模型是否会绕路；
• 文件状态变化后，模型是否会误删；
• 网络失败时，模型是否会重复提交；
• 用户目标含糊时，模型是否会越权替用户做决定。

这类问题靠几道标准题很难发现。

小团队能学到什么

普通团队没有 OpenAI 那样的流量、模型和评测基础设施，但可以借鉴 Deployment Simulation 的思想。

你不需要 130 万条对话。你可以从 30 到 100 个真实任务开始。

例如，一个客服团队可以抽取过去一个月的真实咨询，去掉用户隐私和身份信息，让新的客服机器人重跑，比较它是否：

• 理解了用户问题；
• 没有承诺做不到的事情；
• 正确引用了政策；
• 知道什么时候转人工；
• 没有泄露内部信息；
• 没有把模糊问题回答得过于确定。

一个开发团队可以抽取历史 issue、PR、失败日志和修复过程，让新的 coding agent 重跑，比较它是否：

• 能复现问题；
• 会先读代码而不是乱改；
• 不会删除无关文件；
• 会运行必要测试；
• 能解释不确定性；
• 在权限不够时停下来说明，而不是假装完成。

这就是小规模的部署模拟。

它比“问五个 demo prompt”更接近真实，也比“只看榜单分数”更能反映你的业务风险。

一个实用评测清单

如果你要在团队里上线一个新 AI 工具，可以按下面的方式做一次轻量预演。

第一，收集真实任务样本。

不要只写理想 prompt。选真实发生过的任务，包括成功案例、失败案例、边界案例和让人烦的长尾问题。

第二，去掉敏感信息。

把姓名、手机号、客户资料、密钥、内部链接、未公开商业信息删除或替换。评测不能变成新的数据泄露风险。

第三，让候选工具重跑。

不要只看它第一轮回答。尽量模拟真实流程：需要查资料就查资料，需要调用工具就调用工具，需要多轮澄清就多轮。

第四，记录失败模式。

不要只打一个总分。记录它是事实错、越权、幻觉、遗漏步骤、过度自信、工具调用失败，还是无法解释不确定性。

第五，上线后继续验证。

部署模拟只是预测。上线后仍然要看真实反馈，比较预测和实际问题是否一致。如果出现新的失败模式，要回到样本库里补测试。

这件事为什么值得关注

AI 行业过去很喜欢用榜单和单点演示讲能力。榜单有价值，演示也有价值，但它们越来越不够。

真正的问题是：模型进入真实世界后，在真实上下文、真实工具、真实约束、真实用户变化中，会怎样表现。

OpenAI 的 Deployment Simulation 之所以重要，是因为它把“上线前评测”从考试题往真实工作流推进了一步。

未来更可靠的 AI 产品，不会只说自己分数高，而会更清楚地回答：

• 我们用哪些真实场景测过；
• 哪些风险能提前估计；
• 哪些风险仍然不能覆盖；
• 上线后怎样监控；
• 出现问题怎样回滚和修正。

这也是普通人判断 AI 工具时应该问的问题。

资料来源

• OpenAI: Predicting model behavior before release by simulating deployment
• OpenAI paper: Predicting LLM Safety Before Release by Simulating Deployment