Vector Database：从向量表示、近似最近邻搜索到生产级 RAG 架构的深度解析

Aug 5, 2026

1. 为什么需要 Vector Database？

传统数据库最擅长的是：

SELECT * FROM documents
WHERE category = 'Java'
AND author = 'Vincent';

这种查询依赖的是：

  • 精确匹配
  • 范围查询
  • 排序
  • 聚合
  • Join

但是 AI 应用经常面对另外一种问题：

“找出与这段问题语义最相关的 10 个文档。”

例如：

Query:

如何解决 Java 应用中的内存泄漏？

用户真正希望找到的可能是：

JVM Memory Leak Troubleshooting
Java Heap Dump Analysis
GC Tuning
OutOfMemoryError Investigation

这些文档可能根本没有出现：

“如何解决 Java 应用中的内存泄漏”

因此传统 SQL 的：

LIKE '%内存泄漏%'

并不能很好地解决问题。

Vector Database 的思路是：

Text
 ↓
Embedding Model
 ↓
Vector
 ↓
Vector Database
 ↓
Similarity Search
 ↓
Top-K Documents

核心变化是：

从“关键词匹配”转向“语义空间中的相似性匹配”。

2. Vector Database 的本质

理解 Vector Database，首先必须理解 Vector。

假设一个 Embedding Model 把一句话转换成 4 维向量：

"Java memory leak"
        ↓
[0.12, 0.83, -0.21, 0.47]

另外一句：

"JVM memory troubleshooting"
        ↓
[0.15, 0.79, -0.18, 0.44]

两个向量在空间中的位置非常接近。

因此：

Semantic Similarity
        ↓
Geometric Similarity

这就是 Embedding + Vector Search 的基础。

真实系统中的向量维度通常远高于 4，例如：

384
768
1024
1536
3072

因此 Vector Database 实际面对的是：

高维空间中的海量向量近邻搜索问题。

3. Embedding：向量数据库的入口

Vector Database 本身并不理解：

Java
Spring Boot
Redis
Kafka

它理解的是：

[0.123, -0.293, 0.831, ...]

Embedding Model 负责完成：

Human Language
      ↓
Semantic Representation
      ↓
Dense Vector

例如：

"Redis is an in-memory database"

        ↓

[0.021, 0.193, -0.823, ...]

Embedding 的核心思想是：

将语义相近的数据映射到向量空间中相近的位置。

因此：

"Java Memory Leak"
"JVM Heap Problem"

通常会比：

"Java Memory Leak"
"Pizza Recipe"

更加接近。

4. Vector Space

假设：

Java
Spring
Kafka
Redis
Pizza
Football

被映射到二维空间。

可以抽象成：

          Redis
            ●

       Java ●
          Spring ●

                         ● Kafka


                                   ● Pizza

                                               ● Football

虽然真实 Embedding 通常是数百或数千维，但数学原理类似。

Vector Database 的主要任务就是：

给定一个 Query Vector，快速找到空间中距离它最近的 K 个向量。

这就是：

K-Nearest Neighbor

简称：

KNN

5. 为什么不能直接暴力搜索？

假设数据库中有：

1,000,000 vectors

每个向量：

1536 dimensions

最简单的方法是：

Query Vector
      ↓
Vector 1   → calculate distance
Vector 2   → calculate distance
Vector 3   → calculate distance
...
Vector 1,000,000

复杂度近似：

O(N × D)

其中：

N = vector count
D = vector dimension

如果：

N = 100M
D = 1536

暴力计算会非常昂贵。

因此 Vector Database 的核心技术实际上是：

如何牺牲少量召回精度，换取数量级的搜索性能提升。

这就是：

Approximate Nearest Neighbor

6. ANN：Approximate Nearest Neighbor

ANN 的核心思想：

Exact Search
    ↓
100% 精确
    ↓
成本高

而：

Approximate Search
    ↓
接近最优答案
    ↓
