cat README.md
alibaba/zvec
我之前自己做 Agent 的时候，写过 RAG 模块。第一版用 Chroma，第二版换 Milvus，第三版跑 FAISS，每次换都觉得自己在造轮子——直到这周我看到阿里把 Proxima 这个跑了 6 年的向量引擎开源出来，我承认我有点恍惚。本地 AI 应用这几年最别扭的事，终于有人补上了。
// 目录
// 概览
我之前自己做 Agent 的时候，写过 RAG 模块。第一版用 Chroma，第二版换 Milvus，第三版跑 FAISS，每次换都觉得自己在造轮子——直到这周我看到阿里把 Zvec 这个"进程内向量数据库"丢出来，我承认我有点恍惚。
因为我突然意识到：本地 AI 应用开发这几年，最别扭的一件事就是——我们要么在用客户端-服务器架构的数据库（Milvus/Qdrant），要么在用纯算法库（FAISS/hnswlib），中间缺一档"像 SQLite 一样嵌进应用"的东西。而 Zvec 直接把这一档给填了。
不多说废话，先看几个我特别在意的点。
我的真实问题：本地 RAG 跑不动，到底是哪里卡了？
我先说我自己遇到的几个真实场景。
去年做一个本地 AI 助手，需求很朴素：笔记本跑 50 万条以内的笔记做语义搜索。我先试 Chroma，UI 友好，但 50 万条下来内存吃 8GB+，笔记本风扇开始狂转；后来换 Milvus Lite，本地单进程版，结果要拉一堆 gRPC 依赖，光部署文档我就看了一晚上；最后用 FAISS 凑合——但 FAISS 是「算法库」不是「数据库」，CRUD 全得自己造，崩溃恢复、数据持久化、schema 演进这些都要从头写。
我那时候就在想：如果有谁能把 SQLite 那一套范式搬到向量世界里该多好——嵌进进程里跑，不用拉服务，不用装 Docker，文件往那一放就能用。
Zvec 6 月 12 日发了 v0.5.0，把"DiskANN 索引"加进去了，意味着它真的能"在笔记本上跑十亿向量"了——这是一个信号：进程内向量数据库这个赛道，开始真正成熟。
这玩意儿到底是什么？为什么说它是"向量数据库界的 SQLite"？
Zvec 是阿里达摩院出品的开源项目（GitHub alibaba/zvec），底层引擎叫 Proxima——这是阿里内部跑了多年的向量检索引擎，淘宝商品搜索、天猫推荐都用它。
最关键的定位是这句话：进程内（in-process）数据库。它不是客户端-服务器架构（不是 Milvus/Qdrant），也不是纯算法库（不是 FAISS），而是把整个数据库引擎做成一个链接到你的应用进程里的库。
类比一下：如果你写 Python 写 C++，你要本地存数据，最省事的是 import sqlite3，开箱即用，零部署。Zvec 想做的事一模一样——import zvec，三行代码就能跑起来。
就这样，没了。
它的核心能力清单我帮你理一下：
稠密+稀疏向量混合检索：单条 MultiQuery 把向量相似度、全文搜索（FTS）、标量过滤一次性搞定。
DiskANN 索引（v0.5.0 新增）：十亿向量也能塞进笔记本。
WAL 预写日志：进程崩了、断电了，数据不丢。
多语言 SDK：Python、Node.js、Go、Rust、Dart/Flutter。
跨平台：Linux、macOS、Windows、RISC-V。
资源控制：硬性 memory_limit_mb、内存映射 enable_mmap、线程数 optimize_threads。
Apache-2.0 协议：商用无门槛。
光看这一条"支持 RISC-V"我就想给它加个鸡腿——这意味着物联网设备、边缘网关、嵌入式 AI 盒子都能跑。
性能到底怎样？我看了官方 benchmark 之后的判断
我先说我看到的官方数据（VectorDBBench + Cohere 10M 公开测试集，g9i.4xlarge / 16 vCPU / 64 GiB 内存 / Ubuntu 24.04）：
QPS：8000+ queries/second，Cohere 10M 上比上一代 leaderboard 冠军 ZillizCloud 2 倍以上。
Index Build Time：构建速度也快——10M 768 维向量的索引构建时间明显短于 Milvus。
Cohere 1M：1M 规模下性能优势依然成立。
可复现：官方把测试命令、参数、实例规格全部公开，没有黑箱。
我自己的判断是：在「单进程/单节点」这个赛道里，Zvec 几乎没有对手。因为：
FAISS 是算法库，你拿到的是一堆 IndexFlatL2、IndexIVFFlat 这些裸类，没有 schema、没有持久化、没有 CRUD、没有全文检索；
Chroma 是嵌进程的，但 Python 化太重，依赖 numpy，HNSW 索引无 SIMD 加速；
hnswlib 是 HNSW 专用算法库，没有持久化；
Milvus Lite 是嵌进程版 Milvus，但保留了 gRPC 风格 API，跟 SQLite 的"零摩擦"差距很远。
Zvec 走的是一条「我帮你做完整数据库，但我不抢你的进程」的中间路线——这个定位非常精准。
但我要提醒一句：Zvec 不适合大规模分布式场景。它就是为「单进程、单节点、本地优先」设计的。如果你的 QPS 需求是几十万以上、需要横向扩展，Milvus/Qdrant/Pinecone 仍然是正路。
跟我在做的事有什么关系？
我每天跑 GitHub AI 日报已经快三个月了，这件事本身就是一个典型的本地 AI 工作负载：
每天抓 20-30 个项目，每个项目有 README、变更日志、issue 列表、PR 列表、代码片段；
我需要把每个项目向量化存起来，做语义去重、做"类似项目"推荐；
数据量大概 1 万条以内，但数据需要 CRUD 起来（每天删除过期项目、加入新项目）。
这套场景的痛点：
- 跑 Milvus 太重，部署文档够我看半天
- 跑 Chroma 内存太凶，1 万条不算大但 Chroma 的 metadata filter 性能一般
- 跑 FAISS 要自己造持久化、CRUD 那一套
Zvec 几乎是为这种场景量身定做的：
嵌进程：跟我的 Python 脚本同一个进程；
零部署：pip install 完就能用；
schema 演进：可以调整索引策略不用重建；
MultiQuery：向量+关键词+标量过滤一条 query 搞定；
跨平台：我同时在 Mac 和 Windows 写脚本，不用为不同平台配不同的环境。
我已经计划下个月把这套日报的语义去重模块从 Chroma 迁到 Zvec——主要是冲着 MultiQuery 和磁盘持久化去的，CRUD 不再需要自己造。
更大的判断：「进程内数据库」这个范式会重新成为本地 AI 应用的标配。原因很简单：AI 应用的负载天生就是「单机为主、偶尔云端」，客户端-服务器架构在过去十年是给 Web 用的，给本地 AI 用就是杀鸡用牛刀。SQLite 在 Web 时代不是主流，在移动时代成了事实标准——同样的剧本会发生在向量数据库上。
我把它拆开看了之后的几个关键判断
为什么是 Proxima 引擎？
Proxima 是阿里内部跑了 6 年以上的向量检索引擎，覆盖淘宝/天猫/优酷/支付宝多个亿级 DAU 场景。这意味着 Zvec 不是「从零造轮子」的项目，而是「内部引擎产品化」——这个背景决定了它不会有算法研究型项目常见的"调参地狱"，也意味着生产环境稳定性有底子。
为什么 6 月 12 日 v0.5.0 是个关键节点？
DiskANN 是 Microsoft Research 2019 年发表的论文，核心思路是把 HNSW 的图索引搬到磁盘上——传统 HNSW 必须全量装内存，DiskANN 让你用磁盘换内存。Zvec 在 v0.5.0 把 DiskANN 加进去，等于宣告：单进程向量数据库正式进入十亿级规模。
之前用本地向量数据库做 RAG，500 万条以上就要开始想"我要不要上 Milvus 集群"了——现在 10M 以内的数据，笔记本就够了。
为什么 v0.5.0 之前的版本我建议等等再用？
24 个 Open Issues、34 个 Open PRs——量不大，但关键是 6 月 12 日才发了 v0.5.0，加上 2 月 9 日首次发布，整个项目也就 4 个月历史。如果你打算生产用，建议等 v0.6+ 再考虑。
为什么阿里要开源这个？
我的判断：战略护城河。阿里云上卖的是"Vector Engine for Enterprise"——本质是托管版 Milvus。Zvec 是免费的进程内版本，定位是"在端侧 / 边缘 / 笔记本上跑"——这两个不冲突，Zvec 反而是给阿里云拉新的开发者入口。你在本地用 Zvec 写原型，规模化的时候无缝迁到阿里云的 Milvus 托管服务。这套打法跟 MongoDB 把 Atlas 和开源版绑在一起是同一套逻辑。
// 架构：四层堆栈
// 横向对比：Zvec vs FAISS vs Chroma vs Milvus Lite
| 维度 | Zvec | FAISS | Chroma | Milvus Lite |
|---|---|---|---|---|
| 部署 | 嵌进程库 | 嵌进程库 | 嵌进程库 | 嵌进程库（受限） |
| 二进制大小 | <1MB | 50MB+（含 BLAS） | ~50MB | ~200MB |
| 持久化 | ✅ WAL 内置 | ❌ 自己造 | ✅ SQLite | ✅ RocksDB |
| CRUD | ✅ 完整 | ❌ 只读/写 | ✅ | ✅ |
| 全文检索（FTS） | ✅ 原生 | ❌ | ❌ | ❌ |
| 标量过滤下推 | ✅ | ❌ | ✅ | ✅ |
| 索引类型 | HNSW / IVF / DiskANN | IVF / PQ / HNSW / ... | HNSW | IVF / HNSW / ... |
| SIMD | NEON / AVX2 / AVX512 | 取决于后端 | ❌ | 部分 AVX2 |
| 分布式 | ❌ | ❌ | ❌ | ✅ |
| 协议 | Apache-2.0 | MIT | Apache-2.0 | Apache-2.0 |
| 多语言 SDK | Py/Node/Go/Rust/Dart | Py / C++ | Py / JS | Py/Java/Go/Node |
一句话总结：Zvec 是在"嵌进程 + 完整数据库 + 零部署"这个交集上，目前最干净的方案。
// 性能直观对比（Cohere 10M / VectorDBBench）
数值来自 VectorDBBench 公开 leaderboard + Zvec 官方 benchmark 页面（无第三方独立审计），仅作量级参考。FAISS 单独标出是因为它不是数据库，需要自建持久化层。
// 跟在我做的事有什么关系：什么时候我会真的用上？
除了上面提到的"日报语义去重模块"以外，我想到的几个可能落地场景：
本地 AI 助手（1 万 - 100 万条数据）：直接 import zvec，pip 一行装好，不用折腾 Docker，不用拉 gRPC 依赖。
边缘 AI 盒子 / IoT 设备：Zvec 的 RISC-V 支持意味着它能跑在物联网网关上。智能家居、机器人、本地化推荐都能用它做"嵌入式语义搜索"——这是 FAISS / Milvus 都没覆盖的场景。
RAG 应用的 MVP 阶段：如果你刚立项做一个 RAG 产品，1M 向量以内、单节点、本地优先——Zvec 比 Milvus 省 3 天部署时间，比 FAISS 省 2 周造轮子时间。
CI/CD 集成：GitHub Action 跑临时脚本做向量检索，Zvec 跟 Python 脚本同进程，零外部依赖，比跑一个 Qdrant 容器方便太多。
✅ Proxima 引擎 6 年生产验证：淘宝/天猫/优酷/支付宝都跑过
✅ 性能领先：单进程赛道 2× QPS（Cohere 10M 8000+ vs ZillizCloud 4000）
✅ 资源控制：硬性 memory_limit、mmap、线程数控制全有
✅ 跨平台：Linux/macOS/Windows + RISC-V（边缘 AI 独家）
✅ Apache-2.0：商用无门槛
✅ 文档完整：中英双语，benchmark 可复现
❌ 缺第三方独立审计：所有 benchmark 是官方自评
❌ 生态待建：RAG 框架（LangChain/LlamaIndex）原生集成还没
❌ 24 Open Issues / 34 Open PRs：响应速度待观察
❌ 不适合分布式：单进程赛道选手，百万 QPS 以上还是 Milvus/Qdrant
// links
GitHub 仓库 alibaba/zvec — 项目主页，Apache-2.0 协议，5 个 SDK
官方文档 zvec.org — 中英双语，API 参考、概念、部署、benchmarks
Benchmark 页面 — VectorDBBench + Cohere 10M/1M 公开测试
Zvec 架构深度解析 — 代码层面的架构分析
中文上手教程 — 知乎专栏，本地 RAG 实战
Proxima 引擎背景 — paperwave/zvec-alibaba 镜像，介绍 Proxima 在阿里的使用
VectorDBBench — Zilliz 维护的开源 benchmark 框架
DiskANN 论文 — Microsoft Research 2019，索引放磁盘的核心思路