附录 B 自测答案与解析

1-1. 智能体适用于难以甚至无法提前预测所需步骤数量的开放性问题。其代价是自主性带来的成本增加和错误累积的可能性，还必须综合权衡广泛的工具权限。因此，Anthropic 建议在沙箱中进行充分测试并设置适当的护栏。如果是步骤固定的任务，工作流则是更简单的解法。

1-2. 指南列举了六种情形：需要保持可预测性的任务、提供静态或受限信息的任务、必须最大程度减少高代价错误的任务、需要完全透明度的任务、快速且低成本构建最为关键的任务，以及人们重视并希望亲力亲为之事的自动化。在这类任务中，规则、检索和人工判断很有可能优于 AI。

1-3. 规则与查询更为合适。由于剩余座位数在预约系统中已有准确数值，因此只需轻量理解提问意图，并将查询到的值原样展示即可。若由生成模型将数字转述为句子，不仅没有任何收益，反而会带来数字转述错误的高风险和额外成本。

1-4. 应首先建立将访问记录录入系统的业务流程与存储结构。预测模型必须依赖历史记录才能构建，且必须有预期结果才能进行评估。在只有纸质登记册的情况下，即使着手开发，也无法对结果进行验证。

1-5. 韩国《人工智能基本法》第34条第1款要求建立并运行风险管理方案、在技术可行的范围内建立并实施解释方案、建立并运行用户保护方案、实施人工管理与监督，以及编写并保存可确认安全性与可靠性保障措施的文档等。此外，第31条第1款的事先告知规定同样适用，第35条第1款则规定应努力开展事前评估对人类基本权利影响的高影响人工智能影响评估。

1-6. 根据韩国《个人信息保护法》第37条之2第1款但书规定，若决定是基于同意、法律规定或履行合同等作出，拒绝权可能会受到限制。然而，个人信息主体要求对决定进行说明等的权利（第2款）及处理者据此承担的采取措施义务（第3款），以及公开决定的标准、流程和个人信息处理方式以便于查阅的义务（第4款）依然保留。根据施行令，处理者若无正当理由，必须提供包含决定结果、主要标准、处理流程等内容的简明且有实质意义的说明，或审查并告知是否采纳了个人信息主体提出的意见。拒绝权受限并不意味着免除整个条款规定的义务。

1-7. 答案因具体课题而异。优秀的解答应依次回答五个问题（是否可通过规则确定、是否直接展示原文即可、效益是否超过成本、是否有历史记录与预期输出、错误是否会导致不可逆的损害），并在首次命中的问题中得出六种结论之一（着手开展（自动化）、着手开展（辅助形式）、改变形态（规则与检索）、数据先行、搁置（维持现有方式）、不予构建）。若结论为着手开展，则应将准备评估集列为下一步行动。

2-1. 必须包含的四个要素是：测什么（指标）、在哪测（数据）、测到什么程度（基准值）、怎么测（测量方法）。缺少任何一项，他人都无法判定是否合格。若能在此基础上补充基线（与什么进行对比得出的数值），便可合理解释基准值为何设定为该数值。

2-2. 例如，应使用百分位数和时间上限进行表述，如“95%的线上请求首个 token 输出在1.5秒以内，完整响应在8秒以内结束”。对于用户在屏幕前等待的功能，应将决定体感延迟的首个 token 响应时间（TTFT）作为主要指标，将总时间作为辅助指标。在测量方法中，还必须明确测量位置（是基于包含网络延迟的用户设备端，还是基于服务器的 API 响应端），这样才能与开发团队保持一致的判定标准。

2-3. 精确率是指判定为正例的样本中实际为正例的比例，召回率是指实际正例中被成功识别为正例的比例。前者衡量“检出的结果有多准”，后者衡量“该检出的结果检出了多少”。

2-4. 必须保证精确率。因为识别出的内容会在未经人工确认的情况下直接导致预约取消，如果将非取消请求的短信误判，就会发生正常预约被删除的事故。而对于遗漏的取消请求，若工作人员后续重新查看短信或患者再次联系即可处理，其代价相对较小。

