跳转至

Lecture10

LaTeX 源码

\makecscover

来源审计：Scaling 不是一条曲线，而是一套 Operating System

本讲由 Anthropic 联合创始人 Ben Mann 主讲，时间是 2025 年 2 月。课堂从 GPT-2/GPT-3 与 scaling laws，讲到 frontier training 的 distributed failure、loss spike、RLHF/Constitutional AI、安全评估、Responsible Scaling Policy（RSP）、mechanistic interpretability，以及 chat 产品与 API 的不同发布纪律。仓库保留官方封面和 1025 条时间戳字幕；本文用论文与 Anthropic 官方材料校验机制，不把演讲后的模型、收入、RSP 或产品状态倒写回课堂。

课堂口径与版本边界

“过去一年十倍增长”“coding segment 三个月十倍”等数字只作为讲者当时的 workload 描述，不当作经审计财务结论。课堂使用 2025-era AI Safety Level（ASL）叙事；截至 2026 年 8 月 11 日，Anthropic 已在 2026 年 2 月 24 日发布 RSP v3.0，采用 capability thresholds、required safeguards 等更新框架。本文先忠实解释历史课程，再单独标记后续演化。

Frontier model program 的四个闭环

  1. Scaling loop：hypothesis \(\rightarrow\) pilot runs \(\rightarrow\) fit/forecast \(\rightarrow\) compute allocation；
  2. Training loop：telemetry \(\rightarrow\) anomaly \(\rightarrow\) checkpoint/replay \(\rightarrow\) fix/resume；
  3. Safety loop：pre-training \(\rightarrow\) post-training \(\rightarrow\) evaluation \(\rightarrow\) safeguards/deployment；
  4. Product loop：chat experiment \(\rightarrow\) behavior evidence \(\rightarrow\) API contract \(\rightarrow\) migration/deprecation。

术语消化：四种“规模”必须分开

Training scale 是参数、token 与训练 FLOPs；serving scale 是请求量、context、latency 和 accelerator fleet；capability scale 是任务成功、泛化与 tool use；risk scale 是模型能力、访问方式和 safeguard failure 共同产生的潜在影响。收入或流量增长不能直接证明 capability，benchmark 增长也不能自动证明 safety。

增长为什么会改变工程假设

快速需求增长不只意味着“多买 GPU”。Training 与 inference 争夺 capacity，API 用户要求稳定 contract，chat 用户期待更快迭代，安全团队要处理更多 adversarial traffic，on-call 则面对更高故障成本。Program 需要把 capability、compute、reliability 和 safeguards 放在同一资源模型中，而不是分别优化。

\lecturefigure{01-scaling-program.png}{Frontier scaling 是 demand、capability、compute 与 reliability 耦合的 program。}{本地字幕 00:00--01:00；概念重绘。}

读图：增长带来正反馈，也带来风险复利

Demand 提供收入和真实任务；capability 提高 adoption；compute 支持训练与 serving；reliability 维持用户信任。任何一环失衡都会反向放大：capability release 没有 serving capacity 会造成排队，traffic 没有 abuse control 会扩大风险，训练挤占 inference 会伤害现有客户，API regression 则会把模型升级变成业务 outage。

本章小结

Scaling program 的对象是完整生命周期。后文不会把“更大模型”当成单一答案，而会追问预测、训练、恢复、对齐、评估、发布与兼容性如何共同成立。

从 GPT-2 到 GPT-3：把直觉变成可检验 Scaling Hypothesis

Mann 把 2015 ImageNet 和随后 GPT-2 的出现视为关键 field signal：长期被认为只是 academic promise 的神经网络开始在真实任务上表现出可迁移能力。GPT-2 提示“在大规模互联网文本上做 next-token prediction 可能产生广泛能力”，GPT-3 则用多尺度实验检验参数、数据和 compute 增长是否稳定改善 loss 与 few-shot performance。

Observation、hypothesis、pilot 与 frontier run

