别把向量数据库理解成“存向量的 MySQL”

很多同学第一次做 RAG，会以为向量数据库只是把 embedding 数组塞进一个字段里，然后再像 MySQL 一样查询。这个理解很容易踩坑：普通数据库擅长的是精确匹配，向量数据库擅长的是“语义相似度搜索”。

换句话说，MySQL 问的是“有没有等于这个值的数据”，向量数据库问的是“有没有意思最接近这句话的数据”。二者不是替代关系，而是能力边界不同。

一、向量数据库到底是什么？

向量数据库是专门用来存储、索引和检索高维向量的数据库。这里的向量通常由 Embedding 模型生成：文本、图片、音频、代码片段都会被转成一串浮点数，这串数字表达的是“语义位置”。

在 RAG 里，向量数据库负责检索环节：用户问题先被转成查询向量，再到向量库里找 Top-K 相似 Chunk，最后把这些 Chunk 塞进 Prompt，让大模型基于证据回答。

面试里可以先这样回答：

向量数据库是为高维向量相似度搜索设计的数据库，核心能力是 ANN（Approximate Nearest Neighbor，近似最近邻搜索）。它能在海量向量中快速找出语义最相近的 Top-K 结果，是 RAG 检索链路的底层支撑。

普通数据库适合精确匹配，例如 id、状态、时间范围。

向量数据库适合语义相似，例如“退款流程”和“如何退钱”虽然字面不同，但语义接近。

生产级向量库还需要支持 metadata 过滤、混合检索、增量更新、分区、备份、权限和可观测。

二、为什么不能直接暴力算相似度？

如果库里只有几百条数据，暴力遍历完全可以。问题是企业知识库通常会有几十万、几百万甚至上亿个 Chunk。每次查询都把 query vector 和全库向量算一遍余弦相似度，延迟和 CPU 成本都会爆。

这就是 ANN 索引存在的原因：它不保证数学意义上的绝对最优解，而是在召回率可接受的前提下，把检索范围快速缩小到“最可能相关”的候选集。

三、向量数据库里存的不只是 vector

真正可用的 RAG 系统，向量库里不能只存一个 embedding。它至少要保存五类信息：唯一 ID、向量、原始文本、metadata、索引结构。尤其是 metadata，决定了权限过滤、租户隔离、时间过滤、业务线过滤和可追溯能力。

id：用于回溯原文、更新、删除、去重。

vector：由 embedding 模型生成，用于相似度检索。

text：返回给 LLM 的真实证据内容。

metadata：来源、部门、产品线、权限、版本、时间、标签。

index：HNSW、IVF、PQ、DiskANN 等加速结构。

四、核心索引算法：HNSW、IVF、PQ 怎么理解？

1. HNSW：多层图导航

HNSW 可以理解成“高速公路 + 城市道路”。它先在高层稀疏图里找到大方向，再逐层下降到底层图里做精细搜索。优点是召回率高、延迟低；缺点是内存占用较大，构建和维护成本更高。

2. IVF：先分桶，再搜桶

IVF 会先用聚类把向量空间分成多个桶。查询时不再全库遍历，而是先找到最相关的几个桶，只在这些桶里计算相似度。IVF 的好处是内存更友好，适合大规模；代价是参数调不好会丢召回。

3. PQ：向量压缩

PQ（Product Quantization）解决的是成本问题：向量维度高、数量大时，存储和内存都很贵。PQ 会把一个大向量拆成多个子向量，再用码本近似表示，从而大幅降低内存，但它是有损压缩，通常需要配合 rerank 或 residual 修正。

索引选型一句话

追求高召回、低延迟、数据量中等：优先 HNSW。

数据量非常大、内存有限：考虑 IVF / IVFPQ / DiskANN。

向量特别多、成本敏感：考虑 PQ/SQ 等量化压缩。

过滤条件很强：不要只看向量索引，还要看 payload/metadata 索引和过滤执行策略。

五、生产级向量数据库必须具备哪些能力？

1. Metadata 过滤

RAG 不是全库乱搜。一个企业知识库里可能有客服文档、研发文档、财务制度、销售话术。用户只能看自己有权限的内容，且通常还要限制产品线、语言、时间和版本。

