K3 · 什么是向量数据库？ - Vector Databases

所属知识库：Agent 全栈技术地图
所属领域：01 · AI
所属章节：04 · AI 如何获取和利用外部知识？ - Knowledge & Retrieval
文档类型：技术原理与工程实践研究
版本：v1.0
更新日期：2026 年 10 月 27 日
核心问题：什么是向量数据库？向量如何被存储、索引和检索？精确最近邻与近似最近邻搜索有什么区别？HNSW、IVF、PQ 等算法如何工作？向量数据库如何处理元数据过滤、数据更新、混合检索、一致性和多租户？如何设计、选型、评估并将其接入 AI 知识库与 Agent System？

专题导读

当 AI 系统需要从成千上万甚至数百万条文档中寻找语义相关的信息时，如何高效地存储、组织和检索 Embedding 向量，就成为知识检索系统的重要技术问题。

本篇围绕 Vector Databases（向量数据库）展开研究，从向量数据的基本结构、相似度计算与最近邻搜索出发，解释向量数据库如何通过索引技术实现大规模相似性检索。

在技术原理部分，重点研究精确最近邻搜索与近似最近邻搜索（ANN）的区别，深入分析 HNSW、IVF、PQ 等核心算法的工作机制，以及检索准确率、响应延迟、内存消耗和索引构建成本之间的关系。

在工程实践部分，进一步研究向量数据的写入与更新、元数据过滤、权限控制、持久化和分布式管理，并比较 FAISS、pgvector、Qdrant、Milvus 等主流技术方案，说明不同业务规模和技术架构下的选型依据。

最后结合 AI 知识库与 Agent System 的实际应用，研究如何设计可维护的向量检索服务、建立检索质量与性能评估体系，并理解向量数据库与 Embedding、信息检索、RAG 之间的技术分工，为后续构建完整的 AI 知识系统奠定基础。

一、研究概述：向量数据库解决什么问题？

在 K2 · Embeddings 中，我们研究了如何把文本等信息编码成向量，以及如何利用向量之间的几何关系近似表达某种任务相关的语义相似性。接下来的问题是：如果只有几十条文本，可以直接计算查询向量与所有文本向量的相似度；但如果有数百万条文档片段、不断更新的数据、多名用户和严格的访问权限，该如何让检索在可接受的延迟、资源和质量范围内持续运行？

**向量数据库（Vector Database）**是一类以向量相似性检索为核心能力，并通常提供数据持久化、索引、元数据、过滤、更新、查询接口及运维能力的数据系统。它接收向量和关联数据，按照指定的距离或相似度度量建立检索结构，使系统能够根据一个查询向量找出相关候选。其实际产品形态既包括独立向量数据库，也包括在关系数据库、搜索引擎或分析数据库中增加向量索引的扩展能力。

向量数据库不负责自动理解文本。通常由 Embedding 模型生成向量；向量数据库保存向量并执行搜索；检索应用决定查询改写、过滤、融合、重排与结果使用方式；生成模型则可能在 RAG 流程中阅读检索内容并作答。数据库本身也不会保证“语义正确”：向量表示质量、数据切分、检索算法、权限规则和评测设计都会影响最终效果。

本篇主要解决四个层面的问题：第一，数据库如何组织向量数据；第二，索引如何用近似计算换取速度和规模；第三，真实工程中的更新、过滤、隔离、可用性如何实现；第四，如何评估并选择适合知识检索与 Agent 应用的方案。K4 将进一步系统研究信息检索与排序，K5 研究 RAG 的生成链路，K6 研究知识库的数据治理与生命周期。

二、基本概念：向量、记录、集合、索引与查询

2.1 向量不是完整的数据记录

一个典型知识片段可以表示为：

json

{
  "id": "doc-17#chunk-003",
  "vector": [0.12, -0.08, 0.31, 0.04],
  "text": "合同审批需要法务复核……",
  "metadata": {
    "document_id": "doc-17",
    "tenant_id": "org-a",
    "version": 4,
    "language": "zh",
    "access_group": "legal",
    "updated_at": "2026-10-20"
  }
}

这里的四维向量只是教学示意。实际文本 Embedding 常使用数百至数千维，具体维度取决于模型和配置。id 是稳定标识，vector 用于相似性搜索，text 是可返回给应用的原始内容或引用，metadata 支持过滤、权限判断、溯源和更新。不同产品可能将文本放在数据库内部、外部对象存储或关系数据库中；并非每个向量索引都存储完整文本。

Collection / Index / Namespace / Table 是不同产品中常见的组织概念，但不能机械视为同义词：Collection 或 Table 通常表示数据组织边界，Index 是加速检索的物理结构，Namespace 可能是逻辑隔离空间。应以具体产品的定义为准。

2.2 相似度与距离的方向

对查询向量 $q$ 与候选向量 $x$ ，常见度量包括：

欧氏距离： $d_{L 2} (q, x) = \sqrt{\sum_{i} (q_{i} - x_{i})^{2}}$ ，越小越近。
点积： $s_{d o t} (q, x) = \sum_{i} q_{i} x_{i}$ ，通常越大越相似；受向量模长影响。
余弦相似度： $s_{c o s} (q, x) = \frac{q \cdot x}{‖ q ‖ ‖ x ‖}$ ，在非零向量上衡量方向一致性。

若向量均经过 L2 归一化，则 $‖ q - x ‖^{2} = 2 - 2 (q \cdot x)$ ，欧氏距离、点积和余弦相似度在相同候选集上产生等价的排序（忽略数值误差与并列项）。但对于未归一化向量，三种度量的结果可能明显不同。索引配置的度量必须与 Embedding 模型的训练目标及评测设定相匹配；不可仅凭某个“距离分数”在不同数据库间横向比较。