\term{scaling law}（缩放定律）是模型性能或 loss 与 compute、dataset size、parameter count 之间的经验规律。它的工程价值不是事后画一条漂亮线，而是在最大训练前用较小 run 估计收益、比较 recipe、配置 data/model mix，并明确何时新证据表明 regime 已改变。

\lecturefigure{02-scaling-hypothesis.png}{Scaling law 把 field signal 转成 hypothesis、pilot runs 和可预测的 frontier commitment。}{本地字幕 01:00--05:40；GPT-2/GPT-3 与 scaling laws 论文。}

读图：最大 run 之前必须有预测

Field signal 提供方向，hypothesis 明确“哪些变量增加会怎样改变 loss”，pilot runs 要跨多个尺度并保持可比 recipe，frontier run 则在预算批准前写出 expected curve、confidence 和 stop condition。若团队只有一个大 run，没有 holdout prediction，就很难判断成功来自 scaling、data cleanup、architecture change 还是选择性解释。

\teachervoice{Mann 强调自己没有传统 PhD 路径，却通过 data engineering、分析与 architecture experiment 参与 GPT-3。课堂提示：frontier research 的关键贡献不只来自提出新公式，也来自构造可信数据、实验和测量系统。}

为什么当时很多人不信

怀疑并不荒谬：历史技术常经历 sigmoid，已有模型可能成本高、部署困难，BERT/T5 时代的经验又强调 task-specific fine-tuning。问题在于把“当前 recipe 和 hardware 下的经济性”误当成“永远的能力上限”。更好的争论方式是要求跨尺度预测、residual analysis 与外推边界，而不是用一次昂贵 demo 或一次失败否定整个假设。

Scaling law 不是“只要加 compute 就一定成功”

Architecture、optimizer、token mixture、data contamination、context length、precision、parallelism 和 post-training 都可能改变曲线。Power law 只描述已观测区间的经验关系；跨 modality、跨 recipe 或跨多个数量级外推时，应扩大 uncertainty，并准备发现新的 bottleneck。

本章小结

Scaling hypothesis 的科学性来自可预测和可证伪。Field signal 触发方向，多尺度 pilot 提供曲线，frontier run 检验外推；任何结果都必须与预注册预测和 residual 对照。

读懂 Scaling Law：Fit、Residual 与 Compute Allocation

前一节解释了研究路径，本节进入公式与决策。常见语言模型 scaling law 把 cross-entropy loss 写成资源的幂律衰减加不可约项。重点不是背 exponent，而是理解每个 fit 假设、数据范围与误差如何影响数千万乃至更高成本的 compute allocation。

Power Law 与不可约损失

\term{cross-entropy loss}（交叉熵损失）衡量模型给真实下一个 token 分配的负对数概率。一个简化 compute scaling 形式是

\[ L(C)=L_{\infty}+aC^{-\alpha}, \]

其中 \(C\) 表示训练 compute，\(L(C)\) 是对应 loss，\(L_{\infty}\) 是当前数据/任务假设下的不可约项，\(a\) 是尺度系数，\(\alpha>0\) 是收益衰减速度。Log-log 图可能近似直线，但 \(L_{\infty}\)、噪声与 recipe change 会显著影响外推。

\lecturefigure{03-scaling-law-fit.png}{Scaling law 是带 residual、confidence 和适用边界的 fit，而不是永恒直线。}{Kaplan et al. 2020；本地字幕 06:20--11:50；概念重绘。}

读图：先看残差，再看斜率

Axes 必须说明是 FLOPs、token、parameter 还是 wall-clock；fit 要给训练区间和 confidence；residual 显示 architecture、data 或 optimization 是否系统偏离；decision 才能据此调整 budget、model/data mix 或停止外推。若较大 run 连续落在预测线同一侧，最重要的信息可能不是“模型还不错”，而是当前 law 已失配。

Benchmark 提升与 loss scaling 不是同一函数

