向量数据库横评

这个 pack 装了什么

这个包把 七个主流向量数据库选项 摆在一起，让选型从一周评测压成 10 分钟决策。选型空间干净分三层：自建数据库、托管数据库、embedding API（很多顺带提供基础向量存储）。

这个 pack 故意只覆盖 DB 层 —— 存向量 + 提供最近邻查询。上面的 retrieve-and-generate 编排（切片 / 改写 / 重排）放在 RAG Pipelines 包里，两个决策保持独立。

为什么要慎重选

多数团队头六个月跑在错的向量 DB 上，等出问题才发现。两个典型崩盘：

• 从 Pinecone 起步，扩规模时账单爆炸。Pinecone 按 pod 收费，1M 向量没问题，到 50M 开始贵。迁出要重 embed 一遍。
• 从自建起步，扩规模时运维爆炸。一台 Chroma 节点存了 30M 向量，发现单节点 ANN 索引不会优雅降级 —— 查询延迟一个季度从 50ms 飙到 800ms。

慎重选意味着看三个轴：

1. 你的向量量级下的召回率 vs 延迟。ANN-Benchmarks 公布 recall@10 vs QPS 曲线；>10M 向量时 Qdrant 和 Pinecone 持续领先，Chroma 在 5M 以下没问题。
2. 混合检索需求。如果查询既要关键词过滤又要语义相似，Weaviate 的混合模式和 Qdrant 的 payload 过滤是分水岭 —— 给 Chroma 后挂 BM25 是噩梦。
3. 运维姿态。两人团队选 Pinecone 的「没服务器要看」就赢。已经在大规模跑 Postgres 的，pgvector（在 Postgres for Agents 包里）TCO 上经常打败所有选项。

一条命令装齐

# 把整个 pack 装进当前项目
tokrepo install pack/vector-db-showdown

# 或只装单个
tokrepo install qdrant-mcp
tokrepo install chroma

TokRepo CLI 把自建选项的 Docker Compose 片段、托管 API 的环境变量模板、加载 10 万向量并测 p95 延迟的基准脚本一起装进项目。

常见踩坑

• 拿随机向量做基准。随机向量的距离分布扁平 —— 所有索引看起来一样快。永远用领域真实 embedding 做基准（Wikipedia dump 是公开代理）。
• 选错距离度量。同样数据下 cosine / dot product / L2 排序不同。用 embedding 模型训练时的度量；OpenAI text-embedding-3 用 cosine，部分开源模型用 dot product。
• 忽视 embedding 模型锁定。用 Cohere embed 1 亿文档后想换 OpenAI，要全部重 embed。有些团队过渡期同时存两套模型 embedding 并行。
• 把「向量 DB」当完整 RAG 方案。这些工具都不做重排、查询改写、结果质量评估。要配 RAG Pipelines 包和 LLM Eval 包。
• 低估过滤基数。先按高基数字段（例如 user_id）预过滤再 ANN 检索，多数引擎召回率崩。要么后过滤，要么按用户建索引。

这套不够用的时候

数据集小（<1M 向量）且已经有 Postgres，pgvector 在运维简单度上打败所有选项 —— 少一个服务要看。查询除了语义相似还要地理或图约束，看 Neo4j + GDS 或 OpenSearch k-NN —— tradeoff 不同但形状更干净。规模到 10 亿向量级，已经超出这个 pack 范围；找厂商谈 Vespa 或 Milvus 专用层。