《AI 工程》学习笔记（下）：RAG、Agent、微调、推理优化与应用架构

方糖猫 方糖猫
- 约 24 分钟读完 - 全文 9453 字

《AI 工程》学习笔记（下）：RAG、Agent、微调、推理优化与应用架构

这是 Chip Huyen《AI 工程》读书笔记的下篇，覆盖第 6-10 章。上篇讲了基础模型、评估和提示工程（见 《AI 工程》学习笔记（上）），这篇进入"重型"话题：RAG、Agent、微调、数据工程、推理优化，最后收拢到完整的应用架构。

如果说上篇的主题是"怎么知道模型干得好不好"，下篇的主题就是"怎么让它在真实世界里又快又稳地干活"。

一、RAG：先检索，后生成

1.1 为什么 RAG 是第一个要掌握的模式

模型的知识有两个硬限制：上下文窗口装不下（整个代码库、几百本书），以及训练截止后的事情不知道。RAG（检索增强生成）用"开卷考试"的思路同时解决两个问题：

flowchart LR
    subgraph 离线["离线索引（写路径）"]
        DOC[文档库] --> CHUNK[切分 Chunking]
        CHUNK --> EMB[Embedding 向量化]
        EMB --> VDB[(向量数据库<br/>+ BM25 倒排索引)]
    end
    subgraph 在线["在线查询（读路径）"]
        Q[用户问题] --> QE[查询向量化]
        QE --> RET[检索<br/>top-k 相关片段]
        RET --> RER[可选: 重排序 Rerank]
        RER --> GEN["LLM 生成<br/>问题 + 检索片段 → 回答"]
    end
    VDB --> RET

作者的一个重要判断：RAG 系统的成败在检索器，不在生成器。检索不到正确材料，生成模型只能"基于错误的证据一本正经地编"。上篇那个合同审查案例就是活例子。

1.2 两派检索算法

词项检索（BM25/Elasticsearch） 向量检索（Embedding）
原理 词面匹配 + 词频统计 语义相似度
强项 精确词命中（型号、ID、专有名词）、轻量、可解释 同义改写、跨语言、模糊查询
弱项 “汽车"搜不到"轿车” 精确 ID 反而可能搜偏
成本 极低 索引/查询都要算 embedding

实战结论是混合检索（hybrid search）：BM25 和向量检索各跑一遍，按 RRF（Reciprocal Rank Fusion）之类的方法融合排序。词项检索是非常强的 baseline，书里的建议是先用 BM25 起步，验证检索确实是瓶颈后再上向量检索，而不是反过来。

1.3 踩坑记录

踩坑 1：chunk 一刀切。 按固定 500 token 切分，把表格拦腰切断、把"问题"和"答案"切进不同 chunk，检索回来全是语义残缺的碎片。改法：按文档结构切（标题层级、段落边界），代码按函数/类边界切，表格整存。chunk 之间留 10%-20% 重叠（overlap），缓解边界处上下文丢失。

踩坑 2：只评估端到端，不看召回率。 RAG 至少要分开盯两个指标：检索的 top-k 召回率（正确片段在不在结果里）和生成的忠实度（回答有没有超出检索内容瞎编）。前者低改检索，后者低改 prompt 或模型——混为一谈就会像无头苍蝇。

踩坑 3：元数据过滤用晚了。 知识库里混着 2020 年和 2025 年的制度文档，用户问"年假几天"，检索回来旧制度。给 chunk 打上时间、部门、文档类型等元数据，检索时先过滤再排序，比换更大的 embedding 模型有效得多。

成功案例：我们给一个内部知识库做问答，初期纯向量检索，员工搜报销系统名称"易快报"时召回很差（专有名词语义模糊）。加上 BM25 混合检索后这类 query 的召回率从 61% 提到 93%，整体满意度显著提升。教训：语义检索不是万能升级，词面匹配在专有名词场景不可替代。

二、Agent：让模型当规划者

2.1 从 RAG 到 Agent：一脉相承

