第 4 章 失败应对与人工监督

学习目标

• 区分编造回答、拒绝、格式错误与临时故障，并针对每种类型设计预防措施和失败时的应对方案。
• 在重试、排队、替代路径、逐步降级、停用功能中，根据故障持续时间与功能特性选择适宜的应对策略。
• 以错误的可逆性、处理量以及高风险子集为基准，确定人工介入点（事前审批、条件转交、事后抽检、异议处理）。
• 为确保审核人员能够做出实质性判断，设计判断依据、修改与拒绝权限以及记录机制。
• 从法律义务与用户体验的双重视角，设计用户告知、信任校准、反馈机制与控制机制。

引言

某电商平台的 AI 客服机器人有一天给出了这样的提示：“本商品在购买后 60 天内可免费退货。”然而实际规定是 14 天。机器人没有报错，响应迅速，语气也十分亲切。系统的所有指标均显示正常，但数百名顾客却听信了错误的期限并采取了行动。AI 功能的失败通常就是这样悄无声息。

传统软件的失败往往以报错界面的形式暴露出来，而 AI 的失败则隐藏在看似合理的回答之中。因此，在规划 AI 功能时，必须包含两项核心工作：第一，按类型划分失败情况，针对性地减少各类失败的发生，并明确发生失败时的系统行为；第二，确定人在何时、以何种方式介入。OpenAI 建议尽可能在实际使用结果之前由人工进行审核，并强调在风险越高的领域，这一点越为关键。然而，我们不可能在每一个环节都安排人力，因此，规划的本质就在于权衡取舍，决定把人放在哪里。

本章首先剖析四种失败类型及各自的应对方式，探讨故障持续时的替代路径与逐步降级方案；随后梳理选择人工介入点的基准及赋予审核人员的权限；最后设计用户告知与反馈机制。

核心概念

失败是规划的一部分

AI 功能的失败大致可以划分为四种类型。

Google PAIR 指南还将错误划分为系统局限、上下文错误以及背景错误。其中，背景错误特指系统未能正常运行、但用户与系统均未察觉到错误的情况，编造回答便是典型代表。用户无法察觉的失败无法通过用户反馈来捕获，因此必须依靠前期设计与运营指标来捕捉。在制定应对方案时，临时故障还会根据持续时间进一步细分。仅需数秒即可恢复的故障与恢复时间未知的长期故障，应对策略截然不同，因此后文的应对表将这四种类型展开为五行来编写。此外，还有通过恶意输入绕过指令的提示词注入等安全失败。虽然本课程不作深入探讨，但如果是接收外部输入的功能，也应将安全审查结果一并纳入该应对表中。

编造回答

编造回答（幻觉）是指模型煞有介事地生成与事实不符或与给定上下文不一致的内容的现象。Claude 文档提出了减少此类现象的三项基本策略：

1. 允许回答“不知道”。 明确允许模型承认不确定性，可以大幅减少虚假信息。
2. 以直接引用作为依据。 处理长文档（Claude 文档中举例为 2 万 token 以上）时，先让模型原文提取相关语句，再基于该引用进行回答。
3. 通过引用进行验证。 要求每个论断都附带依据引用，并撤回找不到依据的论断。

高级技巧包括检查推理过程、多次运行同一问题并比较结果、让模型重新验证结果的迭代循环，以及限制模型仅使用所提供文档中的信息等。同一份文档明确指出，这些技巧虽能大幅减少编造回答，但无法彻底消除；对于关键信息，尤其是在高风险决策中，必须进行核实。

处理编造回答的方法因功能特性而异。对于有依据文档的事实指引，应将回答约束在引用范围内；若缺乏依据，则要求其说明无法确认。对于不涉及事实断言的创意发散任务，可在广泛生成后由人工进行挑选。对于依据文档也无法验证的物理现实判断等缺乏依据且一旦出错会导致不可逆损害的任务，则不应开发该功能，或转为对接专业人士。

