​ author：何绍泽

1.向量数据库的发展历史

第一阶段：理论奠基与算法突破（约2010年代之前）

向量数据库的根，扎在几十年前的学术研究里。

• 思想萌芽：早在20世纪60年代，信息检索领域就提出了向量空间模型，开始尝试用向量表示文本并进行相似性检索。
• 深度学习催生需求：进入21世纪，随着深度学习崛起，神经网络开始从图像、音频等非结构化数据中提取出大量的高维向量特征。如何有效管理和检索这些数据，成为新的技术挑战。
• 核心算法出现：这一时期，一系列近似最近邻（ANN） 算法被提出并不断优化。其中，2011年左右提出的HNSW（分层可导航小世界）算法是一个里程碑，它通过构建多层图结构，极大地提升了高维空间中的搜索效率，成为后来许多向量数据库的索引基石。

第二阶段：关键工具的催化（2017年）

如果说算法是引擎，那么2017年Facebook开源的高性能相似性搜索库FAISS，就是为向量数据库的诞生点燃了火花。

• FAISS的出现：FAISS是一个强大的工具库，它集成了多种先进的ANN算法，并针对GPU进行了优化，让开发者能在十亿级数据规模上实现高效检索。但它本身不是一个完整的数据库，缺乏数据持久化、高可用、分布式等企业级功能。
• 从工具到系统的呼唤：FAISS的出现证明了大规模向量检索的可行性，同时也暴露了问题：开发者需要自己处理数据管理、服务部署、容灾备份等一系列复杂的系统工程问题。这直接催生了对专用、完备的向量数据库的迫切需求。

第三阶段：独立产品诞生与初步探索（约2019年-2022年）

在这一时期，向量数据库开始作为一个独立的数据库品类登上舞台。

• 首批产品问世：2019年，Milvus（由Zilliz公司开发）等第一批专为向量设计的数据库管理系统诞生。它们不仅集成了FAISS等优秀的索引算法，还提供了完整的数据增删改查（CRUD）、元数据管理、数据持久化、分布式扩展等能力，真正实现了从“检索库”到“数据库”的飞跃。
• 技术演进：这一阶段，向量数据库主要服务于垂直领域，如推荐系统、图像检索、异常检测等，技术不断打磨，为后续爆发奠定了基础。

第四阶段：大模型引爆，走向繁荣（2022年至今）

这是向量数据库最高光的时刻。2022年底ChatGPT的横空出世，彻底点燃了这一市场。

• 成为大模型的“记忆体”：大语言模型（LLM）存在知识截止日期和“幻觉”问题。而检索增强生成（RAG） 技术的出现，完美地解决了这一痛点。向量数据库在其中扮演了外部知识库和长期记忆的核心角色，为大模型提供最新、最相关的背景知识，从而生成更准确的答案。
• 市场与产品爆发：一夜之间，向量数据库成为AI基础设施的明星。
  • 市场高歌猛进：从2020年到2025年，其市场规模预计将以26.8%的年复合增长率高速增长。大量资本涌入，Pinecone、Zilliz、Weaviate等公司相继获得巨额融资。
  • 产品形态多元化：市场上形成了两大阵营：
    1. 原生向量数据库：如Pinecone、Milvus、Weaviate、Qdrant等，专注于向量场景，性能和专业性突出。
    2. 非原生/传统数据库集成向量能力：如Redis、MongoDB、腾讯云VectorDB等，它们在原有功能基础上增加向量检索插件，方便用户在熟悉的环境中使用。
  • 云原生与全托管：为了降低用户的使用门槛，各大云厂商和创业公司纷纷推出全托管的云服务，让开发者无需关心底层运维，即可快速构建AI应用。

2. 向量数据库基本概念介绍

何为向量？

在数学和物理学中，向量（Vector）是指具有大小和方向的量。

在向量数据库中，向量依然是那个由一组数字组成的有序列表，但它的来源和意义发生了根本性的变化。它不再仅仅是一个抽象的箭头，而是现实世界中非结构化数据的语义核心。

这个向量通常被称为 “嵌入（Embedding）”，在存储表示中他是一个数组[0.125, -0.562, 0.331, …, 0.987]。

2.1 它是怎么来的？如何表示？

