📚 首页 / 12-evaluation-observability/questions / exam-style.md

模块 12 — 考试题型（Exam Style）

题干中文、考试术语保持英文。答案与逐项解析在文件末尾「答案与解析」独立小节。

单选题

🎯 学习重点：优先识别定义边界与唯一最佳实践，不被看似“更全面”的错位术语干扰。

官方对一次评估（eval）基础结构的定义包含四个部分，它们是：

A. Input prompt、Output、Golden Answer、Score B. Query、Document、Embedding、Ranking C. System prompt、User message、Tool call、Tool result D. Task、Trial、Grader、Harness

机票预订 agent 在对话结尾说「您的航班已预订成功」。按官方术语，判断「任务成功」应依据：

A. Transcript 里出现了预订确认话术 B. Outcome：预订系统数据库里存在该预订记录 C. LLM-as-judge 对话术礼貌度的评分 D. 用户在会话中点击了「满意」按钮

三种评分方法的官方推荐优先顺序是：

A. Human → LLM-based → Code-based B. LLM-based → Code-based → Human C. Code-based → LLM-based → Human（human 少量用于校准） D. 三者等价，按团队人数分配即可

官方对 Regression Evals 的期望通过率与语义是：

A. 低通过率，用于测量新能力上限 B. 接近 100%，分数下降即「有东西坏了」的信号 C. 50% 左右，用于区分难度档次 D. 不设阈值，只看趋势斜率

per-trial 成功率 75%，跑 3 次 trial 全部通过的概率（pass^3）约为：

A. 75%　B. 56%　C. 42%　D. 98%

LLM-as-judge 的官方技巧不包括以下哪一项？

A. 详细清晰的 rubric（如「第一句必须提到 Acme Inc.，否则判 incorrect」） B. 让 judge 先在标签内推理再输出结论，然后丢弃推理 C. 给 judge 提供信息不足时返回 "Unknown" 的出口 D. 用同一个 judge 实例一次性评完所有维度以保持一致性

前沿模型在某道新题上多 trial 全挂（0% pass@100），官方认为最可能的原因是：

A. 模型能力不足，应换更大的模型 B. 任务规格或 grader 坏了（如缺文件路径的歧义任务） C. temperature 设置过低 D. 上下文窗口不够大

官方 reduce-hallucinations 文档中「长文档（>20k tokens）先摘原文引语再作答」的目的：

A. 减少 output token 成本 B. 把生成锚定在文档原文上，降低幻觉 C. 提高检索的 recall@k D. 绕过 prompt caching 的限制

TTFT（Time to First Token）最相关的场景是：

A. 批量离线处理任务的总吞吐 B. Streaming 场景下用户感知的响应速度 C. 每次调用的输入 token 计费 D. 训练时的收敛速度

用户反馈（thumbs-down、bug report）作为评估信号的主要短板是：

A. 无法暴露团队没想到的问题 B. 与产品目标完全不相关 C. 稀缺、自选择、偏严重问题，且很少说明失败原因 D. 不能作为回归测试的题目来源

「把所有召回的块全塞进上下文，recall@100 = 100%」这个案例说明：

A. recall 是最重要的检索指标，应优先最大化 B. recall 单看会被「全库塞入」式方案作弊，须与 precision@k / nDCG 同看 C. nDCG 不适用于 RAG D. recall@k 与 k 无关

官方 develop-tests 文档对成功标准的四条要求是：

A. Specific、Measurable、Achievable、Relevant B. Fast、Cheap、Scalable、Reproducible C. Precise、Robust、Automated、Frequent D. Simple、Modular、Testable、Observable

多选题

🎯 学习重点：逐项核对评分器、数据集和线上信号是否满足各自成立条件。

关于 Tool Correctness（工具正确性）的代码级检查，符合官方做法的有哪些？

A. required 工具是否被调用（如 verify_identity / process_refund / send_confirmation） B. 参数是否合规（如 process_refund 的 amount ≤ 100） C. 严格校验所有工具调用的固定顺序，任何顺序变化都判 FAIL D. 禁止类工具（如金额超限时的 process_refund）未出现在调用记录中

