向量数据库教程：FAISS、Milvus、Qdrant、Weaviate、pgvector和Chroma
摘要
向量数据库在 RAG、语义搜索和智能体记忆中经常被当成单一组件讨论，但生产质量通常取决于一条更长的检索链：文档治理、切分策略、embedding 模型、索引结构、metadata 过滤、重排、权限、引用和评测共同决定答案是否可靠。本文把 FAISS、Milvus、Qdrant、Weaviate、pgvector 和 Chroma 放在同一个工程坐标系中比较，不追求“哪个产品最好”，而追问在什么数据规模、过滤复杂度、权限边界、运维能力和重建要求下，哪种方案更不容易失真。
关键词
向量数据库；FAISS；Milvus；Qdrant；Weaviate；pgvector；Chroma；RAG；混合检索；权限过滤；Recall@K
研究问题与方法
本文围绕三个问题展开：向量库解决的是语义召回问题，还是被误用成权威业务数据库；近似索引、payload 过滤和重排怎样共同影响召回质量；选型时如何把性能指标、权限能力和可重建性放进同一张决策表。方法上，文章先抽象检索链路，再比较不同产品的系统边界，最后用 Recall@K、引用正确率、权限命中和重建时间作为验收指标。
下图强调本文的核心立场：向量数据库只是可重建索引层，不能脱离源数据、权限系统和评测闭环独立判断。
检索质量至少要用集合指标表达，而不是只看一次演示回答：
其中 是查询， 是人工或业务规则确认的相关资料集合， 是检索链路返回的前 K 个候选。这个指标不能单独代表最终答案质量，但能揭示模型回答前证据入口是否已经丢失。
向量数据库不是“把文本变成向量后存起来”这么简单。它处在 AI 应用的关键位置：上游要接收文档、图片、视频片段、业务记录和用户行为，下游要服务语义搜索、知识库问答、推荐、去重、相似案例匹配、智能体记忆和多模态检索。一个检索系统回答得准不准，很多时候不是大模型一端决定的，而是向量切分、embedding 模型、索引结构、过滤条件、重排策略、权限边界和评测集共同决定的。
中文工程实践里，最常见的误解是把向量数据库当成普通数据库替代品。向量库擅长做相似度召回，不擅长替业务系统承担全部事实存储；它可以保存 payload、metadata 或对象字段，但这不等于它应该成为订单、合同、权限、账单和审计的唯一来源。更稳的设计，是把原始业务数据留在权威系统里，把向量库当作可重建的检索索引。这样更容易处理权限变化、模型升级、重建索引、备份恢复和质量回滚。
这篇教程按工程路径讲清楚向量数据库：先解释向量、距离、召回和索引，再分别看 FAISS、Milvus、Qdrant、Weaviate、pgvector 和 Chroma 的定位，最后给出选型、分片、过滤、备份、权限和评测方法。读者不需要一次性学完所有产品，但需要建立一套判断框架：小数据量是不是可以精确检索，过滤条件是不是会破坏召回，是否需要分布式写入，权限是否能在检索前生效，索引是否能重建，回答是否带引用，效果是否有客观评测。
引言：向量数据库解决什么问题
传统数据库擅长按确定条件查找，例如主键、状态、时间、枚举字段、数值区间和全文关键词。向量数据库要解决的问题不同：用户输入一句自然语言、一张图片、一段音频转写、一条客户反馈，系统希望找到语义上最接近的资料，即使字面词不完全一样。比如用户问“怎么取消自动续费”，知识库里可能写的是“关闭订阅扣款”；用户上传一张缺陷照片，系统要找相似缺陷案例；客服看到一段投诉描述，要匹配历史处理方案。这些场景都需要相似度检索。
向量检索的核心流程是：先用 embedding 模型把内容编码成固定维度的向量，再用距离函数计算查询向量和库存向量之间的相近程度，最后返回 TopK 候选结果。距离函数常见有余弦相似度、内积和欧氏距离。模型训练方式不同，适合的距离函数也不同，不能随意混用。很多工程问题就出在这里：入库时用一个模型，查询时换了另一个模型；索引按余弦建，查询按欧氏排；文本和图片混到一个向量空间，却没有确认模型是否支持跨模态对齐。
向量数据库并不只存向量。真正可用的检索系统还要保存文档 ID、段落 ID、标题路径、来源、版本、作者、租户、权限、时间、业务对象、语言、资料状态、引用位置和其他 metadata。向量负责“像不像”，metadata 负责“能不能用、属于谁、是否最新、是否允许展示”。没有 metadata，向量搜索只能返回相似片段，无法满足生产应用中的权限过滤、结果解释和引用追溯。
向量库也不是越大越好。对几千条资料，直接用精确搜索可能比复杂近似索引更稳；对几十万到几百万条资料，HNSW、IVF 等近似索引能显著降低延迟；对千万到十亿级数据，分片、压缩、冷热分层、批量导入、索引重建和集群运维就变成核心问题。选型应该从数据规模、更新频率、过滤复杂度、权限要求、延迟目标、部署能力和成本约束出发，而不是从产品热度出发。
向量、分块和 embedding 模型要一起设计
很多团队一开始只关注向量数据库，忽略了 embedding 模型和分块策略。实际上，向量库只能在已有向量空间里找近邻，无法修复输入表示本身的问题。如果文档切分混乱、标题丢失、表格结构丢失、中文分词异常、图片 OCR 错误、embedding 模型不适合业务领域，换再强的向量库也很难得到稳定召回。
文本知识库常见做法是按章节、标题、段落、表格和语义边界切分。过短的片段缺少上下文，容易召回零散句子；过长的片段包含多个主题，向量会变得模糊，重排和引用也不清楚。中文场景尤其要保留标题层级和上下文路径，例如“产品手册 > 计费 > 退款规则 > 企业版例外”。用户看到引用时，不只需要一段话，还需要知道它属于哪份资料、哪个版本、哪一节。
业务数据切分要尊重对象边界。工单可以按“问题描述、处理过程、最终结论”组织；合同可以按条款和附件组织；代码可以按文件、类、函数和注释组织；报表可以按指标口径、维度和时间范围组织。不要把所有内容都变成固定长度字符块。固定长度切分方便实现，但容易把字段名和字段值、规则和例外、代码定义和调用关系拆开。
embedding 模型选择决定检索语义。中文知识库要测试中文表达、口语化问题、专业术语、同义表达、长句和短问句；跨语言场景要测试中文问英文资料、英文问中文资料；多模态场景要确认文本、图片和视频帧是否在同一向量空间里可比较。工程上最好为每个模型版本建立索引版本号。换 embedding 模型不是换一个配置项，而是整个索引需要重算，评测也要重跑。
向量维度越高，并不必然越好。高维向量可能带来更高存储、内存和计算成本。模型是否适配任务、训练数据是否接近领域、分块是否合理、重排是否到位，通常比盲目追求高维更重要。一个生产级知识库，常见组合是：较稳的 embedding 模型负责第一阶段召回，metadata 过滤保证范围正确，全文检索补充关键词匹配，重排模型负责精细排序，生成模型只基于通过过滤和重排的片段作答。
精确搜索和近似搜索
向量检索可以分为精确搜索和近似搜索。精确搜索会计算查询向量和全部候选向量的距离，理论上能得到真正最近邻，召回最稳定，但数据量大时成本高。近似搜索通过索引结构减少比较次数，用一点召回损失换取更低延迟和更高吞吐。生产系统里，近似搜索非常常见，但它不是免费的：索引参数会影响召回、延迟、内存、构建时间和更新成本。
Flat 索引本质上是暴力搜索。它适合小规模数据、离线评测基线、召回质量校验和对准确性要求极高但延迟可接受的任务。许多团队直接从 HNSW 或 IVF 开始，反而不知道自己损失了多少召回。更可靠的做法，是先用 Flat 或精确搜索建立基线，再调近似索引参数，比较 Recall@K、延迟和成本。
IVF 是倒排文件索引思想在向量检索中的应用。它先把向量聚类到多个中心，查询时只搜索离查询向量最近的一部分簇。IVF 的关键参数包括聚类数量和查询时探测的簇数量。簇太少，候选范围粗糙；簇太多，训练和维护成本高；探测簇太少，召回下降；探测簇太多，延迟接近暴力搜索。IVF 适合数据规模较大、向量分布相对稳定、可以接受训练索引的场景。
PQ 是乘积量化，用压缩码表示向量，主要目标是降低内存和存储成本。IVF-PQ 常用于大规模检索，把“先缩小候选范围”和“压缩候选向量”结合起来。代价是距离计算变成近似，召回和排序精度会下降。为了减少损失，工程上常会先用压缩索引召回较多候选，再读取原始向量或更高精度表示做重排。
HNSW 是图结构近似最近邻索引。它把向量组织成多层导航图，查询时从高层快速接近目标区域，再在底层寻找近邻。HNSW 的优势是召回和延迟表现通常较好，适合中大型在线检索；代价是内存占用较高，构建参数、查询参数和更新策略需要调优。很多向量数据库默认推荐 HNSW，但默认参数不一定适合每个业务。
近似索引调优要有基准。只看平均延迟不够，要看 P95、P99、并发写入、冷启动、过滤后结果不足、热门租户压力和索引重建时间。只看人工主观效果也不够，要用标注问题集计算 Recall@K、MRR、NDCG、命中率和引用正确率。没有评测，调参只是在靠感觉。
FAISS：高性能向量检索库，不是完整数据库
FAISS 由 Meta AI 开源，定位更接近高性能相似度搜索库，而不是完整数据库。它提供大量索引结构，包括 Flat、IVF、PQ、OPQ、HNSW、二进制索引和 GPU 加速能力。很多向量数据库和检索系统的底层设计都受到 FAISS 影响。学习 FAISS 的价值不只是会写几行 Python，而是理解索引结构背后的取舍。
FAISS 最适合需要本地高性能检索、离线实验、可控索引结构、GPU 加速和自定义流水线的团队。比如研究团队要评估不同 embedding 模型，工程团队要做百万级离线相似案例匹配，推荐系统要在批处理阶段做近邻召回，都可以使用 FAISS。它提供了非常灵活的 index factory 语法，可以组合 IVF、PQ、HNSW 等结构。
但 FAISS 本身不提供完整的多租户、权限、备份、在线服务、分布式副本、API 鉴权和业务 metadata 管理。它可以保存向量 ID，也可以结合外部映射表使用，但生产系统需要自己处理文档存储、权限过滤、增删改、索引持久化、服务封装、并发和恢复。对很多 Web 应用来说，FAISS 是强大的引擎，不是开箱即用的向量数据库。
FAISS 的典型学习路径是从 IndexFlatL2 或 IndexFlatIP 开始，建立精确搜索基线；再尝试 IndexIVFFlat，理解训练、聚类和探测参数；数据量变大后引入 IndexIVFPQ，观察压缩对召回的影响；对需要高召回低延迟的场景测试 HNSW；如果有 GPU 资源，再评估 GPU 索引构建和查询。每一步都要和 Flat 基线比较，而不是只看速度。
FAISS 的过滤能力需要特别注意。它有 IDSelector 等机制可以限制候选 ID，但它不是围绕复杂 metadata 过滤构建的数据库。若业务有大量租户、权限、时间范围、分类、状态等过滤条件，通常需要先在外部系统计算可检索候选集合，或把 FAISS 嵌入更完整的服务层。否则很容易出现“向量搜索很快，但过滤后结果不足或越权风险难控”的问题。
Milvus：面向大规模和分布式生产场景
Milvus 是专门面向向量数据库场景的开源系统，适合数据规模较大、需要分布式部署、在线查询、批量导入、分区管理和生产运维的团队。它不是一个轻量本地库，而是一套完整服务，包含集合、字段、索引、分区、负载、查询节点、数据节点和存储组件等概念。对企业级 RAG、图像检索、推荐召回和多业务向量平台，Milvus 的优势在于规模化和系统化。
Milvus 支持多种向量类型和索引策略，包括浮点向量、二进制向量、稀疏向量，以及 IVF、HNSW、SCANN、DiskANN 等不同索引族。具体可用索引会随版本和部署形态变化，选型时要以当前官方文档为准。工程上不应只问“哪个索引最快”，而要问数据量、召回目标、内存预算、写入频率、过滤比例和硬件条件。
Milvus 的 collection 类似一类数据的容器，schema 里可以包含主键、向量字段和标量字段。标量字段可以用于 metadata 过滤，例如租户、分类、状态、时间、语言和权限标签。生产系统应尽量把常用过滤字段建好标量索引，避免每次向量搜索后再靠应用层过滤。因为后过滤不仅影响召回，也可能让无权限候选进入中间环节。
分区是 Milvus 的重要能力。分区可以按租户、业务线、时间、文档类型或冷热数据划分候选范围。合理分区能减少无关搜索，提高性能，也有助于数据生命周期管理。但分区不是越细越好，过多分区会增加管理和查询开销。常见做法是把高频、强边界字段用于分区，把低频、多值字段留给标量过滤。
Milvus 在生产中还要关注备份和恢复。向量库常被当作“可以重建的索引”，但这不代表不需要备份。若数据规模很大，重新解析、重新 embedding、重新导入和重建索引会消耗大量时间。生产系统应同时保存原始数据、解析结果、embedding 模型版本、索引参数和 Milvus 备份。这样才能在误删、版本回滚、集群迁移或灾难恢复时有明确路径。
权限方面，Milvus 提供用户、角色和权限相关能力。企业落地时，不应只依赖应用层约定，也要规划数据库连接凭证、角色授权、服务账号隔离和管理操作审计。尤其是多个业务共用一个 Milvus 集群时，要明确谁能创建集合、删除集合、导入数据、查询哪些集合、执行备份恢复和管理索引。
Qdrant：payload 过滤和工程体验清晰
Qdrant 是 Rust 编写的向量数据库，工程体验较清晰，尤其强调 payload 过滤、集合管理、HNSW 检索和快照。它适合需要向量检索与 metadata 过滤紧密结合的应用，例如多租户知识库、用户级文档检索、商品检索、推荐召回和相似案例匹配。Qdrant 的 payload 不是装饰字段，而是过滤、排序和业务解释的重要组成部分。
Qdrant 的数据单位通常称为 point，每个 point 包含向量、ID 和 payload。payload 可以保存结构化字段，例如租户、用户、文档来源、标签、时间、状态、语言和权限范围。查询时可以通过 filter 表达 must、should、must_not、范围、匹配和嵌套条件。一个健康的 Qdrant 设计，应该把过滤条件前置到查询里，而不是召回后再在应用代码里删除不该看的结果。
Qdrant 使用 HNSW 作为核心近似索引，并提供 payload index 来加速结构化过滤。过滤字段如果不建索引，小数据量时也许看不出问题，数据量大后延迟和召回稳定性都会受影响。工程实践中，租户、权限、状态、类型、时间等高频过滤字段应进入索引规划。对强隔离场景，可以考虑按租户或数据域拆 collection；对普通场景，可以用统一 collection 加严格 payload filter。
Qdrant 的快照机制适合导出和恢复集合。快照包含特定集合在某个时间点的数据和配置，常用于备份、迁移和灾难恢复。需要注意的是，快照不是替代上游数据治理的唯一方案。原始文档、解析文本、embedding 模型版本和业务数据库仍要保存；快照负责恢复向量库状态，不能解释为什么某段资料应该存在或谁有权访问它。
在分布式场景下，Qdrant 支持分片和副本相关配置。分片影响数据分布和扩展能力，副本影响可用性和读能力。选型时要评估写入模式：是持续小批量写入，还是周期性大批导入；是少量大租户，还是大量小租户；是读多写少，还是实时更新。向量库分片策略一旦与租户和权限边界冲突，后续迁移会很痛。
安全上，Qdrant 提供 API key、访问控制和云服务相关能力。企业使用时要把管理密钥、应用查询密钥、写入服务密钥区分开，不要让前端或普通业务服务拿到能删除集合、创建快照或修改配置的凭证。对知识库问答，真正的权限边界仍应由业务身份、payload 过滤和引用访问控制共同完成。
Weaviate：对象模型、混合检索和模块化生态
Weaviate 是面向向量搜索和语义应用的数据库，特点是对象模型、向量索引、倒排索引、混合检索、多租户、模块化向量化和较完整的产品化能力。它不像 FAISS 那样只提供索引库，也不只是简单的向量键值服务。Weaviate 把数据对象、属性、向量和检索 API 组织在一起，适合构建语义搜索、知识库、推荐和多模态检索应用。
Weaviate 的 collection schema 可以定义对象属性、向量化配置和索引配置。向量索引支持 HNSW、Flat、Dynamic 等类型，官方文档通常建议多数场景使用 HNSW，低数据量或强多租户小集合可以考虑 Flat。过滤方面，Weaviate 通过倒排索引支持标量过滤，并能把过滤和向量搜索结合。对生产应用来说，这一点很重要：用户检索时往往不是“全库找相似”，而是在权限、状态、类型、时间和业务范围内找相似。
Weaviate 的混合检索能力适合关键词和语义都重要的场景。中文企业知识库经常需要同时匹配“费用报销”“报销费用”“invoice”“发票”等语义表达，又要精确命中产品型号、错误码、合同编号和字段名。单纯向量检索可能漏掉精确标识，单纯关键词检索可能漏掉同义表达。混合检索把稀疏检索和密集向量结合，再通过权重或融合策略排序，是许多知识库的实用方案。
多租户和权限是 Weaviate 生产使用必须考虑的部分。Weaviate 提供多租户和 RBAC 能力，适合把不同客户或组织空间隔开。但业务应用仍要决定租户边界、用户身份、资源权限、引用访问和导出规则。数据库层有能力不代表产品权限自动完成，尤其是同一租户内部还有团队、项目、文档密级和资料状态差异。
备份方面，Weaviate 提供备份配置和恢复能力，并且需要关注对象存储、索引状态、RBAC 角色和集群一致性等细节。生产系统做备份时，要同时记录 schema、向量化模型、业务数据版本和备份时间点。若只备份向量库，不备份源文档和解析结果，恢复后依然难以验证资料是否完整。
Weaviate 适合希望向量库承担更多语义应用能力的团队。它的优势是对象化、混合检索、模块生态和应用接口；代价是系统概念比轻量库更多，部署和运维要认真规划。对只需要本地实验的项目，它可能偏重；对多租户生产知识库和语义搜索平台，它提供了比较完整的基础。
pgvector：把向量检索放进 PostgreSQL
pgvector 是 PostgreSQL 扩展，让开发者在熟悉的关系数据库里存储向量并做相似度搜索。它的最大优势不是极限性能，而是把向量检索和关系数据、事务、权限、备份、SQL、行级安全、JOIN、迁移工具和现有运维体系结合起来。对很多中小型 AI 应用来说，pgvector 是非常务实的起点。
pgvector 默认可以做精确最近邻搜索，也支持 HNSW 和 IVFFlat 近似索引。HNSW 通常适合追求较好召回和延迟的在线查询，IVFFlat 适合数据量达到一定规模后通过 lists 和 probes 调节性能。官方 README 明确提醒，IVFFlat 索引如果在数据太少时创建，效果可能不好；HNSW 查询结果数量也会受到候选列表和过滤条件影响。工程上要在真实数据规模下建索引和评测，而不是拿几十条样本判断。
pgvector 和过滤条件结合时要特别小心。SQL 里可以写 WHERE category_id = 123 ORDER BY embedding <-> query LIMIT 10，但近似索引扫描和过滤的执行顺序会影响结果数量和召回。pgvector 新版本提供 iterative index scans，用于在过滤后结果不足时继续扫描更多候选。除此之外，常见策略还包括给过滤字段建普通索引、使用 partial index、按高基数字段做表分区，以及在低选择性过滤下考虑精确扫描。
pgvector 的权限和备份优势来自 PostgreSQL。企业若已经有成熟的 PostgreSQL 备份、监控、RLS、审计和迁移体系，pgvector 可以减少新增基础设施成本。比如每条文档片段都在关系表里带 tenant_id、space_id、document_id、version、visibility、created_at 等字段，再通过 SQL 权限和业务层策略控制检索范围。对于强关系约束、多表 JOIN 和业务一致性要求高的应用，这比单独维护一个向量库更简单。
pgvector 的短板也要清楚。它不是专门为超大规模分布式向量检索设计的系统，面对亿级向量、高并发多租户、复杂混合检索、独立向量集群扩容和极致低延迟，可能不如专门向量数据库合适。它更适合从原型到中等规模生产的路径：先把知识库、业务数据和向量放在一个可控数据库中，等规模和性能需求明确后，再评估是否引入 Milvus、Qdrant 或 Weaviate。
一个实用建议是：只要团队还没有证明向量检索会成为独立性能瓶颈，pgvector 往往值得先试。它让开发者把注意力放在分块、embedding、过滤、引用和评测上，而不是过早承担独立集群运维。等数据量、并发、隔离和延迟目标确实超过 PostgreSQL 舒适区，再迁移到专门向量库会更稳。
Chroma：适合原型、实验和轻量知识库
Chroma 常用于本地 RAG 原型、轻量知识库和开发实验。它的 API 易上手，collection、document、metadata、embedding 和 query 概念清晰，和许多 RAG 框架集成方便。对学习者来说，Chroma 是理解向量检索流程的好工具：创建 collection，写入文档和 metadata，查询时传入文本或向量，返回相似结果和距离。
Chroma 支持 metadata 过滤和文档内容过滤。查询时可以用 where 按 metadata 条件限制范围，也可以用 where_document 做文本内容条件。这个能力对小型知识库很实用，例如按资料类型、项目、语言、发布时间或状态过滤。但生产系统仍要注意：过滤字段设计、权限边界、引用访问和数据生命周期，不会因为 API 简单就自动成立。
Chroma 的优势是轻量和开发效率。学习 RAG、验证分块策略、测试 embedding 模型、构建单机知识库、做团队内部小工具，它都能快速启动。对很多教程和实验项目，Chroma 比分布式向量库更合适，因为学习重点在检索流水线而不是集群运维。
但如果应用进入严肃生产，就要评估 Chroma 部署形态、持久化、鉴权、备份、多租户、权限、监控和扩容能力。Chroma Cloud 和开源自托管路径提供不同能力，企业不能把本地开发体验直接等同于生产保障。尤其是客户数据和内部敏感资料进入知识库后，权限过滤、密钥管理和备份恢复必须提前设计。
Chroma 的合理定位是：快速验证和中小规模场景优先，复杂生产边界谨慎评估。不要因为原型跑得通，就默认它适合所有规模；也不要因为大型向量库功能更多，就在第一天放弃轻量方案。工具选择要匹配阶段。
六个方案如何选
如果你在学习向量检索原理，FAISS 是很好的起点。它能让你直接看到 Flat、IVF、PQ、HNSW 等索引结构的效果差异，也适合做离线评测基线。缺点是生产服务能力需要自己补齐。若团队有算法和工程能力，FAISS 可以成为自定义检索系统的核心组件；若团队希望快速上线多租户知识库，单独用 FAISS 会承担较多额外工作。
如果你需要大规模分布式向量平台，Milvus 是强候选。它适合海量向量、专门运维团队、多业务共享集群、复杂索引和批量数据管道。缺点是系统复杂度较高，部署、监控、备份和资源规划都要认真投入。对数据量还不确定的小项目，Milvus 可能偏重；对明确要支撑大规模检索的平台，Milvus 的系统化能力很有价值。
如果你重视 payload 过滤、API 清晰和相对轻巧的生产体验，Qdrant 值得评估。它适合多租户知识库、语义搜索、相似案例和推荐召回。尤其当业务强依赖 metadata 过滤时，Qdrant 的表达比较直接。需要注意的是，collection、分片、副本、payload index 和快照策略仍要根据实际规模设计。
如果你希望向量库同时承担对象存储、混合检索、多租户和语义应用接口，Weaviate 很适合。它的优势在于完整应用生态和对象化模型，适合构建语义搜索产品。代价是概念较多，学习和运维成本高于最轻量方案。对需要关键词加语义检索、对象属性过滤和生产权限能力的团队，它是成熟选项。
如果你的业务数据已经在 PostgreSQL，规模尚未达到独立向量集群的必要程度，pgvector 通常最务实。它让向量检索和 SQL、权限、备份、事务、RLS、审计、迁移工具共处一套体系。缺点是极大规模和专用向量性能不一定占优。很多生产项目可以先用 pgvector 把检索质量做对，再决定是否拆出专门向量库。
如果你要做本地原型、课程实践、轻量知识库或快速验证，Chroma 上手最快。它适合让团队先把分块、embedding、召回、过滤、重排和生成流程跑通。进入生产后，要重新审视持久化、权限、备份、多租户和监控。Chroma 不是玩具，但它最适合从低摩擦起步。
召回链路不要只靠向量相似度
生产级 RAG 很少只做一次向量 TopK。更常见的链路是：查询改写或扩展，按权限和业务范围过滤候选，向量检索召回一批结果，全文检索补充关键词结果，合并去重，重排模型重新排序，按多样性和引用规则截取上下文，最后交给生成模型回答。向量数据库负责其中一部分，不负责全部质量。
查询改写可以处理用户表达和知识库表达不一致的问题。用户问“这个能退吗”，系统可能需要结合当前商品、合同、订单状态和退款规则，把查询扩展成“企业版订阅退款条件、自动续费取消、合同期内退费”。但查询改写不能突破权限，也不能把用户没有提供的事实当成事实。改写后的查询同样要经过 metadata 过滤和审计。
混合检索对中文业务很重要。中文用户常用同义词、简称、错别字和口语化表达；业务资料里又有型号、编号、字段、版本、错误码和专有名词。向量检索擅长语义，全文检索擅长精确词。两者合并后，再用重排模型判断语义相关性，通常比单独一种检索更稳。
重排模型是提高相关性的常见手段。第一阶段召回可以取较大的候选数，例如 50 或 100；第二阶段用 cross-encoder 或大模型评分，把最相关的 5 到 10 条放入上下文。这样能缓解向量索引近似误差、分块边界不理想和关键词噪声。代价是增加延迟和成本，需要缓存、批处理和超时策略。
召回结果要有多样性控制。如果 TopK 全部来自同一份长文档的相邻片段，模型可能忽略其他资料。可以按文档、章节、来源、时间和类型做去重或配额，让上下文覆盖多个证据。对于需要引用的回答，还应优先选择位置明确、版本最新、可信等级高的片段。
metadata 过滤是生产系统分水岭
向量检索在演示中常常是全库搜索，但生产中几乎一定要过滤。用户只能看自己租户、组织、项目、角色允许的资料；问题可能只属于某个产品线、版本、地区、语言和时间范围；资料也有草稿、已发布、归档、删除和过期状态。没有 metadata 过滤，向量库无法进入真实业务。
过滤要尽量发生在检索前或检索过程中，而不是生成后。先召回全库，再删除无权限结果，会带来三个问题：无权限片段可能进入中间日志或重排；过滤后 TopK 数量不足，回答质量下降；系统性能浪费在无关候选上。更稳的做法是把租户、权限、资料状态、数据域等字段作为检索条件的一部分。
过滤字段要从业务建模开始设计，而不是后期补救。常见字段包括 tenant_id、space_id、document_id、version、source_type、visibility、status、language、created_at、updated_at、owner、security_level、allowed_roles、allowed_users、project_id、region、product_version。字段太少，无法控制范围；字段太多且不建索引，查询会变慢。字段设计要和产品权限模型一起做。
过滤会影响索引选择。HNSW 在过滤选择性很强时，可能出现候选不足；IVF 在某些低选择性或分区场景下表现更稳定；pgvector 需要注意近似索引和 WHERE 条件的执行行为；Weaviate、Qdrant、Milvus 都需要为标量字段建立相应索引或配置。不要把过滤当作附加功能，它是检索架构的一部分。
多租户场景要决定共享索引还是独立索引。共享索引成本低、管理简单，但必须保证过滤严格；独立索引隔离更强、恢复和迁移更清楚，但数量多后运维复杂。常见折中是普通小租户共享 collection，大客户或高敏数据独立 collection 或独立集群。无论哪种方式，都要确保缓存键、引用链接和导出文件也包含租户边界。
分片、分区和副本怎么理解
分区和分片经常被混用。分区更多是逻辑层划分候选范围，例如按租户、时间、业务线、资料类型拆分；分片更多是物理层把数据分布到多个节点或 shard 上，以支撑容量和吞吐。两者都能影响性能，但目标不同。分区帮助减少无关搜索，分片帮助横向扩展。
按租户分区适合租户之间边界明确、查询很少跨租户的系统。优点是权限过滤简单，备份和迁移也清楚；缺点是租户数量很大时，分区或 collection 数量可能爆炸。按时间分区适合日志、新闻、工单和事件数据，能支持冷热分层和过期清理。按业务线分区适合产品资料、知识库空间和行业数据，能减少跨域噪声。
分片策略要考虑数据分布。若少数大客户占据大部分数据，按租户静态分片可能导致热点；若写入集中在最新时间段，按时间分片可能导致新 shard 压力过高；若查询经常跨多个分片，聚合和排序成本会上升。向量检索不像普通主键查询，跨分片 TopK 合并需要从每个分片拿候选再全局排序。
副本用于可用性和读扩展。副本越多，读取能力和容灾能力越好，但写入、存储和一致性成本增加。生产系统要明确一致性要求：新上传文档是否必须立刻可检索，还是可以接受几秒到几分钟延迟；删除或权限收紧是否必须立即生效；备份恢复后是否允许短时间只读。不同答案会影响集群配置。
不要把分片当成后期轻松改动的参数。向量数据一旦到达千万级，重新分片、重建索引和迁移集群都很耗时。早期可以从简单策略开始，但要保留索引版本、数据导出、批量重建和双写迁移路径。真正的生产能力不是永远不迁移，而是迁移时知道源数据在哪里、索引如何重建、流量如何切换、效果如何验证。
备份、恢复和重建索引
向量数据库的备份不能只问“有没有快照”。完整恢复需要四类材料：原始资料、解析后的结构化文本或对象、embedding 生成配置、向量库数据和索引配置。若只备份向量库，模型升级后无法解释旧向量；若只保存源文档，不保存解析结果，大规模恢复会很慢；若不记录索引参数，恢复后的召回可能和原来不同。
一个健康的向量数据管道应把向量库视为派生索引。权威源可以是文档系统、对象存储、PostgreSQL、数据湖或业务数据库。入库过程记录 source_id、source_version、parser_version、embedding_model、embedding_version、chunker_version、index_version 和写入时间。这样当模型升级、文档修订或索引损坏时，团队能确定哪些数据需要重算。
备份策略要区分在线恢复和离线重建。在线恢复依赖 Milvus、Qdrant、Weaviate 等系统自身快照或备份能力，目标是快速恢复服务；离线重建依赖源数据和流水线，目标是重新生成干净索引。两者都重要。只靠在线备份，可能把旧错误一起恢复；只靠离线重建，灾难恢复时间可能过长。
删除和权限变更要有强约束。用户删除文档、合同到期、员工离职、资料从公开改为私密，这些变化必须尽快反映到向量库。不能只在业务库删除原文，却让向量片段继续可召回。对高风险场景，删除应包括原始文件、解析文本、embedding、缓存、引用索引和导出产物。备份保留也要符合数据保留策略。
模型升级要走灰度。新的 embedding 模型可能让召回更好，也可能破坏原有排序。稳妥做法是建立新索引版本，离线跑评测集，再用少量流量 A/B，确认 Recall@K、引用正确率、回答采纳率和延迟都可接受，再切换主索引。不要在原索引上直接覆盖向量，除非已有可回滚备份。
权限、审计和安全边界
向量库权限不能只靠“用户看不到管理后台”。AI 应用里，用户可能通过自然语言让系统检索资料，模型上下文一旦包含无权限片段，就已经发生数据处理。真正的权限边界必须在检索前生效：先根据用户身份、租户、组织、角色、项目和资料状态计算可检索范围，再执行向量检索和重排。
向量库自身提供的 RBAC、API key 和访问控制很重要，但它们通常只能控制服务级和集合级权限。业务级权限更细，例如同一集合里某个用户只能看某些文档片段。这个部分需要应用层、metadata 过滤、数据库策略和引用访问控制共同完成。管理密钥、写入密钥、查询密钥也要分开，不能让普通服务拿到删除集合或恢复快照的权限。
审计记录要能还原一次检索行为。至少要记录用户、租户、应用、查询、过滤条件、检索集合、索引版本、embedding 模型、召回文档 ID、重排结果、引用片段、生成模型、成本、耗时和失败原因。敏感正文可以按策略脱敏或保存引用 ID，但没有结构化审计，后续无法解释“为什么回答引用了这份资料”。
提示注入和数据投毒也会影响向量库。外部网页、用户上传文档、邮件和评论中可能包含恶意指令，诱导模型忽略规则或泄漏资料。向量库只负责召回，不理解哪些文字是指令、哪些是资料。因此 RAG 系统要把检索内容标记为不可信资料，工具调用和权限判断不能听从文档里的自然语言指令。权威资料和用户资料还应分级。
安全边界还包括日志、缓存和导出文件。很多系统主检索流程权限正确，却在检索日志、后台查看页面、缓存答案和报告导出中泄漏片段。缓存键必须包含租户、权限范围、知识库版本和模型版本；导出文件要有有效期和下载权限；内部运维查看召回上下文也应有审计。向量库越靠近企业知识核心，这些旁路越不能忽视。
评测：别靠“感觉答案还行”
向量检索评测要从问题集开始。问题集应来自真实用户问题、客服工单、搜索日志、业务专家整理和边界样本。每个问题最好标注期望命中的文档、段落或证据，也可以标注不能引用的资料。没有标注数据，就无法客观比较不同 embedding 模型、索引参数、分块策略和重排方式。
第一类指标是检索指标。Recall@K 衡量正确证据是否出现在前 K 个结果中；Precision@K 衡量前 K 个结果有多少是相关的；MRR 衡量第一个正确结果排得多靠前；NDCG 可以处理不同相关性等级。对知识库问答，Recall@K 往往是底线：如果正确片段没有召回，后面的生成模型再强也只能猜。
第二类指标是回答指标。引用正确率衡量回答是否基于召回资料；事实一致性衡量回答是否歪曲资料；拒答准确率衡量资料中没有答案时是否能承认不知道；可操作性衡量回答是否给出用户需要的步骤。RAGAS、OpenAI Evals 等工具可以辅助构建自动评测，但关键样本仍应由业务专家审阅。
第三类指标是系统指标。包括检索延迟、重排延迟、P95/P99、吞吐、索引构建时间、写入延迟、内存、磁盘、备份时间、恢复时间、过滤后空结果率和成本。很多方案在线下小样本效果很好，上线后因为延迟或过滤后结果不足而不可用。评测要覆盖真实数据量和真实过滤条件。
评测还要覆盖权限样本。A 租户的问题不能召回 B 租户资料；普通用户不能召回管理员资料；草稿文档不能参与普通回答；删除文档不能继续出现在引用中；高敏资料不能被外部模型处理。权限评测不能只看最终回答，应检查召回上下文和引用列表。
每次改变 embedding 模型、分块策略、索引类型、索引参数、过滤字段、重排模型或提示词，都应该跑一次回归评测。向量数据库不是一次建好就结束的基础设施，它会随着资料、模型和业务持续变化。没有评测集，团队无法知道一次优化到底是进步还是倒退。
一个从零到生产的实操路径
第一步，用小样本建立数据模型。选择一类资料，例如产品 FAQ、客服工单或内部制度，设计文档表、片段表、metadata 字段和引用格式。先不要急着接入全部资料。目标是让每个片段都有来源、版本、标题路径、权限字段和可追溯 ID。
第二步，建立精确检索基线。可以用 FAISS Flat、pgvector 精确搜索或向量库的精确模式，先在几百到几千条样本上验证分块和 embedding 模型。准备 50 到 200 个真实问题，手工标注正确证据。若基线都召回不到，问题通常在资料、分块或 embedding，而不在索引。
第三步，引入 metadata 过滤。把租户、空间、状态、语言、资料类型、时间和权限范围加入查询条件。测试同一个问题在不同用户权限下返回不同结果。此时要确认过滤发生在检索前或检索中，而不是生成答案后。
第四步，扩大数据量并选择索引。数据达到几十万条后，开始比较 HNSW、IVF、IVF-PQ 或产品默认索引。用同一套评测问题比较 Recall@K、延迟、内存和构建时间。不要只调一个参数，要记录每次实验配置。对 pgvector，关注 HNSW、IVFFlat、partial index、分区和 iterative scan；对 Qdrant、Weaviate、Milvus，关注向量索引和标量索引配合。
第五步，上线重排和引用。第一阶段召回较多候选，第二阶段重排，生成时只使用通过权限和重排的片段。回答必须带引用，引用可点击回原文，并再次做权限校验。资料中没有明确答案时，系统要能拒答或要求补充信息。
第六步，建设备份、重建和灰度。保存源资料、解析结果、embedding 配置、索引配置和向量库备份。模型升级走新索引版本，先离线评测，再灰度切流。删除和权限变更要有同步机制。上线后持续看检索命中率、空结果率、引用错误、用户反馈和成本。
常见误区
第一个误区是把向量数据库当成知识库全部。知识库还包括资料治理、权限、引用、版本、评测、更新和审核。向量库只是检索索引的一部分。
第二个误区是只看 Top1 示例。演示中一个问题答对，不代表系统稳定。要用成批真实问题评测 Recall@K、引用正确率和拒答能力。
第三个误区是忽略过滤。生产检索几乎都带权限、租户、状态和业务条件。没有过滤设计的向量库，只适合演示，不适合真实组织。
第四个误区是盲目追求大模型和大向量。检索质量常常卡在分块、metadata、引用和重排上，不是向量维度越高越好。
第五个误区是索引不可重建。向量库应该能从源数据重建。若索引成了唯一真相，模型升级、误删和权限变更都会变得危险。
第六个误区是先选产品再定义需求。FAISS、Milvus、Qdrant、Weaviate、pgvector 和 Chroma 都有适合场景。先明确数据规模、过滤复杂度、权限边界、运维能力和评测目标，再做选型。
第七个误区是把备份等同于数据库快照。快照恢复的是某一刻状态，不能替代源资料、解析版本、embedding 配置和索引参数记录。
第八个误区是让模型自己判断权限。模型可以帮助生成回答，不能作为权限边界。权限必须由系统执行。
检查清单
资料进入向量库前，是否有来源、版本、责任人、状态和权限字段。
分块是否保留标题路径、页码、段落、表格结构、业务对象和引用位置。
embedding 模型是否针对中文、领域术语、跨语言或多模态场景做过评测。
是否有精确检索基线，用来比较近似索引的召回损失。
metadata 过滤是否在检索前或检索中生效，而不是生成后删除。
是否为常用过滤字段建立标量索引、payload index、倒排索引、普通 SQL 索引或分区。
是否有 Recall@K、MRR、NDCG、引用正确率、拒答准确率和延迟指标。
是否记录索引类型、索引参数、embedding 模型版本、分块版本和资料版本。
是否有备份、恢复、重建索引、模型升级和回滚路径。
是否区分管理密钥、写入密钥、查询密钥和只读业务凭证。
是否审计每次检索的用户、租户、过滤条件、召回片段、引用、模型和成本。
是否验证跨租户、跨项目、删除文档、草稿文档和高敏资料的权限样本。
结语：向量库选型要回到检索质量
向量数据库的价值不在产品名，而在它能否让用户稳定找到正确证据。FAISS 适合理解和自定义高性能检索；Milvus 适合大规模分布式平台；Qdrant 适合 payload 过滤清晰的工程应用；Weaviate 适合对象化、混合检索和语义应用；pgvector 适合把向量能力放进 PostgreSQL 体系；Chroma 适合轻量原型和快速验证。
真正的工程重点，是把检索链路做完整：源数据可治理，分块可追溯，embedding 可版本化，索引可评测，过滤可前置，权限可执行，引用可核验，备份可恢复，效果可持续监控。向量数据库不是 RAG 的全部，但它决定了 AI 应用能不能从“会说话”走向“有依据地回答”。
写作日期：2026-05-22
参考资料
- FAISS Wiki： https://github.com/facebookresearch/faiss/wiki
- FAISS Indexes Wiki： https://github.com/facebookresearch/faiss/wiki/Faiss-indexes
- FAISS Index Factory： https://github.com/facebookresearch/faiss/wiki/The-index-factory
- Johnson 等，Billion-scale similarity search with GPUs： https://arxiv.org/abs/1702.08734
- Milvus Index Explained： https://blog.milvus.io/docs/index-explained.md
- Milvus 标量索引文档： https://milvus.io/docs/index-scalar-fields.md
- Milvus RBAC 文档： https://milvus.io/docs/rbac.md
- Milvus Backup Overview： https://milvus.io/docs/milvus_backup_overview.md
- Qdrant Filtering： https://qdrant.tech/documentation/concepts/filtering/
- Qdrant Indexing： https://qdrant.tech/documentation/concepts/indexing/
- Qdrant Snapshots： https://qdrant.tech/documentation/operations/snapshots/
- Weaviate Vector Index： https://docs.weaviate.io/weaviate/config-refs/schema/vector-index
- Weaviate Filtering： https://docs.weaviate.io/weaviate/concepts/filtering
- Weaviate Backups： https://docs.weaviate.io/weaviate/configuration/backups
- Weaviate RBAC： https://weaviate.io/developers/weaviate/configuration/rbac
- pgvector README： https://github.com/pgvector/pgvector
- Chroma Where Filters： https://docs.trychroma.com/reference/where-filter
- Chroma Filters Cookbook： https://cookbook.chromadb.dev/core/filters/