全部文章 笔记与思考

向量数据库与传统数据库

向量数据库与传统数据库:从精确查询到语义检索

在传统的软件系统中,数据库主要负责存储用户、订单、商品、日志等结构化数据。当我们需要查询某个用户时,通常会使用用户 ID、手机号或者用户名作为条件。

例如:

1
2
3
SELECT *
FROM users
WHERE username = 'zhangsan';

这种查询的特点是:查询条件明确,数据库需要找到精确匹配的数据。

但是在人工智能应用中,我们可能会遇到另一类问题:

  • 找出与这段文字含义最接近的文章。
  • 找到与当前商品风格相似的商品。
  • 根据一张图片搜索视觉上相似的图片。
  • 从知识库中找到能够回答用户问题的内容。
  • 判断两段代码是否实现了相似的功能。

这些问题很难仅通过 =、LIKE 或普通关键字查询解决。

向量数据库正是为了解决这类“相似性检索”问题而出现的。

flowchart LR A[传统数据库] --> B[精确匹配] A --> C[范围查询] A --> D[事务处理] E[向量数据库] --> F[语义相似度搜索] E --> G[图片相似度搜索] E --> H[多模态检索]

什么是传统数据库

传统数据库通常指关系型数据库,以及部分通用型 NoSQL 数据库,例如:

  • MySQL
  • PostgreSQL
  • Oracle
  • SQL Server
  • MongoDB
  • Redis

关系型数据库将数据组织成表,每张表由行和列构成。

例如,一个商品表可能是:

id name category price stock
1001 机械键盘 外设 399 20
1002 无线鼠标 外设 199 35
1003 显示器 显示设备 1599 8

我们可以按照字段进行精确查询:

1
2
3
4
SELECT *
FROM products
WHERE category = '外设'
  AND price < 300;

传统数据库擅长处理以下任务:

  • 根据主键查询数据。
  • 根据字段进行过滤和排序。
  • 执行增删改查操作。
  • 保证事务一致性。
  • 维护实体之间的关联关系。
  • 进行统计、聚合和报表分析。

例如,在电商系统中,订单创建通常涉及库存扣减、订单写入和支付记录生成。这些操作必须满足事务要求。

sequenceDiagram participant U as 用户 participant O as 订单服务 participant DB as 传统数据库 U->>O: 创建订单 O->>DB: 开启事务 O->>DB: 扣减库存 O->>DB: 创建订单 O->>DB: 写入支付记录 DB-->>O: 提交事务 O-->>U: 订单创建成功

传统数据库关注的是:

数据是否准确、关系是否完整、事务是否可靠。

什么是向量

要理解向量数据库,首先需要理解向量。

在人工智能系统中,文本、图片、音频和视频可以通过模型转换成一组数字。这组数字称为向量,也常被称为 Embedding。

例如,下面三句话:

1
2
3
我喜欢骑自行车旅行。
周末我经常骑车去郊外。
数据库出现了连接超时。

经过 Embedding 模型处理后,可能会被转换为:

1
2
3
4
5
6
7
8
我喜欢骑自行车旅行。
→ [0.12, -0.31, 0.85, 0.47, ...]

周末我经常骑车去郊外。
→ [0.15, -0.28, 0.81, 0.51, ...]

数据库出现了连接超时。
→ [-0.62, 0.73, 0.05, -0.16, ...]

前两句话的含义比较接近,因此它们对应的向量在向量空间中的距离也会更近。

quadrantChart title 文本在向量空间中的示意分布 x-axis 低运动相关度 --> 高运动相关度 y-axis 低旅行相关度 --> 高旅行相关度 quadrant-1 骑行与旅行 quadrant-2 旅行主题 quadrant-3 技术主题 quadrant-4 运动主题 "骑自行车去郊外旅行": [0.88, 0.86] "周末骑车锻炼": [0.82, 0.55] "计划去北欧旅行": [0.45, 0.91] "数据库连接超时": [0.12, 0.16]

这里的坐标只是示意。真实的 Embedding 向量往往包含几百甚至几千个维度,人类无法直接观察这些高维空间。

Embedding 的核心作用,是将原始数据的“语义特征”编码为数值。

什么是向量数据库

向量数据库是一类专门用于存储、索引和查询高维向量的数据系统。

