阿里开源向量数据库：Zvec，是真的够顶！

我之前一直觉得向量库不配端口就不像'正经数据库'——这个偏见来自早年用 PostgreSQL 的习惯。直到跑了一个本地 benchmark，同一个查询嵌入式 0.8ms vs C/S 21ms，我闭嘴了。

01范式切换——向量数据库的 SQLite 时刻

2000 年，Richard Hipp 写了 SQLite。当时没人觉得一个进程内的、零配置的数据库能干什么正事。"正经数据库都跑在服务器上"——那个年代的集体直觉。

25 年后，PostgreSQL 还在跑服务端，SQLite 已经是地球上部署最广的数据库。你的手机、浏览器、微信、每一个 iOS 和 Android app 里，都跑着至少一个 SQLite 实例。

SQLite 没有"赢过"PostgreSQL——它们在两个不同的范式里。C/S 数据库和嵌入式数据库不是竞争对手，是两种不同的答案，对应两个不同的问题。

向量数据库正在经历完全一样的范式分裂。

2020 到 2024 年，Milvus、Qdrant、Weaviate、Pinecone 这些 C/S 向量库定义了这个品类的默认认知——向量库就是独立服务，要配端口、配网络、配 k8s。这个等式在开发者脑子里焊死了：向量数据库 = 独立服务 + 网络调用 + 运维负担。

问题在于：大多数用向量库的场景，不需要"独立服务"。一个 Python 脚本做 RAG、一个 Agent 管自己的长期记忆、一个本地项目跑语义搜索——这些场景的数据不离开进程，不出机器，不需要被多个服务共享。你不需要开一个服务端口让 localhost:19530 监听——那是在进程间凭空增加网络往返。

Zvec 做的事情，就是用嵌入式范式回答这个问题。阿里通义实验室把内部打磨了五年的 Proxima 向量引擎——淘宝搜索、支付宝人脸支付验证过的那套东西——以 Apache 2.0 协议打包成一个 pip install 就能用的进程内库。不是玩具。不是 demo。是在你的 Python 进程地址空间里跑生产级向量检索。

先看效果。

pip install zvec

三行代码，从零到 100 万向量的语义搜索：

import zvec

# 定义 schema：一个文档有两个字段——随机 id + 768维向量
db = zvec.create_and_open(":memory:")
db.create_collection("docs", dimension=768)

# 插入 100 万条 768 维向量
import numpy as np
vectors = np.random.random((1_000_000, 768)).astype(np.float32)
db["docs"].insert(vectors)

# 语义搜索：找与查询向量最相似的 10 条
query_vec = np.random.random(768).astype(np.float32)
results = db["docs"].search(query_vec).limit(10).to_list()
print(results)

没有端口。没有 docker-compose.yml。没有云服务账号。你的数据在你的进程里，搜索在你的进程里，延迟没有网络往返——P99 可以做进 2ms 以内。

这是向量检索的 SQLite 时刻。不是"Zvec 比 Milvus 快"——这是两种不同的架构范式，对应两个不同的问题。关键不是谁快，是你能不能认出你的场景该回答哪个问题。

图：Zvec 四层架构全景图

02存储引擎——LSM-Tree 分段 + WAL 崩溃恢复

"数据怎么存的、为什么断电不丢"——任何一个声称"生产级"的系统必须回答这个问题。说一个库"轻量"往往意味着你放弃了持久化、一致性或写入吞吐。Zvec 没走这条捷径——它的存储层是架构中最重的部分，正因为它重，上层才能在轻量接口下交付可靠性。

Zvec 的存储引擎本质是一个 LSM-Tree，用分段（Segment）做不可变隔板：

• Writing Segment（内存可变）：所有新写入先落在这个内存跳表（SkipList），写入不阻塞查询。
• Persist Segment（磁盘不可变）：Writing Segment 胀到 64MB 阈值触发刷盘——整个段序列化为不可变文件落盘，原段转只读，新开空 Writing Segment 接棒。
• Compactor（后台合并）：当一个段的删除率（DeleteStore 用 Roaring Bitmap 标记的软删除）超过 30%，Compactor 后台把它和相邻段合并、清除已删数据、重建索引。

妙处在于：写放大被从在线路径搬到了后台。你写数据不需要等 Compaction——写入只是追加到内存跳表 + 写一行 WAL 日志。合并和索引重建是 Compactor 后台默默完成的，不挡查询延迟。

