去年下半年开始，我们陆续接了 5 个以 RAG 为底座的 AI 项目，从设备厂的售后知识库到律所的合同检索，再到某地化工集团的安全规程问答。每个项目立项时客户最关心的都是大模型选谁，但真正决定上线后客户骂不骂街的，其实是 Embedding 模型选得对不对。
Embedding 是把一句话、一段文档变成一串数字向量的过程。检索质量的一半来自它——大模型再强，如果检索阶段把不相关的文档塞进 Prompt，幻觉就停不下来。这篇把开沿这一年踩过的坑、对比过的几家模型整理出来，专门讲中文场景下怎么选。
Embedding 在 RAG 链路里到底承担多少
一个标准 RAG 流程大致是：用户问题 → Embedding 向量化 → 向量数据库召回 Top-K → 重排序 → 喂给大模型生成答案。看似五个环节，但只要前两步走偏，后面再怎么调 Prompt、加 ReRank 都是补救。
我们做过一组消融实验：固定大模型和 Prompt，只换 Embedding 模型，整体回答正确率的波动可以达到 15-25 个百分点。这个量级足以让一个项目从「客户觉得能用」滑到「客户觉得这就是个噱头」。所以我们现在做 RAG 立项评估时，会把 Embedding 选型放在比模型选型更靠前的位置，相关的工程拆解可以看企业知识库 RAG 落地复盘。
5 家主流玩家的定位差异
中文项目里我们实际跑过的有这 5 家，定位差别相当明显：
| 模型 | 出品方 | 定位 | 中文表现 | 部署方式 |
|---|---|---|---|---|
| BGE 系列 | 智源研究院 | 开源中文向量首选 | 综合靠前 | 本地/云端均可 |
| M3E 系列 | 开源社区 moka-ai | 轻量开源 | 短文本不错 | 本地为主 |
| 通义 Embedding | 阿里云百炼 | 商用云服务 | 长文档稳定 | 云端 API |
| 智源 BGE-M3 | 智源研究院 | 多语言+长上下文 | 多语种兼顾 | 本地/云端均可 |
| OpenAI text-embedding-3 | OpenAI | 海外标杆 | 中文也能用但有出境合规风险 | 云端 API |
BGE 系列是过去两年中文社区的主力，small、base、large 三档参数让小项目和大项目都能找到合适的版本。M3E 出现得比较早，工程同学普遍熟悉，胜在体积小、推理快。通义 Embedding 是阿里云这边主推的商用版本，按 Token 计费，胜在不用自己维护推理服务。BGE-M3 是 2024 年放出的新一代，支持稠密+稀疏+多向量三种模式，一次推理出多种表示。OpenAI 则更多是技术对比时的标杆，国内生产环境基本不能直接用，原因可以参考AI 合规与 PIPL 落地的整理。
中文场景的 4 个评估维度
公开榜单（C-MTEB、MTEB 等）能给你一个起跑线参考，但绝对不能拿来直接做选型决策。我们的内部评估表里有 4 个硬指标：
- 检索准确率：用自己的 200-500 条 QA 对算 Top-1、Top-3、Top-5 召回率
- 上下文长度：模型最大支持多少 Token，长合同、长法规能不能整段塞进去
- 向量维度：维度越高存储越贵，但是不是支持 MRL 降维
- 部署成本：自建推理服务的 GPU 成本 vs 云端 API 的调用单价
为什么要自己测？因为榜单语料和你的业务语料分布天差地别。我们曾经做一个机械加工行业的知识库，公开榜单上排名靠前的某模型，在客户的工艺文档上 Top-3 召回率比 BGE-large 低了将近 10 个百分点——文档里全是「Φ32H7 内孔配合公差」「45 钢调质处理 HB220-250」这类行话，通用语料训练的模型自然没见过。
4 类典型场景的实测对比
下面这张表是我们整理的几个真实场景里跑过一遍的结果，数字都是区间，因为每个项目语料不同：
| 场景 | 文档特点 | 推荐模型 | Top-3 召回率参考区间 | 备注 |
|---|---|---|---|---|
| 集团内部知识库问答 | 文档长、术语多 | BGE-large 或 BGE-M3 | 80-88% | 微调后可上 90% |
| 客服 FAQ | 短问短答 | M3E-base 或 BGE-small | 85-92% | 体积小、上线快 |
| 电商/产品检索 | 短描述、SKU 类 | 通义 Embedding | 78-85% | 配合关键词倒排会更好 |
| 合同/法规搜索 | 段落长、结构化 | BGE-M3 长上下文模式 | 75-82% | 需要做段落切分策略 |
合同搜索这一类项目我们体感最深，因为合同段落动辄上千字，传统 512 Token 上限的模型根本装不下一个完整条款。BGE-M3 把上下文拉到 8K Token，能让一个完整条款落在一个向量里，避免上下文被切断后语义破碎。如果还要进一步追溯条款责任归属，往往得叠一层结构化字段匹配，思路可以参考钉钉与金蝶集成实战里关于多源数据对齐的部分。
微调能不能让小模型反超大模型
可以，而且性价比通常比换更大的模型高。
我们在某化工客户的安全规程问答项目里做过对比：BGE-base 直接用，Top-3 召回率 71%；BGE-large 直接用，Top-3 召回率 79%；BGE-base 用客户的 8000 条对比对微调后，Top-3 召回率冲到 85%，反而比未微调的 large 高一截。微调成本是单卡 4090 跑了一晚上，按市场租用价折算大概一两百块。
微调的关键是构造对比对（contrastive pair），形式是「问题 - 正确文档 - 一个混淆文档」三元组。客户内部 QA 历史、工单系统、客服聊天记录都是天然的语料源头。这一步如果团队没经验，建议先看几个开源微调脚本（FlagEmbedding 仓库给得很全）跑通一遍，再加自己的数据。
微调小模型的另一层价值是私有化部署友好——BGE-base 量级的模型在一张消费级显卡上就能稳定跑推理服务，QPS 也够大多数企业用。这种思路和我们在AI Agent 架构模式里讲的「让小模型干小事」是一脉相承的。
本地部署 vs 云端 API 的真实成本
很多客户一上来就纠结自建还是用云 API，其实算清楚单位成本就清楚了。
| 部署方式 | 初期投入区间 | 单位向量成本 | 适合场景 |
|---|---|---|---|
| 本地 BGE-base，CPU 推理 | 几千块服务器 | 接近零 | 文档量小、并发低 |
| 本地 BGE-large，单卡 GPU | 2-3 万一次性 | 接近零 | 中等规模知识库 |
| 通义/百炼云端 API | 零 | 千 Token 几厘 | 文档量波动大 |
| OpenAI API | 零 | 千 Token 几厘但有出境风险 | 仅做技术预研 |
我们一般的建议是：百万级 Token 以下的实验阶段先用云端 API，省去部署调试时间；进入生产、年化向量量级超过千万 Token 后，迁回本地 GPU 部署通常一年内能把硬件成本回本。这一类成本测算的方法在AI Agent 开发成本拆解里有更细的拆法可以参考。
要注意的是，Embedding 不是一次性成本——文档每次更新、用户每次提问都要再做一次向量化。一个稍微活跃的企业知识库，一年下来的 Token 量轻松上亿，这时候本地化部署的边际成本优势就非常明显了。
和向量数据库怎么搭配
Embedding 模型决定向量的「质量」，向量数据库决定向量的「检索效率」。两者要匹配着选：
- 维度对齐：模型输出 1024 维，数据库就开 1024 维索引，别为了省钱强行降维而不用 MRL 模型
- 稀疏向量支持：BGE-M3 这类支持稠密+稀疏混合的，配合 Milvus、Qdrant 的混合检索能力效果最好
- 元数据过滤：实际业务里 70% 的查询都需要带条件过滤（部门、时间、文档类型），向量库的过滤能力比绝对 QPS 更重要
- 多租户隔离：如果做的是 SaaS 产品，向量库要原生支持 namespace 隔离，避免不同租户数据串味
我们做开沿自己的 AI Agent 工具链时，Embedding 用 BGE-M3 自建推理，向量库用 Milvus，整体延迟控制在百毫秒级。这套架构的好处是，未来想换成更新的 Embedding 模型，只要维度对齐、重新跑一遍向量化就能平滑迁移，不会被某一家云厂商锁死。这种「可替换」的工程思路，和我们在多模型路由策略里强调的解耦原则是一致的。
AI Coding 时代的 RAG 工程师正在变样
讲 Embedding 选型其实不只是讲一个模型怎么挑，背后是 AI Coding 和 AI Agent 把 RAG 工程从「调包跑通」推进到「全链路调优」的趋势。过去一个工程师能跑通 LangChain 的 demo 就算入门；现在的标准是能自己跑评测、能微调向量模型、能做混合检索、能算清楚每一个 Token 的成本。
我们团队内部的做法是，让每个写 RAG 业务的同学都用 AI Coding 工具自己搓一个 mini 评测框架——把客户的几百条 QA 对喂进去，能一键跑出不同模型在不同切分策略下的召回率曲线。这个评测脚本本身只有两三百行代码，但有它和没它，选型时的底气完全不同。这种工具链对个人能力的放大，我们在AI Coding 重塑软件交付和AI Coding 工具横评里都聊过。
一张决策表收尾
把上面所有维度浓缩成一张快速决策表：
| 你的项目特征 | 推荐起点 | 备注 |
|---|---|---|
| POC 阶段、想最快跑通 | 通义 Embedding API | 几小时就能上线 |
| 中等规模企业知识库 | BGE-large 本地部署 | 综合性价比高 |
| 长合同、长法规检索 | BGE-M3 长上下文 | 切分策略要配合 |
| 短问答、客服 FAQ | M3E-base 或 BGE-small | 微调后效果最好 |
| 行业术语密集 | 任选一款做微调 | 比换更大模型划算 |
| 需要多语言支持 | BGE-M3 | 100+ 语言原生支持 |
| 涉及客户/合同/人事数据 | 一律走本地化 | 不要用海外 API |
选 Embedding 模型本质上是在做一道「需求 × 成本 × 合规」的多目标优化题。我们做过的项目里，最后选错模型导致返工的情况很少，更多的坑反而是「没做评测就上线」「数据合规没提前想」这类流程问题。如果你正在评估自己业务里该上哪一款，不妨先花两周时间把语料、QA 对、评测脚本准备好——这个动作本身的价值，往往比模型选型本身更大。
