多语言RAG不只是翻译：电商场景下的实体一致性与检索评估

多语言RAG应用常被简化为翻译问题，但在电商场景中，同一个产品可能有多种语言名称、同义词和描述。真正的挑战在于：在允许用户用母语自然提问的同时，保持底层实体的一致性。本文基于工程实践，拆解多语言RAG的五个关键分离关注点，并指出“流畅的答案”并不等于“正确的检索”。

为什么多语言RAG不能等同于翻译

给RAG应用增加一种语言，远不止把查询和文档翻译一遍那么简单。在电商环境中，同一件商品在德语、法语、英语站点可能有不同的名称、同义词和描述文案。如果系统只做翻译，用户用德语提问时，检索层可能匹配到名称相似但实际不同的产品，或者返回了不适合该语言站点的建议。

原文明确指出：挑战在于保持底层实体一致，同时让客户用自己的语言自然提问。这意味着翻译只解决了表层语言问题，而实体对齐、知识隔离和约束一致性才是工程难点。

五个必须分离的关注点

原文将多语言RAG拆分为五个独立但相互关联的层面，这种分离是构建可维护系统的前提。

1. 规范产品标识（Canonical Product Identity）

不同语言的名称、别名和拼写变体，都应该解析到同一个底层产品实体。这是多语言检索的根基——如果实体解析错误，后续所有环节都会失效。实践中需要建立跨语言的实体映射表，并处理同义词和区域差异。

实体解析（Entity Resolution）与规范ID在多语言场景下，所谓“规范产品标识”通常指一个与语言无关的唯一键（如SKU、GTIN或内部产品ID），所有语言变体都通过映射表指向该键。实体解析需要处理三类问题：同名异实体（如德语“Schloss”既可指锁也可指城堡，需结合类目上下文消歧）、异名同实体（同一产品的不同语言名称、缩写、拼写错误）、以及区域变体（同一产品在德语区与奥地利站点可能有细微命名差异）。工程上常用做法是先建立语言内的别名索引，再通过跨语言对齐（如基于多语言嵌入或人工词典）将各语言簇合并到规范ID，并为映射表维护置信度与回退策略，避免错误合并导致的连锁检索失败。

2. 语言特定知识（Language-specific Knowledge）

产品建议和描述必须与请求的语言及店铺视图相匹配。德语用户看到的推荐理由、合规说明和文案风格，应当符合德语站点的规范，而不是从英语直译而来。这要求知识库按语言维度组织，而非简单共享一套内容。

3. 结构化约束（Structured Constraints）

产品属性和可用性规则（如库存、配送范围、尺寸单位）必须与查询语言无关，保持一致。无论用户用哪种语言提问，系统对“这件商品是否可售”的判断应当相同。结构化数据层需要独立于语言处理层。

4. 评估（Evaluation）

不同语言中的等价问题，应该针对同一个预期结果进行测试。也就是说，德语问法和英语问法如果语义等价，检索结果应当指向同一产品。评估集需要跨语言对齐，而不是每种语言单独设计一套标准。

跨语言评估集的对齐方法构建跨语言等价评估集时，常见做法是以规范产品ID为锚点，为每个查询标注“预期命中的实体”，再为同一意图编写多种语言的查询变体。这需要区分“语义等价”与“字面翻译”：直译可能产生生硬或不符合当地表达习惯的查询，反而降低评估真实性。更可靠的方式是由母语者或本地化团队按同一意图重写查询，并人工校验其指向的预期实体一致。评估指标上，可将检索层指标（如Recall@k、MRR，以规范ID为准）与生成层指标（流畅度、语言自然度）分开报告，从而定位问题究竟出在实体解析、知识隔离还是生成环节。

5. 答案质量（Answer Quality）

检索准确性和语言质量应当独立评估。一个德语答案可能语法完美、表达流畅，但指向了错误的产品或目录实体。如果把两者混在一起打分，就会掩盖检索层的真实问题。

核心教训：流畅不等于正确

原文中最重要的提醒是：流畅的答案不一定意味着正确的检索。一个德语回答听起来毫无破绽，却可能引用了不合适的商品或错误的目录实体。对于多语言RAG系统，一致性（consistency）与翻译质量同等重要。

这一点对评估体系设计有直接影响：需要将“检索是否命中正确实体”和“生成语言是否自然”作为两个独立指标分别度量，否则流畅的生成会掩盖检索失败。

实践建议

从工程落地角度，可以优先做三件事：第一，建立跨语言的产品实体映射，确保名称变体收敛到规范ID；第二，按语言和店铺视图隔离知识内容，避免直译污染；第三，构建跨语言等价的评估集，用同一预期结果检验不同语言的检索表现。结构化约束层应保持语言无关，单独维护。

多语言RAG的难点不在翻译模型，而在实体一致性、知识隔离和评估对齐。把这几层分开处理，系统才能在多种语言下提供稳定可靠的结果。