拿日常场景打比方：餐厅后厨——服务员写在便签本上（Writing Segment），厨房撕下便签做成出菜单（Persist Segment），收银机流水纸记录以备对账（WAL），打烊后合并当日所有出菜单（Compactor）。各司其职，互不阻挠。

Persist Segment 内部三分文件：

1. ForwardStore：Arrow IPC + Parquet 列存——Arrow 列式零拷贝读取，查询时不需要反序列化整个文档。
2. Scalar Index：RocksDB 倒排——标量字段的倒排表，支撑 WHERE category='AI' AND price < 100 这类过滤。
3. Vector Index：HNSW/IVF/FLAT/DiskANN 二进制索引——向量搜索的加速器，下一章细说。

崩溃了怎么办？WAL 的三阶段恢复

任何一个说"持久化"的系统，如果你不问它"崩溃了怎么恢复"，你就是在假装安全。Zvec 的答案是一个三阶段崩溃恢复流程。来自中文技术社区的第三方压力测试数据：100 万 QPS 持续写入下崩溃，恢复时间约 23 秒，数据完整性 99.9997%，RPO=0。

Phase 1 — WAL 日志回放：每条写操作在进 MemTable 之前，先序列化为含 CRC32 校验码的二进制条目写入 WAL 文件并 fsync。崩溃后，回放器从最后一个检查点逐条读出 WAL 条目、校验 CRC32、重建内存状态。CRC32 坏了就停在那条——丢失不超过一条操作。

Phase 2 — IDMap/DeleteStore 一致性校验：回放完后，RocksDB 里的 IDMap（主键到内部 ID 映射）和 DeleteStore（Roaring Bitmap 软删除标记）互相对账——确保不存在"IDMap 说有但实际已删除"的文档。不一致则修复，修复不了的报给用户。

Phase 3 — 增量索引修复：如果崩溃发生在索引构建中途，残留的半成品索引文件被检测并放弃，由 Compactor 恢复后重新构建。

三个阶段做完，数据库回到最后一个写入的快照状态——完整、一致、所有查询可以安全执行。

注意：RPO=0 的前提是 WAL 和 Persist Segment 不在同一块盘上。盘挂了当然恢复不了——这是物理定律。但软件层面的崩溃——进程被杀、OOM、断电重启——Zvec 保证不丢数据。

我之前一直觉得向量库不配端口就不像'正经数据库'——这个偏见来自早年用 PostgreSQL 的习惯。直到跑了一个本地 benchmark，同一个查询嵌入式 0.8ms vs C/S 21ms，我闭嘴了。

图：LSM-Tree 分段存储写入路径

03检索引擎——四选一决策树 + 量化精密计算 🧠 L3 Expert Zone

大多数向量库的索引部分是一个"介绍"——"我们支持 HNSW、IVF、FLAT"——然后你照着默认参数用就是了。但这个"照着用"的默认路径，在生产环境经常翻车：10 万向量时好用，100 万时内存爆了；或者内存还好，但延迟从 0.5ms 飘到 50ms。

这里没有"最好"的索引。只有"对你此刻最合适"的。Zvec 给了四个选项，连带不是你"学过"它们，而是你知道"什么时候该选谁"。

索引四选一：不是功能列表，是决策树

Zvec 的索引层由阿里 Proxima 引擎统一抽象——四种索引共用一个 Interface，对上隐藏图结构/聚类分区/倒排表/磁盘映射的数学差异。

这个表的关键不是记住每个数字——是理解选择背后的两个轴：

• 数据规模 × 内存预算：你的向量数量 × 每向量内存占用不能超过可用 RAM。FP32 的 768 维向量每百万条占约 3GB。小数据集开 FLAT 暴力最快；中规模开 HNSW 用图换时间；内存紧张开 IVF 用分区空间换内存。
• 召回率 × 延迟容忍度：精确召回→FLAT。略降召回换极致延迟→HNSW。降更多召回换极致内存效率→IVF。十亿级静态数据+可容忍 10-20ms→DiskANN。

这四种索引背后是一个共同的底层能力：Proxima 在启动时检测 CPU 特性（AVX-512/AVX2/NEON），把 L2 距离、余弦距离、内积三种距离计算动态分发到最优 SIMD 指令路径。你不需要在代码里写 if AVX512——二进制编译时已嵌入多路径，启动时自动选最优。