书里有个很妙的视角：RAG 是 Agent 的特例——检索器只是模型可用的一件工具。推而广之，给模型配上更多工具（搜索、计算器、数据库、代码执行、API），让它自己规划"先做什么、再做什么"，就成了 Agent。

flowchart TB
    GOAL[任务目标] --> PLAN["规划 Planning<br/>模型分解任务、生成步骤"]
    PLAN --> ACT["执行 Action<br/>调用工具"]
    ACT --> OBS["观察 Observation<br/>读取工具返回"]
    OBS --> REFLECT{"反思 Reflection<br/>结果对吗？目标达成了吗？"}
    REFLECT -- 继续 --> PLAN
    REFLECT -- 完成 --> OUT[最终输出]
    subgraph MEM["记忆系统 Memory"]
        M1[短期: 对话/执行历史]
        M2[长期: 向量库/知识库]
    end
    PLAN -.读取/写入.-> MEM

Agent 由三要素定义：环境（它感知和操作的世界）、工具（它能调用的动作集）、规划能力（模型分析任务、选路径的脑力）。规划是瓶颈——复杂任务需要多步推理，模型的规划能力决定了 Agent 的上限，所以 Agent 类应用对模型能力最敏感。

2.2 失败模式与工程约束

书里对 Agent 的警告很直接：自动化程度越高，失败越灾难性。典型失败模式：

  • 规划错误：任务分解就错了，后面越努力越离谱；
  • 工具调用错误：参数编错、调错工具、幻觉出不存在的 API；
  • 循环失控：反复重试同一个失败动作，token 烧光任务没进展；
  • 复合错误：单步准确率 95% 看着不错，10 步下来整体成功率只有 0.95¹⁰ ≈ 60%。

对应的工程约束（都是血泪换来的常识）：

# 1. 硬性步数上限，防止失控循环
MAX_STEPS = 15

# 2. 每次循环检查预算（步数/token/钱）
for step in range(MAX_STEPS):
    if budget.exceeded():
        return fallback_answer("任务超出预算，转人工处理")
    action = plan_next(state)
    result = execute(action)
    state.update(action, result)

# 3. 不可逆操作（发邮件、删数据、支付）必须人工确认
if action.risk_level == "high":
    require_human_approval(action)

失败案例：某团队的客服 Agent 有"查询订单"和"退款"两个工具。一次上游 LLM 提供商抖动了几次超时，Agent 把超时误判为"查询失败"，触发了它的兜底逻辑——居然直接走了"退款"流程安抚用户。一晚上误退几十单。教训有三：工具的失败语义要精确（超时 ≠ 业务失败）、写操作必须和读操作分级管理、Agent 的所有写操作要留可审计日志。

感悟：Agent 的工程本质是"给概率系统装刹车"。演示 Demo 里 Agent 行云流水，是因为 Demo 只跑了成功路径。生产化的工作量 80% 在失败路径上。

三、微调：什么时候才轮到你上场

3.1 微调 vs RAG：决策树

这是被问得最多的问题，书里给的思路可以画成决策树：

flowchart TB
    Q1{"模型缺的是<br/>知识还是行为？"}
    Q1 -- "缺知识<br/>（不知道你公司的产品、最新政策）" --> RAG["选 RAG<br/>知识更新快、可溯源"]
    Q1 -- "缺行为<br/>（知识够，但格式/风格/领域表达不对）" --> Q2{"提示工程 + few-shot<br/>能教会吗？"}
    Q2 -- 能 --> PE["停在提示工程<br/>最便宜、迭代最快"]
    Q2 -- 不能 --> FT["微调 Finetuning"]
    Q1 -- "都缺" --> BOTH["RAG + 微调组合<br/>常见的企业方案"]

一句话记忆：RAG 给模型"资料"，微调教模型"习惯"。需要频繁更新的知识走 RAG（改数据库就行）；稳定的领域行为（医疗报告的书写规范、固定输出格式）走微调。

不微调的理由同样重要：微调需要高质量标注数据（最难的部分）、引入模型管理复杂度、基础模型升级后可能要重训、还可能损害模型的通用能力（灾难性遗忘）。

