RAG 应用里向量数据库怎么选：架构定位与 8 个选型要点

一篇关于向量数据库选型的独立分析。不写通稿，只说真话。

在 RAG（检索增强生成）架构里，向量数据库扮演的是"记忆层"——大模型负责"想"，向量库负责"记"和"找"。

所以向量数据库选型的第一性原理，不是看产品榜单，而是先搞清楚：它在你的架构里到底要扛什么。 这篇文章从架构定位出发，拆成 8 个选型要点，最后落到一张速查表。

一、向量数据库在 RAG 架构里的位置

一套典型的 RAG 链路，大致四步：

1. 切分与向量化：把知识文档切块，用 embedding 模型转成向量；
2. 写入向量库：向量连同原文、元数据一起落库；
3. 检索：用户提问转成向量，去库里找最相近的片段；
4. 生成：把检索到的片段拼进提示词，交给大模型生成答案。

向量数据库卡在第 2、3 步之间，是整个链路里"检索质量"和"响应延迟"的主要决定者。理解了这一点，选型要点就都有了出处。

二、从架构定位推出 8 个选型要点

这 8 个要点里，多数团队只盯着 2、5、6 三项性能指标，却忽略了 3、4、7、8——而恰恰是这四项，决定了方案"能不能活三年"。

三、索引选择与内存规划

大规模向量检索必须用近似最近邻（ANN）索引，主流两条路线：

• HNSW（图索引）：查询快、内存高、构建慢，适合延迟敏感、过滤需求少的场景；
• IVF（聚类分桶）：构建快、内存低、更耐过滤，适合大规模、过滤检索多的场景。

内存规划上有个粗算公式，选型阶段就该算清：

内存 ≈ 向量数 × 维度 × 每维字节数 × 索引放大系数

以 100 万条 × 1024 维 × 4 字节（FP32）为例，原始向量约 4GB，加图索引放大 1.5 到 2 倍，落到 6 到 8GB；改用 SQ8 量化能压到 1GB 上下，代价是召回轻微下降。

四、部署形态三选一

向量能力的落地，大致三条路线：

• 专用向量数据库：亿级规模、毫秒级延迟、向量是核心能力时选；
• 云托管向量服务：零运维、快速验证，适合把精力留给业务本身的团队；
• 关系型数据库原生向量能力：百万级以内、已有关系库时，性价比最高——少一套系统，事务与运维天然统一。

这里想强调第三条路线：在信创与合规场景下，它往往是被低估的选项。以金仓数据库（KingbaseES）为例，它的产品体系里有 KES Vector 向量能力，走"在关系库上原生支持向量"的路线，向量数据能复用关系库的事务、SQL 与既有运维体系。对"既要存业务数据、又要做智能检索"的项目，这意味着少引入一套异构系统，架构更简单，迁移成本也更低。

五、信创与合规考量

对金融、政务、能源这类强监管行业，私有化部署、国密加密、等保适配、国产 CPU/OS 环境能跑，是准入门槛而非加分项。选型时把这条线放在第一位，先筛掉不满足的方案，再谈性能比较，能省掉大量返工。

六、选型要点速查表

结语

收成三句话：

1. 选型从架构定位出发——先搞清楚向量库在你的 RAG 链路里扛什么；
2. 8 个要点别只盯性能三项——索引、过滤、成本、合规才是长期胜负手；
3. 用自己的真实数据跑 POC——把过滤、增量、删除一起测进去，别只测静态查询。

一句话收尾：向量数据库选型的成熟，是从"追最强"走到"求匹配"。

本文基于公开信息独立撰写，不代表任何厂商立场。
李白客，信创行业独立观察者。关注数据库、AI 基础设施与国产化替代。