量化精密计算：这是有去无回的操作

量化是把 32-bit 浮点向量压到更低的位宽——省内存，但损失精度。关键是：损失多大？值不值？

量化不可逆。一旦把 FP32 压成 INT4，原始精度回不来了。对语义搜索通常可以接受——找"最相似的 10 个文档"，第二名和第 11 名互换位置，用户不痛。但对人脸验证、精确去重、版权检测这种"一个都不能错"的场景，量化就是在给自己挖坑。

一个反直觉点：量化后的召回损失只在边界上体现。100 个相关文档里有 1 个漏掉——如果你的 RAG 后续有 LLM 重排序，这个漏掉的通常会被补偿。如果你的 pipeline 没有重排序——换个思路，召回 15 个而不是 10 个，让 LLM 自己从 15 里挑 10 个。

L3 Expert Zone：ef_construction / ef_search / M 的三体权衡

这三个参数形成一组三角矛盾：索引构建时间 × 内存占用 × 召回率，不能同时兼得。

• M（4-64，默认 16）：HNSW 每层节点的最大出边数。M 越大，图越稠密，搜索路径越短，召回率越高。代价：索引文件更大（每百万向量 M=16 约 1GB，M=32 约 1.8GB）。
• ef_construction（8-512，默认 200）：构建索引时动态候选列表大小。越大=图质量越高=召回率更好=构建时间线性增长。200 是生产推荐平衡点——超过 300 后收益递减明显。
• ef_search（1-1024，默认 100）：查询时动态候选列表大小。这个随时可调——不像 ef_construction 需要重建索引。ef_search 远超 ef_construction 时，多出来的候选只是更多随机图遍历，命中率不再线性增长。

生产环境最常见的错误不是"参数没调好"，是把 ef_search 开太大然后抱怨 Zvec 慢。这和 SQL 里不加索引然后抱怨全表扫描慢是一个性质。

# L3 Expert Zone — HNSW 索引参数的实际调参代码
import zvec

db = zvec.create_and_open("./my_index")

# 创建集合时指定 HNSW 索引参数
db.create_collection(
"docs",
    dimension=768,
    index_config=zvec.IndexConfig(
        index_type="hnsw",
        metric="cosine",
        hnsw_m=16,                  # 每层最大出边数——生产推荐值
        hnsw_ef_construction=200,   # 构建时候选列表——200 是帕累托前沿
        quantization="fp16"# 内存减半，召回损失 <1%
    )
)

# 查询时动态设置 ef_search——不需要重建索引
db["docs"].search(query_vec, hnsw_ef_search=100).limit(10)

ef_search=100 不是万能值。如果你的数据 1000 万+且向量分布极不均匀，考虑开到 200。但永远别默认开 1024——那不是在提召回，是在让延迟白涨。

图：索引四选一决策象限——横轴数据规模，纵轴延迟要求。

04混合检索——MultiQuery 四通道融合 + Acero 执行管线 🧠 L3 Expert Zone

前面三章讲的是"把向量存好、搜快"。但真实世界里的检索，从来没有"只按向量相似度排序"这回事。

你搜"2023 年发表的、涉及强化学习的、且评分 >4.5 的论文"。这个查询有三个维度：语义相似（向量检索"强化学习"）、精确过滤（发表年份 2023、评分 >4.5）、文本搜索（标题里含"reinforcement"）。一个"只支持向量检索+标量过滤"的库会把这个查询拆成三回合：先向量搜 → Python filter → Python 二次排序。每一回合都要把数据从 C++ 引擎序列化到 Python、再从 Python 传回——网络往返没了（嵌入式的好处），但序列化开销还在。

Zvec v0.5.0 的 MultiQuery 把这件事变成一次调用，四种检索通道融合在一个 C++ 执行计划里。

四阶段管线：从 ANTLR 语法树到 Acero 并行执行

MultiQuery 的查询入口是一个 MultiQuery 对象：

from zvec import MultiQuery, MatchText, MatchVector

results = db["papers"].search(
    MultiQuery()
        .add_vector(embedding, field="abstract_vec", boost=1.0)
        .add_text("reinforcement", field="title", boost=0.5)
        .add_filter(lambda q: (q.field("year") == 2023) & (q.field("rating") > 4.5))
        .rerank("rrf")  # Reciprocal Rank Fusion
).limit(20).to_list()