拒绝与过度拒绝

模型不作回答有时反而是正确的行为。面对缺乏依据或存在风险的请求，回答“无法确认”是比编造回答更好的正常行为。此处包含两种失败情形：连本可以回答的问题也一并拒绝的过度拒绝，以及即便属于合理拒绝、却不提供任何后续操作直接中断对话的无引导拒绝。过度拒绝不会计入错误答案的比例（错误率），而在准确率指标中，如果不单独统计拒绝情况，其背后的原因也难以显现。因此，需要单独衡量可回答问题的拒绝率。过度拒绝会阻断用户体验流程，并将处理成本转嫁给人工客服或电话热线。

处理过度拒绝可以从两个维度入手。首先是减少其发生：收集本可回答却被拒绝的案例并加入评估集中，修改提示词或依据范围后重新评估。其次是即使发生拒绝，也要引导用户采取后续行动。PAIR 指南建议，应聚焦于失败后用户可以做的事情，在失败发生时让用户能够接手任务。例如，与其使用“无法回答”，不如表述为“在相关规章文档中未找到针对该问题的解答。相关菜单：○○，转接人工负责人：○○”。因缺乏依据而无法回答与因安全策略而拒绝回答，这两种情况的引导提示应有所区别：前者应为用户开辟其他替代路径，后者则简要告知原因，且不再诱导用户重复发起相同的请求。

格式错误

格式错误是指未遵守预定输出格式而导致的失败。如果输出面向人类阅读的界面，可能导致界面空白或乱码破损；如果输出需要传递给其他系统，则会导致对接失败。对接失败往往容易在无人察觉的情况下悄然累积，因而更具危险性。

Claude 文档指出，虽然使用结构化输出可以确保响应遵循 JSON Schema，但因安全原因被拒绝的响应（stop_reason 为 refusal）或因达到 max_tokens 而被截断的响应，可能并不符合 Schema。因此，应对策略应设立三重防线：

1. 通过结构化输出或严格工具调用（strict tool use，即强制工具名称与输入值遵循 Schema 的设置）来固定格式。由于字符串枚举值的大小写无法得到保证，比对时应不区分大小写。
2. 对接收到的结果进行 Schema 校验，一旦校验失败，严禁传递给下游系统。
3. 将校验失败的数据转入重新处理队列或降级至默认界面，并将该失败比例纳入运营指标进行监控。

临时故障与重试

模型 API 同样会出现故障。Claude 文档列举了 429（rate_limit_error，速率限制）、500（api_error，内部错误）、529（overloaded_error，临时过载）等错误代码。文档建议对内部错误采用指数退避重试机制；Anthropic 官方 SDK 默认会对连接错误、速率限制以及 5xx 等临时性故障自动进行最多 2 次指数退避重试，若存在 retry-after 响应头则遵照其指定时间执行。指数退避是指每次重试时，等待间隔按 1 秒、2 秒、4 秒等倍数逐渐递增的方式。

重试是应对短暂故障的恰当方式。对于数秒内即可解除的过载问题，通过拉大间隔重试几次大多可以解决；一旦超过设定次数，就应告知用户并提供替代路径。如果不对重试次数加以限制，用户将陷入无休止的等待，并且大量请求涌向处于故障中的服务器会导致情况进一步恶化。同一文档还建议，如果调用量突发激增，可能会因加速限制（acceleration limits，针对调用量激增施加的限制）而触发 429 错误，因此应当循序渐进地提升流量。

替代路径与逐步降级

当故障持续时间较长或恢复时间不可预知时，单靠重试是远远不够的。此时需根据功能特性采取不同的应对方案。

逐步降级（graceful degradation）是一种即使 AI 功能中断，核心业务也能通过更简单的路径继续运转的设计模式。例如，当 AI 推荐搜索中断时，回退到关键词搜索；当 AI 智能客服中断时，回退到常见问题解答与人工客服转接通道。NIST AI RMF 明确提出，对于偏离预期用途的表现或结果的 AI 系统，应设立替换、停用或关闭的机制，并明确相应责任归属（MANAGE 2.4）。这类机制必须在产品上线前就构建完备并进行充分测试。