一条向量数据通常不只有向量本身,还会包含原始内容和元数据。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
{
  "id": "article-1001",
  "vector": [0.12, -0.31, 0.85, 0.47],
  "metadata": {
    "title": "如何搭建企业内部 SkillHub",
    "category": "AI 工程",
    "author": "Xinzhan Wu"
  },
  "content": "本文介绍基于 npm Registry 构建企业内部 SkillHub 的方案。"
}

向量数据库可以回答这样的问题:

哪些数据的向量与当前查询向量最接近?

它的基本工作流程如下。

flowchart LR A[用户输入问题] --> B[Embedding 模型] B --> C[查询向量] C --> D[向量数据库] D --> E[相似度搜索] E --> F[返回 Top-K 结果]

例如,用户输入:

1
企业内部应该如何管理 AI Skill?

即使知识库中没有完全相同的句子,向量数据库仍然可能找到以下内容:

1
基于 npm Registry 构建企业内部 SkillHub

原因是两段文本在语义上比较接近。

传统关键字搜索关注“是否出现相同的词”,而向量搜索关注“表达的含义是否接近”。

向量数据库与传统数据库的核心区别

对比维度 传统数据库 向量数据库
主要数据 字符串、数字、日期、JSON 高维浮点向量
典型查询 精确匹配、范围查询、关联查询 相似度查询、Top-K 查询
查询条件 id = 1、price < 100 与查询向量最相似
索引结构 B+ 树、哈希索引、倒排索引 HNSW、IVF、PQ
核心目标 准确性与事务一致性 检索速度与召回率
典型场景 订单、用户、支付、库存 RAG、推荐、图片搜索
结果特点 条件满足或不满足 按相似程度排序
常用指标 QPS、延迟、事务成功率 Recall、Top-K、查询延迟
是否擅长事务 是 通常不是核心能力
是否支持语义搜索 通常不直接支持 是

两者最根本的区别在于查询方式。

传统数据库查询的是:

1
哪些数据满足确定的条件?

向量数据库查询的是:

1
哪些数据与当前内容最相似?

精确查询与相似度查询

假设数据库中有以下三篇文章:

1
2
3
文章 A:使用 Go 开发高并发后端服务
文章 B:Golang 服务端性能优化方法
文章 C:React 前端组件设计实践

用户搜索:

1
如何提高 Go 后端程序的性能?

使用传统关键字匹配时,“Golang”和“Go”可能被认为是两个不同的词,“后端程序”和“服务端”也不完全相同。

使用向量搜索时,文章 A 和文章 B 的向量通常都会与查询向量比较接近。

flowchart TD Q[如何提高 Go 后端程序的性能] --> E[生成查询向量] E --> A[文章 A 向量
相似度 0.89] E --> B[文章 B 向量
相似度 0.93] E --> C[文章 C 向量
相似度 0.32] B --> R1[Top 1] A --> R2[Top 2]

向量数据库最终会按照相似度排序,返回最接近的若干条数据。

向量相似度如何计算

常见的向量相似度计算方式包括:

  • 余弦相似度。
  • 欧氏距离。
  • 点积。

余弦相似度

余弦相似度关注两个向量方向之间的夹角。

其计算公式为:

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

余弦相似度越接近 1,通常表示两个向量越相似。

例如:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
import numpy as np


def cosine_similarity(vector_a: np.ndarray, vector_b: np.ndarray) -> float:
    """计算两个向量的余弦相似度。"""

    denominator = np.linalg.norm(vector_a) * np.linalg.norm(vector_b)

    # 避免零向量导致除零错误
    if denominator == 0:
        return 0.0

    return float(np.dot(vector_a, vector_b) / denominator)


vector_a = np.array([0.2, 0.8, 0.4])
vector_b = np.array([0.3, 0.7, 0.5])

similarity = cosine_similarity(vector_a, vector_b)
print(f"相似度:{similarity:.4f}")

如果数据规模很小,可以逐个计算向量距离。

但如果数据库中存在数百万甚至数十亿条向量,逐条计算的成本会非常高,因此需要使用专门的向量索引。

为什么不能直接遍历所有向量

假设数据库中有 1000 万条向量,每条向量有 1536 个维度。

用户每查询一次,都需要将查询向量与 1000 万条向量分别计算距离。

粗略计算量为:

1
1000 万 × 1536 次浮点运算

这种方式被称为暴力搜索或精确搜索。

精确搜索能够得到绝对准确的结果,但随着数据规模增长,查询延迟会迅速增加。

因此,大多数向量数据库使用近似最近邻搜索:

1
Approximate Nearest Neighbor,ANN