现实世界的数据（文字、图片、声音）不能被计算机直接理解语义。我们需要一个“翻译官”——也就是嵌入模型（Embedding Model，一种深度学习模型）——来将它们转换成计算机能计算的数字语言。

• 例如：你把一句 “今天天气怎么样？” 输入到一个训练好的AI模型中。模型会输出一串长长的数字，比如 [0.125, -0.562, 0.331, ..., 0.987]（假设是768个数字）。这串数字就是这句话的向量。

2.2 这个数字列表代表了什么？

这串数字虽然看起来是随机的，但实际上它编码了这句话的语义特征。

• 核心原理：在向量空间中，位置相近（即数学上的“距离近”）的向量，代表着语义相近的内容。
  • “猫追老鼠” 的向量，会离 “小狗啃骨头” 的向量比较近（都是动物行为）。
  • 它会离 “宏观经济学” 的向量非常远（话题完全不同）。
  • “苹果” 这个词的向量，如果在包含水果的句子里训练，它就会离 “香蕉” 近；如果在包含手机的句子里训练，它就会离 “华为” 近。

假设，我们不讨论高维向量，我们抽象为二维向量来表示用于理解学习：
上述的例子在二维空间里存储形态将会是这样：

3.向量数据库比较于传统数据库学习

对比维度	传统关系型数据库（PostgreSQL）	向量数据库（如Milvus、Pinecone、Qdrant）	关键差异
设计目标	结构化数据管理、事务处理、复杂查询	高效向量相似度搜索、非结构化数据处理	根本差异：前者处理结构化数据，后者处理非结构化向量数据
SQL执行流程	1. 词法分析 → 2. 语法分析 → 3. 优化 → 4. 执行 → 5. 返回结果 • 支持完整的SQL（SELECT/JOIN/AGGREGATE）	1. 向量输入 → 2. 索引检索 → 3. 距离计算 → 4. 结果排序 → 5. 返回结果 • 不支持SQL，使用专用API（如search、query）	核心差异：传统数据库有完整SQL流程，向量数据库无SQL解析环节
优化器（Query Optimizer）	• 基于成本模型（I/O、CPU） • 选择最佳执行计划（表连接顺序、索引选择） • 优化JOIN、聚合、子查询等复杂操作 • 例：EXPLAIN ANALYZE展示执行计划	• 无传统优化器，专注于向量搜索效率 • 优化向量索引类型（IVF、HNSW、FAISS） • 选择近似搜索精度（如k=100, 1000） • 例：选择HNSW索引而非IVF-FP	核心差异：传统数据库优化复杂查询，向量数据库优化向量搜索效率
执行器（Executor）	• 执行表扫描、连接、排序、聚合等 • 处理事务（ACID） • 例：执行SELECT * FROM users WHERE age > 30	• 执行向量检索（如search_vectors） • 计算向量间距离（余弦/欧氏） • 返回最近邻结果 • 例：search(query_vector, k=10)	核心差异：传统数据库执行结构化查询，向量数据库执行向量相似度搜索
存储机制	• 行存储（默认）或列存储 • B树索引（用于等值查询） • GiST/SP-GiST索引（用于范围查询） • 有明确的Schema	• 向量索引（IVF、HNSW、FAISS） • 向量存储（如FP16/INT8压缩） • 无Schema（或动态Schema） • 例：Milvus使用IVF_FLAT索引	核心差异：传统数据库用B树索引，向量数据库用向量索引；传统数据库需要Schema，向量数据库更灵活
典型工作负载	• 事务处理（OLTP） • 复杂报表分析（OLAP）	• 相似度搜索（如推荐系统、图像搜索） • 语义搜索（如RAG应用）	应用场景差异：传统数据库用于事务/分析，向量数据库用于AI/ML场景
数据模型	关系模型（表、行、列）	向量模型（向量、距离、嵌入）	根本差异：前者是关系型，后者是向量型
数据类型支持	支持INT, VARCHAR, JSONB等 • 有严格的数据类型检查	仅支持VECTOR类型（如FLOAT[768]） • 无类型检查，支持任意维度向量	关键差异：传统数据库有严格类型系统，向量数据库仅支持向量

深入对比

3.1. SQL执行流程对比