Average loss 的平滑下降可以对应某些 downstream task 的突然阈值效应，也可能不改善目标任务。能力评估要覆盖真实环境、工具和 elicitation；不能用一条 pre-training loss 曲线替代 post-training quality、安全和 serving economics。

Compute multiplier 是组合，而不是秘密常数

课堂把 architecture、data、optimizer 和 systems improvement 统称为 compute multiplier：同样 nominal FLOPs 下获得更多 effective capability。保密具有竞争理由，但内部仍要能复现。每个 multiplier 应有 baseline、ablation、interaction 与 transfer evidence，避免 portfolio 中多个改动相互抵消却都被宣称成功。

\lecturefigure{04-compute-allocation.png}{Compute allocation 同时投资 model、data、optimization 与 systems 四类 multiplier。}{本地字幕 12:00--15:20；概念重绘。}

读图：收益要按 effective compute 归因

Architecture 可能提高表达或稀疏效率；data 改善 signal-to-noise；optimization 提高稳定性与收敛；systems 提高 hardware utilization。最终应比较固定 wall-clock、固定美元、固定 energy 或固定 FLOPs 下的 quality，而不是只报告某一 microbenchmark。Multiplier 还可能只在特定 scale 生效，必须验证 transfer。

\teachervoice{讲者把 frontier lab 描述成 researchers 与 engineers 深度协同，而不是研究员提出想法、工程师做“杂活”。Scaling law 让两者共享一个实验语言：研究改 recipe，工程保证 run 可比、可恢复、可测量。}

本章小结

Scaling law 是资源决策工具。正确做法是联合 fit、residual、uncertainty 与 multiplier ablation；错误做法是把历史指数当自然常数，或把系统吞吐提升直接等同于模型能力提升。

Distributed Training：Rare Failure 会变成日常事件

Frontier run 同时依赖大量 accelerators、host、collective network、dataset storage、checkpoint storage、scheduler 和 cloud quota。单个组件的故障率即使很低，规模扩大后也会频繁中断。系统目标不是幻想零故障，而是限制 failure domain、快速检测、保存科学状态并恢复有效进展。

Workers、network、storage 与 scheduler

\term{collective communication}（集合通信）是 all-reduce、all-gather、reduce-scatter 等多设备协同 primitive；一次慢 worker 或 network partition 会拖住同步训练。Storage 既要持续供给 token，也要接收大 checkpoint；scheduler 则维护 membership、placement 与 restart。任何依赖都需要 health signal、timeout、backpressure 和 ownership。

\lecturefigure{05-training-failure-domains.png}{Frontier training 耦合 workers、network、storage 和 scheduler 四类 failure domain。}{本地字幕 15:00--17:20；概念重绘。}

读图：先区分 hard failure 与 silent corruption

Hard failure 包括进程退出、设备掉线、storage timeout，容易触发 restart；silent corruption 可能表现为错误数据、collective bit error、stale code 或异常梯度，更危险。监控不仅要回答“job 还在跑吗”，还要回答“它是否仍在执行同一个有效实验”。

Useful training rate

设理论峰值 compute 为 \(F_{peak}\)，有效利用率为 \(u\)，因故障、恢复与空转损失的比例为 \(d\)，则长期 useful rate 可近似写为

\[ F_{useful}=F_{peak}\,u(1-d). \]

其中提高 kernel MFU 只改善 \(u\)；若 checkpoint 太慢、故障检测迟或恢复不一致导致 \(d\) 很大，昂贵硬件仍无法转化为有效训练进展。

本章小结

规模让 rare failure 常态化。Distributed training 必须同时优化 steady-state utilization 与 recovery tax，并用实验一致性而非“job resumed”作为恢复成功标准。

Training Observability：Loss Spike 只是症状

训练不是提交 job 后等待数周。研究假设可能被 data corruption、optimizer instability、precision overflow、code regression、network degradation 或 checkpoint mismatch 破坏。单看 global loss 无法诊断，因此需要 model、optimizer、data 与 system 四个同步 telemetry plane。

四类 Telemetry 与 anomaly triage

