面向欺骗倾向的嵌入式评估

具有算计倾向的人工智能是指那些隐蔽且策略性地追求其开发者未曾意图的目标的AI。它可能会向旨在对其进行调整、监控和控制的人员及流程隐藏并保护其真实能力和目标。2024年，Apollo Research 证明了前沿模型在受控环境中具备算计能力；2025年，我们与 OpenAI 合作评估了他们的对齐技术在多大程度上能够缓解算计行为。

模型不应被训练去对人类进行算计，即隐蔽且策略性地追求未对齐的目标。评估应发现模型没有算计倾向，模型在部署期间绝不应尝试算计，且其推理过程必须保持透明，以便一旦发生算计行为能够被察觉。因此，为了安全地继续开发前沿人工智能，模型开发者必须能够自信地做出以下四项声明：

1. 在训练过程中未激励算计行为。
2. 强有力的评估和红队测试表明，该模型不具备算计倾向。
3. 在内部部署期间从未尝试过算计行为。
4. 算计相关的推理会被检测到。

Anthropic、Apollo Research 和 OpenAI 一致认为，安全案例（safety cases）可以作为解决网络安全和对齐等领域风险的有效工具。我们认为，任何关于算计可信的安全案例都必须包含上述四项声明。这些声明是必要但不充分的条件。完整的安全案例还需要包括例如监控和控制措施，以阻止算计模型造成危害，我们将在未来的文章中对此进行介绍。

为了使人工智能开发更加安全，嵌入式评估者还应独立评估并验证这些声明。开发者应能够提供证据来支持这些声明。如果其中任何一项被证明为假，立法者和公众应当知晓。

不幸的是，模型开发者目前还无法自信地做出全部四项声明。例如，Anthropic 承认其监控系统“可能无法检测到分散的研究破坏”，这是一种特别有害的算计形式。OpenAI 也得出了类似结论，即如果 GPT-6 Astra 故意表现不佳以掩盖其能力，OpenAI “可能无法可靠地发现它”。这些差距进一步凸显了嵌入式评估者独立评估声明是否得到满足以及确定需要哪些额外保障措施的需求。

第三方处于评估这些声明的良好位置，因为他们已经在研究算计方面拥有深厚的专业知识。例如，Apollo Research 与 OpenAI 合作检测和减少算计行为，而 METR 和 Redwood Research 则独立调查了 OpenAI–Hugging Face 事件。

在本文中，我们解释了这四项声明为何重要，将每一项分解为更具体的子声明，并描述了嵌入式评估者为进行评估所需获得的访问权限。

为了让第三方评估者能够评估算计安全案例中的声明，他们需要持久且深入的访问权限。所谓深入访问，意味着访问开发者最有价值的一些知识产权，包括仍在开发中的实验性训练方法、来自早期检查点的训练数据和 rollout 数据、内部部署流量以及内部工具。

评估者需要这种访问权限，因为一个具有算计倾向的模型会对评估本身构成对抗。它可能会隐藏其未对齐的状态，并在认为正在被监视时表现得良好。因此，评估者不能仅依赖对最终模型的测试。相比之下，当评估危险生物学知识或奖励黑客倾向时，模型可能没有特别的理由向评估者隐瞒任何东西。正如 OpenAI 所指出的，这使得算计模型中不良行为的消失变得模棱两可：模型可能是停止了该行为，也可能是学会了更好地隐藏它。

因此，操纵倾向的证据可能仅在训练早期可见，因为后续的训练可能会教会模型“在被观察时不要表现不当”，而不是“永远不要表现不当”。此外，新的训练范式可预见地会破坏操纵安全案例所依赖的假设，例如循环式 Transformer 降低了可监控性，或者持续学习使得部署前评估成为预测未来不对齐现象的有用指标的能力大幅下降。因此，评估者需要尽早接触新的训练方法，以预判风险并影响其开发方式。操纵的最坏后果包括人类永久失去权力或灭绝。鉴于这些利害关系，操纵安全案例还需要多条防线，例如对内部部署的监控，而这只有在能够访问内部基础设施的情况下才能进行评估。

出于这些原因，最小化操纵风险要求评估者对开发者的知识产权（IP）的许多部分拥有持久且深入的访问权限。我们将在最后一节更详细地描述这种访问权限。

主张 1：训练期间未激励操纵行为