传统数据库（PostgreSQL）	向量数据库
sql<br>SELECT * FROM users WHERE age > 30 AND city = 'Beijing';<br>
• 词法分析：解析SQL语法 • 语法分析：构建AST（抽象语法树） • 优化：选择索引（如age_idx） • 执行：扫描表、过滤、排序 • 返回：结果集	python<br>results = collection.search(query_vector, k=10)<br>
• 向量输入：接收查询向量 • 索引检索：在向量索引中查找 • 距离计算：计算余弦/欧氏距离 • 结果排序：按距离排序 • 返回：Top-K结果列表
关键点：传统数据库处理结构化查询，向量数据库处理向量搜索，无SQL解析环节	关键点：向量数据库不使用SQL，而是使用向量API，执行流程更简单

3.2. 优化器对比

传统数据库	向量数据库
• 优化器基于成本模型（如I/O成本、CPU成本） • 例：EXPLAIN ANALYZE显示使用age_idx索引 • 优化JOIN顺序、子查询等复杂操作	• 优化器专注于向量索引选择 • 例：选择HNSW（高精度）vs IVF_FLAT（低延迟） • 优化近似搜索精度（k=100 vs k=1000） • 无JOIN、聚合等优化
关键点：传统数据库优化复杂查询，向量数据库优化向量搜索效率	关键点：向量数据库没有传统优化器，优化目标不同

3.3. 执行器对比

传统数据库	向量数据库
• 执行表扫描、JOIN、排序、聚合 • 处理事务（ACID） • 例：执行SELECT COUNT(*) FROM users	• 执行向量检索 • 计算向量距离（余弦/欧氏） • 返回Top-K结果 • 例：search(query, k=10)
关键点：传统数据库执行结构化查询	关键点：向量数据库执行向量相似度搜索

3.4. 存储机制对比

传统数据库	向量数据库
• 行存储（默认）：存储整行数据 • 列存储：用于分析型查询 • B树索引：用于等值查询 • GiST索引：用于范围查询	• 向量索引：IVF、HNSW、FAISS • 向量压缩：FP16/INT8存储（节省50%+空间） • 无Schema：动态添加向量，无需预定义结构
关键点：传统数据库存储结构化数据，需严格Schema	关键点：向量数据库存储非结构化向量，存储优化针对向量特性

3.5应用场景对比

场景	传统数据库（PostgreSQL）	向量数据库
电商推荐系统	• 存储用户订单、商品信息 • 用SQL查询SELECT * FROM orders WHERE user_id=123	• 存储商品嵌入向量 • 用向量搜索search(product_vector, k=5)
文档检索系统	• 存储文档内容，用全文索引 • 用tsvector搜索	• 存储文档嵌入向量 • 用向量搜索search(document_vector, k=3)
用户画像分析	• 用SQL聚合统计用户行为 • 例：SELECT AVG(age) FROM users	• 存储用户嵌入向量 • 用向量搜索找相似用户

4.向量数据库索引算法

算法名称	核心思想	关键特点	适用场景
FLAT (暴力索引)	全量暴力计算，精确但慢	优点：100%召回率，无需训练 缺点：大数据集下速度极慢，内存占用高	小规模数据集、需要100%精确结果的场景（如数据校验）
IVF (倒排文件)	先聚类（分区），再在局部搜索	优点：速度快，内存占用较低 关键参数：nlist（聚类中心数）、nprobe（搜索的聚类数）	亿级以上超大规模数据集、内存有限但追求高速度的场景
HNSW (分层小世界图)	构建多层图结构，层层递进搜索	优点：速度极快，召回率极高 缺点：内存占用高，构建时间长	对查询延迟和精度要求极高、且数据量可放入内存的场景（如在线实时推荐）
LSH (局部敏感哈希)	将相似的向量以高概率映射到同一个"桶"中	优点：理论上速度很快 缺点：实际召回率可能不稳定，需要多张哈希表	大规模数据的极快速粗筛，对精度要求不高的场景

其中两种最核心的算法：IVF系列和HNSW。

3.1倒排文件索引（IVF系列）

IVF的核心思想是“分而治之”，通过将庞大的向量空间划分成一个个小的区域，来避免大海捞针。