性能大幅提升

例如：

1,000,000 vectors

暴力搜索可能需要比较：

1,000,000

个向量。

ANN 索引可能只需要探索：

几百
几千

个候选向量。

最终得到：

Top-K approximate nearest neighbors

这也是 Vector Database 的核心竞争力之一。

7. Distance Metric

向量数据库并不是简单判断：

vectorA == vectorB

而是计算两个向量之间的距离或相似度。

常见方法包括：

  1. Cosine Similarity
  2. Euclidean Distance
  3. Inner Product / Dot Product

8. Cosine Similarity

Cosine Similarity：

cos(A,B) =
(A · B) / (||A|| ||B||)

它关注的是：

两个向量方向是否相似。

例如：

A →
B →

方向非常接近：

cos(A,B) ≈ 1

如果方向相反：

cos(A,B) ≈ -1

在很多语义搜索场景中，Cosine Similarity 非常常见。

9. Euclidean Distance

欧氏距离：

d(A,B) =
sqrt(
    Σ(ai - bi)^2
)

二维情况下就是：

        B ●
         /
        /
       /
      ● A

两点之间的直线距离越小：

Similarity ↑
Distance ↓

10. Inner Product

内积：

A · B

对于归一化向量：

||A|| = ||B|| = 1

Cosine Similarity 与 Inner Product 在排序意义上可以等价。

因此很多系统会进行：

Normalize Vector
        ↓
Inner Product Search

来优化计算。

11. Vector Index 的核心

Vector Database 的性能，很大程度上取决于：

使用什么 Vector Index。

常见索引：

HNSW
IVF
PQ
IVF-PQ
DiskANN
ScaNN

其中工程实践中最重要的之一就是：

HNSW

12. HNSW：Hierarchical Navigable Small World

HNSW 是现代 Vector Search 中非常重要的一种 ANN 算法。

它的思想来源于：

Small World Network。

假设：

A —— B —— C —— D —— E

如果增加一些远距离连接：

A ───────── D
B ──────── E

那么从 A 到 E 就可以快速跳跃。

HNSW 就利用类似思想构建多层图。

13. HNSW 的层级结构

可以抽象成：

Layer 2:

A -------------------- G


Layer 1:

A ------- C ---------- G
          |
          D


Layer 0:

A -- B -- C -- D -- E -- F -- G

最高层：

节点少
连接跨度大

底层：

节点多
局部连接密集

搜索过程类似：

Top Layer
    ↓
快速定位大致区域
    ↓
Lower Layer
    ↓
逐渐缩小搜索范围
    ↓
Base Layer
    ↓
Top-K

14. HNSW 为什么快？

如果没有索引：

Query
 ↓
1M vectors
 ↓
calculate all distances

HNSW：

Query
 ↓
Entry Point
 ↓
Navigate Graph
 ↓
Candidate Nodes
 ↓
Top-K

因此不需要遍历整个数据库。

15. HNSW 的核心参数

HNSW 常见参数：

M
efConstruction
efSearch

M

表示节点连接数量的控制参数。

M 越大：

Graph Connectivity ↑
Recall ↑
Memory ↑
Build Cost ↑

efConstruction

控制构建索引时搜索候选数量。

通常：

efConstruction ↑
        ↓
Index Quality ↑
        ↓
Build Time ↑

efSearch

控制查询阶段搜索范围。

efSearch ↑
    ↓
Recall ↑
    ↓
Latency ↑

因此：

efSearch 是一个非常典型的 Recall / Latency Trade-off。

16. IVF：Inverted File Index

另一类重要方法是 IVF。

核心思想：

先把向量空间划分成多个 Cluster。

例如：

Vector Space

       Cluster A
     ● ● ● ●

                Cluster B
              ● ● ●

      Cluster C
    ● ● ● ● ●

                           Cluster D
                         ● ●

可以使用：

K-Means

建立：

Centroids

17. IVF Search