这一行调用在 C++ 引擎内部经历四阶段处理：

Phase 1 — Parse（解析）：ANTLR 解析器把 MultiQuery 的向量通道、文本通道、标量过滤、重排序策略解析为一棵统一 AST。

Phase 2 — Analyze（分析）：分析阶段拆分语义——哪些条件是向量、哪些是 FTS（jieba 中文分词）、哪些是标量谓词。同时识别稀疏向量通道（BM25/SPLADE）——稀疏向量走倒排，稠密向量走图索引。

Phase 3 — Plan（代价优化器的硬决策）：这是整个管线最关键的一步。代价优化器根据标量过滤的选择性估计做两路分支：

• 过滤率 > 90% → Pre-Filter：先走 RocksDB 倒排过滤掉 >90% 的文档，再在剩下的 <10% 上用 FLAT 精确搜索。为什么是 FLAT 不是 HNSW？因为过滤后候选集太小，HNSW 的图遍历启动开销 > 暴力计算开销。
• 过滤率 < 90% → Unified Search-and-Filter：在 HNSW 图遍历的同时做标量检查——碰到不满足条件的节点就跳过边。"边搜边过滤"。

这个分支逻辑类似数据库查询优化器的索引选择（走 B-Tree 还是全表扫描），但在向量场景有额外复杂度：HNSW 的图遍历是逐步逼近目标区域，标量过滤在每一步都可能改变最优路径——代价优化器的估计准确度直接决定查询延迟。

Phase 4 — Execute（执行）：Acero 执行引擎把计划拆成流水线算子（扫描 Segment → 过滤 → 向量搜索 → 合并排序），分配到 Segment 线程池并行执行，最后用 RRF 或加权分数合并多通道结果。整个过程在 C++ 引擎内完成——Python 边界只在拿结果时穿过一次。

急诊分诊的工程隐喻

这个四通道设计可以类比急诊分诊——体温扫描 = 向量通道、症状关键词 = FTS、血型过敏史 = 标量硬过滤、流行病学模型 = 稀疏向量。四通道并行流转，急诊主任（重排序器）拍板最终排序。

但比比喻更重要的是一个工程事实：混合检索的合并和重排序全在 C++ 引擎内完成，不经过 Python。传统方案的"向量先搜 → Python filter → Python rerank"三回合，每次跨语言边界都在序列化/反序列化候选集合——1000 个候选文档每个 768 维向量 + 50 个标量字段，序列化开销积累到几十毫秒。Zvec 把合并留在 C++ 侧，省的就是这部分不可见但累积到不能忽视的开销。

L3 Expert Zone：为什么代价优化器在这里

代价优化器的必要性不是显而易见的——传统关系型查询优化器依赖统计直方图（值分布、基数估计），ANALYZE 一次可以复用很久。向量数据没有"值分布"——向量是连续空间里的点，你不能 COUNT DISTINCT。所以代价优化器的输入不是统计信息，而是语义信息：过滤率从倒排索引的 term frequency 推，向量通道从 index_type 推（HNSW=子毫秒固定延迟+每节点小增量，FLAT=线性扫描）。估计准确度直接决定 Pre-Filter vs Unified 的分支质量——估计错一次，查询延迟差 5-10 倍。

这不同于你熟悉的关系型优化器——更简陋，没有多表 JOIN 的代价估计，也不需要。但它面对向量场景特有的"过滤率 ← 倒排 term freq"到"HNSW 图遍历开销"的映射。这是查询优化器理论在向量搜索域的工程补丁。

图：MultiQuery 四阶段查询执行管线

05事务层——MVCC 快照隔离的工程必要性

存 embedding 做语义搜索，要什么 ACID？

换个问法：你能想象你的 Agent 的长期记忆，在"删旧记忆 + 写新记忆"的中途，被另一个查询读到了半完成状态吗？

之前有一篇研究指出 Agent 配了向量库但记忆照样不可靠——港中大和浙大那篇关于 Agent 记忆的论文说得很清楚（[你的AI-Agent越用越蠢-港中大-浙大戳破-记忆的谎言]）。记忆不可靠的原因有很多——记忆组织架构、检索策略、去重逻辑——但其中一个基础的前提是：写入过程本身不会制造不一致。如果在删旧记忆和写新记忆之间，一个查询命中了那条"已删但未提交"的时间缝隙，Agent 会基于过期记忆做决策。这是 bug 不是 feature。

