语义检索与向量数据库选型：从 FAISS 到 Milvus 的落地对比

直接答案：RAG 系统的检索质量，七成取决于向量库的选型与索引策略。下面从索引类型、主流方案、关键参数、选型决策、工程要点五个维度做落地对比。

一、索引类型。向量检索本质是近似最近邻（ANN）搜索，常见索引有几类：

• 暴力检索（Flat）：逐一计算距离，准确率 100%，但耗时随数据量线性增长，仅适合万级以内数据或作为评测基线。
• IVF 系列（IVF-Flat / IVF-PQ）：先聚类再在最近簇内检索。关键参数 nlist 控制聚类数（常取 √N ~ 4√N），nprobe 控制查询时扫描的簇数（16–64 之间权衡召回与速度）；PQ（乘积量化）把向量切段压缩，显存占用可降一个数量级，召回率略有损失，适合亿级数据。
• HNSW：基于图的层级导航结构，查询延迟低（毫秒级），关键参数 M 控制每层节点连接数（常用 16–64，越大召回越高但内存越贵），efConstruction 控制建图质量（100–400），efSearch 控制查询时的候选集大小（50–200）。是在线低延迟服务的常用选择，但内存占用高。

二、主流向量库对比。

• FAISS：Meta 开源库，单机嵌入式，轻量灵活，需自行封装服务层，适合原型与中小规模（千万级以内）。
• Milvus：分布式向量数据库，支持百亿级向量、多索引类型与水平扩展，自带 API 与服务化，适合生产环境高并发。
• pgvector：PostgreSQL 插件，复用现有关系库，运维简单，支持 IVFFlat 与 HNSW，适合已用 PG 且数据量中等的团队。
• Elasticsearch（dense_vector）：搜索生态成熟，支持向量与 BM25 关键词混合检索，适合已有 ES 技术栈的团队。

三、选型决策（按三要素）。

• 数据量 < 100 万且追求轻量：FAISS；
• 需要弹性扩展、百亿级与高并发：Milvus；
• 已有 PG、不愿引入新组件、数据中等：pgvector；
• 要做混合检索且已有 ES 技术栈：dense_vector。 粗略阈值：百万级用 FAISS/pgvector，千万到亿级用 Milvus，亚亿级且重延迟用 HNSW 索引的任意库。

四、工程要点。 ① 维度一致性：embedding 模型与检索端必须用同一模型，否则向量不在同一语义空间，相似度毫无意义。维度通常 768（bge-base）或 1024（bge-large）。 ② 距离度量：余弦相似度最常用，需与训练时保持一致；内积（IP）在向量已归一化时等价于余弦。 ③ 混合检索：向量召回叠加 BM25 关键词，召回率通常优于单一向量检索；可给 BM25 0.3–0.5 的融合权重。 ④ 重排：召回 top-k（5–10）片段后，用 Cross-Encoder 重排器（如 bge-reranker-large）重新打分，取最相关 2–4 段送入生成模型，可显著提升答案准确度。 ⑤ 评估：用 Recall@k（前 k 个结果含正确答案的比例）衡量检索，用 Faithfulness/Answer Relevancy 衡量生成；可借助 RAGAS、TruLens 框架做自动化评测，定量看哪环掉链子。

五、最小落地流程。 切分文档（200–500 字/块，overlap 10–20%）→ 同模型向量化 → 选索引建库 → 混合检索召回 → 重排 → 拼接生成 → 用 Recall@k 与 RAGAS 评测迭代。

小结：没有万能选型，按数据规模、延迟要求、现有技术栈三要素综合判断；先把检索质量测起来，再谈优化。