3.2 PEFT 与 LoRA：微调的平民化

全参数微调动辄几百 GB 显存，普通团队玩不起。于是有了一类叫 PEFT（Parameter-Efficient Fine-Tuning，参数高效微调） 的技术：共同思路是冻结绝大部分原模型权重，只训练一小撮新增或挑选出来的参数。家族成员包括 Adapter（在层间插小模块）、Prefix/Prompt Tuning（只学一段可训练的"软提示"向量）等，其中目前最主流、事实标准的是 LoRA。

LoRA（Low-Rank Adaptation）的思路是：冻结原模型权重，只训练一对低秩矩阵来近似权重的变化量 ΔW ≈ A·B：

flowchart LR
    X[输入 x] --> W["原始权重 W<br/>（冻结，不训练）"]
    X --> A["低秩矩阵 A<br/>（可训练）"]
    A --> B["低秩矩阵 B<br/>（可训练）"]
    W --> SUM((+))
    B --> SUM
    SUM --> Y[输出 y = Wx + BAx]

好处实打实：

  • 可训练参数量降到 0.1%-1%，显存需求砍掉一个数量级；
  • 模块化：一个基础模型可以挂多个 LoRA"插件"——客服一个、营销一个，推理时按需加载，不用每个场景部署一份完整模型；
  • 推理时可以把 LoRA 权重合并回主干，零额外延迟。

踩坑 4：LoRA rank 不是越大越好。 新手直觉是 rank 越大容量越大，但数据量撑不住时，大 rank 只会过拟合得更快。常见起点是 rank=8-16，配合几百到几千条高质量数据，往往比 rank=128 + 脏数据强。微调的效果上限在数据质量，不在参数量——这直接引出了下一章。

3.3 LoRA 的数学原理：手算一遍就懂了

① 前向传播的公式。 设原始权重 $W \in \mathbb{R}^{d \times d}$（冻结），LoRA 用一对小矩阵乘积来近似权重的变化量：

$$ \Delta W = BA, \quad B \in \mathbb{R}^{d \times r},\ A \in \mathbb{R}^{r \times d},\ r \ll d $$

前向计算变成：

$$ y = Wx + BAx = (W + BA)x $$

参数量对比一目了然：全参数微调要学 $d^2$ 个数（$d=4096$ 时约 1677 万）；LoRA 只学 $2dr$ 个（$d=4096, r=16$ 时约 13.1 万，占 0.8%）。省显存的真正大头其实不在参数本身，而在优化器状态：冻结的 $W$ 没有梯度，Adam 也就不必为它存两份和权重一样大的动量张量——全参数微调时那才是真正吃显存的部分。

② 为什么"低秩"够用。 直觉是：预训练已经把模型放在了一个很好的解附近，微调只需要在少数几个方向上做修正，而不是对 $d^2$ 维空间做任意改动。LoRA 论文的实验支持这一点——权重增量的内在秩（intrinsic rank）很低，rank 取 1、2 在很多任务上就能接近全参数微调的效果。$r$ 就是"允许修改的子空间维数"：$r=1$ 时 $\Delta W$ 的所有列都是 $B$ 的倍数，只能表达"沿一个方向拉伸"；$r$ 越大，能表达的修正模式越丰富。

两个工程细节：初始化时 $A$ 用随机高斯、$B$ 全零，这样训练起点 $BA=0$，模型行为和原模型完全一致；实际实现里增量还会乘缩放系数 $\alpha/r$（$\alpha$ 是超参），让换 rank 时不用重调学习率。

③ 手算：一个 $2 \times 2$ 的完整训练步。 取 $d=2, r=1$，冻结权重设为单位阵，输入 $x = [1, 2]^T$，目标输出 $y^* = [0, 0]^T$。假设 $A = [1, 1]$（$1 \times 2$）、$B = [1, 1]^T$（$2 \times 1$），都只有 2 个可训练参数：