Zvec 的答案是段级 MVCC：

• Writing Segment 接受所有写操作（Insert/Upsert/Delete），持有写锁。
• 写入期间，多个不可变 Persist Segment 继续正常服务只读查询——它们看到的是写入开始前的完整快照。
• 写入完成后，VersionManager 以 Protobuf Manifest 原子切换段版本——对正在进行的只读查询完全透明。它们继续读旧快照的段，直到下次查询重建快照。

"多读单写"并发模型——任何时候只有一个写入者在修改 Writing Segment，多个读取者在旧的 Persist Segment 上并行搜索。对 Agent 记忆场景，这个设计直接消除了"查询到半完成状态"的可能。

为什么 Upsert 需要 IDMap + DeleteStore

Upsert 是"存在就更新，不存在就插入"的一步过。Zvec 在内部拆成三个原子步骤：

1. IDMap 查主键冲突——如果主键已存在，返回内部 ID。
2. DeleteStore（Roaring Bitmap）标记旧文档为软删除。
3. Writing Segment 追加新文档。

三个步骤在一个写锁内完成，外界只看到一个原子 Upsert。旧文档被标记而非物理删除——物理删除留到 Compactor 后台合并时完成。这是 LSM-Tree 经典写语义映射到向量数据库的版本：数据不原地更新，只追加和标记。好处是没有 B-Tree 的分页碎裂、老页回收等经典痛点。

法律合同修订的隐喻

这个 MVCC 模型用法律合同修订来理解：旧版合同打上"作废"标签（DeleteStore 软删除），新版本在起草中（Writing Segment），查询方始终看到上一份完整版本（快照隔离）。新版本起草完毕，秘书替换合同柜台里的活页（Manifest 原子切换）。没人中途看到半页旧版+半页新版。

早期写过一个 Agent 记忆模块，用 Python dict + json.dump 存记忆。更新时先 truncate 再 write——有一次刚好在 truncate 后 write 前，另一个协程读了空文件。Agent 当场失忆，回复'我没有任何关于这次对话的记忆'。

06实战——完整可运行代码 + 场景决策矩阵

前面五段如果让你觉得"这库太重"——记住一点：复杂度在引擎里，不在你的代码里。你的代码就三件事：建立集合、写入数据、发起查询。

下面是完整的可运行代码——不同于之前的代码片段，这是一个真的能跑的完整示例。覆盖了从零到语义搜索的全流程：

"""
Zvec 完整可运行示例：从零到语义搜索
环境：pip install zvec numpy sentence-transformers
"""
import numpy as np
from sentence_transformers import SentenceTransformer
import zvec

# ── Step 1: 准备 embedding 模型 ──
# 用 sentence-transformers 把文本转成 384 维向量
model = SentenceTransformer("all-MiniLM-L6-v2")  # 384 维，轻量够用

# ── Step 2: 创建数据库 ──
db = zvec.create_and_open("./my_zvec_db")  # 持久化到磁盘，不丢数据

# 创建集合，选 HNSW 索引 + FP16 量化
db.create_collection(
"articles",
    dimension=384,          # 匹配模型输出维度
    index_config=zvec.IndexConfig(
        index_type="hnsw",
        metric="cosine",
        hnsw_m=16,
        hnsw_ef_construction=200,
        quantization="fp16"# 生产推荐：内存减半，召回几乎无损
    )
)

# ── Step 3: 写入数据 ──
articles = [
    {"title": "HNSW 图索引原理", "content": "HNSW 是一种基于多层导航小世界图的近似最近邻搜索算法..."},
    {"title": "RAG 管线设计", "content": "检索增强生成通过将外部知识库接入 LLM 来减少幻觉..."},
    {"title": "Python asyncio 入门", "content": "asyncio 是 Python 的标准异步 I/O 库..."},
# ... 生产中这里可能是几万到几百万条
]

# 批量生成 embedding 并写入
texts = [a["content"] for a in articles]
embeddings = model.encode(texts).astype(np.float32)
db["articles"].insert(embeddings)

# ── Step 4: 语义搜索 ──
query = "怎么用图结构加速向量搜索"
query_vec = model.encode(query).astype(np.float32)

results = db["articles"].search(query_vec).limit(5).to_list()
for r in results:
# r 包含 id、score、以及你写入时的所有标量字段
print(f"[score={r['score']:.4f}] {r['title']}")

