第 4 章 — 选对向量数据库
LLM Primer III: Enhancing Enterprise AI with RAG 章节走读的第四篇。RAG 系统里长得最快、上量后最贵、把团队锁得最死的那一层 — 用技术指标比着选,用运维条件决定。
这一章为什么存在
向量数据库是检索系统的存储层,选这件事是多轴决策 — 性能、数据驻留、团队的运维形态、系统寿命内的总拥有成本。选错锁定的是好几年,因为把十亿条嵌入从一套系统挪到另一套,是任何团队都不会轻易动手的工程。技术对比有用,但选型常常被技术对比绕开的那三根轴决定:数据被允许住在哪里、团队能运维什么、这套系统在它一生里花多少钱。
4.1 架构:专用 vs 扩展
第一个决定,常常没人把它点出来:是新引入一套为向量负载量身打造的系统,还是在团队已经运维着的某套系统上加一层向量。专用 数据库 — Pinecone、Qdrant、Milvus、Weaviate、Vespa — 从索引向外造起。查询规划器、存储布局、复制模型、API 都是为高维向量近似最近邻而设的。性能天花板更高,尤其在「过滤 + 向量」的混合查询上;但又多一套要运维的系统。
扩展 这一路 — pgvector、Elasticsearch dense_vector、MongoDB Atlas Vector Search、Redis with RediSearch — 给团队已经在跑的数据库加上向量搜索。没新的认证、没新的备份流程、没新的值班轮换、没新的补丁节奏。性能天花板由宿主架构决定,通常远高于数千万向量量级以内的应用所需要的。这个选择很少是纯性能问题。它更常是「团队愿意把运维预算花在哪里」的问题 — 一个跑一台 Postgres 的团队,不会想再多跑一套数据库;一个跑十种数据服务的团队,再加一种眼也不眨。
4.2 托管派的主角:Pinecone 与 Vertex
Pinecone 是托管向量数据库里的标杆。运维简单、延迟可预期、SDK 成熟,还有一档无服务的方案 — 把存储和计算解耦,按真实用量而不是预留容量计费。新部署的合理默认,除非工作负载特别能从预留容量里受益。代价是任何托管专有系统都要付的架构锁定 — 嵌入原则上可移植,但导出再重建索引的成本是真实的。Vertex AI Vector Search 是 Google 的方案,底层是支撑 Google 自家大规模相似搜索的 ScaNN 库。规模上限更高,与 GCP 其余部分整合得严丝合缝 — 嵌入模型、IAM、Cloud Monitoring — 代价是对单云的战略承诺也跟着。Azure AI Search 对死忠微软栈的团队占同样的位置。三家平台原生选项之间的取舍通常跟着已有的云承诺走,这是合理的 — 前提是团队验证过规模和驻留。
4.3 开源派:Qdrant、Milvus、Weaviate
开源这一档是给那些要自己掌控基础设施 — 因为成本、驻留或战略考量 — 并且有运维分布式系统能力的团队。Qdrant 是最小最专的:Rust 写的,单二进制部署,为低延迟向量检索调优,过滤和量化支持都很到位。亲和度够,几分钟就能跑起来;运维占地要尽量小的场景,就选它。Milvus 是最大、最面向企业的 — 云原生架构,计算、存储、元数据分离,在这一档里规模天花板最高(十亿级语料、GPU 加速索引、分层存储)。运维复杂度也大,Zilliz Cloud 把这件事缓了缓。Weaviate 夹在两者中间 — 比 Qdrant 多功能,比 Milvus 简单,自带嵌入、重排、多租户模块。与其说是一座搜索索引,不如说是一座搜索平台。三家核心都是 Apache 协议,有付费托管;基准里彼此差的只是一个小常数。决定的是「合不合」,不是「跑得快」。
4.4 嵌入式与 Postgres:Chroma 与 pgvector
大多数真实的 RAG 部署,是每秒几十次查询,在几十万向量上服务,而不是每秒数百万次在十亿条上。这种负载,正确的工具住在应用进程里或者紧挨着应用进程跑。Chroma 是嵌入式选项 — 默认进程内、持久化到本地磁盘,最简单的场景不需要任何配置。原型、自带数据的工具、装得下一台机器的生产部署,选它都合理。pgvector 把向量类型、距离运算符、HNSW/IVFFlat 索引加进 Postgres。在配置得当的主机上,大约到一千万向量这一档,pgvector 是有公信力的生产选择,也是已经跑 Postgres 的团队最省运维的一档。向量搜索变成对一张已有 ORM 认得的表的 SQL 查询;和结构化元数据 join 是一等公民。这两档隐藏的好处是,它们把「改变主意」这件事的成本压得很低 — 真要迁到分布式系统,这条路是有边界的。
4.5 驻留、运维、成本 — 真正定胜负的那三根轴
三根运维轴值得专门点名,因为生产选型真正是在这里被定下的。数据驻留 在任何技术对比有意义之前,就已经把候选名单缩小了。欧盟数据保护、金融业监管、主权云承诺 — 这些约束不可谈判,问任何一家厂商的第一个问题就是:你们支持哪些区域、对数据处理签的是什么合同。一个特别容易踩的坑:嵌入是派生数据,但在大多数监管框架下仍然算个人数据 — 因为它能被反演,或者能用相似搜索把原文捞回来。一份覆盖原始文档却对嵌入语焉不详的合同,是不完整的。
运维形态 说的是团队自己的能力。三个工程师跑一个应用服务的团队,该选对运维面贡献最小的那一档 — pgvector、托管的 Pinecone 或 Qdrant Cloud、嵌入式 Chroma。三十个工程师的团队,能为了成本和能力的优势,吸收一套开源分布式系统的复杂度。错处在于挑了一套与团队真实能运维的能力不匹配的系统。总成本 在系统寿命内,包括预置、监控、备份、恢复演练、容量规划、升级工作、值班时间分摊。诚实的提法是问三档成本 — 当前负载、10 倍、100 倍 — 因为曲线的斜率和起点一样要紧。
第 4 章接下去会怎么走
向量数据库决定存储层能装下什么、能多快被查询、能支持什么样的过滤和元数据样式。这些性质里没有一个单独决定检索质量 — 它们决定的是上面能搭出什么。上面要搭的,是检索流水线,这里收益开始叠加:稠密向量加 BM25 的混合搜索、跨异构检索器的 reciprocal rank fusion、cross-encoder 重排,以及那一层架在「用户怎么问」与「文档怎么答」之间的查询理解。
明天 — 第 5 章:搭一条检索流水线。稠密向量和关键词检索怎么经 reciprocal rank fusion 合在一起、cross-encoder 重排怎么把剩下的质量差关上一大半,以及那一层查询理解的工作。