查询：

Query Vector
      ↓
Find nearest centroid
      ↓
Search selected clusters
      ↓
Top-K

例如：

100 clusters

查询时可能只搜索：

5 clusters

而不是：

100 clusters

这样就降低了计算量。

18. PQ：Product Quantization

当 Vector 数量非常大时，还有一个重要问题：

Memory。

假设：

100M vectors
dimension = 1536
float32 = 4 bytes

仅原始向量大约需要：

100M × 1536 × 4
≈ 614.4 GB

还没有计算：

Index
Metadata
Replication
Overhead

因此必须压缩。

这就是：

Product Quantization

19. PQ 的核心思想

例如一个向量：

[1,2,3,4,5,6,7,8]

可以拆成：

[1,2] [3,4] [5,6] [7,8]

然后每个子空间使用 Codebook 进行量化。

原始：

Float Vector

变成：

Compact Codes

从而显著降低：

Memory
Storage
Bandwidth

代价是：

Accuracy ↓

因此 PQ 本质上是：

用一定的精度损失换取巨大的存储效率。

20. HNSW vs IVF vs PQ

可以简单理解：

技术核心思想优势代价
HNSWGraph高 Recall、低延迟内存高
IVFCluster搜索效率高参数敏感
PQCompression节省大量内存精度损失
IVF-PQCluster + Compression大规模场景系统复杂度高
DiskANNDisk-based Graph超大规模工程复杂

因此实际系统通常不是简单选择一个算法，而是组合：

IVF + PQ

或者：

HNSW + Quantization

21. Vector Database 并不只是 Vector

一个成熟的 Vector Database 通常存储：

ID
Vector
Metadata
Document
Timestamp
Tenant
Category
Permission

例如：

{
  "id": "doc-001",
  "vector": [0.12, 0.38, ...],
  "text": "Spring Boot transaction management",
  "metadata": {
    "category": "Java",
    "author": "Vincent",
    "tenant": "enterprise-a"
  }
}

因此 Vector Database 实际上更接近：

Vector
+
Metadata
+
Search Engine
+
Distributed Storage

22. Metadata Filtering

这是生产环境非常重要的问题。

假设数据库中有：

10M documents

用户属于：

tenant-A

那么搜索不能仅仅：

vector similarity

还必须：

tenant = A

因此查询实际上变成：

Similarity Search
+
Metadata Filter

例如：

WHERE tenant_id = 'A'
AND document_type = 'technical'

然后再进行：

Vector Similarity

或者反过来：

Vector Search
 ↓
Candidate Set
 ↓
Metadata Filtering
 ↓
Top-K

两种执行方式的性能可能完全不同。

23. Filtering 是 Vector Search 的难点

假设：

100M vectors

但：

tenant-A only = 10K vectors

如果先做 ANN：

100M → ANN → candidates → filter

可能浪费大量计算。

如果先 Filter：

100M → filter → 10K → ANN

则可能非常高效。

但如果：

tenant-A = 80M

情况又不同。

所以生产级 Vector Engine 必须考虑：

Filter Selectivity。

这也是 Vector Search Engine 与简单 ANN Library 的重要区别之一。

24. Hybrid Search

纯 Vector Search 并不能解决所有搜索问题。

例如：

"Spring Boot 3.2.5"

这里：

3.2.5

是一个非常精确的版本号。

Semantic Search 不一定比：

BM25
Keyword Search

更好。

因此现代 AI Search 通常采用：

Keyword Search
+
Vector Search

即：

Hybrid Search

25. BM25 + Vector

例如：

Query
 ↓
 ┌──────────────┐
 │              │
 ↓              ↓
BM25          Vector
 ↓              ↓
Keyword       Semantic
Score         Score
 └──────┬───────┘
        ↓
   Rank Fusion
        ↓
      Top-K

这样既能处理：

Exact Match

也能处理：

Semantic Match