ANN 不一定遍历所有向量,而是借助索引快速缩小搜索范围。

它牺牲少量准确率,换取显著的性能提升。

flowchart LR A[查询向量] --> B{搜索方式} B --> C[暴力搜索] C --> D[遍历全部向量] D --> E[结果准确
速度较慢] B --> F[ANN 搜索] F --> G[通过索引筛选候选集] G --> H[结果近似
速度较快]

常见的向量索引

HNSW

HNSW 的全称是 Hierarchical Navigable Small World,即分层可导航小世界图。

它会将向量组织成多层图结构。

查询时先在较高层快速确定大致方向,再逐层向下寻找更接近的向量。

flowchart TD subgraph L3[第三层:稀疏节点] A1((A)) --- A2((B)) end subgraph L2[第二层:中等密度] B1((A)) --- B2((C)) B2 --- B3((B)) end subgraph L1[第一层:高密度节点] C1((A)) --- C2((D)) C2 --- C3((C)) C3 --- C4((E)) C4 --- C5((B)) end A1 -.向下搜索.-> B1 A2 -.向下搜索.-> B3 B2 -.向下搜索.-> C3

HNSW 通常具有较高的召回率和较低的查询延迟,但需要占用较多内存。

适合:

  • 中低延迟在线检索。
  • RAG 知识库。
  • 实时推荐系统。
  • 数据规模在内存可承受范围内的系统。

IVF

IVF 的全称是 Inverted File Index,即倒排文件索引。

它会先通过聚类将向量划分到不同的中心区域。查询时只搜索与查询向量最接近的几个聚类,而不是遍历所有向量。

flowchart TD Q[查询向量] --> C{选择最近的聚类} C --> C1[聚类 1] C --> C2[聚类 2] C --> C3[聚类 3] C --> C4[聚类 4] C2 --> S1[搜索聚类 2 内的向量] C3 --> S2[搜索聚类 3 内的向量] S1 --> R[合并并返回 Top-K] S2 --> R

IVF 可以通过调整搜索的聚类数量,在查询速度和召回率之间进行权衡。

PQ

PQ 的全称是 Product Quantization,即乘积量化。

它会将高维向量切分为多个子向量,再对每个子向量进行量化编码。

原本需要使用大量浮点数保存的向量,可以被压缩为较短的编码。

PQ 的优势是:

  • 降低向量存储空间。
  • 减少内存占用。
  • 加快距离计算。

代价是量化过程可能造成一定精度损失。

向量数据库的基本数据模型

向量数据库中的一条记录通常包含三部分。

flowchart LR A[向量记录] --> B[唯一标识 ID] A --> C[Embedding 向量] A --> D[Metadata 元数据] D --> E[类别] D --> F[时间] D --> G[作者] D --> H[权限]

例如:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
{
  "id": "doc-001",
  "vector": [0.21, -0.37, 0.66, 0.19],
  "metadata": {
    "department": "研发部",
    "document_type": "技术文档",
    "visibility": "internal",
    "created_at": "2026-07-13"
  }
}

元数据非常重要。

在真实系统中,通常不能只进行向量搜索,还需要添加过滤条件。

例如:

1
2
3
找出与用户问题最相关的文档,
并且文档所属部门必须是研发部,
文档权限必须是 internal。

对应的逻辑类似于:

1
2
3
4
5
6
7
8
results = vector_database.search(
    vector=query_vector,
    top_k=5,
    filter={
        "department": "研发部",
        "visibility": "internal",
    },
)

这种方式称为带元数据过滤的向量检索。

向量数据库如何应用于 RAG

RAG 的全称是 Retrieval-Augmented Generation,即检索增强生成。

它的核心思想是:

在大语言模型生成答案之前,先从知识库中检索相关资料,再将资料交给模型生成答案。

完整流程如下。

flowchart TD A[企业文档] --> B[文档切分] B --> C[Embedding 模型] C --> D[生成文本向量] D --> E[写入向量数据库] U[用户提问] --> F[生成查询向量] F --> G[向量相似度搜索] E --> G G --> H[返回 Top-K 文档片段] H --> I[构造 Prompt] U --> I I --> J[大语言模型] J --> K[生成最终答案]

假设企业知识库中存在如下内容:

1
Skill 包发布前需要完成安全扫描、版本检查和元数据校验。

用户提问:

1
内部 Skill 发布之前需要检查什么?

系统会先将问题转换成向量,再从向量数据库中找到相关文档片段,最后让大语言模型根据检索结果回答。

