模块 1 架构师问答题 — LLM 基础
用途：面试式自测。每题先自己答，再看参考要点。参考要点只列"架构师必须说出的点"，不是唯一标准答案。 场景题格式：Scenario / Constraints / Options / Best choice / Why / Why others are weaker / Tradeoffs / What would change the answer。
Q1. 客户说"你们用 1M 窗口的模型，把整座知识库塞进去不就行了，为什么要检索？"
🎯 学习重点：必须同时答出准确性、成本、延迟与 ITPM 四个维度，并说明长上下文合理的边界场景。
参考要点：
- 装得下 ≠ 记得准：官方文档明确 上下文衰减 (context rot)——"As token count grows, accuracy and recall degrade"（来源: https://platform.claude.com/docs/en/build-with-claude/context-windows（访问于 2026-08-30））
- 成本与延迟随 token 线性增长；ITPM 速率限制按输入 token 消耗
- 正确架构：检索/分块后只注入相关内容 + prompt caching 降低重复前缀成本；上下文工程优先于堆上下文
- 何时客户是对的：一次性离线分析超长文档、且接受成本时，1M 窗口确实省掉建检索系统的复杂度
- 数字化决策：比较“全库输入 token/请求”与“检索后注入 token/请求”，再以真实压测的 TTFT/总时长和任务召回率验收；输入计费按 token 增长，但 API 延迟不可武断假设为严格线性
Q2. 你的多轮对话应用每轮都把全部历史重发给 API。为什么这是必须的而不是浪费？有什么缓解手段？
🎯 学习重点：说清 API 无状态与应用有状态并不矛盾；缓存只降成本/限速压力，不扩窗口。
参考要点：
- Messages API 无状态：模型权重冻结（训练 vs 推理），"记忆"只能靠每次重发上下文窗口内容
- 缓解：prompt caching（重复前缀按 0.1x 计费且多数模型不占 ITPM，模块 3）；摘要压缩（compaction）；检索式注入只放相关轮次
- 陷阱：截断最旧消息会静默丢失早期约束（如任务指令），压缩时要保留关键指令与最近轮次
- 若每轮内容近似等长，持续重发使前 n 轮累计处理的历史近似
1+2+…+n，呈 O(n²) 级增长；应按会话轮次监控 input token 斜率，而非等到超窗才处理
Q3. 场景题：合规审查助手的输出必须是合法 JSON
🎯 学习重点：最佳答案是结构化输出；温度不是格式合同，schema 也不替代业务语义校验。
Scenario：内部工具从 Claude 响应里解析 JSON，最近频繁崩在 json.loads()。 Constraints：下游是确定性解析器；不能容忍格式失败；模型为 Opus 5。 Options：(a) prompt 里强调"必须输出合法 JSON" (b) temperature=0 (c) 输出后修复重试 (d) 结构化输出（schema 约束/strict tool use） <!-- 保留原题模板占位： Best choice：。 --> Best choice：(d) 结构化输出（schema 约束/strict tool use）。 Why：b 在 Opus 5（4.7+ 模型）上非默认值直接 400（来源: https://platform.claude.com/docs/en/about-claude/model-deprecations（访问于 2026-08-30））；a 是软约束；c 是兜底不是保证。 Why others are weaker：(a) 无机器可验证合同；(b) 既不保 JSON，在该模型上还会报错；(c) 增加延迟与重复计费，修复后仍须再次校验。 Tradeoffs：约束解码只保格式不保语义，业务校验仍需应用层。 What would change the answer：平台不支持结构化输出时 → 降级组合（清晰 prompt + 修复式重试 + 人工兜底）。
Q4. "模型幻觉了"事故复盘会上，架构师应该给出的定位与行动是什么？
🎯 学习重点：从追责“模型为什么错”转成风险分级、可观测信号、确定性防线和升级路径。
参考要点：
- 定位：幻觉是 next-token prediction 的机制性产物，概率系统的固有属性，不是"bug"
- 行动分层：接地（RAG/引用，模块 07）、工具取实时事实（模块 04）、评估集显式测幻觉率（模块 12）、提示层允许"不确定"
- 反模式：试图靠 prompt 说"请不要出错"当唯一防线
- 指标：按任务风险分桶统计“无依据断言率、引用存在率、引用支持结论率、工具事实一致率”；有 citation 但 citation 不支持结论仍算失败
- 高风险动作：模型只产出建议，不直接越权执行；付款/合规等结论经确定性规则或人工批准
Q5. 为什么说"上下文窗口是工作记忆，不是数据库"？这句话对多租户 SaaS 设计有什么影响？
🎯 学习重点：答题必须落到应用层持久化、租户隔离、最小化注入与审计，而非只背“working memory”。
参考要点：
- 官方定义：context window 是模型生成时可引用的全部文本的"working memory"（来源: context-windows（访问于 2026-08-30））；对话不写权重，推理结束即消失
- 影响：跨会话个性化/记忆必须由应用层存储（DB/向量库/memory 工具），每轮按需注入；租户数据隔离在应用层，不在模型层
- 安全边界：检索查询必须带服务端派生的 tenant/user 过滤条件；不能让模型从 prompt 自报 tenant_id，也不能把跨租户材料塞入上下文后再要求模型“不要泄露”
Q6. 思考 token (thinking tokens) 为什么"又贵又值"？什么任务该开高 effort？
🎯 学习重点：用“质量收益是否覆盖输出成本、OTPM 与尾延迟”决定 effort，而不是全局默认最高档。
参考要点：
- 计入
max_tokens、按输出 token 计费、占上下文、占 OTPM（来源: context-windows（访问于 2026-08-30））
- 截至 2026-08-30：Opus 5 / Sonnet 5 / Fable 5 为自适应思考 (adaptive thinking)，由
effort（默认 high）调节；Haiku 4.5 仍是手动 extended thinking（来源: https://platform.claude.com/docs/en/models/overview（访问于 2026-08-30））
- 高 effort 适合：复杂分析、多步 agent 规划；低 effort/快模型适合：分类、抽取、简单路由
max_tokens 同时容纳 thinking 与可见答案；输出预算太小会让推理挤压最终结果，需按 task_type × model × effort 监控成功率、p95 总时长和 output token
Q7. 判断题：参数微调（temperature 等）属于 prompt 工程的一部分，模型越新越应该多调参。对吗？
🎯 学习重点：这是版本边界题；回答必须带“4.7+ 非默认值 400”，不能只泛谈低温更稳定。
参考要点：
- 不对。方向恰恰相反：新一代模型（4.7+）拒收非默认 temperature/top_p/top_k（400），官方建议"omit and use prompting"（来源: model-deprecations（访问于 2026-08-30））
- 架构含义：行为控制的杠杆从"调参"移向"上下文设计"（system prompt、示例、结构化输出、工具定义）
- 迁移 Gotcha：共享客户端若无条件发送旧默认配置，会让新模型切换在请求入口即失败；参数组装必须按模型能力表做契约测试
Q8. 系统延迟突然恶化，SLO 从 3s 掉到 9s。列出你按顺序排查的 token 相关假设。
🎯 学习重点：按 TTFT 与生成时长拆解延迟，再关联输入、输出、缓存、限流与模型/effort 变更。
参考要点：
- 输入是否膨胀（历史累积、塞了大文档 → TTFT 变差）
- 输出是否变长（含 thinking token → 总时长变长）
- 缓存是否失效（cache_control 改动导致前缀重算；模块 3）
- 是否逼近 ITPM/OTPM 触发限流退避
- 是否换了模型/effort（Fable/Opus 比 Sonnet/Haiku 慢一档，来源: https://platform.claude.com/docs/en/models/overview（访问于 2026-08-30））
最低观测字段：request_id、模型、effort、任务类型、input/output/cache token、stop_reason、TTFT、总时长、重试次数与 429。若 TTFT 上升而输出速率正常，优先查输入/缓存；若 TTFT 稳定但总时长上升，优先查输出长度/thinking；若两者都正常而端到端变慢，查排队、退避与下游工具。
📚 目录