向量数据库 on Snow

向量数据库与传统数据库

Mon, 13 Jul 2026 21:24:23 +0800

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

在传统的软件系统中，数据库主要负责存储用户、订单、商品、日志等结构化数据。当我们需要查询某个用户时，通常会使用用户 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

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

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 模型处理后，可能会被转换为：

我喜欢骑自行车旅行。
→ [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 的核心作用，是将原始数据的“语义特征”编码为数值。

什么是向量数据库

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

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

{
  "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，通常表示两个向量越相似。

例如：

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[权限]

例如：

{
  "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。

对应的逻辑类似于：

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、图片等原始文件。

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

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

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

关键字搜索与向量搜索

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

例如，用户搜索：

`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 参数控制返回结果数量。

例如：

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 模拟一个最简单的向量搜索过程。

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 知识库

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

语义搜索

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

图片搜索

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

例如：

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

多模态检索

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

用户可以输入：

`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、智能搜索、推荐系统和多模态应用的基础。

RAG 技术全景：让大模型从"闭卷考试"到"开卷考试"

Wed, 08 Jul 2026 15:00:00 +0800

RAG 技术全景：让大模型从"闭卷考试"到"开卷考试"

大模型很强，但它会"一本正经地胡说八道"。RAG（Retrieval-Augmented Generation，检索增强生成）给大模型外挂了一个"知识库"，让它从闭卷考试变成开卷考试，回答既准又能溯源。本文用 6 张图带你完整搞懂 RAG。

一、先聊痛点：大模型的"幻觉"从哪来？

你大概遇到过这样的场景：问 GPT 一个公司内部的政策问题，或者让它总结一份最新发布的财报，它信誓旦旦地给你一段听起来很专业的回答——但仔细一查，全是编的。

这就是大模型的幻觉（Hallucination）。它不是故意的，而是由其工作方式决定的：LLM 本质上是在做"下一个 token 预测"，它根据训练时记住的概率分布生成文本，分不清"知道"和"不知道"。

原生 LLM 在企业级场景下有四个硬伤：

知识截止：训练数据有截止日期，不知道今天发生的事
幻觉问题：没见过的知识就靠"编"，还很自信
领域知识不足：对企业内部文档、专业细分领域不熟悉
无法溯源：回答不知道来自哪里，没法核验

要解决这些问题，传统思路是微调（Fine-tuning）——用领域数据重新训练模型。但微调又贵又慢，而且知识一更新就得再来一遍。

RAG 给了另一条路：不重新训练模型，而是给它外挂一个可随时更新的知识库，回答时先去知识库里检索，再基于检索到的内容作答。

就像考试一样：原生 LLM 是闭卷考试，全凭记忆，记不清就编；RAG 是开卷考试，遇到不会的可以翻书，答案有据可循。

二、RAG 是什么：核心思想一句话

RAG = 检索（Retrieval）+ 增强（Augmentation）+ 生成（Generation）

在 LLM 生成回答之前，先从外部知识库中检索相关资料，把这些资料增强到 Prompt 里作为上下文，再让 LLM 基于这些上下文生成回答。

用一句话概括：RAG 让 LLM 从"闭卷考试"变成"开卷考试"。

它和微调的根本区别在于：微调把知识"烧进"模型权重里，RAG 把知识放在模型之外的数据库里，用的时候现查。这也决定了两者的适用边界——后面会详细对比。

三、RAG 工作流程：三阶段详解

RAG 的完整流程可以拆成离线建库和在线问答两大阶段。在线问答又分为检索、增强、生成三步。

3.1 离线阶段：把文档变成可检索的向量库

这一步是"建图书馆"的过程，通常一次性完成，知识更新时增量重建：

文档加载：读取 PDF、Word、HTML、Markdown 等原始文档
切分（Chunking）：把长文档切成小段。为什么不整篇存？因为检索时要找最相关的片段，整篇文档向量会"稀释"语义；而且 LLM 上下文有限，塞不下整篇
向量化（Embedding）：用嵌入模型把每段文本转成一个高维向量（通常 768~1536 维），语义相近的文本在向量空间里距离也近
存入向量数据库：把向量和原文一起存进去，建好索引，供后续快速检索

3.2 在线阶段：检索 → 增强 → 生成

用户每一次提问，都会实时跑这三步：

① 检索 Retrieval

把用户问题用同一个 Embedding 模型转成向量
在向量数据库中做相似度检索（通常用余弦相似度），召回 Top-K（一般 3~10 条）最相关的文档片段

② 增强 Augmentation

把检索到的片段拼到 Prompt 模板里，作为上下文
一个典型的 Prompt 长这样：

你是一个严谨的问答助手，请根据以下参考资料回答用户问题。
如果资料中没有答案，请回答"根据现有资料无法回答"，不要编造。

【参考资料】
{检索到的文档片段1}
{检索到的文档片段2}
...

【用户问题】
{用户的问题}

③ 生成 Generation

把拼好的 Prompt 喂给 LLM，生成最终回答
可以要求模型在回答中标注引用来源，实现可溯源

四、完整架构图

这张图把离线和在线两条流水线放在了一起。注意几个关键点：

Embedding 模型必须一致：离线建库用哪个模型，在线检索时也要用同一个，否则向量空间不兼容
知识更新无需重训模型：新增文档只需走一遍"切分 → 向量化 → 入库"，模型权重完全不动
检索质量是 RAG 的命门：如果第一步召回的片段就不相关，后面 LLM 再强也答不好

五、核心组件选型

RAG 系统由四个核心组件构成，选型直接影响效果：

组件	作用	常见选型
Embedding 模型	文本转向量，决定语义匹配上限	BGE（智源）、M3E、OpenAI text-embedding-3、Cohere、bge-m3
向量数据库	存储与检索向量	Milvus、Qdrant、Chroma、Pinecone、FAISS、Weaviate
LLM	基于上下文生成回答	GPT-4、Claude、Qwen、DeepSeek、Llama、GLM
编排框架	串联整个流程	LangChain、LlamaIndex、Haystack、DSPy

几个选型经验：

中文场景：Embedding 优先考虑 bge-large-zh 或 bge-m3，比 OpenAI 的英文模型在中文检索上更准
轻量起步：向量库用 Chroma（纯 Python，单机嵌入式）跑通流程，量大了再换 Milvus / Qdrant
框架选择：快速原型用 LangChain，文档密集型场景用 LlamaIndex（它对文档处理和索引抽象更细致）

六、进阶技术：从"能用"到"好用"

朴素 RAG（一次向量检索 + 拼 Prompt）能跑通，但效果往往一般。真正生产级的 RAG 通常会在四个方向上做增强：

6.1 Query 改写（让问题更适合检索）

用户的问题往往是口语化、模糊的，直接拿去检索效果差。常见技巧：

Query Rewriting：让 LLM 把"那个东西怎么用"改写成"产品 X 的使用方法"
HyDE（Hypothetical Document Embeddings）：先让 LLM 生成一个假设性答案，再用这个答案的向量去检索——因为"答案"和"答案"的语义比"问题"和"答案"更接近
Multi-Query：把一个问题拆成多个子问题分别检索，结果合并去重
Step-back Prompting：先抽象出上位概念再检索，比如"2024 年诺贝尔物理学奖得主"先退到"诺贝尔物理学奖近年得主"

6.2 混合检索 + Rerank（多路召回，精排提纯）

单靠向量检索有个问题：它擅长语义匹配，但对专有名词、产品型号、人名这种精确字面匹配反而不如传统检索。所以生产系统通常用混合检索：

向量检索（语义）+ BM25 关键词检索（字面）并行召回
用 RRF（Reciprocal Rank Fusion） 融合两路结果
再用 Cross-Encoder 重排模型（如 bge-reranker-large、Cohere Rerank）对召回结果做精排
最后取 Top-K 喂给 LLM

Rerank 的关键区别：Embedding 是把 query 和 doc 分别编码再算相似度（双塔），而 Cross-Encoder 是把 query 和 doc 拼一起送进模型（交叉编码），精度高得多，但速度慢——所以先用向量检索粗筛，再用 Rerank 精排，兼顾速度和精度。

6.3 GraphRAG：基于知识图谱的全局检索

微软 2024 年提出的 GraphRAG 解决的是朴素 RAG 的另一个痛点：局部性。向量检索只能召回和问题相似的片段，回答不了"总结整个文档集的核心主题"这种全局性问题。

GraphRAG 的做法：

用 LLM 从文档中抽取实体和关系，构建知识图谱
用社区检测算法（如 Leiden）把图谱分成主题层次化的社区
为每个社区生成摘要
查询时根据问题粒度选择社区摘要或具体节点回答

它特别适合"全局性总结"“跨文档推理"类问题，代价是建图成本高、更新麻烦。

6.4 Self-RAG / 自适应 RAG：让模型自己决定要不要检索

不是每个问题都需要检索——“1+1 等于几"还去查库就浪费了。Self-RAG 让模型学会自我反思：

是否检索：判断问题是否需要外部知识，简单问题直接答
检索结果是否相关：过滤掉无关片段
生成是否忠于检索：检查答案有没有脱离资料编造

好处是省 token、降延迟，坏处是需要训练模型学会这些判断（或用 prompt 模拟），实现复杂度高。

七、方案对比：RAG vs 微调 vs 长上下文

随着模型上下文窗口越来越长（Claude 200K、Gemini 1M、GPT-4o 128K），有人质疑 RAG 是不是过时了——直接把所有文档塞进上下文不就行了？

实际并非如此，三者各有定位：

长上下文：贵（按 token 计费）、易"迷失在中间”（Lost in the Middle 现象）、不可溯源。适合一次性分析单份长文档
RAG：经济、可扩展到海量文档、可溯源。适合知识库问答
微调：改变模型行为/风格，而非注入事实知识。适合固定格式输出、领域术语适配
RAG + 微调：效果最好，成本最高，用于高精度专业场景

经验法则：知识频繁变化 → RAG；风格/格式固定 → 微调；两者都要 → 结合用。

八、实战：用 LangChain 跑通一个最小 RAG

理论讲完，来看一段能跑的代码。用 LangChain + Chroma + OpenAI 实现 30 行的 RAG：

from langchain_community.document_loaders import TextDocumentLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough
from langchain_core.output_parsers import StrOutputParser

# ① 离线建库：加载 → 切分 → 向量化 → 入库
docs = TextDocumentLoader("knowledge.txt").load()
chunks = RecursiveCharacterTextSplitter(
    chunk_size=500, chunk_overlap=50      # 500 字一段，重叠 50 字
).split_documents(docs)
vectorstore = Chroma.from_documents(
    chunks, OpenAIEmbeddings(model="text-embedding-3-small")
)
retriever = vectorstore.as_retriever(search_kwargs={"k": 4})  # 召回 Top-4

# ② 在线问答：检索 → 增强 → 生成
prompt = ChatPromptTemplate.from_template("""
你是严谨的问答助手，根据以下资料回答问题。资料中没有答案就说"无法回答"，不要编造。

【资料】
{context}

【问题】
{question}
""")

def format_docs(docs):
    return "\n\n".join(d.page_content for d in docs)

rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | prompt
    | ChatOpenAI(model="gpt-4o-mini", temperature=0)
    | StrOutputParser()
)

# ③ 提问
print(rag_chain.invoke("公司请假流程是什么？"))

这段代码虽然简单，但已经包含了 RAG 的所有核心环节。生产化时再把 Embedding 换成 BGE、加上 Rerank、换成 Milvus，骨架不变。

九、常见挑战与优化方向

实际落地 RAG，踩坑往往不在模型，而在检索。下面是常见问题对应的优化手段：

症状	根因	优化方向
检索结果不相关	Query 与文档语义差距大	Query 改写、换更强的 Embedding
召回准确但答非所问	片段顺序/噪声干扰	加 Rerank 精排、调 Top-K
答案不忠于资料	LLM 忽略上下文编造	Prompt 加约束、降 temperature、强制引用
专有名词召回差	纯向量检索短板	加 BM25 混合检索
上下文超长	召回太多塞不下	上下文压缩、LongLLMLingua、换长上下文模型
知识更新延迟	索引重建慢	增量索引、流式更新
答案无法溯源	未保留片段来源	检索结果带 metadata，Prompt 要求标注引用

一个经验：80% 的 RAG 优化工作都在检索阶段，而不是生成阶段。先把检索做准，效果立刻提升一大截。

十、典型应用场景

企业知识问答：基于内部 Wiki、手册、合同的智能客服与员工助手
法律/医疗咨询：基于法条、判例、药品说明、病历的精准问答
代码助手：基于私有代码库的代码生成（Cursor、Copilot Workspace 都用了 RAG 思想）
教育辅导：基于教材的个性化答疑，答案可指向课本页码
智能搜索：搜索引擎的 AI 摘要（Perplexity、Bing Chat、Google AI Overviews）
数据分析：Text-to-SQL，基于数据库 schema 的自然语言查询

总结

RAG 不是某个具体工具，而是一种 “把外部知识检索和大模型生成结合起来” 的架构思想。它的价值在于：让大模型能用最新、最准、可溯源的外部知识来回答问题，而无需重新训练。

回顾本文要点：

核心思想：检索 → 增强 → 生成，让 LLM 从闭卷变开卷
两大阶段：离线建库（切分+向量化+入库）+ 在线问答（检索+增强+生成）
命门在检索：80% 的优化工作都在检索阶段
进阶四件套：Query 改写、混合检索+Rerank、GraphRAG、Self-RAG
方案选择：知识频繁变化用 RAG，风格固定用微调，高精度场景结合使用

随着模型上下文窗口变长、多模态能力增强，RAG 的形态还在演进（比如多模态 RAG、Agentic RAG），但"外挂知识库"这个核心思想短期内不会过时——毕竟，开卷考试永远比背书更可靠。

如果你对其中某个环节（比如向量数据库选型、Embedding 微调、GraphRAG 实现）想深入，欢迎在评论区交流。