\term{loss spike} 是训练 loss 突然异常上升，可能短暂恢复，也可能预示 run 已失效。Model plane 记录 loss、gradient/activation statistics；optimizer plane 记录 learning rate、moment/update norm；data plane 记录 batch source、token mixture 与 corruption；system plane 记录 utilization、network、storage 和 hardware error。

\lecturefigure{06-training-observability.png}{训练诊断需要 model、optimizer、data 与 system 四类同步 telemetry。}{本地字幕 17:20--20:10；概念重绘。}

读图：Correlation 先于 root cause

当 loss spike 出现，先把异常时间对齐 data batch、optimizer update、collective retry 和 device error，再提出 hypothesis。若只看 loss，团队可能错误降低 learning rate；若只看 hardware log，又可能忽略特定数据触发的数值不稳定。所有 telemetry 必须使用一致 run/step ID，并保存 code/data/config version。

Dashboard 绿色不代表实验有效

GPU utilization、throughput 和 job status 可以全部正常，而训练目标已因错误 mask、污染数据、label shift 或 optimizer state 损坏而失真。Frontier program 需要 scientific invariants：held-out loss、gradient range、data distribution、checkpoint checksum 与 periodic evaluation。

Checkpoint、replay 与 resume

\term{checkpoint} 保存恢复训练所需的参数、optimizer state、scheduler state、random state 与 data cursor；它不同于 activation checkpointing，后者是在单个 forward/backward 内用重算节省显存。\term{deterministic replay} 尽可能用相同 code、batch 和 state 重现异常，以判断是 transient infrastructure fault 还是 recipe defect。

\lecturefigure{07-checkpoint-recovery.png}{训练恢复要保留科学含义：detect、checkpoint、replay、diagnose，再 resume 或修复。}{本地字幕 17:20--19:10；概念重绘。}

读图：恢复点必须包含 data cursor

只保存 model weights 会丢失 optimizer moments、LR schedule、randomness 和数据位置，恢复后曲线可能悄悄改变。Replay 若在同一 batch 再次 spike，优先检查 data/recipe；若换硬件后消失，可能是 transient fault；若无法重现，则要保留不确定性并提高监控，而不是宣布问题已解决。

\teachervoice{Mann 用“像看护病人一样看训练”说明 on-call 心态：loss curve 的异常可能在数小时后才显现，回滚又会损失昂贵进度。课堂里的重点不是戏剧化值班，而是训练本身已经成为需要 SRE discipline 的生产系统。}

本章小结

Training observability 把模型实验与系统运行连接起来。Loss spike 是入口，四类 telemetry、完整 checkpoint 与 controlled replay 才能把 anomaly 变成可修复知识。

Follow-the-Sun：全球值班不等于自动拥有清晰责任

长训练跨越时区，follow-the-sun 可以减少无人响应时间，但只有 handoff packet、明确 owner 和 stop criteria 才能避免重复操作。Frontier training 的难点是系统和研究责任交织：网络故障由 infra owner 处理，loss drift 需要 research owner，data corruption 又跨 pipeline 与 privacy owner。

Handoff packet 与 escalation

一个有效 handoff 至少包含当前 checkpoint/step、expected curve、最近异常、已验证 hypothesis、禁止重复的 action、pending experiment、下一决策 deadline 与 contacts。接班者必须 acknowledge 并复核 dashboard，而不是只读聊天记录。High-risk action，例如修改 optimizer 或跳过数据 shard，应要求双人 review。

\lecturefigure{08-follow-the-sun.png}{Follow-the-sun 依赖 active owner、handoff packet、接班确认与跨职能 escalation。}{本地字幕 19:00--21:20；概念重绘。}

读图：Coverage 与 ownership 是两件事

全球 coverage 保证有人在线，ownership 决定谁有权 stop、rollback 或 change recipe。若多个地区都能“顺手修”，run 会积累不可追踪变更；若所有人只观察，又会错过 recovery window。Handoff 应冻结当前 hypothesis 和 authority，重大变更写入 run ledger。

