這項由美國西北大學、日本早稻田大學、美國布朗大學、日本理化學研究所（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）的改善最明顯。但擴展後的模型性能依然低於處理純英文查詢時的水平，說明詞彙覆蓋只是問題的一部分，更深層的原因在於模型從未經歷過混合語言的訓練，語義處理層面存在根本性缺陷。
