跳到主要内容
Agent Memory 分离式协同

第6章：鲲鹏路线 3——超低内存混合介质向量检索

把 RabitQ + PCA + SIMD 的量化体系叠在 UB + SSD 混合介质上，做到"1/100 内存 + 高召回"——展开量化算法链路、混合介质数据流、二阶段精排的延迟控制、与 Ch5 全局整图路线的工程互补

鲲鹏 RabitQ PCA SIMD 量化 混合介质 DiskANN

Ch5 给了一条**“砸钱换召回 + 低 P99”的路——千亿级 HNSW 整图。但很多生产场景里预算才是第一约束**。鲲鹏路线 3 是另一条工程哲学：把内存占用砍到 1/100，让千亿向量也能用普通节点装下。它的核心是 RabitQ + PCA 的量化体系叠加 UB + SSD 的混合介质——粗排在 UB 池里跑紧凑量化向量，精排再回 SSD 拿原始向量。这一章把整套链路、关键数字、与 Ch5 的工程互补关系拆开讲。

📑 目录

1. 鲲鹏路线 3 的工程定位

1.1 一个让所有架构师纠结的取舍

Ch5 的路线 2 给了”砸钱换召回 + 低 P99”——但单价虽然比全 DRAM 便宜 12 倍，绝对值仍然是 12 万 USD / 年起步。对中型公司、垂直应用、内部系统而言，这仍然太贵。

但如果只用 SSD（DiskANN 路线），P99 又会不稳。这是工程师反复纠结的取舍：有没有一种方式让”千亿规模 + 高召回 + 中等 P99 + 低成本”同时做到？

1.2 鲲鹏路线 3 的方法论

鲲鹏路线 3 给出的回答是：用更激进的量化把”内存占用”再砍一个量级——千亿向量从 ~300 TB 压到 ~3 TB——然后让 UB 池只装压缩后的索引、SSD 装原始向量、二阶段精排把召回拉回来。

                            ┌──────────────────────────────┐
                            │   原始向量 100B × 3KB        │
                            │   = 300 TB（在 SSD 上）      │
                            └──────────┬───────────────────┘
                                       │
                                       │  PCA 768 → 64 维
                                       │  + RabitQ float32 → 1bit
                                       ▼
                            ┌──────────────────────────────┐
                            │   紧凑索引 100B × ~64 bits   │
                            │   = ~3 TB（在 UB 池）        │
                            └──────────┬───────────────────┘
                                       │  Phase 1: 粗排
                                       │  (汉明距离 / SIMD)
                                       ▼
                            ┌──────────────────────────────┐
                            │   候选 top-1000              │
                            └──────────┬───────────────────┘
                                       │  Phase 2: 精排
                                       │  (回 SSD 读原始向量)
                                       ▼
                            ┌──────────────────────────────┐
                            │   最终 top-10                │
                            └──────────────────────────────┘

🌟 核心定位：用量化把内存压到极致，再用混合介质拼出”召回 + 延迟”——这是路线 3 的工程哲学。

2. 量化体系：PCA + RabitQ + SIMD 三件套

2.1 第一步：PCA 降维 (768 → 64)

PCA（主成分分析）是经典的统计降维方法。原理：

  • 找数据集主方向（principal components）
  • 把每个向量投影到前 k 个主方向上
  • 高维空间的距离关系大致保留在低维空间里

应用到 768 维向量时：

  • 把 768 维投影到前 64 维 → 12x 压缩
  • 在常见 embedding 上 recall@10 损失 ~3-5%（可被精排弥补）

为什么这步重要：

  • 后续的 RabitQ 量化在低维上效果更好（高维空间太”空”，量化误差更难控）
  • SIMD 加速对 ≤ 128 维的距离计算更高效
  • 整体存储压力直接降一个量级

2.2 第二步：RabitQ 旋转 + 二值化 (float32 → 1bit)

RabitQ 是 2024 年 VLDB 论文提出的量化方法，核心思想：

  • 先做一个随机正交旋转——把向量分布”打散”到各方向
  • 再做符号量化——每个维度只保留正负号 (1 bit)
  • 距离查询用汉明距离做粗排——比浮点距离便宜上百倍

数学层面：

  • 旋转矩阵 RR 是随机正交矩阵
  • 量化函数 q(v)=sign(R⋅v)q(v) = \text{sign}(R \cdot v)
  • 两向量的距离用 popcount(q(a) ⊕ q(b)) 估算

为什么 RabitQ 比传统量化（PQ / OPQ）好：

方法压缩率距离估算误差计算复杂度
传统 PQ8-32x中子向量查表
OPQ8-32x较低子向量查表 + 旋转
RabitQ64x（每维 1 bit）极低（理论可证）popcount + SIMD

把 PCA 64 维 + RabitQ 1bit 叠加：原 768×32bit = 24576 bits → 64×1bit = 64 bits → 总压缩比 384x。

2.3 第三步：SIMD 加速距离计算