$$ W = \begin{bmatrix} 1 & 0 \\ 0 & 1 \end{bmatrix}, \quad A = \begin{bmatrix} 1 & 1 \end{bmatrix}, \quad B = \begin{bmatrix} 1 \\ 1 \end{bmatrix} $$

前向：先算 $A$ 再算 $B$（注意顺序，别先乘出 $\Delta W$，那是 $d \times d$ 的大矩阵，先算 $Ax$ 只需 $O(dr)$）：

$$ Ax = 1 \times 1 + 1 \times 2 = 3, \quad BAx = B \cdot 3 = \begin{bmatrix} 3 \\ 3 \end{bmatrix}, \quad y = Wx + BAx = \begin{bmatrix} 1 \\ 2 \end{bmatrix} + \begin{bmatrix} 3 \\ 3 \end{bmatrix} = \begin{bmatrix} 4 \\ 5 \end{bmatrix} $$

损失：$L = \frac{1}{2} |y - y^*|^2 = \frac{1}{2}(4^2 + 5^2) = 20.5$。

反向：令 $g = y - y^* = [4, 5]^T$，即 $\partial L / \partial y$。梯度沿链路只流向 $A$ 和 $B$，$W$ 不参与：

$$ \frac{\partial L}{\partial A} = B^T g \cdot x^T = \big([1,1] \cdot [4,5]^T\big) \cdot [1,2] = 9 \times [1, 2] = \begin{bmatrix} 9 & 18 \end{bmatrix} $$

$$ \frac{\partial L}{\partial B} = g \cdot (Ax) = \begin{bmatrix} 4 \\ 5 \end{bmatrix} \times 3 = \begin{bmatrix} 12 \\ 15 \end{bmatrix} $$

更新（学习率 $\eta = 0.1$）：

$$ A_{\text{new}} = \begin{bmatrix} 1 & 1 \end{bmatrix} - 0.1 \begin{bmatrix} 9 & 18 \end{bmatrix} = \begin{bmatrix} 0.1 & -0.8 \end{bmatrix}, \quad B_{\text{new}} = \begin{bmatrix} 1 \\ 1 \end{bmatrix} - 0.1 \begin{bmatrix} 12 \\ 15 \end{bmatrix} = \begin{bmatrix} -0.2 \\ -0.5 \end{bmatrix} $$

再走一遍前向验证：

$$ A_{\text{new}}x = 0.1 \times 1 + (-0.8) \times 2 = -1.5, \quad B_{\text{new}}A_{\text{new}}x = \begin{bmatrix} -0.2 \\ -0.5 \end{bmatrix} \times (-1.5) = \begin{bmatrix} 0.3 \\ 0.75 \end{bmatrix}, \quad y_{\text{new}} = \begin{bmatrix} 1.3 \\ 2.75 \end{bmatrix} $$

新损失 $L_{\text{new}} = \frac{1}{2}(1.3^2 + 2.75^2) \approx 4.63$。一步梯度下降，损失从 20.5 降到 4.63，全程没碰过 $W$ 的一个元素——这就是 LoRA 训练的全部。

④ 推理时合并。 部署时把增量并回主干：

$$ \Delta W = B_{\text{new}}A_{\text{new}} = \begin{bmatrix} -0.2 \\ -0.5 \end{bmatrix} \begin{bmatrix} 0.1 & -0.8 \end{bmatrix} = \begin{bmatrix} -0.02 & 0.16 \\ -0.05 & 0.4 \end{bmatrix}, \quad W_{\text{merged}} = W + \Delta W = \begin{bmatrix} 0.98 & 0.16 \\ -0.05 & 1.4 \end{bmatrix} $$

验证：$W_{\text{merged}} x = [0.98 + 0.32,\ -0.05 + 2.8]^T = [1.3,\ 2.75]^T$，和上面分开算的结果完全一致。合并后就是一个普通矩阵乘法，零额外推理延迟就是这么来的。

（这个玩具例子里 LoRA 是 4 个参数、全参数也是 4 个，省不了——节省只在 $r \ll d$ 的大矩阵上出现。）

四、数据工程：质量、覆盖、数量