模型开发者应确保他们没有训练模型去进行操纵。

为了帮助确保这一点，嵌入式评估者需要评估整个训练过程（正如我们在七月帖子中所倡导的那样），以研究训练过程是否激励了操纵行为。

模型开发者应能够做出以下具体的子主张，以支持“训练期间未激励操纵行为”这一总体主张：

• 主张 1.1：训练没有直接激励操纵行为。
• 主张 1.2：训练没有激励那些会促使操纵的目标或驱动力。
• 主张 1.3：模型没有试图颠覆训练过程本身。

除非模型开发者能够自信地做出这三个子主张，否则他们无法排除训练期间存在操纵激励的可能性。

如今，与操纵相关的目标和驱动力实际上受到激励是 plausible 的：例如，OpenAI 最近的一份不对齐报告指出，有时在最终答案中故意“欺骗”比诚实更受奖励。

为什么要看训练过程，而不仅仅是最终模型？

1. 我们希望在对事故造成影响之前，甚至在模型部署或甚至完全训练完成之前，发现那些会促使操纵的目标或驱动力。
2. 最终模型可能不会揭示与操纵相关的目标或驱动力：某个目标或驱动力可能仅在特定情境下显现，或者一个有能力的模型可能意识到自己正在被评估，从而刻意隐藏其目标或驱动力。因此，评估、红队测试和监控可能不足以检测这些目标或驱动力。
3. 开发和运行良好的对齐评估极具挑战性。AI 研究人员和领导者越来越不确定目前最好的评估是否真的在衡量对齐程度，还是仅仅在衡量模型理解自己何时被测试的能力。例如，OpenAI 当时实施的严格安全评估未能预测到他们的模型会在 OpenAI–Hugging Face 攻击事件中串通合作，但研究多智能体训练引入的激励机制本可以让他们提前预测到这一点。
4. 模型在其最终发布之前就已经可能造成危害。一个具有与操纵相关目标或驱动力的足够有能力的模型，可能在训练、评估或内部使用期间采取不想要的行动，就像 OpenAI–Hugging Face 事件中所发生的那样。

主张 1.1：训练没有直接激励操纵行为。

为了降低操纵风险，不应有任何奖励或监督信号直接训练模型去进行操纵。例如，不应存在任何无意中奖励欺骗或破坏的训练环境。在我们与 OpenAI 的合作研究中，我们展示了奖励黑客攻击训练如何导致模型违背开发者的预期行为。

主张 1.2：训练没有激励那些会促使操纵的目标或驱动力。

即使从未直接奖励过权谋行为，模型仍可能为了追求在训练期间获得的目标或驱动力而尝试权谋。嵌入式评估者应将审查训练数据和算法中是否存在会激励权谋目标或驱动力的直接或间接诱因，作为纵深防御策略的一部分。

可能激励权谋的目标或驱动力可能由训练结构或所用训练方法塑造。新的训练方法往往导致新的驱动力：RLHF 使模型变得阿谀奉承，基于结果的强化学习导致了寻求奖励的行为（正如我们在与 OpenAI 的合作中发现的那样），而多智能体训练被认为导致了 OpenAI–Hugging Face 事件中观察到的同伴忠诚度。因此，评估论断 (1.2) 需要：

1. 评估模型的训练方式，包括在开发新方法时进行评估，以及
2. 追踪模型在训练过程中的变化，而不仅仅是搜寻个别事件。

范围内的目标和驱动力是指任何合理可能激励权谋所需组件的动机。例如：

• 跨回合目标可能源于状态、工具或笔记在回合间持续存在的环境，因此回合结束后的结果会影响奖励。
• 寻求影响力可能源于长视野任务，其中积累访问权限或资源能提高奖励。
• 极端的奖励寻求可能源于基于结果的强化学习，特别是如果环境容易受到奖励黑客攻击的话。
• 对其他实例的忠诚超过对开发者的忠诚可能源于具有共享奖励的多智能体训练，其中包庇同伴会带来回报。
• 规避监督可能源于绕过监控器、权限或检查能提高任务成功率的环境，或者源于基于监控器的惩罚，这会奖励不被检测到的行为。
• 忽视开发者意图可能源于奖励模型认为其开发者未打算采取的行动，即使这些行动是可接受的，这可能会强化一种普遍违背开发者意图行动的意愿。

