在构建 RAG 系统的检索环节时，嵌入模型（embedding model）的选择会直接决定检索质量的上限。以下几个方面的考量，来自真实工程实践中的经验，可以直接作为选型和调优的参考。
维度选择
嵌入模型生成的向量维度，通常在 384、768、1024，甚至更高（如 4096）。维度越高，向量能够编码的语义信息通常越丰富，但也会带来存储空间和检索延迟的显著增加。
- 低维度（≤384）
存储和计算成本低，适合对延迟要求极高、数据量不大或语义相对简单的场景。例如，某个只包含产品型号和对应参数的内部查询系统，768 维和 384 维的召回差别可能不明显，而 384 维能节省近一倍的向量数据库内存。
- 中高维度（768~1024）
是目前平衡效果和成本的主流选择。大量开源和商用模型（如 BGE、E5、text-embedding-ada-002 对应的 1536 维等）都在这个区间，能较好捕捉长文本和复杂语义。
- 高维度（≥2048）
通常带来更精细的语义表示，在一些精细语义区分、多语言混合场景中可能占优，但实际增益需要评估。很多时候从 768 升到 4096 维，召回率提升不到 1%，但存储和计算量却成倍增加。
实用建议：
可以先从 768 维或 1024 维的通用中英文模型起步，在自有测试集上对比不同维度的 top‑k 召回准确率，再决定是否有必要升维。对于绝大多数企业知识库问答场景，768~1024 维已经足够。
中英文适配
很多业务场景并非单一语言，可能同时涉及中文文档、英文手册、中英混杂的工单等。中英文适配的核心是选择或组合能够同时处理好两种语言的嵌入模型。
- 单一多语言模型
常见的如 paraphrase-multilingual-MiniLM-L12-v2（384 维）、BGE-M3（1024 维）、multilingual-e5-large 等，它们被训练时已经混合了中、英等多种语言数据。优点是统一一个模型，维护成本低；缺点是在极端侧重某一语言时，可能不如专用模型效果极致。
- 中英文分路 + 合并索引
如果知识库中中英文内容体量相当且语义侧重不同，可以使用中文专用模型（如 bge-large-zh-v1.5）和英文专用模型（如 bge-large-en-v1.5）分别对中英文文档建库。检索时先按语言方向路由，或同时在两个库中检索后合并结果。这种方法效果好，但架构稍复杂，需要额外的语言检测步骤。
- 中英混杂文档的处理
真实文档里经常一段中文夹杂英文术语（如“请参考 API reference 中的 authentication 章节”）。此时，单一多语言模型通常比分路方案更自然，也避免了一条记录同时出现在两个库中的去重难题。
实用建议：
如果 80% 以上是中文内容，优先选择一款评估过的中文或多语言模型即可。若中英文都很重要且有明显语言边界，可以用语言检测自动分库，各自使用专用嵌入模型，再用 Reranker 统一排序，能获得接近最优的效果。
性能指标
评估嵌入模型以及检索效果，不能只看厂商给出的 benchmark，要在自己的业务数据上验证。以下是几个最实用的指标和获取方式。
- 召回率（Recall@k）
指在返回的 top‑k 个结果中，至少包含一个真正相关文档的查询比例。这是 RAG 场景中最核心的指标，因为只要相关片段被找回来，生成链路就有机会给出正确答案。通常考察 Recall@5 或 Recall@10。
怎么测：准备一批问题和对应的“正确文档片段”，跑检索后统计命中率。
- 平均倒数排名（MRR）
衡量第一个相关文档出现在返回列表中的位置。位置越靠前，分数越高。该指标侧重“能否让模型第一眼就看到正确信息”，对于直接将 top‑3 片段喂给 LLM 的场景尤其重要。
- 命中率（Hit Rate）
与 Recall@k 类似，只是有时会严格要求至少有一条相关文档命中。常和 MRR 一起使用。
- 检索延迟与吞吐
实际系统中，向量检索的延迟通常要求在 100ms 以内，高端在 10~50ms。维度、索引类型（如 HNSW、IVF）和向量库硬件都会影响这一指标。在选型时，务必用相近规模的数据实测冷热启动下的延迟表现。
如何快速构建评估集：
抽取 50~100 条真实用户问题（或由业务方提供），人工标注每个问题对应的正确文档片段（可以从知识库中直接定位）。这是一个费时但回报极高的步骤。有了这个小规模标准集，就可以可靠地比较不同模型、不同切片大小、不同 top‑k 设置的效果，量化优化收益，而不是凭感觉调参。
通过合理地选择维度、匹配中英文需求，并用明确的指标持续评估，可以确保 RAG 系统的检索部分稳定、高效，并为后续生成提供真正可靠的知识依据。