Embedding 模型与向量数据库选型实战

前言

上一篇讲了 RAG 的 pipeline，但有两个核心依赖没展开：Embedding 模型和向量数据库。选错一个，整个 RAG 的天花板就锁死了。

这两个组件在生产中一旦选定就很难换：

换 embedding 模型 → 必须全量重新 embed + 重建索引，几百万条文档可能要跑几天
换向量数据库 → 迁移 + 重新调优索引参数 + 业务代码改动

所以选型阶段要谨慎。这一篇按”先 embedding，后向量库”的顺序展开：

Embedding 模型：5 个维度评估 + 主流模型对比
向量数据库：5 个主流选项 + 决策框架
实战选型 checklist：基于 QPS、数据量、部署环境

一、Embedding 模型怎么选

Embedding 模型把文本变成向量。向量质量直接决定 RAG 的召回上限——选错 embedding，再好的检索策略都救不回来。

5 个评估维度

维度	怎么测	为什么重要
检索准确率	MTEB BEIR / MIRACL	核心指标：能不能召回到正确答案
中文能力	C-MTEB / MMarco	英文 benchmark 高不代表中文也好
向量维度	看模型文档	维度高 = 准但贵，维度低 = 省但可能掉精度
推理成本	$/1M tokens	生产 100 QPS × 100 tokens/query 成本爆炸
上下文长度	max sequence length	长文档（>512 tokens）必须切，损失语义

主流模型对比（2026 年中）

按场景分类：

闭源主力

OpenAI text-embedding-3-small：1536 维，$0.02/1M tokens。通用最强 baseline，英语 / 多语种均衡
OpenAI text-embedding-3-large：3072 维，$0.13/1M tokens。精度最高，但贵
Cohere embed-v3：1024 维，$0.1/1M tokens。自带压缩 API（按需输出 256/512/1024 维）
Voyage-3：1024 维，$0.06/1M tokens。法律 / 金融领域 SOTA
Google gemini-embedding-001：3072 维，Matryoshka 支持（动态维度）

开源主力

BAAI/bge-large-en-v1.5（HuggingFace）：1024 维，英语 MTEB 平均 64.23，开源里英语最强
BAAI/bge-m3：1024 维，多语言 + 长文本（8192 tokens）+ dense/sparse/ColBERT 三合一。中文 / 跨语言 / 长文档场景首选
Alibaba gte-large / gte-Qwen2：开源多语言强模型，文本检索效果接近闭源
intfloat/e5-large-v2：另一款开源英语 SOTA，社区采用率高

实操选型建议

图 1：Embedding 选型决策树

经验法则：

预算充足 + 通用：text-embedding-3-small，不会错
中文 / 多语种：bge-m3（开源可自托管），数据不出域
法律 / 金融 / 医学：voyage-3，领域 SOTA
大规模 + 成本敏感：自托管 bge-large-en-v1.5（GPU 推理）或 bge-m3

一条容易踩的坑：换模型要全量重建

如果你在生产有 500 万条文档，要从 text-embedding-3-small 换到 bge-m3：

500 万次 embed API 调用 ≈ 几小时-几天
重建向量索引 ≈ 几小时（取决于 DB）
这段时间服务可能要降级

建议：上线前用 ≥ 1000 条真实 query + ground truth 在候选 embedding 上做离线 A/B 评测，选定后再全量上线。

二、向量数据库怎么选

向量库管”如何快速找到相似向量”。生产里你需要关注 5 件事：

5 维度

规模：10 万 / 100 万 / 1000 万 / 1 亿+ —— 决定用 Postgres 扩展还是独立向量库
延迟：< 10ms（实时）/ < 100ms（近实时）/ 数百 ms（批处理）
部署模式：自托管 / 云托管 / 嵌入式
混合检索：是否原生支持 BM25 + 向量
运维：监控 / 备份 / 多租户 / 权限

5 个主流选项

选项 1：pgvector（Postgres 扩展）

pgvector 是 Postgres 的向量扩展。最大优势：数据和向量在同一个数据库。

-- 安装
CREATE EXTENSION vector;

-- 建表
CREATE TABLE docs (
  id BIGSERIAL PRIMARY KEY,
  content TEXT,
  metadata JSONB,
  embedding vector(1536)  -- OpenAI 1536 维
);

-- 索引（HNSW 适合高召回，IVFFlat 适合快速构建）
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);

-- 检索
SELECT id, content, metadata
FROM docs
WHERE metadata->>'category' = 'api'  -- metadata 过滤
ORDER BY embedding <=> $1             -- 余弦距离
LIMIT 4;

优势：

已经在用 Postgres 的团队零基础设施成本
原生 JOIN / ACID / 事务
40+ 语言客户端

劣势：

千万级以下性能好，亿级以上吃力（需要 Citus / PgDog 分片）
高级 ANN 算法需要自己组合（binary quantization + iterative scan）

选 pgvector 的场景：

数据已经在 Postgres 里
总向量 < 1000 万
想用 metadata JOIN 关联业务表

