嵌入模型（Embedding Model）是 RAG 系统的“神经末梢”，它负责将文本转换成能在向量空间中计算相似度的数学表示。检索环节能否准确地从海量文档中找到与用户问题最相关的片段，很大程度上取决于嵌入模型的质量和适配程度。本节从实用的角度出发，梳理嵌入模型选型时需要考虑的关键因素，并给出真实可操作的选型建议。
7.1.1 嵌入模型在 RAG 中的角色
在 RAG 架构中，嵌入模型承担两个核心任务：
- 索引阶段：将知识库中的每一段文档切片转为向量，存入向量数据库。
- 检索阶段：将用户的查询问题实时转为向量，与数据库中的文档向量进行相似度匹配，召回最相关的片段。
整个过程可以理解为把“语义相似”具象化为“向量空间中距离近”。因此，嵌入模型的理解能力直接影响检索质量——如果模型无法正确捕捉问题和文档的语义，后续生成再强也无济于事。
7.1.2 选型需要考虑的核心维度
在实际项目中，嵌入模型的选型很少只看单一指标，而是需要在以下六个维度之间做权衡：
1. 语义理解质量
这是选型的首要指标。一个优秀的嵌入模型应该能够准确捕捉文本的深层语义，而非仅停留在关键词匹配。具体而言：
- 是否支持句子级、段落级的语义编码，而不仅仅是词汇级别。
- 对领域术语、缩写、同义表达是否有较好的泛化能力。例如，在医疗场景中，“心梗”和“心肌梗死”应该被映射到相近的向量。
常见评测基准包括 MTEB（Massive Text Embedding Benchmark），它覆盖分类、聚类、配对、检索、摘要等多种任务，能较全面地反映模型的通用语义能力。但需要注意的是，MTEB 高分不一定等于在你的特定领域表现好，实际仍需用自有数据进行验证。
2. 向量维度与检索效率
向量维度决定了向量能承载的语义信息量，也直接影响存储和检索成本：
- 高维度（如 1024、1536）：通常表达能力更强，但占用存储空间更大，相似度计算更慢。
- 低维度（如 384、768）：检索速度更快，存储更省，但可能存在语义信息压缩损失。
对于多数企业级应用，768 维是当前一个较好的平衡点。如果文档量极大（千万级以上），可以优先考虑 384 维模型，或使用有损压缩技术（如 PCA 降维）降低存储压力。
3. 支持的最大文本长度
嵌入模型一次能处理的文本长度有限（通常是 token 数）。在 RAG 中，这个限制直接影响切片策略：
- 如果模型最大长度是 512 tokens，而你切出的文档片段平均 1000 tokens，就需要截断或降级处理，信息可能丢失。
- 部分模型支持高达 8192 tokens 的输入，可以处理较长段落，但成本也相应升高。
选型时建议模型最大长度 ≥ 你计划使用的 chunk 长度的 1.2~1.5 倍，留出一定余量。
4. 领域适配能力
通用嵌入模型在垂直领域（如法律、医药、金融、工业制造）的表现可能会打折扣，因为领域内存在大量专用术语和特有表达方式。判断领域适配性可以从以下方向入手：
- 查看模型训练数据中是否涵盖类似语料。
- 有无官方或者社区提供的领域微调版本。
- 在自己业务数据集上做小规模人工评测，计算 top‑k 检索准确率。
如果预算和资源允许，也可以考虑在通用模型基础上用自有领域数据做微调，但这一步往往需要高质量标注数据，成本较高且需要持续维护。
5. 推理成本与部署方式
嵌入模型的调用发生在每一次知识库更新和每一次用户查询时，因此推理效率直接影响系统整体的响应速度和运行成本：
- API 调用模型（如 OpenAI text-embedding-3、Cohere Embed 等）：无需自建算力，按 token 或次计费，集成立刻可用，适合低延迟敏感度或快速试错的场景。但长期大规模使用成本不低，且数据需外传。
- 本地部署模型（如 BGE、E5、GTE 系列）：需要 GPU 或 CPU 资源自行托管，前期投入较高，但数据不出域，且长期用量下边际成本低。对于对数据隐私有高要求的企业，这是几乎必然的选择。
6. 多语言支持
如果知识库和用户问题涉及中英混合、多语种场景，则需要嵌入模型具备良好的多语言能力。市面上有专门的多语言模型（如 multilingual-e5、BGE-M3），在跨语言检索任务上表现明显优于纯中/英文模型。选型时需特别留意模型在多语言语义对齐上的评测表现。
7.1.3 常见嵌入模型横向对比（截至 2025 年初）
以下整理了几个在 RAG 实践中被广泛使用且经过充分验证的模型，供选型时参考：
| 模型 | 维度 | 最大长度 | 中文支持 | 备注 |
|------|------|----------|----------|------|
| OpenAI text-embedding-3-small | 512/1536 | 8191 tokens | 良好 | API 调用，成本较低，通用性好 |
| OpenAI text-embedding-3-large | 256~3072 | 8191 tokens | 优秀 | API 调用，质量高，价格也较高 |
| BGE-large-zh-v1.5 | 1024 | 512 tokens | 优秀 | 中文专优，可本地部署，社区活跃 |
| BGE-M3 | 1024 | 8192 tokens | 优秀 | 多语言，支持长文本，本地部署 |
| GTE-Qwen2-7B-instruct | 3584 | 32K tokens | 优秀 | 需较高算力，适合复杂语义场景 |
| Moka-ai/m3e-base | 768 | 512 tokens | 优秀 | 轻量中文模型，适合资源受限场景 |
说明：模型迭代极快，具体选型时建议查阅最新评测，并以自有数据实测对比为准。
7.1.4 选型实操建议
实际工作中，嵌入模型选型可以按以下步骤推进，避免陷入无休止的评测漩涡：
- 先确定硬约束
- 数据是否允许出域？ → 不允许则必须本地部署。
- 平均文档长度大概多少？文档是否包含大量英文/其他语种？ → 据此过滤模型支持的最大长度和语言能力。
- 预估的文档总量和并发查询量？ → 评估所需的硬件配置或 API 调用预算。
- 用轻量评测快速筛选 2~3 个候选
从知识库中抽取出 50~100 个真实问题，手工标注每个问题的相关文档片段（不需要特别精确，能判断对错即可）。用不同嵌入模型做检索，计算 top‑3 召回率（即正确答案出现在前三个召回结果中的比例）。这个过程通常一天内就能完成，足以暴露模型的明显差距。
- 考察稳定性与边缘表现
注意模型对否定、时间顺序、数值比较等语义的捕捉能力。例如问题“2023 年之前的规定”是否能与 2022 年的文档匹配，而不是错误地将 2024 年的文档排在前面。
- 生产环境压力验证
无论选择哪个模型，在正式上线前务必进行端到端的压测，确认检索延迟和资源占用在可接受范围内。尤其对于本地部署方案，不同优化引擎（ONNX Runtime、TensorRT 等）带来的速度差异可能很大。
- 保留模型切换能力
在设计系统时，将嵌入模型的调用封装成一个独立模块，尽量解耦其他的检索和生成逻辑。这样在未来更换模型时，只需要重新索引入库，而无需修改整体流程。模型是会进化的，保持架构的灵活性就是为长期维护省下最大的一笔成本。
总结：嵌入模型的选型没有“银弹”，最合适的模型是在你的数据、你的算力预算、你的性能要求之间找到的那个平衡点。做好小规模真实评测，比单纯看排行榜更能做出正确的选择。