第5章：向量索引的层次化设计
DiskANN / SPANN / FreshDiskANN / Filtered DiskANN / AlayaDB 五大代表方案 + 图索引 vs 聚类索引的访存差异 + 长记忆向量库的特殊设计准则
向量索引是长记忆系统的”第二战场”——它不像 KV Cache 那样高频(每个 token 都要扫),但每次访问的 IO 放大系数往往是 KV 的 10× 以上。一次”找出与当前问题最相似的 100 条历史记忆”看似一行代码,在存储侧可能触发几百次 SSD random IO——这是为什么传统纯 RAM 向量库到了 TB 级就跑不动、纯 SSD 方案又召回延迟爆炸。本章把过去六年(2019-2025)向量索引层次化设计的代表方案放在一起精读:DiskANN(图索引 SSD 奠基)、SPANN(聚类索引层次化)、FreshDiskANN(流式更新)、Filtered DiskANN(带过滤)、AlayaDB(LLM-aware)。读完这章你能回答两个问题:给定一份 Agent 长记忆库,该选图索引还是聚类索引?哪些维度上现有系统都没解? 这正是项目第一模块在向量侧的研究腹地。
📑 目录
- 1. 长记忆系统里向量索引的”四个不一样”
- 2. 主流 ANN 的两条主路径
- 3. DiskANN:图索引 SSD 化的奠基之作
- 4. SPANN:聚类索引的层次化代表
- 5. FreshDiskANN:流式更新
- 6. Filtered DiskANN:带 metadata 过滤
- 7. AlayaDB:LLM-aware 长上下文向量库
- 8. 横向能力矩阵
- 9. 长记忆向量索引的设计准则
- 10. 给本项目的整合启示
- 自我检验清单
- 参考资料
1. 长记忆系统里向量索引的”四个不一样”
通用向量库(Milvus / FAISS / Qdrant)和长记忆系统里的向量库,看着是同一个东西,工程约束完全不一样:
| 维度 | 通用向量库 | 长记忆向量库 |
|---|---|---|
| 写入模式 | 批量构建为主,偶尔追加 | 流式持续追加(Agent 一直在产生新记忆) |
| 查询触发 | 用户点搜索按钮 | LLM attention 内部触发,每个 token 都可能调 |
| 延迟约束 | P99 几十-几百 ms 可接受 | P99 必须 < 几十 ms(否则破坏 token 生成节奏) |
| 过滤需求 | 偶尔 metadata 过滤 | 每次都带 user_id / 时间窗 / 任务标签过滤 |
| 数据特性 | 单模态 embedding | 文本 + 图像 + 音频 embedding 共存 |
🌟 核心判断:长记忆向量库 = 流式 + 低延迟 + 强过滤 + 多模态混存——四个维度同时收紧,通用向量库的设计被四面挤压。
🍎 直觉比喻:通用向量库像图书馆——人类一天来几次,提前编好目录够用;长记忆向量库像车载导航——你每秒钟问它一次”附近最近的咖啡店”,还要带条件”评分 4.5 以上、当前营业、有充电桩”——访问频率、延迟、过滤一起爆炸。
2. 主流 ANN 的两条主路径
近似最近邻(ANN)算法过去十年走出两条主流:
2.1 图索引路径:HNSW / NSG / Vamana
每个向量是图的一个节点,与”近邻”建边。查询时从入口点出发,沿边爬山搜索直到收敛。
入口点
│
▼
邻居列表 → 选距离最近的几个 → 展开它们的邻居 → 再选 ……
│
▼
收敛 / top-k
| 优点 | 缺点 |
|---|---|
| 召回率高,可调 | 内存开销大(每节点要存邻居表) |
| 查询路径短(对数级跳数) | 写入难(增量加点要更新很多邻居) |
| 算法成熟 | 大规模时邻居表本身放不下内存 |
代表:HNSW(Hierarchical Navigable Small World, TPAMI 2018)、NSG(Navigating Spreading-out Graph)、Vamana(DiskANN 用)。
2.2 聚类索引路径:IVF / SPANN
把向量预先聚成簇(K-means 或类似),查询时:
- 找最相关的 N 个簇(粗筛)
- 只在这 N 个簇内扫描(精排)
query
│
▼
簇中心比较 → top-N 簇
│
▼
簇内逐一比较 → top-k
| 优点 | 缺点 |
|---|---|
| 内存只放簇中心,主体可放磁盘 | 召回率天然有损(漏簇就漏数据) |
| 写入相对友好 | 簇划分质量决定一切 |
| 大粒度顺序读,SSD 友好 | 边界附近向量的召回不稳定 |
代表:IVF(Inverted File, FAISS)、SPANN(NeurIPS 2021, Microsoft)、ScaNN(Google ICML 2020,加量化)。
2.3 第三条路:量化作为辅助
不是独立索引,但几乎所有 SSD 方案都用:
- PQ(Product Quantization, TPAMI 2011) — 把高维向量切段独立量化,大幅压缩
- OPQ / Residual Quantization — PQ 的改进
- Binary Quantization — 极端二值化
🧠 关键作用:量化让”全量向量副本”能塞进 RAM 做粗筛,真正的精确比较再去 SSD——这是 DiskANN / SPANN 的共同套路。
2.4 两条路径的存储倾向
| 路径 | 内存友好度 | SSD 友好度 | 写入友好度 | 召回稳定性 |
|---|---|---|---|---|
| 图索引(HNSW) | 中(邻居表大) | 差(随机 IO 极重) | 差 | 高 |
| 图索引(Vamana / DiskANN) | 高(只放 PQ) | 中(单层图 SSD 友好) | 中 | 高 |
| 聚类索引(IVF / SPANN) | 高 | 高(大粒度顺序读) | 中-高 | 中 |
📍 第一道决策:如果向量库以”近实时写 + 大规模 SSD 主存”为目标,聚类路径或 Vamana 路径优于经典 HNSW。
3. DiskANN:图索引 SSD 化的奠基之作
3.1 一句话精髓
把图索引(类似 HNSW)的”邻居表”放在 SSD,只在 RAM 里保留极小的 PQ 压缩副本做粗筛,实现单机十亿向量 ANN——证明了”向量索引完全可以驻留 SSD”。
3.2 出处与定位
- 论文:DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node
- 出处:NeurIPS 2019(Microsoft Research)
- 后续:FreshDiskANN(2021,流式更新)、Filtered DiskANN(SIGMOD 2024,带过滤)
- 影响:Microsoft 内部产品(Bing 等)采用,后开源
3.3 关键设计
| 维度 | 内容 |
|---|---|
| 图算法 | 自创 Vamana —— 一种比 HNSW 更适合磁盘访问的单层图,搜索路径更短 |
| RAM 上的导航表 | 全量向量做 PQ(几倍-十倍压缩)放 RAM,用于快速过滤候选 |
| SSD 上的主体 | 完整向量(fp32/fp16)+ 邻居表 |
| 批量异步 IO | 一次 search 的多次 SSD 读用 io_uring/libaio 并发 |
| 构建侧 | 用 RAM 构建子图后合并,避免一次性把全图放内存 |
RAM:
┌─────────────────────────────────────┐
│ PQ-compressed 向量(全量,~10× 压缩)│
│ 入口点 │
└─────────────────────────────────────┘
│ 用 PQ 距离粗筛候选
▼
SSD:
┌─────────────────────────────────────┐
│ 完整向量(fp16/fp32) │
│ Adjacency list(邻居表) │
└─────────────────────────────────────┘
│ 异步并发读真实邻居
▼
精确距离 → 更新候选堆 → 收敛返回 top-k
3.4 关键收益(论文公开)
- 单机十亿规模,95%+ 召回 @ ms 级延迟(NVMe + 较大内存配置下)
- RAM 占用从”数百 GB”降到 几十 GB 量级
- Recall vs latency 曲线在 SSD 方案里长期是 SOTA
3.5 局限
- 更新友好性差——原版只支持批量重建,FreshDiskANN 才补了流式更新
- 单查询延迟对 SSD random IO 敏感,P99 抖动比纯内存大
- 不考虑带过滤(metadata filter) 的查询(后续 Filtered DiskANN 才补)
- 多模态/异构数据没原生支持(只有向量)
3.6 给本项目的启示
🌟 向量索引层级化的标杆——证明了”向量库不必塞 RAM”。本项目要做的扩展:
- 三级化:DiskANN 是 RAM-SSD 二级,我们要 HBM-DRAM-SSD 三级——HBM 放最热的几百万向量(GPU 可加速距离计算),DRAM 放 PQ 副本,SSD 放完整
- 与 KV / 多模态共享存储池:DiskANN 假设独占 SSD,生产环境向量库要和 KV Cache、原始 blob 共住——调度器要平衡几路 IO
- 过滤 + 长记忆:Filtered DiskANN 已经做了”带 metadata 过滤的 ANN”,我们要做”按 user_id / 时间窗”的 Agent 级过滤
- 流式更新:FreshDiskANN 思想对路,但 Agent 长记忆的写入频率可能比它的假设还高
4. SPANN:聚类索引的层次化代表
4.1 一句话精髓
不靠图,而是把向量聚成大量小簇,簇心放内存、簇内向量放 SSD——查询先找簇,再在簇里扫,SSD 顺序读友好。
4.2 出处与定位
- 论文:SPANN: Highly-efficient Billion-scale Approximate Nearest Neighbor Search
- 出处:NeurIPS 2021(Microsoft Research)
- 关键创新:层次化平衡聚类 + 副本机制(同一向量可被多个簇拥有,提高边界召回)
4.3 关键设计
| 维度 | 内容 |
|---|---|
| 聚类策略 | 多级 K-means + 平衡控制(避免簇过大/过小) |
| 副本机制 | 边界向量被多个簇拥有(几倍存储换召回) |
| 内存只放簇心 | 极小,通常 GB 级 |
| SSD 上的主体 | 每簇内向量按簇号顺序存放 |
| 查询流程 | RAM 簇心比距 → top-N 簇 → SSD 顺序读簇 → 簇内精排 |
RAM: SSD:
┌────────────────┐ ┌──────────────────┐
│ 簇心 1, 2, ...K│ ─── top-N ──> │ 簇 1: [v_a, v_b…]│
└────────────────┘ │ 簇 2: [v_c, v_d…]│
│ …… │
│ 簇 K: [v_y, v_z…]│
└──────────────────┘
顺序读最相关的几个簇
4.4 关键收益
- 在十亿规模上,与 DiskANN 相当或更好的召回-延迟权衡
- SSD IO 模式更友好(顺序大块读 vs DiskANN 的随机邻居读)
- 内存占用更小(只放簇心)
4.5 局限
- 副本带来存储放大(2-5× 不等)
- 写入仍然麻烦——加点要决定它属于哪些簇,可能要重新平衡
- 过滤场景支持有限
- 极端长尾簇(某簇特别大)会拖累查询
4.6 给本项目的启示
🌟 聚类索引是”SSD 顺序读 + 大粒度”的好朋友——长记忆系统里:
- 多模态向量更适合聚类(图像 / 音频 embedding 簇结构往往更清晰)
- 冷热分级天然适合簇粒度:整簇热 → 升 DRAM,整簇冷 → 留 SSD
- 副本开销和容错(第三模块)有交叉——副本既提升召回又能容错
📍 决策启发:本项目的”图 vs 聚类”选择不是二选一,而是分类型用——KV-similar 的 prefix 用图索引(高召回),冷历史多模态用聚类(SSD 友好)。
5. FreshDiskANN:流式更新
5.1 一句话精髓
给 DiskANN 加一个”内存里的小图 + 周期性合并”机制,让它能边查边写,而不是只支持批量重建。
5.2 解决的问题
DiskANN 原版只支持批量构建——但 Agent 长记忆库每秒钟都在新增向量。如果每次重建,几十 TB 的索引几小时才能完成,期间新数据不可查。
5.3 关键设计
| 维度 | 内容 |
|---|---|
| 双层结构 | RAM 里维护一个”小 Vamana 图”接收新点 + SSD 上的”主图” |
| 查询合并 | 每次查询同时扫两层,结果合并 |
| 后台 merge | 小图增长到阈值时,后台合并进主图(类似 LSM-tree) |
| 删除 | 用墓碑标记 + 合并时清理 |
写入:
new vector → RAM 小图(可立即被查到)
│
│ 累积到阈值
▼
后台 merge 进 SSD 主图
(期间查询继续 working,新主图 ready 后切换)
查询:
query → RAM 小图查 + SSD 主图查 → 合并 top-k
5.4 给本项目的启示
🌟 流式更新 = LSM 思想搬到向量索引——但有几点本项目要重新考虑:
- Agent 写入频率可能远高于 FreshDiskANN 假设 —— 内存小图阈值要重新设计
- 多类型混合:KV 写、向量写、scratchpad 写共用同一组 SSD 通道,写放大要协同管理
- 冷热演化(Ch10):FreshDiskANN 的”merge”思路可以泛化为”层级间数据演化”
6. Filtered DiskANN:带 metadata 过滤
6.1 一句话精髓
把 metadata 过滤(
tag = X/time > T)从”查完再过滤”升级到”查时就过滤”,避免大量无效的距离计算。
6.2 解决的问题
通用向量库的过滤常见做法:先 ANN 找 top-1000,再 filter 选符合条件的 top-10——但如果过滤条件严苛(如”只看本用户”),top-1000 里可能只有几条满足,召回严重不足。
Filtered DiskANN 的视角:让索引图本身知道过滤条件,搜索时跳过不满足的节点。
6.3 关键设计
| 维度 | 内容 |
|---|---|
| 属性绑定 | 每个图节点绑定 metadata 标签 |
| 过滤感知遍历 | 搜索时只展开符合 filter 的邻居 |
| 专属图(可选) | 高频过滤条件可建专属子图 |
6.4 给本项目的启示
🌟 长记忆系统的”按用户 / 时间 / 任务”过滤是必备——通用向量库这块支持差,Filtered DiskANN 是直接可借鉴方案:
- 多租户隔离:user_id 过滤是基础,可推广到企业内部权限
- 时间窗查询:Agent 经常查”最近 7 天的相似记忆”——索引层支持比应用层后过滤高效
- 任务标签:Agent 不同任务类型的记忆可标 tag,查询时定向召回
7. AlayaDB:LLM-aware 长上下文向量库
7.1 一句话精髓
不是把传统向量库接到 LLM 后面,而是从 attention 算子的视角重新设计向量库——让”检索”和”注意”成为同一件事。
7.2 出处与定位
- 项目:AlayaDB(HKUST,2025)
- 关键词:LLM-native vector DB、attention-driven retrieval、long context、agent memory store
⚠️ 本系统较新,本节基于公开预印本/项目页二次资料整理,精确数字以原文为准。
7.3 解决的问题
把”长上下文”塞 prompt 太贵,把外部记忆”RAG 出来再拼回 prompt”又粗糙。AlayaDB 要做的是:
- 让 LLM 在生成的每一步都能从外部记忆库精确”召回”少数 token
- 召回不再是”先检索 → 再 cross-encoder rerank → 再拼 prompt”两阶段,而是直接和 attention 融合
- 长记忆库本身的存储 / 索引 / 调度针对 LLM 访问模式优化
7.4 关键设计要点(整合自公开资料)
| 维度 | 内容 |
|---|---|
| LLM 原生检索算子 | 不走 cosine top-k → rerank 的二阶段,直接给 attention 提供候选 |
| 多层级存储 | 热向量 / 冷向量 / 原始 token 各自分级 |
| attention 稀疏性引导 | 只把 attention 真正会用到的 token 拉进 KV |
| agent 友好接口 | 写入 / 更新 / 召回的语义对接 agent 的 episodic / semantic 记忆 |
┌─────────────────────────────────────┐
│ LLM Decoder(生成第 t 个 token) │
└────────────┬─────────────────────────┘
│ attention 候选请求
▼
┌─────────────────────────────────────┐
│ AlayaDB 检索算子 │
│ (替代/补充传统 attention 的 KV) │
└────────────┬─────────────────────────┘
│
┌─────────┼─────────┬───────────┐
▼ ▼ ▼ ▼
HBM DRAM SSD (远端)
(hot KV) (warm vec)(cold vec) (跨节点)
7.5 局限
- 系统级新概念,生态成熟度远不如 FAISS / Milvus / DiskANN
- “attention 算子级集成”对模型代码侵入大,落地需要框架协同
- 学术 prototype 阶段,工业部署经验有限
- 多模态、跨语言场景的数据组织还不清晰
7.6 给本项目的启示
🌟 第一模块”统一抽象”路线最值得对标的近期工作——AlayaDB 已经在做”向量索引和 LLM 推理同构”。我们的差异化:
- 把 KV cache 和向量索引放进同一个抽象:AlayaDB 偏向量,我们让 KV 块也成为这个抽象的成员
- 多模态扩展:AlayaDB 主攻文本向量,我们把图像 / 音频 + 原始 blob 也纳入
- token 单位成本:AlayaDB 优化召回质量,我们更进一步给”每 token 召回成本”建模
- 生产场景适配:AlayaDB 偏研究原型,我们对接生产场景的容量 / 延迟 / 可靠性 SLA
- 协作而非竞争:AlayaDB 可以作为”向量召回算子”的现成组件,被纳入我们的统一调度器
8. 横向能力矩阵
把五个方案 + Faiss 基线在 8 个维度上对比:
| 能力 | FAISS HNSW(基线) | DiskANN | SPANN | FreshDiskANN | Filtered DiskANN | AlayaDB | 本项目目标 |
|---|---|---|---|---|---|---|---|
| 主索引位置 | RAM | SSD(主体) | SSD(簇内) | SSD + RAM 增量 | SSD | 多级 | HBM/DRAM/SSD 三级 |
| 十亿规模 | 困难(全量 RAM) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 流式更新 | 弱 | ❌ | 中 | ✅ | ❌ | ✅ | ✅ |
| metadata 过滤 | 后过滤 | ❌ | 弱 | ❌ | ✅ | 中 | ✅(强类型) |
| LLM-aware | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅(attention 融合) |
| 多模态 | 各自独立 | ❌ | ❌ | ❌ | ❌ | 主文本 | ✅ |
| 跨层级冷热 | ❌ | RAM-SSD | RAM-SSD | RAM-SSD | RAM-SSD | 部分 | ✅ HBM/DRAM/SSD |
| 与 KV / blob 同源管理 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ⭐ 核心增量 |
🌟 观察一:没有任何一个向量索引系统把”与 KV、多模态 blob 同源管理”做出来——所有方案都假设”向量库独占 SSD”。
🌟 观察二:HBM 这一级几乎没人用——所有方案都只到 RAM-SSD 两级,GPU 加速 ANN 还是研究热点(Faiss-GPU、CAGRA 等)。
🌟 观察三:LLM-aware 是 2025 才出现的方向(AlayaDB)——把 attention 和检索融合,这条路径学术界还很初步。
9. 长记忆向量索引的设计准则
把上面五个方案的经验浓缩成八条设计准则,直接可用:
9.1 准则 1:RAM 必有 PQ-compressed 全量副本
无论选图还是聚类,RAM 上一定要有全量向量的压缩副本(PQ 或类似)用于粗筛——SSD 随机 IO 太慢,不能让查询的每一步都打 SSD。
9.2 准则 2:聚类索引天然适合”大粒度跨层级演化”
簇是天然的迁移单元——整簇升 DRAM、整簇降 SSD。图索引的迁移粒度更难定义(单节点 / 子图)。
9.3 准则 3:metadata 过滤要进索引,不要后过滤
后过滤在严苛 filter 下召回崩溃。Filtered DiskANN 思路必须支持。
9.4 准则 4:写入流式 + 后台 merge
不要重建——FreshDiskANN 的 LSM 思路是长记忆唯一可行方案。
9.5 准则 5:HBM 上做 GPU-accelerated ANN
最热的几百万向量(典型 user × 个人记忆)放 HBM,用 GPU kernel 做距离计算——延迟可压到 ms 以下。
9.6 准则 6:多模态向量分模态索引
文本 / 图像 / 音频 embedding 维度不同、距离度量不同(cosine / dot / L2),应该建多个独立索引 + 元数据关联,不是塞一个大索引。
9.7 准则 7:与 KV / blob 共享 metadata 层
向量召回回来的”对象 ID”必须能直接找到对应 KV(如有)或 blob(如有)——统一 metadata 层是统一抽象的入口(Ch8 主题)。
9.8 准则 8:索引建好后留 cost monitor
每个查询的 IO 次数、SSD 命中率、过滤通过率等指标必须长期采集——这是 Ch11 token 成本建模的输入。
10. 给本项目的整合启示
10.1 已有可复用武器
| 武器 | 来源 | 用在哪 |
|---|---|---|
| Vamana 单层图 + PQ 副本 | DiskANN | SSD 主索引底座 |
| 平衡聚类 + 簇副本 | SPANN | 大粒度顺序 IO |
| 流式 LSM 合并 | FreshDiskANN | Agent 高频写入 |
| 过滤感知遍历 | Filtered DiskANN | 多租户 / 时间窗过滤 |
| LLM 算子级集成思路 | AlayaDB | 长上下文场景 |
10.2 还缺的拼图
| 缺口 | 内容 | 难度 |
|---|---|---|
| ⭐⭐⭐ HBM 上的 GPU-ANN | 最热向量在 HBM 用 Tensor Core 算距离 | 中-高(工程) |
| ⭐⭐⭐ KV / 向量 / blob 同源 metadata | 统一 ID 空间,跨类型互相引用 | 高(科学问题腹地) |
| ⭐⭐ 多模态分模态独立索引 | 各模态 embedding + 跨模态联合检索 | 中 |
| ⭐⭐ 跨层级演化协同 KV | 同一用户的 KV 升 HBM 时,Ta 的向量索引也跟着升 | 中-高 |
| ⭐⭐ 强 metadata 过滤 | 用户/时间/任务多维过滤的索引层支持 | 中 |
| ⭐ 冷簇压缩归档 | 长期不查的簇做激进压缩 + 归档到对象存储 | 低-中 |
10.3 选型决策矩阵(给项目示范系统直接用)
| 场景 | 推荐方案 |
|---|---|
| 高频 Agent 个人长记忆(GB 级) | HBM/DRAM 上的 HNSW 或 GPU-ANN |
| 中频用户级记忆(GB-TB) | DRAM-SSD 上的 SPANN 或 DiskANN |
| 低频企业级知识库(TB+) | SPANN(SSD 友好) + 冷归档 |
| 多模态混合 | 各模态 SPANN + 联合 metadata |
| 长记忆 + 实时推理融合 | AlayaDB-style 算子级集成 |
🌟 关键洞察:长记忆系统不是选一种向量索引,是组合用——不同热度、不同类型的向量,选不同的索引方案,通过统一 metadata 层串成一个逻辑库。这正是 Ch8 要给的”统一表示”。
✅ 自我检验清单
- 四个不一样:能用一句话讲清长记忆向量库与通用向量库的核心差别
- 图 vs 聚类:能对比两条主路径在内存、SSD、写入、召回稳定性上的差异
- 量化的作用:能解释 PQ 在 DiskANN / SPANN 中扮演什么角色
- DiskANN 三件套:RAM PQ + Vamana + 异步 IO
- SPANN 副本机制:能解释”边界向量被多簇拥有”为什么提升召回
- FreshDiskANN LSM 类比:能讲清”内存小图 + 后台 merge”的逻辑
- Filtered DiskANN 与”先 ANN 后过滤”对比:能解释严苛过滤场景的召回崩溃问题
- AlayaDB 算子级集成:能讲清和传统”RAG 后接 LLM”的差异
- 能力矩阵两列空白:能复述”与 KV/blob 同源管理”和”HBM-DRAM-SSD 三级”全空的事实
- 8 条设计准则:能默写至少 6 条,各举一个具体应用场景
📚 参考资料
五大方案
- DiskANN(NeurIPS’19, Microsoft) —— Vamana 图 + PQ 副本
- SPANN(NeurIPS’21, Microsoft) —— 平衡聚类 + 副本
- FreshDiskANN(arXiv 2105.09613, 2021) —— 流式更新版
- Filtered DiskANN(SIGMOD’24) —— 带 metadata 过滤
- AlayaDB(HKUST, 2025) —— LLM-aware 长上下文向量库
经典 ANN 算法
- HNSW(Malkov & Yashunin, TPAMI 2018) —— 主流图索引
- NSG(Fu et al., 2019) —— 图索引另一变种
- PQ(Jégou et al., TPAMI 2011) —— 量化奠基
- OPQ(Ge et al., TPAMI 2014) —— PQ 改进
- ScaNN(Google ICML 2020) —— 量化感知 ANN
工业级实现
- FAISS:github.com/facebookresearch/faiss
- Milvus:milvus.io
- Qdrant:qdrant.tech
- Weaviate:weaviate.io
- LanceDB:lancedb.com —— 多模态友好
- CAGRA(NVIDIA RAPIDS) —— GPU-ANN
综述
- A Survey on Vector Database Management Systems(2024)
- A Comprehensive Survey on Vector Database(arXiv 2310.11703)
调研笔记
本系列其它模块
- 模块五 Agent Memory —— 上层 Agent 记忆框架(Mem0 / Letta / A-MEM)
- 本模块第2章 多类型数据访问规律 —— 向量索引的访问指纹
- [本模块第3章 三级存储基础](./第3章-三级存储基础与延迟带宽cheat sheet.md) —— 各级介质 IO 物理上限