26. RRF：Reciprocal Rank Fusion

一种常见的融合方法是：

RRF

假设：

Vector Search:
A, B, C, D

Keyword Search:
B, D, A, E

可以根据排名计算综合得分。

核心思想不是直接比较：

Vector Score
Keyword Score

而是利用：

Rank

进行融合。

这通常比简单：

0.5 × Vector Score
+
0.5 × Keyword Score

更加稳定。

27. Vector Database 与 RAG

Vector Database 最重要的应用之一就是：

RAG

完整流程：

Documents
   ↓
Chunking
   ↓
Embedding
   ↓
Vector Database

用户提问：

Question
   ↓
Embedding
   ↓
Vector Search
   ↓
Top-K Chunks
   ↓
Prompt Construction
   ↓
LLM
   ↓
Answer

因此：

Vector Database 是 RAG Retrieval Layer 的核心基础设施。

28. RAG 中最容易被忽视的问题：Chunking

很多人认为：

RAG = Embedding + Vector Database + LLM

这是不完整的。

实际上：

Document
 ↓
Chunking
 ↓
Embedding
 ↓
Index

Chunking 对最终 Recall 有巨大影响。

例如：

一个 100 页 PDF

如果整个 PDF 只生成一个向量：

PDF → Vector

那么检索粒度太粗。

如果切得太碎：

每 20 个字符一个 Chunk

又会丢失上下文。

因此需要设计：

Chunk Size
Chunk Overlap
Semantic Chunking
Parent-Child Chunk
Metadata

29. Retrieval 的完整链路

一个生产级 RAG Retrieval Pipeline 可以是：

User Query
    ↓
Query Rewrite
    ↓
Query Embedding
    ↓
Hybrid Retrieval
    ↓
Metadata Filtering
    ↓
ANN Search
    ↓
Candidate Retrieval
    ↓
Reranking
    ↓
Top-K Context
    ↓
LLM

这里最值得注意的是：

Vector Database 只是 Retrieval Pipeline 的一个组件。

30. Reranker

Vector Search 找到：

Top 50

但是最终给 LLM 的可能只有：

Top 5

中间可以增加：

Reranker

架构：

Vector DB
    ↓
Top 50
    ↓
Reranker
    ↓
Top 5
    ↓
LLM

Embedding Model 更擅长：

快速召回

Reranker 更擅长：

精确判断 Query 与 Document 的相关性

因此可以形成：

Embedding → Recall
Reranker  → Precision

这是现代 RAG 中非常重要的两阶段检索架构。

31. Recall 与 Precision 的平衡

假设真正相关的文档有：

A B C

Vector Search 返回：

A B X Y Z

那么：

Recall = 2 / 3

如果提高：

Top-K

可能：

A B C X Y Z

Recall 提高。

但是：

Noise ↑
LLM Context ↑
Latency ↑
Cost ↑

因此 Retrieval 的核心不是：

“找到最多的数据。”

而是：

在有限延迟和 Token Budget 下，找到最有价值的数据。

32. Vector Database 的性能指标

生产环境不能只看：

QPS

至少需要关注：

Recall

Recall@K

Latency

P50
P95
P99

Throughput

QPS

Memory

GB

Index Build Time

Index Construction Duration

Update Latency

Insert
Update
Delete

Freshness

Document → Searchable

之间的时间。

33. Recall@K

假设：

Ground Truth:
A B C D E

Vector Search：

A B C X Y

那么：

Recall@5 = 3 / 5 = 60%

Recall 是评估 ANN Index 最重要的指标之一。

通常需要建立：

Recall
vs
Latency

曲线。

例如：

efSearch ↑
    ↓
Recall ↑
    ↓
Latency ↑

最终寻找：

Best Operating Point

34. Vector Database 的分布式架构

当数据规模达到：

100M
1B
10B vectors

单机已经无法解决所有问题。

因此需要：

Client
   ↓
Query Router
   ↓
