选型与前沿：到底用哪个，2026 在变什么

数据基线：pgvector 0.8.0 · pgvectorscale · Milvus 2.6 · Qdrant 1.15  |  前沿截止：2026-06  |  性能数字引自公开基准（VectorDBBench / ann-benchmarks / 厂商博客），「未本地复现」

▸产品全景：一张对比矩阵

向量检索的产品分两层：一层是能直接当数据库用的服务（有持久化、CRUD、过滤、网络服务化），另一层是只提供检索算法的库（FAISS 是典型，没有持久化也没有过滤）。02 章已经讲过这条分界线——索引（HNSW / IVF / DiskANN）只是其中一个零件，一个向量数据库还要在零件外包上写入路径、元数据过滤、分布式分片。下表只列能进生产候选清单的选项，按「类型 / 甜区 / 主要权衡」对齐：

▸选型启发式：从约束反推，而不是从产品挑

选型不是给产品打分排名，而是把项目的硬约束（数据量、一致性要求、运维预算、规模上界）依次代入，让候选集自己收敛。下面这组规则按「最常命中」到「最特殊」排列：

• 已在跑 Postgres，且向量 <10–50M、需与业务数据强一致 JOIN → 先上 pgvector。理由是少一个服务、有 ACID 事务、不会产生孤儿向量。不到这条线，「这一步就不需要专用向量库」——这是本章最该带走的一句话。
• 过亿 / 十亿级、高 QPS、要 GPU 摄入 → Milvus / Zilliz。这是它的分布式组件和 GPU 索引真正回本的区间。
• 复杂 metadata 过滤是核心需求（多租户隔离、范围查询、地理过滤）→ Qdrant。它的 filtered-HNSW 把过滤条件织进图遍历（03 章讲过：pre-filter 召回不掉、post-filter 结果不缩水），是这类场景的强项。
• 要开箱即用的 hybrid → Weaviate（稀疏 + 稠密 + 融合内置）；或者已经有 ES / OpenSearch，就直接 bolt-on，省一个服务。
• 零运维、要快速上线、规模可控、预算够 → Pinecone。但要算账：规模一大，转自托管能省约 75%——50M 向量自托管月成本约 $835，Pinecone 同规模 $3.2k+。
• 原型 / 本地 demo → Chroma 或 LanceDB；如果只要进程内的检索算法、根本不要一个数据库 → FAISS。

▸你是否真的需要专用向量库

这是本章的核心辨析，也是面试里区分「装过库」和「做过选型」的分水岭。默认反应往往是「上 RAG 就装个向量数据库」——但 2026 的共识恰恰相反：专用向量库不是必选基础设施，而是一个要被约束触发的选项。把决策拆成五个依次收紧的问题：

• 数据量多大？百万到几千万级，单机方案（pgvector / Qdrant 单节点）绰绰有余；过亿才需要考虑分布式。
• 已经在跑 Postgres 或 ES 吗？在跑，就优先 bolt-on（pgvector / ES kNN），把「新增一个服务」的成本算进去。
• 过滤有多复杂？只是「按 user_id 过一下」，谁都能做；要多租户 + 范围 + 地理的复合过滤，才值得为 Qdrant 的 filtered-HNSW 买单。
• 一致性要求多高？要和订单 / 文档表做事务性强一致 JOIN，pgvector 的 ACID 是专用库给不了的——这条经常单独就把答案定死。
• 规模上界在哪？两年内会不会冲到十亿？会，就要么现在选 Milvus，要么留好迁移路径（先 pgvector，预留导出与切换方案）。

下面把这五个问题画成一棵可执行的决策树。注意它的入口不是「选哪个产品好」，而是「能不能不引入新服务」——只有当约束逼着往下走，才一层层升级到更重的方案。

▸2026 前沿：分三桶看，别把旧法当新知