SIMD（单指令多数据）让一条 CPU 指令同时处理多个数据。把 RabitQ 量化向量装进 256-bit / 512-bit 寄存器：

  • 一次距离计算可以同时算 4-8 对向量的汉明距离
  • popcount 是现代 CPU 的硬件指令（AVX2 / AVX-512 都有）
  • 实测每秒可做 10⁹ 次量化距离计算 / CPU 核

这个吞吐量是什么概念：千亿向量做一遍粗排 = 100B 次距离 = ~100 秒 / 单核——用 32 核可以做到几秒级。这就让”扫一遍千亿向量”在工程上变成可行。

2.4 三件套的总效果

维度原始PCA + RabitQ + SIMD
单向量768 × float32 = 3 KB64 bits = 8 B
千亿向量~300 TB~3 TB（降 99%+）
单次距离计算~3000 次浮点乘加popcount on 64 bits（一条 SIMD 指令）
召回质量（粗排）N/Arecall@1000 ~0.85

⭐ 关键观察：粗排 recall@1000 ≈ 0.85——这意味着真实最近的 10 个邻居有 ~85% 概率落在粗排返回的 top-1000 里。剩下的 15% 缺口由 Phase 2 精排弥补。

3. 混合介质的数据流：UB 池 + SSD 双层

3.1 介质分工

把整个检索系统的数据按介质分层：

介质存什么大小访问延迟
DRAM（CPU 上）PCA 投影矩阵、RabitQ 旋转矩阵、查询缓冲~MB 级< 100 ns
UB 内存池量化后的紧凑索引（1bit 向量）+ HNSW 图~3 TB~1-3 µs
SSD（NVMe）原始 float32 向量 + 元数据~300 TB~80 µs

3.2 完整查询流程

让我们走一次完整查询：

Step 1: Query 进来 (768 维 float32)
    │
    ▼
Step 2: PCA 投影到 64 维 + RabitQ 量化（DRAM 上）
    │     latency: ~5 µs
    ▼
Step 3: HNSW 图查询（在 UB 池）
    │     - 跳数约 50-100 跳
    │     - 每跳读 1 bit 邻居 + popcount 距离
    │     - latency: ~50-100 µs
    │     - 输出: top-1000 候选
    ▼
Step 4: 精排（回 SSD）
    │     - 读 top-1000 候选的原始 float32 向量
    │     - 1000 × 80 µs = 80 ms 单线程，并发后 ~5-10 ms
    │     - 用真实距离 rerank 出 top-10
    ▼
Step 5: 返回 top-10
    │     总延迟 P50: ~10-15 ms
    │     总延迟 P99: ~30-50 ms

3.3 关键工程细节：精排的 IO 模式

第 4 步的精排访问 1000 个原始向量——这件事如果做错就直接拉爆延迟。鲲鹏路线 3 的几个关键点：

  • 预取（prefetch）：粗排返回 top-1000 时立即异步发起 SSD 预取，不等粗排结束才请求
  • 批量读：1000 个候选的 SSD 请求合成一个批次，让 NVMe 的并发优势发挥
  • 结果跨磁盘并发：1000 个候选可能分布在多个 SSD 上，并发到所有可用通道

这套机制把 Phase 2 的实际延迟从单线程 80 ms 砍到 ~5-10 ms。

4. 二阶段精排：把召回从 0.85 拉到 0.96

4.1 为什么需要精排

粗排的量化误差是不可避免的——float32 → 1bit 一定会丢信息。结果是：

  • 粗排 top-10 的召回（recall@10）只有 ~0.70-0.80
  • 粗排 top-1000 的召回（recall@1000）能到 ~0.85-0.90
  • 真正最近的 10 个邻居通常在 top-1000 里——但相对位置乱了

精排做的事：在 top-1000 里用原始 float32 向量重新排一次，挑出真实的 top-10。

4.2 二阶段精排的召回数字

阶段输出召回延迟（典型千亿）
Phase 1 (粗排)top-1000recall@1000 ~0.85-0.9050-100 µs
Phase 2 (精排)top-10recall@10 ~0.95-0.965-10 ms

最终 recall@10 = recall@1000 × (top-10 in 1000 found) ≈ 0.85 × 0.99 ≈ 0.84 看起来似乎不够好——但这是悲观估算。实际上 top-1000 里真正前 10 名向量的位置都被精排重排到了正确顺序——所以最终 recall@10 接近 0.95。

4.3 精排的关键参数：top-K candidate count

二阶段精排的核心调参是 “粗排返回多少候选给精排”：

top-K candidaterecall@10Phase 2 延迟
1000.83~1 ms
5000.92~3 ms
10000.96~5-10 ms
50000.98~25 ms
100000.99~50 ms

🍎 直觉比喻：粗排好比”筛选简历到面试 1000 人”，精排好比”在 1000 人里仔细面试选 10 人”——筛选范围越大，最终选出来的越接近最优，但成本也越高。

4.4 工程上 top-K 的选择经验

  • 风控 / 召回必须接近完美：top-K = 5000-10000，recall ~0.98-0.99
  • 客服 / 长记忆陪聊：top-K = 500-1000，recall ~0.92-0.96
  • 粗放推荐 / 探索性搜索：top-K = 100-500，recall ~0.83-0.92