2.3 Top-K 查询的实际含义

给定查询 $q$ 、候选集 $D$ 和 $k$ ，精确最近邻检索的目标是找到按相似度排序最高的 $k$ 个候选。应用层还可能指定 tenant_id=org-a、access_group=legal 等过滤条件。因此，真正的查询通常是“在有权限且满足业务条件的候选集合内，找出最相似的 $k$ 条记录”，而不是在全库中任意挑选最接近的向量。

三、为什么不能总是逐条比较？精确搜索与 ANN

3.1 精确最近邻（Exact Nearest Neighbor, ENN）

最直接的方法是对 $N$ 条 $d$ 维向量逐条计算距离，再选 Top-K。仅计算距离的时间量级通常为 $O (N d)$ ，加上 Top-K 选择与数据访问开销。它简单、可解释，能作为准确性基准；但当数据规模、并发和维度增加时，计算与内存带宽开销可能难以满足延迟目标。

精确扫描并非永远不合适。对小规模数据、过滤后候选很少的查询、离线评估或高召回要求的场景，精确搜索可能是最经济且最可靠的选择。某些数据库优化器也会在过滤后选择精确扫描。

3.2 近似最近邻（Approximate Nearest Neighbor, ANN）

ANN 不保证每次都找出真正的精确 Top-K，而是通过索引结构缩小搜索范围，以较少计算获得高概率的近邻结果。其价值是在召回质量、延迟、吞吐量、内存与构建成本之间提供可调节的折中。

不能将 ANN 的“近似”误读为生成模型的“幻觉”。ANN 的近似主要指相对于指定距离度量的精确近邻集合可能有遗漏；至于这些近邻是否真正回答用户问题，还取决于 Embedding 和任务相关性。

3.3 ANN 的核心权衡

提高搜索深度，通常有机会提高 ANN Recall，但也会增加延迟和计算；效果并非严格单调，取决于实现与数据。
增大索引或保留更精细的向量表示，可能提高召回，但增加内存或磁盘成本。
压缩向量可降低容量和访存开销，但可能引入距离误差。
高更新率、过滤选择性、数据分布漂移和多租户隔离，会改变原本在静态基准上得到的性能结论。

因此，向量数据库选型不应只看单次 QPS 或某篇公开排行榜，而应基于自己的向量、过滤条件、查询负载与召回目标测试。

四、HNSW：基于分层邻近图的搜索

4.1 直观机制

HNSW（Hierarchical Navigable Small World）将向量组织为多层近邻图。高层通常包含较少节点，用于快速跨越较远的搜索区域；底层包含更多节点，用于局部细化。查询时从较高层的入口节点开始，沿着能改善距离的邻居移动，逐层下降，最后在底层保留一组候选并输出 Top-K。

其思想类似于：先通过高速道路到达目标区域，再通过局部道路寻找具体位置。这种比喻仅解释导航机制，并不意味着每个图边都对应真实地理空间或精确最近邻关系。

4.2 建图与查询参数

HNSW 常见的三个参数是：

M：节点连接数量的主要控制参数之一，影响图连通性、索引体积和搜索质量。实际不同层的连接上限与实现细节可能不同。
efConstruction：建图阶段候选搜索宽度，通常影响构建时间与图质量。
efSearch：查询阶段候选搜索宽度，通常影响查询耗时与召回；一般需要不小于目标返回数 $k$ ，但具体约束依实现而定。

这些参数没有通用最优值。更高的 M 或 efConstruction 不一定值得，尤其在数据频繁更新、内存紧张或有大量小分区时。工程上应通过数据集实验选择参数，并测量索引构建耗时、峰值内存、更新行为与 P95/P99 延迟。

4.3 HNSW 的工程局限

HNSW 往往适合低延迟、高召回的内存或内存友好型搜索，但图结构会引入额外的指针/邻接表开销。插入通常需要搜索并建立邻接关系；删除可能使用逻辑标记、图修复或后台重建。高频更新、过滤后的图遍历效率和索引重建策略因数据库实现而异，不能仅凭“HNSW 支持动态插入”推断其适合任何高变更工作负载。

过滤与 HNSW 的冲突尤其重要：如果图中大量近邻不符合过滤条件，搜索可能需要探索更多节点才能找到足够的合格结果；若先搜索再过滤，还可能出现“明明有合格结果却只返回很少条”的现象。数据库可能通过过滤感知遍历、预过滤、分区或自适应精确扫描缓解，但具体效果需要验证。

五、IVF、PQ 与压缩：另一类重要索引机制

5.1 IVF：先定位簇，再搜索候选

IVF（Inverted File Index）通常先通过聚类把向量划分为多个簇，每个簇维护一个候选列表。查询时找到与查询向量最接近的若干簇，只扫描这些簇中的候选。常见参数包括簇数量 nlist 和查询探测簇数量 nprobe。

nprobe 较小时扫描少、速度快，但可能错过位于其他簇的近邻；增大 nprobe 往往提高召回，同时增加计算。IVF 需要训练或构建聚类中心，数据分布变化时可能需要重新训练或重建。对于高度不均匀的簇分布，负载可能倾斜。

5.2 PQ：把高维向量压缩成短编码

PQ（Product Quantization，乘积量化）将向量拆成多个子向量，对每一部分分别学习码本，再用短编码表示原始向量。查询时可利用预计算距离表近似估计候选距离，从而减少存储和访存。它适合大规模、内存受限的检索，但压缩会引入误差，可能影响近邻排序。