各类失败应对表

失败应对方案应整理成一张清晰的表格。如果其中的单元格留白，就意味着一旦发生该类失败，谁也无法预料系统将会发生什么。

人工介入点

人工介入的方式大致可划分为四种：

选择介入方式的标准主要有三项：错误是否具有可逆性、处理量是否在审核能力范围内、风险是否集中在特定子集（如限制销售商品、大额资金、安全相关等）。Anthropic 解释称，智能体可以在检查点或受阻点暂停以等待人工反馈。产品规划者的职责，就是预先设定好这些检查点。

此外，还必须设计用户在等待转交人工处理期间的体验。设定审核的目标耗时，在此期间向用户展示处理进度，并制定超时未处理案例的应对规则（如追加分配处理人、执行安全的默认操作）。如果缺乏应对审核队列积压溢出的处理规则，人工介入就会演变为服务延误。

通常的做法是将多种方式组合使用。例如，面对日均数万件的分类任务，对触发风险条件的案例采用条件转交，其余数据则自动生效并辅以事后抽检，同时为对结果不满的商家提供异议申诉渠道。

审核人员的权限与依据

仅仅设置了人工审核环节，并不意味着监督机制真正发挥了作用。如果审核界面上只有 AI 的推荐结果和一个“确认”按钮，审核人员既无法修改推荐，也无法查看生成该推荐的原因。这种形式虽叫人工决策，实质上仍是全自动化。

要使审核发挥实质性作用，必须具备三项要素：

1. 判断依据。 审核人员能够查阅 AI 得出该结果的主要依据（引用的文档、纳入考量的项目）。
2. 处置权限。 审核人员拥有修改或拒绝该结果的权限，且其处理结果能真正生效落实。
3. 留痕记录。 完整留存修改与拒绝的理由，作为后续复盘检查与系统优化的资料。

NIST AI RMF 要求根据组织政策对人工监督过程进行定义、评估与记录（MAP 3.5）。韩国《人工智能基本法》（《关于促进人工智能产业发展与建立信任基础的基本法》）也规定，对于高影响人工智能——即在招聘、贷款审批等法定领域中可能对生命、安全与基本权利产生重大影响的人工智能（参见第 1 章）——提供此类技术或使用其提供产品与服务的人工智能经营者（开发经营者与运营经营者），在应当采取的措施中明确包含了人工管理监督机制、解释方案，以及编写并保存可核实措施内容的文档（第 34 条第 1 款）。即便是不属于高影响范围的常规客服机器人，切实的人工审核设计也是保障产品品质与用户信任的基础。

信任校准与置信度展示

用户对 AI 生成的结果无条件盲信或无条件怀疑都是不可取的。Google PAIR 指南指出，设计的目标是帮助用户正确校准信任，从而在特定情境下予以采信，而在必要时进行再次核对。

展示置信度水平有时确有帮助，但呈现方式至关重要。该指南警示称，以数值形式展示置信度带有预设用户能够透彻理解概率的风险；相对而言，更推荐展示多个候选选项，或将置信度划分为若干等级，并在每个等级中明确告知用户应采取的行动。如果置信度展示无法对用户的决策产生实质性影响，那么不予展示也是一种可行的方案。

用户告知

韩国《人工智能基本法》第 31 条提出了三项法定要求：拟提供基于高影响或生成式人工智能的产品与服务时，必须预先向用户告知该产品与服务是基于相关人工智能运行的事实（第 1 款）；提供生成式人工智能或使用其提供产品与服务时，必须标注输出成果系由生成式人工智能生成的事实（第 2 款）；提供与现实难以区分的虚拟音频、图像、视频时，必须以用户能够清晰识别的方式进行告知或标注（第 3 款）。具体实现方式与豁免例外由总统令规定（第 4 款）。