错误做法是先全库 ANN，再过滤；这样 Top-K 结果可能被过滤掉很多，最后给 LLM 的证据不足。更合理的是把 metadata 过滤融入检索过程，先缩小合法候选集，再做 ANN。

2. 混合检索

纯向量检索擅长语义泛化，但对专有名词、型号、错误码、英文缩写可能不如关键词检索稳定。所以生产 RAG 通常会做混合召回：向量召回找“语义接近”，BM25/全文检索找“字面命中”，再用 RRF 或 reranker 融合排序。

3. 实时更新与删除合规

RAG 知识库不是一次性导入后永不变化。文档会新增、修改、下线，权限也会变化。所以向量数据库要支持增量写入、按 ID 删除、metadata 更新、索引后台构建、版本回滚和审计。

特别注意：删除不能只做“业务层隐藏”。对合规敏感场景，还要确认底层索引文件、备份、缓存、快照是否也满足数据删除和保留策略。

六、常见向量数据库怎么选？

选型不要只看 GitHub Star，也不要只看单机 Benchmark。真正要看的是：你的数据量多大、是否需要混合检索、是否需要复杂过滤、是否自托管、是否已有 PostgreSQL、团队有没有运维能力。

更落地的建议

快速原型：Chroma 上手快，适合 Demo、课程、个人知识库。

中小规模生产：Qdrant 过滤能力和 API 体验好，适合团队快速上线。

大规模分布式：Milvus 索引类型丰富，适合亿级向量和复杂集群，但运维门槛更高。

云托管：Pinecone、Zilliz Cloud、Qdrant Cloud 这类服务可以减少运维，但要评估成本和合规。

已有 PostgreSQL：pgvector 可以降低组件复杂度，适合中小规模和需要 SQL JOIN 的业务。

算法库：FAISS 很强，但它更像底层检索引擎，不是带权限、备份、租户、API 的完整数据库。

七、代码示例：pgvector 怎么做最简单的向量检索？

如果项目已经在 PostgreSQL 上，pgvector 是非常适合入门和中小规模业务的选择。它可以把 embedding 存在业务表里，并和 metadata 一起过滤。

SQL 代码示例

八、代码示例：Milvus 基础检索流程

如果数据规模更大，或者需要专门的向量数据库能力，可以用 Milvus/Qdrant 这一类系统。下面示例展示的是“写入向量 + metadata + Top-K 搜索”的最小链路。

Python 代码示例

九、生产级架构：别把向量库当成唯一核心

在生产系统里，向量数据库只是检索层的一部分。它前面有数据清洗、切分、embedding、权限和版本管理；它后面有 Query Rewrite、混合召回、rerank、Prompt 组装、答案引用和评测反馈。

十、上线前必须压测的指标

向量数据库选型不能靠感觉。至少要用自己的业务数据和真实 Query 集压测四类指标：检索质量、性能、成本、运维。

检索质量：Recall@K、MRR、nDCG、人工标注通过率。

性能：P50/P95/P99 延迟、QPS、索引构建时间、批量写入吞吐。

成本：内存、磁盘、云服务费用、GPU/CPU 成本。

运维：备份恢复、增量更新、删除合规、多租户隔离、监控告警。

十一、常见坑

只用向量检索，不做关键词召回，导致型号、错误码、专有名词命中不稳定。

先 ANN 后过滤，Top-K 被权限过滤掉，最后上下文证据不足。

只看平均延迟，不看 P95/P99，线上一有并发就抖。

只测查询，不测批量导入、增量更新、删除和重建索引。

不存 doc_id、chunk_id、source_url、version，答案无法溯源。

embedding 模型升级后没有重建向量，导致新旧向量空间混在一起。

把 FAISS 当完整数据库使用，却没有权限、持久化、备份、并发写入和审计方案。

十二、面试回答模板

如果面试官问“什么是向量数据库？有没有做过向量数据库选型？”，可以按下面顺序回答。

总结

向量数据库的本质不是“存向量”，而是“高维语义相似搜索”。它的核心价值是用 ANN 索引把原本不可接受的全库相似度计算，变成可在线服务的 Top-K 检索。

真正落地时，选型不能只看某个工具火不火，而要看数据规模、过滤复杂度、混合检索、更新频率、运维能力、成本和合规。原型阶段可以轻量，生产阶段必须可观测、可追溯、可回滚、可评测。