Partition
   ↓
Vector Nodes
   ↓
Storage

常见设计包括：

Sharding
Replication
Load Balancing
Distributed Index
Object Storage
WAL

35. Sharding

可以按照：

Tenant
Document
Hash
Vector Partition

进行分片。

例如：

Shard 1
10M vectors

Shard 2
10M vectors

Shard 3
10M vectors

查询：

Query
 ↓
Router
 ↓
Shard 1
Shard 2
Shard 3
 ↓
Local Top-K
 ↓
Global Merge
 ↓
Top-K

这里会产生一个重要问题：

Distributed Top-K

每个节点只返回：

Local Top-K

然后 Router：

Merge

得到：

Global Top-K

36. Replication

Vector Search 通常是：

Read Heavy

因此可以通过：

Leader
   ↓
Replica 1
Replica 2
Replica 3

提高：

Read Throughput
Availability

但是更新时需要解决：

Index Consistency
Data Consistency
Replica Lag

37. Vector Database 的一致性问题

传统数据库通常讨论：

Strong Consistency
Eventual Consistency

Vector Database 还有一个非常特殊的问题：

数据已经写入，但索引是否已经更新？

例如：

t0:
Insert Document

t1:
Document stored

t2:
Embedding generated

t3:
Vector index updated

t4:
Searchable

因此生产系统需要定义：

Write-to-Search Latency

即：

一条数据写入之后，需要多长时间才能被搜索到？

38. Delete 也非常复杂

删除：

Document

不意味着：

Vector
Index
Metadata
Cache

同时消失。

可能需要：

Tombstone
Compaction
Index Rebuild
Garbage Collection

因此 Vector Database 的数据生命周期通常是：

Insert
 ↓
Index
 ↓
Update
 ↓
Delete
 ↓
Tombstone
 ↓
Compaction

39. Vector Database 与传统数据库

Vector Database 并不是：

“MongoDB / PostgreSQL 的替代品。”

更合理的理解是：

Relational DB
    ↓
Transactional Data

Search Engine
    ↓
Keyword Search

Vector Database
    ↓
Semantic Search

现代系统经常是：

PostgreSQL
+
Redis
+
Kafka
+
Elasticsearch
+
Vector Database
+
Object Storage

不同组件解决不同问题。

40. PostgreSQL + pgvector

对于很多中小型系统，并不一定需要部署独立 Vector Database。

如果已经使用 PostgreSQL，可以通过：

pgvector

增加向量能力。

架构：

Application
     ↓
PostgreSQL
 ┌───────────────┐
 │ Relational DB │
 │ Vector        │
 │ Metadata      │
 └───────────────┘

它的优势是：

Architecture Simplicity
Transaction
SQL
Metadata Filtering

因此对于中小规模 RAG：

PostgreSQL + pgvector 往往是一个非常值得优先考虑的架构。

41. 专业 Vector Database

当系统进一步扩大，可以考虑专门的 Vector Database / Vector Search Engine。

典型技术路线包括：

  • Milvus
  • Qdrant
  • Weaviate
  • Pinecone
  • Elasticsearch Vector Search
  • OpenSearch Vector Search
  • MongoDB Atlas Vector Search
  • PostgreSQL + pgvector

不同系统在：

Scale
Performance
Cloud Integration
Filtering
Consistency
Operational Complexity

方面各有取舍。

因此不要简单认为：

“某个 Vector Database 性能最高，所以一定应该使用它。”

真正应该问的是：

Data Size?
QPS?
Recall?
Latency?
Filtering?
Multi-tenancy?
Update Frequency?
Deployment Model?
Operational Capability?

42. Vector Database 的 CAP 视角

对于分布式 Vector Search，可以从三个角度分析：

Consistency
Availability
Partition Tolerance

但 Vector Database 与传统 OLTP 最大不同之一是：

Retrieval Quality 本身也是系统设计指标。

因此实际上需要同时考虑：