IVF 与 PQ 可组合成 IVF-PQ：先按簇缩小候选范围，再用压缩编码高效估计距离。常见系统也可能使用标量量化、二值量化、磁盘 ANN、残差编码或重新排序等其他方案。压缩策略应按实际模型分布和质量要求评估，不能把“维度不变”误认为“信息没有损失”。

5.3 重排与原始向量保留

一些系统会用压缩索引找出较大的候选集，再使用原始高精度向量对候选重新计算距离（rescore / rerank）。这能在一定程度上恢复压缩带来的排序误差，但要求能访问原始向量或更高精度表示，并引入额外计算。这里的“向量精排”与 K4 中使用 Cross-Encoder 或生成模型进行语义重排序是两种不同层次的操作。

六、数据结构与存储：不只有一组浮点数组

6.1 基础存储估算

假设有 $N$ 条向量，每条 $d$ 维，每维以 32 位浮点数保存，则仅原始向量数组的理论大小约为：

S_{v e c t o r s} = N \times d \times 4 bytes

例如，100 万条、768 维、float32 向量：

1,000,000 \times 768 \times 4 = 3,072,000,000 bytes

即约 3.072 GB（十进制）或 2.861 GiB（二进制）。这只是向量本体，不包括索引图、ID、元数据、文本、WAL、缓存、复制副本、预留空间和后台构建峰值内存。真实资源需求可能明显更高。

6.2 写入路径

生产数据库通常需要处理以下操作：

text

原始文档 → 文本解析/切分 → Embedding → 记录与元数据校验
                                       │
                                       ▼
                                 持久化/写入日志
                                       │
                                       ▼
                              索引插入或后台构建
                                       │
                                       ▼
                                  可被查询

但持久化成功、索引更新完成、查询立即可见可能是不同事件。系统可能采用同步索引、异步索引、内存缓冲区或后台合并。需要根据产品文档明确写入确认语义、读后写可见性、一致性模型和故障恢复机制。

6.3 更新与删除

向量数据库中的“更新”通常不是只改一个数字：文档内容变化时，应用需重新生成 Embedding，并更新向量、文本、元数据和版本。建议使用稳定主键及幂等 upsert，记录 document_id、chunk_id、embedding_model_version、content_hash 和 source_version，避免旧向量与新文本错配。

删除还涉及多个层次：逻辑不可见、索引移除、底层文件清理、备份与副本保留期限。对于敏感数据或合规要求，不能把 API 返回“删除成功”等同于所有物理副本已立即清除。

七、元数据过滤、权限与多租户

7.1 过滤顺序会改变结果

假设全库中有 100 万条记录，某用户仅能访问 1000 条。两种看似类似的方案可能产生不同结果：

先全库 ANN Top-10，再过滤权限：可能只剩 0—2 条，甚至可能在检索候选与日志阶段接触不应访问的数据。
先限定授权候选集，再做 Top-10：目标是返回授权集合内最相关的 10 条，语义上更符合访问控制要求。

实际系统可通过过滤感知索引、按租户分区、过滤后精确搜索等策略实现。关键原则是：授权约束必须在检索数据访问和结果输出的安全边界内强制执行，而不能仅依赖模型提示词或最后的文本遮盖。

7.2 过滤表达式的工程问题

过滤条件可能包括 tenant_id、project_id、document_type、时间范围、访问组、语言或业务状态。它们的组合选择性直接影响性能。过滤极窄时，精确扫描少量合格记录可能优于复杂 ANN；过滤较宽时，图或聚类索引可能更有优势。应测试真实过滤分布，而不是只测试无过滤 Top-K。

7.3 多租户隔离模式

常见设计包括共享集合加 tenant_id 过滤、按租户划分 namespace / partition、独立 collection 或独立实例。共享集合节省资源，但要求每条请求都可靠注入租户条件；独立实例隔离更强，成本和运维复杂度更高。不同租户规模、监管要求和噪声邻居风险，决定适合的隔离层级。

不要把 namespace 名称本身当作权限系统。权限应由身份认证、授权策略、数据库访问控制和服务端强制过滤共同保障。

八、查询执行链路：从问题到候选片段

一个常见的语义检索请求包含：

text

用户问题
  ↓
查询规范化/可选改写
  ↓
Embedding 模型生成查询向量
  ↓
服务端身份认证与权限计算
  ↓
确定 collection / namespace / metadata filter
  ↓
向量 ANN 或精确检索（Top-K / 候选池）
  ↓
可选的距离精排 / 关键词融合 / 语义重排
  ↓
关联文本与来源元数据回填
  ↓
返回带 ID、版本和来源的检索结果

其中“向量数据库查询”通常只是中间的一段。查询向量的生成、权限判定、结果重排、证据拼装与最终回答属于应用或检索服务职责；有些数据库产品把部分功能集成到服务内，但不改变概念边界。

8.1 分数不是概率

向量距离、余弦相似度和数据库返回的 score 可能采用不同尺度与方向。score=0.85 并不自动代表“85% 相关概率”。不同模型、距离度量、数据集和产品之间，分数阈值不可直接迁移。若需要拒答阈值，应使用带标签的数据集进行校准，并考虑查询类型与业务代价。

8.2 Top-K 不是越大越好

更大的候选集可能提高召回，但也增加检索延迟、重排成本和下游上下文噪声。最终送入 LLM 的片段数应由相关性、去重、来源覆盖、Token 预算和任务需求共同决定。向量数据库层的 top_k、重排候选池大小和最终 RAG 上下文片段数，是三个可以分别设置的参数。

九、混合检索：向量数据库与全文搜索如何协作？

