向量数据库原理：从嵌入到相似搜索的完整技术体系

传统关系型数据库擅长存储结构化数据并执行精确匹配查询。但当面对非结构化数据——文本、图像、音频、视频——时，关系模型的局限性就暴露出来了。

核心问题是：非结构化数据无法用等于号（=）来比较。两段文本是否相似、两张图片是否属于同一类别、两段语音是否说了同样的话——这些问题无法通过字符串匹配或数值比较来回答。

向量数据库的解决方案是将非结构化数据转换为高维向量（也称为嵌入 Embedding），然后在向量空间中计算相似度。两个向量在空间中越接近，它们代表的原始数据就越相似。

这种范式转换带来了三个关键优势：

• 语义搜索：不再依赖关键词匹配，而是理解查询的真正含义。搜索"如何学习编程"可以返回"编程入门指南"，即使没有任何共同关键词。
• 多模态检索：文本、图片、音频都转换为向量后，可以在同一空间中进行跨模态检索。
• RAG 架构的基石：检索增强生成（RAG）依赖向量数据库来存储和检索知识库，让大语言模型能够基于最新、最相关的信息生成回答。

理解向量数据库是理解现代 AI 应用架构的第一步。无论是推荐系统、语义搜索、还是 RAG 应用，底层都依赖向量相似搜索。

嵌入是向量数据库的数据源。没有好的嵌入模型，向量数据库只是一个存储浮点数数组的空壳。

嵌入的本质是将高维离散空间（如词汇表、像素空间、频谱空间）映射到低维连续向量空间，使得语义相近的事物在向量空间中也距离相近。这个过程也称为降维或表征学习。

以文本嵌入为例，假设我们有一个包含 50000 个词的词汇表。每个词可以用一个独热编码（One-Hot Encoding）表示——一个 50000 维的向量，只有一个位置为 1，其余为 0。但独热编码有几个致命问题：

• 维度灾难：50000 维向量非常稀疏，存储和计算成本极高
• 语义鸿沟：「猫」和「狗」的独热编码完全不相关，但它们在实际语义中非常接近
• 无法表达多义性：同一个词在不同上下文中的含义完全不同

现代嵌入模型（如 OpenAI 的 text-embedding-3-large、Google 的 text-embedding-004、以及开源的 bge-large-zh-v1.5）通过深度神经网络训练，将文本编码为 768-3072 维的稠密向量。这些模型在训练时学习了大量语料中的共现模式和语义关系，使得编码后的向量能够捕捉文本的深层语义。

嵌入模型的训练方式主要有三种：

• 对比学习（Contrastive Learning）：让模型学会将语义相似的文本拉近、不相似的文本推远。这是最主流的嵌入训练范式。
• 因果语言建模（Causal LM）：通过预测下一个词来学习语言的结构和语义。
• 掩码语言建模（Masked LM）：通过预测被掩码的词来学习上下文理解能力。

选择嵌入模型时的关键考量包括：

截至 2026 年 5 月，中文场景推荐的嵌入模型包括：BAAI/bge-m3（支持 100+ 语言，MTEB 排行榜前列）、Alibaba/gte-Qwen2-7B-instruct（阿里通义实验室出品）、以及 OpenAI text-embedding-3-large（英文表现最佳）。

有了向量，下一个问题是：如何计算两个向量之间的相似度？ 这不是一个简单的问题，因为距离度量方式的选择会直接影响搜索结果的质量。

主流的向量距离度量有三种：

余弦相似度（Cosine Similarity）：计算两个向量之间夹角的余弦值，范围 [-1, 1]，值越大表示越相似。这是最常用的度量，因为它只关心方向（语义），不关心向量的长度（幅度）。在大多数嵌入模型输出已经归一化的情况下，余弦相似度等价于向量点积。

欧氏距离（Euclidean Distance / L2）：计算两个向量之间的直线距离。值越小表示越相似。欧氏距离对向量的幅度敏感——如果嵌入模型没有做归一化，幅度大的向量可能会主导距离计算。