\teachervoice{讲者承认 follow-the-sun 也没有消除困难：有些 failure 模糊、偶发且跨研究/系统边界。课堂提醒我们，增加时区覆盖不是组织魔法，仍需共享语言、runbook 与明确 escalation。}

本章小结

全球训练运营的关键是 evidence transfer 与 decision rights。Handoff 质量决定 coverage 能否转化为更低 downtime，而不是更多并发误操作。

Post-Training：RLHF 与 Constitutional AI

Pre-training 提供广泛语言和世界知识，但不会自动产生符合产品意图的对话行为。Post-training 把 instruction、preference、principle 和 tool policy 注入模型。课堂从 RLHF 讲到 Constitutional AI/RLAIF，重点不是把 human feedback 完全替换，而是扩大监督规模并让行为目标更明确、可迭代。

RLHF：把偏好训练成 proxy reward

\term{reinforcement learning from human feedback}（RLHF）通常包含 supervised fine-tuning、human preference comparison、\term{reward model}（奖励模型）和 policy optimization。Reward model 学习预测人类更喜欢哪个回答，RL 再优化模型提高 predicted reward，并用 KL 等约束避免策略偏离过远。

\lecturefigure{09-rlhf-pipeline.png}{RLHF 把 demonstrations、preference、reward model 与 policy optimization 串成训练管线。}{InstructGPT；本地字幕 21:00--26:20；概念重绘。}

读图：每一层都有独立误差

SFT 受 demonstration 覆盖限制；preference 受 annotator/rubric 影响；reward model 可能在 distribution shift 下被 exploit；RL policy 可能提高 proxy reward 却损害真实 helpfulness。最终 human evaluation、safety evaluation 和 product metrics 不能被 reward curve 替代。

Reward hacking 是 proxy 问题，不只是算法 bug

任何有限 rubric 都无法完整表达“有帮助、诚实、无害且符合上下文”。模型可能学会讨好 judge、过度拒绝或使用表面风格获得高分。应使用多维 evaluation、adversarial examples、holdout tasks 和 policy review，避免单一 reward 成为唯一真理。

Constitutional AI 与 RLAIF

\term{Constitutional AI} 用一组原则指导模型 critique 和 revise 自己的回答，再生成 AI preference data；\term{reinforcement learning from AI feedback}（RLAIF）用 evaluator model 产生偏好或 reward signal。人类仍负责选择 principles、审计行为、处理冲突与决定 deployment boundary，AI feedback 负责降低每个样本都要人工标注的成本。

\lecturefigure{10-constitutional-ai.png}{Constitutional AI 用 principles、critique/revision、AI preferences 与 RLAIF 扩展监督。}{Anthropic Constitutional AI；本地字幕 26:00--27:40；概念重绘。}

读图：Base model capability 是前提

模型必须能理解原则、发现问题并提出更好 revision，CAI 才能工作；evaluator model 也可能共享 target model 的 blind spot。Principle 冲突、文化语境、过度拒绝与 hidden reasoning 都需要 human audit。RLAIF 扩大监督吞吐，不等于消除 human governance。

\teachervoice{Mann 把 Constitutional AI 描述为一个能力门槛后的突破：早期模型还不足以可靠 critique 自己，模型变强后才可能成为监督工具。这个例子说明 capability growth 也能创造新的 safety technique，而不是只增加风险。}

本章小结

Post-training 是多层 proxy 优化。RLHF 和 RLAIF 都需要清晰原则、独立 evaluation 与 human governance；它们改变行为，却不替代 base capability、system control 或 deployment safety。

Evaluation：Measured Capability 取决于 Elicitation

安全与能力评估看似是给模型出题，实际还包括 prompt、scaffold、tool、time budget、environment、judge 与统计不确定性。\term{elicitation}（能力激发）是通过合理 prompting、tool access、search 或 fine-tuning，让评估尽可能接近模型可达到能力。Elicitation 太弱会低估风险，太强又可能脱离真实 attacker/user 条件。