语义检索擅长发现措辞不同但语义相关的文本；关键词检索更容易准确命中产品型号、错误码、专有名词、数字、法律条款编号等字面线索。两者并无绝对优劣。混合检索（Hybrid Search）常将 BM25 或其他词法评分与向量搜索组合，再做融合或重排序。

常见融合方式包括：

候选合并：分别从词法和向量索引取 Top-K，去重后形成候选池。
分数融合：对不同分数归一化后加权，但归一化可能对分布变化敏感。
排名融合：例如 Reciprocal Rank Fusion（RRF），按各检索器名次累加 $1 / (c + r a n k)$ ，避免直接比较不兼容的原始分数。
学习重排：使用专门的 reranker 对合并候选重新打分。

RRF 的常见形式为：

R R F (d) = \sum_{r \in R} \frac{1}{c + r a n k_{r} (d)}

其中 $R$ 是检索器集合， $c$ 是平滑常数；未进入某个检索器结果集的文档通常不贡献该项。RRF 不会自动修复低质量候选，也不能替代业务权限检查。混合检索的完整算法与评估归 K4 研究，本篇重点理解数据库需要提供的索引、查询和融合能力。

十、向量数据库、向量索引、全文搜索与关系数据库的区别

方案	核心能力	常见优势	需要注意
内存数组 + 精确扫描	小规模 Top-K 与质量基准	简单、可控、易验证	规模与并发受限；持久化需自建
FAISS 等向量检索库	高性能相似度索引	索引算法丰富，可嵌入服务	本身不等同于完整多用户数据库；持久化、权限、复制等需自行设计或集成
独立向量数据库	向量检索 + 数据管理服务	面向向量负载的索引、过滤、运维能力	新增基础设施、数据同步与治理成本
PostgreSQL + pgvector	关系数据与向量查询集成	SQL、事务、既有业务数据协同	索引、过滤、吞吐和规模需按具体负载验证
Elasticsearch / OpenSearch 等搜索平台	全文搜索、过滤、向量与混合检索	词法检索和业务搜索能力成熟	集群复杂度、索引成本、评分与版本兼容性

这里的“向量数据库”是功能类别，不应把所有产品硬分为完全互斥的几类。搜索引擎和关系数据库也能提供成熟的向量检索能力。真正的选型问题是：现有系统是否已满足数据一致性、权限、检索质量和运维目标？新增独立向量数据库能否带来足够收益？

十一、主流技术方案：如何选择，而不是简单排名

11.1 FAISS

FAISS 是 Meta Research 开源的高效向量相似度搜索库，提供精确索引、IVF、PQ 等多种算法及部分 GPU 支持。它适合作为 ANN 算法实验、离线索引或自建检索服务的基础组件。应用需要自行处理多租户、鉴权、网络 API、写入一致性、备份与服务监控等数据库层职责。

11.2 PostgreSQL + pgvector

pgvector 使 PostgreSQL 能存储向量并执行距离运算，支持精确检索以及 HNSW、IVFFlat 等索引方法。对于已有 PostgreSQL 业务系统、向量规模可控、希望把向量和业务记录放在同一事务或 SQL 查询环境中的场景，具有很强的工程吸引力。需要关注索引创建时机、过滤条件、查询计划、更新负载和维护成本；并非“装上扩展就自动获得最佳 ANN 性能”。

11.3 Qdrant

Qdrant 是面向向量相似性搜索的数据库，强调向量检索、payload 过滤与服务接口。适合希望采用专门向量服务并管理过滤条件的团队。具体的索引构建、分片、复制、量化与一致性能力需按目标版本的官方文档验证。

11.4 Milvus

Milvus 是面向大规模向量数据的开源数据库，支持多种索引及分布式部署形态。适合有独立向量基础设施需求、数据量较大或希望研究多种索引与集群架构的团队；同时需要承担更复杂的组件、资源与运维管理。不同部署模式的能力与成本不能混为一谈。

11.5 Weaviate

Weaviate 提供对象数据、向量检索和面向应用的搜索能力，常见于语义搜索与知识应用架构。选型时应确认目标版本中的向量化方式、混合检索、过滤、租户隔离和模块依赖，避免把产品集成能力误解为通用数据库标准。

11.6 Elasticsearch / OpenSearch

若团队已有全文搜索集群，并且业务查询高度依赖关键词、过滤、聚合和语义检索结合，扩展现有搜索平台可能优于新增独立向量数据库。应验证具体版本的向量字段类型、ANN 索引、过滤执行、混合检索与查询性能。

选型原则：优先从现有数据栈、权限体系、查询负载、运维能力和质量目标出发，再比较产品功能；不以“专用向量数据库必然更快”或“关系数据库一定不够用”作为先验结论。

十二、可复现工程案例：一个最小向量检索器

为了清楚展示数据库的核心语义，先实现一个不依赖第三方库的精确向量检索基线。这不是生产数据库，也不包含 ANN、持久化、并发或真正的权限系统；它用于验证相似度、过滤和 Top-K 的逻辑，并为后续真实数据库实验提供对照。

运行环境：Python 3.10+，仅使用标准库。保存为 vector_baseline.py，运行 python vector_baseline.py。

python

from dataclasses import dataclass
from math import sqrt
from typing import Dict, List, Tuple

@dataclass(frozen=True)
class Record:
    id: str
    vector: Tuple[float, ...]
    text: str
    tenant_id: str


def cosine(a: Tuple[float, ...], b: Tuple[float, ...]) -> float:
    if len(a) != len(b) or not a:
        raise ValueError("vector dimensions must match and be nonempty")
    na = sqrt(sum(x * x for x in a))
    nb = sqrt(sum(x * x for x in b))
    if na == 0 or nb == 0:
        raise ValueError("zero vector is not valid for cosine similarity")
    return sum(x * y for x, y in zip(a, b)) / (na * nb)


