一篇关于向量数据库选型的独立分析。不写通稿，只说真话。
阅读时间：约 11 分钟 | 标签：#向量数据库 #RAG #技术选型 #国产数据库
向量数据库怎么选，是眼下 RAG 项目里最被低估、又最贵的一个决策。 它不像选一门编程语言，错了还能重构；向量库一旦上线，索引、数据、embedding 全量迁移一遍的代价，足以把一个项目的利润吃光。
如果你正在做检索增强生成、语义搜索或智能问答，这篇文章给你一套可复用的选型框架------不是告诉你"哪个产品最好"（这种东西不存在），而是告诉你该从哪 8 个维度去比、每个维度怎么量化、最后怎么落成决策。
先亮结论：向量数据库选型的本质是匹配度，不是性能排名。 我见过太多选型失败，不是参数没看懂，而是没想清楚"我的场景到底卡在哪一个维度上"。
目录
- 动笔之前，先回答一个更基本的问题
- [8 个维度：一张表看清该比什么](#8 个维度：一张表看清该比什么)
- 索引是选型里隐藏的分水岭
- [把 8 个维度合成一张决策表](#把 8 个维度合成一张决策表)
- 选型里最常见的四个错误
- [常见问题 FAQ](#常见问题 FAQ)
- 结语
一、动笔之前，先回答一个更基本的问题
搜索"向量数据库选型"的人，默认自己需要"一个向量数据库"。但相当一部分人真正需要的，可能只是"在现有数据库上加一个向量能力"。
判断标准很朴素，看三个数：
- 向量规模：百万级以内，还是亿级起步？
- 延迟要求：毫秒级实时，还是百毫秒也能接受？
- 现有底座：是否已经在跑一套关系型数据库？
如果答案是"百万级以内、百毫秒可接受、已有关系库"，引入一个独立向量数据库的收益，往往抵不过新增一套系统的运维成本。反过来，亿级规模、毫秒级延迟、向量是产品核心能力，才值得上专用向量库。
这一步想清楚，能直接筛掉一半的错误选型。下面的 8 个维度，是针对"确认需要向量能力"之后的那部分决策。
二、8 个维度：一张表看清该比什么
先给全景，再逐个拆。
| 维度 | 要回答的问题 | 可量化指标 | 最容易被忽略的点 |
|---|---|---|---|
| 1 检索质量 | 召回够不够准 | Recall@K、相关排序 | 召回率会随压缩和过滤而变化 |
| 2 索引类型 | 用哪种索引算法 | 构建耗时、查询耗时 | 索引决定内存与召回的上限 |
| 3 过滤能力 | 带业务条件能不能查 | 高过滤比例下的召回 | 过滤一加，很多索引会退化 |
| 4 延迟 | 单次查询多快 | P50/P95/P99 | 只看平均延迟会误判 |
| 5 吞吐 | 并发扛不扛得住 | QPS、并发下延迟 | 单条快不等于并发快 |
| 6 成本 | 三年花多少 | 内存/存储/人力 | 人力成本往往超过服务器 |
| 7 运维 | 能不能长期养得起 | 备份/监控/扩缩容 | 迁移代价是最大的隐性成本 |
| 8 生态 | 工具链与合规接不接得上 | 框架集成、信创适配 | 合规是硬门槛，不是加分项 |
下面挑最关键的几个展开。检索质量、延迟、吞吐这三个，属于"性能三角"，多数团队只盯着它；但我更想先把第 6、7、8 项讲清楚------因为它们是决定"能不能活三年"的维度，恰恰是很多选型文章一笔带过的地方。
维度 6：成本------算的是三年，不是一个月
选型时最容易只看到服务器账单，忽略两笔更大的钱：人力 和迁移。
一个朴素的估算方法，把内存先算明白。向量索引常驻内存的粗算公式是：
内存 ≈ 向量数 × 维度 × 每维字节数 × 索引放大系数
举个可复核的例子：100 万条 × 1024 维 × 4 字节（FP32）= 约 4GB 原始向量，加上图索引结构放大 1.5 到 2 倍，内存落在 6 到 8GB。换成压缩量化（8bit 或乘积量化），能压到 1GB 上下，代价是召回率往下掉。这个"内存换召回"的权衡，直接决定了你要买多大内存的机器。
这里我必须说一句可能得罪人的话："成本贵十倍"这类标题，往往没有真算过账。 真正拉开差距的不是单价，是"要不要为此多养一套运维体系"。复用现有关系库的向量能力，把向量库纳入既有 DBA 的运维半径，在百万级以内的场景里，通常是总成本最低的一条路。
维度 7：运维------迁移才是最大的隐性成本
向量数据库之间的迁移，没有关系库那样成熟的 ETL 工具链。embedding 要重算还是能搬、索引要重建多久、重建期间服务断不断，这三问在选型阶段就要有答案。
我的经验判断：选型阶段多花一周做 POC，胜过上线后花一个月做迁移。 判断一个方案好不好运维，不看它的功能页，看三件事------备份恢复怎么做、监控指标全不全、扩缩容要不要停机。
维度 8：生态与合规------信创场景的硬门槛
对金融、政务、能源这些强监管行业，合规不是可选加分项，是准入线。私有化部署、国密加密、等保适配、国产 CPU/OS 环境跑得起来，这些条件会直接划掉一批方案。
这也是我想单独点一句的地方：在"国产数据库统一管理"这条要求下，关系型数据库原生提供向量能力 的路线有天然优势。以金仓数据库（KingbaseES）为例，它的产品体系里有 KES Vector 向量能力，走的是"在关系库上原生支持向量"的路线，好处是向量数据能复用关系库的 ACID 事务、SQL 能力和既有运维体系------对"既要存业务数据、又要做向量检索"的信创项目，这意味着少引入一套异构系统。
三、索引是选型里隐藏的分水岭
这是很多文章没讲透、但选型时绕不开的一块：同样一批向量，选不同的索引，内存和召回能差出一个数量级。
先说前提。向量检索在大规模下不可能用暴力搜索（复杂度随数据量线性上涨，亿级直接不可行），必须用近似最近邻（ANN）索引。主流的两种思路：
- HNSW（分层可导航小世界图）：把向量组织成多层图，查询走图就能快速逼近结果。特点是查询快、内存占用高、构建慢。
- IVF（倒排文件）：先聚类分桶，查询时只进少数几个桶精算。特点是构建快、内存低，更适配带过滤条件的检索。
IVF 再往下分三档，本质是"用召回率换内存"的刻度：
| 变体 | 压缩方式 | 内存 | 召回 | 适用 |
|---|---|---|---|---|
| IVF_FLAT | 不压缩 | 高 | 最准 | 内存充足、追求精度 |
| IVF_SQ8 | 8bit 标量量化 | 约 1/4 | 轻微损失 | 平衡档 |
| IVF_PQ | 乘积量化 | 可压到 1/8 甚至更低 | 损失加大 | 亿级、内存受限 |
两个关键参数：nlist 决定分桶的粗细，经验起点取 √N（N 为向量数）；nprobe 决定查询进几个桶，调大召回更好但更慢。这两个数的取舍，就是"召回-延迟-内存"三角在工程上的落脚点。
还有一个必须点破的坑：HNSW 在"带过滤条件"的检索里会退化。 图索引的边一旦被过滤条件切断，候选集变小，召回掉得比预期狠。如果你的业务大量依赖"按时间、按状态、按权限过滤后再做语义检索"，选型时要把"高过滤比例下的召回"当成一项专门指标去测，而不是默认它没事。
四、把 8 个维度合成一张决策表
维度拆完了，落到决策。我给一张按"场景"出发的表，比按"产品名"出发更有用：
| 你的场景 | 建议路线 | 为什么 |
|---|---|---|
| 百万级以内 + 已有关系库 | 关系库原生向量能力 | 少一套系统，运维与事务天然统一 |
| 亿级 + 毫秒级延迟 | 专用向量库（分布式） | 内存与吞吐需要专门架构 |
| 零运维 + 快速验证 | 云托管向量服务 | 开箱即用，把精力留给业务 |
| 强监管 + 信创环境 | 国产数据库原生向量能力 | 合规、私有化、统一运维一条龙 |
| 向量只是辅助、核心是结构化数据 | 关系库原生向量能力 | 别为次要功能引入主力系统 |
这张表想表达的核心判断是：选型不是"找最强的那个"，而是"找代价最小、又刚好够用的那个"。 追求"最强"往往意味着为用不上的能力持续付费。
五、选型里最常见的四个错误
- 只看 Benchmark 不看场景。 评测用的是理想化数据集，你的数据分布、查询模式、并发量跟它不一样。结论只有一个：用你自己的数据做 POC。
- 过早为"未来规模"买单。 一上来就上分布式，数据量却长期停在百万级。分布式带来的复杂性和开销，可能让单机方案反而更快。按未来 6 到 12 个月的增长规划就够了。
- 忽略混合检索。 纯向量检索在生产里几乎不够用，"按时间范围筛""按状态过滤""关键词精确匹配"这些需求迟早会来。确认方案支持混合检索再拍板。
- 低估迁移成本。 前面说过，向量库迁移没有成熟 ETL。一旦选定，切换成本极高，选型阶段值得多花一周验证。
六、常见问题 FAQ
Q1：向量数据库选型最该先定什么？
先定数据规模和延迟要求，这两个是硬约束，直接决定架构形态。
Q2：数据量小，还用得上专用向量数据库吗？
百万级以内且已有关系库，优先考虑关系库原生向量能力，性价比通常更高。
Q3：HNSW 和 IVF 怎么选？
追求极致查询性能、内存充足、过滤需求少选 HNSW；数据规模大、内存受限、过滤检索多选 IVF 系列。
Q4：向量压缩会影响召回率吗？
会。SQ8 损失轻微，PQ 压缩比越高损失越大，本质是内存与精度的权衡。
Q5：信创环境怎么选？
优先看私有化部署、国产 CPU/OS 适配、国密与等保支持，以及是否支持数据库原生向量能力。
结语
把这一篇收成三句话，给正在做决策的人：
- 先问"是否需要独立向量库"，再谈选型------这一步筛掉一半的错误；
- 用 8 个维度做体检，别只盯着性能三角------成本、运维、合规才是决定能不能活三年的；
- 索引用"场景"去匹配，用 POC 去验证------任何评测报告都替代不了你自己的数据。
一句话收尾：向量数据库没有"最好的"，只有"代价最小又刚好够用的"。选型的成熟，是从"追最强"走到"求匹配"。
本文基于公开信息独立撰写，不代表任何厂商立场。
李白客，信创行业独立观察者。关注数据库、AI 基础设施与国产化替代。