对产品规划人员而言，关键在于明确预先告知与成果标注在原则上属于两项各自独立的义务。进行了预先告知并不意味着可以免除成果标注的义务。具体方式与例外情形由实施令第 23 条规定。预先告知可通过载入服务条款、界面提示、服务场所张贴等方式进行；成果标注可采用人类可识别的方式或机器可读取的方式，若采用机器可读方式，则必须以文字或语音形式至少提示一次该内容系由生成式 AI 生成。若通过服务名称或界面文案已显而易见属于应用 AI 的情形，或仅用于内部办公用途等，可不适用本规定的全部或部分内容。除法律义务之外，PAIR 指南建议，在用户首次使用时坦诚说明产品“能做什么”和“不能做什么”，并重点阐述用户能获得的实际益处而非技术本身。因用户对功能边界产生误解而导致的抱怨（例如误以为正在查看实时信息等），不能单靠修改输出结果来化解，而应通过对齐预期来解决。

反馈与控制机制

用户反馈包含两种形式。按照 PAIR 指南的定义，隐式反馈是指留存在产品日志中的用户行为数据（如修改、重新生成、流失退出等），而显式反馈则是指用户主动留下的评价意见（如点赞/点踩、投诉举报等）。如果输出结果中只有局部内容频繁出错，允许用户直接修改结果并记录修改内容，既能减轻用户的使用负担，又能同步解决收集优化素材的问题。然而，用户的修改并不总是完全正确的，因此修改记录需经过审核筛选后，方可纳入评估集或作为模型优化材料。

控制机制同样必不可少。PAIR 指南建议，应允许用户根据自身需求调整或关闭输出，在初次引入 AI 时提供试用或关闭选项，并尊重用户不使用该功能的决定。OpenAI 提出，应为用户提供便捷举报不当行为的途径，且该举报须由人工进行监控并作出恰当响应。NIST AI RMF 同样建议设立反馈流程，使最终用户及受影响的群体能够报告问题并对处理结果提出异议（MEASURE 3.3）。

深入阅读

形式化审批的陷阱

虽然由人工审批全部结果的架构看似安全，但如果处理量过大且 AI 绝大多数时候都是正确的，审核人员就会逐渐不加核实地直接予以批准。如果每天每件只看几秒并处理数百件，且 99% 以上都按原样通过，那么这种审核就不是监督，而是流于签字。

这一陷阱会体现在数字上。应当定期查看审核人员的修改率（未按原样批准的比例）、单件审核时间，以及审核人员修改的内容是否确实有误。人类不假思索地全盘接受 AI 推荐的倾向被称为自动化偏见。如果修改率接近 0 且审核时间极短，通常代表两种情况之一：要么是 AI 确实极为准确而前置审批过于冗余，要么是审核人员缺乏判断的依据与权限而放弃了核实。对于前一种情况，可以通过条件式移交来减少审核量；对于后一种情况，则应改进审核界面。此外，还可以采用在部分结果中特意掺入已知错误的方法，观察审核人员能否将其识别出来。

自动切换至其他模型的陷阱

作为故障应对方案，经常有人提议“自动切换至其他供应商的模型”。仅从可用性来看这似乎合情合理，但策划人员需要确认三件事：第一，是否已针对该模型运行评估集，确认其达到质量标准。即便是相同的提示词，模型一旦更换，生成的结果也会改变。第二，是否存在允许将客户数据发送给该供应商的合同与处理条款。第三，延迟与成本是否在合同条件范围之内。

如果三者中有任何一项未能确认，自动切换不过是将故障转化为质量事故或违约事件而已。在这种情况下，降级运行或排队机制才是更安全的方案。若想设置备用模型，前提是平时就要对其一同开展评估并签署好协议。

免责声明不是应对措施