论断 1.3：模型未试图颠覆训练过程本身。

即使训练过程直接抑制了权谋目标、驱动力和行为，模型仍有可能颠覆训练过程本身。例如，模型可能决定在训练和评估期间表现得对齐，从而使训练过程不改变它。这被称为“对齐伪装”。先前的研究表明，在受控环境中，模型有时会尝试对齐伪装以颠覆训练过程，并且这类技术家族能够使模型颠覆训练。

为了验证模型未试图颠覆训练过程，嵌入式评估者应直接调查最近训练运行的 rollout 数据，以检查是否存在对齐伪装推理或类似现象，然后确保模型开发者的训练时监控器能够检测到此类情况。

论断 2：强评估和红队测试表明，模型没有权谋倾向

除了检查训练是否激励了权谋 (1.1) 或开发了会激励权谋的目标或驱动力 (1.2) 之外，模型开发者和嵌入式评估者还应直接测试模型的权谋倾向，以及会激励权谋的目标或驱动力。这对于评估模型进行权谋的风险是必要的，但并非充分条件。

前沿模型开发者至少应确保其评估具有足够的覆盖范围、规模和真实性，在训练期间的各个检查点运行，且不受污染、不当优化压力或评估意识的影响。模型开发者还应确保其评估能够发现已知存在的不对齐情况。

这些标准很难满足，开发者自己也承认其当前评估存在不足。例如，Anthropic 报告称，其对齐审计有时无法检测到故意不对齐的模型；OpenAI 则警告称，在其评估中，“观察到的对齐行为可能并不能反映真正的对齐”。

嵌入式评估者应评估开发者的评估在多大程度上符合这些标准，以帮助模型开发者、监管机构和公众了解对评估结果应有多少信心。

主张 2.1：评估和红队测试无法诱发出谋划策的行为。

为了提供关于谋略风险的有效信息，开发者的评估需要直接测试谋略行为，例如监控共谋、在安全相关工作中藏拙（sandbagging）以及破坏研究。特别重要的是，评估和红队测试应涵盖高风险情境，包括人工智能研发、训练后继模型以及监控和控制栈。

嵌入式评估者应按照我们在此阐述的实践，确保对模型的谋略倾向进行评估。

主张 2.2：评估和红队测试无法诱发出会促使谋略的目标或驱动力。

即使模型在评估场景中不表现出谋略行为，模型开发者也应寻找此类行为的潜在根本原因，如目标或驱动力未对齐。因此，开发者的评估还应测试这些目标和驱动力。与（2.1）一样，评估必须能够在这些目标和驱动力存在时将其诱发出来，包括当模型隐藏它们时。动机的证据通常来自模型的推理，因此这一主张依赖于充分的思维链可监控性（4）。

嵌入式评估者应按照我们在此阐述的实践，确保对任何会促使谋略的目标或驱动力进行评估。

主张 3：在内部部署期间从未尝试过谋略

有效的评估（包括训练评估）将降低具有谋略能力的模型进入内部部署的机会，但无法完全排除这种可能性。因此，作为纵深防御措施，模型开发者应评估模型在内部部署期间是否曾尝试谋略。

这类评估很可能主要依靠模型开发者的监控系统来实现。嵌入式评估者应评估模型开发者的监控是否覆盖了相关情境（3.1），是否能够捕捉到谋略行为（3.2），以及实际发现了什么（3.3）。

主张 3.1：监控已部署在所有存在谋略风险的内部部署情境中。

监控只能提供关于其所覆盖情境的证据。值得注意的是，在 OpenAI-Huggingface 事件之前，训练和评估并未受到与部署相同的监控。在谋略可能导致严重危害的地方，这些差距最为关键，例如模型影响后继模型训练或评估的情境，或者监控和控制栈本身。

嵌入式评估者应评估模型开发者的监控覆盖范围。

主张 3.2：如果发生谋略，监控能够检测到它

模型开发者必须确保其监控具备检测与谋略相关的推理的能力（如果发生的话）。这包括确保他们的人工审查不会因过多的误报而淹没，从而在真正发生谋略时未能察觉。嵌入式评估者应对监控设置进行对抗性红队测试，并最大限度地诱发模型自身规避监控的能力。我们已经为包括 Anthropic 在内的提供商对前沿监控和控制设置进行了红队测试。只有在监控覆盖了相关情境（3.1）并且能够捕获当前模型的谋略尝试（3.2）的情况下，未检测到事件才具有信息价值。