内积 / 点积（Inner Product / Dot Product）：直接计算两个向量的点积。当向量已经归一化时，点积等价于余弦相似度。这是许多向量数据库的默认度量，因为它计算速度最快——只需要做向量乘法然后求和。

选择建议如下：

• 如果嵌入模型输出已归一化（大多数现代模型都是），三种度量效果基本一致，选择点积以获得最佳性能。
• 如果嵌入模型输出未归一化，优先选择余弦相似度，避免向量幅度偏差。
• 如果业务场景需要考虑语义强度（如区分「喜欢」和「热爱」），选择欧氏距离。

实践中，90％ 的应用场景使用余弦相似度或点积就足够了。只有在特殊需求下才需要考虑其他度量。

如果只有几百个向量，暴力搜索（逐个计算距离然后排序）完全可以胜任。但当向量数量达到百万级甚至十亿级时，暴力搜索的 O(n) 复杂度就不可接受了。

近似最近邻（Approximate Nearest Neighbor, ANN）算法的核心理念是牺牲少量精度，换取搜索速度的数量级提升。典型的 ANN 算法可以在毫秒级从十亿向量中找到最近邻，精度损失通常不到 5％。

主流 ANN 算法可以分为四类：

第一类是基于树的算法（如 KD-Tree、Annoy）。

KD-Tree 通过递归地沿某个维度切分向量空间，构建一棵二叉搜索树。查询时沿着树的分支向下遍历，只访问与目标向量相邻的区域。这种方法的优点是精度高，缺点是在高维空间（100 维以上）效率急剧下降——这就是所谓的「维度灾难」。

Annoy（Approximate Nearest Neighbors Oh Yeah）是 Spotify 开源的基于随机投影树的算法。它构建多棵随机树，每棵树通过随机超平面切分空间。查询时在每棵树中搜索，然后合并结果。Annoy 的索引是只读的，构建后不能增量插入，但查询速度极快。

第二类是基于图的算法（如 HNSW、NSG）。其中 HNSW（Hierarchical Navigable Small World）是当前最流行的 ANN 算法，被 Milvus、Qdrant、Weaviate 等主流向量数据库采用。它构建多层图结构：上层是大跨度的快速导航层，下层是精细搜索层。查询时从顶层开始，快速接近目标区域，然后在底层精细搜索。HNSW 在精度和速度之间取得了最佳平衡，也是本文重点介绍的算法。

第三类是基于量化的算法（如 PQ、IVF-PQ）。乘积量化（Product Quantization, PQ）将高维向量切分为多个低维子向量，每个子向量分别聚类为 K 个簇，然后用簇中心的索引代替原始子向量。这样 128 维的浮点向量可以被压缩为 8-16 字节的整数序列，压缩比可达 10-50 倍。FAISS 是这一类算法的代表实现。

第四类是基于哈希的算法（如 LSH）。局部敏感哈希（Locality-Sensitive Hashing, LSH）设计一种特殊的哈希函数，使得相似的向量更可能碰撞到同一个哈希桶中。查询时只需检查目标桶内的向量。LSH 的速度极快，但精度通常低于 HNSW 和 PQ，适合对延迟要求极高但对精度要求不苛刻的场景。

算法选型对比：

2026 年的趋势是混合索引——结合多种算法的优势。例如 FAISS 的 IVF-HNSW 先用 IVF 粗筛缩小搜索范围，再用 HNSW 精细搜索，兼顾速度和内存效率。

HNSW 是当前向量数据库中使用最广泛的 ANN 算法。理解它的工作原理，对调参和排查搜索性能问题至关重要。

核心思想：多层图结构。

想象你在一座大城市中从一个位置走到另一个位置。如果你只有街道地图（单层），你需要逐条街道搜索。但如果你有一张地铁图（高层），你可以先坐地铁快速接近目标区域，再步行精细搜索。HNSW 就是给向量空间构建了一张「地铁图」。

HNSW 的多层图结构：

• 顶层（Layer M）：节点稀疏，每个节点连接远处的节点，实现大跨度跳转。
• 中间层：节点密度逐渐增加，连接范围逐渐缩小，实现中等跨度导航。
• 底层（Layer 0）：包含所有节点，密集连接，实现精细搜索。

