跨语言检索的三条路
"我们的 embedding 模型支持多语言"这句话，在多语言知识库上线第一天就会被打脸。
模型支持多语言，指的是它能把不同语言的文本映射到同一个向量空间。它不保证中文 query 和英文 query 的检索质量一样好，也不保证跨语言检索的排序是对的。这两件事是工程问题，不是模型能力问题。
1. 三条路径
1.1 多语言向量：一个索引，直接跨语种比
用多语言 embedding 模型（BGE-M3、Multilingual E5、Cohere Embed v3 等）把所有语言的内容放进同一个索引，查询时不区分语言。
优点：零额外调用，架构最简单，天然支持跨语言检索。
缺点：跨语言对齐是近似的。训练时各语种的数据比例通常不均衡（英文占比高），所以非英文查询的质量会差一些；"中文查询检索英文文档"这种跨语言场景衰减更明显。
1.2 翻译中枢：翻成同一语言再检索
入库时把所有文档翻成主语言，查询时把 query 翻成主语言，然后按单语检索。
优点：把多语言问题转成了单语问题——切分、embedding、重排全链路都在各自最擅长的单语模式下工作，单语检索质量是最高的。
缺点也很硬：
- 翻译有延迟：API 翻译每篇 2–10 秒，自托管（NLLB-200、Opus-MT）约 0.5–2 秒
- 翻译错误会静默传播：一个专业术语被翻错，正确表述的查询就永远找不到它，而你可能直到用户投诉才发现
- 必须保留原文：翻译版用于检索，原文用于引用——用户要看到原始语言的出处
- 领域术语的翻译质量仍不完美，金融和法律类中英文本里有相当比例的术语会被翻错
1.3 双索引：各语言独立索引，合并后重排
每种语言一套独立索引，查询时检测语言、并行检索、合并后用跨语言 reranker 重排。
优点：绕开了跨语言 embedding 的质量问题——每个索引用的是该语言上最优的 embedding，单语质量最高；同时可以通过召回后的合并保留跨语言能力。融合权重可以按查询类型、用户角色、文档领域调整。
缺点：复杂度显著上升——两套入库管线、两套索引管理、还要自己写合并与重排层。语料规模大（十万级切片以上）时这套才划算。
1.4 怎么选
| 场景 | 建议 |
|---|---|
| 语料小、语种少、要快速上线 | 多语言向量 |
| 语料 80%+ 是单一语言，偶尔有其他语言 | 翻译中枢（且已用留出集验证过领域术语翻译质量） |
| 语料大、多语种分布均衡、要求可控 | 双索引 + 跨语言重排 |
还有一个混合做法：语言路由。高置信度的单语查询直接走主语言索引；低置信度或混合语查询同时触发原文检索和翻译路径检索，在融合层合并。这样简单查询不付翻译的成本，复杂查询才走双路。
2. 三种典型失败
2.1 语义相近，但区域串线
最隐蔽的一种。中文文档和英文文档讲的是同一件事，但适用地区不同——欧盟的退货政策和美国的退货政策不一样，向量上却非常接近。
结果就是：用户问退货政策，召回了正确语义但错误地区的内容，模型读着欧盟的政策回答了一个美国用户。
这类问题的根子在于地区是一个硬约束，不是相关性维度。处理方式跟权限过滤是同一套思路（见《权限过滤要在检索前》）：把 region 作为元数据，检索时强制过滤，而不是指望排序把它排掉。
2.2 实体词被翻译洗掉
错误码、SKU 编号、产品型号、API 名称——这些在翻译里经常被"翻"成别的东西，或者干脆消失。
例子：query 是 "error E4021 怎么解决"，翻译后变成 "how to resolve error"，编号没了，检索质量直接崩。
这就是为什么纯翻译路径不保险：翻译只能补召回，不能承担精确匹配。混合检索（见《混合检索与 RRF 融合》）里 BM25 那一路的价值在这里特别大——它能精确命中编号，不受翻译影响。
2.3 中英混合 query 被分词切断
"这个 SKU 的 return policy 是什么"——中英夹杂在真实用户输入里非常常见，尤其是技术类、跨境类场景。
分词器如果按中文切，英文术语会被切断；按英文切，中文部分失效。切分阶段就要识别语言边界，把中文段落和英文段落分开处理，同时在元数据里保留语言关联信息（见《切片决定检索上限》）。
3. 语言路由
不建议每个 query 都跑完整的多语言链路——那样 P95 延迟会明显上升，而大部分查询并不需要。
路由逻辑：
- 语言检测 → 置信度高且是主语言：走主语言索引，单路
- 置信度高且是次语言：走次语言索引，单路
- 置信度低或检测到混合语：同时触发原文检索 + 翻译路径检索，双路合并
第三类的判断阈值要实测。做对了之后，多跑这一路的成本只落在真正需要的查询上。
4. 重排是收益最大的一层
如果多语言 RAG 只做一件事，做重排。
原因在《重排修不了召回》里说过：bi-encoder 分别编码 query 和文档，跨语言对齐是近似的；cross-encoder 同时看到 query 和文档，在注意力层面能消掉 bi-encoder 消不掉的歧义。英文 query 找日文文档正是这种情形——对齐的近似性在这里最伤，而重排能补回来。
4.1 特征不止文本相似度
跨语言场景里，重排的输入不该只有文本。值得一起进特征的：
query_lang/doc_lang——是否跨语言region——地区是否匹配doc_freshness——版本时间- 查询里是否含版本号、国家名、错误码
最后一条很有用：当查询里带版本号、国家名、错误码这类强约束词时，优先抬高原语言候选，让翻译路径只负责补召回，不负责定序。
这样做的好处是防止翻译把精确信息洗掉之后，排序又被翻译结果主导。
4.2 重排模型选型
跨语言场景常用的几个：
- BGE-reranker-v2-m3：开源可自托管，中日文表现好
- Cohere rerank-2.5（托管，2025-08 起取代 rerank-2，32K 上下文、100+ 语言）：注意 rerank-multilingual-v3.0 已属 legacy，新项目直接用当前代
- voyage-rerank-2：托管，跨语言表现好
延迟量级约 50–200ms（取决于候选数），几乎总是值得的。选型和候选数设置见《重排修不了召回》。
5. 引用必须回到原文
这一点在实现上经常被忘：用户看到的引用必须是原始语言的那份文档。
翻译路径下很自然会出现这种情况——检索用的是英文翻译版，于是引用也指向翻译版，用户点进去发现语言不对，或者根本找不到这个"翻译版"的存在。
正确做法是切片同时保存原文与翻译版：翻译版参与 embedding 与检索，原文用于展示和引用。元数据结构大概是：
chunk_id: doc_42_chunk_7
lang: zh
region: EU
content_original: 原文…
content_for_embedding: 翻译后的文本…（仅用于检索）
切片 ID 的设计和版本切换的做法见《知识库的重灌与切换》——多语言场景下重灌更频繁（翻译模型会升级），稳定 ID 更重要。
6. 评测集必须按语种分布建
最容易犯的评测错误：评测集里 90% 是中文，线上流量是 60% 英文、30% 日文、10% 中文。
评测集的语种分布要和真实流量一致，否则你在优化一个不存在的分布。同理，跨语言 query（中文问英文文档）要有专门的一类，不能混在单语里被平均掉。
指标按语种和跨语言分开统计（见《RAG 评测指标怎么选》）。聚合在一起的分数会掩盖某一个语种的崩塌——就像按 tag 分开看才能发现单类别回退一样。
标注成本不低：50–100 条真实 query，每条手标 3–5 个理想文档，两个小时的活。但这步省掉，后面就是一星期的"为什么检索这么差"。
7. 模型选型的几个实际约束
除了质量，还有三件事会决定你能不能落地：
能否自托管。 有数据驻留要求的场景（金融、医疗、跨境合规）不能把文档发给第三方 API。BGE-M3（MIT）、Multilingual E5（MIT）可以自托管；Cohere、OpenAI 只能走 API。
维度与存储。 1024 维的向量，一千万切片大约 40GB；3072 维接近 120GB。Matryoshka（MRL）训练的模型支持存全量、查询时截断——比如 voyage-3-large、text-embedding-3 都提供多档维度，存 1024 维、第一阶段用 384 维召回、再用全量重排，是性价比不错的默认模式。注意不是所有模型都支持：voyage-3 基础版就是固定 1024 维，用之前先确认目标模型给了哪些档位。
许可证。 这一条在《切片决定检索上限》里强调过，embedding 侧同样要看：有的模型权重允许研究但限制商用，有的是非 OSI 许可。商用前逐条确认。
最后一句提醒：公开榜单（MTEB、MIRACL、JMTEB）是必要条件不是充分条件。你的语料有自己的领域词汇，你的用户有自己的问法。榜单上领先不到 3 个点的差异，在你的数据上可能翻转。用自己的数据测一遍再定，这是唯一可靠的做法。