如何为检索场景选择和使用 Embedding 模型？

核心回答

Embedding 模型选型要同时看任务匹配、业务检索效果和部署成本。 模型负责把问题与文档编码为可比较的向量；选择时可以按三步判断：

1. 筛选候选：确认是相似问句匹配，还是短问题检索长文档，再检查语言、领域术语、有效输入长度、资源和许可条件。
2. 业务评测：用同一套文档与问题，比较证据 Recall@K、排序质量、实际回答效果，以及延迟、吞吐和费用。榜单用于筛选，不能代替本业务评测。
3. 正确接入：文档离线编码建索引，问题在线编码检索；两侧遵循模型相互对齐的输入约定，并匹配维度、归一化和距离度量。

例如中文问题需要查英文故障手册时，要测试跨语言检索，而不只看模型是否标注“支持中文和英文”。更换模型也不只是替换查询端：同维度不代表同一向量空间，通常需要重算文档向量、建立新索引，验证后再切换。

先按检索任务筛选候选

任务与数据匹配。 相似问句检索比较接近对称匹配；“如何处理 Redis 连接超时”检索故障手册，则是短查询找长段落的非对称检索。句子相似度任务上的高分，不能直接证明文档检索能力。还要检查中文、英文和混合术语；如果中文提问要找英文文档，需要评测跨语言检索，而不只是确认模型声称支持两种语言。

输入与工程约束。 对照模型的有效输入长度检查切分后的文本，记录超长输入是报错还是截断。长输入能力不等于应该把整篇手册编码成一个向量。云 API 需要考虑费用、限流和数据传输要求；本地部署要看吞吐、显存、并发、运维与许可。维度越高，向量存储和距离计算的开销也会增加，但检索效果并不随维度单调提高。

例如 BGE-M3 的官方模型卡说明其支持多语言与长输入，并明确查询不需要添加旧版 BGE 的检索指令。这是该模型的使用约定，不能推广为其他 BGE、E5 或指令式模型都使用同样输入。

用业务评测选，而不是凭单次相似度选

准备真实或经审核的查询，标注相关文档及支持答案的证据，覆盖常见问法、缩写、领域术语、容易混淆的条件、跨语言和无答案问题。在各候选模型合法的输入范围内，固定语料切分、过滤规则和 Top-K，按各自官方约定编码，再比较：

• 召回覆盖：Recall@K，看所需相关证据找回了多少。
• 排序质量：MRR 看首个相关结果的位置；有分级相关性标注时，可用 nDCG。
• 实际回答与工程成本：检查答案正确性、证据支持和引用，同时测查询 P95 延迟、文档编码吞吐、资源与费用。

还应检查分场景结果，防止总体提升掩盖错误码、中文术语或某个业务领域的退步。更换模型时先尽量隔离模型变量，再比较包含混合检索、重排的完整链路。

使用中最容易踩的坑

把两个编码入口当成同一种处理。 文档侧通常批量编码并保存块标识、来源、模型版本等信息；查询侧按模型要求编码后查对应索引。有的模型要求不同前缀，有的采用不同查询和文档编码模块，也有的无需区分。关键是两侧处于经过训练对齐的空间，而非机械地加同一个前缀。

把同维度当成兼容。 两个模型都输出 1024 维，只能说明数组长度相同，不说明坐标含义一致。维度异常应排查模型或配置；随意补零、截断或用零向量填补失败，不能把不兼容模型变成兼容模型。模型明确支持的降维也要按其方法使用并重新评测。

盲目归一化或套分数阈值。 先看模型推荐的相似度算法，再配置索引和查询。两侧向量都归一化为单位长度时，内积与余弦相似度等价；有些模型会利用向量长度，不能一律归一化。相似度分数也不是正确概率，应结合本业务正负样本校准阈值，并确认接口返回的是距离还是相似度。

升级后混用新旧向量。 缓存和索引要关联模型修订、编码配置、维度与文本处理版本。更换模型时，可在新集合重算向量，处理迁移期间的文档增量，评测后切换查询并保留回退路径。不能把新查询向量直接查旧文档向量。

追问

换了更好的模型，为什么仍然找不到答案？

先确认原文有答案、解析与切分没有丢条件，再核对编码配置和截断、过滤及索引召回。错误码、型号等精确词可能需要关键词检索补充；正确证据已进上下文而回答仍错，则继续查上下文组织与生成环节。

对应教程

参考资料