几百万条还能毫秒级找到 — 规模化,与三个月后的漂移
这一章讲三件事: 为什么「和每一条都比一遍」在几百万条上根本走不通; 换成什么找法能把它变成毫秒级;以及为什么一套上线时好好的系统,三个月后会自己变差。
它在全书链条里的位置: 第 06、07 章解决的是「找得准不准」, 这一章解决的是「找得快不快」和「三个月后还准不准」。 这三章合起来,才是一套能真的跑在生产上的检索。
1. 顶层全景:把第 07 章那套政策库放大一万倍
这一章的主走查是同一套东西的放大版:第 07 章是 5 条政策文档,这一章是 200 万块。
① 最朴素的做法:查一次,和 200 万条各比一遍 → 慢到不可用
▼
② 换一种找法:把向量组织成分层的图,几跳就到 → 毫秒级
▼
③ 可它得全装进内存:768 个数 × 200 万条 × 每个数 4 字节 ≈ 6 GB
▼
④ 把每个数压小:压到 1 字节 → 约 1.5 GB;压到 1 比特 → 约 0.19 GB
▼
⑤ 拿压过的粗筛一遍,候选再交给第 07 章那个精排模型
▼
⑥ 三个月后:同一条查询开始取不到东西,而文档一个字没改
图说:①→② 是算法问题,③→④ 是内存问题,⑥ 是时间问题。**三件事互不相干,要分开修。**
第 ③ 步那笔换算是我们算的,书里没有给这个算式。
2. 慢不是机器不够快,是数量级问题
这一节先把问题的性质说清楚:它不是「买更好的机器」能解决的那一类。
先看现象:书给的两个门槛
十万篇文档就足以让朴素的向量检索慢到难受;到几百万篇,它完全不可用。1
注意这两个数之间只差一个数量级,而结论从「难受」跳到了「不可用」。
为什么
最朴素的做法是:把查询算成一个向量,然后和库里每一条向量都算一次余弦相似度,排序,取前几名。
库里 5 条: 比 5 次 ← 第 07 章那个例子,眨眼就完
库里 10 万条: 比 10 万次 ← 开始难受
库里 200 万条: 比 200 万次 ← **每来一个用户就要比 200 万次**
而且每一次比较不是比一个数,是比 768 个数。
200 万 × 768 ≈ **15 亿次乘法**,只为回答一个问题。
图说:这笔账是我们算的(200 万 × 768),书只说了「不可用」。
关键在于:**用户数翻倍,这笔账也翻倍;文档数翻倍,它也翻倍。**
这种「要和每一条都比一遍」的做法,行内的说法是它的耗时和条数成正比。 买快一倍的机器,只能让 200 万变成「相当于 100 万」——而库明年就会涨到 400 万。
所以出路不是更快的机器,是换一种找法。
3. 换一种找法:分层的图,几跳到位
这一节是全章机制最深的一处。它的核心思想可以用一个日常场景说明。
先看现象:你自己找路是怎么找的
你在一座陌生城市找一家店。你不会把全城每一栋楼都看一遍。 你先看大区(城东还是城西),定了大区再看街区,定了街区再看具体门牌。 每一步都把范围缩小一大截,而你从来没有遍历过整座城。
做法:把向量组织成层数递增的图
存放这些向量、并且能按接近程度查它们的那套东西,就叫向量库。 而这里要讲的这套找法叫分层小世界图——英文缩写 HNSW, 你在任何一个向量库的配置界面上都会见到这四个字母2。
第 2 层(最上面,最稀疏): ●─────────────●─────────────●
只有极少数向量,彼此连着长边
第 1 层(中间): ●───●─────●───●─────●───●───●
更多向量,边变短
第 0 层(最底下): ●─●─●─●─●─●─●─●─●─●─●─●─●─●
**全部 200 万条都在这一层**
查询进来之后:
① 从最上层随便一个点出发
② 看它连着的几个邻居,谁离查询更近就跳过去
③ 在这一层跳不动了(邻居都不如当前这个近)→ **沉到下一层,接着跳**
④ 一直沉到第 0 层,停下来的地方附近就是答案
图说:上层负责「一步跨很远」,下层负责「精细定位」。
**和找店那个过程是同一个形状:先定大区,再定街区,再定门牌。**
为什么这样就快:书给的两条性质
书自己拆了原因3:
| 性质 | 是什么 | 它带来什么 |
|---|---|---|
| 小世界结构 | 图里任意两点之间,只要跳很少的几步就能到达 | 上层那几步能跨越很远的距离 |
| 分层导航 | 一层一层往下沉,每一层都比上一层精细 | 逐级精化,不必回头 |
两条合起来,把「比的次数和条数成正比」变成了「比的次数随条数只慢慢地长」。 书用的正式写法是从 O(n) 降到 O(log n)4。
这个变化有多大,拿具体的数看:
和每一条都比: 200 万条 → 200 万次
只随条数慢慢长: 200 万条 → 大约 21 次
(因为 2 的 21 次方 ≈ 210 万)
图说:**这个对照是我们算的**,书只说了「毫秒级和数秒级的差别」。
更要紧的是增长方式:条数翻到 400 万,前者变 400 万次,后者只变 22 次。
「近似」这两个字必须留
这套做法找到的不保证是真正最近的那一条,而是「大概最近的那几条」。
「离查询最近的那几条」这个目标,行内叫最近邻;而只求「大概最近」的做法,就叫近似最近邻。
为什么可以接受这个「近似」: 因为下游还有第 07 章那个精排。 这一层只需要保证「正确答案在候选池里」,排序交给后面那个更贵更准的模型。 (这正是第 07 章「分三段」那条设计的另一半理由。)
两个可调的参数,书给了推荐值
| 参数 | 它管什么 | 书推荐 | 调高的代价 |
|---|---|---|---|
| M | 每个点最多连几条边 | 16 | 更准,但更占内存 |
| efConstruction | 建这张图的时候搜得多彻底 | 100 | 更准,但建索引更慢 |
书给这两个数的理由说得很实在:16 能给出足够的连通性、又不至于内存爆掉; 100 探索的候选够多、又不至于建得太久5。
走查第 ①② 步
200 万块政策文档,每块一个 768 维的向量
朴素做法: 比 200 万次 × 每次 768 个数 → 数秒级,不可用
分层图: 上层跳几步 → 沉一层 → 再跳几步 → 沉到底
实际比较次数在几百到几千次量级 → **毫秒级**
图说:「几百到几千次」是我们按 M=16、逐层下沉估的量级,**不是书里的数**;
书给的只有「毫秒级和数秒级的差别」这个结论。
4. 内存这一关:三种压法
这一节讲第二个问题。它和上一节完全无关,但会在同一个规模上一起找上门。
先看现象:一笔简单的乘法
高质量的嵌入常常是 768 维,甚至 1536 维。乘上几百万条文档,索引就要吃掉几十上百 GB 内存。6
把这笔账算出来(这笔换算是我们算的,不在书里):
先说清一个单位:计算机存东西的基本单位叫字节,一个字节是 8 个二进制位。
一个数用标准精度存 = 4 字节
一条向量 768 个数 = 768 × 4 = 3072 字节 ≈ 3 KB
200 万条 = 3 KB × 200 万 ≈ **6 GB**
换成 1536 维: ≈ 12 GB
换成 2000 万条: ≈ 60 GB
图说:**参照物:一台常见的机架式主机(行内叫服务器)内存是 32 到 64 GB。**
所以「几百万条 768 维」还塞得下,「几千万条 1536 维」就要开始想办法了。
做法:少存几位
第 06 章讲选模型的硬件那一轴时,已经给过这个动作的名字:量化—— 把每个数从「占很多位」压成「占很少位」来存。 这一节是同一个动作,只是作用的对象从模型的内部换成了这些向量。 (反过来作用在模型自己那些数上会怎样,第 11 章讲——那里它是「用一块游戏显卡微调一个大模型」的关键一步。)
书给了三种7。表里第二行会用到一个词:单独一个数,和「一串数」的向量相对,就叫标量。
| 压法 | 做什么 | 200 万条 768 维大约占多少 |
|---|---|---|
| 乘积量化 | 把向量切成几段,每段拿一本「码本」里最接近的那个代表来近似 | 看码本设置,通常能压到几十分之一 |
| 标量量化 | 每个数从 4 字节降成 1 字节 | 6 GB → 约 1.5 GB |
| 二值量化 | 每一维只留 1 个比特(正的记 1,负 的记 0) | 6 GB → 约 0.19 GB |
书特意说明了一件很实用的事:这三个词就是你在配置向量库时会看到的原词。8 所以它们必须留名——你迟早会在某个配置界面上撞见它们。
压完怎么用:和第 07 章那套接起来
书给的最佳搭配是:压过的向量做第一轮粗筛,候选再交给交叉编码器精排。9
200 万条(压成 1 字节的版本,1.5 GB,全在内存里)
│ 分层图搜索,取回 100 条候选 ← 快,但只是「大概最近」
▼
100 条候选
│ 交给第 07 章那个交叉编码器,逐对精排 ← 慢,但只跑 100 次
▼
最终 3 条
图说:**规模和质量在这里被分到了两层上,各自用最擅长的工具。**
这是第 07 章「分三段」和这一章「压缩」的合流点。
5. 工具这一关:一个库和一个数据库,不是一回事
这一节澄清一个非常常见、而且代价很高的混淆。
先看现象:重启一次,索引没了
书里明说了一件事,而它是很多人踩过的坑:
最常用的那个相似度搜索库是内存里的库,不是一个托管的数据库; 进程一退出,索引就没了。10
生产上要么手动把索引存到磁盘,要么改用一个自带持久化的向量数据库 ——所谓向量数据库,就是把上一节那个库补上「重启还在、能改能删、能分到多台机器」之后的完整产品。
一个库和一个数据库,差的是哪五件事
书列了向量数据库比裸算法多出来的东西11:
| 多出来的 | 具体是什么 | 没有它会怎样 |
|---|---|---|
| 持久化 | 向量存得住,重启还在 | 每次重启都要把几百万条重算一遍 |
| 增量更新 | 加一条、改一条、删一条,不必重建整个索引 | 文档改一个字就要重建全库 |
| 横向扩展 | 把向量分散到多台机器上 | 单机内存到顶就没法再涨 |
| 副本 | 多台机器各存一份 | 一台挂了,搜索就停 |
| 监控 | 看得到健康状况、性能和搜索质量 | 出问题了不知道出在哪 |
七个候选,以及各自的取舍
书给了一张对照表12,我们按「什么时候选它」重排了一遍:
| 什么时候选它 | 它是谁 | 代价 |
|---|---|---|
| 想最快跑起来,不想运维 | 托管服务那一类 | 规模上来之后费用高 |
| 元数据条件复杂(第 07 章那套过滤) | 支持复杂查询语言的那一类 | 配置复杂 |
| 要高性能的过滤 | 用系统级语言写的那一类 | 生态较小 |
| 只是开发和测试 | 接口最简单的那一类 | 生产特性有限 |
| 团队已经在用传统的表格式数据库(行内叫关系型数据库,数据按行列存在一张张表里) | 给这类数据库加的向量扩展 | 超大规模时受限 |
| 超大规模部署 | 云原生、微服务架构的那一类 | 运维复杂 |
| 团队已经有一套搜索基础设施 | 传统搜索引擎加上向量能力 | 不是为向量而生的 |
这张表里最该注意的是加粗的那两行:如果你已经有一套数据库或者搜索系统, 先看它能不能加上向量能力——省下的运维成本,常常比性能差的那一点值钱得多。
一条实在的生产经验
把原文一起塞进向量库里,省掉一次去别处查的动作——书说这样架构更简单、用户等的时间更短 (「从发出请求到拿到结果要等多久」这个量,行内叫延迟)13。
但书紧接着给了规模上的警告:
百万级切块时,把原文存在向量库里会让索引占的内存明显膨胀、成本上升。 企业常见的做法是:向量库里只放向量和一个块的编号,原文放在便宜的文档库里,按编号去取。14
这条值得记住,因为它是「小规模的最优解在大规模上是错的」的一个干净例子。
6. 三个月后:文档一个字没改,它开始找不着了
这一节讲一件必然会发生、而且几乎没人在上线时考虑的事。
先看现象
以前答得好的问题开始给含糊的回答;以前能精准命中的查询,现在只捞回一些松散相关的东西, 甚至什么都捞不到 。15
而你的文档一个字都没改。
第一种漂移:人变了
就算你的文档一个字没改,人们提问的方式会变。16
书给的三条原因:新的产品功能、政策措辞的演化、甚至用词习惯的文化变迁。
结果是用户的问法和索引里的向量慢慢分开。 书给这件事起了名字:嵌入漂移。
上线时: 用户问「怎么开通国际漫游」 ← 和文档里的说法很接近,命中
半年后: 新套餐上线,大家改口叫「出境流量包」
而文档里还写着「国际漫游」
→ 两串数慢慢分开 → **同一个功能,查不到了**
图说:**这个例子是我们编的**,书只给了三条成因和症状。
但机制是书里的:**不是检索器坏了,是你的嵌入和当下的世界脱节了。**
第二种漂移更隐蔽:模型换了,文档没重算
换了嵌入模型或者升级了版本,却没有把文档重新算一遍—— 哪怕模型结构或训练材料只有小改动,文档在那张「意思地图」(行内叫向量空间)上的位置也会移动。17
书这里有一句极准的话:
不一致地重算,查询和文档就会分开——不是语义上分开,是数值上分开。
「数值上分开」这四个字值得停一下。 第一种漂移是「大家真的换了说法」,那是世界变了; 第二种漂移里,查询和文档说的还是同一件事,只是两边用了不同的尺子去量 ——得到的相似度数字毫无意义。
这正是第 06 章那句「换供应商要把整个资料库重算一遍」的另一副面孔。
处置:关键不是周期,是一致
书的建议是把「算嵌入」当成一个活的过程,而不是一次性的建库动作18:
有的团队每晚重算 有的每周重算 有的每次模型更新之后重算
**书说没有一个普适的周期。** 真正的要求只有一条:
查询用的是哪个模型的哪个版本,文档就必须用同一个。
图说:**周期可以商量,一致不能商量。** 一致性被打破的那一刻,
相似度这个数就不再有意义——而它不会报错,只会悄悄变差。
书在小结里还补了一条选型建议:选一个足够通用的嵌入模型,可以降低重算的频率和成本。
走查第 ③ 步:漂移在走查上是哪一步
第 ①–⑤ 步做完:200 万块,分层图 + 压缩 + 精排,毫秒级,准确率满意
│ 三个月过去,没有任何人改过任何东西
▼
同一条查询,取回的东西开始变差
│ 查两件事:
├─ 用户的问法变了吗? → 是第一种漂移,重算 + 补充新说法
└─ 有人升级过嵌入模型吗?→ 是第二种漂移,**必须把全库重算一遍**
图说:这两种漂移的症状**一模一样**,但修法完全不同。
**先查有没有人动过模型版本——这一条五分钟能查完,而重算全库要几个小时。**
7. 作者的判断与证据
书里给了证据的:
| 说法 | 证据是什么 |
|---|---|
| 十万篇难受、几百万篇不可用 | 两个具体的门槛,但书没有给测试条件 |
| 分层图把「要比多少次」从和条数成正比降到只慢慢长 | 一条算法性质,来自算法本身,不需要实验 |
| M=16、efConstruction=100 | 推荐值 + 理由(连通性够、内存不爆) |
| 那个搜索库不提供持久化 | 一条事实陈述,可以直接核对 |
| 三种压缩就是配置界面上的原词 | 一条实用观察,可以直接核对 |
| 两种漂移 | 一条机制解释 + 症状描述,没有量化数据 |
作者的推测或没给证据的:
| 说法 | 它是什么 |
|---|---|
| 「毫秒级和数秒级的差别」 | 一个量级判断,没有基准测试 |
| 七个数据库的取舍 | 一张选型表。 每一格都是一句话判断,没有对照数据 |
| 「企业常见做法是只存向量和编号」 | 一句行业观察,没有来源 |
| 「没有普适的重算周期」 | 一句诚实的坦白,而这比给一个假的周期有用 |
判断(我们的,不是书里的): 这一章三个问题里,漂移是唯一一个「不做就一定出事」的。 慢和内存都会当场暴露(用户会抱怨,机器会报警); 而漂移不报错、不宕机、不触发任何告警——它只是让你的系统一点点变差, 而所有指标都还是绿的。 这正是第 01 章那句「语义正确性在面板上没有格子」在检索这一层的具体形态。 如果错,会错在: 如果你的系统本来就有一套按周跑的检索质量评测(第 09 章那一套), 漂移会在评测分数上显现出来,那它就不是「看不见的」。 判据是:你有没有一个会随时间下滑的检索质量数字在被人盯着。
8. 边界与局限
-
没有讲怎么选压缩比例。 三种压法各会掉多少准头、什么场景该选哪种,书只给了名字和效果方向;
-
IVF 只有一句。 书提了一句「文档频繁新增或者内存预算紧,IVF 可能更合适」, 但 IVF 是什么、为什么在这两种情况下更合适,一个字没讲——我们也没有补到一手来源;
-
没有讲重算全库要多久、要花多少钱。 这是决定「多久重算一次 」的关键输入,书完全没提;
-
没有讲怎么检测漂移。 症状描述得很清楚,但「用什么数字能提前发现它」一句没有 ——这一块要到第 09 章和第 19 章才有工具;
-
七个数据库的对照表会过时。 这类产品每年都在变,表里的具体判断建议只当参考, 不要当结论。
9. 可带走的
全章那条走查,一行写完: 200 万块政策文档 → 朴素做法要比 200 万次 (每次比 768 个数,约 15 亿次乘法,这笔账是我们算的)→ 换成分层的图, 上层跳远、下层精定,几百到几千次比较,毫秒级 → 内存要 6 GB(768 × 4 字节 × 200 万, 这笔换算是我们算的)→ 每个数压成 1 字节约 1.5 GB、压成 1 比特约 0.19 GB → 拿压过的粗筛 100 条,交给第 07 章那个精排 → 三个月后同样的查询开始取不到, 先查有没有人换过嵌入模型。
- 慢不是机器不够快,是数量级问题: 十万条难受、几百万条不可用,买更快的机器解决不了;
- 出路是换一种找法:分层的图,上层跳远、下层精定,几跳到位;
- 它靠的两条性质:小世界(任意两点几跳可达)+ 分层(逐级精化);
- 代价是「近似」: 它找的是「大概最近的那几条」,所以后面必须接一个精排;
- 两个参数:每个点最多连几条边(推荐 16)、建索引搜得多彻底(推荐 100);
- 内存的账要自己算一遍: 768 个数 × 4 字节 × 条数。200 万条 ≈ 6 GB;
- 量化就是「少存几位」——第 06 章那个动作,这里作用在向量上。三种压法的名字 就是你在配置界面上会看到的原词;
- 压过的粗筛 + 精排,是规模和质量的标准分工;
- 那个最常用的搜索库是内存里的,进程一退索引就没了——生产要么存盘、要么换数据库;
- 数据库比裸算法多五件事: 持久化、增量更新、横向扩展、副本、监控;
- 已经有数据库或搜索系统的团队,先看它能不能加向量能力——省下的运维常常更值钱;
- 原文塞进向量库在小规模上更省事,在百万级上会让内存暴涨——这是「小规模最优解在大规模上是错的」的样板;
- 两种漂移症状一样、修法不同: 人的问法变了 vs 模型换了没重算。先查有没有人动过模型版本;
- 周期可以商量,一致不能商量——查询和文档必须用同一个模型的同一个版本;
- 漂移是这一章里唯一「不报错、不告警、只是慢慢变差」的那一种。
10. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 十万篇难受、几百万篇不可用 | Chapter 4: Embeddings and Vector Search | text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1155(搜「painfully slow」) |
| 分层小世界图的结构与搜索过程 | Chapter 4: Embeddings and Vector Search | text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1160(搜「Hierarchical Navigable Small World」) · text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1169(搜「increasingly connected layers」) |
| 两条性质与复杂度 | Chapter 4: Embeddings and Vector Search | text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1177(搜「small world」) · text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1180(搜「O(n) to O(log n)」) |
| M 与 efConstruction 的推荐值 | Chapter 4: Embeddings and Vector Search | text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1184(搜「M (the maximum」) · text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1187(搜「16 provides good connectivity」) |
| 那个搜索库不提供持久化 | Chapter 3: Grounding Outputs with RAG | text/06-ch03-chapter-3-grounding-outputs-with-rag.txt:1412(搜「in-memory similarity search library」) |
| 数据库多出来的五件事 | Chapter 4: Embeddings and Vector Search | text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1266(搜「Persistence and durability」) · text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1276(搜「Horizontal scaling」) |
| 七个候选的对照 | Chapter 4: Embeddings and Vector Search | text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1296(搜「Rapid prototyping」) · text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1310(搜「Existing Elastic stack」) |
| 内存的账与三种压法 | Chapter 4: Embeddings and Vector Search | text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1800(搜「768 or even 1536 dimensions」) · text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1808(搜「Scalar Quantization」) |
| 压过的粗筛 + 精排 | Chapter 4: Embeddings and Vector Search | text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1812(搜「multi-stage systems」) |
| 原文塞进向量库的规模警告 | Chapter 4: Embeddings and Vector Search | text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1564(搜「bloat index RAM」) |
| 第一种漂移 | Chapter 4: Embeddings and Vector Search | text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1771(搜「are not static」) · text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1782(搜「defaulting to vague replies」) |
| 第二种漂移与「数值上分开」 | Chapter 4: Embeddings and Vector Search | text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1789(搜「without reprocessing your documents」) · text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1791(搜「not semantically, but」) |
| 关键是一致,不是周期 | Chapter 4: Embeddings and Vector Search | text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1794(搜「embed documents」) · text/07-ch04-chapter-4-embeddings-and-vector-search.txt:1796(搜「the key is consistency」) |