企业级 AI 应用工程实战（八）：向量数据库选型与语义检索实现

摘要上一篇文章我们已经完成了企业知识库 RAG 系统中最关键的入库链路：文档上传、解析、清洗、切片、Embedding 生成与向量写入。但把向量写进去只是第一步。真正决定 RAG 系统能不能好用的，是检索阶段：用户提出一个问题后，系统能不能从海量文档切片中快速、准确、可控地找出最相关的内容。本文进入 RAG 的第二个关键环节：向量数据库选型与语义检索实现。本文会重点解决以下问题：企业级 RAG 为什么需要向量数据库？Chroma、Milvus、pgvector、Elasticsearch 分别适合什么场景？语义检索的完整链路如何设计？为什么检索不能只看向量相似度？如何实现 metadata 过滤、权限过滤、TopK 召回、阈值过滤和引用来源？如何封装统一的 VectorStore 接口，避免业务代码绑定某个向量库？企业级 RAG 检索如何从“能查到”升级到“查得准、查得快、查得安全”？一、为什么 RAG 必须重视检索层？很多初学者做 RAG 时，容易把重点放在大模型生成上：用户问题 → 检索文档 → 拼接 Prompt → 大模型生成答案看起来大模型是最终输出者，所以大家会优先关注模型能力。但在企业知识库问答中，真正决定