向量数据库在 RAG 中主要承担以下职责:

  • 存储文档向量。
  • 根据用户问题进行语义检索。
  • 返回最相关的上下文。
  • 支持权限、部门、时间等元数据过滤。

需要注意的是,向量数据库本身不会生成答案,它只负责检索相关内容。

向量数据库不能替代传统数据库

向量数据库与传统数据库并不是替代关系。

例如,一个 AI 知识库系统可能同时使用:

flowchart LR A[应用服务] --> B[PostgreSQL] A --> C[向量数据库] A --> D[对象存储] B --> E[用户信息] B --> F[文档元数据] B --> G[权限与任务状态] C --> H[文本向量] C --> I[语义检索索引] D --> J[PDF 原文件] D --> K[图片与附件]

其中:

  • PostgreSQL 保存用户、权限、任务和业务状态。
  • 向量数据库保存 Embedding 和向量索引。
  • 对象存储保存 PDF、Word、图片等原始文件。

当用户上传一份文档时,系统可能执行以下操作:

  1. 将原始文件上传到对象存储。
  2. 在传统数据库中记录文档名称、上传者和权限。
  3. 对文档进行解析和分块。
  4. 调用 Embedding 模型生成向量。
  5. 将文本片段和向量写入向量数据库。

传统数据库负责业务事实,向量数据库负责语义检索。

关键字搜索与向量搜索

传统全文搜索通常基于倒排索引。

例如,用户搜索:

1
Go 高并发开发

系统会查找包含“Go”“高并发”“开发”等关键词的文档。

关键字搜索的优点是:

  • 对专有名词、代码、型号和编号比较准确。
  • 搜索结果容易解释。
  • 对完全匹配的关键词非常敏感。

向量搜索的优点是:

  • 可以理解近义词。
  • 可以处理不同表达方式。
  • 能够按照语义相关程度排序。
  • 更适合自然语言问题。

两者也各有缺点。

搜索方式 优点 缺点
关键字搜索 精确、可解释、适合专有名词 难以理解语义和近义表达
向量搜索 支持语义检索、表达方式更灵活 可能忽略关键字的精确性
混合搜索 同时利用关键词和语义 架构和排序逻辑更复杂

混合检索

在实际的 RAG 系统中,单纯使用向量搜索并不总能获得最佳效果。

例如,用户搜索:

1
错误码 YN0031 是什么意思?

这里的 YN0031 是一个精确错误码。

向量搜索可能认为它与 Yarn、依赖安装、Node.js 等内容相关,但关键字搜索可以直接找到包含 YN0031 的文档。

因此,许多系统会同时执行:

  • 关键字检索。
  • 向量检索。
  • 结果重排。
flowchart TD Q[用户查询] --> K[关键字检索] Q --> V[向量检索] K --> R[结果融合] V --> R R --> RR[重排序模型] RR --> T[最终 Top-K 结果]

这种方式称为混合检索。

一种简单的混合评分公式是:

1
最终得分 = α × 向量相似度 + β × 关键字匹配得分

其中:

1
α + β = 1

对于自然语言问题,可以提高向量相似度的权重。

对于错误码、产品型号、文件名和函数名,可以提高关键字匹配的权重。

向量搜索的 Top-K

向量数据库通常通过 Top-K 参数控制返回结果数量。

例如:

1
2
3
4
results = vector_database.search(
    vector=query_vector,
    top_k=5,
)

表示返回与查询向量最相似的 5 条数据。

Top-K 并不是越大越好。

Top-K 太小可能漏掉重要信息,Top-K 太大则可能引入无关内容,并增加大语言模型的上下文长度。

flowchart LR A[Top-K 太小] --> B[可能遗漏相关文档] C[适中的 Top-K] --> D[相关性和上下文长度平衡] E[Top-K 太大] --> F[噪声增多、Token 消耗增加]

实际项目中通常需要结合以下因素调节:

  • 文档分块大小。
  • Embedding 模型效果。
  • 用户问题长度。
  • 大语言模型上下文窗口。
  • 是否使用重排序模型。
  • 数据库检索召回率。

文档为什么需要分块

大多数情况下,不会直接将整篇文档转换成一个向量。

假设一篇文档包含 10000 字,同时讨论安装、配置、权限和故障排查。将整篇文章生成一个向量,会导致不同主题被压缩到同一个表示中。

因此,通常需要先对文档进行分块。