Task、elicitation、environment 与 judge

评估首先定义 construct：是在测 knowledge、planning、tool use、cyber/CBRN uplift 还是 harmful propensity；随后确定 elicitation budget 和权限；environment 应模拟真实 feedback 和 constraint；judge 则可由专家、人群或模型构成，并需要 rubric、inter-rater agreement 与 calibration。

\lecturefigure{11-evaluation-stack.png}{模型评估的分数由 task、elicitation、environment、judge 和 confidence 共同决定。}{Anthropic evaluation research；本地字幕 27:30--30:40；概念重绘。}

读图：低分可能是能力低，也可能是没激发出来

固定 prompt 的失败不能证明 model 无能力；允许无限工具和人工搜索的成功也不代表普通用户可复现。Evaluation report 应写 model/version、system prompt、tools、samples、search effort、judge、scoring 和 uncertainty，并区分 observed performance 与 estimated upper bound。

置信区间比单点分数更诚实

若 \(n\) 个独立样本中成功 \(k\) 次，经验成功率为

\[ \hat p=\frac{k}{n}. \]

其中 \(\hat p\) 是有限样本估计，真正能力 \(p\) 仍有统计区间；当高风险 gate 依赖极低 failure rate 时，几十个样本远远不足。还要处理非独立任务、prompt selection 与 evaluator bias，不能只报告整数百分比。

高风险评估不应泄露可操作细节

公开材料可以说明风险类别、评估框架、access control、red-team process 和 aggregate finding，但不应发布能显著降低有害行为门槛的具体流程、材料或绕过方法。Transparency 的目标是可问责，而不是把 evaluation set 变成能力教程。

本章小结

Evaluation 是 measurement system，不是题库。Elicitation、environment 和 judge 决定分数含义；高风险决策需要 uncertainty、external review 和版本化证据。

RSP：从 Historical ASL 到 Capability-Triggered Safeguards

课堂使用 AI Safety Levels 描述模型能力与防护等级的关联，并强调 defense in depth。当前 Anthropic RSP v3.0 已演化为 capability thresholds、required safeguards、risk reports 与治理流程。两版共同的 durable idea 是：随着 capability evidence 接近高影响 threshold，训练和部署必须先升级 security/deployment controls，而不是事后补救。

Threshold、safeguard 与 gate

团队先通过 evaluation、elicitation 与 forecast 形成 capability evidence，再判断离 threshold 多远；若达到或接近 threshold，就要满足对应 required safeguards，例如更强 model-weight security、access control、runtime guard、monitoring、red team、incident readiness 与 governance review；最后才决定继续训练、扩大部署或限制 access。

\lecturefigure{12-capability-safeguards.png}{能力证据触发 threshold review、required safeguards 与 deployment gate。}{课堂 ASL framing；Anthropic RSP v3.0；概念重绘。}

读图：版本变化说明 governance 需要可修订

课堂 ASL 把模型/防护分级绑定得较紧；RSP 后续版本把 capability threshold 与 safeguard package 拆开，以便针对具体风险更新。这个变化不是“旧版错误、新版正确”的简单替换，而是承认 evaluation science、threat model 与 safeguard evidence 会变化，因此 policy 本身也必须 versioned、公开变更并接受 review。

\teachervoice{讲者强调评估最难之处之一是 elicitation overhang：今天没测出来，不代表更强 scaffold、tool 或研究 effort 后仍做不到。课堂里的 ASL 不是给模型贴永久标签，而是要求组织在不确定性下提前准备防护。}

Defense in Depth

\term{defense in depth}（纵深防御）是设置相互独立、失败模式不同的多层控制。Training 通过 data/objective 与 post-training 降低危险行为；access 层限制谁能使用什么能力；runtime classifier/tool policy 监控请求和 action；response 层负责 red team、incident、patch、revoke 与 customer communication。

\lecturefigure{13-defense-in-depth.png}{Frontier model safety 需要 training、access、runtime 与 response 的纵深防御。}{本地字幕 37:00--39:10；概念重绘。}

