第 2.4.1 节：先判断向量数据库适合解决什么问题
进入实现之前，先围绕“先判断向量数据库适合解决什么问题”划清适用场景、不做范围和判断条件。完成本节后，你应该能够写出向量数据库的适用场景、不适用场景、前置条件和进入工程实现的判断标准。
本章要解决什么问题
上一章已经讲清了分块、Embedding（嵌入向量）、索引、召回和重排。到了本章，读者会遇到一个很现实的问题：向量应该放在哪里，项目应该选哪一种向量数据库。
新手很容易把这个问题变成产品名比较：Qdrant（向量数据库产品）是不是更简单，Milvus（向量数据库产品）是不是更强，PGVector（数据库向量扩展）/pgvector（数据库向量扩展）是不是更省事。这个问法不够工程化。真实项目里，向量数据库选型不是产品说明书，也不是流行度投票，而是要回答这些问题：
- 客服知识库现在有多少 chunk（分块），半年后会增长到多少。
- 查询时是否必须带 tenant_id（租户编号）、角色、部门、资料状态和有效期过滤。
- 客户是否要求内网部署，团队有没有专门运维人员。
- 是否需要 hybrid search（混合检索），也就是向量语义召回和关键词召回共同工作。
- 是否需要高并发、水平扩展、分片、副本和灾备。
- 向量数据丢了以后，是从源文档重建，还是必须从备份快速恢复。
- Embedding（嵌入向量）模型升级后，旧向量如何灰度重建和切换。
- 查询延迟、机器成本、云服务成本和维护成本能否被业务接受。
在企业客服知识库与工单 Agent（智能体）工作台中，选错向量数据库的后果通常不会第一天暴露。试点阶段可能一切正常，到了生产环境才发现：
- 多租户权限过滤太慢，客服回答明显卡顿。
- 旧政策和新政策混在同一个集合里，回答引用错版本。
- 没有备份策略，索引损坏后只能停机重建。
- 试点用的结构太随意，扩展到集团多部门时无法隔离数据。
- Embedding（嵌入向量）模型换了，向量维度变了，旧集合无法平滑迁移。
本章要解决的不是“哪一个产品最好”，而是教读者建立一套选型方法：根据项目规模、过滤权限、部署运维、成本、备份、混合检索和增长预期做工程选择。
本章用流程图、字段契约表、选型矩阵、失败兜底表和面试回答，帮助读者把向量数据库选型讲成可交付方案。
学习目标
学完本章后，读者应该能做到：
- 用人话解释 Vector Database（向量数据库） 在 RAG（检索增强生成） 中负责什么，不负责什么。
- 区分 Qdrant（向量数据库产品）、Milvus（向量数据库产品）和 PGVector（数据库向量扩展）/pgvector（数据库向量扩展）的典型适用场景。
- 根据小企业试点、中型客服知识库、集团多租户权限过滤三类场景做初步选型。
- 说明 metadata filter（元数据过滤）为什么会影响选型，而不只是影响查询条件。
- 设计 collection/schema（结构定义），包括集合边界、向量维度、嵌入模型、索引类型和距离度量。
- 设计向量检索字段契约，覆盖 collection_name（集合名称）、tenant_id（租户编号）、vector_dim（向量维度）、embedding_model（嵌入模型）、metadata_filter（元数据过滤）、permission_scope（权限范围）、index_type（索引类型）、distance_metric（距离度量）、top_k（召回数量）、rerank_enabled（是否重排）、backup_policy（备份策略）、rebuild_plan（重建方案）、latency_budget_ms（延迟预算）和 query_trace_id（查询追踪编号）。
- 解释 hybrid search（混合检索）、backup/rebuild（备份与重建）和增长预期如何改变技术选择。
- 说清权限、状态和日志不能只靠向量数据库完成，还需要应用层一起治理。
- 面试时把“我用了某个向量库”升级成“我如何根据业务约束做选型和验收”。
贯穿业务场景
本章继续使用贯穿项目：企业客服知识库与工单 Agent 工作台。
这个工作台要让客服、售后、主管和客户在同一个系统中完成问答、引用、工单创建、转人工和质检复盘。知识库里会有售后政策、产品手册、FAQ（常见问题）、客服 SOP（标准作业流程）、历史工单总结和培训材料。每一段资料经过分块和向量化后，都要写入向量检索系统。
为了理解选型，我们用三个规模逐步升级的场景。
| 场景 | 资料规模 | 查询特点 | 权限特点 | 选型关注点 |
|---|---|---|---|---|
| 小企业试点 | 几百份资料，几千到几万条 chunk（分块） | 并发低，主要验证问答效果 | 角色少，租户少 | 上手快、成本低、重建简单。 |
| 中型客服知识库 | 几千份资料，几十万到百万级 chunk（分块） | 客服高频查询，需要稳定延迟 | 部门、产品线、资料状态过滤 | metadata filter（元数据过滤）、混合检索、监控和备份。 |
| 集团多租户权限过滤 | 多业务线、多客户、多区域，百万到千万级以上向量 | 并发高，增长快，服务等级明确 | 租户、部门、角色、客户归属、敏感等级 | 集群能力、分片副本、权限隔离、灾备、容量规划。 |
这三类场景不应该默认使用同一种方案。小企业试点要控制复杂度，中型知识库要平衡检索质量和运维成本，集团级项目要优先考虑隔离、扩展、备份和可观测性。
再看一个具体问题：
客户问：我买的是企业版设备，签收第 6 天发现无法开机，可以直接换货吗？
这个问题进入系统后，向量数据库相关链路至少要做 6 件事：
- 在当前 tenant_id（租户编号）范围内检索，不能跨客户命中资料。
- 过滤已经发布、仍在有效期内、当前用户可见的售后政策。
- 同时考虑语义召回和关键词命中，比如“签收 7 天内”“硬件故障”“换货检测”。
- 控制 top_k（召回数量），不要把大量相似但不适用的资料塞进上下文。
- 把候选交给 Reranker（重排序器）重排，提升真正适用条款的位置。
- 记录 query_trace_id（查询追踪编号），让客服主管能复盘为什么引用了这条政策。
所以，本章的核心不是“向量数据库能不能存向量”，而是：它能否支撑企业客服场景下的权限、过滤、延迟、备份、重建和增长。
新手为什么会卡住
新手在向量数据库选型上常见卡点如下。
| 卡点 | 表面现象 | 真正原因 | 正确处理 |
|---|---|---|---|
| 只问哪个产品最好 | 在 Qdrant（向量数据库产品）、Milvus（向量数据库产品）、PGVector（数据库向量扩展）/pgvector（数据库向量扩展）之间反复摇摆 | 没有先定义项目规模和约束 | 先写清向量数量、过滤字段、并发、部署和备份要求。 |
| 只看向量检索速度 | 压测单次向量搜索很快，上线后仍然慢 | 实际查询还要 metadata filter（元数据过滤）、重排和权限校验 | 用真实查询链路验收，不只测裸向量搜索。 |
| 把权限寄托在向量库 | 以为加过滤条件就安全 | 过滤字段可能漏传，应用层也可能误展示引用 | 检索前、检索后、引用展示前都要校验权限。 |
| 忽略集合设计 | 所有资料塞进一个集合 | 版本、租户、模型维度、发布状态混杂 | 先设计 collection/schema（结构定义）和迁移策略。 |
| 忽略备份与重建 | 只考虑写入成功 | 索引损坏或模型升级时无法恢复 | 同时设计 backup_policy（备份策略）和 rebuild_plan（重建方案）。 |
| 试点架构无法长大 | 小项目上线快，扩部门时推倒重来 | 字段契约和集合边界太随意 | 试点也要保留 tenant_id、embedding_model、vector_dim、权限字段。 |
| 过早引入复杂集群 | 小试点部署一堆组件 | 团队没有运维能力，成本超过收益 | 先选可维护方案，等规模和并发证明需要再升级。 |
这些卡点本质上都来自同一个误区：把向量数据库当成单独工具，而不是 RAG 工程链路的一部分。