def search(records: List[Record], query: Tuple[float, ...],
           tenant_id: str, k: int) -> List[Tuple[str, float]]:
    if k < 1:
        raise ValueError("k must be positive")
    # 教学示例：在相似度计算前限制租户候选集合。
    allowed = [r for r in records if r.tenant_id == tenant_id]
    scored = [(r.id, cosine(query, r.vector)) for r in allowed]
    scored.sort(key=lambda item: (-item[1], item[0]))
    return scored[:k]


if __name__ == "__main__":
    rows = [
        Record("a1", (1.0, 0.0), "合同审批", "A"),
        Record("a2", (0.8, 0.6), "法务流程", "A"),
        Record("b1", (1.0, 0.0), "其他租户私有数据", "B"),
    ]
    result = search(rows, (1.0, 0.0), "A", 2)
    assert [r[0] for r in result] == ["a1", "a2"]
    assert all(r[0] != "b1" for r in result)
    assert round(cosine((1.0, 0.0), (0.0, 1.0)), 6) == 0
    print(result)

这里的 tenant_id 过滤只说明查询语义，不是安全的认证授权实现：调用方可以自行传入租户 ID。生产服务必须从经过验证的用户身份与授权上下文导出租户范围，并由服务端强制执行。

12.1 从基线迁移到真实数据库

在真实项目中，可以将上述 Record 映射为数据库记录，使用 Embedding 服务生成向量，并把 search() 替换为数据库的带过滤 Top-K 查询。迁移时至少需要检查：

查询向量维度、模型版本、距离度量与索引一致。
使用稳定 ID 和幂等 upsert，处理重复写入。
授权过滤在服务端强制执行，且查询结果包含可审计的来源 ID。
对更新、删除、空结果、超时、索引尚未可见等状态定义明确行为。
将 ANN 结果与精确搜索基准比较，不能只验证 API 返回 200。

12.2 pgvector 的概念性 SQL 示例

下面展示关系数据库与向量检索结合的结构。此示例为概念性 SQL，未在本次环境安装 PostgreSQL/pgvector 运行；实际使用前须核对扩展版本、索引算子类及 SQL 语法。

sql

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE knowledge_chunks (
    id TEXT PRIMARY KEY,
    tenant_id TEXT NOT NULL,
    document_id TEXT NOT NULL,
    content TEXT NOT NULL,
    embedding vector(3) NOT NULL
);

-- 示例选择余弦距离的 HNSW 索引。
CREATE INDEX knowledge_chunks_embedding_idx
ON knowledge_chunks USING hnsw (embedding vector_cosine_ops);

-- 余弦距离运算符 <=>；越小越接近。
SELECT id, document_id, content,
       embedding <=> '[0.2,0.3,0.4]'::vector AS distance
FROM knowledge_chunks
WHERE tenant_id = 'org-a'
ORDER BY embedding <=> '[0.2,0.3,0.4]'::vector
LIMIT 5;

注意：这里使用三维向量只是为了易读；真实维度必须与所用 Embedding 模型匹配。SQL 的 WHERE tenant_id = ... 不能单独充当完整的授权机制；实际系统应采用可信身份上下文、数据库权限策略（必要时包括 RLS）及安全审计。对于带过滤 ANN，索引是否能高效返回足量候选，需要结合查询计划和召回测试验证。

十三、从数据库到知识检索服务：推荐的工程分层

text

┌───────────────────────────────────────────────────┐
│ Agent / RAG / 搜索应用                            │
│ 问题理解、任务策略、证据使用、最终输出             │
└───────────────────────┬───────────────────────────┘
                        │
┌───────────────────────▼───────────────────────────┐
│ Retrieval Service                                 │
│ 身份与授权、查询改写、混合检索、融合、重排、缓存    │
└───────────────┬─────────────────┬─────────────────┘
                │                 │
┌───────────────▼───────┐ ┌──────▼──────────────────┐
│ Vector Index / DB     │ │ Full-text / SQL / APIs  │
│ ANN、过滤、向量查询   │ │ 关键词、结构化条件查询  │
└───────────────┬───────┘ └──────┬──────────────────┘
                │                 │
┌───────────────▼─────────────────▼─────────────────┐
│ Data & Ingestion                                  │
│ 原始文档、解析、分块、Embedding、版本与权限元数据  │
└───────────────────────────────────────────────────┘

这种分层的好处是可以替换向量数据库而不重写 Agent 的任务逻辑，也能把鉴权、结果来源和质量评估放在统一检索服务中。对于小型项目，可将多层合并部署，但职责仍应清楚。

13.1 写入流水线的幂等性

推荐将文档版本与分块 ID 显式绑定。例如：chunk_id = hash(document_id, source_version, chunk_index, chunking_policy_version)。同一版本重复写入应得到相同 ID；当切分策略或 Embedding 模型改变时，应建立新的索引版本，避免同一集合中混入不兼容的向量空间。

13.2 零停机迁移与双索引

升级 Embedding 模型时，旧向量与新向量通常不可直接混用，即使维度相同也不代表空间兼容。可采用“新索引离线构建 → 增量同步 → 影子查询/质量评估 → 流量切换 → 观察 → 清理旧索引”的迁移方式。需要同时管理查询编码器版本，防止“新查询向量搜索旧文档向量”。

13.3 缓存与新鲜度

可缓存查询 Embedding、常见检索结果和来源文档，但缓存键应包含租户、权限版本、模型版本、索引版本和查询参数。知识更新后应设计失效策略，否则检索可能持续返回旧内容。跨租户共享缓存尤其需要防止权限泄露。