2-5. 当模型出于安全原因拒绝回答时（stop_reason 为 refusal），拒绝消息会优先于 schema 约束，导致输出可能不符合 schema。当输出达到 max_tokens 上限而被截断时，也会因结果不完整而无法满足 schema。因此需要建立校验与失败处理规则。

2-6. （A）银行账号残留比例会导致个人信息安全事故，因此属于上线阻断标准。（B）简洁度评分属于不影响正常使用的质量项，因此属于改进目标。（C）退款期限误写比例可能导致客户误信错误期限并采取行动而造成损失，因此属于上线阻断标准。

2-7. 优秀的解答应针对各种失败场景（无法回答、输入超出范围、依据不足、处理延迟、系统故障等），具体写明向用户展示的文案与后续行动（手动输入、相关菜单、转接人工、重试时机）。如果存在像“发生错误”这样未提供后续行动的空白项，则说明设计尚未完成。

3-1. 顺序依次为：定义评估目标、收集数据、定义评估指标、执行与对比、持续评估。前一步骤的结果是后续步骤的输入，因此该顺序不可调换。

3-2. 无关或不存在的输入、过长的输入；若是对话功能，还包括低质、有害或无关的用户输入，以及人与人之间也存在判定分歧的模棱两可案例。

3-3. 代码评分对于难以用规则表达的复杂判断缺乏对细微语境的理解，且难以识别与标准答案仅表述不同但实际正确的回答。LLM 评分的结果可能存在微小波动，因此必须先验证其可靠性，并与人工评分进行校准。人工评分质量高，但速度慢且成本昂贵。

3-4. 归还截止日期通过代码评分来检查是否与借阅系统中的数值完全一致。由于标准答案固定，这种方式最快且最可靠。引导语气由于没有标准答案字符串，应使用设定了评分量规（rubric）的 LLM 评分器进行打分，但使用前必须先与人工评分样本进行对照，确认一致性后再投入使用。

3-5. 能力评估用于观察模型将尚不擅长的事情做到了何种程度，通常从较低的通过率开始。回归评估用于观察模型是否持续稳定地完成此前已经擅长的事情，其通过率应接近 100%。当能力评估任务能够被稳定做好后，可将该任务“毕业”转移至回归评估包中持续运行，以此监控性能衰减。

3-6. 应怀疑针对开发集调整所导致的过拟合。虽然开发集上的指标提升了 23 个百分点，但在优化过程中未接触的保留集上仅提升了 2 个百分点，说明实际改善微乎其微。应以保留集的结果作为发布决策的依据，并通过研读仅在开发集上被修正的案例来排查原因。

3-7. 供人工从多个候选项中挑选一个的功能，只需在 k 次尝试中至少成功一次即可，因此适用于 pass@k。而客户每次都必须获得同等质量回答的功能，要求 k 次尝试必须全部成功，因此适用于 pass^k。

3-8. 优秀的解答应完整填写本章模板中的所有栏目，并针对每个成功标准写明评分方式（可与标准答案比对时采用代码评分，可通过量规判定时采用与人工对照校准后的 LLM 评分，需要专业判断时采用人工评分）及其理由。在评估集栏目中，应分别明确贴合实际比例的样本构成、边界用例包、高风险用例包，以及从各个用例包中独立划分出的保留集。

4-1. 允许模型表示“不知道”；先从长文档中直接提取原文引述作为依据；对每项主张通过引述进行验证，并要求撤回无法找到依据的主张。

4-2. 过度拒绝由于未提供错误信息，因此不会被计入错误回答的比例（错误率）。若以全部题目为基准计算准确率，拒绝也会被计为未答对从而导致得分下降，但如果不单独观测拒绝率，就无法查明该指标下降是否由拒绝引起。应对方向有两个：一是将原本可以回答的拒绝案例纳入评估集进行优化，以减少拒绝本身；二是即使拒绝回答，也要向用户提供相关菜单或转接人工等后续行动指引。

4-3. 根据 Claude 官方文档，结构化输出无法保证字符串枚举值（enum、const）的大小写，即使无错误或无特殊终止原因的正常结束响应中，也可能包含仅大小写不同的值。因此对于枚举值，应保留不区分大小写的比对校验。此外，由于存在因拒绝回答（stop_reason 为 refusal）或达到 max_tokens 而超出 schema 约束的情况，因此应同时设置终止原因检查与 schema 校验。