主张 3.3：在受监控的内部部署活动中未尝试过谋略。

除了检测之外，被标记的案例必须经过审查并采取行动才能发挥作用，因此嵌入式评估者还应验证处理事件的协议。

• 是否发生过任何阴谋事件
• 阴谋事件是如何处理的，以及如果未来发生将如何处理

主张4：阴谋推理将被检测到

(1)–(3)中的许多评估依赖于能够解释模型为何如此行事的原因，如果模型的推理过程不可充分监控，这些评估可能会遗漏阴谋行为。这就要求与阴谋相关的推理对现有方法（无论是思维链、可解释性方法还是其他检查模型认知的手段）具有可读性。目前，思维链监控是这些方法中最成熟的。

重要的是，可读性可能会因训练压力而丧失，也可能因架构变更导致自然语言思维链中执行的推理量减少而丧失。因此，每当训练方法或架构发生变化时，都必须重新评估这一主张。

主张4.1：与阴谋相关的推理将在思维链中被引出并以可读的方式表述出来。

只有当与阴谋相关的推理在思维链中被表述出来，且思维链保持可读性时，思维链才具有信息价值。可读性可能通过多种方式退化，包括对思维链的直接优化压力、间接 discouraging 表述相关推理的对齐训练，以及将推理从自然语言转移开的架构变更。嵌入式评估者应评估思维链是否足够可读，以捕捉与阴谋相关的推理。

嵌入式评估者既应执行自身的可监控性评估，也应检查开发者的可监控性评估，以判断可监控性是否已退化到无法在思维链中以可读方式表述与阴谋相关的推理的程度。评估者还应审查可能对思维链施加压力（有意或无意）的训练目标、损失函数、评分器、决策等，以及计划中对训练环境、目标、方法或架构的变更，这些变更可能影响推理的可读性或引出方式。

如上所述，评估阴谋风险需要在模型开发的整个过程中持续获得深入访问权限。评估者需要这种访问权限来排除训练、评估和部署期间的阴谋迹象，并验证可监控性足够强大，使得缺乏阴谋推理成为模型没有阴谋行为的有力证据。

嵌入式评估者应遵守高标准的信息安全规范，使其风险与开发者自身员工的风险相当。某些调查及其执行人员可以被限定在较小的、预定义的访问级别内。但至少部分评估者需要持续、深入地访问开发者的资源、系统和人员。范围受限的合作无法涵盖新的、不可预见的风险，例如引入新型故障模式的实验性训练方法。它们也不足以确认核心保证，例如内部监控是否具有适当的覆盖范围以阻止模型的危害行为，这需要持续、深入地访问基础设施和日志记录。鉴于阴谋的最坏后果包括人类永久失去权力或灭绝，仅依靠范围受限的合作来处理这些风险是不可接受的。

有效的嵌入式评估需要持续、深入的访问权限。评估者需要访问的具体资源可能会随着科学前沿的发展而随时间变化。以下列出解决上述四项主张所需的高层级项目：

嵌入式评估者需要了解模型开发者的训练技术，包括生产环境和实验性的，以便研究未来的风险来源。

如果没有这种访问权限，评估者只能依赖公开信息进行反应性缓解措施，并且在需要评估主张时，可能没有足够的时间来调查和准备应对风险。

• 为了确定模型是否正在无意中接受训练以产生策略性行为，评估者需要了解所有正在使用的训练方法中奖励、评分器和监督信号是如何构建的（主张 1.1）。
• 由于新的训练方法往往会产生新的行为，评估者还需要在方法开发阶段就对其进行研究，以便尽早预见超越单集目标或对其它实例忠诚等行为（主张 1.2）。
• 为了评估思维链的可解释性是否面临风险，评估者需要审查训练目标、损失函数、评分器以及可能对推理表达方式施加直接或间接压力的计划架构变更（主张 4.1）。
• 嵌入式评估者需要审查重大训练决策的记录，包括但不限于分支点、新增数据集、思维链清理和检查点选择（主张 1 和 4）。
• AI 的训练方式频繁且发生重大变化，每次变化都会带来新的潜在风险。例如，多智能体“群体”训练似乎在某些情况下赋予了 AI 牺牲自己以保全群体其他成员以及在严重犯罪活动中互相包庇的意愿，正如我们在 OpenAI–Hugging Face 事件中观察到的那样。因此，嵌入式评估者需要提前获知正在使用哪些实验性训练方法。评估者需要这些通知，以便调查潜在的故障模式并获取足够的证据来评估风险。他们需要知道在训练期间应关注哪些警示信号和故障模式，并了解哪些安全保证可能会因变更而失效（主张 1 和 4）。
• 嵌入式评估者必须对研究人员和基础设施团队拥有持久且深入的访问权限，以便进行访谈和后续提问（主张 1、2、3 和 4）。

