首页 / 文章 / 向量数据库的运作原理：从嵌入模型到混合搜索

Vector Databases Embeddings RAG Semantic Search Azure AI Search HNSW

向量数据库的运作原理：从嵌入模型到混合搜索

解释了嵌入如何编码含义、相似性搜索与索引的扩展方式，以及混合搜索和向量数据库何时真正适用于企业级人工智能系统。

1832 词

当开发者刚开始使用生成式AI系统时，总会出现这样一句话：

“我明白SQL数据库的运作原理，但向量数据库对我来说仍然像是个黑箱。”

这种看法其实很合理。

传统数据库是通过结构化的关系来处理查询的：

SELECT * FROM customers WHERE country = 'India';

而向量数据库则是为了解答完全不同类型的问题而设计的：

“哪些存储的内容与这个查询的含义最为接近？”

这种提问方式的转变，正是当今众多人工智能应用背后的核心所在。

RAG流程、语义搜索、推荐系统、基于文档的助手以及自主智能体，都严重依赖这一功能。

最重要的并非数据库技术本身。

它阐明了向量实际上编码了什么、如何衡量向量之间的相似度，以及为何选择正确的索引方法如此重要。

嵌入到底是什么？

将含义转化为数字

考虑这样一句话：

"Employees can work remotely for up to 30 days."

嵌入模型会将其转换为一个向量：

[0.021, -0.184, 0.731, 0.092, ...]

在实际应用中，嵌入向量的维度可达数百甚至数千。

不要误以为各个数字代表：

“这个特定数值对应单词‘employee’。”

这并非准确的概念模型。

实际上，向量是对文本语义特征经过学习后得到的数值编码。

基于此，像这样的句子：

"I love my dog."
"My puppy is my favorite companion."

通常生成的向量会比如下这类配对中的向量更接近。

"I love my dog."
"The database connection timed out."

这就是其核心运作机制。

含义会被转化为可以通过数学方式检索的形式。

生成嵌入向量

使用模型生成嵌入向量的流程十分简单：

from openai import OpenAI

client = OpenAI()

response = client.embeddings.create(
    model="text-embedding-3-small",
    input="Employees can work remotely for up to 30 days."
)

vector = response.data[0].embedding
print(len(vector))
print(vector[:5])

生成的向量并非供人类直接阅读的。

这没有问题。

原始数值并非为人类设计的受众群体。

关键在于将此向量与其他向量进行比较。

相似性才是核心理念

从根本上说，向量数据库是在数学空间中进行搜索的

假设你有三个源文档：

A -> Remote work policy
B -> Travel reimbursement policy
C -> Employee leave policy

而你的查询是：

"Can I work from home while travelling abroad?"

首先会对查询进行嵌入处理。

随后将该查询向量与每份文档的向量进行比较。

此处常用的相似度度量标准是余弦相似度：

import numpy as np

def cosine_similarity(a, b):
   return np.dot(a, b) / (
      np.linalg.norm(a) *
      np.linalg.norm(b)
   )

从视觉上看，其表现如下：

较大的余弦相似度值通常表明两个向量的方向更为接近。

当向量被归一化后，余弦相似度在数学上会接近点积相似度。

这种关联性解释了为何这两个概念在向量搜索系统的讨论中频繁出现。

为什么不能直接比较所有向量？

尺度问题是导致朴素方法失效的原因

想象一个包含以下内容的数据集：

1,000 documents

在那种规模下，将查询与每一个向量进行比较是极其简单的。

现在再想象：

100 million vectors

在那种规模下对所有向量进行全面比较会耗费大量资源。

这正是向量索引所要解决的问题。

与其逐一检查每个向量，近似最近邻技术通过对向量空间进行结构化处理，使得查找高度相似的向量速度大幅提升。

这类技术中较为著名的一类是HNSW——分层可导航小世界图。

即便不想自行构建HNSW，也能从向量搜索中获益。

你需要理解的是其背后的权衡：

在精确搜索精度上做出一定牺牲，就能换来速度上的显著提升以及更好的扩展能力。

这种权衡正是向量数据库运作机制的核心所在。

向量索引究竟存储了什么？

在实际应用中，每条存储的记录通常不仅仅包含嵌入向量：

document = {
    "id": "policy-1042",
    "title": "Remote Work Policy",
    "content": "Employees can work remotely...",
    "department": "HR",
    "country": "India",
    "embedding": vector
}

这个细节非常重要。

该嵌入内容并不能替代完整文档。

它实际上是一种便于索引的文档表示形式。

除此之外，您仍需保留：

原始文本、元数据、唯一标识符、访问控制信息以及指向源文件的引用

当您为企业构建RAG系统时，这一点就显得尤为重要。

Azure AI Search

向量搜索与企业搜索的交汇点

Azure AI Search除了提供传统的关键词搜索外，还支持基于向量的搜索以及两者的混合搜索方式。

一个简化的向量查询示例如下：

from azure.search.documents.models import VectorizedQuery

vector_query = VectorizedQuery(
    vector=query_vector,
    k_nearest_neighbors=5,
    fields="content_vector"
)
results = search_client.search(
    search_text=None,
    vector_queries=[vector_query],
    select=["title", "content"]
)