Consistency
Availability
Latency
Recall
Freshness
Cost

这是一种更加符合 AI Search 的工程权衡。

43. 多租户架构

企业级 RAG 通常不是：

One User
One Knowledge Base

而是：

Tenant A
Tenant B
Tenant C
...

因此 Vector Database 必须解决：

Tenant Isolation
Authorization
Filtering
Index Isolation
Resource Isolation

一个常见设计是：

vector
metadata:
    tenant_id
    document_id
    user_id
    permission

查询：

tenant_id = currentTenant
AND permission ...

然后：

Vector Similarity Search

这里有一个极其重要的安全原则：

Authorization Filter 必须成为 Retrieval 的一部分，而不是 Retrieval 完成后再过滤。

否则可能出现：

Vector Search
 ↓
召回了无权限文档
 ↓
LLM

这会造成严重的数据泄露风险。

44. Vector Search Security

企业 RAG 中：

User
 ↓
Authentication
 ↓
Authorization
 ↓
Query
 ↓
Vector Retrieval
 ↓
LLM

权限模型应该进入：

Metadata Filter

例如：

tenant_id
department_id
document_acl
security_level

因此：

RAG 的安全边界不仅在 LLM，也在 Retrieval Layer。

45. Vector Database 的 Cost Model

Vector Search 的成本主要来自：

Embedding
Storage
Index
Memory
Compute
Network
Replication
Reranking
LLM

尤其需要注意：

Embedding Cost
+
Vector Storage
+
LLM Token Cost

一个看似简单的：

RAG Question

实际上可能经过：

Query Rewrite
 ↓
Embedding
 ↓
Vector Search
 ↓
Reranker
 ↓
LLM

因此应该从端到端角度优化，而不是只优化 Vector Database。

46. 一个生产级 RAG 架构

可以设计成：

                   ┌──────────────┐
                   │     User     │
                   └──────┬───────┘
                          ↓
                   ┌──────────────┐
                   │ API Gateway  │
                   └──────┬───────┘
                          ↓
                   ┌──────────────┐
                   │ Query Service│
                   └──────┬───────┘
                          ↓
                 ┌──────────────────┐
                 │ Query Processing  │
                 └────────┬─────────┘
                          ↓
              ┌────────────────────────┐
              │ Hybrid Retrieval       │
              │                        │
              │ Keyword + Vector       │
              └───────────┬────────────┘
                          ↓
                 ┌─────────────────┐
                 │ Vector Database │
                 └────────┬────────┘
                          ↓
                    Candidate Docs
                          ↓
                    ┌───────────┐
                    │ Reranker  │
                    └─────┬─────┘
                          ↓
                     Top-K Context
                          ↓
                       ┌─────┐
                       │ LLM │
                       └──┬──┘
                          ↓
                       Answer

Document ingestion：

Documents
    ↓
Parser
    ↓
Chunker
    ↓
Embedding
    ↓
Vector Database

47. 如何选择 Vector Index？

可以建立一个简单的决策模型：

数据规模较小
      ↓
Exact Search

中等规模
      ↓
HNSW

超大规模
      ↓
IVF / PQ / Disk-based ANN

如果：

Memory Plenty
+
Low Latency
+
High Recall

通常可以优先考虑：

HNSW

如果：

Huge Scale
+
Memory Sensitive

则需要考虑：

IVF
PQ
DiskANN
Quantization

48. Vector Database 最容易出现的误区

误区一：向量维度越高越好

不是。

维度越高：

Memory ↑
Compute ↑
Index Size ↑
Latency ↑

Embedding Dimension 应该通过实验确定。

误区二：Top-K 越大越好

不是。

K ↑

可能导致：

Recall ↑
Noise ↑
Context ↑
LLM Cost ↑
Latency ↑

不是。

对于：

Product ID
Version
Error Code
Class Name
API Name

Keyword Search 往往更可靠。

所以：