第 8 章是全书最"脏活累活"的一章，也是我最推荐反复读的一章。数据集设计三准则：

flowchart TB
    D[数据集三准则] --> Q["质量 Quality<br/>标注准确、格式一致、无噪声"]
    D --> C["覆盖 Coverage<br/>覆盖真实场景的多样性<br/>含边界情况和失败样例"]
    D --> N["数量 Quantity<br/>够用即可，边际收益递减"]
    Q -.->|"少量高质量 > 大量噪声"| LESSON["核心教训"]
    C -.-> LESSON
    N -.-> LESSON

几个反直觉的要点：

  • 少量高质量数据胜过大量噪声数据。LIMA 等研究表明，1000 条精心策划的指令数据可以让模型行为对齐得相当好；
  • 合成数据是主力补给，但必须评估。用大模型生成训练数据已经是标准操作（比如用 GPT-4 造指令数据微调小模型，即蒸馏），但"AI 生成的数据"和"AI 生成的内容"一样需要评估把关。人们更倾向于使用自己能可靠评估的合成数据；
  • 最难的不是标注，是写标注规范。“什么叫好答案"没想清楚的团队，标注出来的数据就是标注员个人偏好的大杂烩。

踩坑 5：合成数据近亲繁殖。 用模型 A 生成数据训练模型 B，再用 B 生成数据训练 C…… 几轮下来多样性塌陷，模型只会说"AI 腔”。书外研究（model collapse）也印证了这点。对策：合成数据里持续掺真实数据、定期用多样性指标（如 n-gram 去重率）体检。

成功案例：一个做 SQL 生成的朋友团队，微调数据从"网上爬的 5 万条 SQL 问答"换成"自己业务库表结构 + 人工审核的 3000 条"，效果反而大幅提升。爬虫数据里大量通用示例和他们的业务 schema 无关甚至冲突。覆盖你的真实分布，比堆量重要得多。

五、推理优化：先懂指标，再谈优化

5.1 延迟的两段式结构

自回归生成决定了延迟不是单一数字：

sequenceDiagram
    participant U as 用户
    participant S as 推理服务
    U->>S: 发送 prompt
    S->>S: Prefill 预填充阶段<br/>并行处理全部输入 token
    S-->>U: 第一个 token (TTFT)
    loop Decode 解码阶段（逐 token 串行）
        S-->>U: 第 2, 3, ... N 个 token (间隔 = TPOT)
    end
  • TTFT（Time To First Token）：首 token 延迟，由 prefill 阶段决定。长 prompt 的应用（塞了一大段检索内容的 RAG）TTFT 高；
  • TPOT（Time Per Output Token）：每个输出 token 的间隔，由 decode 阶段决定。长输出的应用（写报告）对 TPOT 敏感；
  • 吞吐量和延迟存在权衡：batch 开大吞吐高、单价低，但单请求延迟上升。

实战含义：流式输出（streaming）是最便宜的"延迟优化"——总时长没变，但用户感知延迟从"整个生成时间"变成了 TTFT。聊天场景不流式输出基本不可接受。

5.2 优化手段地图

flowchart TB
    OPT[推理优化] --> MO["模型级优化<br/>（会改变模型本身）"]
    OPT --> SO["服务级优化<br/>（模型不动，改服务方式）"]
    MO --> Q[量化 Quantization<br/>FP16→INT8/INT4，省显存提速]
    MO --> D[蒸馏 Distillation<br/>大模型教小模型]
    MO --> KV[KV Cache 管理<br/>注意力机制优化]
    SO --> B[连续批处理<br/>Continuous Batching]
    SO --> PC[Prompt 缓存<br/>相同前缀不重算]
    SO --> P[并行策略<br/>张量并行 / 副本并行]
    SO --> PD[Prefill/Decode 分离部署]

对应用开发者（主要用 API 的人）最相关的两条：

① Prompt 缓存（prompt caching）。多轮对话或固定长 system prompt 的场景，重复的前缀不用重复算，省钱省延迟。Anthropic/OpenAI 的 API 都已支持，但要注意缓存按前缀匹配——把变化的内容（时间戳、用户问题）放在 prompt 尾部，稳定内容放头部，否则缓存命中率是零。