防止系统「过拟合到评测集（overfitting to the eval set）」的有效机制包括：

A. 题目分布贴近真实生产分布，并保持线上失败回流换血 B. 用同一份题目既调参又汇报最终成绩 C. 双向平衡：同时测「该做 X」与「不该做 X」 D. 汇报用 held-out 子集，调参用开发子集

LLM-as-judge 上线前应完成的校准动作包括：

A. 与人类专家对同一批样本打分并对比分歧 B. rubric 修改后重新校准 C. 让 judge 强制二选一，禁止返回 Unknown D. 系统稳定后仍定期人工抽检复核

官方 agent 评估示例（YAML）中 tracked_metrics 覆盖了：

A. time_to_first_token 与 time_to_last_token B. output_tokens_per_sec C. n_turns / n_toolcalls / n_total_tokens D. 用户次月留存率（retention）

判断题

🎯 学习重点：警惕“永远、只需、完全替代”等绝对化表述。

判断：Groundedness 高的回答一定是正确的回答（证据支撑 ⇒ 事实正确）。

判断：官方建议评估「优先题量、配合可自动化的略低信号评分」，而不是少量精雕的人工题。

场景决策题 S1（评估体系设计）

🎯 学习重点：最佳方案需同时覆盖真实题源、确定性 grader、CI 门禁与线上回流。

Scenario：你是某 B2B SaaS 公司的架构师。公司的客服 agent（Claude + 工具集：查订单/验证身份/处理退款/升级人工）已上线 3 个月，月均 4 万会话。近两个月做了三次 prompt 改版与一次模型小版本升级，每次上线后客服团队都会零星抱怨「某些场景变差了」，但复现困难；目前唯一的「评估」是上线前让两名内部同事手工试 15 个问题。财务要求季度成本不超预算；客服总监要求退款场景零事故。你现在要为公司设计第一套正式评估与可观测体系。

Constraints：

工程资源有限：只有 1 名工程师 × 4 周可投入；
历史工单数据丰富（3 个月、上万条真实会话与用户投诉）；
退款类工具调用有金额上限规则（≤100 自动处理，>100 必须升级人工）；
无法每次发布都跑大规模人工评审；
线上已有基础日志（每次调用的 token 数与耗时）。

Options： A. 直接采购全功能 LLM 评估平台，把所有历史会话导入，让平台的 LLM judge 自动给每次会话打一个综合质量分，按总分告警。 B. 从历史工单与失败会话提炼 100–200 道金标题（重点覆盖退款/升级规则，双向平衡），全部用代码 grader（state_check + tool_calls 断言 + 少量 LLM judge 评语气），做 capability/regression 两套件接 CI；线上对高风险（>100 退款被自动处理）100% 拦截审计、常规流量按周分层抽样人审，加改写率/接管率逃逸指标与 Usage & Cost API 成本日报。 C. 先攒 6 个月数据，用统计方法训练一个专有质量预测模型，取代一切人工与规则评分；期间沿用「上线前 15 题手工试」。 D. 只做线上：不建离线金标集，靠生产监控（错误率/延迟/token 成本）+ 用户 thumbs-down 告警发现所有回归。

Best choice：B。

Why：