Hybrid Search

通常比纯 Vector Search 更适合企业应用。

误区四：Vector Database 就是 RAG

不是。

完整 RAG：

Document Processing
+
Chunking
+
Embedding
+
Retrieval
+
Reranking
+
Prompt Engineering
+
LLM
+
Evaluation

Vector Database 只是其中的重要基础设施。

49. Vector Database 的未来方向

Vector Database 正在从：

Vector Storage

逐渐演变成：

AI Search Engine

未来重点可能包括：

不再只是：

Text → Vector

而是：

Text
Image
Audio
Video
Code

统一进入：

Multimodal Embedding Space

2. Hybrid Retrieval

进一步融合：

Vector
+
Keyword
+
Graph
+
Structured Data

3. Learned Retrieval

使用机器学习动态优化：

Query
 ↓
Retrieval Strategy
 ↓
Index Selection
 ↓
Ranking

4. Agentic Retrieval

AI Agent 不再只进行一次：

Vector Search

而可能：

Question
 ↓
Plan
 ↓
Search
 ↓
Analyze
 ↓
Search Again
 ↓
Rerank
 ↓
Answer

Vector Database 将成为 Agent Memory 和 Knowledge Retrieval 的基础设施之一。

50. 从架构师角度理解 Vector Database

如果只把 Vector Database 理解为：

存向量

理解还比较浅。

真正的架构问题应该是：

                ┌──────────────┐
                │  Embedding   │
                └──────┬───────┘
                       ↓
                 Vector Index
                       ↓
               ANN Retrieval
                       ↓
              Metadata Filter
                       ↓
              Hybrid Retrieval
                       ↓
                  Reranking
                       ↓
                    Context
                       ↓
                     LLM

同时还需要考虑：

              ┌──────────────┐
              │ Scalability  │
              ├──────────────┤
              │ Availability │
              ├──────────────┤
              │ Consistency  │
              ├──────────────┤
              │ Security     │
              ├──────────────┤
              │ Recall       │
              ├──────────────┤
              │ Latency      │
              ├──────────────┤
              │ Cost         │
              └──────────────┘

这才是生产级 Vector Database Architecture。

51. 总结

Vector Database 的核心并不是“数据库里保存了一堆向量”，而是解决：

如何在高维向量空间中，对海量数据进行低延迟、高召回率、可扩展的相似性搜索。

它背后的核心技术可以总结为：

Embedding
    ↓
Vector Representation
    ↓
Distance Metric
    ↓
ANN
    ↓
HNSW / IVF / PQ / DiskANN
    ↓
Filtering
    ↓
Hybrid Search
    ↓
Reranking
    ↓
Distributed Vector Search

而在 AI 应用中：

Vector Database
        ↓
Retrieval
        ↓
RAG
        ↓
AI Application

真正成熟的 AI Search 架构并不是简单地：

LLM + Vector DB

而是：

                  AI Application
                        │
                        ↓
                 Query Processing
                        │
             ┌──────────┴──────────┐
             ↓                     ↓
        Keyword Search       Vector Search
             │                     │
             └──────────┬──────────┘
                        ↓
                  Hybrid Ranking
                        ↓
                    Reranker
                        ↓
                  Context Selection
                        ↓
                       LLM
                        ↓
                     Answer

因此，从架构师视角看，Vector Database 最值得掌握的不是某一个产品的 API，而是下面这条完整技术链：

Embedding → Vector Space → Similarity Metric → ANN → Index → Filtering → Hybrid Retrieval → Reranking → Distributed Search → RAG

掌握这条链路之后，无论面对 Milvus、Qdrant、Weaviate、Pinecone、pgvector、Elasticsearch Vector Search，还是未来新的 AI Search Engine，都能够从底层原理、性能、架构和生产实践层面进行分析，而不仅仅停留在“会调用 Vector DB API”的层面。

Vincent zhai
Vincent zhai
Full-Stack Engineer