为什么要先搜一遍 —— 以及什么时候别搜
这一章讲三件事: 这套做法要治的到底是什么病、它最简的样子长什么样、 以及什么时候根本不该用它。
它在全书链条上的位置是第一环。 后面十八章全在回答「怎么做得更好」, 只有这一章在回答「要不要做」——而书自己给的答案是:很多时候不该做。
1. 这一章讲什么
三句话:
- 这一代模型有三样毛病,而且不是「再做大一点就好了」的那种;
- 这三样毛病有一个共同的解法,而这个解法本身简单到只有两个零件;
- 但它有一条能当场判死刑的判据,书把这条判据摆在了第一章。
2. 顶层全景:这一章是四个判断连成的一条线
① 它答不上来 → 不是它不够大,是三个结构上的缺口
↓
② 一次堵三个 → 提问前先去你的资料里搜,把搜到的连同问题一起交给它
↓
③ 但先问一句 → 这件事能不能用一条规则解决?能,就别上这一套
↓
④ 也别急着挑框架 → 依赖从 2、3 个变成 50 多个,而且这个方向走过去容易、退回来难
图说:这一章的四节正文对应这四步。它们是一条线,不是四条并列的建议——
第 ③ 步答「不」的话,后面十八章都不必读。
3. 先看现象:它答不上来的三种方式
这一节 回答:为什么必须有这一整套东西。
你大概碰到过这三种情况:
| 你看到的 | 它其实是哪种缺口 |
|---|---|
| 问它「我们公司的差旅报销上限是多少」,它给了一个听着很正常、但根本不是你们公司的数 | 它碰不到你的资料 |
| 把一份三百页的合同整个贴给它,要么被拒,要么很贵,要么它只答了开头那部分 | 它一次读不完 |
| 问一个它不知道的细节,它不说「我不知道」,而是编一个 | 它宁可编也不认输 |
这三条不是三个 bug,是三个结构上的缺口。 书把它们并列写在第 1 章开篇, 用的词是「根本性的结构限制」1。下面三节各讲一个。
4. 缺口一:你不给它,它就没有
第一条最好理解,也最容易被低估。
这一代模型的本事全部来自训练:事先让它读过海量公开文字,把里面的规律吃进去。 你们公司内部的合同、工单、会议纪要、报价单,它一个字都没读过—— 除非你在提问的时候亲手把它们贴进去。
低估的地方在于:很多人以为「它这么聪明,应该能查到吧」。 它不能。 它没有一个能翻你硬盘的通道,除非你给它建一个——建那个通道就是这本书的全部内容。
5. 缺口二:它一次只端得住那么多字 —— 「上下文窗口」
这一节要讲透的是本章第一个承重词。一句话先给结论:上下文窗口就是它一次能读进去的 那段文字的长度上限。 这个词在书里从头到尾当已知词用、一次没解释过, 而后面十八章的成本讨论全部建立在它上面,所以这一节把它拆开讲。
先讲「上下文」
你每问一次,它实际读到的不只是你刚打的那句话。 它读到的是一整段文字: 你的问题 + 你贴给它的材料 + 这轮对话里之前说过的所有话。 这一整段,就叫这一次的上下文。
再讲「窗口」
这一段有长度上限。上限之内,它全部看得见;超出上限,超出的部分它根本收不到。 这个上限就叫上下文窗口——你在任何一家的接口文档里都会撞见这个名字。
书对这条缺口的说法是:窗口限制了它一次能考虑多少信息, 「这使得长文档要么昂贵、要么根本不可能在一遍里分析完」1。
为什么它同时是钱和时间的闸门
这里要补一层书没交代的:
补充(不在书里,来自通用知识):模型不记事。 它每一次回答,都是把整段上下文重新读一遍。所以在一轮长对话里, 你每问一句,之前说过的全部内容都要再发一次、再被读一次。
于是:
对话第 1 轮 发过去 500 字 便宜、快
对话第 10 轮 发过去 8 000 字 贵 16 倍、慢
对话第 30 轮 超出窗口 最早那几轮被丢掉,它开始"忘事"
图说:这些数是为演示编的,不是真实数值。要看清的是形状——
长度是一路涨上去的,而钱和时间跟着长度走。
所以「一次读不完」不只是「读不完」,还是「读得越多越贵、越慢」。 这正是为什么这本书的做法是只搜出最相关的三四块塞进去, 而不是把整个资料库都塞进去。(按长度具体怎么计价、四个档位差多少钱,第 03 章讲。)
6. 缺口三:它宁可编也不认输 —— 「幻觉」
本章第二个承重词。一句话先给结论:幻觉就是它编出一段看着合理、其实没有依据的内容。 书同样只用了这个词,没解释为什么会这样1。
现象长什么样
你问一个具体的细节,它给出一个格式漂亮、语气笃定、细节丰满的答案—— 而那个答案是假的。 假的引用、假的条款号、假的版本号。 这种「编得像真的」的现象,业界叫它幻觉。
为什么它必然会编
补充(不在书里,来自通用知识): 这台机器的基本动作只有一个—— 照着已有的文字往下续写最像样的下一个词。 「我不知道」在它见过的文字里,极少作为一个技术问题的下文出现; 而一段自信、具体、格式正确的说明,则出现过几百万次。 所以「编一个像样的」恰恰是它在做对它被要求做的事。承认无知才是需要额外教它的行为。
这本书怎么压住它
书的办法朴素得出奇:在给模型的那段话里明确写死「只用我给你的材料回答, 材料里没有就说没有」——于是每一个答案都能追回一份真实的来源2。
这一条是这套做法真正的价值所在,而不是「省钱」或者「更快」: 它把「它说的对不对」变成了一个可以当场核对的问题。
7. 一次治三个:这套做法最简的样子
三条缺口,一个解法:提问的时候先去外部资料里搜一遍, 再把搜到的内容连同问题一起交给模型去写答案3。
它最简的形态只有两个零件4:
用户的问题
↓
┌──────────────┐ 在你自己的文档里搜,返回几段可能相关的文字
│ 搜索器 │ (书打的比方:它像一个只索引你自己文档的搜索引擎,
└──────────────┘ 而不是像谷歌那样索引整个互联网)
↓
┌──────────────┐ 拿这几段当材料,写出一个有依据的答案
│ 模型 │
└──────────────┘
↓
答案(每一句都能指回是哪一段文字支持的)
图说:就这两个零件。后面十八章都是在给这两个零件加零件。
注意一件容易搞混的事:这不是一种产品,也不是一个框架。它是一个动作顺序。 你可以用两百行代码实现它,书的第 1 章就是这么干的—— 它明说不用现成框架,是为了让核心概念保持清楚5。
8. 主走查:一万份供应商合同里,哪些含自动续约条款
这是本章的主走查,前面每一个机制都在这条线上占一步。 场景是书里那张打分表打了 5 分的第一条6。
先交代数据:一万份 PDF 合同,平均每份 18 页。 (除了「一万份」是书里的,其余的数都是为演示编的,不是真实数值。)
第 0 步:先试最笨的办法 —— 一条规 则
「自动续约」在英文合同里最常见的写法是 automatic renewal。写一条规则去搜这个字串:
规则: 匹配 "automatic renewal"
跑完: 命中 3 180 份
然后人工抽查 100 份没命中的,发现漏了这些写法:
"shall automatically renew for successive one-year terms"
"unless either party gives notice, this Agreement renews"
"evergreen term"
"自动展期"(有 400 份是中德双语合同)
图说:这些合同措辞是为演示编的。要看清的是形状——
同一件事有十几种写法,而规则只认你写进去的那几种。
这一步暴露的正是第 3 节那张表里第一行的反面: 规则不理解意思,它只认字面。而这恰恰是它的优点:你知道它漏了什么,因为它的规则是你写的。 (所以这一步不是白跑的——它是第 9 节那条判据的输入。)
第 1 步:把一万份合同变成能搜的东西
1 万份 PDF ──抽出文字──> 纯文本
──切成小块──> 约 42 万块(每块 1 000 字符左右)
──每块换算成一串数──> 42 万串,每串 1 536 个数
──存进库──> 一个能飞快找出"方向最接近的几串"的库
这一整步是离线做的,提问之前就做完了。 它花掉的时间和钱是这套做法的主要开销, 而且只有这一头会碰上第 4 节那条缺口——资料是你的,你得亲手把它送进去。 (每一步怎么做、各花多少,第 04 到 09 章讲。)
第 2 步:提问
问题:「哪些合同含自动续约条款?」
问题也换算成一串数:1 536 个
↓
和库里 42 万串比方向,取最接近的 20 块
↓
取回来的 20 块里,有一块是这样的(为演示编的措辞):
"…this Agreement shall renew for successive one-year terms
unless either party provides written notice ninety (90) days
prior to the expiration of the then-current term…"
关键在这里:这一块里一次都没出现 "automatic renewal" 这两个词。 第 0 步那条规则漏掉了它,而按意思搜把它捞了上来—— 因为「到期后自动延续一年,除非提前通知」和「自动续约」说的是同一件事。
书自己举的例子是同一个道理:供应商说 "delayed due to weather"(因天气延误) 和说 "shipment rescheduled"(发货改期),规则式系统要写两个分支, 而这套做法知道两句话说的是同一件事7。
第 3 步:交给模型,并且把它捆住
把这 20 块连同一句写死的指令一起发过去:
[指令] 只根据下面的合同片段回答。片段里没有的,直接说没有。
每条结论后面必须给出它依据的是哪一份合同的哪一段。
[材料] <20 块文字,合计约 2 万字符>
[问题] 哪些合同含自动续约条款?
图说:第 6 节那条"只用给你的材料回答"就写在第一行。
没有它,模型会拿训练时读过的通用合同知识来答,而你无从分辨。
输出(为演示编的):
含自动续约条款的:12 份
· SUP-0417 第 14.2 条 "shall renew for successive one-year terms…"
· SUP-0912 第 9.1 条 "evergreen term…"
· …
片段里没有提到续约的:8 份
注意它只答了这 20 块。 一万份合同要全部过一遍,得把这个动作重复几百次—— 这就是为什么第 9 节那条判据要问「量够不够大」。
第 4 步:回头给这件事打分
书那张五档表把这个场景打了 5 分,理由写得很短: 「量大到人工审不动,而且是一个抽取任务,输出可以核对。」6
把这两句拆开,正是它值得做的两个理由:
- 量大到人审不动 —— 一万份 × 18 页,一个人一天审 20 份,要两年;
- 输出可以核对 —— 它说 SUP-0417 第 14.2 条含续约条款,你翻开那一页三秒就能确认。
第二条比第一条重要。 下一节那张表里被打低分的那些场景, 栽的几乎都是第二条。
9. 什么时候别用它:一条能当场判死刑的判据
这是全书最硬的一条边界,而且它在劝你别用这本书教的东西。
「如果你能写一条正则或一句 SQL 覆盖 95% 的情况, 上 RAG 只是在增加不必要的复杂度和成本。」8
先把两个名字讲清楚(它们是你出门会撞见的写法):
| 名字 | 它是什么 | 例子 |
|---|---|---|
| 正则(正则表达式) | 一条描述「什么样的字符串算数」的规则 | 「以 INV- 开头,后面跟六位数字」 |
| SQL | 一句查数据库的语句 | 「把金额大于一万的订单按日期列出来」 |
回到第 8 节那条走查:如果那一万份合同不是 PDF,而是一张表,
表里有一列就叫 auto_renewal,值是 0 或 1 —— 那么一句 SQL 就够了,
这一整章、这一整本书,都不必看。
它换来的是什么、赔进去的是什么
书把这笔账算得很干脆:「它拿简单性换灵活性。」9
| 规则式做法 | 这一套 | |
|---|---|---|
| 速度 | 更快 | 慢(每次都要搜一遍、再让模型写一遍) |
| 每次的钱 | 更便宜 | 贵 |
| 失败的方式 | 可预测(它漏了什么,你查一眼规则就知道) | 不可预测(它为什么漏了这一份,你得去查检索日志——系统自己记的流水账:这次搜了什么、取回了哪几块) |
| 边缘情况 | 差(每一种写法都要你手写一个分支) | 好(这是它唯一的优势,但这个优势很大) |
| 要养的东西 | 无 | 模型托管、话术、评测框架 |
「失败方式可预测」这一行是这张表的重心。
一条规则漏了 evergreen term,你补一行就好了;
而按意思搜漏了某一份,原因可能在切块、在换算模型、在取回几块、在排序——
排查一次的成本,和补一行规则完全不是一个量级。
量的门槛:书给了一个具体的数
「一天处理 10 份文档的系统,可能撑不起这套东西的开发成本; 一天处理 1 000 份的,撑得起。」10
这个数配上第 8 节那条走查就有了参照物: 一天 10 份,一个人半小时就审完了;一天 1 000 份,一个人要审两个月。
10. 哪些场景值得:那张五档打分表
书用 1 到 5 分给八个场景打了分,1 分是「没什么价值」,5 分是「最适合」11。 这张表是第 1 章最有用的东西,因为它是八个具体场景,不是八条原则。
| 分 | 场景 | 书给的理由 |
|---|---|---|
| 1 | 「我想和我的季度报告聊天」 | 单份文档、量小。直接读,或者丢进现成的聊天工具就行12 |
| 2 | 「帮我总结这一份文档」 | 通用模型已经做得很好,自建加不了价值13 |
| 2 | 「把高风险决策自动化」 | 能做,但太险——没有人在环(关键决策必须有人过目才生效)、没有审计、没有失效兜底,就别做14 |
| 4 | 会议录音堆着,进不了知识库 | 把拿不到的资料变成搜得到的,但质量取决于转写15 |
| 4 | 技术图纸要对着规格书查 | 人做很烦的比对,但需要强评测和例外处理16 |
| 5 | 一万份合同里哪些有自动续约条款 | 量大到人审不动,抽取任务,输出可核对6 |
| 5 | 客服工单里的产品问题聚不起来 | 跨文档找模式,人在规模上做不到17 |
| 5 | 每天几百封咨询要分派给对的团队 | 重复分类,成功标准清楚、投入产出可测18 |
把这八行压成两句(这是我们的归纳,不是书里的原话)
判断(我们的,不是书里的): 三条 5 分的共同点是「量大 + 输出可核对 + 单条价值低但总量高」; 三条 1–2 分的共同点是「单份、低量、通用模型已经覆盖」。 所以真正的判据不是「我的资料重不重要」,而是**「这件事一天要做多少遍, 以及做错了我能不能一眼看出来」**。 如果错,会错在: 那条打 2 分的「高风险决策自动化」不符合这个归纳—— 它量大、单条价值高,却被打了低分。它是被第三个维度(错了的代价)否掉的, 而我们这条归纳没把那个维度包进去。要用的话,得三个维度一起看。
书给的那个完整例子
第 1 章还给了一个从头到尾的场景,它是全书最完整的一个「高价值」实例19:
制造商每天收到供应商几千份质量文件
↓ 抽取关键信息
↓ 和库里的 ISO 标准比对
↓ 查合规
↓ 出报告
↓ 若某个参数不合规(书举的例子是焊缝厚度)
→ 自动查出这家供应商的联系人 → 起草一封跟进邮件
图说:注意最后两步。它不止是"查得到",它接着 做了一件事。
这就是书说的第二类高价值方向:流程自动化。
这个例子会在第 19 章再出现一次,那时候我们会拿它从最笨的一级一路加码到最贵的一级, 看每一级各买到什么。
11. 最后一个诱惑:先挑个框架再说
决定要做了,大多数人的下一个动作是去挑一个现成的框架。书对这件事的态度很硬。
具体的数
只需要「搜一下 + 生成」的简单应用,直接用两个库是 2 到 3 个依赖; 全量上框架是 50 多个。 而书自己量出的后果是:「依赖超过 100 个的项目(全量用框架时很常见), 排障时间明显多于只用 5 到 10 个核心库的项目。」20
(依赖:你的程序要跑起来,得先装上的那些别人写的库。 装 3 个和装 100 个的区别是:后者里任何一个升级、任何一个和另一个打架,都是你的事。)
方向不可逆 —— 这是全书最该记住的一条形状
「你可以以后再把一个简单实现迁到框架上。 反方向——从框架简化回直接实现——难得多。」21
为什么这一条重要: 它把「先简单还是先复杂」从一个偏好问题,变成了一个顺序问题。 两条路都能走通,但一条能反悔,另一条不能。在能反悔的那条上起步,是纯赚的。
这句话在这本书里会以九种不同的面貌反复出现(要不要建索引、要不要加关键词搜索(按字面命中来搜,和按意思搜是两回事)、 要不要上框架、要不要加图谱……),而书一次都没给它起过名字。 我们在第 19 章给它起了名字,并把九处收在一起。
12. 作者的判断与证据
这一章里,哪些是有证据的、哪些是作者的经验,必须分开看。
| 说法 | 它是什么 |
|---|---|
| 三条结构缺口 | 有事实支撑:它们是这类模型的工作方式决定的,不是某个产品的缺陷 |
| 「一次解决全部三个问题」 | 成立,但要注意口径:它是「绕开」这三条,不是「修好」它们。模型本身一点没变 |
| 「95% 用正则或 SQL 覆盖就别上」 | 作者的经验判断,书没给任何测量。 那个 95% 是个手感数,不是测出来的阈值(一条划死的线:过了走这边,没过走那边) |
| 「一天 10 份不值得、1 000 份值得」 | 同上,是经验数。它没有配任何成本模型 |
| 五档打分表的八个分数 | 作者的判断。 每一行的「理由」那一栏都是定性的,没有一行有数据 |
| 「依赖超过 100 个的项目排障明显更久」 | 书写得像观察,但没给来源。 我们把它当经验陈述,不当统计结论 |
| 「从框架退回去难得多」 | 作者的经验,而且方向上很可信——它符合任何一次技术栈迁移的常识 |
判断(我们的,不是书里的):这一章的价值几乎全在那些「别做」的话上, 而那些话恰恰一条证据都没有。 这不是要否定它们——一个把这套东西真推上生产的人给的手感,比没有手感强得多; 而是提醒:引用这一章时,要说「作者的经验是」,不能说「研究表明」。 如果错,会错在: 如果这些判据后来被别人的对照实验证实了, 那我们这条提醒就显得过分谨慎。但在这本书里,它们确实没有证据。
13. 边界与局限
书没在这一章覆盖的:
- 它没说明怎么判断「95% 覆盖」。 你怎么知道你的规则覆盖了 95% 而不是 60%? 第 8 节那条走查里我们是靠人工抽查 100 份估出来的——这个动作书里没有;
- 它没给「什么时候该退回去」。 从简单走到复杂的时机它说了九遍, 但已经建好一套之后发现不值得,该怎么退,一句没有;
- 它没算过这套东西的总成本。 每一章都在标价,但从来没有一处汇总—— 所以第 9 节那句「一天 1 000 份就值得」,你没法自己验算。
已经被时间冲刷的:
- 那张五档表里「通用模型已经做得很好」这个理由,分界线一直在往上移。 书写「总结一份文档」不值得自建,这条今天成立; 但「和一份季度报告聊天」被打 1 分的理由是「量小」,不是「模型做不到」—— 这条判据比模型能力更耐用,因为它不随模型变强而失效。
14. 可带走的
- 三条缺口:碰不到你的资料 · 一次读不完 · 缺信息时会编。 三条是结构上的,不是「模型再大一点」能解决的;
- 上下文窗口 = 它一次能读进去的文字的长度上限。 而且它同时是钱和时间的闸门——因为模型不记事,长对话每一轮都要把之前全部重发一遍;
- 它会编,不是故障,是它的基本动作(往下续写最像样的)在做对它被要求做的事。 压住它的办法是在指令里写死「只用给你的材料回答,没有就说没有」;
- 这套做法最简的形态只有两个零件:一个搜你自己文 档的搜索器 + 一个照材料写答案的模型。 它不是产品,是一个动作顺序;
- 判死刑的判据:一条正则或一句 SQL 覆盖 95% 的情况,就别上。 它拿简单性换灵活性,而规则式做法最值钱的地方是失败方式可预测;
- 量的门槛:一天 10 份不值得建,一天 1 000 份值得(作者的经验数,不是测量值);
- 值得做的场景有三个共同点:量大 + 输出可核对 + 单条价值低但总量高; 而「错了代价极高」的场景要单独否掉,和量无关;
- 别一上来就挑框架:2、3 个依赖 vs 50 多个,而且这个方向走过去容易、退回来难。 这条形状在全书出现九次,是最该记住的一条。
15. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 三条结构缺口 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:6(搜「fundamental structural limitations」) |
| 一次解决三个问题 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:9(搜「addresses all three problems at once」) |
| 最简形态:搜索器 + 模型;搜索引擎那个比方 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:11(搜「rather than the entire web like Google」) |
| 多个检索器、模型自己决定调哪个(第 8 章的伏笔) | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:15(搜「Modern systems often use multiple retrievers」) |
| 聊天界面往往不是最优解 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:21(搜「chat interfaces aren’t always the optimal solution」) |
| 五档打分表 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:48(搜「A value of 1 indicates a RAG fit」) · text/03-ch01-chapter-1-getting-started-with-rag.txt:88(搜「10,000 contracts」) |
| 制造商质量文件那个完整例子 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:104(搜「welding thickness」) |
| 因天气延误 vs 发货改期 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:112(搜「delayed due to weather」) |
| 95% 判据 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:114(搜「95% of cases」) |
| 拿简单性换灵活性、失败方式可预测 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:116(搜「fail in predictable ways」) |
| 一天 10 份 vs 1 000 份 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:118(搜「processes 10 documents daily」) |
| 第一个项目别挑跨系统集成 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:120(搜「Avoid complex multisystem integrations」) |
| 三个必备零件 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:336(搜「three essential components」) |
| 第 1 章故意不用框架 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:380(搜「without frameworks」) |
| 100 个依赖 vs 5–10 个核心库 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:590(搜「100+ dependencies」) |
| 方向不可逆 | Chapter 1. Getting Started with RAG | text/03-ch01-chapter-1-getting-started-with-rag.txt:596(搜「is much harder」) |
| 「只用检索到的材料回答」那条指令 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:46(搜「use only the retrieved context」) |