详细解释
向量数据库（Vector Database，VDB） 可以理解为”语义版的搜索引擎”。传统数据库（MySQL、Postgres、MongoDB）存的是结构化字段 + 精确匹配（B 树索引）/ 全文倒排索引（Elasticsearch）——你搜”感冒吃什么药”，它只会找出现了”感冒/吃/药”这几个字的文档；而向量数据库的思路是：
- 先把你的每一段知识库文本（Chunk）过一遍 Embedding 模型，转成一个 1024 / 1536 / 3072 维的浮点数向量（这段文本的”语义指纹”）；
- 存进向量库；
- 用户提问时，同样把问题 Embedding 成一条向量；
- 比较查询向量与所有库向量的相似度（一般用 余弦相似度 Cosine Similarity），返回 Top-K 个最像的片段；
- 把这 Top-K 片段塞给 LLM 的 System Prompt，让它”基于以下内容回答”——这就是 RAG（检索增强生成） 的完整链路。
向量数据库的核心差异化能力 = ANN 近似最近邻索引（Approximate Nearest Neighbor）。“近似”两字是关键：如果真的和库里每一条都算一遍（暴力 KNN），库里 100 万条，每条 1536 维，一次查询就要算 15 亿次浮点——太慢。ANN 通过 HNSW、IVF-Flat、DiskANN、ScaNN 等索引结构，牺牲 ＜1% 的召回率换 100×–1000× 的查询加速，做到 P95 ＜ 100ms 仍能保持 99%+ 召回。
主流向量数据库选型（2025 年）
| 产品 | 类型 | 亮点 | 典型适用场景 |
|---|---|---|---|
| pgvector（Postgres 扩展） | 关系库扩展 | 你已经在用 PG，一张表既有结构化字段又有 vector 列，不需要新基建。支持 HNSW / ivfflat 索引。 | 中小规模（1000 万条以下）、不想引入新组件 |
| Milvus（LF AI 基金会） | 独立分布式 | 纯向量库老牌，支持 10 亿+，GPU 索引加速、混合检索、高可用集群全有。 | 大中规模企业、自托管可控需求强 |
| Qdrant | 独立 Rust 实现 | 部署超简单（单 binary），API 友好，Rust 性能好、内存占用低。 | 中大规模、偏好 Rust 生态 |
| Chroma / FAISS（SQLite / 纯库） | 单机 / 本地文件 | 起步最轻量，pip install 直接跑，无需服务端。 | 原型 / demo、Poc 阶段；生产一般换 |
| Pinecone / Weaviate | SaaS 托管 | 零运维、按量付费、混合检索+Reranker 内置。 | 快速上线、不想管基础设施工程 |
| 唯元智创 知识库（内置 RAG 管线） | 一体化 | 连 Embedding 模型 + 切片 + Rerank + 向量存储 + LLM 摘要一起给，直接接 REST 用，不用自己搭。 | 业务直接上生产，零代码接入 |
RAG 场景中向量数据库的关键参数（调优清单）
| 参数 | 常见值 | 怎么调 |
|---|---|---|
| Embedding 维度 d | 768（小） / 1024（中） / 1536（text-embedding-3-large） / 3072 | 维度越高语义越好，但存储和 ANN 速度线性下降；中文业务推荐 1024–1536 |
| 切片大小 Chunk Size | 256 / 512 / 1024 / 2048 Tokens | 小 chunk 召回精度高但上下文碎；大 chunk 反过来。一般 Tokenizer 中文 512 chars ≈ 一个段落 |
| Top-K 值（检索条数） | 3 / 5 / 10 / 20 | K=3 适合喂给 8K 上下文；K=20 适合超长上下文 + 后续 Rerank 精排重选 |
| 相似度阈值 Filter | 0.75 / 0.8 / 0.85 | 低于阈值的结果不要塞给 LLM（容易导致 幻觉）。宁可少召回不要瞎召回 |
| Rerank 模型（精排） | bge-reranker / Cohere Rerank 3 | 向量召回 Top-K=20，过一次 Rerank 重排选 Top-3 再给 LLM——RAG 准确率暴涨 15–30%，但多一次调用成本 |
常见问题
我能用 Elasticsearch / OpenSearch 代替向量数据库吗？
可以，现代 ES/OS 都内置了 dense_vector + HNSW/IVF 索引（k-NN 插件）。适用于你已经有 ES 集群、数据量在几百万条以下的场景。优势是能做”关键词 BM25 + 向量”的**混合检索（Hybrid Search）**一行 SQL/DSL 就搞定；但纯向量性能在超大规模上不如专门的 VDB（Milvus/Qdrant）。
「近似」最近邻会漏掉正确答案吗？
存在理论可能，但实践中 HNSW efSearch 参数默认值下 Recall@10 一般 ＞ 99%。担心漏的话两个工程手段：① 检索的 K 设得大一点（比如 Top-20）然后 Rerank；② 混合检索（BM25 关键词 + 向量）做融合。经验上，RAG 最终效果的瓶颈从来不是 ANN 召回差，而是切片策略、Embedding 模型和 Prompt 写得不对——先优化这三件事比纠结 Recall 小数点后两位有意义。
我必须先搭向量数据库才能做 RAG 吗？
不用。你可以用”托管一站式 RAG”。比如 唯元智创 的”企业知识库”模块：你只需要上传 PDF/Doc/网页，切片、Embedding、建索引、Rerank、最后喂模型——整条链路由服务端自动完成，你用一个 query 接口就能拿到回答。只有你的知识库是高度定制化更新、和你的业务数据库强耦合、或者数据有严格不出域要求时，才需要自建 VDB。