向量数据库入门：存储与检索企业知识的核心原理

把文本转成嵌入向量之后，一个更现实的问题立刻浮现：数百万个向量该存在哪里，又如何在毫秒级找到与用户提问最接近的那几个？这正是向量数据库要解决的核心命题。

向量数据库到底是什么

用一个比喻来理解：传统关系型数据库像一排贴着标签的档案柜，你按名字去要“open”文件夹，它准确递给你。向量数据库更像一位理解语义的图书管理员——即使没有完全匹配的标签，他也能根据你的意图，把“意思最接近”的书找出来。

据原文作者 Suresh Pallapothu 的系列文章，关系型数据库擅长的是精确匹配，例如 WHERE status = 'open'。它缺乏高效回答“哪些已存向量离这个查询向量最近”的能力，因为这是一个几何问题。而 Milvus、Qdrant、Pinecone 这类专用向量数据库，从底层就是为存储和索引海量嵌入、并高效完成近邻查询而设计的。

ANN：用一点精度换大量速度

最朴素的办法是把查询向量和库里每一个向量都比一遍。但当文档达到百万量级，这种暴力比对会慢到无法接受。向量数据库的解法是预先构建索引，其中 HNSW（Hierarchical Navigable Small World，分层可导航小世界）是最流行的索引结构之一。

HNSW 把向量连成一张分层图：搜索从粗糙的高层开始，逐层向目标“跳跃”靠近，最终在底层锁定近邻。原文明确指出，这是一种近似最近邻（ANN） 策略——牺牲一点召回精度，换取数量级的速度提升。对于大多数企业检索场景，这个取舍非常划算。

嵌入向量与度量空间是所有向量检索的数学基础。嵌入模型把一段文本映射成一个固定长度的实数向量（常见维度为384、768、1536等），其核心假设是：语义相近的文本，在向量空间中的距离也相近。衡量“距离”的方式主要有三种——余弦相似度（比较方向夹角，对文本长度不敏感，最常用于语义检索）、欧氏距离（L2，比较绝对空间距离）和内积（IP，与向量模长相关）。pgvector 中 <=>、<->、<#> 分别对应这三者，选用哪种距离函数必须与嵌入模型的训练目标一致，否则检索质量会大幅下降。需要注意的是，ANN 索引本身与距离度量绑定：HNSW 在构建时按某种度量组织近邻图，换用另一种度量通常需要重建索引。

pgvector：不必引入新系统

并不是所有团队都愿意为了向量检索再运维一套新数据库。如果你的团队已经在跑 PostgreSQL，pgvector 扩展可以直接为它增加向量列类型和相似度搜索能力。嵌入和普通关系数据放在一起，一条查询就能同时按客户过滤、再按语义排序。

原文给出了一个完整的 pgvector 示例（示例用三维向量仅为缩短篇幅，真实嵌入通常有数百维，vector(3) 应替换为模型实际输出维度，如 vector(1536)）：

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE docs (
  id        serial PRIMARY KEY,
  body      text,
  embedding vector(3)
);

CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);

SELECT body
FROM docs
ORDER BY embedding <=> '[0.80, -0.10, 0.49]'
LIMIT 2;

其中 <=> 表示余弦距离，值越小代表语义越接近。加上 HNSW 索引后，这条查询在数据规模扩大时依然能保持快速。

HNSW 与 IVFFlat 是 pgvector 支持的两类主流索引，二者取舍不同。HNSW 基于多层跳表式图结构，查询时从稀疏的上层图快速逼近，再在稠密底层精确收敛，特点是召回率高、延迟低，但构建慢、内存占用大。IVFFlat 则先用 k-means 把向量聚成若干簇（lists），查询时只扫描与查询向量最近的若干个簇（probes），内存开销小、构建快，但召回率通常低于 HNSW，且需要在数据已有一定量后再建索引才能聚类得合理。选型时可参考：数据量小而要求高精度选 HNSW；数据极大、内存紧张、可容忍略低召回则考虑 IVFFlat。无论哪种，索引参数（如 HNSW 的 m、ef_construction）都会直接影响速度与召回的平衡。

一次完整检索长什么样

把流程串起来：用户的问题先经嵌入模型转成向量，向量数据库找出最接近的已存向量，再把对应段落按接近程度排序返回。原文将其总结为“嵌入问题 → 找最近向量 → 拿回匹配段落”三步。这也正是后续 RAG（检索增强生成）的地基——原文预告 Day 13 将讨论如何用 RAG 与企业私有文档对话。

选型上的三种路径

原文把存储位置归纳为三条路线：

• 专用向量数据库：Milvus、Qdrant、Pinecone，适合大规模、纯向量检索为主的场景；
• PostgreSQL + pgvector：适合已有 PG 技术栈、希望向量与业务数据共存的团队；
• 本地库：适合小规模实验与原型验证。

选择的关键不在于哪个“最强”，而在于你的数据规模、现有技术栈和运维成本之间的平衡。对于多数从零起步的企业知识库项目，先用 pgvector 验证，再按规模决定是否迁移，是一条务实路径。

专用向量数据库的工程优势往往在规模上来后才显现。Milvus、Qdrant、Pinecone 这类系统除了提供 HNSW 等索引外，还内置了面向生产的特性：分布式分片与水平扩展、量化压缩（如乘积量化 PQ、标量量化 SQ）以降低内存占用、元数据过滤与向量检索的联合执行、多租户隔离、以及批量写入和一致性控制。当向量数量达到千万甚至十亿级、或需要高并发低延迟在线服务时，这些能力是单机 pgvector 较难匹配的。反之，若数据规模在百万以内、查询 QPS 不高，pgvector 与业务数据同库的简洁性往往比极限性能更有价值。

核心要点回顾

向量数据库的本质，是把“精确匹配”升级为“语义近邻检索”。它通过 ANN 索引（如 HNSW）解决规模问题，通过 pgvector 这类方案降低引入门槛，最终服务于企业知识的语义搜索与 RAG 应用。理解这三层——存储、近似检索、集成方式——就抓住了向量数据库在企业场景中的全部关键。