补上下文与挑结果
这一章讲三件事: 取回来的那一块为什么常常「对但不够」、 拿什么把它补厚、以及一堆候选摆在面前时凭什么砍掉大部分。
它在全书链条上的位置:第 02 章那条走查的第 5 步和第 6 步之间。 「取最近三块 → 拼进提示」——这一章说的是这两步中间还能再做两件事。
1. 这一章讲什么
三句话:
- 这一章从一个两难开始,而这个两难是前面所有切块讨论绕不开的死结: 搜索要小块才够聚焦,生成要大块才有上下文;
- 书给了两种补法,它们看着像同一件事,其实一个按结构补、一个按位置补—— 前者会随内容随机应变,后者不会,但后者简单得多;
- 第三招和前两招不是一路:它不补东西,它砍东西; 而它真正的用途,是收拾第 11 章那几招留下的烂摊子。
2. 顶层全景:一个两难,三种补法
两难:块该切多小?
切小了 → 搜得准(每块只讲一件事),但交给模型的材料上下文不够
切大了 → 上下文够,但搜不准(一块里混了好几件事)
三种补法,两种在"补",一种在"砍":
┌ 招一 按结构补 ──→ 用小块搜;同一个父块下命中够多个小块,
│ (第 4 节) 就把整段父块交出去 ← 会随机应变
│
├ 招二 按位置补 ──→ 用小块搜;命中哪一块,就固定带上
│ (第 5 节) 它前后各 N 块 ← 不看内容,永远这么干
│
└ 招三 重排 ─── ─→ 不补。把几十个候选重新打一遍分,
(第 7 节) 只留前几个 ← 收拾一堆候选
图说:招一和招二解的是同一个两难,选其中一个就够(第 9 节给分界)。
招三解的是另一个问题 —— 候选太多,和块大小无关。
3. 承重词一:父块与子块 —— 先把那个两难摆清楚
这一章第一个承重词。一句话先给结论:父块与子块就是把同一段原文存两遍—— 存成一堆小块用来搜,同时存成一个大块用来交给模型;两者靠编号连着。
先看两难本身(书自己就是这么开场的)
书这一节的第一句话就是那个两难1:
语义搜索想要小块(才够聚焦),生成想要大块(才有上下文)。
为什么两头都是真的:
── 为什么搜索要小块 ──
一块 3 000 字符,里面混着"公司简介""财务摘要""风险提示"三件事。
这块的那 1 536 个数,是这三件事糊在一起的一个平均方向。
用户问风险提示 → 相近程度被另外两件事稀释 → 搜不准。
── 为什么生成要大块 ──
一块 250 字符,恰好是"2024 年营收同比下滑 12%"这一句。
搜得准极了。可交给模型时,它不知道这是哪家公司、哪个业务板块、
和什么比的 —— 模型只能照着这一句瞎猜,或者说"材料里没有"。
这个两难在第 07 章讲切块的时候一直悬着:那一章给了五种切法, 但没有一种能同时满足两头——因为一刀切下去,只能得到一个尺寸。
解法:不切一次,切两次
原文
├── 切成子块(每块约 250 字符) → 这些块参与搜索,存它们的那 1 536 个数
└── 四个子块合成一个父块(约 1 000 字符) → 这些块参与生成,不必存数
两者靠编号连着:
每一条记录同时存 子块编号 和 它属于哪个父块的编号
图说:这些数只给子块算,父块一个数都不用算 ——
父块从来不参与"比相近程度"这一步,它只在最后被整段取出来。
所以这一招几乎不增加第 08 章那一步的开销。
书那个跑例的具体参数是2:子块约 250 字符,四个子块合成一个父块, 所以父块约 1 000 字符。每个子块恰好属于一个父块。
「父块」「子块」这两个名字要留 ——各家框架里管这一族做法叫「父文档检索器」
或者「自动合并检索器」,配置项里全是 parent 和 child。
4. 招一:按结构补 —— 命中够多个,才把整段交出去
这一招的做法只有一句话:用子块搜,搜完数一数,同一个父块下命中了几个子块; 超过一个门槛,就把整段父块交出去。
门槛这个词很关键
一次查询,判为相关的子块是:叶 1、叶 2、叶 5
叶 1 和叶 2 都属于父块 1 → 命中 2 个,达到门槛(书那个例子的门槛是 2)
→ 把父块 1 的完整文本整段取回
叶 5 属于父块 2,而父块 2 下只有它一个命中
→ 没达到门槛
→ 只取叶 5 那 250 字符,不扩
图说:这就是"会随机应变"的意思 —— 同一次查询里,
一个父块被整段取回,另一个只取了一小块。
(这个例子是书里的,包括"叶 1、2、5"和"父块 1 下有两个命中"。)
为什么要设这个门槛,而不是「命中一个就扩」: 命中一个只能说明「这句话跟问题有关」,命中两个才说明「这一整段跟问题有关」。 门槛就是把「碰巧」和「确实」分开的那条线。
什么时候用、什么时候跳过
| 用3 | 文档有很强的层级结构(有章有节的书、有小节的论文);或者信息横跨多个块导致检索质量下降;或者评测显示更大的上下文块确实提高了生成质量、而且没把提示撑爆 |
| 跳过4 | 简单的平铺切块已经够用;文档本来就没有清晰的层级(常见问答、商品描述);更大的提示只增加成本不提高质量;或者维护父子关系那点复杂度不值得 |
代价书说得很实在5:你要同时存父块和子块、维护它们之间的编号关系、 再实现一段合并逻辑。 换来的是「当查询同时命中好几个相关片段时,取回的上下文更连贯」。
5. 招二:按位置补 —— 命中哪块就带上邻居
这一招更简单:不管内容,命中哪一块,就把它前后各 N 块一起送进去。
它解决的是哪种具体失败
书给的例子很好6:
用户问:"拜仁慕尼黑是一家什么样的俱乐部?"
语义搜索命中的那一块:
"……近年来球队连续夺得联赛冠军,并在欧洲赛场……"
可是紧挨着它的上一块写的是:
"拜仁慕尼黑成立于 1900 年,名字来自巴伐利亚州,主场位于慕尼黑……"
→ 用户真正要的背景,被切在了隔壁块里
→ 只取命中的那一块,模型答不出"它是什么"
图说:这不是搜错了 —— 命中的那一块确实最相关。
是"最相关的那一块"和"回答问题需要的那一块"不是同一块。
它有一个入库时就必须满足的前提
这一条容易被忽略,而且漏了整招就不成立7:
入库时,块的编号必须反映原文顺序。 第一段是 1、第二段是 2,依次排下去。
因为「取前一块和后一块」是靠编号加减一做到的——
chunk_id = 4 命中,就去取 3 和 5。编号一乱,取回来的就是文档里别处的两段。
所以这一招是一个「入库时就要决定」的选择,不是查询时想加就能加的。
书那个跑例的具体参数
每块约 250 token
命中一块 → 连它前后各一块 → 送进模型的窗口约 750 token
「token」就是第 03 章讲的那个计价单位 —— 一段文字被切成的小块,
英文里大致三四个字符一个。
它和招一到底差在哪(书自己写了这一句)
这句区分必须记住,否则两节会读成同一件事8:
| 扩张的依据 | 结果 | |
|---|---|---|
| 招二 按位置补 | 固定的位置——不管内容,永远加相邻 N 块 | 更简单,但不会随机应变 |
| 招一 按结构补 | 相关性——只有当同一个父块下有多个子块命中,才把父块加进来 | 更聪明,但要维护父子关系 |
书自己的推荐: 单纯是「需要位置上的上下文」就用招二; 「文档结构和相关性模式应该来决定要不要扩张」的时候,才值得上招一。
6. 补上下文的代价是可以算的
这一节很短,但它是这两招唯一的硬约束。
书给的数9:
从每块 1 000 个 token 扩到 3 000 个 token,上下文长度翻三倍,成本和延迟都涨。
这个数要和第 03 章那一章连起来看才有量感: 那一章讲过,你是按这段话的长度付钱的,而且模型每 吐一个字都要把前面全部回看一遍。 所以「上下文翻三倍」不只是账单翻三倍,它同时让每个答案都变慢。
书给招二的跳过条件里有一条正是冲着这个来的10: 你的块本身已经有 500 个 token 以上、上下文本来就充足了,就别扩。
7. 承重词二:重排 —— 为什么它必须是第二遍,而不是替代品
这一章第二个承重词。一句话先给结论:重排就是拿到一堆候选之后, 再用一个更贵、更准的办法给每一条重新打一次分,只留最高的几条。
先看它是来收拾什么的
这一点书写得很直接,而且它把前面几章串起来了11:
谁会产出一大堆候选?
第 11 章招一(HyDE) → 生成好几段假文,每段各搜一次
第 11 章招二(多问几遍) → 四个问法并行搜,四堆结果
第 13 章那种让模型自己决定的系统
→ 可能同时查了 SQL 表、向量库、外部接口、一段计算
这些做法都产出一个合并后的结果集,而它需要被筛。
图说:所以重排不是"锦上添花的第三招" ——
它是前面那些"把网撒大"的做法的必要配套。
第 11 章说的"脏那一头交给第 12 章收拾",指的就是这里。
为什么不能只用初检的分数排
这是这一节的机制核心,书用一句话说清了12:
| 它怎么打分 | 快慢 | 准不准 | |
|---|---|---|---|
| 初检(算相近程度、BM25) | 把查询和文档各自独立处理——先各自算出自己那串数,再比一比 | 快,能在 20 万条上跑 | 粗 |
| 重排 | 把查询和候选放在一起看,让两边的每个词互相照面 | 慢,只能在几十条上跑 | 准 |
为什么「各自独立」会粗: 第 08 章讲过,一块文字被压成 1 536 个数的时候, 它并不知道自己将来会被什么问题查到。这串数是一个「面向所有可能问题」的概括。 而重排是在知道问题的前提下重读一遍这块文字——信息量根本不同。
书给这种「放在一起看」的机制起了名字:交叉注意力(cross-attention)。 它做的事很具体:把查询里的每个词和候选文字里的每个词两两配对,逐对算出关联强度—— 「E-17」这个词和候选里的「报警码」照过面,「高温」和「保护触发」照过面。 而初检那一步,两边从头到尾一次面都没照过。
顺 带交代一个你一定会撞见的名字
先说半个词。编码器指的是「把文字读进去、吐出一串数」的那一头—— 第 08 章那台把每块文字换成 1 536 个数的机器,就是一个编码器。 它有一个很要紧的性质:它一次只读一段文字,所以每块文档的那串数可以事先算好、存起来。
做重排这件事的模型,在各家框架里叫「交叉编码器」(cross-encoder)。 它一次读的不是一段,而是「查询 + 一条候选」拼在一起的两段。 于是那个「事先算好存起来」的便宜没了:换一个查询,全部候选都要重算一遍。 这就是它跑不动大规模的根本原因。
所以它是两阶段,不是替代
书把这一句写死了12:
两阶段的组合平衡了速度(初检)与精度(重排)。 重排是对合并结果的第二遍,不是用来替代快速初检的。
理由很算术: 重排要给每一条候选单独过一遍,20 万条上跑不动。 必须先用便宜的办法把 20 万条砍到几十条,重排才有可能。
书那个跑例:五段候选,重新排一遍
做法是让一个模型给每份候选按相关性打 1 到 5 分,然后只留前几名13。
查询:"特斯拉还能不能保住电动车市场的领先地位?"
五段候选(书给的原样,这里译出大意):
1. 特斯拉的超级充电网络和技术优势,正面对比亚迪和传统车厂的竞争
2. 特斯拉产量在涨,但价格战威胁它的市场份额
3. 因为气候变化和法规,整个汽车业正在转向电动车
4. 芯片短缺正在扰乱汽车业的供应链
5. 消费者对自动驾驶和高级配置的需求,影响着电动车竞争格局
提示里写的是:"请评估每份文档与这个查询的相关程度,
给出 1 到 5 的相关性分数,5 最相关。"
模型重排后的顺序(书给的结果):5 号最相关,其后依次是 4 号、2 号、1 号。
取前三 → 只有 5、4、2 号进最终提示,1 号和 3 号被砍掉。
图说:注意这里出现了两组"5" —— 一组是块的编号,一组是打分的满分。
书给出的是重排后的**次序**(哪几号块排在前面),没有给出每块的具体分数。
它买到了什么、什么时候别用
收益14:能放心地从 50 多个候选里筛到 5 到 10 个高质量的。
书给的适用条件里,有一条特别值得单记14:
「合并之后取前五」比「每个来源各取前五」质量更好。
为什么这一条重要: 多个来源各取前五是最省事的做法, 但它假设了每个来源的贡献一样大——而真实情况常常是某一个来源里有全部三条有用材料, 其余来源一条都没有。合并再排,才可能把那三条全留下。
判断(我们的,不是书里的):这一节讲的三招里,只有重排这一招是「减法」, 而书把它和前两招并排放在同一章,容易让人以为三招是同一类东西、可以一起加。 实际上它们的关系是有方向的:前两招和第 11 章那几招都在往提示里塞更多东西, 而重排是唯一一个把东西拿出去的。 一套系统可以完全不用前两招, 但只要用了第 11 章任何一招,重排就几乎是必需的—— 否则你只是把噪声(混在检索结果里、跟问题其实没关系的那些块)撒得更大, 然后原样交给模型。 如果错,会错在: 如果你的取回块数本来就很小(比如永远只取三块), 那候选数根本上不去,重排确实可有可无。 判据是:数一数一次提问最终有多少块候选摆在面前。书给的线是 20 条。
跳过它的时候15:只有单一检索源、而且它自己的排序已经够好; 初检返回的结果本来就高度相关;或者多那一次模型调用的成本, 拿指标衡量下来并不划算(该拿什么指标衡量,第 17 章讲)。
8. 主走查:一份有章有节的手册,一次查询走到底
这是本章的主走查,前面每个机制都在它上面占一步。
(子块约 250 字符、四个合一个父块约 1 000 字符、每块约 250 token、 窗口约 750 token、「叶 1、2、5」那个命中格局、五段候选重排成 5→4→2→1、 「翻三倍」都是书里的;下面的手册内容、块数、以及最后那笔账是我们为演示编的。)
第 0 步:入库时切两遍
一份 40 页的设备维护手册,有章有节 。
切成子块:每块约 250 字符,共 1 280 块
每块存四样:子块编号、子块正文、它那 1 536 个数、它属于哪个父块的编号
合成父块:每 4 个子块合成一个,共 320 块,每块约 1 000 字符
父块只存正文,不算那 1 536 个数
子块编号按原文顺序排:1、2、3……1 280
↑ 这一步同时满足了招二的前提 —— 两招共用同一份编号
第 1 步:提问、初检
用户问:"3 号泵在高温下报 E-17 该怎么处理?"
→ 换成一串数 → 在 1 280 个子块里比相近程度 → 取前 5
子块编号 相近程度 它属于哪个父块
叶 1 0.74 父块 1
叶 2 0.71 父块 1
叶 41 0.68 父块 11
叶 77 0.67 父块 20
叶 5 0.66 父块 2 ← 记住它排在第 5
(这些相近程度是为演示编的。)
↑ 这五块里,只有叶 5 真的写着 E-17 是什么。
而它在这个榜上排最后 —— 因为它那 250 字符里全是报警码和处置动作,
"3 号泵""高温"这些和问题字面接近的词反而没几个。
这就是这一章要收拾的局面。
第 2 步:招一,按结构补
数一数每个父块下命中了几个子块:
父块 1 ← 叶 1、叶 2 命中 2 个,达到门槛(门槛 = 2)
父块 2 ← 叶 5 命中 1 个,不达标
父块 11 ← 叶 41 命中 1 个,不达标
父块 20 ← 叶 77 命中 1 个,不达标
于是取回:
父块 1 的完整正文 约 1 000 字符 ← 整段
叶 5、叶 41、叶 77 各约 250 字符 ← 只取本身
合计约 1 750 字符,而不是 5 × 250 = 1 250 字符
第 3 步:如果改用招二,会取回什么
换成按位置补(前后各一块):
叶 1 → 取 叶 0、1、2 (叶 0 不存在,只取 1、2)
叶 2 → 取 叶 1、2、3
叶 5 → 取 叶 4、5、6
叶 41 → 取 叶 40、41、42
叶 77 → 取 叶 76、77、78
去重之后:叶 1、2、3、4、5、6、40、41、42、76、77、78 共 12 块
合计约 3 000 字符,窗口约 750 token 一组
两招的差别一眼可见:
招一 取回 1 750 字符,其中 1 000 是"整段父块"(连贯)
招二 取回 3 000 字符,是 12 个碎片(更全,但更长也更碎)
第 4 步:候选还不止这些
这次提问同时还跑了第 11 章招二(多问几遍),四个问法各搜一次:
去重之后,候选从 5 块涨到 23 块。
23 块 × 平均 250 字符 ≈ 5 750 字符,再加上招一扩出 来的父块 ——
已经超出"取前三块拼进提示"那个原始设计一个数量级。
↑ 这就是重排必须出场的时刻。
第 5 步:招三,重排
把 23 块连同原问题一起交给一个模型,让它每块打 1 到 5 分:
块 打分 判断依据
叶 5 5 它直接写着 "E-17:高温保护触发"
父块 1 4 讲 3 号泵的常规维护,含高温工况
叶 41 4 讲报警码的通用处置流程
叶 77 2 讲另一型号泵的报警码
其余 19 块 1–2 只是提到"泵"或"高温"
(这些分数是为演示编的;书那个跑例只给了排序,没给分数。)
取前三:叶 5、父块 1、叶 41
最终进提示的材料:约 1 500 字符,而不是 5 750 字符。
↑ 对照第 1 步那张榜:叶 5 在初检里排第 5,这里排第 1。
第一遍是把问题和每块各自单独打分打出来的,所以它认不出
"E-17" 那一串就是用户要的东西;第二遍把问题和这一块摆在一起看,才认得出。
第 6 步:把这一章做的事收成一句
进提示的材料 它够不够回答问题
什么都不做(取前 3 块) 750 字符 叶 1、2 讲维护周期,叶 41 讲通用处置流程
—— 三块里没有一块写着 E-17 是什么
只补上下文(招一) 1 750 字符 够了,但混着两块无关的
补 + 撒大网(招一 + 多问) 5 750 字符 全在里面,但淹了
补 + 撒大网 + 重排 1 500 字符 够,而且干净
图说:第一行是这一章的起点 —— 含答案的那块(叶 5)初检排第 5,
"取前三"正好把它切掉了。
最后一行的字符数比第二行还少,却比它更全 ——
这就是"先撒大网再挑"和"一开始就取三块"的差别。
9. 三招各自的触发条件
书没有把三招放在一起比过,下面这张表是我们照三处「什么时候用」归的31614:
| 你观察到的现象 | 用哪一招 |
|---|---|
| 文档有明确层级(有章有节的手册、论文) | 招一 按结构补 |
| 答案的背景常被切在隔壁块(法律文书、技术手册、叙事文本),而且块本身只有 200–500 个 token | 招二 按位置补 |
| 从多个来源合并了 20 条以上候选,或者初检捞回来的东西噪声大 | 招三 重排 |
三条反面判据合起来也是一句话:
块本身已经够大、文档本来没有层级、只有单一来源而且它排得已经够好—— 三招一个都别加。
这是全书那 个反复出现的句式的第五次露面(第 10 章三次、第 11 章一次)。 第 19 章把九处收在一起,并给它起个名字。
10. 作者的判断与证据
| 说法 | 它是什么 |
|---|---|
| 「搜索要小块、生成要大块」这个两难 | 是机制推导,成立,而且它是这一整章存在的理由 |
| 父子两级的做法 | 是事实描述,各家框架里都有对应实现 |
| 「叶 1、2、5,父块 1 下有两个命中」那个例子 | 是书里图 7-13 的说明,不是跑出来的实测 |
| 子块 250 字符、父块 1 000 字符 | 是书那个跑例用的参数,书没有解释为什么是这两个数 |
| 门槛设成 2 | 是跑例里的取值,书没有讨论怎么定这个门槛 |
| 按位置补需要「编号反映原文顺序」 | 是实现事实,而且是硬前提 |
| 每块 250 token、窗口 750 token | 是跑例参数,同样没有解释来历 |
| 拜仁慕尼黑那个例子 | 是书里图 7-14 的说明,用来讲清失败形状,不是实测 |
| 两招的区别(位置扩张 vs 相关性扩张) | 是书自己写的区分,写得很准 |
| 「1 000 扩到 3 000,翻三倍」 | 是算术,成立 |
| 重排是来收拾多来源候选的 | 是机制推导,而且它把第 11 章和第 13 章串了起来 |
| 初检各自独立打分、重排把两者放在一起看 | 是事实描述,这是这一章最硬的一条机制 |
| 「合并后取前五」胜过「每个来源各取前五」 | 作者的判断,没有数据。 但推理成立 |
| 「能放心地从 50 多个筛到 5–10 个」 | 作者的经验说法,没有测量 |
| 特斯拉那五段候选的重排结果 | 是书里跑出来的一次真实输出,但书只给了次序,没给分数 |
11. 边界与局限
- 所有参数都没有解释来历。 250 字符、四合一、门槛 2、前后各一块—— 书一个都没说为什么是这个数,而这几个数直接决定检索质量;
- 门槛怎么定,书完全没讲。 一个父块下有 8 个子块,门槛该是 2 还是 4? 书的例子里父块只有 4 个子块、门槛是 2,别的情形一律没有覆盖;
- 两招能不能同时用,书没说。 招一和招二共用同一份块编号,技术上可以叠加, 但书从没讨论过叠加之后的上下文长度会怎样;
- 重排的成本没有量过。 「多一次模型调用」是多少毫秒、多少钱? 书只说「交叉编码器更快但仍有开销」,没有一个数;
- 书没有讲重排该保留几条。 跑例取前三,适用条件里说「筛到 5–10 个」, 两处对不上,而且都没有依据;
- 重排本身会不会排错,书没有讨论。 它把一个「快但粗」的排序换成了 「慢但准」的排序,可后者依然是模型的判断,依然会错—— 而这一次错了,被砍掉的候选再也没有第二次机会;
- 书没有把去重讲清楚。 多问几遍会让同一块被多次取回, 合并时怎么去重、去重之后名次怎么算,全书没有一处交代。
12. 可带走的
- 一切从一个两难开始:搜索要小块才够聚焦,生成要大块才有上下文。 一刀切下去只能得到一个尺寸,所以要么补、要么切两遍;
- 父块与子块 = 同一段原文存两遍: 小的用来搜(存那 1 536 个数), 大的用来交给模型(不存数),两者靠编号连着。几乎不增加换算的开销;
- 招一按结构补:数一数同一个父块下命中了几个子块,超过门槛才把整段父块交出去。 门槛的作用是把「碰巧命中一句」和「这一整段确实相关」分开;
- 招二按位置补:命中哪一块,就固定带上前后各 N 块。 它的硬前提是入库时块编号必须反映原文顺序——所以这是入库时就要定的事;
- 两招的分界:招二看位置、不看内容,更简单但不会随机应变; 招一看相关性,更聪明但要维护父子关系;
- 补上下文的代价可算:1 000 个 token 扩到 3 000 就是三倍,成本和延迟一起涨。 块本身已经有 500 个 token 以上就别扩了;
- 重排不是「第三 种补法」,它是前面那些「把网撒大」的做法的必要配套—— 第 11 章那几招和让模型自己决定的系统,都会同时产出几十个候选;
- 它必须是第二阶段,不能替代初检: 初检把查询和文档各自独立打分, 快但粗,能在 20 万条上跑;重排把两者放在一起看,准但慢,只能在几十条上跑;
- 「放在一起看」这件事的名字叫交叉注意力,对应的模型叫交叉编码器—— 你在框架文档里会撞见这两个词;
- 一条容易被忽略的做法判据:「合并后取前五」胜过「每个来源各取前五」。 因为有用的材料常常集中在某一个来源里;
- 三招的触发条件: 文档有层级 → 招一;背景常被切在隔壁块 → 招二; 候选超过 20 条 → 招三。都不满足就三招一个都别加。
13. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 那个两难 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:552(搜「small text chunks for semantic search while providing larger parent chunks」) |
| 父子块的做法与门槛 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:556(搜「counts the number of child chunks that belong to the same parent」) |
| 叶 1、2、5 那个例子 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:558(搜「leaf nodes 1, 2, and 5 are relevant」) |
| 250 字符 / 四合一 / 1 000 字符 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:566(搜「four child chunks are merged into one parent chunk」) |
| 招一该用与该跳过 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:660(搜「strong hierarchical structure」) · text/09-ch07-chapter-7-retrieval.txt:662(搜「Skip this approach when simple flat chunking works well」) |
| 招一的代价 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:664(搜「storage complexity versus context quality」) |
| 拜仁那个例子 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:682(搜「FC Bayern Munich」) |
| 编号必须反映原文顺序 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:697(搜「chunk ID reflects the original order」) |
| 250 token / 750 token | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:710(搜「roughly 750 tokens to the LLM」) |
| 招二该用与该跳过 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:718(搜「adjacent context frequently matters」) · text/09-ch07-chapter-7-retrieval.txt:720(搜「chunks already contain 500+ tokens」) |
| 翻三倍 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:722(搜「Expanding from 1,000 to 3,000 tokens」) |
| 招一与招二的区别 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:724(搜「fixed positional expansion」) |
| 谁会产出一堆候选 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:743(搜「Agent systems may query multiple tools」) |
| 重排的做法与那五段候选 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:764(搜「Supercharger network」) · text/09-ch07-chapter-7-retrieval.txt:795(搜「the fifth text chunk appears to be the most relevant」) |
| 只取前三 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:799(搜「select only the top three text chunks」) |
| 重排该用与该跳过 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:805(搜「combining 20+ candidates from multiple sources」) · text/09-ch07-chapter-7-retrieval.txt:808(搜「single retrieval source with good native ranking」) |
| 两阶段的机制 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:812(搜「treats the query and document independently」) |
| 从 50 多个筛到 5–10 个 | Chapter 7. Retrieval | text/09-ch07-chapter-7-retrieval.txt:810(搜「confidently filter from 50+ candidates」) |