十四、如何科学评估向量数据库？

数据库评测必须区分近邻算法质量、检索任务相关性和最终问答质量。

14.1 ANN Recall@K

对每个查询，用相同距离度量在相同授权候选集合中执行精确搜索，得到真实 Top-K 集合 $G_{q}$ ；ANN 返回集合为 $A_{q}$ 。定义：

R e c a l l @ K_{A N N} = \frac{1}{| Q |} \sum_{q \in Q} \frac{| A_{q} \cap G_{q} |}{K}

该指标衡量 ANN 相对精确近邻的保留程度，不代表检索结果在业务语义上相关。如果精确 Top-K 本身就与用户问题无关，ANN Recall 很高也不能说明知识检索有效。

14.2 语义检索质量

使用人工标注的相关文档或答案证据，评估 Recall@K、Precision@K、MRR、nDCG 等指标。若涉及多段证据，除单段相关性外还应测量证据覆盖率、跨文档多样性与可回答性。详细指标定义与标注方法在 K7 展开。

14.3 性能与资源指标

至少采集：查询 P50/P95/P99 延迟、吞吐量（QPS）、并发量、索引构建耗时、写入延迟、读后写可见性、内存、磁盘、CPU/GPU 使用率、每百万向量成本、过滤选择性、删除与重建开销。需要分别测试冷启动、热缓存、批量导入、持续更新、过滤查询和混合检索。

14.4 实验设计

采用统一向量集、查询集、过滤条件、目标召回与硬件预算，比较多个索引参数组合。每组至少报告：数据规模、维度、度量、数据类型、索引参数、硬件、并发、查询分布、更新比例、过滤选择性及结果分位数。不要把“不同召回率下的 QPS”直接当成同条件对比。

14.5 故障与安全测试

还应验证：权限过滤绕过尝试、租户隔离、批量删除后的可见性、节点重启、备份恢复、索引损坏、写入重试、重复消息、网络超时和容量耗尽。数据库在理想情况下速度很快，不等于其作为生产知识基础设施足够可靠。

十五、常见故障及排查路径

现象	可能原因	排查方向
搜索结果语义不相关	Embedding 模型不适配、切分不合理、查询与文档编码方式错误	检查模型文档、标注样本、精确搜索基线
召回突然下降	新旧 Embedding 混用、索引参数变化、更新未可见	检查模型版本、索引版本、写入日志、ANN Recall
带过滤查询结果不足 K 条	后过滤截断、过滤与 ANN 不兼容、授权候选不足	比较过滤后精确查询、查看执行计划
低并发快、高并发慢	线程池、内存带宽、缓存、IO、排队	分离服务时间与排队时间，查看 P95/P99
索引体积超预期	图索引开销、元数据、复制、WAL、历史版本	分项统计容量，测量重建峰值
删除后仍能检索	异步索引、逻辑删除、缓存、备份副本	验证读写一致性、缓存失效、清理策略
不同数据库分数不可比	度量、归一化、分数方向或实现不同	统一评测集和排序指标，不直接比较原始分数
更新后结果出现旧文本	向量/文本版本错配、异步流水线、重复写入	稳定 ID、内容哈希、原子版本切换

排查时建议先固定查询与授权范围，用精确搜索判断问题来自 Embedding 还是 ANN，再检查索引与过滤，最后检查应用层的融合、重排和上下文拼装。不要直接通过“增大 top_k”掩盖根因。

十六、安全、隐私、治理与可靠性

向量不是不可逆的匿名信息。Embedding 可能保留可推断的语义或敏感属性，向量相似度接口也可能泄露数据分布。对于包含个人信息、商业机密或受监管资料的系统，应将向量、原文、元数据和日志都纳入数据分类与访问控制范围。

生产环境至少应考虑：传输加密与静态加密、最小权限、密钥管理、服务端鉴权、租户隔离、审计日志、备份恢复、保留期限、删除流程、数据驻留要求和依赖供应链安全。数据库返回的文档内容属于外部不可信数据；在 Agent/RAG 场景中，还需防范恶意文档中的提示注入，不应因为文本来自内部知识库就赋予其系统指令权限。

高可用设计需区分副本、分片与备份：副本提高可用性和读取能力，分片扩展数据容量与吞吐量，备份用于从误删除、损坏或灾难中恢复。三者不能互相替代。分布式 ANN 还可能需要跨分片候选合并，分片数、每片 Top-K 和全局重排会影响最终召回与延迟。

十七、向量数据库在 Agent 与 Agent System 中的位置

对单个 Agent 而言，向量数据库通常是知识检索工具背后的基础设施，而不是 Agent 的推理引擎。Agent 可以决定是否检索、使用什么查询、是否继续追问；检索服务负责权限、查询执行和证据返回；模型负责解释与使用证据。向量数据库不应自主决定任务目标或执行外部行动。

对 Agent System 而言，向量检索通常可以被封装为共享的 Knowledge Service，供多个 Agent 使用。系统需要管理数据源、权限、索引版本、访问配额、缓存、成本和审计。共享知识不等于共享全部权限；不同 Agent、用户和工作空间应遵守各自的授权边界。

还需要区分 Knowledge 与 Memory。知识库更偏向可管理的外部事实与文档；Agent Memory 可能包含会话历史、用户偏好、事件轨迹、任务状态和长期经验。二者都可能使用向量检索，但数据生命周期、时间语义、写入策略和可信度不同，不能因为都存向量就合并为一个没有治理规则的集合。

十八、工程选型与落地路线

