跨语言搜索如何补齐分词、召回与排序

跨境搜索接上翻译 API，为什么还是搜不全？这篇文章给出的答案是：翻译只解决语言表达，分词、词形、字符规范化和地区规则仍要分别处理。作者建议把按语言分析、多语言向量召回、本地化排序接成一条完整链路。

对做跨境电商、商品目录和多语言站内搜索的团队，这套拆解有参考价值。它把「搜索效果不好」拆成了可以定位的工程问题。不过，文中的架构建议主要是经验判断，引用的模型成绩也不能直接当成业务效果。

搜不到商品，可能还没轮到翻译出错

作者用防水夹克举例：德国用户输入「wasserdichte jacke」，日本用户用日语搜索，泰国用户输入一串没有空格的文字。如果底层统一按空格切词，再套英语规则，三种查询都可能漏掉结果。

检索首先要把查询和文档拆成能够匹配的词项。中文、日文、泰文，以及老挝文、高棉文、缅甸文，都不能依赖空格确定词边界。输入切错了，后面的排序再精细，也只能处理已经召回的候选。

中文可以采用 IK、jieba 等词典分词方案，方便控制行业词，但要持续维护词典；也可以采用 CJK bigram，把连续字符切成相邻字符对，以索引膨胀换取召回覆盖。原文引用的 Elasticsearch 文档说明，该过滤器处理中文、日文和韩文，非 CJK 输入保持不变。泰文等语言则需要考虑 ICU 的词典支持。

另一类问题来自词形。德语的「Schuhe」和「Schuh」、俄语的「книга」和「книги」，表达相关含义，字符却不同。词干提取（stemming）可以把部分变化归并，Elasticsearch 已经提供 Arabic、German、Russian 等语言分析器，包含停用词和词干规则，可以优先复用。

但归并也可能伤到品牌和型号。SKU、型号适合放进 keyword 字段，品牌等需要保留的词则应配置词干排除规则。

字符规范化同样要统一：带附加符号的字母可能由一个码点表示，也可能由基础字母和组合标记组成；全角、半角、大小写处理也会影响匹配，土耳其语还有特殊规则。此外，德语复合词、日语和韩语的语序，都提醒我们不能直接照搬英语的短语和邻近匹配规则。

查询与文档必须经过兼容的语言分析，翻译才能发挥作用。

一个混合索引，加向量通道就够了吗

原文比较了三种架构，但没有给出真实部署的成本或效果对照。

架构	适用条件	主要代价
每种语言独立索引	语言集合固定，各语言数据量都较大	每增加一种语言，都要增加运维和调优工作
单索引加语言字段、语言子字段	希望集中管理多语言内容	查询需要路由到对应语言的分析链
向量索引	需要跨语言语义召回	精确型号、编码和数字规格仍需关键词检索

作者偏向把混合索引作为常规方案：入库前识别语言，写入语言字段；不同语言的文本进入各自子字段，绑定独立 analyzer；查询时再按语言路由。独立索引则给各语言更多调优空间。

跨语言检索还要解决另一件事：用户用 A 语言提问，商品文档只有 B 语言。原文给出三条路径。

查询翻译是在搜索时翻译输入，能复用现有索引，接入成本低，但每次查询都会增加外部调用和延迟。行业术语一旦翻错，正确候选可能根本进不了召回集合。

文档翻译把工作提前到入库阶段，查询时无需等待翻译，但索引体积会随目标语言数量增加，源文档更新后还要重新翻译。这里的「查询侧零延迟」仅指没有查询时翻译开销，搜索本身仍然需要时间。

多语言向量对齐则把不同语言映射到共享语义空间，让含义接近的文本彼此靠近。原文引用 LaBSE 在 Tatoeba 上覆盖 112 种语言、达到 83.7% 双语文本检索准确率的结果，对比此前工作的 65.5%，并提到其模型覆盖超过 109 种语言。两个语言数量对应不同描述，不能混为同一指标。

LaBSE 结合了掩码语言建模、翻译语言建模、双编码器翻译排序和 additive margin softmax。multilingual E5 则先在数十亿多语言文本对上做对比预训练，再微调，并提供多种尺寸供选择。

这些数据支持向量对齐的可行性，但没有证明它能独立承担商品搜索。作者建议向量负责跨语言召回，关键词通道保住型号和术语精度，再融合排序。至于融合算法、权重和阈值，原文没有交代。

本地化要管匹配，也要管商品能不能出现

「相关」和「能卖」需要分别处理。一件商品再符合查询，如果目标地区不能销售或配送，就不应该靠扣一点排序分来限制曝光。

作者建议把可售地区、库存和海关限制放进召回阶段的过滤条件；各地区的合规屏蔽规则分别维护，并保留变更和审计记录。

价格、尺寸和日期则需要先统一解释。价格范围查询与排序要使用一致的币种、含税口径；尺寸和重量要处理单位转换；日期要区分日月顺序，数字还要识别千位符与小数分隔符。它们不能只在前端展示时才被格式化。

当地词汇也需要独立维护。例如 football 与 soccer 的市场用法不同，同义词表应按语言管理；日语片假名外来词、西班牙语重音折叠则放在分析阶段处理。

验收同样要拆开。原文举的是一个假设：英语流量占多数时，德语和泰语召回同时下降 20%，综合指标可能只下降几个百分点，看起来仍像普通波动。这不是作者报告的线上实验。

建议是每种语言建立标注集，覆盖高频词、长尾词、型号编码、自然语言问题四类查询；看板默认按语言和地区拆分零结果率、首位结果点击率和召回指标，并为各语言设置独立告警阈值。

我的判断

我认同它对问题边界的拆分。尤其是把语言分析放在前面，把精确字段留给关键词，把地区限制做成硬过滤，能避免团队把所有搜索问题都归因于模型。

但「独立索引质量最好」「混合索引是主流」「向量应承担主要跨语言召回」，都需要结合业务判断。原文没有提供相同语料、相同预算下的架构对照，也没有给出查询翻译与向量检索的业务评测。这些属于经验建议。

如果当前只增加少量语言，现有关键词搜索已经成熟，查询翻译可以作为成本较低的起点。是否进一步引入向量，应看术语错误、漏召回和延迟是否已经成为实际问题。LaBSE 的句子检索成绩，无法代替自家商品型号与规格的测试。

原文结尾还介绍了 Tengence Search，并带有试用和咨询入口，存在明确产品推广语境。架构建议可以参考，但不能据此确认该产品的效果。

能拿来做什么

• 做多语言站内搜索时，先检查语言字段、分析器和 keyword 字段配置，用词形变化、无空格输入、品牌和型号构造回归查询，再判断是否需要增加向量召回。
• 在 Node 搜索接口中统一解析币种、含税口径、单位和日期，并把地区可售、库存和海关条件传给检索过滤器，避免只在前端隐藏不符合条件的结果。
• 接入翻译 API 或多语言 embedding 前，建立术语、品牌和型号保护清单，用同一批查询比较关键词、翻译和向量通道的漏召回与规格错误。
• 发布分词规则、同义词或模型变更时，按语言和地区验收四类标注查询，同时查看零结果率和首位点击表现，避免总指标掩盖小语种退化。