Chapter 05

综合自测与场景判断：把四章揉成判断力

前四章分别建立了四块心智模型：LLM 的组件特性（01）、RAG 检索（02）、Agent 循环（03）、生产工程（04）。这一章不教新东西——它把四块拽进同一个场景，逼你做选择。能选对，才说明这些心智模型真的连成了网，而不是四堆各自孤立的名词。

本章你将做到

  • 在真实场景里交叉调用四章的知识——这是迁移，不是复述
  • 在“RAG vs 长上下文 vs 微调”“Workflow vs 单 Agent vs 多 Agent”这类岔路口当场做选择并说清理由
  • 用一道系统设计题检验能不能把四章揉成一个完整方案
  • 通过亲手画架构图，验证脑子里那张图是不是真的存在

5.0这一章怎么用

下面的题分三层，难度递增。概念层测“记得住”，原理层测“讲得通”，应用判别层测“选得对”。面试的区分度集中在第三层——前两层背一背就能过，第三层只有把四章连成网的人才答得稳。所有参考答案都折叠在本页最后一个折叠块里：先把答案写在纸上或编辑器里，再展开对照。直接看答案，等于把这一章当成又读了一遍正文。

概念层 · 记得住（recall） 原理层 · 讲得通（understand） 判别层 · 选得对 01–04 各章 为什么 跨章
图 5.1题目按认知难度分三层。注意：背得出定义的人多，能在岔路口选对、还说得清理由的人少——区分度在塔尖。别在塔基刷出“我都会”的流畅感错觉。

5.1概念层 · 记得住

每题一句话能答完。答不利索的，回对应章节的小节补。

  1. KV cache 把注意力的什么成本从二次降到了线性？代价是什么？（01 章 §1.1）
  2. 混合检索的 RRF 靠什么把两路结果合并，为什么不直接用归一化后的相似度分数相加？（02 章 §2.5）
  3. ReAct 一轮循环的三个步骤分别是什么？（03 章 §3.3）
  4. Anthropic 的 prompt 前缀缓存，缓存命中时的输入价格大约是未命中的几折？（04 章 §4.2）
  5. RAGAS 里 faithfulness 和 answer relevancy 分别衡量 RAG 的什么？（02 章 §2.7）

5.2原理层 · 讲得通

这一层不问“是什么”，问“为什么这样”。能讲清因果，才算理解。

  1. 为什么 cross-encoder 适合做精排，却不适合做第一阶段的大规模召回？（02 章 §2.5）
  2. 为什么 Anthropic 主张“能用 workflow 就别上 agent”？从成本和可控性两个角度解释。（03 章 §3.1）
  3. “上下文窗口已经足够大”为什么仍不能完全替代 RAG？给出至少两个理由。（01 章 §1.3 + 02 章 §2.1）
  4. 为什么生产环境里熔断要按“行为模式”（如循环、成本速率）触发，而不是只按请求量触发？（04 章 §4.6）
  5. Anthropic 的多智能体系统中，约 80% 的性能差异由 token 用量解释。这个事实对“要不要上多 Agent”的设计决策有什么启示？（03 章 §3.7）

5.3应用判别层 · 选得对（核心）

这是中高级与初级的分水岭。每个场景都没有“标准答案”，只有“有没有把约束、取舍、代价说清楚”。先用下面这棵决策树把“要不要上 Agent、要几个”想清楚，再做场景题。

一个新任务 流程能不能 预先写死? 能 Workflow（最可控 · 最便宜） 不能 子任务独立可并行 且超出单上下文? 否 单 Agent（ReAct / Plan-Execute） 是 价值高到吃得下 ~15× token? 是 多 Agent（supervisor + 并行） 否 退回单 Agent / 拆成 Workflow
图 5.2“要不要上 Agent、要几个”的决策路径。注意：默认值在最左上角——能写死流程就用 Workflow。每往下一层，可控性下降、成本上升；多 Agent 是最后才考虑的选项，不是起点。