这个领域变化快，但不是每一处都在变。把当下状态分成三桶——已沉淀（STABLE）照着教没问题、仍在变（IN FLUX）要盯日期、已被取代（SUPERSEDED）别再写进新方案。下面每条都带时间锚点，因为「2026 的前沿」半年后就会移动。

STABLE · 已沉淀的稳定内核

• HNSW 是默认索引——除非数据规模或内存预算逼你换 IVF / DiskANN（02 章），起手用 HNSW 不会错。
• pgvector 0.7.0（2024-04）的存储与量化原语：halfvec（半精度，存储减半）、sparsevec（稀疏向量）、binary_quantize()（二值量化）；以及 0.8.0（2024-10）的 iterative index scans——解决了过滤后结果不足时自动继续扫描的老问题。
• MRL（Matryoshka 表示学习）与可截断维度：text-embedding-3（2024-01）的 dimensions 参数让一个模型输出可按需截断，256 维即超过旧 ada-002 的全维质量。「维度越高越好」已不成立。
• hybrid 检索是标配：稠密 + 稀疏 / BM25 + RRF 融合 + rerank，03 章已作为生产基线讲过。
• 量化分层：scalar 量化约 4× 压缩、binary 约 32× 压缩，配合用原始向量做 rescore 兜底召回——已是内存优化的标准配方。

IN FLUX · 近 6–12 月还在变（盯日期）

• late-interaction / 多向量检索：从 ColBERT 出发，演进到 ColPali / ColQwen 处理视觉文档（直接对页面图像做 token 级匹配，跳过 OCR）。Qdrant 原生支持 multivector，Weaviate、Vespa 亦已跟进。
• GPU 索引 cuVS / CAGRA：Milvus 2.6（2025-08）转向 GPU 建图 + CPU 查询的分工，并引入 RaBitQ 量化，报告省约 72% 内存——但查询端因成本退回 CPU，说明「全程 GPU」尚未在生产经济上跑通。
• 更细粒度量化：Qdrant 1.15（2025-07）的 1.5-bit / 2-bit 量化，在 binary 的激进压缩和 scalar 的召回之间补了中间档。
• 存算分离的 serverless 设计：turbopuffer 用 S3 做底座（Cursor 采用其检索）、LanceDB 嵌入式列存、Pinecone serverless——向量主体落对象存储，内存只做缓存。pgvectorscale 的 StreamingDiskANN + SBQ 是 Postgres 侧的同向探索。
• embedding 换代：Gemini Embedding 001（MTEB 约 68，居榜首）、Cohere embed-v4、Voyage voyage-3-large，开源侧 Qwen3-Embedding-8B 多语种第一。榜单半年一换，选型时按当下 MTEB 重测，别认死一个名字。

SUPERSEDED · 已被取代，别再教

• text-embedding-ada-002 → text-embedding-3（更高质量 + 可截断维度）。
• 裸 float32 全维存储 → halfvec / 量化（同等召回下内存数倍下降）。
• 纯 IVFFlat → HNSW（IVFFlat 仍有批处理场景，但默认不再用它）。
• dense-only 检索 → hybrid + rerank（纯稠密在精确词 / 专名 / 代码上召回不稳）。
• 「向量数据库是必选基础设施」的绝对论 → 按需选型。2026 共识：小规模 + 长上下文 + lexical 检索在不少场景可替代专用库。

附：RAG vs long-context 之争的理性立场

长上下文窗口变大后，「RAG 是不是要死了」反复被问。当下理性立场：RAG 没死，但 naive chunk pipeline 过时了。它正演进为 agentic retrieval——把 hybrid + rerank + CRAG / Self-RAG / HyDE 嵌进 agent 的推理循环，检索不再是一次性预处理，而是 agent 可反复调用的工具。long-context 在答案质量上略胜，但 token 成本上 RAG 仍便宜 8–82×。结论是混合，不是取代：用长上下文承载少量精排结果，用检索把候选从海量压到少量。