踩坑 6：我们就犯过这个错——system prompt 开头嵌了当前时间，每请求都变，prompt cache 从没命中过。把动态部分挪到末尾后，长 system prompt 场景的成本降了约 40%。

② 量化是性价比之王。书里总结"跨场景最有效的技术通常是量化"——INT8 几乎无损，INT4 轻微掉点但显存减半以上。自托管时先用上量化再谈别的。

六、收拢：完整的 AI 应用架构

第 10 章把前面所有技术拼成一张图。一个生产级生成式 AI 应用的典型架构：

flowchart TB
    U[用户] --> GW["模型网关 Model Gateway<br/>认证 / 限流 / 路由 / 审计"]
    GW --> GR1["输入护栏<br/>注入检测 / 敏感词 / PII 脱敏"]
    GR1 --> CTX["上下文增强<br/>RAG 检索 / 记忆 / 用户画像"]
    CTX --> CACHE{"缓存命中？"}
    CACHE -- 是 --> RESP
    CACHE -- 否 --> ROUTER["模型路由<br/>简单问题→小模型<br/>复杂问题→大模型"]
    ROUTER --> LLM[基础模型<br/>+ LoRA 插件]
    LLM --> GR2["输出护栏<br/>事实核查 / 格式校验 / 安全过滤"]
    GR2 --> RESP[响应]
    RESP --> FB["用户反馈采集<br/>点赞/点踩/会话信号"]
    FB --> OBS["可观测平台<br/>指标 / 告警 / 追溯"]
    OBS -.数据飞轮.-> CTX

这张图是按"增量搭建"的顺序理解的——作者的 step-by-step 思路非常实用：

  1. 先增强上下文（RAG/记忆），解决"模型不知道"；
  2. 加护栏，解决"模型乱说"，护栏可以在输入侧、输出侧，或独立服务；
  3. 加网关和路由，解决"多模型管理"：简单 query 走便宜小模型，复杂的走大模型，省钱；
  4. 加缓存降延迟降成本；
  5. 最后才加 Agent 模式，解决"模型不会做"——这是复杂度最高的一步，放最后。

6.1 可观测性与用户反馈

可观测性的核心问题是"理解系统怎么失败的"。LLM 应用的新失败模式（幻觉、注入、格式漂移）要求新指标：除了传统的延迟/错误率，还要跟踪忠实度评分、护栏拦截率、judge 分数趋势、token 成本曲线。日志里要存完整的 prompt 和上下文，否则 bad case 根本无法复盘。

用户反馈是被工程师系统性低估的金矿。点赞点踩、追问、复制回答、重新生成……这些会话信号是迭代评估集和微调数据的免费来源——这就是数据飞轮：

flowchart LR
    P[产品上线] --> U[用户使用]
    U --> F[反馈信号采集]
    F --> E[回流评估集<br/>发现 bad case]
    E --> I[迭代 prompt/检索/模型]
    I --> P

作者因此说"AI 工程比 ML 工程离产品更近"——反馈机制设计传统上是产品的事，但它是模型改进的数据源头，工程师必须介入。

感悟：这张图最值得记住的不是组件本身，而是搭建顺序。见过太多项目第一天就上 Agent + 多模型路由，结果复杂度爆炸、没人知道错误来自哪一层。每加一个组件，系统能力 +1，但失败模式 +N。够用就好，是 AI 架构的第一美德。

