跨境电商最头疼的事之一：一份中文产品手册，要同时支撑英语、西语、阿拉伯语用户的客服问答。很多人第一反应是"那就把知识库翻译成五种语言各存一份"。我先说结论——那是下策，会把自己埋进维护地狱。下面讲讲我的思路和踩的坑。

多语言 RAG 的核心矛盾

矛盾在哪：用户用西语提问，知识库是中文的，模型怎么从中文知识库里检索出相关内容，再用西语回答？

拆成两个子问题：

1. 检索：跨语言的语义匹配。西语 query 要能命中中文文档。

2. 生成：拿着中文片段，用西语作答。

第二步对现在的模型不是事，主流模型多语生成早就够用了。难的是第一步。

三种方案对比

第一种最直觉也最坑：知识库一更新，五份翻译全要重做，还得保证一致，人力根本扛不住。我朋友公司就栽在这，三种语言的库慢慢就不同步了，越南语版还停留在三个月前的政策。

我选的路子：单库 + 跨语言检索

只维护一份中文知识库，用一个支持跨语言语义的 embedding 模型做向量化。西语、阿语 query 进来，直接在这份中文向量空间里检索，能召回语义相关的中文片段。然后把片段连同"请用用户的语言作答"的指令一起交给模型生成。

好处很直白：知识库只有一份，更新一次全语种生效，再也不用同步五份。

翻过的坑

坑一：阿拉伯语、泰语这类低资源语言检索质量明显掉档。 英语、西语命中率很高，但阿语 query 偶尔召回不相关的中文片段。我的兜底是：对低资源语言，额外加一道 query 翻译做"双路检索"——既用原文 query 检索，也用翻译成中文的 query 检索，两路结果合并去重。中高资源语言不开这个，省算力。

坑二：专有名词和型号被"翻译"了。 用户问 "Model X-200"，翻译环节给翻成了别的，检索全偏。我的处理是把型号、SKU 这类用占位符保护起来，不让它进翻译。这种脏活躲不掉。

坑三：回答语言飘。 偶尔用户用西语问，模型却用中文答（被中文片段带跑了）。我在 prompt 里硬加了"无论检索内容是什么语言，必须用用户提问的语言回答"，并且把用户语言显式检测出来传进去，别让模型自己猜。

搭起来其实不重

这套"语言检测 → 双路检索 → 多语生成"的流程，我是在一个拖拽配节点的智能体平台上拉的。语言检测一个节点、检索一个节点、低资源语言的翻译分支挂个条件判断，生成节点统一收口。整个图清清楚楚，加一种语言基本不用改结构。

模型和向量这块走的讯飞星辰 MaaS（现成的模型即服务），我没自建向量服务，省了部署多语模型那摊事。

你们做跨境客服是维护多份翻译库，还是单库跨语言检索？阿语、泰语这种低资源语言你们检索质量怎么样，评论区聊聊。