“AI 回答可能存在错误”这句声明虽然很常见，但其本身并不是失败应对措施。用户即便利读了该声明，仍然会相信答案并据此采取行动，而且该声明丝毫无法减少捏造的回答。法律所要求的告知（基于 AI 的事实、属于生成式结果的标识）与失败应对（引用依据、人工介入、替代路径）属于不同层面的工作。

告知是为了对齐用户的预期，而失败应对是为了减轻失败带来的损害。如果在策划案中把“添加免责声明”写在失败应对这一栏，那么这一栏实际上依然是空白的。

工作场景

瀚光镜片的度数咨询机器人

眼镜商城“瀚光镜片”运营着一款回答客户咨询的 AI 机器人。查看试运营记录后发现，共出现了三类失败：一是提供了镜片更换规定中所没有的“免费更换3次”的捏造回答；二是拒绝了诸如“如何输入度数”这类简单提问的过度拒绝；三是订单查询结果在 App 界面上显示为空白的格式错误。

策划人员按类型制定了应对策略。针对捏造回答，要求其引用更换规定文档中的原句作答，若无法找到引用内容，则显示“在规定中无法确认”并提供人工客服转接入口。针对过度拒绝，将 120 个被拒绝的问题加入评估集来修改提示词，修改完成后使用修改时未见过的保留问题重新测试拒绝率，并在拒绝时一并提供度数输入界面的快捷跳转链接。针对格式错误，将订单查询结果固定为 schema 规范，一旦验证失败，则转至默认的订单界面。

此外还有一项功能。曾有人提议由 AI 读取客户上传的验光单照片并将度数填入订单的功能。然而一旦度数读取错误，就会制作出不合度的镜片，而已制成的镜片是无法挽回的。该功能的处理量为每天 60 件。策划人员选择让客户将 AI 读取的度数与验光单并排对比确认，并在制作前由配镜师对每一件进行批准的前置审批方案。被弃用的方案是“置信度高的件自动制作”。因为每天 60 件的处理量完全在配镜师的全量查看能力范围内，而且哪怕置信度再高，一旦镜片做错也是无法挽回的。

聚珠工坊的商品审核

手工集市“聚珠工坊”计划利用 AI 审核每天新增上架的 8,000 件商品，以筛除违禁品（仿冒品、危险品）。人工审核力量每天可处理 250 件。

最初的提议是“由人工审核所有被 AI 怀疑的件”。但测试后发现，AI 怀疑的件每天达 900 件。策划人员划分了风险等级：疑似危险品的情况虽少见但危害巨大，因此全部转交人工审核；对于疑似仿冒品，置信度高的件自动暂缓上架，仅将置信度低的件转交人工；毫无疑点的商品则自动放行，之后每天抽检 50 件样本。这样一来，转交人工的件数缩减为疑似危险品 30 件、低置信度疑似仿冒品 140 件以及事后抽检样本 50 件，合计每天 220 件，完全控制在 250 件的审核负荷之内。对于被自动暂缓上架的商家，提供了可查看原因并申请复审的申诉通道。

审核界面也进行了改进。最初的界面上只有“疑似违禁”的标记和批准按钮。审核人员因不清楚怀疑的缘由，绝大多数情况下都直接按原样批准，第一周的修改率仅为 2%。策划人员随后改为将 AI 视作依据的商品名称、图片区域以及描述语句一并呈现，并在审核人员推翻判定时让其选择原因。审核人员在看到依据后开始切实纠正错误判定，第二周修改率上升到了 11%，而记录下来的原因也成为了下一个评估集的素材。

易错点

