外观
向量数据库与语义检索
向量数据库（Vector Database）是专为存储与检索高维向量（Embedding）而设计的数据库，支持按语义相似度进行近似最近邻（ANN）检索，是 RAG 系统的存储底座。
它解决的核心问题是传统数据库做不到的：存进去的不是"张三是谁"这种结构化记录，而是"这段文本/这张图/这段语音在语义上是什么"的高维坐标；查出来时也不靠 WHERE 精确匹配，而是问"和这段查询最像的 10 条是什么"。谁在用？几乎所有生产级 RAG 应用——从 Perplexity 这类 AI 搜索，到企业内部文档问答——底层都挂着向量数据库；推荐系统、多模态搜索、Agent 记忆也都是它的主场。在理解它之前，先理解它存的东西：向量（Embedding）。
一句话定位
如果说 RAG 是"给大模型配一个外挂知识库"的系统架构，那么向量数据库就是这个外挂知识库的存储与检索引擎——知识能不能被查到、查得准不准，很大程度取决于这一层。
一、前置概念：Embedding 与向量
嵌入（Embedding）是把文本、图像、音频等非结构化数据映射为高维向量的过程，映射结果就是一个由几百到几千个浮点数组成的向量，例如 [0.13, -0.42, 0.87, ...]。它的核心性质是一条几何假设：语义相近的对象，其向量在空间中位置也相近。
- 文本 Embedding：整句/整段编码为一个向量，由 Transformer 这类模型的编码器生成，常见维度如 768（BERT-base）、1024（BGE）、1536（OpenAI text-embedding-3-small）、3072（text-embedding-3-large）。
- 图像 Embedding：图像经 CLIP 等模型的视觉分支编码为向量，可与文本向量放在同一空间（见多模态模型）。
- 每个向量本质上是高维空间中的一个点，两个点"离得越近"（按某种距离度量），语义越接近。
| 概念 | 一句话解释 | 典型维度 |
|---|---|---|
| 词向量（Word2Vec） | 每个词一个向量，"国王−男人+女人≈女王" | 100–300 |
| 句向量/文本向量 | 整句/整段一个向量，语义可比 | 768–3072 |
| 多模态向量 | 文本、图像映射到同一向量空间 | 512–1024 |
一句话判断：Embedding 的质量决定检索质量的上限——向量数据库只是忠实地做近邻搜索，如果 Embedding 模型本身区分不开语义（比如分不清"苹果公司"和"苹果手机"），任何索引技巧都救不回来。
二、语义检索 vs 关键词检索
传统搜索引擎的关键词检索以 BM25 为代表：把文档切成词，统计词频与逆文档频率，查询与文档按"共有词的权重"打分。它完全不知道词的意思。
| 对比维度 | BM25 关键词检索 | 向量语义检索 |
|---|---|---|
| 匹配单位 | 字面词（token） | 语义向量 |
| 是否理解同义词 | 否（"汽车"匹配不到"车"） | 是（语义相近即命中） |
| 多语言能力 | 差（分词问题） | 强（同一向量空间直接比） |
| 对查询的鲁棒性 | 换种说法就搜不到 | 表达不同但意思相同也能召回 |
| 精确度 | 高（命中即相关） | 中（可能召回"像但不相关"） |
| 是否需要倒排索引 | 是 | 否（需要 ANN 索引） |
| 典型延迟 | 毫秒级 | 毫秒级（近似的） |
| 适合场景 | 精确关键词、编号、日志 | 自然语言问答、模糊语义 |
一个直观例子：用户问"怎么给花浇水"，BM25 需要文档里真的出现"浇水"才可能命中；向量检索可以召回一篇写"植物的水分管理"的文章——因为它俩的向量离得近。
一句话判断：别迷信向量检索"万能"——查订单号、身份证、精确产品型号时 BM25 完胜；而开放域问答、语义模糊的场景向量检索完胜。所以成熟系统几乎都用混合检索（见第六节）把两者叠加，而不是二选一。
三、相似度度量：余弦相似度、内积、欧氏距离
给定查询向量 q 与候选向量 d，判断"多像"有三种主流度量：
| 度量 | 公式 | 数值范围 | 什么时候用 |
|---|---|---|---|
| 余弦相似度（Cosine） | $\cos\theta=\frac{q\cdot d}{|q||d|}$ | [-1, 1]（越高越像） | 最常用默认项；关心"方向"而非"模长"，对 Embedding 的语义对比最稳 |
| 内积（Dot Product） | $q\cdot d=\sum_i q_i d_i$ | 无界 | 已归一化或模型按内积训练时；适合显式建模"相关度分数" |
| 欧氏距离（L2） | $\sqrt{\sum_i (q_i-d_i)^2}$ | [0, +∞)（越小越近） | 需要物理距离语义时；L2 越小越相似，检索时按升序取最小 |
度量与索引的匹配坑
度量选错会导致召回结果莫名变差。比如索引按"余弦"构建，查询却传了"内积"分数；或者用了 L2 距离却忘记 Embedding 未归一化，让"模长大的向量"系统性占便宜。多数文本 Embedding 模型推荐先 L2 归一化再算内积/余弦——此时三者结果排序等价，也方便不同度量间切换。
经验结论：没特别理由就用余弦相似度（文本场景）；图像/视频特征常用内积；需要严格"空间距离"语义时才用欧氏距离。选定后全链路保持一致，并在评估集上验证（见LLM 评估与基准）。
四、核心技术：ANN 索引
朴素做法是暴力扫描（Brute Force）：把查询向量和库里每一个向量算相似度再排序。数据量小时（万级）没问题；到了百万、亿级，一次查询要算几百万次点积，延迟无法接受。于是诞生了 近似最近邻（Approximate Nearest Neighbor, ANN） 索引：牺牲一点点召回率，换取数量级的速度提升。
| 检索方式 | 速度 | 召回率 | 内存 | 适用规模 |
|---|---|---|---|---|
| 精确检索（暴力扫描） | 慢（O(N)） | 100% | 低 | < 10 万 |
| ANN（HNSW/IVF/PQ） | 极快（毫秒级） | 90–99% | 中–高 | 百万到十亿 |
三大主流 ANN 算法：
| 算法 | 全称/思路 | 优点 | 缺点 |
|---|---|---|---|
| HNSW | 分层可导航小世界图（Hierarchical Navigable Small World） | 召回率高、查询快、无需训练 | 内存占用大、插入成本高 |
| IVF | 倒排文件（Inverted File），先聚类分桶再桶内搜索 | 内存可控、构建快 | 桶边界的召回损失、参数敏感 |
| PQ | 乘积量化（Product Quantization） | 大幅压缩向量（内存省 8–32 倍） | 精度损失、查询需查表较复杂 |
text
HNSW 检索过程（文字示意图）：
第4层 ──●──────────────────── 入口点（最稀疏，长跳）
│
第3层 ──●──●──●──────────────
│ │
第2层 ──●──●──●──●──●──────── 贪心搜索，逐步下探
│ │ │
第1层 ──●──●──●──●──●──●──●─ 最底层（最稠密）
查询从顶层入口进入 → 每层贪心走向最近的邻居 →
到底层后用光束搜索（beam search）收集 Top-K 候选文字图里发生了什么：HNSW 把向量组织成多层图——上层稀疏负责"远距离跳转"、底层稠密负责"精确定位"。查询向量从顶层入口出发，每层都走向"当前最近的邻居"，逐层下探到最底层，再在底层收集一批候选并排序。整个过程是贪心的，所以理论上可能错过全局最近点——这就是"近似"的来源，实际工程中召回率损失通常 < 1%。
- HNSW 是当前默认主力（Milvus、Qdrant、pgvector、FAISS 都支持），Rust/Go 实现下典型 p95 查询延迟在几毫秒到几十毫秒；
- IVF + PQ 组合常被用于十亿级、内存吃紧的场景：先量化压缩再分桶检索；
- 一句话判断：默认 HNSW，数据量上亿或内存受限再考虑 IVF/PQ；论文出处见文末参考资料（HNSW，arXiv:1603.09320）。
五、产品与选型对比
截至 2025 年中，向量检索生态分两类：向量数据库（完整数据库产品）与向量检索库/扩展（嵌入到应用或现有数据库里）。主流选项如下：
| 产品 | 类型 | 核心特性 | ANN 支持 | 部署形态 |
|---|---|---|---|---|
| FAISS（Meta 开源） | 检索库 | 最成熟的底层算法库，GPU 加速强，生态事实标准 | HNSW/IVF/PQ | 嵌入应用（需自管数据） |
| Milvus（Zilliz） | 分布式向量数据库 | 云原生、十亿级扩展、GPU 索引（CAGRA）、强 Filter | HNSW/IVF/PQ 等 | 本地/自托管/云托管 |
| Qdrant（开源） | 向量数据库 | Rust 实现、过滤与 Payload 极强、延迟低 | HNSW | 本地/自托管/云托管 |
| Pinecone | 托管向量数据库 | 全托管、免运维、Serverless | 内部优化索引 | 仅云托管 |
| Weaviate | 向量数据库 | 内建 GraphQL、生成式模块、模块化 | HNSW | 本地/云托管 |
| pgvector | PostgreSQL 扩展 | 与现有 SQL 共存、事务一致、零新基建 | HNSW/IVF | 随 PostgreSQL |
| Chroma | 轻量向量数据库 | Python 原生、开发上手最快 | HNSW | 本地/嵌入式 |
| Elasticsearch | 搜索引擎 + 向量 | 与 BM25/倒排共用一套系统，dense_vector 字段 | HNSW | 本地/云托管 |
本地 vs 云托管的取舍：
| 维度 | 本地/自托管 | 云托管（Pinecone、云版 Milvus/Qdrant） |
|---|---|---|
| 初始成本 | 低（开源免费） | 高（按量计费） |
| 运维负担 | 高（索引调参、扩容、备份） | 低（平台负责） |
| 数据合规 | 数据在自己手里 | 需评估数据出境与隐私条款 |
| 规模弹性 | 需自己规划 | 弹性扩缩容 |
| 适合 | 学习、POC、私有化、已有 K8s 团队 | 快速上线、波动负载、小团队 |
一句话判断：团队没有专门的检索工程师，就从托管服务起步；等规模与成本压力出现再迁回自托管。已有 PostgreSQL 业务且向量量在百万级以下，先试 pgvector——零新组件、事务与 SQL 天然可用，这是成本最低的起步路径。
六、在 RAG 流水线中的角色
典型 RAG 流水线（详见从零搭建 RAG 应用）中，向量数据库承担存储与召回环节：
text
文档切片 → ① Embedding 编码 → ② 写入向量数据库（索引）
│
用户问题 → ③ Embedding 编码 → ④ ANN 检索 Top-K → ⑤ 重排（Rerank）
│
元数据过滤（时间/来源/权限）贯穿 ④
▼
检索结果拼入 Prompt → LLM 生成回答三个关键实践：
- 索引 → 检索 → 重排：向量数据库只负责召回"宽"的候选（通常 Top-50~200），重排器（如 cross-encoder）再精排成 Top-5~10 喂给 LLM。召回宁多勿漏，精排宁精勿滥——这是提升答案质量性价比最高的一环；
- 元数据过滤：向量数据库几乎都支持在查询时叠加过滤条件（时间范围、文档来源、业务线、权限标签）。先过滤再 ANN 搜索能大幅减少候选集、提升准确率。权限过滤尤其重要——否则"能搜到但无权看"的文档会被检索出来；
- 混合检索（稠密向量 + 稀疏 BM25）：把向量检索与 BM25 结果做加权合并（如 RRF 倒数排名融合），兼顾语义与精确匹配。这是 Perplexity 这类 AI 搜索产品的标准做法，能显著缓解向量检索"像但不相关"的毛病。
评估优先
给 RAG 配向量数据库前，先建立检索质量基线：准备一批"问题 → 期望文档"的标注集，量化召回率@k（想要的文档是否被召回）与命中率@k（召回的是否相关）。没有这个基线，索引参数、Embedding 模型、混合权重都只能靠感觉调。
七、高级话题
7.1 向量 + 知识图谱：互补而非竞争
向量擅长"模糊语义联想"，但不懂"关系与规则"；知识图谱擅长精确的多跳关系推理，但对自然语言表达脆弱。两者互补（详见知识图谱与知识注入）：
| 场景 | 向量数据库 | 知识图谱 |
|---|---|---|
| "有哪些文档讲微服务降级？" | 强（语义召回） | 弱 |
| "A 服务依赖的 B 服务依赖了谁？" | 弱 | 强（多跳推理） |
| 事实一致性 | 无法保证（向量是概率表示） | 可验证 |
| 权限/规则 | 需自行实现过滤 | 天然适合规则 |
实践模式：先向量检索召回候选实体，再用图谱对候选做关系验证与路径推理，最后拼装答案。
7.2 多模态向量：跨模态检索
CLIP 类模型把文本与图像映射到同一向量空间，于是"上传一张图搜相似商品""用文字描述搜图片/视频片段"都变成一次向量近邻查询（见多模态模型）。向量数据库对多模态的唯一要求是：检索的 Embedding 来自同一模型家族——混用不同模型的向量等于用不同坐标系比距离，结果无意义。
7.3 向量数据库作为 Agent 的长期记忆
AI 智能体（Agent）的上下文窗口有限，需要把历史交互、工具结果、用户偏好沉淀为"可查询的记忆"。常见方案：把每次交互编码为向量存入向量数据库，新任务到来时先按相关性召回过往经验，再拼进上下文（详见从零开发一个 Agent）。这与 RAG 在技术上几乎同构，区别在于写入的是过程记录而非知识文档，因此对写入频率、去重与时效（记忆过期）的要求更高。
八、工程陷阱
维度灾难（Curse of Dimensionality）
向量维度越高，空间中任意两点距离越趋同，近邻区分度下降。缓解：选择与数据量匹配的 Embedding 维度（小数据集用 384 维就够）、对高维向量做 PCA/量化降维、用余弦而非欧氏距离。
冷启动（Cold Start）
新入库数据少、没有足够近邻，检索质量差；或 Embedding 模型换版本导致新旧向量空间不一致。缓解：冷启动期允许混合检索兜底；Embedding 模型升级时**全量重嵌入（re-embed）**并重建索引，绝不混用新旧向量。
数据更新与删除
向量索引的"更新"通常是先删旧再加新，而非原地改值；高频增删会拖慢 HNSW（图结构需维护）。删除在分布式实现里常是"软删除 + 定期压缩"。缓解：批量化写入、评估吞吐需求再选架构（读写比例决定索引配置）。
成本
向量检索的钱花在内存（HNSW 图全在内存）与 Embedding 计算上。百万条 1536 维向量约需 6GB 内存（不含索引开销）。缓解：用 PQ 量化压内存、为热点数据分温冷层、对每轮查询的嵌入复用缓存，并与推理优化与量化中的成本思维对齐。
向量数据库不是银弹
它解决"按语义找相似"，不解决"答案是否正确、事实是否一致"。把公司全部数据塞进向量库、期望 LLM 引用全部正确，是把检索召回与事实核验两件事混为一谈——后者要靠评估、Rerank 与护栏。更多翻车现场见常见陷阱与反模式。
延伸阅读
- 检索增强生成（RAG）——向量数据库的核心应用场景
- 从零搭建 RAG 应用——索引、检索、重排的端到端落地
- 知识图谱与知识注入——向量与图谱互补的进阶打法
- 多模态模型——跨模态向量检索的基础
- AI 智能体（Agent）——向量库作为长期记忆
- Perplexity 与 AI 搜索——混合检索的经典产品实践
- 推理优化与量化——从模型侧压缩成本
- 常见陷阱与反模式——检索与 RAG 工程坑位
- 术语表——向量、ANN 等术语速查
- 精选资源清单——向量数据库与检索工具集
参考资料
- Malkov & Yashunin. Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs（HNSW 论文） —— ANN 领域最具影响力的工作，HNSW 的原始出处
- Johnson, Douze & Jégou. Billion-scale similarity search with GPUs（FAISS 论文） —— FAISS 算法库的官方论文
- FAISS 官方文档（GitHub） —— Meta 开源的向量检索算法库
- Milvus 官方文档 —— 开源分布式向量数据库
- Qdrant 官方文档 —— Rust 实现的向量数据库
- pgvector（GitHub） —— PostgreSQL 向量扩展
- Chroma 官方文档 —— Python 原生轻量向量数据库
- Pinecone 学习中心：向量数据库基础 —— 面向入门者的向量检索教程