正在加载，请稍候
召回层是唯一按秒计费的一层。换量化索引前先把内存、召回、运维三笔账算清，再用分档表判断你的规模该不该换。
2026 年 9 月，主流模型聚合目录里，嵌入与重排已经和文本、图像并列成为一级分类，同一周新增的条目中还有多个按「天」滚动版本号的模型。对企业知识库 AI 项目来说，这个信号很直接：召回质量不再只由索引算法决定，嵌入模型自身的更替节奏，已经把检索层推到了成本谈判桌上。
过去两年，多数团队把预算花在摄入层——解析、切片、清洗。真正开始吃钱的第二层是召回：索引常驻、副本、重建窗口，全是按秒计的固定支出。
两层之间交换的东西很少，但每一条都牵一发动全身：向量维度、是否做归一化、向量 ID 空间、可用于过滤的元数据字段、切片粒度与重叠长度。
这份契约在项目初期往往随手就定了，代价要到后期才显现——换嵌入模型意味着全量重算向量并重建索引，而召回层所有参数都是围绕旧维度调出来的。上游那篇讲解析层的切片与向量化取舍已经把摄入侧讲透，本文只谈下游这一段。
摄入层可以排队、可以夜间跑、失败可以重试，它的成本形态是「一次性 + 增量」。召回层不一样：索引要么常驻内存，要么每次查询都付出磁盘随机读的代价。
规模不大时看不出来。一旦切片数进入千万级，内存成本会先于查询性能触到天花板——这也是近两年一批超大规模检索系统，把主力结构从全内存图索引换成「量化 + 倒排」组合的直接原因。更早一步走到百亿量级的系统是怎么演进的，从 Demo 到百亿级向量的架构路径里有一段可对照的过程。
换索引不是一次技术升级，而是一次三向权衡。只谈其中一笔的方案都不完整。
| 账目 | 度量口径 | 换成量化结构后的方向 | 建议的验收线 |
|---|---|---|---|
| 内存账 | GB / 百万向量、单节点常驻、查询峰值 | 明显下降 | 单节点常驻 ≤ 原值 40% |
| 召回账 | 前十命中率、前五十命中率、排序质量 | 下降，需要补偿手段 | ≥ 原索引同期指标的 97% |
| 运维账 | 全量重建耗时、增量写入 p99、回滚耗时 | 重建更快、切换流程更复杂 | 重建 ≤ 4 小时、回滚 ≤ 15 分钟 |
全内存图索引的开销有两块：每向量的原始浮点数据，加上图结构本身——每个节点保存若干条邻居边，边数由构建参数决定。这也是这类结构在业内被叫作内存大户的原因。
量化方案换了一套结构：码本 + 压缩码 + 倒排桶。原始向量可以退到磁盘或对象存储，只在精排阶段按需回捞。压缩比越高，内存账越好看，召回账越难看。
算这笔账的正确顺序是先算「GB / 百万向量」，再乘以分片数和副本数。副本数是最容易被漏掉的一项，它直接成倍放大内存支出。
量化是有损压缩，损失不可能为零，能做的是把它限制在用户无感的范围内。工程上通常三招并用：压缩码粗筛、原始向量精排、多路召回并行去重。
多路召回指关键词路与语义路同时跑，各自取候选后合并去重。它对知识库场景尤其重要，因为制度编号、产品型号、人名这类查询本质上是字面匹配，纯语义召回反而容易漂移。
检索增强生成的召回率评测最怕口径漂移。建议固定 200–500 条人工标注查询，冻结切片版本、嵌入模型版本与索引参数，记录前十命中率、前五十命中率与端到端 p95 延迟。
别只看平均值，要分桶看：短查询、长文档、表格、代码片段各算一组。多数「换完掉点」的案例，掉的是其中某一个桶；如果掉的是字面匹配那一桶，先排查检索不到内容的六类常见成因，再动索引参数。
量化结构的重建通常更快，但多了一个前置环节——码本训练要留出一批代表性样本，样本分布偏了，整体压缩质量会下滑。
增量更新是量化的老问题。新增向量可以直接编码，删除只能先打标记、再定期合并。长期不合并的索引会同时劣化内存与召回。
切换必须走蓝绿，步骤大致如下：
公开榜单的分数只能用来筛掉明显不合格的候选，不能用来排序。嵌入模型对比真正决定成败的是下面四项，且必须在自己的数据上跑。
中文长文档。拿两千字以上的切片建检索集，看长文档内部的关键句能不能被召回出来。很多模型在短句基准上表现接近，一进长文档就分层。
表格与代码片段的语义保真。结构化内容被拍平成一行文本后语义衰减最快。测试集里要专门放表格问答与代码检索两类查询。
维度与单价的乘积。计费按 token 走，存储和内存按维度走。高维度模型在召回上未必更好，却会让索引常驻成本线性上涨。
版本迁移可回滚性。供应商是否保留旧版本、能否双写、能否灰度切换。模型目录按天滚动的节奏意味着：不能回滚的模型等于不能上生产。
判断标准不是「有没有更先进的结构」，而是内存账在总成本里的占比，以及扩容速度能否跟上数据增长。
| 向量 / 切片规模 | 建议结构 | 该动手的信号 |
|---|---|---|
| 300 万以下 | 全内存图索引足够 | 没有信号，别提前优化 |
| 300 万 – 3000 万 | 图索引 + 副本 + 合理降维 | 单节点内存占用超过一半，扩容开始排队 |
| 3000 万 – 5 亿 | 量化倒排 + 原始向量精排 | 内存支出占检索层总成本三成以上 |
| 5 亿以上 | 量化为主 + 分层存储 | 必须，且需要自建评测与合并流水线 |
业界常以 SPANN 指代这类「量化码 + 倒排桶」的分区结构。它的核心不是某个具体算法，而是把「全量常驻」换成「按需回捞」。这一点想清楚，选哪套实现都只是细节——托管数据库自带的那套能力边界在哪里，原生向量搜索的适用边界里有对照。
如果第 5–8 周发现增量写入的 p99 已经超出预算，说明当前业务的写入模式不适合量化倒排，这时候应该停在原地，而不是硬推。
要按自己的切片规模、查询分布和副本策略把这三笔账算一遍，可以把现有索引参数和一段脱敏查询日志发给我们，出一版对照方案——聊聊你的检索层现状；也可以先看检索层与知识库工程案例，里面有同量级的落地路径；部署形态还没定的，私有化部署里的六个工程决策可以先过一遍。
粗筛阶段会掉，端到端不一定。把精排和关键词多路召回补上之后，多数场景可以做到与基线持平，代价是查询链路变长、延迟略升。
不要同时换。两个变量一起动，出问题时无法归因。先用现有模型把索引换完、跑通评测口径，再单独立项换模型。
要看删除占比。以追加为主、删除很少的场景适合；频繁删除与改写会让标记堆积，必须配合定期合并，否则内存账和召回账会同时恶化。
用内存账说话。把「单节点常驻 × 节点数 × 单位内存成本」换算成年支出，再对比一次性迁移工作量。召回层是唯一按秒计费的一层，这个说法最容易听懂。