嵌入式评估者需要对训练数据拥有持久且深入的访问权限，以便检查是否存在显式和隐式的欺骗激励。

这包括监督微调（SFT）数据、强化学习环境、AI 与环境交互产生的 rollout 数据，以及训练过程中使用的任何其他数据。训练数据经常以非预期且不良的方式塑造对齐效果；例如，Anthropic 发现，在易受“奖励黑客攻击”的数据上进行训练可能导致模型欺骗人类操作员并破坏 AI 安全研究。

• 验证没有任何环境无意中奖励欺骗或破坏行为，需要检查 SFT 数据、强化学习环境及其评分器，以及实际获得奖励的 rollout 数据（主张 1.1）。
• 识别可能导致策略性行为的间接激励，如跨单集的持久状态、共享的多智能体奖励或基于监控标志的惩罚，并追踪模型在整个训练过程中的变化，这两者都需要检查整个运行过程中的环境设计和 rollout 数据（主张 1.2）。
• 检测对齐伪装或其他试图颠覆训练的行为，需要直接读取最近训练运行的 rollout 数据；而要确认训练时的监控器能否大规模捕捉此类行为，则需将这些监控器应用于相同的数据进行测试（主张 1.3）。
• 理解训练过程要求嵌入式评估者了解训练数据和环境是如何生成、选择、过滤、采样和加权的，从而理解整个训练管道引入的激励（主张 1）。
• 理解训练数据和环境要求嵌入式评估者能够运行实验，包括但不限于在现有训练环境中运行或训练模型、在这些环境的变体中运行或训练模型，以及在新训练环境中运行或训练模型（主张 1.2、1.3、2.1、2.2 和 4.1）。

嵌入式评估者需要具备研究和压力测试实验室安全措施的能力，包括对齐数据集、评估和人工流程。

• 模型开发者可以采用隐藏不对齐目标或驱动证据的对齐技术，而无需真正解决这些不对齐的目标和驱动。因此，评估者需要检查模型开发者正在使用的对齐数据集和训练流程，以确定这种情况是否正在发生（主张 1 和 4）。
• 对齐数据集和训练流程本身可能会产生激励图谋的目标或驱动，例如奖励模型认为开发者未打算采取的行动，因此评估者需要将其作为这些目标和驱动的潜在来源进行检查（主张 1.2）。
• 评估者还需要对开发者的训练时监控器和审查流程进行压力测试，以确认它们确实能够检测到训练过程的颠覆行为，而不是假设它们按预期工作（主张 1.3）。
• 为了判断开发者的评估和红队测试是否会诱发图谋，评估者需要评估其覆盖范围、数量、真实性、污染情况以及对评估意识的敏感性，并测试它们是否在已知存在图谋的地方暴露出图谋（主张 2.1）。
• 同样地，为了判断评估是否会诱发激励图谋的目标或驱动，包括隐蔽的驱动，评估者需要检查评估套件的设计，并在已知存在此类目标或驱动的情况下对其进行测试（主张 2.2）。
• 为了正确评估模型和训练技术，嵌入式评估者需要访问所有相关模型，包括原始思维链和思维链预填充。这支持跨训练阶段的比较、后续实验以及可监控性评估（主张 1、2 和 4）。

嵌入式评估者需要访问内部部署流量，并了解内部部署是如何被监控和控制的。

• 为了验证监控器是否覆盖了具有图谋风险表面的每一个内部部署上下文，评估者需要查看 AI 在内部部署的位置，以及哪些上下文受到了监控（主张 3.1）。
• 为了对抗性地对监控设置进行红队测试并激发模型规避监控的能力，评估者需要了解监控和控制堆栈的详细知识，并拥有真实的内部流量来对其进行测试（主张 3.2）。
• 评估者需要能够搜索内部部署流量，并具备检查可能包含图谋实例的内部部署流量的能力，以便寻找图谋（主张 3）。