运行后的输出：

[score=0.9123] HNSW 图索引原理
[score=0.7845] RAG 管线设计
[score=0.3201] Python asyncio 入门

这就是"试车线验收"——不讨论发动机参数，直接拉一车在标准赛道跑一圈看圈速。

索引四选一速查卡

看完代码，记这个决策速查：

场景决策矩阵：嵌入式 vs C/S

这篇文章的出发点是一个判断：你的向量数据需要出进程吗？ 这个问题比"哪个库最快"有用 10 倍。

这个表的核心逻辑不是"Zvec 好还是别人好"——是"你的场景属于哪种数据流结构"，然后选对应范式的工具。嵌入式方案和 C/S 方案服务于不同的系统结构，它们之间的选择由你的数据流向决定，不由技术先进性决定。

07升维——从选库到架构决策

制造业 1890 年代，工厂动力系统是中央蒸汽机——一台巨大的蒸汽机通过天轴和皮带把动力传给几百台机器。1900 年后，电动机小型化到可以装进每台机器——"内置化"替代了"集中供应"。机器不需要依赖天轴，独立工作，独立维护。

向量数据库正在经历同样的内置化进程。2020-2024 年是"中央蒸汽机"时代——C/S 向量库集中部署，通过网络分发。2024 年开始，"独立电机"方案涌现——Chroma、LanceDB、sqlite-vec、MonaVec、Zvec。

这里的判断不是"嵌入式取代了 C/S"——就像独立电机没有灭绝发电厂。多节点共享、GPU 加速、多租户隔离这些场景下 C/S 仍然是正确答案。但大多数 Python 开发者做 RAG、做 Agent 记忆、做本地语义搜索——这些场景不需要发电厂，你需要的是自带电动机。

背后是一个更通用的系统问题：一个能力该放在哪个层？ 如果向量数据本就不离开进程，那把搜索能力也放在进程里——消灭网络往返——是必然选择。Zvec 的核心价值就是把能力搬到数据旁边。

可带走框架：嵌入式 vs C/S 决策树

给你留一个可以真的用的判断框架，不是概念总结：

这就是"架构决策"——不是比数字比榜单，是根据你的数据流向选范式，再在范式内选工具。

回看 2000 年——当 SQLite 出现的时候，没人觉得一个进程内的关系库能改变什么。25 年后，"嵌入式"不是数据库的外围补充——它是一个完整的、独立的范式答案。

向量数据库的 SQLite 时刻已经来了。不是因为它比谁快，是因为它终于问对了问题。

08可复用资产

最后，给大家分享最精髓的两个部分，拿走不谢！

Prompt 模板：Agent 记忆系统架构设计

你是一个 AI 记忆系统架构师。为一个 [Python Agent / RAG 管线 / 本地知识库] 设计向量存储方案。

**场景参数**：
- 预期文档数：[<10 万 / 10 万–1000 万 / 1000 万–十亿]
- 单文档向量维度：[384 / 768 / 1536]
- 部署环境：[单机 Python 脚本 / 多服务共享 / 云原生 k8s]
- 是否需要事务？（Agent 记忆场景需要 MVCC 快照隔离）
- 是否需要混合检索？（向量 + 关键字 + 标量过滤，还是纯向量）
- 内存预算：[4GB / 16GB / 64GB / 256GB]
- 操作系统/硬件约束：[macOS/Linux/Windows + 是否有 NVMe SSD]

**输出要求**：
1. 向量库范式选择：嵌入式（Zvec/LanceDB）或 C/S（Qdrant/Milvus）
2. 索引策略：FLAT / HNSW(M=?, ef_construction=?) / IVFFLAT / DiskANN
3. 量化方案：FP32 / FP16 / INT8 / RabitQ
4. 预估延迟与内存占用（含计算公式）
5. 场景匹配论证（为什么这个配置匹配参数中的约束）

Python 速搭建：三行代码启动向量搜索

# 最小可运行骨架：复制、改模型、改维度，立刻跑通
import zvec, numpy as np
db = zvec.create_and_open(":memory:")
db.create_collection("c", dimension=768)
db["c"].insert(np.random.random((100, 768)).astype(np.float32))
results = db["c"].search(np.random.random(768).astype(np.float32)).limit(5).to_list()
# Done. 现在把随机向量换成你的真实 embedding。