下面六个场景，每个都横跨至少两章。先写下你的判断和理由，再看答案。

  1. 场景 A · 内部 API 文档问答助手：文档约 5 万字（≈80K tokens），更新频率低，但要求每个答案都能溯源到具体段落。该用 RAG、长上下文全塞、还是微调？（牵涉 01 上下文/幻觉 + 02 RAG vs 微调 + 04 缓存成本）
  2. 场景 B · 客服工单自动分类 + 回复草稿：日均量大、延迟敏感、预算紧。用单次 LLM 调用、Workflow、还是 Agent？（牵涉 03 Agent vs Workflow + 04 模型路由/流式）
  3. 场景 C · 竞品调研报告生成：要并行查多个信源、各自深挖、最后汇总成一份报告。单 Agent 还是多 Agent？理由是什么？（牵涉 03 多 Agent 何时上/代价）
  4. 场景 D · RAG 上线后某类问题答得离谱：怎么定位是检索环节还是生成环节的问题？怎么量化“改好了没有”并防止下次回归？（牵涉 02 链路/评估 + 01 幻觉/采样 + 04 eval/CI）
  5. 场景 E · 给 Agent 接入“发邮件”“查数据库”“删记录”等工具：怎么保证它不会被一段恶意文档诱导着把数据偷运出去或误删数据？（牵涉 03 Agent 安全可控 + 04 Prompt 注入/致命三件套/可靠性）
  6. 场景 F · 项目深挖（STAR）：面试官指着你简历上“用 RAG 把客服自动回复准确率从 72% 提到 89%”这条让你深挖。逐个想清楚下面四个递进追问（任一答不利落，这条经历就站不住）：
    1. 这个项目最难的技术点在哪？
    2. “准确率”具体怎么定义、怎么量化的？
    3. 为什么选 RAG，不选微调或长上下文？
    4. 踩过最大的失败模式是什么？怎么定位和解决的？
    （牵涉全部四章 + 你的真实经历）

5.4系统设计综合题

压轴 · 把四章揉成一个方案

设计一个面向 10 万内部员工的“企业知识 + 操作”助手

它既要能基于公司文档回答问题（带引用），也要能执行“查考勤”“提工单”这类操作。给出整体架构，并在以下决策点明确选择 + 理由 + 代价：

  1. 知识接入：RAG / 长上下文 / 微调，怎么选？（可以混用，但要说清各部分为什么这么选）
  2. 要不要上 Agent？单 Agent 还是多 Agent？哪些请求其实用 Workflow 就够？
  3. 流式与延迟：哪些环节必须流式？多步操作怎么给用户进度反馈？
  4. 成本控制：在不降质的前提下，你会按什么顺序拉哪几个杠杆？
  5. 可观测与评估：上线后怎么知道“变好了还是变坏了”，怎么定位某一跳变慢变贵？
  6. 安全：文档权限隔离怎么做？“删记录”这类高危操作怎么防注入、防误删？
亲手画一张图

合上教程，在纸上把图 0.1 的因果链默画出来——只画四个方块、它们之间的三条箭头，并在每条箭头上写出“左边的什么限制催生了右边的方案”。画完翻回起点页对照：你写的箭头标签，和“上下文有限 + 幻觉 → 检索”“自主循环 → 成本 / 失控”对得上吗？对不上的那一环，就是你心智模型里最虚的地方，也是面试官最容易问倒你的地方。

5.5参考答案

先做完上面所有题，再展开。答案给的是“强答案应命中的点”，不是唯一表述——面试看的是你的推理链，不是逐字背诵。

展开全部参考答案（先做完再看）