七、思考与感悟（下篇）

  1. 检索、工具、微调，本质都是"上下文管理"。 RAG 是把外部知识塞进上下文，工具是把能力塞进上下文，微调是把行为烙进权重。选哪种取决于：变化的频率（天天变→RAG，稳定→微调）、成本（上下文 token 费 vs 训练费）、可靠性要求。

  2. 复杂度是敌人，按失败模式的"价格"出牌。 每章读完都有一个共同感受：作者永远在问"这个技术的失败模式是什么"。RAG 的失败在检索，Agent 的失败在规划复合错误，微调的失败在数据，judge 的失败在漂移。工程技术选型 = 选择你承受得起的那种失败。

  3. 数据飞轮是唯一持久的护城河。 模型会商品化，框架会趋同，但"真实用户反馈 → 评估集 → 迭代"这个循环积累下来的数据和评估体系，别人抄不走。

  4. 先把指标立住，再谈优化。 TTFT/TPOT/召回率/忠实度这些指标的意义在于：它们把"感觉变慢了"“感觉变笨了"变成可以定位、可以回归的数字。没有指标体系的优化都是玄学。

八、面试高频题（下篇）

Q1：RAG 和微调怎么选？ 看缺什么：缺知识选 RAG（更新快、可溯源、成本低）；缺行为/格式/风格选微调；都缺就组合。实践顺序：先提示工程，再 RAG，最后微调——按投入产出排序。补充：微调需要高质量标注数据，且可能损害通用能力。

Q2：RAG 效果差，你的排查顺序是什么？ 组件级评估：① 单独测检索召回率——正确片段在不在 top-k；不在则查 chunking、混合检索、元数据过滤、查询改写；② 召回没问题再测生成忠实度——回答是否忠于检索内容；不忠实则改 prompt、加引用约束或换模型。③ 全程保留 bad case 进评估集。

Q3：词项检索和向量检索各自的适用场景？ 词项检索（BM25）：精确匹配强（ID、型号、专有名词）、轻量可解释，但不理解语义；向量检索：同义改写、模糊查询强，但精确词可能搜偏、成本高。生产上常用混合检索 + 融合排序。

Q4：Agent 的单步准确率 95%，为什么 20 步任务成功率不到 40%？怎么改进？ 错误复合：0.95²⁰ ≈ 36%。改进：缩短链路（任务分解更粗粒度）、加反思与自我纠错、关键步骤验证后再继续、步数/预算上限、高风险动作人工确认、提升单步可靠性（更好的工具描述与参数校验）。

Q5：LoRA 的原理是什么？为什么受欢迎？ 冻结原权重，用低秩分解 ΔW≈A·B 学习权重增量，可训练参数降到 1% 量级。优点：显存省一个数量级；数据效率高；模块化——一个基座挂多个 LoRA 插件按需加载；可合并回主干零额外推理开销。

Q6：TTFT 和 TPOT 的区别？各自受什么影响？怎么优化？ TTFT 由 prefill 决定，受 prompt 长度影响——优化：prompt 缓存、压缩上下文、流式输出改善感知；TPOT 由 decode 决定，逐 token 串行——优化：连续批处理、量化、投机解码、更好的硬件利用率。两者存在吞吐-延迟权衡。

Q7：怎么设计一个 AI 应用的护栏体系？ 分层：输入护栏（注入检测、PII 脱敏、话题边界）、生成约束（结构化输出、引用检索内容）、输出护栏（事实核查、安全过滤、格式校验）、动作护栏（工具最小权限、高危操作人工确认）。护栏可放在网关、推理服务或独立组件，关键指标是拦截率和误杀率。

Q8：模型网关（Model Gateway）解决什么问题？ 统一入口做认证、限流、审计、多模型路由（简单问题走小模型省钱）、故障转移（provider 挂了就切换）、缓存。类比微服务里的 API Gateway——当系统里有多个模型、多个 provider 时，它把横切关注点从业务代码里收走。

全书写在最后

把两篇笔记浓缩成一句话：AI 工程 = 用评估驾驭概率，用上下文注入知识，用架构吸收失败。

这本书值得放在手边反复翻。技术细节会过时（明年 Agent 框架肯定又换了一轮），但书里那些思维框架——组件级评估、失败模式分析、先简单后复杂的搭建顺序、数据飞轮——是长期有效的工程直觉。

方糖猫
方糖猫（大可）

18 年后端架构，现在独立做 AI 产品。这里记录 AI 视频、AI Agent 与工程实践。

本文阅读量 次