阶段一：建立精确基线。 收集具有代表性的文档、查询、权限与相关性标签；固定 Embedding 模型和切分规则。用精确向量搜索测量语义上限，并与 BM25 基线比较。

阶段二：评估是否需要 ANN。 根据数据量、延迟目标和成本，决定使用精确扫描、HNSW、IVF 或其他索引。测试目标 Recall@K 下的延迟与资源，不盲目追求最高 QPS。

阶段三：确定数据系统形态。 若已有 PostgreSQL 且规模适中，可先评估 pgvector；若全文搜索与过滤是主需求，可评估现有搜索平台；若大规模向量检索是独立核心负载，再评估专用向量数据库。

阶段四：实现可信检索服务。 封装写入、查询、过滤、鉴权、溯源、超时、重试、版本与日志。将检索服务接口与底层数据库实现解耦。

阶段五：进行端到端验证。 先评估 ANN 召回，再评估业务检索质量，最后评估 RAG/Agent 任务质量；同时覆盖性能、权限和故障恢复。

阶段六：持续运营。 监测查询分布、索引体积、数据更新、召回退化、尾延迟与成本。Embedding 模型、切分策略或数据库版本变更时，采用可回滚的索引迁移流程。

十九、核心结论与常见误区

向量数据库的核心是高效管理与检索向量，不是替代 Embedding 模型或生成模型。
ANN 是性能与召回的折中机制。 精确搜索仍然是重要的基线，也可能是小规模或强过滤场景的最佳方案。
HNSW、IVF、PQ 解决的是不同的索引与压缩问题。 其参数必须结合数据、过滤和负载测量。
数据库返回的相似度分数不是事实正确率，也不是通用概率。 业务相关性需要独立评估。
元数据过滤是检索语义的一部分，授权是安全边界。 二者有关联但不能相互替代。
“向量数据库”不等于“必须新增一个专用数据库”。 关系数据库和搜索引擎也可能满足需求。
知识库的可靠性来自完整系统。 数据质量、索引、更新、权限、检索策略和生成评估缺一不可。

二十、与前后专题的关系

K1 · Parametric Knowledge：说明模型内部知识的来源与局限；K3 研究模型外部知识的检索基础设施。
K2 · Embeddings：解释向量如何形成、相似度如何定义；K3 负责向量的组织、索引和查询。
K4 · Information Retrieval：深入研究 BM25、混合检索、查询处理、排序与重排；K3 提供其中的向量检索组件。
K5 · RAG：把检索结果纳入模型输入，研究证据利用与生成可靠性。
K6 · Knowledge Base：负责资料采集、解析、切分、更新、权限与知识生命周期；向量数据库是可选基础设施之一。
K7 · Retrieval Evaluation：建立检索相关性、证据支持、回答质量和端到端任务评估方法。
Agent A5/A6/A7 与 Agent System L2/H9：进一步研究记忆、知识工具、共享知识服务和数据治理。

二十一、参考文献与技术资料

以下列出原始论文与官方技术入口。原理性论文适用于解释算法思想；产品接口与部署参数需以实施时的对应版本文档为准。

Malkov, Y. A., & Yashunin, D. A. (2018). Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs. IEEE TPAMI. arXiv:1603.09320。HNSW 的原始研究。
Jégou, H., Douze, M., & Schmid, C. (2011). Product Quantization for Nearest Neighbor Search. IEEE TPAMI. 论文页面。PQ 的基础研究。
Johnson, J., Douze, M., & Jégou, H. (2019). Billion-scale Similarity Search with GPUs. IEEE Transactions on Big Data. arXiv:1702.08734。FAISS 与大规模近邻检索。
Aumüller, M., Bernhardsson, E., & Faithfull, A. (2020). ANN-Benchmarks: A Benchmarking Tool for Approximate Nearest Neighbor Algorithms. Information Systems. 项目。ANN 基准测试方法。
Cormack, G. V., Clarke, C. L. A., & Büttcher, S. (2009). Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods. SIGIR. ACM DOI。RRF 排名融合。
FAISS 官方项目：facebookresearch/faiss。索引类型、算法与工程实现。
pgvector 官方项目：pgvector/pgvector。PostgreSQL 向量类型、距离算子与索引。
Qdrant 官方文档：qdrant.tech/documentation。向量检索与过滤。
Milvus 官方文档：milvus.io/docs。向量索引与分布式架构。
Weaviate 官方文档：docs.weaviate.io。向量搜索、对象与混合检索。
Elasticsearch 官方文档：elastic.co/guide。全文搜索与向量检索相关文档入口。
OpenSearch 官方文档：docs.opensearch.org。k-NN、向量与混合检索相关文档入口。

二十二、研究声明

研究与验证说明：本文依据向量检索经典论文、公开技术原理及官方项目文档入口组织研究，区分了精确最近邻、ANN 索引、向量数据库产品与上层检索服务。文中数据容量计算为基于 float32 存储的理论估算，不代表任何具体产品的实测内存或磁盘占用。HNSW、IVF、PQ 参数说明为算法层面的通用机制，实际实现和参数名称可能因产品及版本而异。Python 精确检索示例为可离线执行的教学基线；SQL 示例为概念性配置，未在本次环境中部署数据库验证。本文未进行真实向量数据库集群部署、性能压测或生产故障演练。

最新性状态：核心算法原理有原始论文支持；产品能力、API、部署方式和版本兼容性在本文中仅给出官方技术资料入口，未逐项完成截至 2026 年 10 月 27 日的在线版本核验，因此不能将其视为已验证的最新产品对照表。正式实施前应再次核对目标产品的官方版本文档、变更记录、索引参数、过滤语义及许可要求。