概念层

  1. KV cache 缓存历史 token 的 Key/Value，使每生成一个新 token 的注意力计算从“对总长度二次”降到“对总长度线性”。代价是显存随上下文长度线性增长——这是推理服务真正的瓶颈，也是长上下文又贵又占资源的原因。
  2. RRF 按每路结果里文档的排名（rank）合并：score = Σ 1/(k+rank)，k≈60。用排名而非分数，是因为 BM25 的词频分数和向量的余弦相似度不在同一量纲，直接相加需要脆弱的归一化；用排名则天然可比。
  3. Thought（推理下一步该干什么）→ Action（调用一个工具）→ Observation（把工具返回结果观察进来），然后回到 Thought，直到产出最终答案。
  4. 约 0.1 折……更准确地说，缓存命中时输入价格约为未命中的 10%（即一折）。代价是写入缓存那次会贵 1.25×–2×，且缓存有 5 分钟 / 1 小时的存活期。
  5. faithfulness 衡量“回答里的每个论断是不是都有检索到的上下文支撑”（防生成环节编造）；answer relevancy 衡量“回答是不是切题、对得上用户的问题”。前者管忠实，后者管切题，两者可以一个高一个低。

原理层

  1. cross-encoder 把 query 和每个 doc 拼在一起送进模型做一次完整前向，才能给出精细的相关性分数——准，但要为每个候选都算一次，无法预先把文档编码成可索引的向量。第一阶段要在百万级文档里召回，必须用 bi-encoder（文档预先编码成向量、查询时只算一次、靠近邻索引秒回）。所以是“bi-encoder 求广召回 top-100，cross-encoder 求准精排到 top-10”的两段分工。
  2. 成本上，Agent 的自主循环每一步都要 LLM 调用、token 随轮次膨胀；可控性上，预定义路径（workflow）的行为可预测、可测试、可回滚，而 Agent 自主决策意味着行为空间大、难调试、可能死循环或调错工具。多数生产任务的流程其实可以预先写死，强行上 Agent 只是用更高的成本和更低的可控性换一个用不上的“灵活性”。
  3. 理由（任取两个）：① 注意力 O(n²)，把全部知识塞进超长上下文，每次请求都为不相关内容付费、还更慢；② “Lost in the Middle”——长上下文中段的信息容易被忽略，塞进去 ≠ 用得到；③ 知识仍会过期、需要按权限过滤、需要可溯源引用，这些是检索层的职责，长上下文本身解决不了。
  4. 真正烧钱、拖垮系统的生产事故往往不是“答错”，而是重试风暴：某次调用失败 → 带着已增长的上下文重试 → 上下文二次膨胀 → 更慢更贵 → 触发更多重试。这种事故请求量未必异常，但“同样的调用在循环”“成本速率飙升”是它的特征。只按请求量设阈值会漏掉它；按行为模式（循环检测、成本速率）触发才能及时熔断。
  5. 启示：多 Agent 的收益主要靠“烧更多 token 做更多并行探索”买来，本质是一种用成本换广度的特化手段。所以只有当任务价值高到能吃下约 15× 的 token、且子任务天然独立可并行（广度优先）时才划算；需要共享大量中间上下文或步骤强依赖的任务，多 Agent 既不划算也容易因一步出错而整体崩。

