🚨 多语言一接进来，为什么证据很快开始互相串线
很多团队把知识库从中文扩到英文、日文和东南亚站点后，最先暴露的问题往往不是模型不会回答，而是同一个问题在不同语言下会召回到不同证据。⚠️ 中文 query 还能答对，英文 query 一上线就开始引用旧文档；日文 FAQ 入库后，结果被英文产品页压在后面。📉 读者看到的是“答案忽好忽坏”，底层是跨语言召回链路失稳。
这类问题很容易被误判成 Embedding 不够强。🧠 但线上更常见的根因，是查询语言、文档主语言和实体词没有分开治理。产品名、版本号、错误码这类高辨识实体，常在翻译后失去稀疏命中；纯多语言向量又会把语义相近但地区政策不同的文档拉到一起。📌 一旦证据池把不同语种、不同区域的内容混在同一榜单里，生成阶段就只能在冲突上下文里补答案。
🔍 真正被拖垮的，不是召回器数量，而是语言边界和排序责任
真正拉低命中率的，通常有三层。🔍 第一层是语言识别过晚，系统等到 rerank 才发现 query 和文档语种不一致；第二层是索引粒度失衡，中文 chunk 按段切、英文 chunk 按页切，导致长度偏置把短文本顶到前排；第三层是排序信号混用，BM25 更偏爱原语言实体词，multilingual embedding 更偏爱语义近邻，两者一旦不校准，就会让“同主题但不同地区版本”的文档互相打架。🧩
一组企业帮助中心灰度里，单用 multilingual embedding 时，中文 query 的 evidence hit rate 有84%，英文 query 降到71%，夹杂产品缩写的混合 query 只剩63%。✅ 补上 translation pivot 和 language-aware rerank 后，混合 query 回到80%，P95 时延只增加11%。这说明跨语言 RAG 的关键不是把所有语种硬塞进一个向量空间，而是先把语种边界和排序责任拆清楚。
| 方案 | cross-lang evidence hit rate | wrong region quote rate | P95 检索时延 | 典型问题 |
|---|---|---|---|---|
| 仅 multilingual embedding | 71% | 14% | 1.00x | 语义近但区域常串线 |
| embedding + 机器翻译直搜 | 76% | 11% | 1.09x | 实体词容易被翻掉 |
| 语言路由 + translation pivot + rerank | 80% | 6% | 1.11x | 更稳，适合生产 |
🛠️ 更稳的做法，是先判语言路径，再决定谁负责补 recall
更稳的工程路径，是先做轻量语言路由，再决定检索计划。🛠️ 高置信 query 直接走主语言索引；低置信或混合语 query，同时触发原语 query 检索和 translation pivot 检索，再在融合层保留语言标签、地区标签和版本时间。🔒 这样做的价值，不是多跑一路召回，而是防止翻译后的 query 把实体词、错误码和 SKU 编号洗掉。
rerank 这一层也不能再只看文本相似度。🧪 更可落地的做法，是把query_lang、doc_lang、region和doc_freshness一起进特征门禁；当查询里带版本号、国家名或错误码时，应优先抬高原语言候选，再让翻译路径只补 recall。🚦 很多团队跨语言越做越慢，本质不是模型太大，而是每个 query 都走全量多语链路，没有把翻译、融合和重排做成条件化决策。
defbuild_retrieval_plan(query:str,lang_conf:float,detected_lang:str):plan={"primary_lang":detected_lang,"use_pivot":False,"boost_original":False}iflang_conf<0.85orany(token.isupper()fortokeninquery.split()):plan["use_pivot"]=Trueifany(keyinquery.lower()forkeyin["v2","error","sku","cn","jp"]):plan["boost_original"]=Truereturnplan📈 接下来 3 到 6 个月，跨语言 RAG 会进入语言治理阶段
接下来 3 到 6 个月，多语言 RAG 的分水岭不会是谁接入更多语种，而是谁能把语言路由、翻译质量和证据新鲜度做成统一治理面板。📊 团队至少要长期盯住cross_lang_hit_rate、translation_entity_loss、wrong_region_quote_rate和rerank_gain_after_pivot，否则线上坏答案只会被误判成“模型偶发幻觉”。
笔者认为，成熟的跨语言知识库不会把“多语言向量模型”当成终局，而会把它看成一层基础召回能力。💡 真正决定上限的，是系统能不能在不同语种之间保住实体、版本和区域边界。🙂 你们现在的多语言问答，更常见的问题是翻译丢实体、区域文档串线，还是 rerank 成本失控？欢迎交流。