插入过程：

1. 新向量以一定概率被分配到不同的层数（概率遵循指数衰减，大多数向量只在底层，少数向量进入高层）。
2. 从最高层开始，在每层中找到距离目标最近的节点，作为下一层搜索的入口点。
3. 在每一层中，从入口点出发，检查邻居节点，选择更近的邻居继续前进（贪心搜索），直到当前层找不到更近的邻居。
4. 在底层，找到 K 个最近邻后，根据配置决定是否将新向量插入图结构中。

搜索过程与插入类似，但不插入新节点：从顶层开始快速导航，逐层向下精细搜索，最终在底层返回 K 个最近邻。

关键参数：

• M（最大连接数）：每个节点在每层的最大邻居数量。M 越大，图越密集，搜索越精确但内存消耗越大。推荐值 16-64，通常 16 是性能和精度的良好平衡。
• efConstruction（构建时搜索范围）：构建索引时每步探索的候选节点数。越大索引质量越高但构建越慢。推荐值 100-500。
• efSearch（搜索时探索范围）：查询时每步探索的候选节点数。越大结果越精确但查询越慢。推荐值 50-200，可以根据精度要求动态调整。

调参经验：

• 如果搜索速度太慢：降低 efSearch 或 M
• 如果搜索结果精度不够：提高 efSearch 或 efConstruction
• 如果内存不足：降低 M（每减少 1，内存消耗降低约 6％）

2026 年 5 月，Milvus 和 Qdrant 的最新版本已经支持动态 efSearch 调整——系统根据查询负载自动调节搜索范围，在高峰期降低精度换取吞吐量，在低峰期提高精度。

2026 年的向量数据库生态已经非常成熟。选择哪个数据库取决于你的部署方式、数据规模、功能需求和运维能力。

Milvus（开源）

由 Zilliz 公司开源，是目前最流行的开源向量数据库。支持 HNSW、IVF、SCANN 等多种索引，支持分布式部署和 GPU 加速。社区活跃，文档完善。适合需要自建基础设施的团队。

• 优势：开源免费、功能全面、分布式架构、社区大
• 劣势：运维复杂度高、资源消耗大
• 适用场景：中大型企业、需要完全控制基础设施

Qdrant（开源 + 托管）

Rust 编写，性能优异，支持过滤条件与向量搜索的混合查询。API 设计友好，Python SDK 体验很好。托管版本提供免费 tier。

• 优势：性能好（Rust）、API 优雅、支持混合查询
• 劣势：分布式功能相对较新、中文社区较小
• 适用场景：中小型项目、快速原型验证

Pinecone（托管）

纯托管服务，无需运维。支持 Serverless 模式，按用量付费。API 极简，集成方便。但不开源，价格较高。

• 优势：零运维、Serverless、集成简单
• 劣势：不开源、价格高、定制能力有限
• 适用场景：初创团队、不想管基础设施

FAISS（库，非数据库）

Meta 开源的向量搜索库，不是完整的数据库系统。提供多种 ANN 算法实现，需要自己封装为服务。

• 优势：算法最全、性能极高、灵活
• 劣势：不是数据库（无持久化、无 API）、需要自己搭建服务
• 适用场景：算法研究、嵌入式场景、自定义系统

Weaviate（开源 + 托管）

内置向量化和模块化管理，支持多种嵌入模型直接集成。GraphQL API 设计独特。

• 优势：内置向量化、模块化管理、GraphQL
• 劣势：学习曲线较陡、生态相对较小
• 适用场景：需要端到端向量搜索方案的团队

选型决策矩阵：

向量数据库最常见的应用场景是 RAG（检索增强生成）。理解这个场景，对设计 AI 应用架构至关重要。

RAG 的核心流程：

1. 知识库向量化：将文档、FAQ、手册等知识内容分段（Chunk），每段通过嵌入模型转换为向量，存入向量数据库。
2. 查询向量化：用户的提问通过相同的嵌入模型转换为查询向量。
3. 相似性检索：在向量数据库中找到与查询向量最相似的 K 个知识片段。
4. 上下文增强：将检索到的知识片段附加到 LLM 的 Prompt 中，让模型基于这些知识生成回答。

