为纪念 35 周年:《Terminator 2: Judgment Day》将在全球影院重映
2026-07-13
2026-07-15 0
轻量级 RAG 应用福音!阿里开源的进程内向量数据库 Zvec,无需部署服务,import 即用,性能不打折。核心内容:1. 轻量级向量数据库 Zvec 的定位与适用场景2. 官方基准测试展示的千万级向量检索性能3. 五行代码快速上手的简易使用示例
做 RAG 应用,向量数据库这一步大多数人会想到部署 Milvus 或者起一个 Qdrant 容器。
但很多场景其实不需要这么重。本地跑个 Agent 的记忆库、笔记软件的语义搜索、移动端 App 的离线检索——这些场景里,专门起一个数据库服务、维护一套部署、处理网络延迟,是杀鸡用牛刀。
Zvec 是阿里巴巴开源的进程内向量数据库,不需要起服务,pip install 之后直接在代码里 import 用,和 SQLite 之于关系型数据库是同一个定位。在阿里内部生产环境里跑了一段时间之后才开源出来。
这是官方用 VectorDBBench(向量数据库社区广泛采用的开源基准测试框架)跑出的 Cohere 1000 万条 768 维向量的测试结果:

横轴是并发数,纵轴是每秒查询数(QPS)。这是在单台 16 核 64GB 内存的机器上跑出来的结果,没有依赖额外的存储或网络服务。
召回率(搜索结果的准确度)同步测量:

千万级向量,毫秒级检索,这两张图加在一起说明的是:进程内架构不代表性能妥协。
import zvec
# 定义 collection schema
schema = zvec.CollectionSchema(
name="example",
vectors=zvec.VectorSchema("embedding", zvec.DataType.VECTOR_FP32, 4),
)
# 创建 collection,本地文件存储
collection = zvec.create_and_open(path="./zvec_example", schema=schema)
# 插入文档
collection.insert([
zvec.Doc(id="doc_1", vectors={"embedding": [0.1, 0.2, 0.3, 0.4]}),
zvec.Doc(id="doc_2", vectors={"embedding": [0.2, 0.3, 0.4, 0.1]}),
])
# 按向量相似度搜索
results = collection.query(
zvec.VectorQuery("embedding", vector=[0.4, 0.3, 0.3, 0.1]),
topk=10
)
没有连接字符串,没有起服务,没有等待网络往返。./zvec_example 是本地一个目录,关掉进程数据还在,下次打开继续用。
直接告诉你的 Claude Code 或 Cursor:
帮我在这个 Python 项目里集成 Zvec 作为本地向量库,
用来存储文档的 embedding,支持语义搜索和过滤检索。
Schema 设计:每个文档需要 id、embedding 向量、和一个 source 字段用于过滤。
参考文档:https://zvec.org/en/docs/db/quickstart/
Node.js 项目:
帮我用 @zvec/zvec 给这个 Node.js 项目加一个本地向量存储,
不需要起 Docker,直接 npm install 用,
用来做 RAG 应用的文档检索
Agent 会处理好 schema 设计、安装依赖、写好增删改查的封装代码。
这是 Zvec 比很多同类工具更完整的地方——原生支持混合检索(Hybrid Search),不需要外接关键词搜索引擎再做结果合并。
稠密向量(Dense Vector)抓的是语义相似度——"猫"和"小猫"在向量空间里离得近。稀疏向量(Sparse Vector)类似传统的关键词检索——专有名词、产品型号这类精确匹配场景,稠密向量反而不如关键词准。
Zvec 支持在一次查询里同时用结构化过滤条件(比如按时间、来源筛选)加向量相似度排序,不需要先用 SQL 过滤再单独调向量搜索拼接结果。
进程内数据库最让人担心的事情是:进程崩了,数据是不是就没了?
Zvec 用 Write-Ahead Logging(预写日志)保证持久性——写操作先落日志再生效,进程崩溃或断电后重启,数据可以从日志恢复,不会丢。
并发模型是"多读单写":多个进程可以同时打开同一个 collection 做查询,但写入操作是单进程独占的。这个设计和大多数嵌入式数据库(SQLite 也是类似模式)一致,适合"一个进程写、多个进程读"的场景,比如一个后台任务在更新索引,多个 API 进程在提供查询服务。
作为进程内库,Zvec 的运行环境就是你代码运行的环境——不需要额外部署:
Dart/Flutter 的官方 SDK 也在 v0.4.0 里发布了,FFI 绑定打包好了 Android(arm64-v8a)和 iOS(arm64)的预编译版本,不需要手动编译 native 代码——这意味着可以直接在手机 App 里做本地语义搜索,完全离线。
# Python(3.10–3.14)
pip install zvec
# Node.js
npm install @zvec/zvec
支持平台:Linux(x86_64、ARM64)、macOS(ARM64)、Windows(x86_64)。源码编译支持更多平台,包括 iOS 和 Android。
单机单进程写入是设计限制,不是 bug
如果你的场景需要多个进程同时写入同一份数据(比如分布式爬虫往同一个向量库灌数据),Zvec 的"单写"模型会成为瓶颈。这种场景适合 Milvus 或 Qdrant 这类客户端-服务端架构的数据库,不是 Zvec 的目标场景。
没有内置的分布式能力
Zvec 的定位就是单机进程内库,没有分片、没有副本、没有跨机器的数据分布。数据量大到单机内存放不下,或者需要高可用容灾,需要换方案。
生态和工具链还在早期
v0.4.0,7 个正式发布版本,相比 Milvus、Qdrant、Chroma 这些更早进入市场的项目,集成生态(LangChain、LlamaIndex 这类框架的官方适配器)还不够丰富,遇到问题能搜到的资料相对少。
topK 上限调整是最近才放开的
v0.4.0 才放宽了 topK 的上限限制,用来支持更大规模的召回场景。如果你用的是更早的版本,大批量召回可能会遇到限制,建议直接升级到最新版。
Zvec 解决的问题很具体:不是所有需要向量搜索的场景都需要一个独立部署的数据库服务。
本地 Agent 的记忆系统、笔记软件的语义搜索、移动端离线检索、Jupyter 里的实验原型——这些场景起一个 Milvus 集群是过度设计,用进程内库 import 一下就够。
阿里内部生产验证过,C++ 核心保证性能,Python/Node.js/Dart 三端 SDK 覆盖了大多数应用场景,混合检索和 WAL 持久化也都到位。如果你的项目不需要分布式架构,只是想要一个嵌进代码里就能用的向量库,值得试一下。
GitHub:https://github.com/alibaba/zvec
登录查看剩余 70% 内容