flowchart LR A[完整文档] --> B[分块 1
系统介绍] A --> C[分块 2
安装步骤] A --> D[分块 3
配置说明] A --> E[分块 4
故障排查] B --> F[向量 1] C --> G[向量 2] D --> H[向量 3] E --> I[向量 4]

分块后,用户询问安装问题时,系统可以直接检索“安装步骤”对应的片段,而不是返回整篇文档。

常见分块策略包括:

  • 固定字符数分块。
  • 固定 Token 数分块。
  • 按段落分块。
  • 按 Markdown 标题分块。
  • 按语义边界分块。
  • 滑动窗口分块。

分块大小需要根据文档类型进行调整。

代码文档更适合按照类、函数或模块边界分块;普通文章可以按照标题和段落分块。

一个简单的向量检索示例

下面使用 Python 模拟一个最简单的向量搜索过程。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
from dataclasses import dataclass

import numpy as np


@dataclass
class Document:
    """知识库文档。"""

    document_id: str
    content: str
    vector: np.ndarray


def cosine_similarity(vector_a: np.ndarray, vector_b: np.ndarray) -> float:
    """计算余弦相似度。"""

    denominator = np.linalg.norm(vector_a) * np.linalg.norm(vector_b)

    if denominator == 0:
        return 0.0

    return float(np.dot(vector_a, vector_b) / denominator)


def search_documents(
    query_vector: np.ndarray,
    documents: list[Document],
    top_k: int = 3,
) -> list[tuple[Document, float]]:
    """按照相似度返回 Top-K 文档。"""

    scored_documents = [
        (document, cosine_similarity(query_vector, document.vector))
        for document in documents
    ]

    # 按照相似度从高到低排序
    scored_documents.sort(key=lambda item: item[1], reverse=True)

    return scored_documents[:top_k]


documents = [
    Document(
        document_id="doc-1",
        content="使用 Go 构建高并发后端服务",
        vector=np.array([0.8, 0.7, 0.1]),
    ),
    Document(
        document_id="doc-2",
        content="React 组件状态管理实践",
        vector=np.array([0.1, 0.2, 0.9]),
    ),
    Document(
        document_id="doc-3",
        content="Golang 服务端性能优化",
        vector=np.array([0.9, 0.6, 0.2]),
    ),
]

query_vector = np.array([0.85, 0.65, 0.15])

results = search_documents(
    query_vector=query_vector,
    documents=documents,
    top_k=2,
)

for document, score in results:
    print(f"{document.document_id}: {score:.4f} - {document.content}")

这个示例本质上仍然是暴力搜索。

真实的向量数据库会使用 HNSW、IVF 等索引结构,并处理数据持久化、并发查询、分片、过滤和容错等问题。

向量数据库的典型应用场景

RAG 知识库

将企业文档、产品手册和技术资料转换为向量,让大语言模型根据内部知识回答问题。

语义搜索

用户不需要输入完全一致的关键词,只需要描述自己的意图,系统就能找到相关内容。

推荐系统

将用户、商品或内容表示为向量,根据向量之间的距离生成推荐结果。

flowchart LR A[用户行为] --> B[用户向量] C[商品信息] --> D[商品向量] B --> E[相似度计算] D --> E E --> F[推荐商品列表]

图片搜索

通过图像模型将图片转换成向量,实现以图搜图。

例如:

  • 上传一张鞋子的图片,搜索外观相似的商品。
  • 上传一张人脸图片,搜索相似人物。
  • 上传一张风景图片,查找相似的摄影作品。

多模态检索

文本和图片可以通过多模态模型映射到相同的向量空间。

用户可以输入:

1
寻找一张冬季北欧雪山和湖泊的图片

系统通过文本向量搜索相似的图片向量。

代码搜索

将函数、类和代码文件转换成向量后,可以根据自然语言描述搜索代码。

例如:

1
查找负责校验 JWT Token 的函数

即使代码中没有出现完全相同的注释,系统仍然可能找到相关实现。

异常检测

正常数据通常集中在向量空间中的某些区域。如果一条新数据与其他数据距离明显较远,它可能是异常数据。

该方法可以用于:

  • 欺诈检测。
  • 日志异常分析。
  • 网络攻击检测。
  • 工业设备故障预警。

如何选择数据库

选择数据库时,不应该先问“哪个数据库更先进”,而应该先明确数据和查询模式。