5. 与 Ch5 全局整图路线的精确互补

5.1 两条路线的本质差异

维度Ch5 全局整图（路线 2）Ch6 超低内存（路线 3）
核心思路”砸钱换召回 + P99""压内存换成本”
内存需求~300 TB（UB 池）~3 TB（UB 池）
SSD 需求仅元数据~300 TB（原始向量）
Phase 数1（直接整图查询）2（粗排 + 精排）
recall@100.96+0.96+
P50 延迟1.5-2 ms10-15 ms
P99 延迟5-10 ms30-50 ms
介质年成本（粗估）~120K USD~30-50K USD

⭐ 关键观察：两条路线在召回质量上等价——但在延迟和成本上做了完全不同的取舍。

5.2 选哪条路线？三类业务场景的判定

场景 1：金融风控、安全监控

  • 要求：P99 < 50ms 是硬性要求
  • 预算：相对宽裕
  • 路线选择：Ch5 路线 2——P99 5-10ms 才能稳定满足业务

场景 2：客服对话、长记忆陪聊

  • 要求：P99 < 200ms 即可
  • 预算：成本敏感
  • 路线选择：Ch6 路线 3——P99 30-50ms 满足要求，介质成本节省 60-75%

场景 3：BI 分析、内容推荐

  • 要求：P99 < 1s
  • 预算：根据业务规模
  • 路线选择：两条都可以，路线 3 更划算

5.3 一种混合策略：路线 2 + 路线 3 共存

实际生产里，最优策略往往是两条路线共存：

  • 热数据（最近 30 天访问 / 高优先级用户）→ 走路线 2（全局整图，P99 5ms）
  • 冷数据（90 天前 / 低优先级）→ 走路线 3（粗精排两阶段，P99 30ms）
  • 用户透明：上层 Harness 根据数据热度路由查询

这套混合策略让总成本逼近路线 3，又让关键查询拿到路线 2 的延迟——是工程上”在两个极端中间找平衡”的经典模式。

6. 工程取舍清单：什么时候选路线 2 vs 路线 3

把上面的对照浓缩成一份”决策 checklist”：

6.1 选路线 2（Ch5 全局整图）的信号

  • ✅ 业务有明确 P99 < 50ms 硬性要求（风控、HFT、安全）
  • ✅ 千亿规模或更大
  • ✅ 预算可承受 100K+ USD / 年
  • ✅ 召回质量必须 ≥ 0.95
  • ✅ 数据增量更新频繁——HNSW 整图增量比量化体系更友好
  • ✅ 团队有强工程能力维护新硬件栈

6.2 选路线 3（Ch6 超低内存）的信号

  • ✅ P99 200ms 内可接受
  • ✅ 成本压力是第一约束（中型公司、垂直应用）
  • ✅ 数据相对稳定（每天 / 每周批量更新）
  • ✅ 召回质量可以接受 0.92-0.96
  • ✅ 已有 SSD 基础设施可复用

6.3 两条都不选的信号

如果你的业务规模在亿级以下——直接用 HNSW 整图（单机内存）或 DiskANN（单机 SSD）就够了。鲲鹏路线 2 / 3 的工程复杂度只在千亿规模才能摊销开。

🌟 核心判断：鲲鹏路线 2 和路线 3 不是替代关系，是”同一个底座（UB）下的两种工程哲学”——一种偏向”召回 + 延迟”，一种偏向”成本 + 灵活”。理想生产系统会把两者混合部署。

🎯 自我检验清单

  • PCA + RabitQ + SIMD 三件套各自的核心机制是什么？为什么把它们叠在一起的总压缩比能到 384x？
  • 粗排 recall@1000 ~0.85 是什么意思？精排怎么把最终 recall@10 拉到 0.96？
  • 解释二阶段精排里”top-K candidate count”调参的取舍——为什么不直接选 top-K = 10000？
  • 鲲鹏路线 2 和路线 3 在内存 / 延迟 / 成本上的核心区别是什么？什么业务场景下分别更合适？
  • 设计一个”混合策略”：怎么在同一系统里同时使用两条路线？它的工程复杂度增量在哪？

📚 参考资料

  • RabitQ（VLDB 2024）—— 旋转 + 二值化量化算法基础
  • PCA / Principal Component Analysis —— 经典降维方法
  • DiskANN（Microsoft NeurIPS 2019）—— 二阶段精排架构原型
  • AlayaDB（2024-2025）—— 量化检索产品化
  • Intel SIMD Programming Guide（2024）—— SIMD 编程基础
  • 鲲鹏 Agent Memory 创新方案（华为鲲鹏团队 2026 公开发表）—— 路线 3 详细技术披露
  • 本系列模块十四 第 5 章：向量索引的层次化设计
  • 本系列模块十六 第 5 章：UB 全局向量检索

下一章预告：Ch7 把鲲鹏路线 1/2/3 三件套拉出来，和我们项目第一/二模块（LMObject 统一抽象 + 分离式资源池化）做精确对照——指出哪些是直接互补、哪些是重叠、哪些是项目能在鲲鹏路线之上做差异化创新的工程腹地。