应用判别层

  1. 场景 A：语料 ~80K tokens 已低于“全塞”的经济阈值（约 200K），技术上可以全塞 + prompt 缓存，实现最简单。但“答案要溯源到具体段落”这个硬需求把天平推向 RAG（检索天然带来源 chunk，可做引用）。微调不合适——微调改的是风格/能力而非知识，且知识更新时还要重训。结论：轻量 RAG（甚至“全塞 + 让模型标注引用段落”的折中）；不微调。说清代价：全塞每次都为整篇文档付 token、且引用不可靠；RAG 多一套链路但可溯源、可增量更新。
  2. 场景 B：流程是固定的（分类 → 取模板 → 填充草稿），预定义路径足够 → 用 Workflow（routing 模式），不上 Agent。分类用小模型、草稿生成用稍大模型做模型路由降本；给坐席的草稿用流式输出改善体感。Agent 在这里只会徒增延迟、成本和失控风险——这正是“能写死就别上 Agent”的典型。
  3. 场景 C：子任务（查不同信源）天然独立、可并行，且汇总前的中间材料容易超出单个上下文 → 属于“广度优先”，多 Agent（supervisor + 并行 subagents）划算。前提是这份报告的价值撑得起约 15× 的 token。如果各信源之间强依赖、要频繁共享中间结论，则退回单 Agent，避免协调开销和错误传播。
  4. 场景 D：先分段定位（检索和生成是两段）。看 retrieved context：相关段落有没有被召回？没召回 → 召回问题，去调 chunk 策略 / 上混合检索 / 加 rerank（context recall、precision 量化）。召回到了还答错 → 生成问题，faithfulness 低，去强化“仅依据上下文回答”的 prompt 约束、降 temperature、加引用校验。量化与防回归：用 RAGAS 三元组 + 一个固定的 golden set，把这些指标接进 CI，每次改 prompt / 改链路都跑一遍。
  5. 场景 E：用“致命三件套”框架看——不可信输入（用户消息、被检索到的文档/邮件）+ 私有数据访问 + 对外发送通道，三者同时存在就是高危。防御要砍掉其中的边：工具最小权限（“删记录”必须 dry-run + 人工确认 + 权限边界，绝不给 Agent 直接删的能力）；把检索/邮件内容当不可信数据、与系统指令分隔，防间接注入；高危操作 Human-in-the-Loop 审批 + 可回滚 + 全程审计。
  6. 场景 F：这题没有标准答案，考的是怎么把一段真实经历讲成结构化论据。用 STAR 骨架：①背景与目标（一句话讲清做什么、为谁做）；②难点（挑一个真有技术含量的，如“召回不准导致幻觉”，别泛泛说“数据多”）；③选型理由与取舍（为什么 RAG 不微调：知识常变、要溯源——呼应 02 章；成本/延迟权衡——呼应 04 章）；④量化（“准确率”先把口径定清楚，如人工抽样标注的答案正确率，再给基线 → 提升后的数字和样本量，72%→89% 这种数字要说得出怎么测的）；⑤一个真实失败模式 + 定位过程（如“混合检索上线后延迟翻倍”，用 trace 定位到 rerank 阶段——呼应 04 章可观测）。一句话拎出信号：用具体数字、说清取舍、敢讲一个失败并展示定位能力，是中高级最被看重的三件事。

系统设计综合题（参考骨架）

  1. 知识接入：公司文档问答走 RAG（可溯源、可按权限过滤、文档更新只需重建索引），混合检索 + rerank；高频小文档可叠加 prompt 缓存。不微调主模型（知识会变）。
  2. Agent / Workflow：默认 Workflow——大部分请求是“问答”或“单步操作”，routing 分流即可。只有“跨多个系统的复合操作”才升级到单 Agent；几乎不需要多 Agent（员工助手不是广度优先的研究任务）。
  3. 流式与延迟：问答类回答必须流式（SSE），改善 TTFT 体感；多步操作用流内事件回传“正在查考勤……”这类进度。
  4. 成本：顺序——先模型路由（问答用小模型、复杂操作用大模型）、再 prompt 前缀缓存（系统提示 + 工具定义是静态前缀）、再语义缓存高频问题、必要时批处理离线任务。
  5. 可观测与评估：全链路 trace（Langfuse/LangSmith），每个 span 记 token/成本/延迟；离线 golden set + RAGAS 进 CI 防回归；线上按版本灰度 + 监控 P99/错误率/token 燃烧率。
  6. 安全：文档检索带用户权限做 metadata/行级过滤，多租户隔离；“删记录/提工单”等写操作走最小权限 + dry-run + HITL 审批；把文档和用户输入当不可信内容，防直接与间接 prompt 注入；操作可回滚、可审计。