改查询:检索之前先把问题改一遍
这一章讲三件事: 为什么用户那句原话往往是最差的搜索词、 把它改成什么样能搜得更准、以及三种改法各自在什么条件下才划算。
它在全书链条上的位置:第 02 章那条走查的第 4 步之前。 那条走查里「把问题换成一串数」是直接拿用户原话去换的—— 这一章说的是:先别急着换,那句话可以先改一遍。
1. 这一章讲什么
三句话:
- 原书这一章的开篇第一句就是全书最该被记住的一句: 改进检索这一步,是提高准确率与相关性最有效的办法;
- 而在「检索」这个大动作里,能动手的位置只有三个, 这一章管最靠前的那一个:问题还没变成一串数之前;
- 三招各自改的东西不同——一招改文风、一招改数量、一招改结构; 它们的分界很清楚,不是「都试试看哪个好」。
2. 顶层全景:三招都在同一个位置动手
用户那句原话
│
│ ←──────── 这一章的三招全在这一刀之前动手
│
├─ 招一:改文风 原话 → 一段"像你库里文档"的假答案 → 拿假答案去搜
│ (第 5 节)
├─ 招二:改数量 原话 → 原话 + 三条近义问法 → 各搜一次,合并
│ (第 6 节)
└─ 招三:改结构 原话 → 五个各自独立的子问题 → 各搜各的,最后合成一个答案
(第 9 节)
↓
换成一串数 → 算相近程度 → 取回几块 → 交给模型答
↑ ↑
│ └── 检索之后那两招在第 12 章
└── 检索的同时那两招(按字面搜、先缩范围)在第 10 章
图说:三招可以叠加,书自己也说了两处可以合用。
但它们各自的启动条件不同,不该一次全上 —— 第 10 节给分界。
3. 全书最该记住的那一句,以及它为什么值这么高的评价
书这一章的第一句话是1:
「改进检索这一步,是提高一套 RAG 系统的准确率与相关性最有效的办法。」
这句话在第 02 章出现过一次半句版,这里是它的完整版和它的位置。
它为什么值得被单拎出来: 因为大多数人卡住的时候,第一反应是去改交给模型的那段话—— 把指令写得更严、把角色写得更专业、换一个更贵的模型。 而第 03 章已经算过账了:那一头能拧的旋钮就那么几个,拧到头也就那样。
真正决定答案好坏的,是模型手上拿到的那几块材料。 材料不对,再好的模型也只能在错的东西上把话说漂亮。
能改的位置只有三个,书这一章的八个做法正好落在这三格里(这个归类是我们做的):
| 位置 | 在什么时候动手 | 这一章讲哪一格 |
|---|---|---|
| 检索之前 | 问题还没变成一串数 | 就是这一章 |
| 检索的时候 | 已经在库里比了 | 第 10 章(按字面搜、先缩范围、先选源) |
| 检索之后 | 已经取回一堆候选了 | 第 12 章(补上下文、再挑一遍) |
4. 先看现象:问句和文档天生长得不一样
这一节不讲任何做法,只把那个「明明该搜到却搜不到」的场景摆出来。
书给的例子极朴素2:
用户打字问的是: "How do I fix my car?"(我的车怎么修?)
你库里文档写的是: "automotive repair procedures"(汽车维修流程)
"Diagnostic and remediation steps for powertrain faults …"
两边讲的是同一件事,可是:
用户那句是 一个问句、口语、第一人称、短
文档那段是 一段陈述、书面、名词堆、长
第 08 章讲过,那 1 536 个数概括的是「这段话大概在讲什么」—— 而「大概在讲什么」里其实混着两样东西:讲的是什么主题,以及它是怎么写的。
问句和文档在第一样上很接近,在第二样上差得很远。 于是相近程度被拉低了。
这就是这一章要修的东西:不改库,不改模型,只改用户那句话。
注意方向:第 06 章讲过一招方向正好相反——那一招是在入库时给每块文档 生成几个「这块能回答的问题」,把文档往问题的样子拉。 这一章是把问题往文档的样子拉。两招可以只用一个,也可以都用。
5. 承重词一:HyDE —— 先编一段假答案,拿假的去搜
这一章第一个承重词。一句话先给结论:HyDE 就是「先让模型按用户的问题编一段 看起来像你库里文档的段落,然后拿这段编出来的文字去搜,而不是拿用户那句问话去搜」。
它凭什么成立(这里最容易读岔)
第一次听到这个做法的人,第一反应都是同一句:编出来的东西不可靠,怎么能拿去搜?
书把这一点说得非常清楚,而且这句话是整节的钥匙3:
「这些假设性的文档并不追求事实正确。 它们只是看起来像文章或书里那种可能包含答案的段落, 而且写成和你库里真实文档相似的风格。」
关键在于:这段假文不是用来回答问题的,它只用来当搜索词。
它经手的东西一共走这么几步:
用户问题 ──模型──> 一段假答案 ← 里面的数字、人名可能全是编的
│
↓ 换成一串数
去库里比相近程度
│
↓
取回来的是**真文档**
│
↓
最终交给模型的那段话里:真文档在、假答案不在
图说:书明说了这一句 —— "假设性文档不会进最终提示,
它们被从库里检索回来的真实文档替换掉。"
所以假文里编错的细节,没有一个字会出现在最终答案里。
它换到的到底是什么:风格对上了
书给的机制描述只有一句,但这一句把事情说透了4:
HyDE 把查询变成「风格上和你的语料相匹配」的文本。 你的文档是措辞正式的科学论文,它就生成正式的假段落; 你的文档是随意的博客,它就生成随意的文字。 于是相似度从「只比主题」变成了「比主题 + 比文体」。
回到第 4 节那个例子:
❌ 直接拿 "How do I fix my car?" 去比
vs "automotive repair procedures …"
主题接近、文体差很远 → 相近程度被拉低
✅ 先编一段 "Routine vehicle maintenance involves diagnosing the fault,
identifying the affected component, and following the
manufacturer's repair procedure …"
vs "automotive repair procedures …"
主题接近、文体也接近 → 相近程度上去了
(这段假文是为演示编的;书给的是同一对例子的前半句,没有给出模型实际编出来的文字。)
一个细节:用便宜的小模型就够
书专门交代了这一步该用什么档位的模型5:用小而高效的那一档通常就够了, 因为它只需要产出「像那么回事」的文字片段。
这和第 03 章那条「选仍然满足要求的最小模型、逐个步骤地选」是同一条纪律的又一次落地。 它也说明这一招的成本没有想象中高:每次提问多一次调用,但那是最便宜的一档。
它的风险很具体,而且书自己说破了
书给的风险是6:
生成的假文看着合理、其实是错的,把检索带偏。 这在模型缺少知识的专门领域里更容易发生。上生产之前要充分测试。
为什么这条风险和前面那句「不追求事实正确」不矛盾: 两者管的不是一件事。编错的细节不进最终答案(所以不会直接说错话), 但编错的细节会改变那 1 536 个数的方向(所以会搜错地方)。
举个具体的:
用户问 "公司 X 在 2024 年的营收是多少?"
模型对这家公司一无所知,于是编了一段:
"公司 X 是一家总部位于德国的可再生能源设备制造商,
2024 年营收约为 4.2 亿欧元……"
可这家公司其实是做医疗器械的。
→ 这段假文的方向指向"可再生能源制造业"
→ 拿它去搜,搜回来的是新能源行业的报告
→ 真正那份财报,一次都没被取回来
(这个例子是为演示编的;书只说了"专门领域里更容易发生",没有给具体案例。
"公司 X 在 2024 年的营收是多少" 这句是书代码里的真实查询串。)
什么时候用、什么时候跳过
| 用4 | 用户提问的用词和风格,跟你存的文档对不上的时候 |
| 跳过7 | 问句和文档风格本来就一致;或者你的基础检索已经够好了(先用评测数据验证过再说);或者多一次模型调用带来的延迟和费用不划算 |
「先用评测数据验证过再说」这句要留意 —— 书在这一章的每个做法里都塞了同一句提醒:别凭感觉判断当前检索好不好。 (怎么量,第 16、17 章讲。)
这一招的名字要留:它叫 HyDE,是「假设性文档嵌入」(hypothetical document embeddings) 的缩写。 你在任何一家检索框架的文档里都会撞见这四个字母。
6. 承重词二:召回率 —— 多问几遍买到的是什么
这一章第二个承重词。一句话先给结论:召回率量的是「该找到的东西里,你找回了几成」; 而「把同一个问题变出几种问法各搜一次」这一招,买的就是这个数。
先看做法
做法朴素得出奇8:把原问题交给模型,让它写出三条不同的问法, 然后连原问题一起,一共搜四次,再把四份结果合起来。
书那段提示词写得很直白,大意是:「你的任务是给下面这句用户问题写出三条不同的版本, 好让从向量库里检索到相关文档的机会更大;每条一行。」
它凭什么有用
书给的机制是一句话9:
不同的问法会浮出不同的文档。
为什么会这样: 第 08 章讲过,换算出来的那 1 536 个数是对整句话的概括—— 换一种问法,就是在那个空间里换了一个略微不同的落点, 于是「离它最近的几块」自然也换了一批。四个落点覆盖的范围,比一个落点大。
那个数叫什么,以及书自己给的定义
书专门用一个提醒框给了定义,可以直接照用10:
召回率量的是:在你数据库里存在的所有相关文档中,检索器找回了多少。 对一套 RAG 系统来说,高召回意味着检索器成功找到了大部分有用的信息—— 即使它同时也捞回了一些之后会被过滤掉的无关内容。
注意定义里那半句「即使也捞回了无关内容」。 它说的是这个数只管漏没漏,不管脏不脏:
库里真正相关的块一共 10 块。
做法 A:取回 3 块,其中 3 块相关 → 召回率 3/10 = 0.3 (干净但漏得多)
做法 B:取回 40 块,其中 9 块相关 → 召回率 9/10 = 0.9 (脏但漏得少)
(这些数是为演示编的。)
图说:多问几遍这一招,是拿 A 换 B。
它故意把网撒大 —— 而"脏"这一头交给第 12 章那一遍重新挑选去收拾。
这就是为什么这一招和第 12 章那一招几乎总是配对出现。
代价是明码标价的
书给了一个可以直接算的数11:
三次搜索 + 一次生成问法的模型调用, 大致让检索时间和算力成本翻三倍。 复杂的研究型问题划算,简单的常见问题查找不划算。
「三倍」这个数值得对照着看: 第 09 章测出来 20 万条不建索引全算一遍是 85.6 毫秒, 建了索引 13.9 毫秒。在建过索引的库上,三倍也就是 40 毫秒出头,几乎无感; 而那一次生成问法的模型调用,少说也要几百毫秒——真正的代价在那一次调用上,不在多搜的几次上。 (这个对照是我们做的,书没有把两处数字放在一起。)
什么时候跳过
书给的反面判据12:用户问的是窄而具体的问题(一次搜索就应付得很好); 或者你的延迟预算吃不下「N 次并行搜索 + 一次模型调用」; 或者评测数据已经显示单次检索的召回率达标了。
7. 主走查:同一个问题,三招各走一遍
这是本章的主走查,前面每个机制都在它上面占一步。 用的是书那句真实的跑例查询13。
(「和化石燃料相比,可再生能源有什么好处?」这句、拆出来的五个子问题、 「共四次向量搜索」、「三倍」、「多两次模型调用」都是书里的 ——最后那个数我们在招三那一格里数了第二遍,理由写在当场; 下面的假文内容、三条近义问法的具体文字、以及所有毫秒数都是我们为演示编的—— 书把生成结果放在图里,而我们手上的正文里没有那些图。)
第 0 步:原问题
"What are the benefits of renewable energy compared to fossil fuels?"
(和化石燃料相比,可再生能源有什么好处?)
书自己对这句的评价:"这个问题并不算特别复杂,
但用户是从哪个角度问的,并不清楚。"
招一:HyDE —— 变成一段假答案
一次模型调用(小模型),产出一段假文:
"Renewable energy sources such as wind and solar produce
electricity with substantially lower lifecycle greenhouse gas
emissions than coal or natural gas. Levelized cost of
electricity for utility-scale solar has fallen below …"
↑ 里面的"已经低于"是编的,可能不对。不要紧,它不进最终答案。
拿这段去搜:1 次向量搜索
多花:1 次小模型调用(约 300 毫秒)+ 0 次额外搜索
效果:库里那些用 "lifecycle emissions" "levelized cost" 这类
行话写成的报告,相近程度上去了;
而用户原话里一个这样的词都没有。
招二:多问几遍 —— 变成四个问法
一次模型调用,产出三条近义问法:
① "How does renewable energy reduce environmental impact
compared with coal and gas?"
② "What are the economic advantages of switching to
renewables instead of fossil fuels?"
③ "What are the drawbacks of renewable energy versus
fossil fuels?"
连原问题一起:**共 4 次向量搜索** ← 这个数是书里的
多花:1 次模型调用 + 3 次额外搜索 ≈ 检索时间和算力翻三倍
效果:①带回环境类文档、②带回成本类文档、③带回局限类文档
——原问题一条搜下来,这三类里多半只命中一类
招三:拆成子问题 —— 变成五个各自独立的问题
一次模型调用(拆),产出五个子问题(**这五个是书里的**):
① 可再生能源有什么好处?
② 使用化石燃料有什么好处?
③ 两者的环境影响各是什么?
④ 两者的成本各是什么?
⑤ 两者的可获得性各是什么?
每个子问题各搜一次、各自生成一段答案:5 次检索 + 5 段中间答案
然后再来一次模型调用(合成):
把五个子问题连同它们各自的答案一起交给模型,
让它综合成一个完整回答
书写的代价:**多 2 次模型调用**(一次拆、一次合成)+ 多次检索
这个数对不上,而对不上的是书自己。
书讲步骤的那一段明写着「对每个子问题做检索,并各自生成答案」14—— 那五段中间答案,每一段都是一次模型调 用。 可它讲代价的那一段写的是「拆解增加两次模型调用(一次拆解、一次合成)」15, 中间那五次一次没算。
照书自己的步骤数一遍(这个例子是五个子问题):
① 拆 1 次
② 五段中间答案 5 次 ← 书讲代价时漏掉的就是这五次
③ 合成 1 次
────
7 次模型调用
对照:什么都不加的时候,一次提问只有 1 次模型调用(生成答案)。
招一和招二各多 1 次,合计 2 次。
→ 所以招三不是"比招一贵一倍",是贵到三倍以上,而且随子问题个数往上走:
子问题多一个,模型调用就多一次。
这是全书唯一一处「书自己的步骤和自己的计数对不上」的地方。 下面那张对照表按两个数都写:书写的那个,和照书自己的步骤数出来的那个。
把三招放在一起看
多几次模型调用 多几次检索 产出的中间物
招一 HyDE 1 0 一段假答案(不进最终提示)
招二 多问几遍 1 3 同一问题的近义变体
招三 拆成子问题 2(书)/ 6(数得出来) 4 各自独立的子问题 + 各自 的答案
图说一:最后一列 —— 三招产出的中间物完全不同。
这才是它们真正的分界,不是"哪个更强"。
图说二:招三那一格为什么写两个数,上面刚讲过 ——
书只算了拆和合成这两次,漏掉了五个子问题各自生成答案的那五次。
按它自己的步骤,这一招总共 7 次模型调用,比不加任何招数多 6 次。
8. 「多问几遍」和「拆成几个问题」不是一件事
这两招最容易读成同一件事,而书自己写了一句区分,值得照搬16:
| 它产出什么 | 每一条需要单独回答吗 | |
|---|---|---|
| 多问几遍 | 同一个问题的近义变体 | 不需要。 四次搜索的结果直接合成一堆候选 |
| 拆成子问题 | 各自不同的子问题 | 需要。 每个子问题各自回答一遍,最后再合成 |
一句话记住:一个改的是「怎么问」,一个改的是「问几件事」。
原问题:"微软和谷歌去年谁赚得多?"
多问几遍会产出:
"去年微软和谷歌的利润对比是怎样的?"
"微软与谷歌上一财年盈利情况谁更好?"
→ 三句话问的还是同一件事,而且**每一句都同样答不出来**
拆成子问题会产出:
① "微软去年赚了多少?"
② "谷歌去年赚了多少?"
→ 两句各自都能从一份财报里查到,合起来才回答原问题
图说:这个例子就写在书那段拆解提示词里,当范例给模型看。
它说明了什么时候必须用拆解 —— 换问法救不了"需要两份材料"的问题。
书还补了一句:两招可以合用16——复杂的多部分问题,先拆成子问题, 再给每个子问题各生成几种问法。
9. 拆解:它能回答单次检索永远答不好的那一类
它的做法
四步14:
① 拆 一次模型调用,把复杂问题切成几个简单的子问题
② 各搜 每个子问题各做一次语义检索
③ 各答 每个子问题各生成一段答案
④ 合成 把所有子问题和它们的答案一起交给模型,让它综合成一个完整回答
提示词里有一句必须写、而且很容易被忘掉的话17:
「如果问题本来就简单,就原样留着。」
为什么这一句是必需的: 没有它,模型会把「什么是 X?」也拆成三个子问题, 于是每一次提问都要多付四次模型调用外加多次检索的钱 (一次拆、三段中间答案、一次合成,减掉本来就有的那一次生成),而收益是零。
它买到的是什么
书说得直接18:它能回答那些任何单次向量搜索都答不好的问题。
这一类问题有固定的形状,书给了两种:
| 形状 | 例子 | 为什么单次检索答不好 |
|---|---|---|
| 比较型 | 「微软和谷歌去年谁赚得多?」 | 答案需要两份材料,而它们不会出现在同一块里 |
| 多跳型 | 「那家收购了 A 公司的企业,总部在哪个国家?」 | 得先查出是谁收购的,才知道第二步该查谁 |
「多跳」就是「答案要分几步查、后一步查什么取决于前一步查到了什么」。 它是这一族做法在论文里的通行叫法。
它的代价与反面判据
书写的代价15:多两次模型调用(一次拆、一次合成),外加多次检索。 而按书自己给的步骤数出来是七次(第 7 节数过:一次拆 + 每个子问题各一段答案 + 一次合成)—— 书这里少算了中间那几次。
跳过它的时候19:问题简单直接(「X 是什么?」); 一次检索取回的材料已经够了; 多出来的模型调用让响应时间变得不可接受; 或者评测显示单步检索的效果一样好。
一条能抵消延迟的实操点,书自己提了18:子问题可以并行搜。 五个子问题同时搜,检索这一段的耗时接近一次; 真正躲不掉的是那两次串行的模型调用(拆必须在最前面、合成必须在最后面)。 中间那五段答案和检索一样能并行,所以七次调用里只有两次卡在串行上—— 但七次的钱一分不少。 (并行具体怎么做、能省多少,第 13 章有一组书里的实测。)
判断(我们的,不是书里的):这一招还有一个书没有点名的好处—— 中间答案是可以打开看的。 书在「什么时候用」那一条里顺带写了一句「中间答案有助于你调试为什么最终答案是错的」18, 但它没有把这条当成一个独立的理由来讲。 而这在实际维护里往往比准确率更值钱: 一个直接给出错答案的系统,你无从下手; 一个拆成五个子问题、第三个子问题的答案明显是错的系统,你一眼就知道该修哪里。 如果错,会错在: 如果你的系统根本没人维护、也没人看日志, 那这条好处等于不存在,只剩下多出来的那两次调用的成本。 判据是:出错的时候,有没有人真的会去翻中间结果。
10. 三招怎么选(这是这一章最该带走的一 张表)
书没有把三招放在一起比过,下面这张表是我们照三处「什么时候用」归的41219:
| 你观察到的现象 | 用哪一招 | 为什么是它 |
|---|---|---|
| 用户的用词、文体和你的文档明显不是一路 | 招一 HyDE | 它改的正是文体 |
| 问题问得宽或含糊,一次搜索总是漏掉你知道存在的文档 | 招二 多问几遍 | 它改的是覆盖面 |
| 问题里含着多个各自独立的事实点(比较型、多跳型) | 招三 拆成子问题 | 只有它产出「能各自被回答」的东西 |
三条反面判据,合在一起就是一句话:
先什么都不加。等评测数据告诉你「漏了」或者「风格没对上」,再加对应的那一招。
这是这一章里那个反复出现的句式的第四次露面—— 前面第 10 章出现过三次(先只用按意思搜、先只用按意思搜、先用让模型判断)。 书说了九遍、一次都没给它起名字,第 19 章把九处收在一起。
11. 作者的判断与证据
| 说法 | 它是什么 |
|---|---|
| 「改进检索这一步是最有效的办法」 | 作者的判断,没有实验支撑。 但它是全书的组织原则——第 7 章是全书最长最技术的一章,正是因为这句话 |
| HyDE「不追求事实正确」 | 是对原做法的准确描述;书没有给出处,论文名和年份是我们补的 |
| 「相似度从只比主题变成比主题 + 比文体」 | 是机制推导,成立,而且是这一节最有解释力的一句 |
| 「假文不进最终提示」 | 是流程事实,书写得很明确 |
| HyDE 的风险(编得像真的、把检索带偏) | 是机制推导,书自己坦白了,并且给了适用边界(专门领域更容易出事) |
| 用小模型生成假文就够 | 作者的工程建议,和第 2 章那条选型纪律一致 |
| 召回率的定义 | 是标准定义,书给得很准 |
| 「不同的问法会浮出不同的文档」 | 是机制推导,和第 08 章讲的换算方式一致 |
| 「大致翻三倍」 | 作者的估算,不是实测。 而且它把「三次搜索」和「一次模型调用」混在一个倍数里说,这两样的绝对耗时差一个数量级 |
| 「复杂研究型划算、简单常见问题不划算」 | 作者的经验判断,没有数据 |
| 五个子问题那个跑例 | 是书里真实跑出来的一次输出 |
| 「多两次模型调用」 | 书自己的步骤和自己的计数对不上。 讲步骤那一段说每个子问题各生成一段答案,讲代价那一段只算了拆和合成两次——按它自己的步骤数是七次 |
| 三招各自的适用/跳过条件 | 作者的经验归纳。 每一条都合理,但没有一条给了实验对照 |
| 「子问题可以并行搜」 | 是事实,而且第 13 章有一组实测支撑 |
12. 边界与局限
- 三招没有一次同台比较。 书给了三招各自的适用条件, 但从没在同一个问题上把三招各跑一遍、比一比效果——第 7 节那张对照表是我们排的;
- 拆解那一招的代价,书自己算错了。 讲步骤那一段说每个子问题各生成一段答案, 讲代价那一段却只算了拆和合成两次——中间那几次一次没算(第 7 节数过); 书也没有交代子问题该拆成几个,而这个数直接决定这一招多贵;
- HyDE 那段假文该生成几段,书自相矛盾。 正文说「假设性文档们」(复数), 代码里的提示词写的是「生成三段」,而流程图和讲解都按一段在说; 书没有交代生成几段的取舍;
- 三条近义问法的具体内容,我们的正文里没有。 书把生成结果放在图里, 所以那三条实际长什么样无从核对;
- 「三倍」没有拆开。 三次额外搜索和一次模型调用的耗时不是一个量级, 合成一个倍数说,会让人误以为瓶颈在搜索上;
- 书没有讲四份结果怎么合并。 多问几遍产出四堆候选,书只说「用一个合并器合起来, 必要时再重排」——合并时重复的块怎么去重、排名怎么算,一个字没有;
- 书没有讲拆解失败怎么办。 模型把一个简单问题拆成五个,或者拆出一个答不了的子问题, 系统会怎样,书没有讨论;
- 改查询这一整类做法有一个共同的盲区书没提:它们都假设用户那句话本身是对的。 用户问错了对象(把两家公司搞混了),三招都会把这个错误忠实地放大。
13. 可带走的
- 全书最该记住的一句:改进检索这一步,是提高准确率最有效的办法。 卡住的时候先别去改交给模型的那段话;
- 能动手的位置只有三个: 检索之前(这一章)、检索的时候(第 10 章)、 检索之后(第 12 章);
- 问句和文档天生长得不一样——主题接近、文体差很远,而那 1 536 个数把两样混在一起算, 于是相近程度被拉低;
- 招一 HyDE:先让模型编一段「像你库里文档」的假答案,拿假的去搜。 它不追求事实正确,它换来的是文体对上;
- 那段假文不进最终提示,它被检索回来的真文档替换掉——所以编错的细节不会说进答案里, 但会把检索带偏,专门领域尤其容易;
- 生成假文用最便宜那一档模型就够,它只需要产出「像那么回事」的文字;
- 招二 多问几遍:同一个问题变出三条近义问法,连原问题共四次搜索。 它买的是召回率——该找到的里面找回了几成;
- 召回率只管漏没漏,不管脏不脏。 这一招故意把网撒大,「脏」那一头交给第 12 章收拾;
- 它的代价书标了价:大致三倍。 但真正的瓶颈是那一次生成问法的模型调用, 不是多搜的那几次;
- 招三 拆成子问题:把复杂问题切成几个各自需要独立回答的小问题,各搜各答,最后合成。 提示词里必须写「问题本来就简单就原样留着」,否则每次提问都白付好几次调用; 而它的真实代价书自己算错了:书写「多两次模型调用」, 可按它自己给的步骤是七次(一次拆 + 五段中间答案 + 一次合成), 而且子问题多一个就多一次;
- 它是唯一能回答比较型和多跳型问题的一招——那两类问题的答案需要两份材料, 换问法救不了;
- 子问题可以并行搜,能把检索那一段的耗时压回接近一次; 串行躲不掉的只有拆和合成那两次,但七次的钱一分不少;
- 三招的分界看产出的中间物: 一段不进最终提示的假文 / 同一问题的近义变体 / 各自需要独立回答的子问题。不是「哪个更强」;
- 共同的启动条件:先什么都不加,等评测数据告诉你漏了或者风格没对上,再加对应的那一招。
14. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 「改进检索最有效」 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:4(搜「most effective way to increase the accuracy」) |
| 多步检索工作流的三段 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:8(搜「breaking a complex query into focused subqueries」) |
| HyDE 的定义与「不追求事实正确」 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:223(搜「Hypothetical document embeddings」) · text/09-ch07-chapter-7-retrieval.txt:225(搜「not intended to be factually correct」) |
| 假文不进最终提示 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:287(搜「replaced with the real documents」) |
| 风格对齐那句机制 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:291(搜「style + topic rather than just topic」) |
| 修车那个例子 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:293(搜「How do I fix my car」) |
| 用小模型就够 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:246(搜「smaller, efficient model is often sufficient」) |
| 生成假文的提示词与那句查询 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:252(搜「revenue of Company X in 2024」) · text/09-ch07-chapter-7-retrieval.txt:266(搜「three hypothetical text chunks」) |
| HyDE 的风险与跳过条件 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:295(搜「Skip this approach when query and document styles」) · text/09-ch07-chapter-7-retrieval.txt:297(搜「plausible but incorrect hypothetical documents」) |
| HyDE 和多问几遍的区别 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:301(搜「query expansion generates alternative phrasings」) |
| 多问几遍的做法与提示词 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:320(搜「creates several variations」) · text/09-ch07-chapter-7-retrieval.txt:361(搜「three alternative versions of the provided user query」) |
| 共四次向量搜索 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:391(搜「four vector searches in total」) |
| 召回率的定义 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:399(搜「Recall measures the number of relevant documents」) |
| 不同问法浮出不同文档 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:395(搜「different phrasings surface different documents」) |
| 「大致三倍」与跳过条件 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:403(搜「Skip this approach when users ask narrow」) · text/09-ch07-chapter-7-retrieval.txt:405(搜「roughly triples retrieval time」) |
| 多问几遍 vs 拆解 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:407(搜「semantically similar variants of the same question」) · text/09-ch07-chapter-7-retrieval.txt:918(搜「distinct subquestions requiring separate answers」) |
| 拆解的提示词与那个范例 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:866(搜「break down complex questions into simpler ones」) · text/09-ch07-chapter-7-retrieval.txt:873(搜「Did Microsoft or Google make more money last year」) |
| 五个子问题那次跑例 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:880(搜「not highly complex, but it is unclear from which angle」) · text/09-ch07-chapter-7-retrieval.txt:902(搜「five simpler subqueries」) |
| 合成那一步 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:906(搜「synthesize the insights into a single consolidated answer」) |
| 拆解该用与该跳过 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:912(搜「Use decomposition when questions naturally require」) · text/09-ch07-chapter-7-retrieval.txt:914(搜「Skip query decomposition when questions are simple」) |
| 多两次模型调用 | 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:927(搜「Demonstrate-Search-Predict」) |