返回的结果并不会以这样的形式呈现：

“这是数学上距离最近的句子。”

相反，你会得到一个按顺序排列的文档集合，其排序方式取决于你设置的向量搜索配置。

正是在这一点上，架构决策开始发挥真正的作用。

为何混合搜索往往更胜一筹

基于语义的搜索与基于关键词的搜索在不同场景下各有优势

以这个问题为例：

“HR-2026-17号政策是怎么规定的？”

对于这类查询，关键词搜索表现非常好。

现在再对比这个问题：

“员工可以暂时在另一个国家工作吗？”

在这种情况下，语义搜索显然更具优势。

与其在两种方法之间二选一：

Keyword OR Vector

你可以将它们结合起来：

Keyword + Vector => Hybrid Ranking

Azure AI Search允许你执行混合查询，将全文搜索与向量搜索相结合。

这揭示了一个有用的模式：

results = search_client.search(
    search_text="remote work from another country",
    vector_queries=[vector_query],
    top=10
)

具体的排名设置会因应用场景而异，但核心要点在于：

不要仅依靠嵌入模型来解决所有检索问题。

在企业规模下，元数据过滤并非可选

假设你的向量索引中存储着如下文档：

India HR policies
US HR policies
UK HR policies
Finance policies
Engineering documentation

此时有用户提问：

“印度的差旅报销限额是多少？”

仅依赖语义相似度可能会同时检索到来自多个不同地区的匹配文档。

加入元数据过滤器可以缩小搜索范围：

results = search_client.search(
    search_text=query,
    vector_queries=[vector_query],
    filter="country eq 'India'",
    top=5
)

现在的检索过程结合了两种方法：

Semantic relevance + Structured filtering

这也是数据工程师往往能快速掌握企业级向量搜索的原因之一。

它并不会取代数据库已有的优势功能。

相反，它将非结构化语义检索与人们熟悉的结构化数据处理思路相结合。

Pinecone、Weaviate和Databricks向量搜索

不同供应商，相同的核心理念

你可能会用到的几个平台包括：

Pinecone

一款专为可扩展的向量搜索而构建的全托管向量数据库。

Weaviate

一款开源向量数据库，提供向量搜索、过滤功能以及多种以人工智能为特色的附加功能。

Databricks向量搜索

集成在Databricks平台中的向量搜索功能，当企业数据已存储在湖仓中时尤为实用。

这些工具的界面和操作细节各不相同。

但其核心理念始终如一：

不要将这些产品视为需要单独掌握的独立技术。

首先应理解检索模型本身。

一旦掌握了它，每种产品就只是不同的实现选择而已。

向量数据库真正有用的场景

并非所有人工智能场景都适合使用向量数据库

适用场景包括：

企业级RAG系统

查找相关的政策、文档和技术知识。

语义搜索

基于底层概念进行匹配，而非仅依赖精确的关键词匹配。

支持系统

调出与当前问题相似的历史事件或工单。

代码搜索

查找在语义上与给定问题相关的函数或代码片段。

数据工程助手

负责获取相关的流程文档、架构设计、操作手册以及故障历史记录。

不过，对于结构化分析查询，并不必默认使用向量数据库。

如果问题是：

“第二季度的营收是多少？”

而答案存储在受管控的数据仓库中，那么SQL通常是更合适的工具。

Structured question => SQL
Semantic question => Vector Search
Mixed question => SQL + Vector Search

仅这一区别就能避免许多架构上的错误。

我偏好的企业架构

一个设计良好的检索系统更像是由多个组件构成的流程，而非单一工具。

向量数据库只是该流程中的一个环节而已。

这可能是最需要纠正的误解。

单独使用向量数据库并不能让AI应用变得更智能。

它提供了一种基于语义相似度高效检索信息的方法。

真正的智能源自其周围的方方面面：

嵌入策略、内容的分块方式、附加的元数据、检索逻辑、排序决策、上下文的构建方式、评估方法以及模型本身

需要牢记的心智模型

如果你是从数据工程师转型为人工智能工程师，不要一开始就试图记住各种产品名称。

相反，要牢记以下几点：

Embedding = numerical representation of meaning

Vector Search = find semantically similar representations

Vector Index = make nearest-neighbor search fast

Hybrid Search = semantic + lexical retrieval

Metadata Filter = apply structured constraints

Reranking = improve ordering of retrieved candidates

一旦这六个概念变得通俗易懂，像 Azure AI Search、Pinecone、Weaviate 和 Databricks Vector Search 这样的工具就不再显得神秘莫测了。

它们其实只是解决同一个核心问题的不同方法而已：

面对一个查询，如何从海量数据中提取最实用的信息？

这正是向量数据库至关重要的原因。

它们并非数据库类别中的又一个普通存在。

它们正逐渐成为驱动现代人工智能系统的核心检索层之一。

对于数据工程师而言，这使其值得认真学习——并非因为每个项目都需要向量数据库，而是因为越来越多的人工智能应用在给出正确答案之前，需要一种可靠的方法来找到合适的信息。