7.1 为什么技术人必须主动管后果
这一节要回答的问题是动机问题:本讲剩下的五节都要花在「怎么做」上——对齐、可解释、公平度量、风险清单、设计约束——所以在花这些时间之前,先得说清楚「为什么要做、为什么是做模型的人做」。
答案不是「因为做完模型会有风险」这么一句同义反复。真正需要拆开的是三件具体的事:能力与理解的时序关系(为什么风险总是事后才被发现);「技术中立」这个说法在什么条件下成立、在什么条件下失效(什么时候「我只负责实现」是诚实的,什么时候它是把成本推给别人);以及责任链上每一环到底能做什么(如果你不是最终决策者,你的义务边界在哪)。三件事串起来,才构成「主动管后果」这个动作的完整理由。
这一节不含新数学,但它决定了后面五节是「被要求做的合规动作」还是「你要主动设计的工程对象」。前者做完就停,后者才有迭代。
7.1.1 能力先于理解地增长
深度学习领域有一个反复出现的时间结构:先训出能用、好用的模型,事后才发现它在某些条件下会以不可接受的方式失败。 这不是某个团队的疏忽,而是这条技术路线的固有顺序:模型的行为由数据分布与优化过程共同决定,而这两者都不是人能逐条读完的——你只能通过评估去抽样观察行为,而评估的覆盖面永远小于部署的覆盖面。
于是「已知失效」与「未知失效」的关系不是「多测几轮就能清零」,而是永远不会清零。这带来一个工程上必须接受的结论:我们不追求「证明没有失效」,只追求「知道当前在哪些条件下会失效、失效的代价多大、出问题时能多快发现与回退」。第 7.5 节的威胁模型、第 7.6 节的监控与回滚,都是这条结论的直接产物。
设一个系统 由开发方 构建、由部署方 上线、作用于人群 。后果外化指: 的失效成本 主要由 (以及在链条上无决策权的第三方)承担,而不由 或 的决策目标承担。形式化地说, 实际优化的目标 中不含 的项:
外化不必是恶意的:它常常只是目标函数里没有这一项,而优化器只优化写进去的东西(这一点与 7.2 的对齐缺口是同一个机制在不同层级的表现)。
把外化读成道德指责没有工程价值——没人能优化一个没写进目标的项。它真正的意思是:成本已经从系统里流出去了,系统内部没有任何量在感知它。 所以「主动管后果」这个动作的技术内容,就是把 的一部分重新写进系统的设计约束:写成指标、写成门槛、写成回退条件(第 7.6 节)。做一个类比:延迟和成本原本也是外部的,「用户体验」与「云账单」最初没人优化;当它们被写成 SLO 与预算之后,工程才真正开始管它们。安全与公平要走的是同一条路——从「有人提过」变成「有指标、有门槛、有负责人」。
7.1.2 「技术中立」的边界在哪里
「技术本身是中立的」这种说法在有的时候是诚实的,在有的时候是推卸。要分辨,只需要问一句:这个中性成立的前提是什么?
一段技术工作可以被称为「中立」,当且仅当同时满足:
- 可替代性:如果我不做,别人能用同样的资源与知识做出等价的东西——即我的工作不是某个特定后果的必要条件;
- 用途不可预知:下游用途在合理的专业判断下不可预知,而不是「我不去了解」;
- 影响不集中在特定人群:失效成本不由特定弱势群体不成比例地承担。
三条中任意一条不成立,「中立」的说法就失去了它赖以成立的前提,此时「我只负责实现」在事实上等于把判断义务转移给没有决策权的人。
三条里第一条最容易自查,也最常被打破:当你拥有别人没有的算力、数据、权限或时间窗口时,「我不做自然有人做」就不成立了。这不是道德论断,而是事实判断——「可替代性」是一个关于资源分布的问题,可以具体讨论:算力来自哪里?数据来自哪里?许可来自哪里?如果这些条件是你所独有的,那么你在这条链上就承担了别人承担不了的份额。
第 2 条在工程上对应一个可执行的动作:在做之前问一次用途,在做之后留一次记录。不问则第 2 条自动失效——因为「不知道」是你自己选择的状态,不是环境的属性。
第 3 条要求一次分群分析。它把「中立」这个定性问题变成可以查表的问题:失效在子群之间的分布是什么? 这正是 7.4 分群评估要解决的问题。
下面三个情形里,技术人的「中立」是否成立?各自的最小义务是什么?
情形 A:你给一个公开的文本情感分类器写了一个开源实现,代码与权重都在公共仓库,任何人可下载。别人拿它去过滤言论,你事前不知道用途。
情形 B:你为一家公司开发了一个人脸比对服务,客户是物业与学校。你提供 API,客户自行决定用在什么场景。
情形 C:你负责一个招聘筛选模型的特征工程与训练,标签来自公司过去三年的录用记录,模型直接输出「进入 / 淘汰」,没有人工复核环节。
情形 A:三条大致成立——公开资源、可替代性强、影响分散且可被你无法控制的下游改变。最小义务:明确许可条款与已知局限(模型卡,见 7.6),在文档里写出失效条件(例如对反讽与方言的偏差)。这是「中立」成立情形下仍然必须做的事。
情形 B:第 2 与第 3 条不成立。用途不是不可预知——你明确知道客户是物业与学校,而这两类场景正是生物特征识别监管最集中的地方(见 7.4 的事实性概述);影响也集中在特定人群(被识别者)。你拥有的是生物特征比对这一能力与合规身份。最小义务:用途限制与合同约束(哪些场景不提供)、留存策略、默认不做人脸库(不做 1:N 检索而只做 1:1 验证)、可审计日志。这些不是「加一层过滤」,而是能力边界的主动收窄。
情形 C:三条全部不成立,而且这是最典型的后果外化(定义 7.1.1):失效成本落在被淘汰的应聘者身上,而你的目标函数里只有「与历史录用记录的吻合度」。历史录用记录是代理变量,它同时编码了岗位胜任度与历史歧视(7.4)。最小义务:把标签换成与岗位相关的胜任标准;做分群评估并把最差子群的指标写进上线门槛;保留人工复核与申诉通道;记录残余风险由谁批准接受。这里的义务是实打实的工作量,不是一句免责声明能覆盖的。
∎7.1.3 从模型行为到社会后果的责任链
确定了「中立不总是成立」之后,接下来的问题变得具体:链条上有哪些角色、每一环能做什么、义务分别落在哪。「谁负责」这种问法太粗,它会把责任稀释成「大家都有一点」,最后导致没人做具体动作。可操作的问法是逐环列出只有这一环能做的事。
一条典型的系统链条包含五个角色,每个角色的义务由它所独有的事实性优势决定:
| 角色 | 独有的事实性优势 | 只有它适合承担的义务 |
|---|---|---|
| 数据提供方 | 知道数据的来源、采集方式、覆盖与缺口 | 来源与授权记录、覆盖度与缺口说明、去标识化与最小化 |
| 模型开发者 | 知道结构、训练过程、评估覆盖面与已知局限 | 失效模式的识别与文档、评估口径(含分群与鲁棒)、红队、模型卡 |
| 部署者 | 知道真实使用流程、谁在什么环节看这个输出 | 用途限制、人机接口设计(是否可推翻、是否有依据)、监控与回退 |
| 使用者(操作者) | 知道眼前这个个案的具体情境 | 遵守使用边界、在越界情形转人工、上报异常 |
| 平台 / 基础设施 | 拥有分发、权限、速率与审计的开关 | 权限最小化、限速与配额、日志留存、可追责的技术底座 |
关键点:义务的分配依据是信息与权力的分布,不是「谁离得近谁负责」。每一环都有别人做不到的那件事——数据提供方查不了训练逻辑,模型开发者看不见部署流程,部署者读不懂特征工程。因此责任不能被集中,也不能被平摊。
这张表最常见的误用是拿它做「追责定位」——出事之后问「该谁」。「谁该」这个问句在工程上没有出口,因为每一环都会诚实地回答「我只能做到我这一环」。它的正确用法是事前找缺口:逐行问「这一环的那件事有人在做吗?有证据吗?」常见的缺口长这样:
- 没有人负责用途限制:开发者以为部署者会限制,部署者以为许可证里写了(但许可证不执行);
- 没有人负责分群评估:整体指标达标就上线,子群差异从没被算过;
- 没有人负责申诉:对外只有客服工单,没有人能复核模型的判断;
- 没有人负责回退:能上线不能下线,出了事故只能改参数再试。
第 7.5 节的威胁模型与第 7.6 节的检查清单,本质都是把这张表变成待勾选项。
7.1.4 三类失败模式:意外、滥用、系统性偏差
「失败」不是一个统一的类别。把失效按成因分成三类,是因为三类的对策几乎不重叠:一类靠评估与鲁棒性改进,一类靠能力边界与访问控制,一类靠数据与度量设计。混在一起讨论,就会出现「用红队去解决数据偏见」这类错配。
设系统的真实目标为 ,实际被优化的目标为 :
- 意外失效(accidental failure): 与 一致,但系统在未覆盖的输入或环境下行为错误。典型成因:分布偏移、分布外样本、对抗扰动、少见组合、传感器或数据管线故障。责任主体多为模型开发者与部署者,对策以评估与监测为主。
- 滥用(misuse):系统按设计正常工作,但被用于设计目标之外的目的,包括规避既有约束、放大伤害规模、绕过人工环节。典型成因:能力可被自由调用、权限过大、缺少用途约束与身份核验。对策以访问控制与能力设计为主,评估的作用是估计可被滥用的程度。
- 系统性偏差(systematic bias): 与 在人群维度上系统性偏离,且这种偏离在平均指标上不可见。典型成因:数据代表性、标注不一致、代理指标、反馈回路。对策以数据治理与分群度量为主,靠单次评估无法发现。
三者的关系不是并列清单,而是交叠的:一次事故往往同时包含两种(例如被滥用的能力恰好作用在分布外样本上,而被影响的又是一个历史样本稀少的群体)。用这张表的价值是保证三类都至少被检查过一次,而不是把每个失效强行归入一类。
三类里,意外失效最像「普通的软件 bug」,因此最容易得到「多测试就好了」这种回答。但它与前两类有一个结构差异:前两类的成因在系统之外(有人恶意使用、有人在数据里刻了历史),意外失效的成因就在模型内部,而且随分布漂移持续产生新的形态。 你把今天的所有已知失效都修完,明天换一个国家的输入分布、换一种设备、换一个季节,都可能出现新的意外。这意味着意外失效的对策必须有时间维度:不是「上线前测完」,而是「持续监测 + 定期重估 + 可回退」。这也是为什么 7.6 把监控与回滚单列为一节。
- 「伦理问题都是模糊的价值争论,没法工程化」:不对。本讲后面五节给出的全部是可测量对象——误差率、校准误差、分群指标、攻击成功率、回退时间。价值争论发生在选择哪一个准则这一层(7.4),一旦选定,剩下的全是工程。
- 「我只是训练模型,部署的后果不归我管」:把判断义务转移给了没有判断能力的一环。合理的做法不是承担全部责任,而是承担你独有的那一环(定义 7.1.3),并且把它写进文档让下一环知道你放弃的是什么。
- 「把名字、性别、种族这些字段删掉就没有歧视了」:删掉的是特征,不是信息。地址、邮编、就读学校、使用的设备型号、工作时长模式都可能成为受保护属性的代理变量(proxy)。判断是否消歧不能靠「字段列表里没有它」,要靠分群评估(7.4)。
- 「红队没找出问题,说明系统是安全的」:红队产出的是「在哪些攻击下会失守」。没找到问题只能说明没找到——它与「不存在」之间的距离,由红队的覆盖面与创造性决定,不由它的结论决定。
- 「这套东西是合规部门的事」:合规部门能读法规,但读不了你的损失函数。可执行的动作(写指标、加分群报告、设回退阈值)只有做过这套系统的人能定。把这件事外包,等于放弃定义「什么叫失败」的权利。
Q1 用 定义 7.1.2 的三条前提,判断下面这句话是否成立:「我在一个闭源大模型的团队里做数据清洗,模型怎么被用与我无关,因为即使换我做别的岗位,这个模型也会被训出来。」
Q2 定义 7.1.1 说外化常常只是「目标函数里没有这一项」。请举一个你熟悉的、曾经也被外化、后来被写进目标的工程量(非安全领域),并说明它是怎么被写进去的。
Q3 一个语音助手在听不清时会把好几种相近的指令混起来;某方言使用者因此被误触发。这属于 定义 7.1.4 的哪一类?需要什么证据才能确定它不是另一类?
参考要点
Q1 不成立,且失败点在第 1 条。可替代性的判断依据是资源分布:如果你所在的团队独占了这批数据与算力,那么「换别人也一样」这句话在事实上是假的——不是别人不愿做,而是别人没有条件做。此时「我只做清洗」不满足中立的前提。(注意:这不自动推出「你必须辞职」这种结论;它推出的是「你至少要承担你这一环可执行的那件事」——例如把代表性缺口写进数据卡,让下游知道模型在哪些群体上不可靠。)
Q2 参考答案:延迟与云成本。它们最初是外部的(用户体验与账单由别人承担),后来被写成 SLO(如 p99 延迟预算)和单位成本指标,进入需求、进入上线门槛、进入容量规划。写进去之后,工程上才开始真正优化它们。这一点是本讲的核心论点:不是「重要性驱动指标」,而是「指标驱动行动」。
Q3 表面上属于系统性偏差:某一方言群体被不成比例地影响,而整体识别率可能仍然达标,因此平均指标看不见。但要确认,需要三类证据共同出现:① 分群指标显示该群体误触发率显著更高(偏差证据);② 该方言在训练数据中的占比与采集方式(数据来源证据);③ 是否在听不清时的置信度低但仍被照常执行——若低置信度时应当澄清、实际却直接执行,那这里还叠加了一次意外失效(缺少拒答 / 澄清机制,见 7.3 的选择性预测)。只给出「用户投诉变多了」不构成分类依据。
- Amodei 等, Concrete Problems in AI Safety(2016,arXiv:1606.06565)——把「AI 安全」第一次拆成可研究的具体问题(副作用、奖励黑客、可扩展监督、探索安全、分布偏移),本讲的失效分类与它一脉相承。
- 欧盟《人工智能法案》Regulation (EU) 2024/1689 第 26 条(部署者义务)、第 27 条(基本权利影响评估)——把「部署环节也有独立义务」写进成文法的实例,原文见 Article 26 与 Article 27(核查于 2025 年,条款号以官方文本为准)。
- 本教程 第 6 讲 与 第 3 讲 3.2——前者的「偏好对齐只改行为、不改知识」与后者的偏置讨论,是本节两个具体机制的来源。
- 你所在项目的历史事故复盘报告(若有)——本讲所有抽象论述,最有效的检验方式是拿一份真实复盘逐条对,看它在哪一环出现了缺口。
本节小结:后果外化不是道德问题,而是「成本已流出系统、系统内没有任何量在感知它」的结构问题;「技术中立」有三条可自查的前提(可替代性、用途不可预知、影响不集中),任一条不成立就该承担你那一环的义务;责任链的分配依据是信息与权力的分布,每一环都有别人做不到的事;失败分三类(意外 / 滥用 / 系统性偏差),对策几乎不重叠。下一节进入第一条法则:当目标本身就是错的时候,我们能做什么。