走到哪一级就该停
这一章是我们的收束章:材料全部出自书,轴是书自己没有画出来的。
它不引入任何新机制。 前十八章讲的是「每一级怎么做」, 这一章只回答一个问题:你现在这个系统,该停在第几级?
1. 这一章讲什么
三句话:
- 这本书看起来是一本「按需查」的配方书,但真正让它区别于同题材材料的, 是每个配方最后那一段「什么时候别用它」——那些反面判据彼此不重复, 收在一起就是一张「别做什么」的清单;
- 书在九个不同的地方,用几乎相同的句式说了同一件事,而它一次都没有给这件事起名字。 我们给它起个名叫**「先简后繁,方向不可逆」**—— 这是我们的命名,不是书里的术语;
- 书在十二处标了价钱,却从没有把它们汇总在一起。 本章第 5 节是那张总表——有了它,前面十八章的每一步都能被换算成同一个单位。
2. 顶层全景:一条从最笨到最贵的加码路线
第 0 级 一条正则 / 一句 SQL ← 能覆盖 95% 就停在这里(第 4 节)
↓ 失败信号:同一件事有十几种写法,规则一条都盖不全
第 1 级 最简形态:切块 + 换成数 + 搜 + 交给模型答
↓ 失败信号:检索日志里精确串没命中、两个领域串台
第 2 级 加检索招数:按字面搜 / 先缩范围 / 改查询 / 补上下文 / 重排
↓ 失败信号:每一招都要人事先挑,而真实问题事先挑不了
第 3 级 让模型自己决定:工具 + 循环
↓ 失败信号:问题问的是实体之间怎么连,任何一块文字里都没有答案
第 4 级 知识图谱:点和带名字的线
贯穿每一级的两条线:
· 每一级都有一句"什么时候别用它" (第 3 节)
· 每一级都标了价 (第 5 节)
图说:注意每一级之间的箭头上写的都是**具体的失败信号**,不是"想要更好的效果"。
这就是第 4 节那条原则的形状。
3. 「什么时候别用它」才是这本书的正文
先说清这一节在讲什么
这本书每一个配方的结构都是固定的:遇到什么麻烦 → 这么做 → 讨论 → 延伸阅读。 而那个「讨论」里,几乎每一次都有一段「什么时候别用它」。
判断(我们的,不是书里的):这些反面判据合起来的价值,超过正面做法本身。 理由是:正面做法在任何一份框架文档 里都找得到,而且写得更全、更新得更快; 而「什么时候别用它」只能来自真的踩过的人。 这本书的作者是一家大型企业采购部门的 AI 负责人—— 全书跑例(供应商合同、质量文件比对标准、采购分析)都来自这个岗位, 那些反面判据的具体程度,和这个背景是对得上的。 如果错,会错在: 如果读者要的是「怎么把一套东西跑起来」, 那正面做法仍然是主体,反面判据只是锦上添花。 判据是:你手上有没有一套已经在跑、但答不准的系统。有,反面判据就比正面做法值钱。
那张清单
下面每一条都出自书,而且彼此不重复(编号后的括号是我们这份拆解里对应的章)。 这张表可以当成一份自查清单:动手加一样东西之前,先在这里找一找它。
| 别做什么 | 什么时候 |
|---|---|
| 别上这一整套 | 一条正则或一句 SQL 能覆盖 95% 的情况(01) |
| 别默认做成聊天机器人 | 仪表盘和搜索界面往往更快也更直观(18) |
| 别选「最好的模型」 | 该选仍然满足要求的最小模型,而且逐个流水线步骤地选(03) |
| 别自己跑模型 | 除非数据受监管不能出网,或者每月调用量大到自建成本低于接口费(03) |
| 别用最贵的切法 | 除非检索质量至关重要——它比上一级贵 10 到 20 倍(07) |
| 别加标注过滤 | 整个 库题材同质、或者没有可筛的标注时(10) |
| 别加按字面搜 | 用户用自然语言提问、没有任何技术标识时(10) |
| 别训分类器选源 | 类别之间大量重叠时——路由错了会彻底丢掉相关文档(10) |
| 别用编假答案那一招 | 问句和文档的风格本来就一致时(11) |
| 别多问几遍 | 用户问的是窄而具体的问题时(11) |
| 别拆子问题 | 问题简单直接时(11) |
| 别补上下文 | 块本身已经有 500 个 token 以上时(12) |
| 别重排 | 只有单一检索源、而且它自己排序已经够好时(12) |
| 别用固定形状的工作流 | 任务需要随机应变地做决定时(13) |
| 别放手让模型自己决定 | 可靠性比灵活性更重要时(13) |
| 别上重型框架 | 早期需求还没摸清的时候(14) |
| 别上图框架 | 固定顺序、没有分支、不需要共享状态时(14) |
| 别把工具做成独立服务 | 单一用途的 agent、工具和逻辑本来就绑在一起时(14) |
| 别把业务数据灌进图 | 问题纯粹是文档层面的时候(15) |
| 别只靠自动出的题 | 它系统性地比真实查询容易(16) |
| 别只看一个指标 | 优化一个部件会悄悄弄坏另一个(16) |
| 别用摘要替代原文 | 摘要只用来过滤和排序,最终答案永远取回完整正文(15) |
| 别用快速搭界面那类工具 | 面向几千用户的对外应用(18) |
| 别把 PDF 一律转成图片再抽字 | 文档是纯文字的时候——贵 10 到 100 倍,而且什么也没多买到(18) |
| 别让模型自由写查询语句 | 用户不懂查询语句又问得 含糊时——他们没法验证(18) |
| 别一上来就加那三层 | 原型阶段手工部署就行(18) |
注意这张表里有一半以上的条目,判据是「你的场景是什么样」,而不是「这个做法好不好」。 这就是这本书和一般教程最大的不同。
4. 承重词:「先简后繁,方向不可逆」
这一章唯一的承重词,而且它是我们造的。
先说清楚:这个名字是我们起的,书里没有这个说法,也没有任何一处把这九次串起来。 书说了九遍,一次都没有命名。
一句话先给结论:这条原则有两半—— 前一半是「先从最简单的那一级开始,只有当你在日志里看见那一类具体失败,才加下一级」; 后一半是「往上走容易,往回走难得多」。
九处,原样摆出来
下面九处的共同形状是:「先用 X。只有当你观察到 Y,才加 Z。」
| # | 在哪一节 | 书的说法 |
|---|---|---|
| 1 | 挑框架(01) | 「先从简单开始,复杂度值得了再上框架。 你可以以后再把一个基础实现迁到框架上;反过来——从框架简化回自己实现——难得多。」1 |
| 2 | 分类选源(10) | 「先从纯语义搜索开始。只有当你在检索日志里观察到跨领域混淆时,才加分类。」2 |
| 3 | 混合检索(10) | 「先从语义搜索开始。只有当你在检索日志或用户反馈里看到精确匹配失败时,才加混合检索。」3 |
| 4 | 建索引(09) | 「不到 10 万行,全表扫描常常已经够快,跳过索引;超过 100 万行,索引才是必需的。」4 |
| 5 | 选源三条路(10) | 「先用让模型判断那条验证选源逻辑对不对。等延迟成问题、且各源主题分得清,再换分类器。」5 |
| 6 | 选框架(14) | 「早期避开重型框架。先从直接调接口或轻量框架开始,把需求摸清楚。」6 |
| 7 | 优化图谱(15) | 「别一上来就加这些优化。先从基线图开始,量它的表现。」7 |
| 8 | 让模型写查询(18) | 「生产系统从 agent 做法开始。只有当用户明确要求、而且你的数据库文档扎实时,才加上自由形式的让模型写查询。」8 |
| 9 | 部署(18) | 「对原型来说,手动部署没问题。当你确信这个应用会长期运行、多个开发者需要部署、或者合规要求审计留痕时,再加这三层。」9 |
九处分布在原书的第 1、5、6、7、8、9、11 章——七章里都有。 这不是一句被重复的套话,它是这本书的组织原则,只是没有被写出来。
后一半:为什么它不可逆
这半条书只在一处明说过(上表第 1 行),但全书有两组事实在支撑它,而它们方向相反:
── 可逆的那一侧:换存放向量的库 ──
那些数(每块 1 536 个) → 原样搬过去,一个都不用重算 ← 贵的部分免了
索引 → 重建一次 ← 这个便宜
书自己的话:"你必须重建索引,但不需要重新生成那些数
—— 而生成那些数才是贵的那部分。"
── 不可逆的那一侧:框架 ──
"从框架简化回自己实现,难得多"
"框架锁定会随时间复利"
"图框架的状态管理强加了一种结构,很难迁走
—— 迁走意味着把整套状态流转和转移逻辑重新实现一遍"
图说:两侧不对称,而且不对称的方向决定了该在哪儿谨慎。
换库随时可以换,所以先用简单的库完全没有风险;
换框架很难换,所以"早期避开重型框架"这条建议才是有分量的,不是洁癖。
判断(我们的,不是书里的):这两组事实分散在原书的第 6 章和第 8 章, 而书从来没有把它们放在一起过。 放在一起之后,那条「先简后繁」才从一句正确的废话,变成一条可以执行的判据: 凡是「以后换很便宜」的选择(存哪个库、用哪个换算模型的哪一档、切多大的块), 尽管先挑最简单的;凡是「以后换很贵」的选择(框架、状态怎么组织、工具接口怎么定义), 才值得在一开始就多想一步。 如果错,会错在: 换换算模型其实也是不可逆的一侧(要整库重算), 而我们把它归在了「便宜」那一栏——准确的说法是:换库便宜,换换算模型贵。 判据是:这次改动会不会让你重新跑一遍入库流水线。会,就是贵的那一侧。
5. 书在十二处标了价,而它从没汇总
这是这一章第二件事,也是最实用的一件。
下面十二处全部出自书。它们分散在原书的第 1、2、3、4、5、6、7、8、11 章, 而全书没有一处把它们放在一起。
| # | 这一步 | 书标的 价 | 在我们哪一章 |
|---|---|---|---|
| 1 | 上框架 | 2 到 3 个依赖 → 50 个以上;「100 个以上依赖的项目,要多花的排查功夫远超只用 5 到 10 个核心库的」10 | 01、14 |
| 2 | 挑模型的档位 | 每百万输入 token,从 0.05 美元到 30 美元(不同档位之间),而同一档位里各家的差价很小11 | 03 |
| 3 | 自己跑模型的门槛 | 8B 的模型至少要 8 GB 显存,13B 要 16 GB 以上;70B 级别装不进多数笔记本12 | 03 |
| 4 | 用多模态模型抽文字 | 书在两处给了两笔账,基线不同: 每页单价,文字识别对多模态差 100 倍(原书第 3 章)· 整份文档,比直接抽文本层贵 10 到 100 倍;100 页 0.05 美元对 0.50 到 2.00 美元(原书第 11 章)13 | 05 §4 · 18 §7 |
| 5 | 最聪明那种切法 | **比上一级贵 10 到 20 倍;**500 块的文档要 30 到 60 分钟、15 到 40 美元14 | 07 |
| 6 | 训分类器选源 | 额外 10 到 20 毫秒的推理延迟,外加标注数据和定期重训15 | 10 |
| 7 | 建索引 | 20 万条:不建 85.582 毫秒,建多层图 13.927 毫秒——快约六倍,代价是结果从「保证最近」变成「大概率最近」16 | 09 |
| 8 | 让模型判断该查哪个源 | 每次请求加 500 毫秒到 2 秒; 换成小分类器只加 10 到 50 毫秒17 | 10 |
| 9 | 多问几遍 | 检索时间和算力大致翻三倍(三次额外搜索 + 一次模型调用)18 | 11 |
| 10 | 把问题拆成子问题 | 书写「多两次模型调用」(一次拆、一次合成)外加多次检索19;但按书自己给的步骤,五个子问题还要各生成一段答案——数出来是 7 次(第 11 章第 7 节数过) | 11 |
| 11 | 补上下文 | 每块 1 000 个 token 扩到 3 000,上下文翻三倍,成本和延迟一起涨20 | 12 |
| 12 | 并发跑 vs 串行跑 | 三页扫描件:19 + 34 + 38 秒,串行至少 90 秒,并发实测 49 秒21 | 13 |
| — | 挂在线上本身 | 1 核 2 GB 的容器 7×24 跑着,每月 30 到 40 美元(与有没有人用无关)22 | 18 |
这张表最该被读出的一件事:代价的量级差得非常远。
加一次模型调用 几百毫秒、几分钱 ← 招数类的代价大多在这一档
建一次索引 一次性,换六倍速度 ← 一次投入,长期收益
换一种抽文字的方式 10 到 100 倍 ← 这一档要认真算
换一种切法 10 到 20 倍 ← 同上
上一个重型框架 没有标价 ← **书唯一没标 价的一级,而它恰恰是不可逆的那一级**
图说:最后一行是我们看这张表时最在意的一点。
书给九种招数都标了价,却没给"上框架"这件事标价 ——
它只说了"锁定会随时间复利",而那不是一个数。
6. 全书没有一次对照实验
这一节讲这本书的证据结构,而这件事读者有权知道。
全书只有两组实测
通读下来,书里带真实测量数字的地方只有两处(两处我们都在正文里核过):
| 实测 | 数字 | 出处 |
|---|---|---|
| 建索引前后的查询耗时 | 85.582 毫秒 → 13.927 毫秒 | 第 09 章 |
| 并发跑与串行跑 | 19 / 34 / 38 秒,总共 49 秒,串行至少 90 秒 | 第 13 章 |
而且这两组都没有交代测量条件——什么机器、什么配置、什么模型,一个字没有。
其余全是作者的从业经验
这不是指责,是分类。 书里那些「10 到 20 倍」「500 毫秒到 2 秒」「50 个并发」 「至少 50 到 100 对题」「80% 以上算合格」——全部是作者给的经验数,没有一处给了来源。
判断(我们的,不是书里的):这决定了该怎么用这本书里的数。 它们是量级,不是基准。 「10 到 20 倍」的意思是「这一级明显更贵,要认真算」, 而不是「你会付出 14.7 倍」。 拿它们做决策的方向判断可以;拿它们做预算或者写进技术方案当依据,不行。 如果错,会错在: 如果这些数在作者的实际项目里都测过、只是没写进书, 那它们的可信度会比「凭印象」高得多——而这一点无从核实。 判据是:书里有没有一处写「我们测了」。除了那两组毫秒数,没有。
作者的岗位决定了全书跑例的形状
这一条影响的是「这本书适不适合你」:
作者是一家大型能源企业采购部门的 AI 负责人。
全书跑例: 供应商合同 · 服务级别协议 · 质量文件比对标准 · 采购支出 ·
发票 · 议价邮件 · 职位描述
这些例子的共同形状:
· 文档是**长的、结构化的、法务或工程性质的**
· 用户是**企业内部员工**,不是消费者
· 数据量是**几万到几十万份**,不是几亿
· 对**可核对、可审计**的要求高于对响应速度的要求
图说:如果你要做的是面向消费者的问答、或者几亿条数据的检索,
书里那些经验阈值(10 万行、50 个并发、每类 100–200 个标注块)可能都不适用。
但那些**反面判据**大多仍然成立 —— 它们讲的是机制,不是规模。
7. 它明确不覆盖什么,其中三处是张力
书自己在各处坦白了不少缺口。下面按「只是空白」和「是张力」分开。
只是空白的(书没讲,但不矛盾)
- 知识库怎么更新和删除。 文档改了一版、某份合同作废了,已经入库的那些块怎么办—— 全书没有一处讲增量更新或删除;
- 线上怎么监控。 第 16 章讲了评测,但「跑在线上的时候拿什么盯着」没接上;
- 访问控制怎么落地。 「只搜有权限的文档」在查询语句里长什么样讲了, 但用户身份从哪来、怎么和那道闸接上,没写;
- 总成本没有一处汇总。 上面第 5 节那张表是我们拼的,书自己从没算过一套系统每月多少钱;
- 让模型当法官的那个法官准不准。 全书没有一句;
- 工具太多会怎样。 三个工具时模型挑得准,三十个呢?没讨论;
- 图怎么从别的领域设计出来。 那五种点、五种线是作者按采购场景画的, 换一个领域怎么画、能不能让模型自动抽,没讲。
三处是张力(书里两处说法互相拉扯,而它没有调和)
张力一:块该切多大、重叠该设多少。
书在示例里出现过的块长度:250 字符 · 250 token · 1 000 字符 · 1 000 token
书在示例里出现过的重叠: 200 字符
而这五个值,**书一次都没有解释为什么是这个数**。
张力在于:第 12 章那一整章的存在理由,就是"块该多大"这个两难无解;
可书在别处又反复给出具体数值,像是它有答案。
张力二:上下文窗口到底是不是硬约束23。
第 1 章开篇(讲为什么需要检索):
"它们的上下文窗口限制了一次能考虑多少信息,
这让长文档要么很贵、要么根本没法一次分析完。"
第 2 章(讲挑哪家模型):
"某家的模型支持约一百万 token 的上下文窗口,
为跨文本、音频、图像、视频乃至源码仓库的长上下文推理而设计。"
张力在于:如果一次能读一百万 token,那"长文档没法一次分析完"这条理由还剩多少?
**书两处都说了,但从没有回头处理这个矛盾。**
图说:这不是书写错了 —— 两句话各自都对。
缺的是那一句:"窗口变大之后,检索的理由从『读不完』变成了『读得起吗、读得准吗』。"
(这句补充是我们的判断,不是书里的。)
张力三:「先简后繁」和「一开始就该考虑好」。
书一边说:"早期避开重型框架,先摸清需求"(第 8 章)
一边又说:"框架锁定会随时间复利"(同一节)
这两句合起来其实是自洽的 —— 正因为锁定会复利,才要晚一点再锁。
可书没有把这层因果写出来,于是读起来像两条互相拉扯的建议。
图说:第 4 节那个"可逆 / 不可逆"的对照,就是我们为这一处补的那一层。
8. 主走查:第 1 章那个制造商场景,从第 0 级加到第 4 级
这是本章的主走查,前面每一节都在它上面占一步。 用的是原书第 1 章那个真实场景24。
(场景本身、每一级的启动条件和每一处标价都是书里的; 下面的文件数、块数、每月成本演算是我们为演示编的。)
场景(书给的原样)
制造商每天从供应商那里收到数以千计的质量文件。 系统抽取关键信息、拿去和库里的标准比对、检查合规、生成报告; 如果信息缺失或者某个参数不合规(比如焊接厚度), 就自动查出这家供应商的联系人,起草一封跟进邮件。
第 0 级:一条正则
做法:写正则,从每份文件里抓"焊接厚度: __ mm",和标准里的范围比。
这一级的启动条件(反过来说,就是停在这里的条件):
**一条正则或一句 SQL 能覆盖 95% 的情况,就别往上走。**
实际撞墙的地方:
供应商 A 写 "Weld thickness: 3.2 mm"
供应商 B 写 "焊缝厚度 3,2mm"(逗号小数点、无空格)
供应商 C 写在表格里,"厚度" 和 "3.2" 隔着两个单元格
供应商 D 写 "板厚 3.2(符合 EN 10025)"
→ 正则能盖住 A,勉强盖住 B,盖不住 C 和 D。
覆盖率大概七成 —— 不到 95%,所以往上走。
(这四种写法和七成这个数是我们为演示编的。)
这一级的价:几乎为零。
第 1 级:最简形态
做法:文件转文字 → 切块 → 每块换成一串数 → 存库 →
提问时按意思搜 → 取回几块 → 交给模型答。
这一级要付的(照第 5 节那张表):
扫描件走多模态抽文字 比抽文本层贵 10 到 100 倍
→ 每天 3 000 份、平均 3 页 = 9 000 页
→ 按 100 页 0.50 到 2.00 美元折算,每天 45 到 180 美元
→ 每月约 1 350 到 5 400 美元 ← **这是这一级最大的一笔**
换算那些数 一次性,量小
挂在线上 每月 30 到 40 美元
这一级停得住吗?
停得住,如果问的都是"这份文件的焊接厚度是多少"这类直接问题。
实际撞墙的地方:
用户问 "EN 10025 里对 S355 的焊接要求是什么"
→ 纯按意思搜命中一堆讲焊接的通用段落,漏掉 "EN 10025" 那一条
→ **检索日志里看见了精确串没命中** ← 这就是第 2 级的启动条件
第 2 级:加检索招数
照书的顺序一样一样加,每一样都等到看见对应的失败信号才加:
信号:精确串没命中(标准号、牌号)
→ 加按字面搜 + 排名融合
→ 价:两套检索要维护;查询耗时约翻倍(几十毫秒,可忽略)
信号:问 "这家供应商的合规记录" 却捞回别家的文件
→ 加标注过滤(供应商编号、日期、文件类型)
→ 价:入库时要打标注;查询本 身反而更快(搜索空间小了)
信号:答案的背景常被切在隔壁块
→ 加按位置补上下文
→ 价:1 000 token 扩到 3 000,**上下文翻三倍**
信号:上面几招同时产出几十个候选
→ 加重排
→ 价:每次问答多一次模型调用
这一级停得住吗?
停得住,而且书的态度是:**多数系统就该停在这里。**
第 11 章那句"改进检索这一步是提高准确率最有效的办法",说的正是这一级。
实际撞墙的地方:
"这份文件焊接厚度不合规,查出供应商联系人并起草跟进邮件"
→ 这不是一次检索能完成的:要判断合规、要查联系人、要写邮件
→ **每一步该走哪条路,事先挑不了** ← 第 3 级的启动条件
第 3 级:让模型自己决定
做法:把上面那些能力包装成工具 —— 查标准、查供应商联系人、比对参数、起草邮件;
模型在循环里自己决定这一次该调哪个、传什么参数。
价(照第 5 节那张表):
每次交接都是一次完整的模型调用
一份文件从"读进来"到"发出邮件",大约 4 到 6 次模型调用
→ 比第 2 级的一次调用多出四五倍
(4 到 6 这个数是我们为演示编的)
同时白得的:
并发跑起来,一份三页的文件从串行 90 秒降到约 49 秒(书的实测量级)
这一级停得住吗?
书的判断是:**生产系统就该从这一级开始**——
它在最后一章明说"生产系统从 agent 做法开始"。
实际撞墙的地方:
"哪些高支出的供应商,合同里缺少解约条款?"
→ 这个问题的答案**不在任何一块文字里**,它在实体之间的关系里
→ 第 4 级的启动条件
第 4 级:知识图 谱
做法:把公司、地址、合同、条款、条款类型建成点和带名字的线;
再把支出、国家、行业这些业务属性灌进来。
价:
书自己的坦白:"更高的复杂度和成本,需要仔细的数据建模、
结构化的入库、更多的前期工作"
**而这一级书一个数都没标** ← 和"上框架"一样,是没有标价的那一类
这一级值不值:
书给的判据只有一句:**"当关系本身要紧、而最终答案取决于实体之间怎么连接时。"**
实际撞墙的地方(这一级之后书就没有了):
条款分类靠关键词匹配,匹配不上就打成"其他" ——
而全章的检索质量建在这条规则上,书没有量过它的失效率(第 15 章)。
把五级放在一起看
这一级买到了什么 这一级的价 书标价了吗
第 0 级 覆盖固定格式 ≈ 0 —
第 1 级 听得懂"发货改期 = 因天气延误" 抽文字 10–100 倍 ✓
第 2 级 精确串搜得到、范围缩得小 每招几十毫秒到一次调用 ✓
第 3 级 不必事先挑走哪条路 模型调用多四五倍 部分
第 4 级 答得了"缺了什么" **书没标价** ✗
图说:最后一列是这条走查最该被记住的东西 ——
**书给"招数"标了价,没给"换一整套架构"标价。**
而恰恰是后者不可逆(第 4 节)。
9. 我们对这本书的总判断
判断(我们的,不是书里的):这本书的价值不在「教你搭一套 RAG」, 在「教你什么时候别往上加」。 同题材的材料里,正面做法到处都有,而且写得更全、更新得更快; 而这本书那二十多条反面判据,以及那九处「先别急着上这一级」, 是同题材里最少见的东西。 如果错,会错在: 如果你手上还没有一套在跑的系统, 那反面判据对你来说是空的——你还没撞到过那些墙,读了也记不住。 判据是:你有没有一套已经在跑、但答不准的系统。 有,这本书从第 10 章读起最划算;没有,先读第 01、02、18 三章就够了。
判断(我们的,不是书里的):这本书最该被补的一处,是它自己没有画出的那张成本总表。 十二处标价散在九个章节里,而做技术选型的人恰恰需要把它们放在一起看。 本章第 5 节就是我们补的那张表。 如果错,会错在: 配方书的体例本来就是「按需查」,不汇总是设计使然,不是疏漏。 判据是:书的前言有没有说它是给「从头读到尾」的读者写的。 它说了——前言写的组织法是「按建一套系统的自然顺序:核心概念到生产部署」。 既然是按顺序组织的,汇总就该有。
10. 可带走的
- 每个配方后面那句「什么时候别用它」才是这本书的正文。 二十多条,彼此不重复,收在一起就是第 3 节那张自查清单;
- 动手加一样东西之前,先在那张清单上找一找它。 一半以上的条目,判据是「你的场景是什么样」,而不是「这个做法好不好」;
- 书说了九遍、一次没命名的那条原则,我们叫它「先简后繁,方向不可逆」—— 这是我们的命名,书里没有这个说法;
- 它的前一半:先从最简单的那一级开始,只有当你在日志里看见那一类具体失败, 才加下一级。 九处分布在原书七个章节里;
- 它的后一半:往上走容易,往回走难得多。 书只在讲框架时明说过一次;
- 可逆的那一侧:换存放向量的库——要重建索引,但不必重算那些数,而那才是贵的部分。 不可逆的那一侧:框架——锁 定会随时间复利,迁走要重写整套结构;
- 由此得到一条可执行的判据:以后换很便宜的选择(存哪个库、切多大的块), 尽管先挑最简单的;以后换很贵的选择(框架、状态怎么组织),才值得一开始就多想一步。 一句话分辨:这次改动会不会让你重新跑一遍入库流水线;
- 书在十二处标了价,却一次没有汇总。 第 5 节那张表是那份汇总;
- 代价的量级差得很远: 加一次模型调用是几百毫秒几分钱; 换一种抽文字的方式是 10 到 100 倍;而「上一个重型框架」书根本没有标价—— 偏偏那一级是不可逆的;
- 全书没有一次对照实验。 唯二的实测是建索引前后的毫秒数和并发与串行的秒数, 而这两组都没交代测量条件;
- 所以书里那些数是量级,不是基准。 做方向判断可以,写进预算不行;
- 作者的岗位决定了全书跑例的形状(长的、结构化的、法务或工程性质的企业文档); 规模类的阈值可能不适用于你,但那些反面判据大多仍然成立——它们讲的是机制,不是规模;
- 三处张力值得记住: 块该多大(书给了五个数,一次没解释)、 上下文窗口到底是不是硬约束(第 1 章说读不完、第 2 章说支持一百万 token)、 以及「先简后繁」和「锁定会复利」之间那层书没写出来的因果;
- 这本书从第 10 章读起最划算——前提是你手上已经有一套在跑、但答不准的系统。
11. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 正则或 SQL 能覆盖 95% 就别上 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:114(搜「handles 95% of cases」) |
| 制造商那个场景 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:104(搜「thousands of quality documents daily」) |
| 依赖数与「反过来难得多」 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:594(搜「2–3 dependencies instead of 50+」) · text/03-ch01-chapter-1-getting-started-with-rag.txt:596(搜「Going in the opposite direction」) |
| 档位之间的价差 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:303(搜「$0.05 to $30 per 1M input tokens」) |
| 上下文窗口是硬约束 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:6(搜「Their context windows limit how much information」) |
| 一百万 token 的窗口 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:354(搜「context windows of around one million tokens」) |
| 自己跑模型的显存门槛 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:595(搜「at least 8 GB of virtual random access memory」) · text/04-ch02-chapter-2-foundation-models.txt:597(搜「millions of API calls per month」) |
| 最贵那种切法的价 | Chapter 4. Data Preparation | text/06-ch04-chapter-4-data-preparation.txt:988(搜「10 to 20 times more expensive」) |
| 先纯语义搜索,看到串台才加分类 | Chapter 5. Embeddings | text/07-ch05-chapter-5-embeddings.txt:676(搜「Add classification only when you observe」) |
| 分类器的延迟 | Chapter 5. Embeddings | text/07-ch05-chapter-5-embeddings.txt:678(搜「typically 10–20 ms」) |
| 先语义搜索,看到精确匹配失败才加混合 | Chapter 5. Embeddings | text/07-ch05-chapter-5-embeddings.txt:833(搜「Add hybrid search only when you observe」) |
| 原型不需要分布式向量库 | Chapter 6. Vector Databases and Similarity Searches | text/08-ch06-chapter-6-vector-databases-and-similarity-search.txt:181(搜「choosing based on benchmarks instead of workflow」) |
| 换库不必重算那些数 | Chapter 6. Vector Databases and Similarity Searches | text/08-ch06-chapter-6-vector-databases-and-similarity-search.txt:198(搜「which is the costly part」) |
| 两条规模门槛 | Chapter 6. Vector Databases and Similarity Searches | text/08-ch06-chapter-6-vector-databases-and-similarity-search.txt:832(搜「Above one million rows, indexing becomes essential」) |
| 索引前后的实测 | Chapter 6. Vector Databases and Similarity Searches | text/08-ch06-chapter-6-vector-databases-and-similarity-search.txt:760(搜「Execution Time: 85.582 ms」) · text/08-ch06-chapter-6-vector-databases-and-similarity-search.txt:828(搜「Execution Time: 13.927 ms」) |
| 选源三条路与推荐顺序 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:518(搜「adds latency of 500 ms to 2 seconds」) · text/09-ch07-chapter-7-retrieval.txt:528(搜「Start with LLM routing to validate」) |
| 多问几遍翻三倍 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:405(搜「roughly triples retrieval time」) |
| 拆解多两次模型调用 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:916(搜「Decomposition adds two LLM calls」) |
| 补上下文翻三倍 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:722(搜「Expanding from 1,000 to 3,000 tokens」) |
| 早期避开重型框架 | 第 8 章 · 配方 8.3(选框架) | text/18-fm-discussion.txt:11(搜「expands your security attack surface」) · text/18-fm-discussion.txt:13(搜「Framework lock-in compounds over time」) |
| 并发与串行的实测 | 第 8 章 · 配方 8.5(异步提速) | text/23-fm-solution.txt:133(搜「page 1 took 19 seconds」) |
| 图的代价与什么时候值 | Chapter 9. Graph RAG | text/34-ch09-chapter-9-graph-rag.txt:34(搜「additional complexity and cost」) |
| 别一上来就优化图 | Chapter 9. Graph RAG | text/34-ch09-chapter-9-graph-rag.txt:788(搜「Don't add these optimizations up front」) |
| 生产系统从 agent 做法开始 | Chapter 11. RAG Web Apps | text/36-ch11-chapter-11-rag-web-apps.txt:690(搜「start with the agentic approach」) |
| 多模态抽文字的价 | Chapter 11. RAG Web Apps | text/36-ch11-chapter-11-rag-web-apps.txt:501(搜「10 to 100 times more expensive」) · text/36-ch11-chapter-11-rag-web-apps.txt:503(搜「$0.50–$2.00 for multimodal OCR」) |
| 每月 30 到 40 美元 | Chapter 11. RAG Web Apps | text/36-ch11-chapter-11-rag-web-apps.txt:779(搜「$30 to $40 per month」) |
| 原型手动部署没问 题 | Chapter 11. RAG Web Apps | text/36-ch11-chapter-11-rag-web-apps.txt:799(搜「For prototypes, manual deployment is fine」) |
| 作者的岗位 | About the Author | text/38-fm-about-the-author.txt:4(搜「AI lead for procurement」) |