这项由美国西北大学、日本早稻田大学、美国布朗大学、日本理化学研究所（RIKEN AIP）、Snowflake公司、美国犹他大学以及东京大学联合开展的研究，于2026年4月发布在预印本平台arXiv上，论文编号为arXiv:2604.17632。感兴趣的读者可以通过这个编号查阅完整原文。
你有没有过这样的经历：在搜索框里打出"推荐几款性价比高的gaming laptop"，或者发消息问朋友"这个deadline到底是几点截止"？这种中文和英文混着用的说话方式，在全球超过70亿人中的超过一半身上每天都在发生。语言学家有个专门的术语称呼这种现象，叫做"语码转换"（code-switching），指的是人在说话或写作时自然地在两种或多种语言之间切换。
然而，当你把这样一段"混搭语言"输入谷歌、百度，或者任何一个AI问答系统时，背后的检索引擎其实正悄悄地犯难。这些系统在设计之初，几乎清一色假设你说的是"纯粹"的某一种语言。当你中英文混着来，它们的表现会好吗？
这项研究给出了一个令人冷静的答案：不好，而且比我们以为的糟糕得多。研究团队构建了两个全新的评测基准——CSR-L（代码转换检索基准精简版）和CS-MTEB（代码转换版大规模文本嵌入基准），系统性地测试了从传统统计方法到最前沿大模型的各类检索系统，发现性能下降幅度最高可达27个百分点。更重要的是，他们还尝试了一种"给模型补词汇"的修复方案，结果发现有效果，但治标不治本。
一、为什么"中英夹杂"对搜索引擎来说是个大麻烦
要理解这件事，可以先用一个厨师的比喻来热身。假设你是一位只受过中餐培训的厨师，现在有人递给你一张食谱，上面一半是中文菜名，一半是法语烹饪术语。你大概能猜出个大概，但很可能在关键步骤上犯错——因为你的训练经历从来没让你面对这种"混合食谱"。
现代AI检索系统的核心部件，是一个叫做"嵌入模型"（embedding model）的东西。它的工作原理，是把每一段文字变成一个多维空间中的点——语义相近的文字，会被放在空间中相近的位置。你搜索"mRNA疫苗的最新进展"，系统会把这句话变成空间中的一个点，然后找出距离这个点最近的文章。
问题在于，绝大多数嵌入模型是用"纯粹的单一语言"训练出来的。当你塞进一段"mRNA vaccine for SARS-CoV-2 的已知信息和最新进展？"这样的中英混合查询，这个模型就像那位只懂中餐的厨师，遇到了一张混搭食谱。它还是能产出一个"点"，但这个点落在空间中的位置，可能跟你真正想找的文章离得相当远。
研究团队还用一个非常直观的方式证明了这一点：他们用主成分分析（PCA，一种把高维数据压缩成可视化图形的技术）把查询语句的"位置"画出来，结果发现，对于以英文为主的模型，纯英文查询和中英混合查询在空间中形成了两个几乎完全分离的"星团"——就像把北京话说话者和上海话说话者分到了两个互不相交的房间里，即使他们在问同一个问题。相比之下，多语言模型的两个星团有更多重叠，但依然没有完全融合。这种空间上的分裂，正是检索性能下降的几何学原因。
二、他们是怎么"出卷子"的：两个全新测试基准的诞生
研究团队做的第一件事，是制作一套专门用来测试这个问题的"考题"。
CSR-L这套题目的制作方式非常严格，完全依赖人工。研究团队选取了四个已有的英文信息检索数据集，分别来自不同领域：Touché 2020涵盖的是辩论式议题检索（比如"教师应不应该有终身教职"），HumanEval面向的是代码检索任务，TRECCOVID是生物医学文献检索，FollowIR则测试系统能否理解并遵循指令。这四个数据集的文章库保持原样，全部是英文——被改写的只有查询语句本身。
改写工作由三位母语为中文、同时具备英语和日语专业能力的研究者完成。整个过程分两步走：一个人先把查询改写成中英混合形式，另一个人审核并在必要时修改或淘汰。改写的原则很清晰：不能改变原意，不能只加一两个外来词，两种语言都要承担实质性的内容（而不是"摆样子"），同时要尽量自然，像一个真实的双语用户会打出来的东西。最终，针对中文和日文各生成了一套查询集。以TRECCOVID为例，最终有50条查询，对应着超过17万篇文章的语料库，每条查询平均对应493篇相关文档。
第二套题目CS-MTEB规模更大，覆盖11个不同任务、7种任务类型。由于人工改写在这个规模下根本不可行，团队转而使用大语言模型MiMo-V2-Flash来生成代码转换版本。为了保证质量，他们先用人工写的CSR-L查询来"调教"提示语，还对50条自动生成的查询进行了人工抽检。抽检结果显示，自然度平均得分9.16分（满分10分），信息保留度平均9.78分，说明自动生成的质量基本可靠。CS-MTEB涵盖的语言多达9种，除了中文和日文，还包括德语、西班牙语、韩语、法语、意大利语、葡萄牙语和荷兰语，全部与英语混合。任务类型则涵盖检索、重排序、聚类、分类、语义文本相似度、对比分类等多个维度。
三、"考场"里的惨烈表现：没有人能全身而退
现在来看看各路模型在这两套题目上的成绩。用一个比喻来说：如果说不同检索方法是不同风格的厨师，那这次测试就是一场料理比赛，菜单突然临时换成了"中西合璧"的混搭菜肴。
研究团队测试了四大类方法。第一类是统计方法的代表BM25，它的工作原理类似于数单词出现频率，看查询里的词在文章里出现多少次。第二类是双编码器（bi-encoder）模型，涵盖从轻量级的all-MiniLM-L12-v2到专为多语言设计的mE5-large、bge-m3，再到最新的Qwen3-Embedding系列（0.6B、4B、8B三个规格）。第三类是交叉编码器（cross-encoder）模型，包括jina-reranker-v3、bge-reranker-v2-m3以及Qwen3-Reranker系列。第四类是晚交互模型ColBERT v2，它在搜索效率和精度之间走了一条独特的折中路线。
测试结果用nDCG@10作为主要衡量指标——这个指标衡量的是前10条搜索结果的质量，满分是100，越高越好。
英文专用模型的崩塌最为明显。以e5-large-v2为例，在Touché 2020数据集上，纯英文查询得分42.52，而中英混合查询直接跌至22.88，几乎腰斩。在TRECCOVID上，从66.64跌至50.42，损失近25%。整体平均下来，从47.22跌至35.32，跌了将近12个百分点。ColBERT v2的情况同样糟糕，在Touché 2020上从61.62跌至29.30，几乎损失了一半的搜索能力。
多语言模型的表现好一些，但依然无法独善其身。mE5-large从49.66跌至42.76，bge-m3从42.03跌至39.65。更重要的是，即便是当前最强的Qwen3-Embedding-8B，在Touché 2020和TRECCOVID上的跌幅依然超过5个百分点，平均下来从69.88跌至66.20。模型越大，抵抗力越强，但没有任何一个模型能做到"免疫"。
有一个有趣的例外值得一提：HumanEval数据集上的下跌幅度普遍比其他数据集小。研究团队的解释是，代码检索这个任务结构相对简单——因为代码中的函数名、变量名这些关键词是不能翻译的，所以即便查询被"混搭"了，核心搜索词（代码关键词）本身没有发生变化，模型还是能抓住大部分信息。这反过来说明，当混搭查询改变了核心语义词汇时，模型的处理能力就会显著下降。
交叉编码器的表现也很有启发性。这类模型的计算成本更高，理论上能对查询和文档之间的关系做更细致的分析。但实验结果显示，它们并没有因此获得额外的"抗混搭"能力。需要特别说明的是，在CSR-L实验中，研究团队让交叉编码器直接对每个查询和整个文档库做评分，而不是先检索再重排序——所以表格中交叉编码器的绝对分数不能直接和其他方法的分数横向比较，但下降的趋势是一致的。为了排除这个实验设计的影响，研究团队还额外做了一个标准的"先检索后重排序"实验：用Qwen3-Embedding-0.6B先取回前100个候选文档，再分别用jina-reranker-v3和Qwen3-Reranker-0.6B重排序。结果显示，在这种标准流程下，代码转换依然造成了平均约2个百分点的性能下滑，证明问题不是实验设计的产物。
在CS-MTEB的大规模测试中，情况同样令人清醒。e5-large-v2在原始任务上的综合得分55.91，混入中文后跌至40.70，损失超过15个百分点。Arctic-Embed-m-v2.0从54.62跌至45.33。Qwen3-Embedding-0.6B从64.12跌至57.24。跌幅最大的任务类型是"重排序"（reranking）——e5-large-v2在日语混合设置下从60.17骤降至25.75，几乎失去了原来60%的能力。相比之下，"对比分类"任务受到的冲击相对较小，大概是因为这类任务只需要判断两段文字的大致语义相关性，对精确匹配的要求没那么高。
更值得注意的是，语言的"远近亲疏"对下跌幅度的影响并不如直觉所想的那么大。德语和西班牙语跟英语同属印欧语系，从语法结构和词汇上都更相近；中文和日文则跟英语差异极大。但e5-large-v2在混入德语时的表现（综合43.64）和混入中文时（40.70）相差并不悬殊。这意味着，问题的根源不仅仅是"语言太不同了"，而是"模型从来没见过混合的输入"。
研究团队还专门做了一个补充实验，用来排除一种质疑：也许跌分只是因为"从英文查询换成其他语言"本身就会导致检索下降，跟"混合"没关系？为此，他们测试了一个中文文档库配中文查询的基线，然后把中文查询改成中英混合版。结果显示，即便原始查询是中文，换成中英混合后也同样出现了下滑——三个测试模型的跌幅在4.63到7.88个百分点之间。这就明确说明，代码转换本身，才是那个真正的"麻烦制造者"。
四、"给模型补课"管用吗：词汇扩展实验的发现
找到问题之后，研究团队自然想试试能不能修。他们选择了一种成本较低的方案：词汇扩展（vocabulary expansion）。
这套方案的原理可以用这个场景来理解：假设你是那位只接受过英文训练的厨师，现在老板给你一本"中英对照食材词典"，列出了"豆腐"对应"tofu"、"花椒"对应"Sichuan pepper"。你不需要重新学厨艺，只需要在读菜单时"翻译"一下陌生词汇。
具体做法是这样的：研究团队利用双语词典（由Conneau等人提供的高质量资源），把目标语言（中文或日文）里的词汇，通过其英文对应翻译，映射到模型已经"认识"的词嵌入空间中。如果一个中文词"学习路线"在英文里对应"learning path"，那就把"learning path"这两个子词的嵌入向量平均起来，作为"学习路线"这个新词汇的初始向量，再加入模型的词表。当一个目标语言词汇有多个英文翻译时，就对所有翻译的嵌入向量取平均。当一个词在词典里找不到对应翻译时，就用随机初始化的向量填充。
这套方案被应用在两个纯英文模型上：all-MiniLM-L12-v2和e5-large-v2。结果是有效的，但有限。
对all-MiniLM-L12-v2而言，在CSR-L-Chinese上的平均分从30.09提升到37.73，在CSR-L-Japanese上从29.94提升到34.34。对e5-large-v2而言，在CSR-L-Chinese上从35.32提升到43.50，在CSR-L-Japanese上从34.70提升到39.80。提升最明显的是Touché 2020和TRECCOVID这两个通用检索任务，代码检索任务HumanEval的提升则小得多——因为代码里的关键词本来就是英文，词汇扩展对这类任务的帮助有限。
但关键是：即便补了词汇，这两个模型的表现依然远远没有恢复到它们处理纯英文查询时的水平。e5-large-v2在中英混合加词汇扩展之后，Touché 2020上得38.55，而它面对纯英文查询时是42.52。差距依然存在，而且对于更难的任务，差距依然显著。这说明，词汇覆盖只是问题的一部分。更深层的问题，在于模型从未用混合语言的数据训练过，它在语义理解层面对"混搭输入"的处理方式本身就有根本性的缺陷，光靠"加词条"是补不上的。
五、这对未来意味着什么：现有修复方案都还不够
归根结底，这项研究想说的是：代码转换不是一个小众问题，也不是一个靠"用更大的模型"就能自然解决的问题。
多语言训练确实有帮助——这是研究的一个重要发现。在相同规模下，专门支持多语言的Arctic-Embed-m-v2.0比仅支持英文的e5-large-v2在混搭查询上的表现更稳定。这说明，暴露于更多语言的训练数据确实给了模型一定的"免疫力"。但这种免疫力不是完全的，而且当任务变得更复杂（比如重排序），即便是多语言模型也会出现严重的功能退化。
模型规模的扩大同样有帮助，但也有上限。Qwen3-Embedding从0.6B到4B再到8B，抵抗能力逐渐增强，但8B版本在某些任务上依然有显著的下滑。换句话说，单纯地"把模型做大"没法从根本上解决这个问题。
研究团队在讨论部分还提到了另一个有趣的观察：现有的多语言模型在"跨语言对齐"方面其实表现不错——它们能识别出"苹果"和"apple"是同一个东西。但这种对齐能力，和"准确检索"所需要的能力，是两回事。检索任务需要的是在混合输入下精确地判断查询和文档的相关程度，这比单纯的语义对齐要复杂得多。研究团队引用了另一项研究的发现加以呼应：大语言模型当一个翻译工具时表现不错，但当直接和多语言检索系统"裸对接"时就会力不从心，代码转换场景同样如此。
这意味着，真正需要的解决方案，不是更好的翻译，不是更大的词典，也不仅仅是更多的多语言预训练数据——而是从一开始就把代码转换作为一种独立的语言使用模式来对待，用混合语言数据专门训练检索系统。这是一条还没有人真正走完的路。
当然，研究团队也坦诚地说明了自己工作的边界。他们的测试主要聚焦在"英文技术词汇嵌入在另一种语言的句子结构中"这种最常见的查询侧代码转换形式，还有更多复杂的情况（比如文档本身就是混合语言，或者涉及罗马字转写、社区特定惯用法等）没有涵盖，留待未来研究继续探索。
说到底，这项研究做了一件看起来平常、实则颇有价值的事：它把一个每天都在无数人的搜索框里发生的现实问题，第一次放到了严格的学术显微镜下系统检验。结果发现，我们每天习以为常的"中英混打"，在当前最先进的检索系统面前，依然是一个没有被真正解决的挑战。
这对普通用户意味着什么？下次你用混合语言搜索，却发现结果不太对劲，可能不是你的问题，而是搜索引擎本身还没完全准备好理解你的语言习惯。而对于构建这些系统的人来说，这项研究留下了一个清晰的待办事项：不要假设用户会用"纯粹"的某种语言来提问，因为真实世界的语言，从来都不是那么"纯粹"的。
有兴趣深入了解这项研究的读者，可以通过arXiv编号2604.17632查阅完整论文，那里有完整的数据表格、方法细节和实验附录，相信会带来更多思考。
Q&A
Q1：代码转换（code-switching）对信息检索系统的影响有多大？
A：根据CSR-L和CS-MTEB两套基准的测试结果，影响相当显著。纯英文模型在混搭查询下的平均性能下降可达12个百分点，最极端情况（如重排序任务）下跌幅接近35个百分点。即便是当前最强的多语言大模型，也无法完全消除这种下降，只是幅度相对较小。
Q2：多语言训练能彻底解决代码转换导致的检索性能下降问题吗？
A：不能彻底解决，只能部分缓解。实验显示，多语言模型（如bge-m3、Arctic-Embed系列）比纯英文模型更能抵抗代码转换带来的冲击，嵌入空间的"漂移"也更小。但在复杂任务（如重排序）上，多语言模型依然出现明显的性能退化。研究团队认为，根本解决方案需要专门用混合语言数据来训练检索系统，而不仅仅是增加多语言训练数据。
Q3：词汇扩展方法能修复代码转换导致的检索下降吗？
A：能部分改善，但无法彻底修复。对两个纯英文模型（all-MiniLM-L12-v2和e5-large-v2）进行词汇扩展后，在CSR-L基准上的平均分提升了约5至8个百分点，通用检索任务（如Touché 2020、TRECCOVID）的改善最明显。但扩展后的模型性能依然低于处理纯英文查询时的水平，说明词汇覆盖只是问题的一部分，更深层的原因在于模型从未经历过混合语言的训练，语义处理层面存在根本性缺陷。