为何生产级 RAG 正在超越专用向量数据库？
探讨为何独立向量数据库在实战中的 RAG 系统中逐渐失势，以及混合检索、过滤与统一数据层如何重塑这一技术架构。
来源: The Vector Database Era Is Ending. Here’s What Production RAG Is Moving Toward
实际生产环境中使用的检索流程很少是单一机制，现代系统通常会结合多种方法：
- 密集检索以捕捉语义相似性
- 稀疏检索用于匹配精确术语
- BM25算法用于词汇评分
- 混合搜索以提高召回率
- 重排序以提升精确度
- 针对复杂或模糊查询的改写功能
- 对检索结果的自检与验证机制
- 用于处理相互关联知识的图谱检索
- 分多步获取信息的智能工作流
本文将探讨为何在许多实际应用中，以传统向量数据库为核心的检索增强生成设计逐渐显露不足。
如果 RAG 对您来说是个新概念，那么在探讨现代系统如何在其基础上进一步发展之前，先了解一些基础知识是很有必要的——比如 RAG 的定义、LLM 为何会产生幻觉、RAG 工作流通常是如何构建的，以及密集检索与稀疏检索之间的区别，这些都是不错的切入点。
长期以来，用于检索增强生成任务的架构几乎已成为标准配置：
LLM → 嵌入模型 → 向量数据库 → 检索到的上下文 → LLM
如果要在实际项目中构建一个成熟的 RAG 产品，人们通常期望您选择专门的向量存储服务——比如 Pinecone、Weaviate、Qdrant、Milvus、Chroma 或类似的产品。
但现实中的生产应用正在重新定义这个问题。
现在重点已不再是：
“我应该选择哪种向量数据库？”
更关键的问题变成了：
“我真的需要专门的向量数据库吗？”
这种提问方式的转变意义重大。
最近的行业报告和基准测试显示，越来越多的团队将向量搜索集成到他们已有的基础设施中——带有pgvector扩展的PostgreSQL、Elasticsearch以及各种统一数据平台都是常见的选择。
这并不意味着向量数据库会一夜之间消失。
相反，它表明将独立的向量数据库视为默认的架构选择越来越难以被合理化。
而这种压力恰恰出现在人工智能工程中最为关键的部分：
生产成本、运营开销、过滤能力、数据一致性以及整体检索质量。
1. 向量数据库解决了真正的难题
首先回顾一下向量数据库为何会流行起来会有所帮助。
传统数据库可以轻松处理此类查询：
SELECT *
FROM documents
WHERE category = 'insurance'
AND effective_date > '2025-01-01';
但语义搜索则涉及完全不同类型的查询：
“找出含义与此查询相近的文档。”
要回答这类问题，需要将文本转换为数值向量：
"How do I file a health insurance claim?"
↓
Embedding Model
↓
[0.021, -0.183, 0.492, ...]
之后，数据库会执行近似最近邻搜索。
从概念层面来看，其流程如下：
Query Vector
│
▼
┌─────────┐
│ ANN │
│ Index │
└────┬────┘
│
├── Document A 0.91
├── Document B 0.87
├── Document C 0.84
└── Document D 0.81
当需要处理数百万甚至数十亿个向量时，与暴力扫描相比，HNSW或IVF这类专门的索引方法能够极大提升处理速度。
因此最初的设想完全合乎逻辑：
设计一种专为高效检索向量而打造的数据库。
对于某些特定类型的工作负载，这一思路至今依然适用。
问题则出在后续的发展中。
2. 实际应用中的RAG远不止向量查找这么简单
RAG系统的早期原型通常遵循简单的流程：
Question
↓
Embedding
↓
Vector Search
↓
Top 5 chunks
↓
LLM
但真正的生产环境系统几乎从不会如此简单。
实际系统中通常会呈现更为复杂的结构：
┌── Metadata filters
│
├── Tenant isolation
│
Query → Rewrite → Embed ─┼── Keyword search
│
├── Vector search
│
├── ACL filtering
│
├── Recency
│
└── Reranking
│
▼
LLM
此时，数据库已无法仅通过简单的查询来回答问题：
“哪些向量与这个最接近？”
它需要回答的问题要复杂得多：
“哪些文档在语义上相关、属于正确的客户、仍然有效、该用户可以访问，并且同时满足这些额外的筛选条件？”
这样的要求彻底改变了整个问题的性质。
3. 运行两个数据库的隐性成本
假设您的公司已经在使用 PostgreSQL。
您的核心应用数据都存储在那里：
PostgreSQL
users
customers
policies
claims
documents
permissions
metadata
随后又添加了一个向量数据库：
PostgreSQL Vector DB
────────── ──────────
Documents ───────► Embeddings
Users Metadata
Permissions ANN index
Claims
从这时起，更新一份文档可能就需要将变更同步到两个独立的系统中。
典型的更新流程如下：
Document Updated
│
├──────────────► PostgreSQL
│
└──────────────► Embedding Pipeline
│
▼
Vector DB
这种设置会带来同步方面的诸多问题。
请思考以下情况会发生什么：
- 有文档被删除
- 客户的权限发生变更
- 策略有了新版本
- 元数据被更新
- 有租户从系统中移除
- 嵌入模型本身被更换
到那时，您实际上已经在检索层中引入了分布式数据一致性问题。
2026年一篇探讨RAG统一数据层的研究论文指出，正是这种关系型存储与向量存储之间的分离导致了数据过时、租户隔离失败以及查询组合过于复杂等问题。他们在评估中采用的PostgreSQL结合pgvector的设计在过滤检索任务上取得了显著提升，同时消除了维护两个独立系统所带来的同步问题。
事实证明，这比争论某种ANN索引方法在原始速度上是否仅略胜另一种方法要重要得多。
4. “足够好”的向量搜索开始出现在你已使用的数据库中
这就是PostgreSQL发挥作用的地方。
得益于pgvector，PostgreSQL表可以同时存储常规列和嵌入向量：
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
content TEXT,
metadata JSONB,
embedding VECTOR(1536)
);
你可以直接针对同一个表执行相似度查询：
SELECT
id,
content,
embedding <=> query_embedding AS distance
FROM documents
WHERE tenant_id = 123
ORDER BY embedding <=> query_embedding
LIMIT 10;
这里重要的并非 PostgreSQL 具备向量搜索功能，而是这种向量搜索能够与应用程序的其他数据一同处理。
你可以在单个查询、同一个系统中将多种数据结合使用：
SQL filtering
+
Vector similarity
+
Transactions
+
Access control
+
Metadata
对于运行生产系统的团队而言，这无疑是一个极具吸引力的方案。
2026年发布的多篇生产环境对比研究指出，只要 PostgreSQL 已经被纳入技术栈，对于许多 RAG 应用场景而言，pgvector 都是首选方案——尤其是当向量数量处于中等水平而非海量时。
5. 成本问题比看上去更为重要
成本可以说是促使团队重新考虑这种架构的最主要原因。
假设你的技术栈已经包含类似以下组件：
PostgreSQL
$300/month
为该架构添加向量功能其实可以很简单：
Existing PostgreSQL
+
pgvector
+
additional CPU/RAM
与之相比，另一种方式是在 PostgreSQL 之外单独运行托管向量服务：
PostgreSQL
+
Pinecone
+
network traffic
+
index management
+
monitoring
+
data synchronization
对于某些工作负载而言，两者的差距并不明显。
但随着时间推移，架构上的额外开销会逐渐累积。
多项2026年的成本研究指出，在中等负载情况下，托管向量服务与基于 PostgreSQL 的向量搜索之间存在明显的价格差异。某项基准测试显示，Pinecone的每条查询成本明显更高，而pgvector则需要额外的调优才能达到类似的处理效率。
由此得出的结论并非：
"pgvector始终是更便宜的选择。"
这种说法并不适用于所有情况。
真正的结论是：
最便宜的向量数据库往往就是你已经在使用的那个。
6. 成本并非真正制约这一模型的因素
现实情况则没那么乐观。
如果向量数据库的唯一问题只是价格，解决方式其实很简单：降低成本。
但实际在生产环境中使用这些系统的团队面临的是另一个更为根本的问题。
仅依靠相似度搜索往往并非合适的检索方法
举个这样的例子：有客户想了解在明年年初的某个特定日期起，某个州的高级订阅套餐适用哪些取消条款。
这类问题实际上同时包含多个不同的检索信号：
Semantic meaning
+
Exact terms
+
Customer segment
+
Geography
+
Effective date
仅靠向量搜索可能只能理解句子的大意，却完全忽略其中隐含的精确约束条件。
正因如此，当前的RAG系统越来越倾向于将多种技术相结合：
BM25
+
Dense Retrieval
+
Metadata Filtering
+
Reranking
而不是仅仅依赖语义相似度。
一项针对语料库规模变化时检索质量的研究——比较了词汇法、密集向量法、图基方法和智能代理方法——发现BM25的表现极为出色，在所有测试过的语料库规模范围内都处于低成本的帕累托前沿。
仅这一结果就足以让RAG工程师们深思。
人们花费多年时间来优化语义检索技术。
然而基于关键词的搜索实际上从未过时。
7. Elasticsearch已成为可靠的RAG后端
这一趋势进一步削弱了独立向量数据库的合理性。
搜索引擎长期以来一直负责处理：
- 倒排索引
- BM25评分算法
- 过滤功能
- 聚合操作
- 多维度搜索
- 文本相关性排序
- 分布式搜索
现在他们也支持向量搜索了。
因此，团队不必再沿用以往的架构设计：
PostgreSQL
+
Vector DB
+
Search Engine
而是可以转向类似这样的方案：
Search Engine
┌───────────────┐
│ BM25 │
│ Vector Search │
│ Filters │
│ Ranking │
└───────────────┘
2026年的一项社区基准测试将pgvector与Elasticsearch、Qdrant、Pinecone和Weaviate进行了对比，测试内容不仅包括原始的近似最近邻查询延迟，还涵盖了过滤搜索、混合搜索、写入/更新行为以及在实际生产环境条件下的并发访问情况。
这才是实践中真正重要的基准测试类型。
没人会因为余弦相似度数值比竞争对手慢12%就收到紧急通知。
人们收到通知是因为：
有客户看到了错误的文档。
8. 真正的竞争发生在过滤检索领域
这或许是当前RAG设计中最重要的架构见解。
想象一个包含1亿个向量的数据集。
某个用户只能查看符合以下条件的结果：
tenant = ACME
region = US
department = legal
document_status = active
一种简单的处理流程可能会这样操作：
Vector Search
↓
Top 100
↓
Metadata Filtering
↓
Top 10
但等到之后应用过滤条件时，那些真正重要的文档可能早已被排除，因为它们从未进入向量搜索步骤最初筛选出的候选列表中。
现代实际应用中的检索越来越需要这些过滤约束来塑造检索过程本身，而不仅仅是事后进行清理。
换句话说，你真正想要的查询更像是这样：
Semantic Similarity
+
Structured Filtering
+
Authorization
+
Keyword Matching
+
Ranking
从根本上说，这是一个数据库查询优化难题。
它并非单纯的向量搜索问题。
9. 向量数据库也面临着自身的“统一数据层”压力
数据库工程领域数十年来一直在努力将不同类型的数据整合到单一系统中。如今，人工智能正在进一步推动这种整合趋势。
其形成的架构大致如下：
Unified Data Layer
│
┌───────────────────┼───────────────────┐
│ │ │
Relational Vector Search
│ │ │
SQL / joins ANN/HNSW BM25
│ │ │
└───────────────────┼───────────────────┘
│
Graph
│
Relationships
并且有可能扩展为类似这样的结构：
RAG Query
│
▼
Query Planning Layer
│
┌────────────┼────────────┐
▼ ▼ ▼
Vector BM25 SQL
Search Search Filters
│ │ │
└────────────┼────────────┘
▼
Reranker
│
▼
LLM
这与真实企业系统中的数据检索机制更为相似，远比独立的向量存储更贴近实际应用场景。
当前数据库系统领域的研究正在积极探索能够将向量相似度搜索、图遍历和关系过滤作为协同操作来执行的引擎，而非将其视为独立的、顺序进行的检索步骤。这一方向代表了数据检索基础设施设计上的重大变革。
10. Pinecone、Qdrant和Milvus已经成熟了吗？
远未成熟。
这部分论点需要更细致的阐述。
在某些情况下，专为向量数据库设计的方案仍是最佳选择。
当你的向量集合规模极大时。 如果你面临的情况是：
500M+
1B+
10B+ vectors
且向量检索是你基础设施的核心功能，那么专用系统其复杂的结构也是合理的。
当你需要极高的查询处理速度时。 如果必须以极快的速度处理大量向量查询：
Millions of queries
per second
这实际上已成为你的产品核心，此时将所有操作都通过通用事务型数据库来完成并不现实。
当你需要高级的近似最近邻算法调优时。 专用平台能让你对HNSW、IVF、量化处理、分片、复制、分布式近似最近邻搜索以及GPU加速等功能进行精细控制。
当您需要基础设施隔离时。将检索工作负载与核心事务系统分开，是一个经过深思熟虑的明智选择，这样您的 AI 功能就不会成为数据库竞争的根源。
11. 真正正在消失的是什么
并非向量搜索本身，也不是嵌入技术、ANN 索引或 RAG 这种模式。
正在逐渐被摒弃的是一个特定的假设：
“每个生产环境中的 RAG 系统都需要专属的向量数据库。”
这一前提越来越难以成立。对于大多数应用而言，其架构可以简单地如下所示：
PostgreSQL
│
├── Relational Data
├── Metadata
├── Permissions
├── Full-text Search
└── pgvector
│
▼
RAG
而非这样：
PostgreSQL
│
├──── Vector DB
│
├──── Search Engine
│
└──── Cache
每新增一个系统就会增加一处运营接口，而每一处接口都可能是故障点。
12. 更实用的决策方法
不必纠结哪种向量数据库速度最快，而应根据自身的实际规模来考虑问题。
向量数量低于100万：保持简单即可。如果PostgreSQL已纳入您的技术栈，pgvector值得首先考虑。没必要仅仅因为教程推荐就引入另一款数据库。
向量数量在100万到5000万之间：此时真正的基准测试才显得重要。可比较以下选项：
pgvector
vs
Qdrant
vs
Weaviate
vs
Pinecone
vs
Elasticsearch
但评估时不仅要关注原始的top-k近似最近邻搜索速度，还需考虑p95/p99延迟、过滤后的召回率质量、混合检索性能、数据导入吞吐量、更新与删除功能表现、内存占用、运营成本以及故障恢复能力。
向量数量在5000万到5亿以上：此时专用系统就显得非常必要，包括：
Qdrant
Milvus
Pinecone
Weaviate
Elasticsearch
specialized vector infrastructure
现在的选择取决于 QPS 目标、向量维度、索引类型、复制需求、延迟预算、内存限制以及过滤复杂度。
向量数量超过 5 亿个：不要再依赖通用的“最佳向量数据库”排名，而应针对自身的工作负载建立专门的基准测试。在如此大规模的情况下，哪怕是小小的架构失误都可能导致基础设施成本高达数百万。
13. 当前的 RAG 技术栈状况
2023 年典型的 RAG 技术栈如下：
LLM
│
Embedding Model
│
Vector Database
│
Retriever
│
LLM
2026 年出现的实际应用技术栈则有了明显不同：
User Query
│
▼
Query Planner
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
BM25 Vector SQL
Search Search Filters
│ │ │
└─────────────┼─────────────┘
▼
Reranker
│
▼
Context Selection
│
▼
LLM
那张图所遗漏的恰恰很能说明问题：即认为向量搜索处于检索系统的核心位置。但实际上已非如此。向量搜索只不过是众多检索手段之一，而非整个系统围绕其运转的支点。
14. 对人工智能工程师的更广泛启示
这一模式反映了整个人工智能基础设施的发展趋势。
早期，业界往往为每项新功能都搭建独立的系统：
LLM → New database
Embeddings → New database
Vector search → New database
Agents → New orchestration layer
RAG → New retrieval layer
然而最终，开发团队开始提出一个更简单的问题：
“我们能否将其中一些功能合并起来？”
每新增一项服务都会带来：
More cost
More monitoring
More networking
More credentials
More failure modes
More backups
More synchronization
More operational knowledge
在基准测试中，专用工具往往表现更佳。
而在实际生产环境中，整合后的系统通常更具优势。
这正是为什么 PostgreSQL 如今在 AI 技术栈中成为如此具有吸引力的选择。
它不必是最快的向量引擎。
它只需要满足：
速度足够快、成本足够低、稳定性足够高，且集成度足够好。
对于大多数实际应用而言，这样的组合确实难以被超越。
15. 向量数据库并未消失——它们正在被重新定义
现实情况比简单的“向量数据库已过时”这种说法更为复杂。
预计该生态系统会形成三个主要层级。
第一层——内置向量搜索功能的数据库
PostgreSQL + pgvector
Elasticsearch
OpenSearch
other unified databases
这一层级适合那些希望减少系统数量的企业。
第二层——专为向量搜索设计的数据库
Pinecone
Qdrant
Weaviate
Milvus
当仅靠向量检索就需要独立的专用基础设施时，这种分层设计就显得合理了。
第3层 — 专业检索引擎
针对那些规模异常庞大或要求极高的工作负载：
GPU indexes
quantized indexes
distributed ANN
custom retrieval engines
hybrid vector/graph systems
这类需求并未消失。
它只是被拆分成了不同的层级。
最后思考
真正的变化并非仅仅在于PostgreSQL现在可以存储向量。
关键在于工程师们开始对整个检索流程进行优化，而不仅仅是其中的某一个环节。
在实际的RAG系统中，根本不在乎你的ANN基准测试报告什么：
8 ms
vs
12 ms
也不关心你的实际请求路径究竟消耗了多少资源：
40 ms → query processing
30 ms → network
80 ms → reranking
500 ms → LLM
向量数据库从来都不是最终目标。
检索质量才是关键。
一旦综合考虑所有因素——成本、延迟、过滤、安全性、一致性、维护难度以及相关性——再为另一个独立数据库找借口就变得极为困难。
因此，诚实的结论是：
向量数据库并未走向衰落。
正在发生一些更有趣的变化。
向量搜索正逐渐成为数据库的一项功能。
一旦某项技术从独立的产物类别转变为某种功能，其周边架构的一切都会发生永久性的改变。