第 13 章测验

对应章节：评估入门：手写 eval

共 8 题，答对率 ≥ 80% 即通过。请完成全部题目后点击「提交」。

Q1为什么在给 Agent 做了一处修改（比如改了一句提示词）之后，一定要有评估与回归？因为改模型/提示词可能让一部分任务变好、另一部分悄悄变坏，没有固定的任务集做基准，就无法发现这类回归因为 LLM 每次输出都不一样，评估可以把输出固定成完全相同的结果因为评估是模型上线前的法律合规要求，不评估不能发布因为改了提示词之后模型就再也不能修改了，必须一次性做对

Q2关于评估的四个概念——任务、trace、grader、汇总，下列说法正确的是？ trace 是一次 Agent 运行留下的完整记录（最终回答、轮数、每次工具调用与结果），grader 在这份记录上判分，汇总聚合出通过率与失败模式分布 trace 就是任务的最终答案字符串，grader 只比较最终答案是否完全相等 grader 只能由另一个 Agent 实现，不能写成确定性代码任务集里每个任务必须一模一样，否则没法汇总

Q3规则 grader（字符串匹配 / 工具调用检查 / 参数检查）的主要特点是什么？客观、可复现、便宜，适合「答案是否包含关键事实」「是否调用了某工具」这类可判定的断言；局限是僵化，答案换种说法可能被误判只能用于检查工具调用，不能用于检查答案内容比 LLM-as-judge 更主观，同一条 trace 每次判分结果不同必须联网调用真实模型才能工作

Q4什么时候才需要引入 LLM-as-judge？当正确性无法用规则表达时——如「回答是否简洁」「语气是否专业」这类主观标准，用一个更强的模型按明确 rubric 打分任何任务都必须用 LLM-as-judge，规则 grader 没有价值当规则 grader 报的失败太多时，用 LLM-as-judge 把失败任务标记成通过当任务集的每个任务需要跑几十次时，用模型判分能省 token

Q5评估带工具的 Agent 时，为什么只判「最终答案」往往不够，还要看 trace？因为最终答案可能正确但过程浪费（烧了太多轮数、调了多余工具），只看答案发现不了这类效率问题因为最终答案一定是错的，必须看过程才能猜出正确答案因为 trace 比答案短，检查起来更快因为最终答案无法被字符串匹配，只能靠 trace 判

Q6在 planning / tool / efficiency 三类失败模式中，下列对应正确的是？ planning 是计划与动作出错（工具用错、参数错、目标没达成）；tool 是工具本身出错（调用正确但工具返回错误）；efficiency 是轮数/token 超预算 planning 是模型思考太久；tool 是模型没调用工具；efficiency 是答案太短 planning 是任务太难；tool 是任务没有可用工具；efficiency 是任务集太大 planning 与 tool 是同一种失败的两种叫法，efficiency 是另一种

Q7一个失败的 trace 可能同时有多个问题（比如工具用错且超预算）。本章的分类器如何处理？按文档化的优先级顺序归入第一个命中的桶（如超预算先于工具用错），保证每个失败都有确定、可复现的归因随机归入一个桶，避免主观偏见归入所有命中的桶，在汇总里重复计数无法归类的统一算作 tool 失败

Q8关于回归（regression）评估，下列说法正确的是？回归评估是「改动之后把之前的任务集再跑一遍，确认没变坏」；能力评估测「能不能做」，回归评估测「还做不做得来」回归评估只在发布生产前跑一次，之后永远不用再跑回归评估用随机生成的输入，不需要固定任务集回归评估必须用真实模型联网跑，不能用 mock