题目来源正确：官方路线图第一步就是「从 bug tracker / support queue / 手动测试清单收集任务」，3 个月历史工单是现成、分布最真实的题库（来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents，访问于 2026-08-30）。
评分器选型正确：退款场景有明确终态与规则 → state_check + tool_calls 断言（amount ≤100、先鉴权后打款、>100 必须走 escalate）全部可代码化，符合官方「deterministic graders where possible」；只有语气类留 LLM judge 且必须带 rubric 与 Unknown 出口（来源同上；https://platform.claude.com/docs/en/test-and-evaluate/develop-tests，访问于 2026-08-30）。
双套件 + CI 门禁直接治好「改版后零星变差、复现困难」：regression 套件近 100% 红线，任何 prompt 改版/模型升级先跑套件，把「感觉变差」变成「哪层哪个 task 掉了」的定位（来源同上）。
4 周/1 人可交付：题量优先（100–200 道）+ 代码评分为主，评分的永续成本几乎为零（官方「量优先于质 + 自动化评分」原则，develop-tests 与 building-evals cookbook）。
线上闭环符合官方「自动化评估 + 生产监控 + 定期人审」组合：高风险工具调用全审对应退款零事故诉求（应用层强制，呼应模块 11：LLM 指令 ≠ 应用层强制）；改写率/接管率是业界通用逃逸代理；Usage & Cost Admin API 官方支持成本监控与告警（来源: https://platform.claude.com/docs/en/manage-claude/usage-cost-api，访问于 2026-08-30）。

Why others are weaker：

A：单个综合质量分 = 本模块头号反模式「只看平均分」——分层劣化被平均掩盖（退款安全 +20、任务成功 -15 可能总分不动）；LLM judge 未与自己的人工对表校准就决定告警，judge 本身的幻觉无人把关；全量历史会话导入评分的成本高且大部分低风险流量没有信息量。
C：把评估建立在「预测质量的模型」上是二次抽象：训练数据来自哪里（还是需要人定 ground truth）？预测模型自身的正确性谁来评？6 个月空窗期内每次改版仍在裸奔，违背官方「start early」；15 题手工试不满足 Measurable 标准。
D：纯线上监控没有 ground truth、被动（问题先到用户），官方明确 production monitoring 「reveals real behavior but lacks ground truth for grading」且问题是 reactive 的；thumbs-down 稀疏、自选择、偏严重问题——它捕捉回归的延迟以周计，而 CI 金标集以分钟计。

Tradeoffs（选 B 的代价）：

前期 4 周投入与持续维护（题目回流、套件毕业轮换、judge 季度校准）——评估是活资产不是一次性项目；
LLM judge 评语气仍需少量人工校准预算（每周抽检），无法完全零人审；
代码 grader 对「合法变体」偏脆（如先查订单再鉴权的新路径可能被误判）——需按官方「评产出不评路径」原则只硬校验业务规则型顺序；
CI 门禁会拖慢发布节奏：紧急热修需定义豁免流程（事后补跑）。

What would change the answer：

若工具与终态难以程序化校验（如纯开放式咨询机器人，无 state 可查）→ 评分器重心移向「LLM judge + 更高频人工校准」，A 的「平台化」吸引力上升（但仍必须分层指标而非单一总分）。
若历史工单数据匮乏（新业务冷启动）→ 先用官方建议的「Claude 辅助生成初版题目 + 人工审校」，套件从小做起（先 30–50 题）。
若流量小到逃逸指标无统计意义（月千级会话）→ 弃 A/B 式按周抽样，改为全量人审 + 更厚的离线评估。
若出现多租户隔离要求 → 金标集需按租户分层，评估环境必须复现 metadata pre-filter（模块 07/11 联动），否则线上安全回归测不出来。

答案与解析

单选

🎯 学习重点：复盘每个选项具体混淆了哪个评估层级。

A。官方 cookbook 定义 eval 四件套：input prompt、output、golden answer、score（来源: misc-building-evals）。D 的四个词也是官方术语，但属于 agent 评估的扩展结构而非「基础四件套」——这是常见的混淆选项。考什么：eval 的解剖结构。

B。官方定义：transcript 是完整交互记录，outcome 是环境终态；「说订好了」≠「数据库里有预订」。A/C/D 分别是 transcript 内容、主观评分与用户反馈，都不是 task success 的判据。考什么：transcript vs outcome 辨析——高频考点。

C。官方排序原话：deterministic where possible, LLM where necessary, human judiciously；人工的主要角色是校准 LLM judge。考什么：评分器选型的官方次序。

B。regression evals 问「过去会的现在还会吗」，应近 100% 通过；低通过率是 capability evals 的特征。考什么：两类套件的语义。

