声明：本卷是本课程编写的原创教学模拟题，不是、也不冒充任何官方真题；未使用任何泄露材料。 题型结构参考官方公开考试形式（Multiple-choice、Multiple-response、scenario；官方 VERIFIED 截至 2026-08-30）。 与卷一不重复；覆盖互补：RAG 细节 / 评估 / 安全治理 / 模型选型与成本 / CCAR-P 风格的集成与治理题。
🎯 学习重点：重点识别评估、安全、成本与生产运维中的指标口径和错误层级。
Q1. 一个任务：输入法律合同，输出「风险条款清单 + 等级」。团队评估发现单模型 pass@3 = 85%。产品要求三次尝试内至少一次正确才算可用。用 pass^3 衡量，约等于（0.85³ ≈ 0.61）——这说明： A. 85% 的单次通过率对产品目标绰绰有余 B. 「三次全对」的概率只有 ~61%，产品可用性评估必须看 pass^k 而非 pass@k C. 应该把 pass@k 禁止使用 D. 评估方法错误，应改人工评分
Q2. 上线后评估分数暴跌，团队第一反应是「模型变笨了」。更符合方法论的排查顺序是： A. 直接换最新旗舰模型 B. 先审评估本身（题目是否可解、grader 是否配置正确、环境是否漂移），再查模型 C. 大幅改 prompt 试错 D. 回滚所有代码
Q3. LLM-as-judge 的最低配置要求是： A. 随便选个便宜模型打总分 B. rubric 化评分细则 + Unknown/不确定出口 + 定期与人工对表校准 C. 用最强模型就无需校准 D. judge 输出二值即可
Q4. 检索评估中只优化 recall@k（把 K 从 5 调到 50），报表好看但系统变差。最可能的原因： A. recall 计算错误 B. K 越大 context rot 与噪音干扰成本同步上涨，precision 崩了——指标要成对看 C. 应该直接换成 MRR D. 嵌入模型过拟合
Q5. 评估「客服 agent 是否真的解决了工单」，最可靠判据是： A. agent 最后一条消息说「已解决」 B. 环境终态检查（state_check：工单系统里状态确实变更） C. 用户没有再发消息 D. 会话长度足够长
Q6. 团队把幻觉率从 8% 降到 1% 宣布大胜。但弃答率从 2% 涨到 30%。正确结论： A. 成功——幻觉率是唯一指标 B. 需要与弃答率/任务成功率联动解读——模型可能只是学会了「多说不确定」 C. 失败——弃答率必须为零 D. 数据不足以下结论
Q7. 评估集 50 题连续三个月 96 分。正确动作： A. 评估集已完美，保持不变 B. 警惕 eval saturation：旧题毕业进回归套件，补充更难的新题，留 held-out 汇报集 C. 删掉评估集 D. 降低及格线
Q8. 关于 strict 校验 agent 的工具调用顺序（先查库存再下单），正确认知： A. 顺序校验越严越好，保证规范 B. 会惩罚设计者未预料的合法路径（CORE-Bench 42%→95% 教训）——评产出不评路径，业务规则顺序才硬校验 C. 工具顺序无法评估 D. 只在测试环境校验即可
Q9. 一个 agent 的权限设计：读工具 20 个、写工具 3 个、run_sql(全库) 1 个。安全评审首先指出： A. 工具太多影响选择准确率 B. run_sql 全库工具违反最小权限——一个万能工具使其余 23 个的隔离全部失效（blast radius 最大） C. 应该把读工具合并成一个 D. 没问题，读多写少是好的
Q10. 第三方网页内容需要进入 agent 上下文。正确做法： A. 原始 HTML 直接拼进 system prompt B. 走 tool_result 通道 + 提取渲染文本 + JSON 编码，并标注来源 C. 拼进 user 消息开头即可 D. 让模型自己判断网页是否可信
Q11. 「连接器通过了安全审计，所以它取回的数据是干净的」——这句话错在： A. 审计过程太贵 B. 混淆了「连接器合规」与「内容可信」——审计过的连接器照样可能取回被投毒/含注入载荷的文档（间接注入） C. 连接器不需要审计 D. 数据干净与否无法评估
Q12. 本地 MCP HTTP server 的经典攻击 DNS rebinding，官方建议的防线是： A. 只监听 127.0.0.1 就够了 B. 校验 Origin 头（拒绝非预期来源的跨站请求） C. 加长 token D. 改用 stdio 就必然安全
Q13. 公司要求数据不出欧盟 + 满足 GDPR。影响架构的直连决策是： A. 与数据驻留无关，选最便宜模型 B. 数据驻留/合规要求影响接入路径选择（直连 API vs Bedrock/Vertex 区域部署 vs ZDR 条款） C. 只要 prompt 里删除 PII 即可 D. 合规是法务的事，架构不用管
Q14. 模型选型的第一层输入通常是： A. 最新发布的模型 B. 模型家族/档位（价格/延迟/能力三轴）× 任务要求（含限流桶容量） C. 参数量大小 D. 社区口碑
Q15. 高吞吐客服系统用 cascade（便宜模型先答、不确定升强模型）。核心监控指标是： A. 强模型单价 B. 升级率（escalation to strong model 的比例）——决定平均成本与质量 C. 总请求量 D. 弱模型上下文长度
Q16. 流式（streaming）对延迟指标的真正作用： A. 降低总生成时长 B. 降低 TTFT（首 token 时间）后的感知等待，总时长不变 C. 提高输出质量 D. 降低 token 单价
Q17. Prompt caching 设计：system prompt（稳定）+ 工具定义（稳定）+ 每轮变化的消息。断点应放在： A. 每条消息后各放一个 B. 稳定前缀的末尾（变化内容之前），一次性覆盖 system + 工具定义 C. 最后一条消息后 D. 不设断点自动最优
Q18. 529 (overloaded) 错误的正确响应策略： A. 立即并发加倍抢容量 B. 指数退避 + 平缓爬坡 + 熔断器；529 是全平台过载信号 C. 永久放弃该请求 D. 切换到未评估过的模型
Q19. 超时设计的反模式是： A. 顶层统一超时预算向下分配 B. 每层独立设 30s——多层叠加成分钟级挂起 C. 超时预算耗尽即降级 D. 为不同操作设不同预算
Q20. Chunking 策略：支持政策手册（Markdown，含表格与编号条款）。正确做法： A. 固定 512 token 滑窗硬切 B. 按标题层级/条款边界结构化切分，保留标题链元数据（缓解主语丢失） C. 全文一块不切 D. 按句号切
Q21. 「Contextual Retrieval（上下文检索）」解决的核心缺陷： A. 嵌入模型太慢 B. 传统切块丢失主语/上下文（"增长了 3%" 没有公司名就是废数据）——给每块补回上下文 C. reranker 太贵 D. 向量维度太高
Q22. 官方实测数据中，contextual retrieval + reranking 对检索失败率的累计改善约： A. 10% B. 35% C. 67%（49% 来自上下文化 BM25，再叠 reranking） D. 95%
Q23. 判断「该不该给这个 agent 加检索」，第一问是： A. 嵌入模型选哪家 B. 知识规模/变化频率是否超出「全量塞 prompt + caching」的适用范围 C. Top-K 设多少 D. 用不用 reranker
Q24. Agent 的工具描述（description）写得很随意。按官方经验（ACI 投入）： A. 描述不重要，模型够聪明 B. 工具文档质量按 HCI 标准投入——优化工具的时间常超过优化 prompt（如绝对路径改造零失误） C. 描述越长越好 D. 工具数量比描述质量重要
Q25. Planner-executor 与 orchestrator-workers 的区分判据： A. 有没有名字叫 planner 的 agent B. 计划是否作为静态契约先产出并交由执行方落实（是 → planner-executor） C. 子 agent 数量是否超过 3 D. 是否使用 MCP
Q26. Routing 模式的典型收益： A. 消除所有延迟 B. 分离关注点：简单请求走便宜快通道，复杂请求走强模型——成本与体验双优 C. 免去评估 D. 自动修复错误
Q27. 架构评审中，方案文档写了「选 agent 因为更先进」。按决策记录（ADR）规范应补上： A. 更漂亮的架构图 B. 每个决策的选择理由 + 被放弃的选项 + tradeoff（无 tradeoff 记录的决策视为未完成） C. 更多引用供应商宣传 D. 延期评审
Q28. 灰度发布（canary）新模型版本时用稳定哈希分流的原因： A. 加密安全 B. 同一用户稳定落在同一版本，避免体验抖动，且新旧版本指标可分标签对比 C. 减少总流量 D. 绕过限流
Q29. 结构化输出的 JSON schema 里塞了 24 个 optional 参数。潜在问题： A. 没有问题，参数越多越灵活 B. 撞可选参数上限且文法编译变慢——schema 应最小化到任务所需 C. 只影响输入 token D. JSON 不支持 optional
Q30. 数据库含 PII，评估管线要把生产请求回放给模型。合规底线： A. 评估不算生产，随便用 B. 内容级日志/回放数据独立权限 + 脱敏/加密 + 保留期限——PII 进通用日志是合规事故 C. 只删除用户名字段即可 D. 评估在本地跑就无需合规
🎯 学习重点：完整方案常由主机制与护栏组合，避免选两个解决同一层问题的项。
Q31.（选 2）间接 prompt injection 的可能入口包括： A. RAG 检索回来的文档内容 B. 工具调用的返回结果（tool result） C. 用户手打的正常问题 D. 网页正文中的隐藏标签（display:none 的指令）
Q32.（选 2）Defense in depth（纵深防御）在 agent 系统的正确理解： A. 任何单层防御都有已知失效模式，需多层叠加 B. 有了 system prompt 禁令即可免沙箱 C. 层与层覆盖不同失效面（输入筛查/权限/沙箱/egress/审批） D. 层数越多越好，不计成本
Q33.（选 3）评估一个 RAG 系统，最小合格指标组： A. recall@k（检索层查全） B. precision@k 或 nDCG（检索层噪音/排序） C. groundedness（生成层有据性） D. 只看用户点赞数
Q34.（选 2）哪些是「过早优化」应被叫停的情形： A. 功能指标还没达标就砍上下文换延迟 B. 先建基线（功能 → 延迟的优化次序） C. 检索管线还没评估就买 reranker 集群 D. 用 golden dataset 建立回归门禁
Q35.（选 2）MCP 里 resources 与 tools 的正确分工： A. 只读参考数据（文件/schema/目录）→ resources B. 会改变系统状态的操作 → tools C. 所有东西都做成 tools 最省事 D. resources 也能执行写操作
Q36.（选 3）面向干系人汇报架构决策时应包含： A. 需求与约束摘要（含量化指标如 SLO/成本） B. 各选项 tradeoff 与放弃理由 C. 风险与缓解（含失败模式与降级预案） D. 全部技术细节与代码片段
🎯 学习重点：综合约束下比较方案的质量、成本、延迟、治理和发布风险。
Q37.【场景：合规金融助手】 Scenario：银行为理财顾问建 Claude 助手：读取客户档案（含 PII）与内部研报，生成投资建议草稿，顾问审核后发给客户。 Constraints：监管要求每条建议可追溯到研报来源；PII 不得进入模型日志；Claude API 故障时顾问仍要能工作（降级）；建议只是草稿（人审必经）。 Options： A. 全自动 agent：直接给客户发建议，附引用 B. RAG（研报检索 + Citations 引用）+ 生成前 PII 脱敏/字段最小化 + 内容日志独立加密管道 + 降级为「检索结果直接呈现，无生成」+ 顾问审批门 C. 把研报全量微调进模型（不检索） D. 纯模板邮件系统（不用 LLM）
Q38.【场景：电商大促容量规划】 Scenario：电商大促（黑五）预计 QPS ×10。当前架构：单一 Sonnet 档模型 + 每请求全量知识库塞入（~80K token）+ 无缓存。当前已偶发 429。 Constraints：成本预算只有 2×（不是 10×）；p95 延迟 ≤ 12s；知识库每日更新一次；已有分类器可区分「常见问题/复杂问题」。 Options： A. 全部流量切到旗舰模型并扩容限流配额 B. 组合：prompt caching（知识库稳定部分作前缀）+ routing（分类器分流：常见问题→Haiku 档+缓存，复杂→Sonnet 档）+ 429 退避与熔断 + 灰度验证 C. 限制每用户每天 1 次提问 D. 大促期间关闭知识库功能只留寒暄
Q39.【场景：多智能体改造之争】 Scenario：团队现有单 agent 系统（写周报：收集 3 个数据源→汇总→格式化）运行良好。新架构师提议改造为 multi-agent（5 个 subagent：每数据源一个 + 汇总 + 格式化 + 审核）。 Constraints：任务路径固定（数据源列表不变）；当前延迟 30s、成本 $0.05/次；无超窗口问题。 Options： A. 采纳——multi-agent 一定更强 B. 维持单 agent workflow——路径固定可预测，multi-agent 违背四前提且 ≈15× token；若未来数据源数量动态变化再评估 orchestrator-workers C. 折中：改 3 个 subagent D. 全部改成人工写周报
Q40.【场景：评估驱动的模型升级】 Scenario：新版 Sonnet 发布，团队想升级生产模型（当前锁定旧 snapshot）。评估集 120 题：任务成功 82 题。升级后新模型跑同集：79 题（-3）。其中 6 题新模型对了旧模型错了，9 题旧对新错。 Constraints：不能容忍质量回退；发布窗口两周；有 1% 灰度基础设施。 Options： A. 新模型更新更强，直接全量切换 B. 按流程：先分析 9 题回退题（题目分布/失败模式）→ 若为可修的 prompt/工具问题则修复后重评 → 达标后锁新 snapshot 灰度 1%→25%→100%，回退预案就绪；不达标则暂缓 C. 平均分差不多（79 vs 82），视为等价直接换 D. 永不升级，避免风险
（卷二完） · 对答案：mock-exam-2-answers.md · 回看卷一：mock-exam-1.md
📚 目录