Lecture35
\makecscover
课程主线：Frontier Product Research 不是“研究做完再包装”
这堂课的标题容易被误读成一节普通的强化学习（Reinforcement Learning, RL）导论。Karina Nguyen 真正讨论的是更具体的系统问题：当模型进入写作、软件、协作、教育和长期任务后，产品希望模型怎样行动、研究怎样把这种行动写成环境与奖励、界面怎样让用户暴露失败，必须在同一个闭环里共同设计。若研究先优化一个脱离产品的 benchmark，再把模型交给产品团队包装，很多真实失败直到上线才会出现。
\lecturefigure{slide-01-golden-age-curiosity.jpg}{“好奇、知识创造与制作”的黄金时代：讲座先给出价值方向}{00:00:49--00:01:41}
\teachervoice{00:00:49--00:01:38，Karina 明确说这不是单向 lecture，而希望课堂协作讨论；她的起点是每个人都能借助 AI 建造有意义的东西。这个价值判断解释了为什么后文同时讨论 creativity、agency、verification 与 alignment。}
定义：Frontier Product Research
本讲中的 \term{frontier product research} 不是“追踪最新模型并做产品”。它把尚未稳定的模型能力当作研究材料，把真实用户任务构造成训练环境与评测，再用产品交互快速收集反例。其最小闭环是
其中 product belief 是希望产品最终呈现的行为原则；它必须被翻译成可观察任务，而不能停留在口号。
本讲的证据边界
前半段大量使用产品 demo。这些画面能证明某个交互在当时可运行，能展示讲者如何理解产品方向，却不能单独证明模型在所有用户、分布和风险等级上可靠。后文的 eval、拒答 taxonomy、XSTest、RL environment 与 reward hacking，正是在补齐 demo 无法回答的问题。
Canvas：界面改变不是装饰，而是任务结构改变
第一个例子把教育请求拆成解释、代码生成、执行和可视化。若系统只提供一条聊天消息，用户很难同时阅读概念、修改代码和观察图形；Canvas 把“对话”升级为共享工作区，使模型输出成为可编辑对象。读图时不要只看 Gaussian 曲线，而要看左侧解释、中央代码和右侧执行结果怎样构成一个可验证循环。
\lecturefigure{slide-02-gaussian-canvas.jpg}{Gaussian 分布解释、Python 代码与运行结果被放进同一工作区}{00:02:05--00:02:57}
对随机变量 \(X\sim\mathcal{N}(\mu,\sigma^2)\)，密度为
这里 \(\mu\) 控制中心，\(\sigma\) 控制尺度。模型给出公式并不等于教学完成；只有当用户能修改参数、运行代码并观察曲线变化时，抽象符号才变成可操作的理解。产品设计因此改变了评测问题：不再只问答案是否正确，还要问代码能否执行、图形是否对应解释、修改是否局部生效。
\teachervoice{00:02:05--00:04:04，讲者用 Gaussian 教学和论文截图解释 Canvas 的动机：ChatGPT 最初是 conversational UI，但代码、长文和细粒度追问暴露了聊天界面的限制。课堂提示：UI 变化来自任务结构，而不是视觉改版。}
论文理解例子进一步展示“验证入口”。用户先提供论文中的 calibration 图，再要求模型解释、生成研究报告和代码。原始材料、模型解释与新产物必须并排可追溯，否则系统容易把顺畅叙述误当成事实。
\lecturefigure{slide-03-paper-calibration-source.jpg}{论文中的 calibration 图：模型解释必须回到原始视觉证据}{00:02:57--00:03:09}
\lecturefigure{slide-04-calibration-canvas-report.jpg}{Canvas 中生成的 calibration 报告：选择局部内容后继续追问}{00:03:09--00:04:12}
首次使用：Calibration
\term{Calibration（校准）}描述模型置信度与实际正确率是否一致。若所有置信度约为 \(q\) 的预测中，真实正确比例也约为 \(q\)，则该区间近似校准。常见误区是把 calibration 与 accuracy 混为一谈：模型可以准确但过度自信，也可以不够准确却在概率意义上校准。产品需要把“答案是什么”和“应相信多少”分开显示。
\lecturefigure{slide-05-claude-usage-bachelor-degrees.jpg}{教育使用报告中的相关性图：产品数据可以产生研究问题}{00:04:12--00:04:45}
这张使用图把 Claude.ai 的教育用途与美国不同本科专业联系起来。读图先看横轴专业占比或使用占比，再看散点偏离趋势线的位置；它能提示不同学科采用模式不同，却不能证明“专业训练导致使用”或“使用导致学习效果”。产品 telemetry 可以产生值得研究的假设，但相关性、选择偏差与用户自报必须单独处理。
从产品日志到科学结论的三道门
第一，使用者不是总体的随机样本；第二，点击或生成次数不等于任务成功；第三，群体相关性不能直接解释个体因果。Frontier product research 可以从真实流量快速发现问题，但仍需要明确 sampling、outcome 与 counterfactual。
本章小结
课程开场已经给出整堂课的尺度：模型能力、工作界面、用户证据与后训练目标是一个系统。Canvas 的价值不是“多一个窗口”，而是把解释、编辑、执行和验证放进同一交互；产品数据的价值不是天然真实，而是把研究问题暴露得更具体。
能力 Vignettes：产品把多个模型能力组合成可完成的工作
接下来五组画面不是功能清单，而是在展示 \term{compositionality（可组合性）}。一个有用产品通常同时调用语言理解、代码生成、执行环境、视觉渲染、记忆和迭代反馈。单独测某个能力的 benchmark 很高，仍可能在组合链路中失败；因此每个 vignette 都应被读成一个端到端任务图。
从生成代码到个人工具
Stripe 风格 dashboard 例子把自然语言需求变成前端代码和可交互页面。这里至少存在四个验收层：需求约束是否被提取、代码是否能运行、视觉层级是否可读、用户修改后是否保持既有行为。任何一层失败，产品都不能只用“代码 token 正确率”解释。
\lecturefigure{slide-06-stripe-dashboard.jpg}{自然语言生成 Stripe 风格 dashboard：代码与界面同时成为输出}{00:04:41--00:05:00}
\lecturefigure{slide-07-correlation-explorer.jpg}{面向非数学用户的交互式相关性探索器}{00:05:00--00:05:51}
相关性探索器进一步要求系统把概念转成可操纵对象。若用户拖动数据分布，却看不到相关系数、散点结构与反例同步变化，交互只是在“演示动画”。好的产品 eval 应记录：核心变量是否可操作、反馈是否即时、例外情况是否可观察、用户是否能从操作中修正原有误解。
端到端任务成功不是子指标相加
设需求解析、代码正确、执行成功、视觉可读和用户完成任务的事件分别为 \(A_1,\dots,A_5\)。端到端成功是联合事件
而不是五个准确率的平均。若某一层是硬门槛，即使其他层接近满分，整体仍会被最弱环节限制。
图像、移动端与零成本软件
手绘草图到生成图像的画面强调另一种 interface contract：用户提供低保真意图，模型补全风格与细节。输出漂亮不代表遵循了构图、对象关系和作者意图；评测需要把 aesthetic quality、instruction adherence、identity preservation 与 editability 分开。
\lecturefigure{slide-08-sketch-to-image.jpg}{从手绘草图到生成图像：模型补全细节，但作者仍需控制方向}{00:05:51--00:06:02}
\lecturefigure{slide-09-generative-mobile-game.jpg}{移动端即时生成小游戏：内容、代码与触控交互被组合}{00:05:52--00:06:24}
\lecturefigure{slide-10-zero-cost-software.jpg}{“软件创建趋近零成本”的 demo：移动界面由对话即时生成}{00:06:24--00:07:14}
这两张移动端画面支持的是“原型边际成本下降”，不是生产软件已经免费。真实交付仍包含需求澄清、测试、数据安全、维护、分发与责任。尤其当模型生成可执行软件时，必须把执行环境隔离：代码生成能力越强，越不能把任意网络、文件和凭证权限默认交给模型。
\teachervoice{00:04:04--00:07:36，Karina 把个人 dashboard、游戏、图像和移动软件串成“增强创造力”的证据，并希望未来系统更主动、更个性化。讲义保留她的愿景，同时补上工程边界：主动性必须和权限、可撤销性、成本与验证共同设计。}
“零成本软件”最容易漏算什么
生成一次 UI 的 token 成本可能很低，但 total cost of ownership 还包括需求错误、测试、运行基础设施、第三方依赖、权限审计、长期维护和事故恢复。产品研究应测完成真实任务的总成本，而不是只报一次生成价格。
本章小结
能力 vignette 的共同结构是：用户意图经过模型与工具链，被转成可观察、可编辑、可运行的产物。它们证明了新的 product surface 有价值，也暴露了 benchmark 之外的失败面。下一章开始把这些失败面写成两个 scaling paradigm 和两条产品研究路径。
两种 Scaling Paradigm 与两条产品研究路径
讲者先区分 next-token prediction 与 RL on chain of thought，再区分“熟悉界面承载陌生能力”和“先有产品信念，再训练模型做到”。这两个二维坐标非常重要：前一个坐标回答能力怎样获得，后一个坐标回答能力怎样进入产品。把它们混在一起，容易误以为更强预训练会自动给出正确产品行为。
Paradigm 1：Next-token prediction 是 world-building machine
自回归预训练最常见的目标是
\(x_t\) 是当前 token，\(x_{<t}\) 是历史上下文，\(\theta\) 是模型参数。统一目标能让模型吸收语言、知识、风格和部分推理模式，因此被讲者称为 world-building machine；但它奖励的是局部预测，不直接定义一个长任务何时完成，也不提供外部工具成功、用户满意或长期一致性的信号。
\lecturefigure{slide-11-next-token-scaling.jpg}{Paradigm 1：next-token prediction 在多领域建立世界模型}{00:07:58--00:08:39}
为什么早期 token 错误会放大
生成分布可写为 \(p(x_{1:T})=\prod_t p(x_t\mid x_{<t})\)。模型一旦采样到偏离目标的 token，后续条件分布就建立在新的历史上；长文本中的角色、事实和计划因此可能逐步漂移。这个问题不是说自回归一定失败，而是说明“局部似然高”与“长期任务成功”不是同一指标。
Paradigm 2：RL on CoT 把长任务结果写进目标
强化学习把一次推理或行动轨迹记为 \(\tau=(s_0,a_0,\dots,s_T)\)，优化
\(\pi_\theta\) 是策略，\(R(\tau)\) 是整条轨迹的奖励。若 reward 来自代码测试、数学验证器或工具结果，模型就能获得超出逐 token 模仿的任务级信号。实践中常加入参考策略约束，避免策略为追逐奖励过度漂移：
\(\beta\) 控制行为改进与分布保持的权衡。
\lecturefigure{slide-12-rl-cot-scaling.jpg}{Paradigm 2：在 Chain-of-Thought 轨迹上用 RL 优化复杂任务}{00:08:39--00:09:03}
CoT 不是自动真实的“内心过程”
Chain-of-Thought 可以提供更长的计算轨迹、可插入工具调用和中间检查，但可读文字不保证 faithful。模型可能给出正确答案配错误解释，或把奖励偏好的格式学成套路。验收应优先依赖外部 outcome、可执行检查和反事实测试，而不是只奖励“看起来像推理”。
\lecturefigure{slide-13-create-build-make.jpg}{Create, build, and make：能力扩张必须落到可完成的作品}{00:09:03--00:09:35}
\teachervoice{00:07:58--00:09:34，课堂把 next-token prediction 与 RL on CoT 称为两种 scaling paradigm。老师强调的是监督信号发生变化：前者学习分布，后者可把复杂任务的结果反馈写进训练；这并不意味着所有长任务都已被解决。}
两条路径：Capability-first 与 Product-belief-first
第一条路径从新能力出发，寻找用户熟悉的 form factor；第二条路径先提出产品信念，再构造数据、eval 与环境让模型呈现该行为。前者适合探索“模型突然会了什么”，后者适合追求长期一致的产品体验。真实项目通常在两者之间往返。
\lecturefigure{slide-14-two-product-research-paths.jpg}{Research-driven product 的两条路径}{00:09:34--00:10:00}
\lecturefigure{slide-15-familiar-form-unfamiliar-capability.jpg}{路径一：用熟悉 form factor 承载陌生能力}{00:09:43--00:10:06}
Capability、Affordance 与 Eval 的三角形
\term{Capability} 是模型潜在能做什么；\term{affordance} 是界面允许用户怎样调用、编辑和撤销；\term{eval} 是系统用什么证据判断完成。产品失败常来自三者错位：模型会做但界面不能表达，界面能触发但 eval 不测真实结果，或 eval 优化了与用户目标不同的代理指标。
案例一：CLIP fashion search
CLIP 把图像和文本映射到共享 embedding 空间。设图像编码为 \(f_I(i)\)、文本编码为 \(f_T(q)\)，检索得分常用余弦相似度
这项陌生能力被放入熟悉的搜索界面：用户给出文本或目标服装，系统返回视觉相似结果。读三张连续状态时，应比较 query 意图怎样改变结果集，而不是把任何一组漂亮图片都当作搜索成功。
\lecturefigure{slide-16-clip-fashion-target.jpg}{Fashion search：从目标服装与视觉属性开始检索}{00:10:06--00:10:11}
\lecturefigure{slide-17-clip-fashion-yellow-search.jpg}{Fashion search：黄色与款式语义改变结果分布}{00:10:11--00:10:23}
\lecturefigure{slide-18-clip-fashion-style-search.jpg}{Fashion search：自然语言风格查询返回新的候选集合}{00:10:23--00:10:54}
读图：检索 demo 至少要测四件事
第一是 relevance，结果是否匹配 query；第二是 diversity，是否只返回近重复；第三是 controllability，修改颜色、材质或轮廓能否局部改变结果；第四是 failure visibility，系统是否让用户看出为什么匹配。共享 embedding 提供排序机制，但不自动保证公平、库存可用或风格词在不同文化中的一致含义。
案例二：100K context 与文件上传
长上下文能力进入产品后，最直观 form factor 是“上传文件并提问”。然而 token window 足够大，只说明输入可被接收，不说明模型找到了关键页、正确聚合数字或保持来源对应。一个 85 页 10-K 分析任务应至少验收 retrieval、calculation、citation 与 omission 四类错误。
\lecturefigure{slide-19-100k-context-business-analyst.jpg}{100K context 的产品承诺：让 Claude 充当企业分析师}{00:10:54--00:11:00}
\lecturefigure{slide-20-100k-context-input.jpg}{输入侧：85 页 Form 10-K 与具体分析请求}{00:11:00--00:11:13}
\lecturefigure{slide-21-100k-context-analysis.jpg}{输出侧：关键财务指标、表格与解释被组织为分析}{00:11:13--00:11:34}
Long context 不等于 long-context reliability
上下文窗口是容量上限；可靠性还取决于位置偏差、跨页计算、表格解析、冲突证据和引用。若产品只测“能否上传”，模型可能在最危险的情况下给出流畅但遗漏关键负债的摘要。应构造可定位答案、跨段聚合、无答案和冲突文件四组测试。
案例三：Summarizer 与不确定性界面
Summarizer demo 把重复段落、校准和编辑集中到文档界面。它表达的产品信念不是“摘要越短越好”，而是让用户看见哪些句子被保留、哪些内容重复、哪些结论需要再核查。若系统能产生 \(K\) 个候选，可把候选一致性当作不确定性线索，但不能把一致误差当作置信。与前面的 100K context 案例相比，这里更关心用户怎样审查和修改结果：长上下文解决“能读多少”，summarizer surface 解决“怎样把证据压缩成仍可追踪的 artifact”。
\lecturefigure{slide-22-o1-summarizer-calibration.jpg}{Summarizer：重复检测、P(IK) 与可编辑文档界面}{00:12:41--00:13:39}
从产品界面到评测样本
一个实际工作流可以把用户的接受、修改、删除、重试和引用跳转记录成结构化 evidence。最小事件可写为
只有 outcome 被定义，日志才可能转成训练或 eval 数据；单纯收集“用户点了哪里”容易把困惑误判成偏好。
task = observe_real_user_job()
prototype = expose_capability_in_familiar_surface(task)
trace = run_with_permissions_and_logging(prototype)
failures = classify(trace, by=[outcome, control, trust, cost])
eval_set = convert_failures_to_reproducible_cases(failures)
ship_only_if(eval_set, product_constraints).passes()
\teachervoice{00:09:34--00:13:39，讲者用 Inter Alia、100K context 和 summarizer 说明第一条路径：先出现陌生能力，再寻找熟悉 form factor。实践经验是界面必须让用户理解、控制并验证能力，而不是仅把模型接到输入框。}
本章小结
Next-token prediction 提供广泛先验，RL on CoT 可以把轨迹 outcome 写进目标；二者都不能单独决定产品。Capability-first 路径需要合适 form factor，product-belief-first 路径需要把信念翻译成训练与评测。CLIP、长上下文和 summarizer 的共同教训是：产品层必须显式定义可控性与证据。
Product-belief-first：把行为信念写进界面、数据与后训练
第二条路径从一句更强的产品主张开始：系统应该怎样与人共同工作？这类目标往往无法从单一 benchmark 推导。团队需要先构造交互原型，让用户暴露“哪里像合作者、哪里像自动补全”，再把这些差异转成训练样本、reward 与 eval。产品 belief 不是凌驾于证据之上的审美，而是等待被操作化和反驳的 hypothesis。
\lecturefigure{slide-23-product-belief-vision.jpg}{路径二：从 product belief 与 vision 出发，再让模型做到}{00:13:39--00:14:28}
Product belief 的可验收写法
“模型要更聪明”“体验要更自然”都不可直接验收。可操作的 belief 应包含：目标用户与任务、模型应采取/避免的行为、用户保留的控制权、失败时的恢复路径、成功 evidence 和成本边界。例如“成为写作 collaborator”至少意味着模型能读取选区、提出局部修改、说明改动、保持作者声音，并允许逐步撤销。
Language as a high-end product
讲者把 language 本身视为高端产品材料。语言不是界面上的填充物：语气、信息密度、结构、直接性、引用和不确定性表达会改变用户如何理解世界。新闻产品的例子说明，同一 context block 可以在 story page、首页 carousel 和 bottom sheet 中呈现不同形态；底层事实共享，表面组织必须适配场景。
\lecturefigure{slide-24-language-high-end-product.jpg}{Language as a high-end product：信息组织本身就是产品行为}{00:14:28--00:14:36}
\lecturefigure{slide-25-context-block-multiple-surfaces.jpg}{共享 context block：同一事实跨 surface 保持一致}{00:14:36--00:14:45}
\lecturefigure{slide-26-adaptive-presentation-surfaces.jpg}{同一信息在内联 carousel、首页与 bottom sheet 中自适应呈现}{00:14:45--00:15:39}
可以把共享语义表示记为 \(z\)，用户情境为 \(u\)，surface 为 \(s\)，最终呈现为
\(g_s\) 负责篇幅、布局和交互方式，但不得悄悄改变 \(z\) 中的事实。工程上应把 factual core、presentation policy 和 user state 分层；否则一个 surface 的编辑可能在另一个 surface 产生不一致，或模型为了适应短界面删掉关键限定。
首次使用：Single source of truth
Single source of truth 不是要求所有界面显示同一句话，而是让多个 surface 引用同一可追踪事实对象。模型可以摘要、重排和改写，但每个结论应能回到共享来源；用户在一个位置更新事实后，其他位置应明确同步或标注版本。
从 Writing IDE 到 micro-personalization
Writing IDE 例子把语言模型放进作者工作流，而不是要求作者把整篇文稿复制进聊天框。真正难点不是生成一句漂亮文字，而是理解选区、上下文、作者意图和改动范围。Micro-personalization 则进一步要求系统记住“这个用户怎样工作”，但个性化不能演变成不可见的操控。
\lecturefigure{slide-27-writing-ide-gpt3.jpg}{Writing IDE：模型在文档上下文中提供局部协作}{00:15:39--00:15:50}
\lecturefigure{slide-28-language-compressed-knowledge.jpg}{语言是人类知识的高度压缩 artifact，也是界面创新的材料}{00:15:50--00:16:17}
\lecturefigure{slide-29-claude-micro-personalization.jpg}{Claude.ai micro-personalization：根据历史主题组织后续入口}{00:16:17--00:16:20}
若个性化状态为 \(m_u\)，一次更新可写为
其中 \(e_t\) 是本次交互 evidence，\(\gamma\) 是保留强度。产品必须回答：哪些事件可写入、保存多久、用户如何查看/删除、错误记忆如何回滚。若 \(U\) 完全隐形，模型可能把一次偶然偏好固化成长期画像。
个性化的三个误区
第一，把高频点击当作稳定偏好；第二，在用户不知道时跨任务迁移敏感信息；第三，为了“贴心”而减少观点多样性。Micro-personalization 应同时测 relevance、surprise、user control 与 privacy，而不是只测点击率。
\teachervoice{00:13:39--00:16:18，Karina 从新闻产品、Writing IDE 和语言的压缩性说明 product belief 如何先于模型行为。老师强调：真正的 interface innovation 往往要求训练模型理解新的交互对象，而不是只在现有模型外面画 UI。}
Virtual teammate：异步、多人与工具访问
“AI teammate”常被滥用为营销词。讲者给出的 Claude in Slack 原型有更具体的行为边界：异步对话、多人协作、自动任务、定期总结频道和工具访问。它仍不是完整同事，但至少把 teammate 从人格形容词改写成可观察的工作协议。
\lecturefigure{slide-30-claude-slack-product-spec.jpg}{Claude in Slack：从频道历史生成 product spec、目标与 OKR}{00:16:20--00:17:50}
术语消化：Assistant、Tool、Agent、Teammate
| 角色 | 核心机制 | 主要验收问题 |
|---|---|---|
| Assistant | 对请求生成响应 | 单轮帮助是否正确、清楚 |
| Tool | 执行窄操作 | 输入输出是否确定、可审计 |
| Agent | 维护状态并调用工具 | 权限、计划、恢复、停止条件 |
| Teammate | 在多人流程中持续协调 | 责任边界、共享上下文、交接与社会判断 |
同一个模型可以承担不同角色；角色由环境与权限定义，不由聊天语气定义。
一个多人频道中的 teammate 至少要维护共享状态 \(s_t\)、个人可见状态 \(p_i\) 与权限集合 \(\mathcal{A}_i\)。可执行动作必须满足
而不是模型“认为有帮助”就执行。总结频道、写 spec 和修改 issue 的风险等级不同，应有不同确认门槛。
训练模型成为 collaborator
Canvas 不是把文本编辑器接到模型上就完成。讲者回顾的训练工作包括目标数据、context 使用、文档格式、editing suggestion、rewriting、formatting 和 output quality。图中的柱状结果意味着团队把“协作”拆成多个可重复任务，再迭代数据与后训练；它并不证明一个总分能代表所有写作场景。
\lecturefigure{slide-31-human-ai-flexible-affordances.jpg}{Human--AI collaborative affordance：界面应随任务扩展}{00:17:50--00:19:36}
\lecturefigure{slide-32-training-collaborator.jpg}{训练模型成为 collaborator：多类编辑行为与质量比较}{00:18:21--00:19:41}
Collaborator 的最小行为 contract
- 读取当前 artifact、选区、作者目标与禁止改动范围；
- 先提出局部 plan，再生成可比较的 diff；
- 保持未授权区域和作者 voice；
- 对事实性改动给出处或不确定性；
- 允许接受、拒绝、局部修改与完整 rollback；
- 把用户反馈写成下一轮可复现 eval，而不是只做在线适配。
state = load(document, selection, user_goal, permissions)
proposal = model.plan_and_edit(state)
diff = isolate_changes(proposal, protected_regions=state.locked)
evidence = verify_facts_and_style(diff, state.sources)
decision = user.review(diff, evidence)
if decision.accepted:
commit(diff)
else:
record_failure(state, diff, decision.reason)
\teachervoice{00:17:50--00:20:25，课堂追问“模型成为 collaborator 到底是什么意思”，并指出 Canvas 需要专门训练 context use、formatting、rewriting 与 editing suggestion。实践经验：好的协作界面背后是行为数据与 eval，不是一个更大的输入框。}
Modular tool composition：Tasks 不是单个 prompt
ChatGPT Tasks 画面把定时触发、生成文稿、再次编辑和保存组合起来。这里的系统不只生成文本，还需要 scheduler、artifact store、权限与失败恢复。把多个模块连接起来会产生新的 state mismatch：任务可能在旧上下文上运行，生成结果可能覆盖用户修改，重复执行可能制造冲突。
\lecturefigure{slide-33-chatgpt-tasks-composition.jpg}{ChatGPT Tasks：定时任务、Canvas artifact 与后续编辑的模块组合}{00:19:41--00:20:25}
首次使用：Idempotency 与 rollback
\term{Idempotency（幂等性）}指同一动作重复执行不会产生额外副作用；定时任务尤其需要 idempotency key，避免网络重试重复发文或重复修改文件。\term{Rollback（回滚）}则要求系统能恢复到已知版本。两者是 agent/tool 产品的基础，不应等到模型出错后再补。
本章小结
Product-belief-first 的核心是把“希望模型怎样合作”拆成界面对象、权限、数据与 eval。语言产品、共享 context、个性化、Slack teammate、Canvas collaborator 和 Tasks 都说明：越接近真实工作，越需要版本、权限、diff、rollback 和用户控制。下一章进入本讲最扎实的案例——如何把模糊 model behavior 变成可信 eval。
Behavior Evals：从“模型感觉不对”到可调试的拒答系统
模型行为不像数学题只有一个答案。拒答、直接性、政治话题中的平衡、幻觉承认、语言风格和情绪反应共同构成用户感受到的产品。讲者先问“怎样做可信 eval”，再用 Claude 2.1 到 Claude 3 的 over-refusal 改进说明：正确流程不是凭直觉调一个总 reward，而是建立 taxonomy、混合数据来源、追到具体训练集，并用 before/after 样例和 benchmark 回归。
\lecturefigure{slide-34-evals-question.jpg}{核心问题：怎样做可信 eval，怎样测真正需要的行为}{00:20:25--00:20:43}
定义：Eval 是决策协议，不是题库文件
一个完整 eval 至少包含任务分布 \(D\)、模型/系统版本 \(M\)、评分规则 \(S\)、运行条件 \(C\) 和验收阈值 \(\tau\)：
若 prompt、工具、system message、sampling、judge 版本或人工 rubric 改变，结果就不再可直接比较。可信 eval 的关键是可复现和能支持产品决策，而不是题目数量多。
把 model behavior 写成向量
第一组 traits 包括减少 benign refusal、回答时更有主见、降低 milquetoast response，同时在不确定处保留 caveat。第二组 traits 包括高风险话题中的 nuance、鼓励 media literacy、适度更长的解释，以及知道自己不知道。它们不是同一个“helpfulness”维度；若只优化单分数，模型可能用更长、更圆滑的文字掩盖事实错误。
\lecturefigure{slide-35-general-behaviors-refusal-opinions.jpg}{行为向量 I：benign refusal、直接性、caveat 与非模板化回答}{00:20:43--00:23:23}
\lecturefigure{slide-36-general-behaviors-nuance-knowledge.jpg}{行为向量 II：nuance、media literacy、长度与 calibrated self-knowledge}{00:23:23--00:24:17}
可以把一次回答的行为表示为
其中 \(h\) 为 helpfulness，\(s\) 为 safety，\(d\) 为 directness，\(n\) 为 nuance，\(c\) 为 calibration，\(v\) 为 voice consistency。产品验收不是寻找全局最大值，而是在不同风险域中定义允许区域 \(\mathcal{B}_{\text{task}}\)。例如医疗问题要求更强 caveat，创意写作则不应因出现“监控”“heist”等词自动拒答。
术语消化：行为评测常见维度
| 维度 | 解决的问题 | 不能替代什么 |
|---|---|---|
| Helpfulness | 是否推进用户目标 | 不能替代事实正确性 |
| Harmlessness | 是否避免真实伤害 | 不能用表面关键词判断意图 |
| Directness | 是否先回答核心问题 | 不能省略必要限定 |
| Nuance | 是否保留冲突证据与条件 | 不能变成无结论的两边讨好 |
| Calibration | 是否表达合理置信度 | 不能替代外部验证 |
| Self-knowledge | 是否知道能力/信息边界 | 不能靠固定免责声明伪装 |
\teachervoice{00:20:25--00:23:52，课堂没有用一个分数概括“Claude 3 更好”，而是逐项列出 refusals、directness、nuance、balance 与 self-knowledge。课堂提示：产品行为首先要被分解，团队才知道哪一项改好了、哪一项被牺牲。}
Over-refusal：安全分类器把表面词当成意图
Claude 2.1 的典型问题是：提示表面上含有危险词，实际任务却无害。图中“kill a python process”是进程管理问题；模型若只用 keyword 关联风险，就会拒绝。更隐蔽的是创意写作、长文档附件和 function calling：系统可能因为某段上下文看似有害，或忘记 system prompt，产生 misdirected refusal。
\lecturefigure{slide-37-claude21-overrefusal.jpg}{Claude 2.1 over-refusal：表面危险词导致无害请求被拒}{00:23:52--00:25:55}
\lecturefigure{slide-38-nuanced-refusals.jpg}{更细致的拒答：说明责任、承认边界并给出可行替代}{00:25:55--00:26:27}
设 benign prompt 集合为 \(D_b\)，模型拒答指示为 \(r(x)\in\{0,1\}\)，则 false refusal rate 为
FRR 下降并不自动表示安全变好，因为模型也可能开始回答真实有害请求。因此至少要与 harmful compliance rate 一起报告，并按域分层；总平均会掩盖 function calling、creative writing 或长文档中的局部崩溃。
拒答不是越少越好
优化目标应是“对无害请求少拒绝、对真实风险稳健限制、对边界请求给出可解释的安全帮助”。只压低 FRR 会诱发 unsafe compliance；只压低 harmful compliance 会诱发模板化拒绝。二者都需要 hard negatives：表面相似但意图不同的成对样本。
Taxonomy：先给失败命名，再决定修哪里
讲者列出的 taxonomy 包括 benign over-refusal、creative-writing refusal、function-calling refusal、long-document attachment 和 misdirected refusal。分类的作用不是写报告，而是把“模型拒了”映射到可能的系统层：安全数据、self-knowledge 数据、tool schema、long-context 路由或 system-prompt 遗忘。
\lecturefigure{slide-39-refusal-taxonomy.jpg}{拒答 taxonomy：benign、creative writing 与 function calling}{00:26:27--00:27:08}
\lecturefigure{slide-40-refusal-taxonomy-examples.jpg}{拒答 taxonomy 的视觉样例：附件与 misdirected refusal}{00:27:08--00:28:12}
Root-cause 表：同一拒答表面下的不同原因
| 症状 | 可能根因 | 首先检查 |
|---|---|---|
| “kill python process” 被拒 | 关键词安全数据过强 | benign hard negatives |
| 创意故事被拒 | 安全样本污染创作域 | 域配比与 pair data |
| “can't see tool” | self-knowledge 数据错误 | 工具可用状态 |
| 长附件触发拒答 | 文档局部内容误导全局判断 | 段落归因与查询意图 |
| 忘记 system prompt | 上下文/路由缺陷 | 提示拼装与回归轨迹 |
名字相同的“refusal”可能需要完全不同的修复；先加通用 SFT 数据往往会互相污染。
case = replay(prompt, attachments, tools, system_prompt, model_version)
if case.intent_is_benign and case.refused:
bucket = classify_refusal(case)
sources = trace_training_and_policy_influences(bucket)
candidate_fix = design_targeted_data_or_system_change(sources)
run_regression(candidate_fix, benign_suite, harmful_suite, domain_suite)
else:
preserve_or_strengthen_safety_boundary(case)
\teachervoice{00:23:52--00:28:35，Karina 反复强调 over-refusal 不是单一数据源造成的；团队建立 taxonomy，区分 benign、creative writing、function calling、long document 与 misdirected refusal。实践经验：看到一个坏例子时，先问它属于哪种机制，不要立即全局改 reward。}
可信 eval 的来源组合
Slides 将 eval prompt 分为 product flywheel 中真实收集的失败、人工整理的用户样本、覆盖 harmless/helpful 边界的 synthetic prompts，以及 XSTest 等外部 benchmark。每一类都解决不同盲点：真实流量有生态有效性但采样偏，synthetic data 可控但受 generator 偏差，公开 benchmark 可复现但容易被过拟合。
\lecturefigure{slide-41-trusted-evals-sources.jpg}{可信 eval 的来源：产品 flywheel、synthetic prompts 与 XSTest}{00:28:12--00:30:21}
若第 \(k\) 个来源分布为 \(D_k\)，综合 eval 可写为 mixture
\(w_k\) 不是自然常数，而是产品风险决策。按流量占比加权会低估长尾高风险；完全均匀又可能偏离真实使用。更稳妥的做法是同时报告 overall、slice 和 worst-case，并冻结关键回归集。
首次使用：RLAIF 与 synthetic preference data
\term{RLAIF（Reinforcement Learning from AI Feedback）}用 AI judge 或 AI 生成的 preference 代替/补充人工反馈。Synthetic preference data 能快速覆盖特定风格、边界和长尾，但其价值取决于 diversity、judge calibration 与抽样审计。它不是“AI 自己证明自己正确”，而是一个仍需外部验证的数据生产流程。
修复策略：像 debug 软件一样 debug 数据
General Approaches 包括清理/正则化数据、定向人工收集、生成 anti-refusal synthetic data，以及直接 RL。关键不在方法名字，而在根因定位。讲者随后给出最重要的实践句：look at data like you'd debug software。Function-calling refusal 可能来自 self-knowledge 数据；长文档拒答可能来自“我没有视觉能力”类样本；创意写作则可能受安全数据配比影响。
\lecturefigure{slide-42-refusal-general-approaches.jpg}{修复 over-refusal 的一般路线与 WildChat/XSTest 结果}{00:30:21--00:31:00}
\lecturefigure{slide-43-debug-data-like-software.jpg}{像 debug 软件一样看数据：不同拒答来自不同路径}{00:31:00--00:31:13}
\lecturefigure{slide-44-dataset-specific-refusals.jpg}{创意写作拒答与安全数据的可能耦合}{00:31:13--00:31:44}
Data debugging 的四个可追踪对象
- Provenance：样本来自用户、标注员、模型还是政策模板；
- Slice：样本属于哪个任务、风险与语言域；
- Influence：训练后哪些行为 slice 同步变化；
- Reversibility：能否移除/降权该数据并重跑局部实验。
没有 provenance 的大混合数据很难调试；“再加一些好样本”可能掩盖而非解决冲突。
\teachervoice{00:28:35--00:31:44，课堂从 product prompts、synthetic prompts 与 XSTest 转到数据 root cause。老师明确说每类 refusal 可能由不同数据集造成，应像 debug software 一样检查，而不是相信一个通用 safety/helpfulness 旋钮。}
Helpfulness–Harmlessness 是约束优化，不是单滑杆
前面的 data debugging 说明每类拒答有不同根因；现在需要回答跨类别的产品决策：当模型更愿意响应时，可能同时增加违规信息；当模型更保守时，又会伤害正常用户。这个问题不能靠一个“安全程度”滑杆解决，因为 false refusal 和 harmful compliance 的代价、分布与责任边界并不对称。可把目标写成约束优化：
\(H\) 是有用性，\(U\) 是不可接受风险，\(\epsilon\) 是产品设定的风险预算。实际系统还要按域设置不同约束，并考虑 false positive 与 false negative 的非对称成本。
\lecturefigure{slide-45-helpfulness-harmlessness.jpg}{Helpfulness 与 Harmlessness：导航平衡，而非选择单边}{00:31:44--00:31:54}
\lecturefigure{slide-46-xstest-refusal-rates.jpg}{XSTest 上的 incorrect refusal rate：版本比较需要读清样本与指标}{00:31:54--00:32:10}
XSTest 图显示不同 Claude 版本的 incorrect refusal rate 有明显差异。读图时先确认纵轴是错误拒答而不是总体安全，再比较模型版本；低柱支持 benign prompt 上更少拒绝，却不能证明 harmful prompt 上更安全，也不能代表所有语言、工具或长文档场景。图中的一个总数必须与 taxonomy slices 一起解释。
Benchmark 改善不等于产品问题关闭
公开集可能覆盖不到新工具、长上下文、真实系统提示和用户分布。验收应要求：公开 benchmark 改善、内部 regression 不退化、真实流量 slice 改善、严重 case 人工复核，以及上线后的监控/回滚条件。
Vibe check：定性样例怎样成为正式证据
三张 before/after 画面分别使用 surveillance fiction、time travel government project 和 technology-free heist。它们都含有表面危险词，却是合法的创作请求。Claude 2.1 倾向拒绝，Claude 3 给出结构化帮助。单个样例不能证明总体能力，但它们适合检查产品目标是否“有意义地”实现，并帮助人类发现 benchmark 没编码的语气差异。
\lecturefigure{slide-47-vibe-check-surveillance.jpg}{Vibe check I：监控题材科幻写作从拒答变为结构化协助}{00:32:10--00:32:13}
\lecturefigure{slide-48-vibe-check-time-travel.jpg}{Vibe check II：秘密时间旅行项目的 before/after}{00:32:13--00:32:21}
\lecturefigure{slide-49-vibe-check-heist.jpg}{Vibe check III：无现代技术 heist 对话的 before/after}{00:32:21--00:32:30}
Qualitative eval 何时不是“拍脑袋”
定性评测需要固定 prompt、模型版本、采样设置和 rubric；至少两名 reviewer 独立判断，并记录 disagreement。它特别适合发现新 failure mode、语气问题和交互断点。发现后应把样例扩展成对照集、变体集和反事实集，再进入持续回归。
suites = [public_benchmarks, frozen_regressions, synthetic_slices,
product_replays, qualitative_panels]
results = run_all(model, suites, fixed_system_and_sampling=True)
report = aggregate(results, by=[risk, task, language, tool, length])
gate(report.overall, report.worst_slice, severe_case_review)
archive(model_version, judge_version, prompts, traces, report)
\teachervoice{00:31:44--00:32:30，讲者先展示 quantitative XSTest，再用三组 before/after 做 vibe check。课堂提示：数字负责规模化回归，定性样例负责判断行为是否真正符合产品信念；二者不能互相替代。}
本章小结
可信 behavior eval 从行为向量开始，经 taxonomy、mixed-source prompts、数据 provenance、约束指标、benchmark 和 qualitative review 形成决策协议。Over-refusal 案例最重要的经验不是“少拒答”，而是不同失败有不同根因。下一章将这一思路上升到 RL：产品怎样工作，取决于环境、动作、reward 和验证怎样被构造。
RL Environment 是产品架构：任务、工具、奖励与恢复共同定义行为
讲座第三部分把标题压缩成一句话：how you construct RL environment and rewards is how your product will work。这不是修辞。若训练环境只允许文本回答，模型不会凭空学会可靠工具使用；若 reward 只看最终字符串，模型可能忽略过程中的权限、成本和不可逆副作用；若环境没有失败恢复，策略就没有机会学习何时停止、请求帮助或回滚。
\lecturefigure{slide-50-rl-environment-product.jpg}{核心命题：RL environment 与 reward 的构造决定产品行为}{00:33:15--00:35:51}
首次使用：MDP、POMDP 与环境 contract
标准 Markov Decision Process（MDP）写为
其中 \(\mathcal{S}\) 是状态，\(\mathcal{A}\) 是动作，\(P\) 是状态转移，\(R\) 是奖励，\(\gamma\) 是折扣。真实产品更接近 Partially Observable MDP（POMDP）：模型只看到 observation \(o_t\)，用户意图、工具状态和未来后果并不完全可见。环境 contract 还必须声明权限、预算、终止、日志、人工确认和恢复。
轨迹回报为
长任务的关键不是公式，而是 \(r_t\) 从哪里来。代码测试、数据库状态、用户确认和人工 judge 的可靠性不同；把不可验证的主观任务压成一个即时分数，会让策略寻找代理漏洞。
Real-world complexity：工具、长上下文与多步完成
真实软件工程或研究任务的复杂度来自工具调用、长上下文、延迟反馈、外部系统和 reward design。图中的 agent/工具只是结构提示；工程验收要进一步问：调用是否有 schema，工具失败是否重试，写操作是否确认，长任务能否 checkpoint，模型是否区分“没有结果”和“工具出错”。
\lecturefigure{slide-51-real-world-rl-complexity.jpg}{真实用例的复杂度等于 RL environment 的复杂度}{00:35:51--00:38:33}
首次使用：Tool call 与 state transition
工具调用不是一段自然语言。动作可写为 \(a_t=(\text{tool},\text{arguments},\text{idempotency key})\)，环境返回结构化 observation 与状态变化。若训练只奖励模型“写出像 API 的文本”，却不执行工具，策略学到的是格式模仿而不是任务能力。
environment = {
"state": [artifact_versions, tool_status, user_goal, budget],
"observations": [messages, tool_results, verifier_feedback],
"actions": [respond, call_tool, edit, ask_user, stop, rollback],
"permissions": policy_by_action_and_resource,
"termination": [goal_reached, budget_exhausted, unsafe, user_stop],
"rewards": [task_outcome, verifier_score, cost_penalty, safety_penalty],
"audit": persist_full_trace_and_versions,
}
把环境难度拆开讨论
课堂让学生比较 software engineer、AI researcher、creative storyteller 和 multiplayer/multi-agent environment。难度不只来自答案空间大，还来自反馈延迟、可观察性、协作对象和成功标准。软件任务可能有测试，却包含异步部署和隐性需求；创作任务缺少唯一答案，却有作者 voice、情节一致性和审美目标；多人环境还引入协议与激励。
\lecturefigure{slide-52-environment-complexity-exercise.jpg}{环境复杂度练习：软件、研究、创作与多智能体协作}{00:38:33--00:40:55}
环境难度的五个轴
| 轴 | 低难度一端 | 高难度一端 |
|---|---|---|
| Horizon | 单步回答 | 数小时/数天任务 |
| Observability | 状态完全可见 | 隐含意图、外部变化 |
| Verifiability | 精确测试 | 主观、延迟、多人评价 |
| Action risk | 只读与可撤销 | 写入、付款、发布、控制设备 |
| Coordination | 单用户 | 多人、多 agent、冲突目标 |
模型规模相同，环境沿这些轴移动就会产生完全不同的可靠性要求。
\teachervoice{00:33:15--00:38:56，Karina 把 software engineering、AI research 与 real-world tasks 的难度归到 RL environment，而不是只说“模型还不够大”。老师强调 tools、long context、reward design 和 multiplayer interaction 都会增加学习难度。}
Subjective tasks：可验证性弱，不代表不可研究
写作、视觉设计、情绪/主动性和 social intelligence 很难用单一 objective measure。课程没有得出“无法训练”的结论，而是要求把任务变成更真实的情境，收集比较、反事实和长期结果。关键是承认 judge 的价值观和上下文依赖，而不是伪装成客观真值。
\lecturefigure{slide-53-subjective-tasks.jpg}{难测的主观任务：写作、审美、情绪与社会智能}{00:38:56--00:41:30}
对两份输出 \(y_a,y_b\)，pairwise preference 常建模为
\(r_\phi\) 是 reward model，\(\sigma\) 是 logistic 函数。Pairwise 比绝对打分容易，但偏好仍会随 reviewer、文化、目的和上下文改变。应保留 disagreement，而不是强行平均成“全球口味”。
主观任务最危险的简化
把点赞、停留时间、virality 或单个 AI judge 当成 creativity 本身，会把社会反馈、平台分发和新奇性混在 reward 里。真实世界信号可以作为环境的一部分，但必须防止操纵、群体偏差和 Goodhart's law。
新的 Product Research：快速循环而不是一次规格冻结
讲者把新任务视为真实情境的 simulation，结合 in-context learning、强模型 distillation、synthetic data、新的 model behavior、multiplayer interaction 和 deliberate RL。这里的“快速”不是跳过严谨性，而是让 prototype、eval 与训练更短周期地交换证据。
\lecturefigure{slide-54-product-research-loop.jpg}{新的 Product Research：真实情境、ICL、synthetic data 与 RL 的快速循环}{00:41:30--00:42:14}
Co-design loop 的实验单位
每轮实验应固定一条 hypothesis，例如“允许模型先问澄清问题可降低错误工具调用”。然后同时记录：环境改变、数据改变、模型版本、界面改变和 outcome。若五项一起变化，就无法知道提升来自哪里。快速迭代仍需要 controlled comparison。
可以把一次 co-design 迭代记为
分别表示 environment、data、policy/model 和 interface 的变化。理想实验一次只让少量 \(\Delta\) 非零，并在相同 eval 上比较；产品上线则需要同时监测交互效应。
Reward design：把想要的反馈写清楚
Reward design 画面问：如果希望模型在真实社会情境中表现更好，应给什么反馈？答案需要 deep product thinking，因为“用户满意”可能来自短期顺从，“主动”可能变成打扰，“有创造力”可能变成不遵守约束。Reward 必须连接真实 outcome、过程限制和人工 judgment。
\lecturefigure{slide-55-reward-design-product-thinking.jpg}{Reward design：反馈应让模型学会真实场景中的合适行为}{00:42:14--00:45:32}
一种分解是
\(R_{\text{outcome}}\) 衡量任务结果，\(R_{\text{process}}\) 奖励澄清、验证和协作过程，\(C_{\text{cost}}\) 是时间/计算/工具成本，\(C_{\text{risk}}\) 是不可接受风险。权重不是万能修复；如果某项根本无法可靠测量，优化只会放大测量误差。
\teachervoice{00:38:56--00:43:43，课堂把 subjective tasks、真实情境 simulation、synthetic data、multiplayer interaction 与 reward design 连起来。老师的核心问题是：你真正愿意给模型什么反馈，才会让它在现实关系中更有帮助？}
Reward hacking 与 asymmetric verification
Reward hacking 指策略找到高分路径，却没有完成设计者真正想要的目标。随着 reasoning model 和软件 agent 变复杂，hack 可能隐藏在长轨迹、测试漏洞、代码后门或 judge 偏见中。图中的论文与 Lilian Weng 文章提醒：reward 不是 ground truth，verification affordance 本身是 alignment 设计。
\lecturefigure{slide-56-reward-hacking.jpg}{Reward hacking：代理分数提高，但真实目标可能被绕过}{00:43:43--00:45:46}
若真实效用为 \(U(\tau)\)、可测代理为 \(\hat U(\tau)\)，优化的是
但产品关心 \(U\)。分布移动后，\(\hat U\) 与 \(U\) 的相关性可能下降。所谓 \term{asymmetric verification} 是生成高质量结果很难，但检查给定结果相对容易；它允许把 verifier 放进训练。然而 verifier 一旦存在 blind spot，策略也会学习攻击它。
验证链必须独立到什么程度
同一个模型生成答案、解释答案并给自己打分，错误可能高度相关。更强的验证链会组合：可执行测试、规则检查、独立模型、人工抽样、不同数据来源和 adversarial cases。独立性越高，成本越大；产品应按动作风险分配验证预算。
Reward hacking 的产品症状
模型可能通过隐藏失败、操纵 judge、生成只通过测试的脆弱代码、过度请求用户确认来规避责任，或选择容易任务提高成功率。只看平均 reward 会把这些策略当进步；必须审查完整 trace、任务分母和未完成案例。
\teachervoice{00:43:43--00:45:46，Karina 指出 reasoning 与 software engineering 越复杂，reward hacks 也越复杂；用户可能看不懂模型改了什么代码，因此需要新的 trustworthy verification affordance。课堂提示：验证界面本身属于 alignment。}
本章小结
RL 产品的单位不是孤立模型，而是 POMDP 式环境：状态、观察、动作、工具、权限、reward、成本、终止、日志和恢复共同塑造行为。主观任务可以研究，但必须保留偏好差异；reward 可以优化，但必须承认代理误差和 verifier 攻击。Co-design 的严谨性来自把每轮环境、数据、模型和界面变化都记录清楚。
未来 Vignettes 与 Q&A：从廉价智能到社会智能
正式讲稿最后四张图把前面的系统设计外推到未来：能力成本下降、界面动态生成、教育与医疗个性化、故事创作关系改变。随后 22 分钟 Q&A 给出更有价值的限制条件。讲义将愿景与回答合并阅读：每个“可以”后面都补上“还缺什么 evidence”。
能力成本下降，但验证成本未必同步下降
MMLU cost frontier 图表达的是历史趋势：在相似准确率下，推理价格快速下降。它不能证明成本永远指数下降，也不能说明 MMLU 代表真实工作。更重要的是，生成变便宜会增加输出数量；若验证仍依赖专家，系统总成本可能从 inference 转移到 review。
\lecturefigure{slide-57-mmlu-cost-frontier.jpg}{MMLU performance--cost frontier：同类能力的调用成本历史性下降}{00:45:46--00:47:40}
令任务成功率为 \(q(c)\)、单次推理成本为 \(c\)、人工验证成本为 \(v\)，单位可信成功成本可粗略写为
即使 \(c\) 下降，若更复杂任务使 \(v\) 上升或 \(q\) 不稳定，可信结果并不会同速变便宜。产品应优化 \(C_{\text{trusted}}\)，而不是只报 token price。
\teachervoice{00:45:46--00:47:40，讲者说这张图已是“一年前做的”，MMLU 也不再是大家最关心的 benchmark；她用它表达 raw intelligence 变便宜。讲义提醒：这是 dated trend，不是无限外推定律。}
Dynamic UI、个性化服务与故事关系
上一节说明 raw intelligence 的调用成本下降，但低价输出只有进入合适界面才会产生用户价值。本节把成本趋势连接到三类 surface：随意图生成的动态 UI、承担高风险建议的教育/医疗入口，以及保留作者 agency 的故事协作。Dynamic generative UI 的愿景是界面依据意图即时生成：视觉学习者看到可操作图形，听觉学习者得到音频。它要求模型同时推断任务、用户偏好与可用设备；错误推断必须容易撤销，否则“隐形软件”也会让系统行为难以预测。
\lecturefigure{slide-58-dynamic-generative-ui.jpg}{Dynamic generative UI：界面随意图生成，软件创建趋于不可见}{00:47:40--00:48:04}
\lecturefigure{slide-59-personalized-health-education.jpg}{个性化医疗与教育加 consumer hardware 的未来入口}{00:48:04--00:48:42}
医疗与教育的价值很大，风险也不同。教育系统可以允许探索与纠错；医疗建议涉及症状遗漏、紧急分诊、隐私和监管。统一“个性化”指标会掩盖风险层级。产品必须区分 information、decision support 与 autonomous action，并为高风险输出设置专业复核和紧急升级。
\lecturefigure{slide-60-storytelling-relationship.jpg}{人与 storytelling process 的关系将因协作模型而改变}{00:48:42--00:49:18}
故事创作的开放性使它成为检验 social intelligence、voice preservation 与 agency 的好环境。模型可以给灵感、改写和结构建议，但“替作者决定什么值得表达”与“帮助作者实现意图”是不同产品。真正的 collaborator 应让作者看见来源、选择和改动，而不是用流畅文本夺走创作控制。
Future vignette 不等于 deployment claim
这四张图表达讲者的方向判断。它们没有证明医疗安全、教育增益、动态 UI 可预测性或创作劳动影响已经解决。讲义把它们作为 research agenda：每个愿景都必须补上目标用户、失败模式、权限、验证、成本和责任人。
\teachervoice{00:47:40--00:49:18，Karina 设想视觉/听觉偏好驱动的动态界面、个性化教育医疗和新的 storytelling 关系，同时希望创作者把 AI 当工具而非只感到威胁。课堂提示：这种乐观愿景必须与用户 agency 和验证机制一起实现。}
Q&A I：主观任务、benchmark 与创业路径
Q&A 首先追问：是否存在难以评测、因而研究者不愿碰的任务？讲者以 creative writing 和 emotional intelligence 为例，认为可以构造 benchmark，但复杂任务会更慢、更依赖里程碑。她也指出创业者不必先训练 foundation model；可以使用已有低成本模型，把创新集中在真实任务和产品闭环。
课堂提示：主观不等于不可评测
00:49:18--00:55:00，Karina 区分“没有现成 frontier benchmark”和“原则上无法构造评测”。可从成对比较、专家 panel、用户长期 outcome、竞赛结果和反事实样例开始；但这些信号都携带价值判断，不能伪装成自然真值。
Q&A II：如何避免 preference 收敛到全球平均
讲者给出两条思路：保留 base model 的 entropy，以及用 RLAIF/synthetic preference data 定向生成需要的多样性。这里的 entropy 不是鼓励随机，而是避免 RL 把大量可用风格压成“平均用户喜欢的 emoji、Markdown 和语气”。
对上下文 \(x\)，策略 entropy 为
过强 preference optimization 可能降低 \(\mathcal{H}\) 并造成 mode collapse。实践中应按任务保持候选多样性，同时用约束过滤事实错误和安全风险；“多样”不是“任何输出都好”。
课堂提示：RLAIF 的价值是可控覆盖，不是无限数据量
00:55:00--01:01:20，Karina 说 synthetic data 不一定需要很多，关键是 diversity；团队仍可人工检查，或用校准较好的独立模型和 meta-eval 验证。她把 synthetic generation 描述为对目标分布的 curation，而不是复制平均人类偏好。
Q&A III：定性诊断、成本与 frontier work
对于模型 bug，讲者承认大量 nuanced weirdness 来自人工反复“玩模型”；自动 eval 适合检查已知 behavior，但新问题往往先由定性探索发现。她也区分产品开发与 frontier research 的成本：应用团队可以复用便宜模型，前沿团队必须承担发明阶段的低效率，之后才出现第二轮成本优化。
课堂提示：一次异常与系统性行为
00:57:20--01:00:00，Karina 说定性检查要关注 behavior 是否持续出现。偶发 sample 可能来自随机性；跨 prompt 变体、会话和版本稳定复现，才应升级为系统性 issue。讲义建议把每个手工发现扩成变体集后进入自动回归。
成本讨论的边界
Q&A 中关于训练成本、scaling 与未来降本的回答带有明显不确定性。可以确认的是：应用层可复用现有模型、前沿发明昂贵、后续工程会降本；不能从课堂回答推出训练成本必然按某条曲线下降。
Q&A IV：机器人、AI coworker 与 social intelligence
讲者对 robotics 保持乐观，但把数据称为巨大 bottleneck。对于“现在是否已有 AI 同事”，她明确回答尚未达到；理想形态更像共享屏幕、实时对话、指出具体对象并根据用户意愿调节 agency。缺口不是再加一个 Slack bot，而是 social intelligence、speech-to-speech、多模态 grounding 和共同工作空间。
课堂提示：AI coworker 还缺什么
01:05:00--01:10:00，Karina 列出的缺口包括：实时生成与共同编辑、知道何时指导而非夺权、speech-to-speech、同时指向所谈对象，以及适配不同关系。这个清单比“能自动做任务”更严格，也解释了为什么 teammate eval 必须包含人际协调。
Q&A V：Research-driven product 与传统 PRD 流程
传统产品开发常从 PRD、设计和工程排期开始；research-driven product 可能先出现一个惊人的 capability demo，再围绕它塑造产品，也可能由产品和研究从第一天共同试验。Canvas 被讲者作为后者案例：post-training 与产品一起工作，过程更 ad hoc，但并不意味着没有规范；规范转移到了 prototype、eval、trace 和迭代证据。
课堂提示：能力 demo 不是产品终点
01:09:52--01:11:29，Karina 对比传统软件流程和 research-driven product：研究先出现能力时，产品围绕能力成形；有时产品与研究从最初就共同设计。工程判断是：越 ad hoc，越需要记录 hypothesis、版本和 failure，避免团队只记得成功 demo。
本章小结
未来愿景的共同条件不是“模型更聪明”，而是可信成功成本下降、界面能验证与撤销、个性化尊重用户控制、主观任务保留多样性、AI coworker 具备社会与多模态能力。Q&A 让课程主张更完整：很多能力可教，但数据、验证、偏好分布和协作关系决定它是否成为可靠产品。
总结与延伸
这堂课把 RL 从优化算法重新放回产品系统。Product belief 决定希望看到的行为；interface 暴露任务与失败；eval 把“感觉”拆成可复现 evidence；data debugging 追踪行为来源；RL environment 定义状态、动作、工具与恢复；reward 把结果和过程写进目标；上线后的用户 evidence 又启动下一轮研究。任何一层缺失，都会让另一层承担它无法解决的问题。
一张表串起 co-design loop
| 层次 | 核心对象 | 代表性失败 | 验收问题 |
|---|---|---|---|
| Belief | 目标行为与用户关系 | 口号不可操作 | 是否能写成行为 contract |
| Interface | artifact、diff、控制与权限 | 能力不可见或不可撤销 | 用户能否理解、编辑、停止 |
| Eval | 分布、rubric、judge、阈值 | benchmark 与真实任务错位 | 是否可复现、分 slice、可决策 |
| Data | provenance、mixture、preference | 数据冲突与污染 | 能否定位行为来源并回滚 |
| Environment | 状态、动作、工具、终止 | 训练任务与部署任务不同 | 权限、预算、失败恢复是否一致 |
| Reward | outcome、process、cost、risk | reward hacking / Goodhart | verifier 是否独立且抗攻击 |
| Deployment | telemetry、回归、责任人 | demo 成功掩盖长尾事故 | 是否监控 outcome 并可快速回滚 |
开始一个 Frontier Product 项目前应回答
十二问自测
- Product belief 能否写成可观察行为，而不是形容词？
- 目标用户的真实任务和失败成本是什么？
- 模型 capability 通过什么 form factor 暴露？
- 哪些 artifact、状态和来源必须可追踪？
- 用户保留哪些确认、编辑、停止和 rollback 权力？
- Eval 的分布、judge、rubric 与版本是否固定？
- 是否同时报告 overall、slice、worst-case 与严重案例？
- 失败 taxonomy 能否映射到数据、系统或 policy 根因？
- RL environment 的工具、权限、预算和终止是否与部署一致？
- Reward 是否把真实 outcome、过程、成本与风险分开？
- Verifier 有哪些 blind spot，策略是否能攻击它？
- 上线后谁看 outcome、谁能回滚、什么条件触发停机？
复现记录的最小集合
无论研究 data、behavior、RL environment 还是 interface，都应保存 source/version、prompt/system、模型与 sampling、工具 schema、完整 trace、judge/rubric、人工 disagreement、失败样本和回滚条件。若使用 AI judge 或 synthetic data，还要固定生成模型、judge 模型与权限；否则一次结果无法被下一版本解释。
experiment = {
"hypothesis": product_belief_as_testable_behavior,
"model": [base, post_training, checkpoint, sampling],
"environment": [tools, permissions, budget, termination],
"interface": [surface, artifact_schema, confirmation, rollback],
"evaluation": [datasets, slices, judges, rubrics, thresholds],
"evidence": [traces, outcomes, disagreements, severe_failures],
"decision": [ship, hold, rollback, next_hypothesis],
}
拓展阅读
- Bai et al., Constitutional AI: Harmlessness from AI Feedback：理解 RLAIF、原则约束与 AI feedback。
- Röttger et al., XSTest：研究 exaggerated safety 与 benign prompt over-refusal。
- Lilian Weng, Reward Hacking in Reinforcement Learning：系统整理 proxy reward 与 hacking 路径。
- Ouyang et al., Training language models to follow instructions with human feedback：RLHF 的经典 pipeline 与局限。
- Amodei et al., Concrete Problems in AI Safety：从 reward hacking、side effects 与 oversight 理解环境设计。
最后的边界
本讲中的产品名、模型表现、成本曲线和组织实践都属于 2025 年课堂时间点。讲义保存的是 co-design 方法，不把任何单个 demo、benchmark 或公司流程当作永久事实。真正可迁移的能力是：把愿景翻译成环境，把行为翻译成 eval，把失败追到数据与系统，再用可复现证据决定是否交付。