• 基本原理：想象一下，你要在一个巨大的图书馆里找一本书。你不会一本一本地翻遍所有书，而是先通过索引找到它应该在哪个书架（分区）。IVF就是做类似的事情。它首先使用聚类算法（如K-Means）将整个向量空间划分为 nlist 个聚类区域，每个区域有一个中心点。当我们需要搜索时，先找到离查询向量最近的 nprobe 个聚类中心，然后只在这几个区域内进行详细搜索，从而极大地减少了计算量。
• 主要的IVF变体：为了进一步优化内存和速度，IVF衍生出了多种变体：
  • IVF_FLAT：最基本的IVF。在每个选中的聚类内部，它进行精确的距离计算。这种方式在不压缩数据的前提下，实现了速度和精度的平衡，是理解IVF的入门选择。
  • IVF_PQ (乘积量化)：这是内存优化的高手。它将高维向量分割成更小的子向量，并对每个子向量进行压缩编码。它能在牺牲少量精度的情况下，大幅降低内存占用。例如，通过PQ量化，一个原本需要286GB内存的1亿条768维向量数据集，可以被压缩到仅需0.56GB。这使得在有限内存中处理超大规模数据成为可能。
  • IVF_SQ (标量量化)：另一种压缩方法，通过将每个维度的浮点数（如32位）转换为占用更少比特位的整数（如8位），来减少内存占用。

3.2分层可导航小世界（HNSW）

如果说IVF像是一个高效的图书管理员，那么HNSW就像一个拥有多层地图的智能导航系统。

• 基本原理：HNSW算法受启发于社会网络中的“六度分隔”理论，即通过少量中间人就可以认识世界上的任何人。HNSW通过构建一个多层的图结构来实现快速搜索。
  • 上层：是“高速路”，连接稀疏但跨度大的节点，用于在搜索初期快速定位到大致区域（zoom-out过程）。
  • 下层：是“街区小巷”，连接密集的邻近节点，用于在目标区域内进行精细搜索（zoom-in过程）。
• 搜索过程：搜索从一个最上层的随机入口点开始，在当前层找到最接近查询向量的节点，然后以此为入口进入下一层继续搜索，层层递进，直到在最底层找到最终的K个最近邻居。这种机制使得HNSW在速度和召回率上达到了很好的平衡。这也是为什么它被许多数据库（如Apache Doris、腾讯云VectorDB）作为核心索引算法之一。

5.向量数据库的作用位置

以豆包为例：

1. 接入与解析：你的提问（如“豆包的向量模型有哪些？”）首先通过API网关到达。AI智能体（Agent）会分析你的意图，判断是否需要调用外部知识来回答。
2. 问题向量化：一旦确定需要知识库支持，Agent会调用Embedding模型服务（如 doubao-embedding），将你的文本问题也转换成计算机能理解的“语义向量”。
3. 数据检索（向量数据库）：带着这个“问题向量”，Agent向**向量数据库（VikingDB）发起查询。VikingDB内部通过高效的索引算法（如HNSW），在海量向量中高速检索，找到与问题语义最相似的Top-K个知识片段（文本块）**并召回。这一步是RAG系统的核心，也是向量数据库价值的集中体现。
4. 增强生成：Agent将召回的 Knowledge Chunks 和你最初的提问，连同系统指令一起组装成一个“增强版”的提示词（Prompt），然后调用大语言模型服务（如 Doubao-pro）。大模型基于这个包含了精准上下文的提示词，生成最终答案。
5. 返回与应用：最终生成的答案沿着原路返回，通过API网关呈现给你。同时，Agent可能会将本轮对话的上下文信息存入Redis这样的缓存中，以便在多轮对话中保持连贯。

6.目前开源向量数据库有哪些？