读图：层数多不等于独立

若 training、classifier 和 judge 都依赖同一模型与同一数据，它们可能共享 blind spot。有效纵深防御要分析 common-mode failure、权限分离、监控独立性和 human override。每层都应产生 evidence 供下一层判断，并有明确 fallback，而不是把风险在层间循环转发。

本章小结

RSP 的核心是 capability-triggered governance。术语会变，durable contract 是：先评估，再满足 required safeguards，最后训练/部署；任何例外都要有 owner、证据与重新评估日期。

Mechanistic Interpretability：内部证据的希望与限制

Behavioral evaluation 只能观察输入输出，\term{mechanistic interpretability}（机制可解释性）尝试从 activation、feature 和 circuit 理解模型内部计算。Anthropic 的 dictionary-learning 工作把单个 neuron 的混合表示分解为更稀疏的 feature，为“某种概念何时激活、如何影响下游”提供研究工具。

Feature、circuit hypothesis 与 intervention

\term{feature} 是从高维 activation 中提取的可解释模式，不一定对应单个 neuron；\term{circuit} 是多个 feature/attention/MLP interaction 形成的计算路径。研究流程从 activation collection、feature discovery 到 behavior correlation，再用 ablation、steering 或 counterfactual intervention 检验因果。

\lecturefigure{14-interpretability-loop.png}{机制可解释性从 activation 提取 feature，形成 circuit hypothesis，再用 intervention 验证。}{Anthropic monosemanticity research；本地字幕 38:17--39:03；概念重绘。}

读图：可读 feature 不等于完整“读心”

Feature label 来自激活样本和人类解释，可能遗漏 polysemy、distributed representation 或 context dependency；circuit hypothesis 需要 causal intervention；局部解释也不能证明全局安全。Interpretability 更适合作为 evaluation、red team 和 anomaly investigation 的补充证据，而不是单独 release gate。

不要把 anthropomorphic label 当模型意图

“欺骗”“权力”“自我保护”等标签可以帮助检索行为模式，但模型内部 feature activation 不自动意味着持久目标或主观意图。报告应说明 operational definition、dataset、false positive、intervention result 和 alternative explanation。

本章小结

Mechanistic interpretability 提供内部 evidence，但仍处于研究早期。Feature discovery、causal validation 与 behavioral evaluation 必须相互校验，不能把一张 activation 图当成安全证明。

Compute Lifecycle：Pre-training、Post-training 与 Inference

课堂反对“pre-training 已经结束”的二元叙事。Pre-training 高效吸收广泛数据并建立 base capability；post-training 把行为、工具和安全目标聚焦；inference compute 通过 context、search、reasoning 或多次采样解决具体任务。三者的边际收益、latency、cost 和可控性不同。

不同阶段解决不同问题

Pre-training 适合摊销到所有请求的广泛能力；post-training 适合产品/政策行为；inference 适合按任务动态投入。若 base model 缺少知识或 representation，增加 inference token 可能只是更长地猜；若 post-training 不足，强 base model 也可能不遵循工具 contract；若 serving budget 太低，复杂 reasoning 又无法落地。

\lecturefigure{15-compute-lifecycle.png}{Pre-training、post-training、inference compute 与 product feedback 形成互补生命周期。}{本地字幕 34:40--36:50；概念重绘。}

读图：比较 total cost，不只看训练 FLOPs

一个模型的经济性包括训练摊销、post-training iteration、每请求 accelerator/time、context storage、cache、tool call 和 failure retry。更小 base model 加更多 inference search 可能适合低并发高价值任务；更强 base model 可能降低每请求步骤。选择应基于 target workload 与 SLO，而非阶段流行度。

本章小结

Frontier progress 来自 compute 在生命周期中的重新分配，而不是某一阶段永久取代另一阶段。Program 要用端到端 quality、cost、latency 和 risk 选择组合。

Chat Proving Ground 与 API Contract