实验与适用边界：文中的示例向量、租户数据和 SQL 均为教学数据，不代表真实 Embedding 模型的检索质量。索引质量与性能结论必须在目标数据、硬件、过滤条件、并发和权限要求下测量。生产系统应额外验证身份认证、授权、数据删除、备份恢复、索引迁移和安全审计。

K3 · 什么是向量数据库？ - Vector Databases ​

专题导读 ​

一、研究概述：向量数据库解决什么问题？ ​

二、基本概念：向量、记录、集合、索引与查询 ​

2.1 向量不是完整的数据记录 ​

2.2 相似度与距离的方向 ​

2.3 Top-K 查询的实际含义 ​

三、为什么不能总是逐条比较？精确搜索与 ANN ​

3.1 精确最近邻（Exact Nearest Neighbor, ENN） ​

3.2 近似最近邻（Approximate Nearest Neighbor, ANN） ​

3.3 ANN 的核心权衡 ​

四、HNSW：基于分层邻近图的搜索 ​

4.1 直观机制 ​

4.2 建图与查询参数 ​

4.3 HNSW 的工程局限 ​

五、IVF、PQ 与压缩：另一类重要索引机制 ​

5.1 IVF：先定位簇，再搜索候选 ​

5.2 PQ：把高维向量压缩成短编码 ​

5.3 重排与原始向量保留 ​

六、数据结构与存储：不只有一组浮点数组 ​

6.1 基础存储估算 ​

6.2 写入路径 ​

6.3 更新与删除 ​

七、元数据过滤、权限与多租户 ​

7.1 过滤顺序会改变结果 ​

7.2 过滤表达式的工程问题 ​

7.3 多租户隔离模式 ​

八、查询执行链路：从问题到候选片段 ​

8.1 分数不是概率 ​

8.2 Top-K 不是越大越好 ​

九、混合检索：向量数据库与全文搜索如何协作？ ​

十、向量数据库、向量索引、全文搜索与关系数据库的区别 ​

十一、主流技术方案：如何选择，而不是简单排名 ​

11.1 FAISS ​

11.2 PostgreSQL + pgvector ​

11.3 Qdrant ​

11.4 Milvus ​

11.5 Weaviate ​

11.6 Elasticsearch / OpenSearch ​

十二、可复现工程案例：一个最小向量检索器 ​

12.1 从基线迁移到真实数据库 ​

12.2 pgvector 的概念性 SQL 示例 ​

十三、从数据库到知识检索服务：推荐的工程分层 ​

13.1 写入流水线的幂等性 ​

13.2 零停机迁移与双索引 ​

13.3 缓存与新鲜度 ​

十四、如何科学评估向量数据库？ ​

14.1 ANN Recall@K ​

14.2 语义检索质量 ​

14.3 性能与资源指标 ​

14.4 实验设计 ​

14.5 故障与安全测试 ​

十五、常见故障及排查路径 ​

十六、安全、隐私、治理与可靠性 ​

十七、向量数据库在 Agent 与 Agent System 中的位置 ​

十八、工程选型与落地路线 ​

十九、核心结论与常见误区 ​

二十、与前后专题的关系 ​

二十一、参考文献与技术资料 ​

二十二、研究声明 ​

K3 · 什么是向量数据库？ - Vector Databases

专题导读

一、研究概述：向量数据库解决什么问题？

二、基本概念：向量、记录、集合、索引与查询

2.1 向量不是完整的数据记录

2.2 相似度与距离的方向

2.3 Top-K 查询的实际含义

三、为什么不能总是逐条比较？精确搜索与 ANN

3.1 精确最近邻（Exact Nearest Neighbor, ENN）

3.2 近似最近邻（Approximate Nearest Neighbor, ANN）

3.3 ANN 的核心权衡

四、HNSW：基于分层邻近图的搜索

4.1 直观机制

4.2 建图与查询参数

4.3 HNSW 的工程局限

五、IVF、PQ 与压缩：另一类重要索引机制

5.1 IVF：先定位簇，再搜索候选

5.2 PQ：把高维向量压缩成短编码

5.3 重排与原始向量保留

六、数据结构与存储：不只有一组浮点数组

6.1 基础存储估算

6.2 写入路径

6.3 更新与删除

七、元数据过滤、权限与多租户

7.1 过滤顺序会改变结果

7.2 过滤表达式的工程问题

7.3 多租户隔离模式

八、查询执行链路：从问题到候选片段

8.1 分数不是概率

8.2 Top-K 不是越大越好

九、混合检索：向量数据库与全文搜索如何协作？

十、向量数据库、向量索引、全文搜索与关系数据库的区别

十一、主流技术方案：如何选择，而不是简单排名

11.1 FAISS

11.2 PostgreSQL + pgvector

11.3 Qdrant

11.4 Milvus

11.5 Weaviate

11.6 Elasticsearch / OpenSearch

十二、可复现工程案例：一个最小向量检索器

12.1 从基线迁移到真实数据库

12.2 pgvector 的概念性 SQL 示例

十三、从数据库到知识检索服务：推荐的工程分层

13.1 写入流水线的幂等性

13.2 零停机迁移与双索引

13.3 缓存与新鲜度

十四、如何科学评估向量数据库？

14.1 ANN Recall@K

14.2 语义检索质量

14.3 性能与资源指标

14.4 实验设计

14.5 故障与安全测试

十五、常见故障及排查路径

十六、安全、隐私、治理与可靠性

十七、向量数据库在 Agent 与 Agent System 中的位置

十八、工程选型与落地路线

十九、核心结论与常见误区

二十、与前后专题的关系

二十一、参考文献与技术资料

二十二、研究声明