第 2.4.2 节：按规模、过滤和运维比较 PGVector、Qdrant 与 Milvus
本节围绕“按规模、过滤和运维比较 PGVector、Qdrant 与 Milvus”展开，先建立直观判断，再进入工程细节。完成本节后，你应该能够用对比表判断 PGVector、Qdrant 与 Milvus 的适用条件、职责边界和取舍理由。
核心概念四层解释法
下面这些概念会贯穿本章。每个概念都按四层解释：人话解释、项目位置、工程动作、面试说法。
Vector Database（向量数据库）
| 层级 | 解释 |
|---|---|
| 人话解释 | 向量数据库负责保存知识片段的语义坐标，并在用户提问时快速找出相似片段。它像客服知识库的“语义检索引擎”。 |
| 项目位置 | 在客服工作台里，它位于分块和 Embedding（嵌入向量）之后、Reranker（重排序器）和回答生成之前。 |
| 工程动作 | 选择产品，设计集合、索引、元数据字段、过滤策略、备份、重建、容量和延迟验收。 |
| 面试说法 | 向量数据库只是 RAG（检索增强生成）的一层。我会根据数据规模、过滤权限、运维能力、混合检索和灾备需求选型，而不是只报产品名。 |
Collection（集合）与 schema（结构定义）
| 层级 | 解释 |
|---|---|
| 人话解释 | collection（集合）像一个资料仓库，schema（结构定义）说明这个仓库里的每条知识片段必须有哪些字段。 |
| 项目位置 | 客服知识库可以按租户、资料类型、Embedding（嵌入向量）模型版本或业务线设计集合边界。 |
| 工程动作 | 定义 collection_name（集合名称）、vector_dim（向量维度）、distance_metric（距离度量）、索引类型、元数据字段和迁移策略。 |
| 面试说法 | 集合设计影响权限隔离、模型升级、备份恢复和查询性能。不能所有资料随意塞进一个集合，也不能拆得太碎导致检索和运维复杂。 |
metadata filter（元数据过滤）
| 层级 | 解释 |
|---|---|
| 人话解释 | 元数据过滤是先用租户、产品线、权限、版本、状态等业务标签缩小检索范围，再做语义相似搜索。 |
| 项目位置 | 客服回答售后政策时，必须过滤当前租户、当前产品线、已发布资料和当前用户可见范围。 |
| 工程动作 | 设计 tenant_id（租户编号）、permission_scope（权限范围）、publish_status（发布状态）、effective_from（生效时间）、effective_to（失效时间）等字段，并为高频过滤字段建立索引或等价优化。 |
| 面试说法 | 向量相似不等于业务适用。企业 RAG 必须把元数据过滤当成核心需求，选型时要验证过滤后的召回质量和延迟。 |
hybrid search（混合检索）
| 层级 | 解释 |
|---|---|
| 人话解释 | 混合检索是把向量语义搜索和关键词搜索结合起来。用户说法模糊时靠语义，问题里有订单规则、政策编号、产品型号时靠关键词。 |
| 项目位置 | 客服知识库里，“签收 7 天”“企业版 X200”“SLA-3”这类精确词不能只靠语义相似。 |
| 工程动作 | 决定向量库是否内置支持稀疏向量、全文检索或多路召回；如果不内置，就在应用层合并向量结果和关键词结果，再交给重排。 |
| 面试说法 | 混合检索不是为了堆技术，而是为了处理客服资料中的精确规则、型号、编号和口语表达。选型时要看产品能力，也要看系统能否记录融合前后的分数和候选。 |
index_type（索引类型）与 distance_metric（距离度量）
| 层级 | 解释 |
|---|---|
| 人话解释 | 索引类型决定怎么快速找相似向量，距离度量决定“相似”怎么算。 |
| 项目位置 | 同一批客服知识片段写入集合时，必须和 Embedding（嵌入向量）模型的推荐距离度量匹配。 |
| 工程动作 | 在 HNSW（向量索引算法）、IVF（倒排文件索引）、Flat（精确检索）等索引思路之间取舍，记录 distance_metric（距离度量），用评估样例验证召回率和延迟。 |
| 面试说法 | 索引不是越复杂越好。小规模可以优先简单，规模变大后再用近似索引换速度，但必须监控召回损失。 |
backup/rebuild（备份与重建）
| 层级 | 解释 |
|---|---|
| 人话解释 | 备份是把当前索引状态保存下来，重建是从源文档、分块和 Embedding（嵌入向量）任务重新生成索引。 |
| 项目位置 | 客服知识库上线后，政策更新、模型升级、索引损坏、迁移环境都会触发备份或重建。 |
| 工程动作 | 设计 backup_policy（备份策略）、rebuild_plan（重建方案）、重建数据源、耗时预算、灰度集合和回滚方式。 |
| 面试说法 | 向量库不是写入一次就结束。生产项目要同时有备份恢复和可重建能力，因为向量索引可以从源资料重建，但重建耗时和服务中断必须被管理。 |
PGVector（数据库向量扩展）/pgvector（数据库向量扩展）
| 层级 | 解释 |
|---|---|
| 人话解释 | PGVector（数据库向量扩展）/pgvector（数据库向量扩展）是让 PostgreSQL（开源关系型数据库）支持向量存储和相似搜索的扩展。行业里常说 PGVector（数据库向量扩展），扩展项目名通常写作 pgvector（数据库向量扩展）。 |
| 项目位置 | 如果客服工作台已经用 PostgreSQL（开源关系型数据库）保存文档、租户、权限和工单，小规模知识库可以把向量也放在同一套数据库体系里。 |
| 工程动作 | 评估表结构、索引、过滤字段、备份方式、业务库隔离、查询延迟和未来迁移路径。 |
| 面试说法 | PGVector（数据库向量扩展）/pgvector（数据库向量扩展）的优势是基础设施少、事务和备份体系成熟；风险是大规模、高并发、复杂向量检索时要谨慎压测，不要把业务库拖慢。 |
本章在客服工作台中的位置
客服 Agent（智能体）工作台可以拆成 8 层。
| 层级 | 作用 | 本章关注点 |
|---|---|---|
| 资料接入层 | 上传政策、手册、FAQ（常见问题）、SOP（标准作业流程） | 提供向量库的源数据。 |
| 分块与元数据层 | 生成 chunk（分块）和业务标签 | 决定写入向量库的字段质量。 |
| Embedding（嵌入向量）层 | 把文本转成向量 | 决定 vector_dim（向量维度）和 distance_metric（距离度量）。 |
| 向量数据库层 | 存储向量、元数据和索引 | 本章核心：选型、集合、索引、过滤、备份、重建。 |
| 检索编排层 | 构造查询、混合召回、合并候选 | 本章关注：hybrid search（混合检索）和 top_k（召回数量）。 |
| 重排与引用层 | 重排候选并生成引用片段 | 使用向量库返回的候选和分数。 |
| Agent 回答层 | 基于依据回答或转人工 | 依赖检索质量和权限结果。 |
| 日志与评估层 | 记录 query_trace_id（查询追踪编号）、延迟、过滤和命中 | 本章核心：验收选型是否稳定。 |
本章不负责“文档怎么分块”的全部细节，也不负责“模型怎么生成最终回答”。本章负责的是：让向量数据以正确结构、正确权限、正确索引、正确备份方式承载客服知识库检索。
系统流程图
完整链路先分成“知识发布与索引版本”和“查询、召回与回答”两段阅读，再把备份重建回路接回发布链。需要先抓住三个重点：
- 向量数据库不是只保存向量，还要保存元数据、索引状态和集合版本。
- 查询不是单纯相似搜索，而是权限过滤、向量召回、关键词召回、重排、引用和日志的组合。
- 生产系统必须同时考虑 backup（备份）和 rebuild（重建），否则索引出问题时无法稳定恢复。
A. 知识如何变成可发布的索引版本
发布链按“资料上传与审核 → 文档解析与分块 → 补齐元数据：租户、产品线、权限、版本、状态 → 生成 Embedding 嵌入向量 → 选择或创建 collection 集合 → 写入向量、文本摘要和元数据 → 建立向量索引与元数据过滤索引 → 发布索引版本”推进。发布后的两个运维出口是定期备份，以及模型升级或索引异常时重建；重建不会覆盖线上集合，而是回到选择或创建 collection 集合生成新版本。
读图重点：发布不是一次写入：索引通过验证后才能服务，并始终保留备份和新版本后台重建两条恢复路径。
B. 用户问题如何变成有依据的回答
查询主链按“用户提出客服问题 → 构造查询与权限范围 → 读取 collection_name 和过滤条件 → metadata filter 元数据过滤 → 向量召回 → 合并候选 → 是否启用 rerank”推进；构造查询与权限范围还会同时进入关键词或稀疏召回，再汇入合并候选。判断为“是”时进入重排序，判断为“否”时按召回分数截断，两条分支都会进入生成引用片段 → Agent 生成带依据回答 → 记录 query_trace_id、延迟、过滤、候选和引用。
读图重点：两路召回在候选层汇合，重排或截断只是质量门；引用、回答和日志必须共享同一条可追踪证据链。
模块拆分
向量数据库选型落地后，不要把所有逻辑写成一个“检索模块”。在客服工作台中，建议拆成这些模块。
| 模块 | 职责 | 输入 | 输出 |
|---|---|---|---|
| 向量库选型配置模块 | 保存当前项目使用 PGVector（数据库向量扩展）/pgvector（数据库向量扩展）、Qdrant（向量数据库产品）还是 Milvus（向量数据库产品），以及连接方式和能力开关 | 项目规模、部署配置、选型结论 | vector_store_profile（向量库配置档案）。 |
| 集合管理模块 | 管理 collection_name（集合名称）、schema（结构定义）、vector_dim（向量维度）、distance_metric（距离度量） | 资料类型、租户策略、模型版本 | 可写入和可查询的集合定义。 |
| 写入与发布模块 | 接收分块结果，生成向量，写入集合，审核后发布 | chunk（分块）、metadata（元数据）、embedding_model（嵌入模型） | 已发布索引版本。 |
| 元数据过滤模块 | 根据租户、角色、资料状态、有效期构造 metadata_filter（元数据过滤） | 用户身份、会话、资料范围 | 过滤条件和过滤日志。 |
| 检索编排模块 | 执行向量召回、关键词召回、混合合并和 top_k（召回数量）控制 | 用户问题、查询向量、过滤条件 | 候选片段列表。 |
| 重排与引用模块 | 根据 rerank_enabled（是否重排）决定是否重排，并生成可展示引用 | 候选片段、用户权限 | 最终引用片段。 |
| 备份与重建模块 | 执行 backup_policy（备份策略）和 rebuild_plan（重建方案） | 集合版本、源文档、向量任务 | 可恢复快照或重建索引。 |
| 日志与评估模块 | 记录 query_trace_id（查询追踪编号）、延迟、过滤、候选、错误和命中质量 | 查询过程数据 | 可复盘日志和评估报表。 |
这样的拆分能帮助读者理解：向量数据库选型不是一个配置项，而是一组工程边界。