4-4. 采用队列更为合适。面对已持续 30 分钟的故障，仅进行几次重试并不合适，而发送操作并不需要实时完成，在次日上午前均有充裕时间。因此应先将请求保存在队列中，待系统恢复后再行处理，并向负责人告知预计完成时间。降级方案更适合于用户必须立即查看结果的功能中提供更简单路径的应对场景。

4-5. 事前审批适用于结果不可逆且处理量在人工审核能力范围内的情况；条件式转交适用于处理量大且风险集中在特定子集的情况；事后抽检适用于错误易于修正且造成的损失较小的情况；申诉处理则适用于结果对个人产生影响且当事人能够察觉到错误的情况。

4-6. 第一种可能是，AI 实际准确度极高，导致对每笔记录都进行事前审批显得多余。这种情况下，可缩减为仅将触发风险条件或置信度较低的记录转交人工的条件式转交。第二种可能是，审核人员因缺乏判断依据或修改权限而放弃实质审核，流于形式化审批。这种情况下，应在审核界面中增加依据展示、修改与拒绝功能以及原因记录。可以通过特意混入已知错误并观察审核人员能否识别，来区分这两种情况。

4-7. 第1款要求：拟提供利用高影响或生成式人工智能的产品或服务时，必须事先向用户告知该产品或服务基于相应人工智能运行的事实。第2款要求：提供生成式人工智能或利用其生成的产品或服务时，必须标识输出成果是由生成式人工智能生成的事实。两者属于相互独立的义务，履行其中一项并不代表可以免除另一项。

4-8. 优秀的解答应至少将编造回答、过度拒绝、格式错误、瞬时故障、长时间故障作为表格行，并在各行中填写预防措施（依据引述、拒绝案例评估、结构化输出、流量逐步递增、备用路径准备）、监测指标、失败时的应对动作、面向用户的展示文案与后续行动。如果某一栏只写了免责声明，则该栏不能算作有效应对。

5-1. 必须能够暴露问题、具有代表性，且能够归因于变更。

5-2. 影子测试不向用户展示新结果，因此无法衡量投诉举报、流失、转化等用户反应。若需要观察用户反应且属于易于回滚的变更，应使用金丝雀发布；若要对比两种方案对业务指标的效果，则使用 A/B 实验。

5-3. 小样本中出现的差异可能是偶然因素所致，无法据此判定是否达到了基准。若没有最小样本量，就可能因偶发噪声而执行回滚，或在缺乏依据的情况下盲目扩大至下一阶段。最小样本量是作出判定的前提条件。

5-4. 包含系统（错误、延迟、成本）、质量（依据引述比例、schema 校验失败、拒绝率、抽样评分）、用户行为（重新生成、转人工客服、流失、投诉举报）、业务（转化、节省成本）四个层级。从系统视角来看，编造的回答是作为正常响应输出的，因此错误响应率指标无法捕获任何异常。

5-5. 分别为 Active（完全支持，推荐）、Legacy（停止更新，后续可能停止支持）、Deprecated（仍可运行但不推荐，已指定替代模型与停用日期）、Retired（不可使用）。向已停用的模型发送请求将会失败。

5-6. 顺序依次为：阻断扩散（关闭、转交人工、回滚）、排查受影响人群并进行通知与更正、查明原因与修复（经回归评估确认后逐步重新开放）、记录、免责复盘、实施并验证防范复发措施。

5-7. 第一种类型为 50笔 × 4万韩元 × 流向客户的10% = 每月20万韩元，第二种类型为 1,200笔 × 2,000韩元 = 每月240万韩元。从月度损失来看，应优先解决第二种类型。但若第一种类型可能引发法律或安全问题，或是导致重大的信任受损，则需单独确认阻断机制是否充分。

5-8. 优秀的解答应完整涵盖上线范围、发布方式及选择理由、各阶段比例·周期·最小样本量、对照组、量化的终止基准、回滚方案（包含已处理的结果）、运行监控指标与告警、变更管理以及事故联络机制。若终止基准中未设定最小样本量，或对照组采用的是发布前后对比，则应重新修改。