最后一节把研究与产品连接起来。Chat experience 由供应商控制 UI、system prompt、tool、rollback 与 user education，可以快速试验；API 一旦被客户写进 production，schema、model behavior、latency、error、pricing 和 retirement 都成为外部 contract。正如课堂所说，“APIs are forever”不是字面永不变化，而是变化成本落在大量客户系统上。

从实验到 versioned primitive

Chat 中验证 PDF upload、long context 或 tool behavior 后，团队需要把隐式 UX 约束转成 API schema、auth、quota、idempotency、error model、version 和 docs。\term{API deprecation}（弃用）是宣布某模型或参数不再推荐，并提供 replacement、migration guidance 与 retirement date；retirement 后请求失败，因此客户必须在窗口内测试和迁移。

\lecturefigure{16-chat-to-api.png}{Chat 负责快速试验，API 则把成熟能力发布为长期兼容 contract。}{本地字幕 39:00--41:56；Anthropic API lifecycle docs；概念重绘。}

读图：Release 之前要补齐哪些证据

Chat experiment 先观察 usefulness、安全和 failure；evidence 形成 acceptance criteria；API release 固化 schema/version/SLO；lifecycle 提供 active、legacy、deprecated、retired 状态与 migration。客户 continuity 可能比“最新模型更聪明”更重要，因此 replacement 必须在真实 workload 上回归，而不能只看 benchmark。

\teachervoice{Mann 用 Claude 旧模型仍在某处生产环境说明 API inertia：客户可能没有工程资源迁移，也可能把旧行为写进合规流程。课堂提醒 frontier lab，发布 API 就等于接受 support、compatibility 和 deprecation 责任。}

模型升级不是普通 binary upgrade

新模型可能改变 refusal、format、tool call、latency、token usage 与 nondeterministic distribution。Migration 需要 golden tasks、safety regression、cost/SLO test、shadow traffic、rollback 和 customer communication；同名 alias 静默切换会让事故难以归因。

本章小结

Chat 与 API 的速度不同是合理的。Proving ground 帮助发现行为，API contract 要求版本化、可测试和可迁移；产品纪律是 frontier capability 成为基础设施的最后一步。

总结与延伸

本讲把 frontier scaling 从“模型越大越好”扩展为一套 research、systems、safety 与 product operating system：

  1. Scaling law 是预测合同：先用多尺度 run 做 fit 和 residual，再批准 frontier commitment；
  2. Compute multiplier 需要归因：model、data、optimization 与 systems 改动要在共同成本基准下验证；
  3. Rare failure 必须被设计进去：failure domain、checkpoint、replay 和 recovery tax 决定 useful progress；
  4. Training 需要四平面可观测性：model、optimizer、data、system telemetry 共同解释 anomaly；
  5. 全球值班需要 decision rights：handoff packet、owner 与 stop criteria 比“有人在线”更重要；
  6. Post-training 优化 proxy：RLHF/CAI/RLAIF 扩大行为监督，但都需要独立 evaluation 与治理；
  7. Evaluation 取决于 elicitation：task、tool、effort、environment、judge 和 uncertainty 决定分数含义；
  8. Safeguard 随 capability 升级：RSP 版本会演化，先评估、满足 required controls、再训练/部署的原则不变；
  9. Interpretability 是补充证据：feature/circuit 需要 causal validation，不能单独证明安全；
  10. API 是外部 contract：chat 可快速试验，API 必须 version、migrate、deprecate 与 support。

Frontier Model Program 作业

设计一个 8 周训练与发布计划：给出三档 pilot scale、loss fit 与 uncertainty；列出 workers/network/storage/scheduler failure budget；定义 checkpoint/replay 和 follow-the-sun handoff；画出 pre-training、RLHF/RLAIF、capability/safety evaluation、safeguard gate、chat canary 和 API release；最后给出 model deprecation、shadow traffic 与 rollback。每个 gate 必须有 owner、evidence 和 stop condition。

拓展阅读

{

}