项目名称	开源地址	核心特点与简介
Milvus	https://github.com/milvus-io/milvus	云原生、分布式，专为海量向量场景设计。它采用微服务架构，支持水平扩展，能处理十亿级向量数据，是许多企业构建生产级AI应用的首选之一 。
Qdrant	https://github.com/qdrant/qdrant	使用 Rust 语言编写，以高性能和内存安全著称。它提供了强大的负载过滤功能，允许在向量搜索时结合复杂的元数据条件进行精准筛选，非常适合对搜索精度和过滤条件要求高的场景 。
Weaviate	https://github.com/weaviate/weaviate	一个云原生、AI原生的向量数据库。它不仅存储向量和对象，还内置了机器学习模块，可以在数据库内部直接完成数据向量化，并提供了开箱即用的混合搜索能力（结合向量与关键词搜索）。
Chroma	https://github.com/chroma-core/chroma	专注于轻量级和开发者体验，为Python而生。它设计简洁，API友好，可以快速嵌入到AI应用中，特别适合做RAG的原型开发和小型项目 。
pgvector	https://github.com/pgvector/pgvector	它不是独立的数据库，而是为 PostgreSQL 提供的向量检索扩展。如果你已经在使用PostgreSQL，希望在一个系统内同时管理业务数据和向量数据，它是最自然的选择，能有效简化技术栈 。
Redis ( with RediSearch )	https://github.com/redis/redis	Redis本身是一个内存数据库，通过其 RediSearch 模块添加了对向量检索的支持。它的优势在于极低的延迟（毫秒级），并能在一个系统中同时处理向量检索、缓存和会话管理等多种任务 。
Faiss	https://github.com/facebookresearch/faiss	严格来说，它不是一个数据库，而是由 Facebook AI Research 开源的高效相似性搜索库。它提供了最前沿的向量索引算法，是许多向量数据库的底层引擎。适合需要深入定制算法或在特定硬件上优化的研究人员 。

7.开源的Embedding模型有哪些？

模型名称	作者/公司	模型大小	语言支持	主要特点	开源地址
Qwen3-Embedding	阿里通义	0.6B/4B/8B	119种语言	• 支持表征维度自定义 • 指令适配优化 • MTEB多语言Leaderboard排名第一（8B版本） • 专为文本表征、检索与排序任务设计	• ModelScope： https://modelscope.cn/collections/Qwen3-Embedding-3edc3762d50f48 • Hugging Face： https://huggingface.co/collections/Qwen/qwen3-embedding-6841b2055b99c44d9a4c371f • GitHub： https://github.com/QwenLM/Qwen3-Embedding
Qwen3-VL-Embedding	阿里通义	8B	超30种语言	• 多模态向量表示模型 • 专为图文、视频等混合内容设计 • MMEB-v2基准测试中超越所有开源模型	• ModelScope： https://modelscope.cn/collections/Qwen3-VL-Embedding-6841b2055b99c44d9a4c371f • Hugging Face： https://huggingface.co/collections/Qwen/qwen3-vl-embedding-6841b2055b99c44d9a4c371f
GTE-Qwen1.5-7B-instruct	阿里通义	7B	多语言	• 指令驱动嵌入模型 • 适合复杂指令任务 • 专注于指令理解和执行	知识库未提供具体开源地址
GTE-Qwen2-7B-instruct	阿里通义	7B	多语言	• 70亿参数大型嵌入模型 • 专注于指令驱动任务优化 • 适合复杂对话系统	知识库未提供具体开源地址
acge_text_embedding	TextIn团队	-	多语言	• 曾登顶C-MTEB榜首 • 采用对比学习技术 • 使用MRL技术降低存储需求	• Hugging Face： https://huggingface.co/aspire/acge_text_embedding • API： https://www.textin.com/market/detail/acge_text_embedding
EmbeddingGemma	Google	308M	100+种	• 支持离线运行、保护隐私 • 内存占用小，兼容多种推理框架 • 支持MRL技术（可变维度嵌入）	• Hugging Face： https://huggingface.co/google/EmbeddingGemma
Sentence Transformers	Hugging Face	多种	中文	• 提供多种预训练模型 • 包含中文模型如’shibing624/text2vec-base-chinese’ • 适用于语义相似度计算	• Hugging Face： https://huggingface.co/sentence-transformers
xiaobu-embedding-v2	-	-	中文	• 针对中文语义优化 • 语义理解能力高	知识库未提供具体开源地址
zpoint_large_embedding_zh	-	-	中文	• 适用于大规模中文语义分析 • 高精度嵌入表示	知识库未提供具体开源地址
IYun-large-zh	-	-	中文	• 专为中文语境优化 • 捕捉细微语义差异	知识库未提供具体开源地址
piccolo-large-zh-v2	-	-	中文	• Piccolo系列第二版 • 针对中文文本优化	知识库未提供具体开源地址
AGE_Hybrid	-	-	多语言	• 多语言嵌入模型 • 结合多任务优化策略	知识库未提供具体开源地址