选项 2：Milvus（自托管，亿级）

Milvus 走云原生路线，专门为大规模向量搜索设计：

规模：已经验证支持数百亿向量，Salesforce / PayPal / NVIDIA 在用
索引：HNSW / IVF / FLAT / SCANN / DiskANN + 量化 + GPU 加速（CAGRA）
混合检索：dense + sparse + BM25 全文本检索 + reranking
部署：Lite（笔记本） / Standalone（单机 Docker） / Distributed（K8s 亿级） / Zilliz Cloud（托管）

优势：规模、性能、混合检索、企业级特性齐劣势：K8s 运维门槛高，小团队用 Standalone 容易遇到资源瓶颈

选 Milvus 的场景：

数据规模 ≥ 1 亿向量
需要混合检索（dense + sparse + BM25）
有 K8s 运维能力

选项 3：Pinecone（云托管）

Pinecone 是 Serverless 风格的云原生向量库：

优势：零运维、按需扩缩容、内置 embedding 模型（不用单独搭）
劣势：供应商锁定、数据出境、单 GB 成本相对高
特色：document schema 支持 dense + sparse + 全文本检索单索引混合

选 Pinecone 的场景：

不想运维向量库
数据可以出境 / 已用 AWS
调用模式 burst（平时低 QPS，偶尔尖峰）

选项 4：Qdrant（Rust 写的高性能）

性能接近 Milvus，单二进制部署
Rust 写的过滤引擎，metadata 过滤极快
适合复杂 metadata 过滤 + 千万级

选项 5：Weaviate（GraphQL-first）

自带模块化 embedding + reranker 集成
GraphQL 查询 API
适合已有 GraphQL 栈的团队

决策树

图 2：向量库选型决策树

三、组合示例：3 套生产方案

方案 A：中小团队，10 万 - 100 万文档

// embedding: OpenAI text-embedding-3-small
// vector DB: pgvector
// 单 Postgres 实例即可
import { embed } from 'ai';
import { openai } from '@ai-sdk/openai';
import { Pool } from 'pg';

const { embedding } = await embed({
  model: openai.embedding('text-embedding-3-small'),
  value: userQuery,
});

const { rows } = await pool.query(
  `SELECT content FROM docs
   WHERE category = $2
   ORDER BY embedding <=> $1
   LIMIT 4`,
  [embedding, 'api']  // pgvector 自动处理数组格式
);

月度成本（1000 万 token embed）：~$200 + Postgres 主机费

方案 B：中等规模，500 万 - 5000 万文档

// embedding: bge-m3 自托管（GPU）
// vector DB: Milvus Standalone + BM25 混合检索
// 1 台 8 卡 GPU 服务器 + 1 台向量库主机

月度成本：GPU 服务器 ~$3000 + 向量库主机 ~$500

方案 C：大规模，亿级文档

// embedding: 混合（自托管 bge-m3 + 调用 OpenAI 大模型）
// vector DB: Milvus Distributed + Cohere Rerank
// 多台 GPU + K8s 集群

月度成本：GPU 集群 ~$15000 + Cohere rerank（按调用）

踩坑提醒

不要混用不同 embedding 模型的向量。如果迁移模型，必须全量重新 embed，不能新旧混用（向量空间不同）。
不要只看 benchmark 排名选 embedding。用自己的领域数据 + 真实 query 做离线评测，否则英文 SOTA 在中文 / 法律 / 代码领域可能翻车。
不要忽视 metadata 过滤的索引。pgvector 的 metadata 过滤如果没有合适索引，亿级数据下会全表扫描。
不要把向量索引和数据混在同一台机器上。生产推荐向量库独立部署 + 副本，避免 OLTP 写入影响检索性能。
不要”一次选型永远不变”。每 6 个月 re-eval 一次 embedding / 向量库，新模型 / 新库可能比当前更好。

总结

6 个 takeaway：

Embedding 模型决定 RAG 上限：5 维度评估（准确率 / 多语种 / 维度 / 成本 / 上下文），首选在自己数据上做离线 A/B。
BGE-m3 是中文 / 多语种首选：开源可自托管，支持 dense + sparse + 长文本。
OpenAI text-embedding-3-small 是英文通用 baseline：通用场景不易错。
pgvector 适合 < 1000 万向量 + 已有 Postgres：成本最低、生态成熟。
Milvus / Pinecone / Qdrant 适合 > 1000 万向量：按 K8s 能力、托管偏好、metadata 复杂度选择。
选型后难换：上线前充分评测，避免被锁死。

下一篇：Function Calling 与 Tool Use：从协议到工程实现 — 进入 Agent 核心模式。

参考资料

BAAI/bge-large-en-v1.5 (HuggingFace) — 开源英语 embedding SOTA，MTEB 64.23
Milvus 架构概览 — 云原生向量数据库，支持 dense + sparse + BM25 混合检索
pgvector (GitHub) — Postgres 向量扩展，HNSW/IVFFlat + metadata 过滤