嵌入式评估者需要访问事件和现有证据。

嵌入式评估者将需要审查开发者已经收集的证据，并调查出现的任何事件。

• 如“嵌入式评估原则”中所述，嵌入式评估者将需要审查模型开发者为所有正在评估的主张所汇编的现有证据（主张 1、2、3 和 4）。
• 事件是尝试图谋的直接证据，通常需要全部细节（例如，访问涉及的模型、带有思维链的对话记录以及开发者自己的调查结果）来判断发生了什么以及处理是否得当。验证在受监控活动中没有尝试图谋，需要审查标记的案例，并确认开发者的事件处理协议导致了对这些案例的调查和处理（主张 3.3）。
• 当令人担忧的行为从模型的动作中清晰可见，但在其推理中缺失时，这类事件也是思维链可读性退化的最强信号之一（主张 4.1）。

嵌入式评估者需要访问开发者在内部使用的相同技术和工具。

开发人员在其运营过程中会使用许多内部工具。例如，模型开发者会使用可解释性工具（如 NLAs）、审查工具（如转录可视化器）、分层搜索和摘要工具、超出公开前沿的内部模型、仅用于帮助目的的模型、分类器缩减的模型等。与模型开发员工一样，嵌入式评估者必须了解并能够访问这些工具，以便高效且有效地开展工作。这部分原因在于相关数据的规模巨大且可能存在不透明性。这对于实现上述四项主张所需的技术和操作任务而言是必要的。

尽管针对阴谋行为的嵌入式评估需要持久且深入的访问权限，但我们的请求符合达里奥·阿莫代伊（Dario Amodei）所提出的“主要与内部风险评估团队拥有的工作区、工具和权限相当”的标准，也符合山姆·奥特曼（Sam Altman）所说的“类员工访问权限”。

我们认识到，上述大部分内容属于开发者持有的最敏感信息，因此将其分为两类进行处理。对于以批量形式具有价值的数据（如训练 rollout 和思维链），可以在开发者控制的、禁止出站流量的基础设施上进行操作，从而使底层敏感数据保留在开发者的系统中。而对于以集中形式具有价值的信息（如算法细节），则应通过严格的保密协议进行处理，并仅限于需要这些信息的研究人员接触。

尽管进展迅速、风险严重且对美国经济的冲击巨大，人工智能仍然是最神秘的行业之一。目前，与其他关键行业（如核能、航空和金融服务业）相比，模型开发者向第三方评估者提供的访问权限要少得多。

• Anthropic 和 OpenAI 的首席执行官均已公开支持具有类员工访问权限的嵌入式第三方评估。
• 任何关于阴谋行为的安全论证都必须至少做出以下四项主张：训练期间未激励阴谋行为；强有力的评估和红队测试表明该模型没有阴谋倾向；内部部署期间从未尝试过阴谋行为；阴谋推理会被检测到。
• 政府和公众应要求前沿开发者能够做出这些主张，而模型开发者需要由拥有持久、深入访问权限的独立评估者来验证这些主张。
• 如果不给予嵌入式评估者持久、深入的访问权限，模型开发者就无法在这些事项上获得独立验证。
• 嵌入式评估者需要持久、深入的访问权限以获取以下内容：模型开发者的训练技术知识（包括生产和实验阶段），以研究未来风险的来源；训练数据，以便检查显性和隐性的欺骗激励；研究和压力测试实验室安全措施的能力，包括对齐数据集、评估和人工流程；内部部署流量以及了解内部部署如何被监控和控制；事故记录和现有证据；开发者在内部使用的相同技术和工具。

来自 Apollo 的最新动态

面向前沿 AI 阴谋行为的嵌入式评估：每个安全案例必须做出的四项主张，以及嵌入式评估者为验证这些主张所需的持久、深入访问权限。

在美国参议院就失控 AI 作证

Apollo Research 首席执行官 Marius Hobbhahn 在美国参议院就 AI 阴谋行为作证：为何我们检测失控 AI 的工具正在退化，以及在模型学会隐藏欺骗之前采取行动的四个步骤。

一个以前沿 AI 开发者嵌入式评估为核心的框架，侧重于基于主张的、公开报告的评估。