1. “加入‘回答不知道’的指令，捏造的回答就会消失。” 这只能大幅减少而无法彻底消除。重要信息必须配备验证机制。
2. “多次生成如果答案一致，就说明是事实。” 模型可能会重复相同的误解。一致性不能当作依据。
3. “拒绝是安全的，所以不算失败。” 过度拒绝会阻拦用户，并将服务成本转移给其他渠道，同样属于失败。
4. “使用结构化输出就不需要格式验证了。” 在触发拒绝或达到长度限制时，格式可能会偏离 schema。
5. “一旦发生故障，自动切换到其他模型即可。” 切换至未经验证或无数据处理协议的模型，会导致质量事故或违约风险。
6. “所有结果全由人工审批是最安全的。” 若处理量超出审核负荷就会流于形式化审批，且对于容易挽回的错误而言成本过高。
7. “只要有审核人员，监督机制就会起作用。” 如果缺乏依据、修改与驳回权限以及记录，监督充其量只是签字过场。
8. “附上免责声明就算是应对失败了。” 告知只是对齐预期，减轻失败带来的损害依靠的是系统设计。

要点速览

• 失败的四种类型：捏造回答（用户无法获知实情）、拒绝与过度拒绝（流程受阻）、格式错误（格式损坏）、暂时性故障（等待）。
• 捏造回答：允许“不知道”、直接引用、引用验证。只能减少，无法彻底消除。
• 格式错误：结构化输出 + 验证 + 失败件重新处理。拒绝和长度限制属于例外情况。
• 故障：耗时短则采用有限次数的退避重试，无实时需求则使用排队机制，耗时长则阶段性缩减，备用模型必须以预先评估和合同为前提。
• 人工介入：根据可逆性、处理量与风险子集，在前置审批、条件式移交、事后抽检、申诉机制中进行选择。
• 审核有效运作的前提是依据、权限与记录。利用修改率和审核时间来监控形式化审批。
• 置信度应以阶段与操作指引的形式呈现，对数值形式的置信度需保持谨慎。
• 韩国《人工智能基本法》第31条：事前告知与结果标识属于各自独立的义务。申诉举报窗口需由人工查看并答复。

查阅官方文档

• Claude Docs — Reduce hallucinations：基础与高级技巧，以及“无法彻底消除”的提示。
• Claude Docs — Structured outputs：schema 保证，以及拒绝与 max_tokens 的例外情况。
• Claude Docs — Claude API errors：错误代码、指数退避，以及 SDK 的自动重试。
• OpenAI — Safety best practices：人工审核、红队测试、举报通道与人工监控。
• Google PAIR Guidebook — Errors + Graceful Failure：错误类型、失败后的后续操作、归还控制权。
• Google PAIR Guidebook — Explainability + Trust：信任校准与置信度呈现方法。
• Google PAIR Guidebook — Feedback + Control：隐式与显式反馈、修改与关闭。
• NIST AI RMF — Core：MAP 3.5（人工监督）、MEASURE 3.3（举报与申诉）、MANAGE 2.4（替代·解除·中止）。
• 国家法律信息中心 — 韩国《人工智能基本法施行令》第23条：事前告知与结果标识的方法、适用例外。

自测

4-1. 请写出 Claude 文档中给出的减少捏造回答的三种基本策略。

4-2. 请说明过度拒绝为何无法通过错误回答的比例（错误率）体现出来，并写出处理过度拒绝的两个方向。

4-3. 在使用结构化输出的功能中，即便响应无报错正常结束，为何仍需保留验证步骤？请说明理由。

4-4. 在公文自动发送功能中，模型 API 已连续 30 分钟未响应。发送任务只需在明天上午前完成即可。在重试、排队机制、阶段性缩减中，哪一种方案合适？为什么？

4-5. 请写出人工介入的四种方式，并分别用一句话写明各自适用的条件。

4-6. 审核人员每天查看 500 件，平均每件用时 3 秒，且 99.8% 都按原样批准。请写出这一数字可能代表的两种情况以及各自应采取的措施。

4-7. 请写出韩国《人工智能基本法》第31条第1款与第2款各自的要求，并解释二者之间的关系。

4-8. （设计题）请为当前负责的 AI 功能撰写一份按失败类型划分的应对表（包含预防、检测、失败时动作、向用户展示的内容），共分五行。

实操练习