C。pass^k 要求全部成功：0.75³ = 0.421875 ≈ 42%（官方原文例子）。B（56%）是 0.75²。考什么：pass^k 的计算直觉——k 增大 pass^k 下降。

D。官方建议恰好相反：按维度隔离 judge（每个维度一个独立 LLM-as-judge）比一个 judge 包打所有维度更稳。A/B/C 均为官方技巧原文。考什么：LLM grading tips。

B。官方：「前沿模型 0% pass@100 最常是任务坏了的信号，不是模型不行」——先查任务规格与 grader（Terminal-Bench 文件路径歧义案例）。考什么：评估排障的第一怀疑对象。

B。原文「Use direct quotes for factual grounding」：先逐字摘引再执行任务，把响应锚定在实际文本上降低幻觉。考什么：减幻觉三招之一的机制。

B。TTFT 是「第一个 token 产出前的时间」，streaming 场景下决定感知响应速度（官方 reduce-latency 定义）。考什么：延迟指标术语。

C。官方表格：用户反馈稀缺、自选择、偏严重问题、很少解释为什么失败——但它能暴露没预料到的问题（A 反了），也是新 eval 题目的来源（D 反了）。考什么：六方法矩阵中 user feedback 的定位。

B。recall@k 随 k 单调不降，「全库塞入」必得 recall 100%，因此必须与 precision@k / nDCG 同看（模块 07/12 一贯论断）。考什么：指标作弊识别。

A。官方四条：Specific / Measurable / Achievable / Relevant（SMART 去掉 Time-bound 的官方版本）。考什么：成功标准框架。

多选

🎯 学习重点：检查漏选项是否只是成本较高，而非方法本身无效。

A, B, D。三者均为官方 tool_calls 校验的做法（required 集、参数级断言 amount ≤100、禁止类不出现）。C 错：官方明确警告严格校验固定调用顺序「过脆」——只有业务规则型顺序（先鉴权后打款）才值得硬校验，一般原则是「评产出不评路径」。考什么：tool correctness 的正确检查面。

A, C, D。B 是反模式：同一份题目既调参又汇报 = 直接教会系统「应试」，held-out 分离正是官方 develop-tests 示例中的标准做法（"on a held-out test set"）。考什么：防过拟合机制。

A, B, D。校准 = 与人工对表、rubric 变更后重校、稳定后定期抽检。C 反了：Unknown 出口是官方技巧（避免 judge 幻幻觉判定），禁止 Unknown 会制造虚假确定性。考什么：judge 校准实践。

A, B, C。官方 YAML 的 tracked_metrics 恰好是 transcript 指标（n_turns/n_toolcalls/n_total_tokens）+ 延迟指标（TTFT/output_tokens_per_sec/time_to_last_token）；D 的留存率属于 A/B 测试与产品指标，不在单次 trial 的 tracked metrics 里。考什么：agent 评估的 tracked metrics 构成。

判断

🎯 学习重点：把错误陈述改写成带边界条件的正确架构判断。

错。groundedness 只问「主张是否被证据支撑」，不问证据本身对不对——引用了过时文档的回答可以有据但错误（模块 07 已辨析 groundedness ≠ accuracy）。反向也不成立：碰巧答对可以无据。两个维度分开报。

对。官方设计原则「Prioritize volume over quality」：更多题目 + 略低信号的自动评分，好于少量高成本人工题——前提是评分可自动化（这又回到「代码评分优先」）。

场景决策题 S1

🎯 学习重点：用来源与约束解释为何最佳方案优于只做 dashboard 或只做 judge。

见题内「Best choice / Why / Why others are weaker / Tradeoffs / What would change the answer」各节。核心考点：评估体系设计的第一性原理——题目从真实失败来、评分能代码则代码、capability/regression 分套、离线 CI 与线上监控双闭环；单一综合分（A）与纯线上（D）分别代表「平均分陷阱」与「无 ground truth 的被动监控」两个官方点名的反面模式。

📚 目录