摘要

上一篇文章我们已经完成了企业知识库 RAG 系统中最关键的入库链路：文档上传、解析、清洗、切片、Embedding 生成与向量写入。

但把向量写进去只是第一步。真正决定 RAG 系统能不能好用的，是检索阶段：用户提出一个问题后，系统能不能从海量文档切片中快速、准确、可控地找出最相关的内容。

本文进入 RAG 的第二个关键环节：向量数据库选型与语义检索实现。

本文会重点解决以下问题：

1. 企业级 RAG 为什么需要向量数据库？
2. Chroma、Milvus、pgvector、Elasticsearch 分别适合什么场景？
3. 语义检索的完整链路如何设计？
4. 为什么检索不能只看向量相似度？
5. 如何实现 metadata 过滤、权限过滤、TopK 召回、阈值过滤和引用来源？
6. 如何封装统一的 VectorStore 接口，避免业务代码绑定某个向量库？
7. 企业级 RAG 检索如何从“能查到”升级到“查得准、查得快、查得安全”？

一、为什么 RAG 必须重视检索层？

很多初学者做 RAG 时，容易把重点放在大模型生成上：

用户问题 → 检索文档 → 拼接 Prompt → 大模型生成答案

看起来大模型是最终输出者，所以大家会优先关注模型能力。

但在企业知识库问答中，真正决定