分块（Chunking）策略是 RAG 性能的关键：

• 固定长度分块：按固定 token 数（如 512）切分，实现简单但可能切断语义单元。
• 语义分块：在段落边界、标题边界或主题变化处切分，保持语义完整性。
• 递归分块：先按大单元切分，再对过大单元递归细分，兼顾效率和语义完整性。

分块大小的权衡：

• 太小（100-256 token）：检索精度高，但上下文信息不足，LLM 可能无法理解片段含义。
• 适中（512-1024 token）：在精度和上下文完整性之间取得平衡，是大多数场景的推荐值。
• 太大（2000+ token）：包含更多上下文，但检索精度下降（大向量容易与多种查询产生中等相似度匹配）。

2026 年的最佳实践是动态分块——根据文档结构（标题、段落、列表、代码块）自动调整分块策略。例如，代码块保持完整不切分，而长段落按语义边界切分。

RAG 的性能优化：

• 元数据过滤：在向量搜索之前先用元数据（如文档类型、时间范围、语言）过滤，减少搜索空间。
• 混合检索：结合向量搜索和关键词搜索（BM25），互补两种方法的优缺点。
• 重排序（Reranking）：先用向量搜索快速召回 Top-100 候选，再用精排模型（如 Cohere rerank、bge-reranker）精排 Top-10。
• 缓存：对高频查询结果进行缓存，避免重复向量搜索。

将向量数据库从开发环境推向生产环境，需要解决几个关键问题：

持久化与备份

向量数据库的索引通常占用大量内存。生产环境必须确保：

• 索引可以持久化到磁盘，服务重启后能快速恢复
• 定期备份原始向量和索引文件
• 考虑跨地域复制，防止单点故障

监控与告警

需要监控的关键指标：

• 查询延迟：P95 和 P99 延迟是否在 SLA 范围内
• 索引构建进度：增量插入是否导致性能退化
• 内存使用率：是否接近上限，是否需要扩容
• 搜索精度：定期用标准测试集验证 ANN 结果的精度是否在可接受范围内
• 写入吞吐量：增量更新的速率是否满足业务需求

性能调优清单

• 调整 HNSW 的 efSearch 以平衡延迟和精度
• 使用批量插入代替逐条插入，提升构建速度
• 对高频查询结果建立缓存层（如 Redis）
• 使用混合索引（IVF + HNSW）降低内存消耗
• 为不同业务场景创建独立的 Collection，避免索引过大

安全考虑

• 向量数据库中的向量可以逆向推断原始数据——研究表明，给定足够多的嵌入向量和对应的嵌入模型，可以近似恢复原始文本。因此，向量数据中的敏感信息需要加密存储。
• 访问控制：生产环境的向量数据库应该与业务 API 同属一个权限体系，不能裸暴露在公网。
• 数据生命周期：过期的知识片段需要定期清理，避免向量库无限膨胀。

2026 年的新趋势是向量数据库原生支持 RBAC（基于角色的访问控制）和字段级加密，这使得在共享基础设施上运行多租户向量搜索服务成为可能。

以下是学习向量数据库和向量搜索的推荐资源：

经典论文：

• HNSW 原始论文：「Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs」（2018）
• Product Quantization：「Product Quantization for Nearest Neighbor Search」（2011）
• FAISS 论文：「Billion-scale similarity search with GPUs」（2019）

实践资源：

• Milvus 官方文档：milvus.io/docs（中英文）
• Qdrant 官方文档：qdrant.tech/documentation
• Pinecone 学习中心：docs.pinecone.io/learn
• FAISS GitHub：github.com/facebookresearch/faiss

相关主题：

• RAG 架构设计：llm-002（检索增强生成架构）
• LoRA 高效微调：llm-003（结合向量数据库做个性化微调）
• LLM 评测基准：llm-010（如何评估 RAG 系统的检索质量）
• LLM 部署实践：llm-012（向量数据库与推理服务的联合部署）