flowchart TD A{系统主要查询什么} --> B[根据 ID 或字段查询] A --> C[根据语义或相似度查询] A --> D[两种查询都需要] B --> E[传统数据库] C --> F[向量数据库] D --> G[传统数据库 + 向量数据库]

可以按照下面的方式判断。

需求 推荐方案
用户、订单、支付、库存 传统关系型数据库
事务和强一致性 传统关系型数据库
文档语义搜索 向量数据库
图片相似度搜索 向量数据库
企业知识库问答 向量数据库配合传统数据库
精确错误码搜索 全文搜索或传统索引
同时需要语义和关键词 混合检索
既有业务数据又有 AI 检索 多数据库组合

使用向量数据库时需要关注什么

Embedding 模型

向量数据库只能根据已有向量进行搜索,向量质量主要取决于 Embedding 模型。

如果 Embedding 模型无法正确理解业务术语,即使向量数据库性能很好,检索结果也不会理想。

向量维度

更高的维度通常可以表达更丰富的信息,但也会增加:

  • 存储空间。
  • 内存占用。
  • 索引构建时间。
  • 相似度计算成本。

召回率

ANN 搜索是近似搜索,因此可能无法返回理论上最相似的全部结果。

召回率可以表示为:

1
Recall@K = 检索到的真实相关结果数量 / 理论相关结果数量

系统需要在查询延迟、内存占用和召回率之间进行平衡。

数据更新

某些向量索引适合静态数据,某些适合频繁更新。

如果系统中的向量会持续新增、修改和删除,需要关注:

  • 索引是否支持动态更新。
  • 删除数据后是否需要重建索引。
  • 新数据写入后多久可以被查询。
  • 索引构建是否会影响在线请求。

元数据过滤

企业系统通常存在复杂的权限条件。

例如:

1
用户只能检索自己所在部门的内部文档。

因此,向量数据库是否支持高效的元数据过滤十分重要。

数据一致性

如果传统数据库中的文档已经删除,但向量数据库中的向量仍然存在,用户可能检索到失效内容。

系统需要设计数据同步机制。

sequenceDiagram participant APP as 应用服务 participant DB as 传统数据库 participant VDB as 向量数据库 APP->>DB: 删除文档记录 DB-->>APP: 删除成功 APP->>VDB: 删除对应向量 VDB-->>APP: 删除成功

在复杂系统中,还可以通过消息队列和补偿任务保证最终一致性。

常见误区

向量数据库就是大语言模型数据库

向量数据库不是专门存储大语言模型的数据库。

它存储的是向量、原始内容和元数据,可以用于文本、图片、音频、推荐和异常检测等多种场景。

向量数据库可以直接回答问题

向量数据库负责检索,不负责生成自然语言答案。

在 RAG 系统中,最终答案通常由大语言模型生成。

向量维度越高越好

维度越高不一定意味着检索效果越好。

最终效果取决于模型训练数据、业务场景、文本质量和检索策略。

使用向量数据库就不需要传统数据库

向量数据库通常无法替代订单、用户、权限、库存和支付系统中的传统数据库。

实际应用更常见的是组合使用。

相似度最高的内容一定正确

向量相似度只表示语义或特征上的接近程度,并不等于事实正确。

因此,RAG 系统还需要考虑:

  • 文档是否过期。
  • 数据源是否可信。
  • 用户是否有访问权限。
  • 检索内容是否真正能够回答问题。
  • 是否需要使用重排序模型。

总结

传统数据库和向量数据库解决的是不同类型的问题。

传统数据库擅长:

  • 精确查询。
  • 结构化数据管理。
  • 事务处理。
  • 数据关系维护。
  • 聚合和统计。

向量数据库擅长:

  • 语义搜索。
  • 相似度检索。
  • 图片与多模态搜索。
  • 推荐系统。
  • RAG 知识检索。

两者之间并不是竞争或替代关系。

在现代 AI 应用中,一种常见的架构是:

flowchart LR U[用户请求] --> A[应用服务] A --> DB[传统数据库] A --> VDB[向量数据库] A --> LLM[大语言模型] DB --> B[用户、权限、业务状态] VDB --> C[语义相关上下文] B --> A C --> A A --> LLM LLM --> R[最终回答]

传统数据库保存明确的业务事实,向量数据库提供基于语义的检索能力,大语言模型负责理解问题并组织答案。

可以将它们概括为:

传统数据库负责找到“符合条件的数据”,向量数据库负责找到“含义相近的数据”。

理解这一差异,是设计 RAG、智能搜索、推荐系统和多模态应用的基础。