这项由意大利博洛尼亚大学（University of Bologna）信息科学与工程系主导的研究，以预印本形式发布于2026年5月，论文编号为arXiv:2605.08299，感兴趣的读者可通过该编号查询完整原文。

当程序员在代码库里找一段"能把列表里最小缺失正整数找出来"的代码时，搜索引擎却把一堆看起来长得像但功能完全不同的代码塞给他——这种抓狂的经历，相信很多开发者都不陌生。代码搜索，说白了就是"在成千上万段代码里找到你真正需要的那一段"，听起来简单，做起来却难得要命。

问题的根源在于，现代代码搜索引擎通常依靠"向量嵌入"技术工作——你可以把这想成给每段代码拍一张"指纹照片"，然后通过比较指纹来找相似的代码。麻烦在于，给代码拍指纹的这台相机（也就是所谓的"编码器"）有个坏毛病：它特别在意代码的"外貌"——变量叫啥名、语句怎么排列——而不是代码实际"在做什么"。这就像两个人都在做番茄炒蛋，一个人写"先打鸡蛋再下番茄"，另一个写"先翻炒番茄再倒入蛋液"，做出来的菜是一样的，但相机却觉得这两张照片差别很大。

博洛尼亚大学的研究团队决定换一个角度来解决这个问题：既然代码的"外貌"会误导搜索，何不把代码"翻译"成另一种形式，让搜索引擎更容易理解它的本质意图？更进一步，他们想搞清楚，这种翻译应该翻译到什么程度？翻译一点点，还是彻底翻译成白话文？什么时候翻译是值得的，什么时候反而帮倒忙？

带着这些问题，研究团队展开了一场系统性的实验。他们设计了三个层次的"翻译策略"，就像厨师给同一道菜写出三种不同详细程度的食谱一样：第一种是"风格润色"，就像把食谱重新排版但内容不变；第二种是"伪代码"，像把复杂的烹饪步骤转写成通俗的操作指南，去掉专业术语但保留逻辑骨架；第三种是"完全自然语言"，彻底翻译成一句话描述，比如"找到列表中从1开始第一个不存在的正整数"。这三种策略在六个不同的代码搜索测试集、五种不同的代码搜索引擎、三个来自不同公司的AI翻译模型上进行了全面测试，总计覆盖了90种不同的实验配置。

研究结论出人意料地清晰：在代码密集型的搜索任务中，把代码彻底翻译成自然语言，能让某些搜索引擎的准确率从0.23直接飙升到0.74——提升幅度超过200%。但这个策略并不是万能的，在自然语言本身就很丰富的搜索场景里，翻译反而会帮倒忙。更妙的是，研究团队还发现了一个简单的"预测信号"，可以在不跑完整搜索实验的情况下提前判断翻译策略是否值得——这一发现，对实际工程部署有相当大的参考价值。

一、代码搜索为什么那么难——从"拍指纹"说起

要理解这项研究，得先搞清楚现代代码搜索是怎么工作的。

今天最主流的代码搜索方式，靠的是"密集向量检索"——把每一段代码和每一个搜索查询都转换成一串数字（向量），然后通过计算这些数字串之间的距离来判断相似程度。负责做这种转换的工具叫"编码器"，可以理解为一台专门给代码拍"语义指纹"的相机。

这台相机的问题在于，它是靠大量代码数据训练出来的，而训练数据里充满了各种编程习惯和风格的代码。结果就是，相机学会了识别代码的"外貌特征"：用了什么关键词、变量名叫什么、代码结构长什么样。但程序真正做了什么事——也就是它的"语义"——这台相机往往抓得不够准。

举个具体的例子。前面提到的那个"找最小缺失正整数"的函数，有人可能写成：用一个集合存储所有正数，然后从1开始逐个检查是否存在，找到第一个不存在的数就返回。另一个人可能把变量名全换成a、b、c，或者把循环结构稍微改一下——内容完全一样，但代码的"外貌"已经面目全非。搜索引擎的相机看到这两段代码，可能会觉得它们相差甚远，从而把正确结果排在很后面。

之前已经有研究者发现了这个问题，并尝试了一个解决办法：用大型语言模型（就是ChatGPT那类AI）把代码"润色"一遍，统一风格，然后再拿去搜索。这样确实有效，但留下了两个没解答的问题：翻译应该翻译到什么程度才最有效？以及，每次来了一个搜索查询就要调用一次AI翻译，这个成本值不值得？博洛尼亚大学的团队就是要正面回答这两个问题。

二、三层翻译策略——从风格润色到彻底说人话

研究团队设计的核心思路，就是把代码的"翻译层次"当作一个连续的刻度盘，从几乎不变到彻底变形，看看拨到哪里搜索效果最好。

最浅的一层叫"风格润色"（Rephrasing）。这就像把你写的一段文字交给一个文字编辑，他不会改你说的内容，只会把表达方式统一成他自己的风格。放到代码上，就是用AI把代码里的变量名、格式、语法结构重新写一遍，使其更规范统一，但代码的逻辑和结构完全不变。以前一位研究者（来自新加坡管理大学等机构）已经用过这种方法，也是这项研究的基准对比对象。

中间层叫"伪代码"（PseudoCode）。这是这项研究引入的全新尝试。伪代码是一种"既不是真正的代码，也不是纯粹的人话"的混合体，类似于厨师手册里的操作步骤：用大写的关键词标注控制流（比如WHILE、RETURN），用普通话描述操作逻辑（比如"只保留正数"、"快速查找候选值"）。伪代码去掉了大量编程语言特有的语法噪音，同时保留了程序的逻辑骨架。关键在于，这项研究把伪代码直接当成最终的搜索媒介——查询和文档都转换成伪代码，然后在伪代码的空间里做搜索。这一点与之前某些研究把伪代码只当中间桥梁用完就丢掉的做法截然不同。

最深的一层叫"完全自然语言"（Natural Language，简称NL）。这就是彻底说人话——把那个找最小缺失正整数的函数，翻译成"通过忽略非正数值并从1开始向上检查整数，返回最小的缺失正整数"这样一句话。所有的代码语法全部消失，只剩下对程序行为的纯文字描述。同样，这项研究把这个纯文字描述直接用于搜索——查询翻译成自然语言描述，文档也翻译成自然语言描述，然后在纯文字的空间里做匹配。

在这三种翻译策略之上，研究团队还设计了两种使用模式。第一种叫"查询加文档同步翻译"（QC模式），就是每次来了一个搜索请求，AI要同时翻译这个查询和数据库里的文档，查询和文档都换成同一种语言再匹配——这相当于每次搜索都需要临时调用一次AI，成本比较高。第二种叫"仅文档预先翻译"（C模式），就是事先把整个代码数据库翻译一遍存好，以后查询时直接用原始查询去匹配已翻译的文档——这样可以省掉每次搜索时的AI调用，更经济实惠。这两种模式哪个更好，也是研究想要回答的核心问题之一。

三、实验现场——六场比赛，五种选手，三位裁判

为了让结论足够可靠，研究团队搭建了一个相当大规模的测试舞台。

测试场地是六个来自CoIR基准集的代码搜索任务，涵盖了三大类型：代码找代码（给你一段代码，帮你找功能相似的代码）、文字找代码（给你一段自然语言描述，帮你找对应的代码实现）、以及混合类型（查询和文档都是代码与自然语言的混合体）。六个具体的测试集分别是CT-Contest（竞赛编程题）、CT-DL（深度学习相关代码）、Apps（编程题答案）、CosQA（代码问答）、StackOverflow-QA（技术问答社区内容）以及CodeFeedback-MT（多轮代码对话）。

参与测试的搜索引擎（编码器）共有五种，覆盖了通用型和代码专用型两大类：Qwen3-Emb（阿里通用嵌入模型）和E5-base-v2（微软通用嵌入模型）代表通用选手；MoSE-18（博洛尼亚大学自研的代码嵌入模型）、CodeXEmbed（Salesforce代码检索模型）和UniXcoder（微软代码表示模型）代表代码专用选手。

担任翻译工作的AI（重写器）来自三个完全独立的模型家族：Qwen3-Coder-30B来自阿里巴巴，DeepSeek-Coder-V2-Lite来自深度求索，Codestral-22B来自法国的Mistral公司。选择三个完全不同来源的AI，是为了验证研究结论是否只对某一种AI有效，还是具有普遍性。

所有实验的评价标准统一采用NDCG@10——这个指标衡量的是搜索返回的前10个结果里，真正相关的结果排得有多靠前。满分是1.0，越高越好。

四、惊人的数字背后——翻译效果究竟有多大

实验结果出来了，在代码密集型的搜索任务上，完全自然语言翻译加上同步翻译查询的组合，拿出了令人印象深刻的成绩单。

最戏剧性的案例发生在MoSE-18这个编码器上。在CT-Contest这个竞赛编程搜索任务里，不做任何翻译时，MoSE-18的NDCG@10得分只有0.23——这意味着它找到的结果里，相关代码排得很靠后，基本算是在瞎猜。但在采用了完全自然语言翻译之后，得分直接跳到了0.74。从0.23到0.74，绝对提升了0.51分，相对提升幅度超过了200%。同一个搜索引擎，同一道题，就因为换了一种"语言"来表达，搜索效果天翻地覆。

E5-base-v2这个通用型编码器也受益匪浅，在CT-Contest上从0.61提升到0.85，在CT-DL上也有明显进步。UniXcoder在CT-Contest上的提升更是达到了32%。

伪代码的表现稳稳地夹在风格润色和完全自然语言之间——不如最彻底的翻译，但比只做风格润色要好。这种单调递进的规律在代码密集型任务上非常稳定，就像用越来越白话的方式写说明书，读者理解起来确实越来越轻松。

但是，对于本来就已经很强的代码编码器，翻译的边际效益急剧下降。CodeXEmbed在CT-DL上的基准分数已经有0.33，而所有翻译策略反而都低于这个分数——说明当搜索引擎本身已经足够强，翻译这道工序就成了多此一举，甚至会引入新的噪音。

Qwen3-Emb这个通用编码器的表现更是直接告诉你翻译策略的边界在哪里：平均得分从0.56下降到了0.52。这并不奇怪，因为Qwen3-Emb本身已经有强大的语言理解能力，翻译改变了代码的原始信号，却没有给它提供更多有用的信息，反而适得其反。

五、同步翻译vs预先翻译——省钱的方案为什么不靠谱

研究团队原本也很期待那个更省钱的方案——预先把整个代码库翻译好，以后查询直接用原始问题来搜翻译后的库。如果这个方案管用，就可以节省每次搜索时调用AI的时间和费用。

然而结果相当扎心：在90种实验配置中，有56种（约62%）在只翻译文档而不翻译查询的情况下，搜索效果反而比什么都不翻译还要差。整体来看，同步翻译查询和文档的QC模式在78/90次对比中胜出了单独翻译文档的C模式，胜率达到86.7%。

道理其实并不难懂。代码搜索的本质是"语言匹配"——查询和文档要说同一种语言，相机才能把它们的指纹拍得相近。你把所有代码都翻译成了自然语言，但搜索时还是用原始代码来查，这就像你把餐厅菜单翻成了日语，却用中文去找菜名，当然找不到。这种"语言不匹配"的问题，研究者称之为"模态错位"，是单独翻译文档策略失败的根本原因。

具体的数字更能说明问题。MoSE-18在只翻译文档的完全自然语言策略下，平均分从基准的0.12下跌到了0.08——比啥都不做还差了整整三分之一。C模式下的自然语言翻译，成了所有配置里最糟糕的选择之一。

这个发现对实际应用有明确的指导意义：如果你打算在生产系统里用翻译策略来改善代码搜索，省掉查询端翻译的想法得打消——省下来的成本，是用搜索质量的大幅下降来换的，不划算。

六、为什么翻译会改变搜索效果——用"词汇熵"来解释

研究团队不满足于只记录"翻译有没有用"，他们更想搞清楚"翻译为什么有用"。为此，他们引入了两个测量工具，用来在翻译前后"解剖"代码的表示特征。

第一个工具叫"输入词汇熵变化"（ΔH）。"熵"这个词听起来高深，实际上在这里就是衡量词汇多样性的一把尺子。代码里的词汇高度集中——for、if、return、等号、括号，这些符号反复出现，词汇分布极度不均匀，熵值很低。翻译成自然语言之后，词汇变得丰富多样，分布更均匀，熵值升高。ΔH就是翻译前后熵值的变化量——这个数字越大，说明翻译把代码的词汇结构改变得越彻底。

实验数据印证了这个逻辑：在CodeXEmbed和E5-base-v2这两个编码器上，风格润色让ΔH约为+0.79到+0.80，伪代码提升到约+1.15到+1.16，完全自然语言更是达到约+1.38到+1.44。这个单调递增的规律，与三种策略在代码搜索效果上的排名完全一致。

从词汇统计的角度来看，自然语言翻译后，语料里"只出现一次的词"（Hapax词）的比例从原始代码的约27-34%跳升到了约40-47%——这意味着词汇的长尾分布更加丰富，更多的语义细节被编码进了文本。在自然语言翻译的语料中，要覆盖80%的文本内容，需要的不同词汇数量大约是原始代码的1.9倍。换句话说，自然语言描述的词汇多样性几乎是代码的两倍。

第二个工具叫"嵌入配对余弦相似度变化"（Δs）。这是在"指纹空间"里测量的：翻译之后，数据库里所有代码段的指纹，平均来说是离得更近了（说明它们被压缩到了相似的区域），还是离得更远了（说明它们被区分得更好了）？离得更远通常意味着搜索效果更好，因为不同的代码段有了更大的区分度。

完全自然语言翻译对所有五个编码器都让Δs 变负了（最大的提升出现在UniXcoder上，Δs = -0.15），说明翻译确实让指纹空间变得更"宽敞"、区分度更高。相比之下，伪代码对某些编码器反而让指纹更聚集（UniXcoder上Δs = +0.08），这可能是因为伪代码保留了一些语法结构，对某些编码器来说反而引入了干扰。

七、ΔH——一个神奇的"预言信号"

研究中最具实用价值的发现，莫过于ΔH这个词汇熵变化指标，竟然可以在不跑完整搜索实验的情况下，预测翻译策略对搜索效果的提升幅度。

研究团队用斯皮尔曼相关系数（一种衡量两个排名之间相关性的统计指标，满分是1或-1，越靠近±1说明相关性越强）来量化这种预测能力。结果显示，在同步翻译查询和文档的QC模式下，ΔH与搜索效果提升之间的相关系数，对Qwen重写器为+0.356（统计显著），对Codestral重写器高达+0.593，对DeepSeek为+0.274，把DeepSeek和Codestral合并计算后的相关系数为+0.436。这些数字说明，ΔH是一个相当可靠的预测指标——词汇熵变化越大，翻译带来的搜索提升通常也越大。

这个指标还有一个特别好用的性质：它可以双向预测。在CosQA这个自然语言查询的搜索任务上，三个重写器的ΔH都接近零甚至为负（DeepSeek：-0.11；Codestral：-0.36），而相应地，这些任务上翻译策略对搜索效果的影响也是均匀负面的——三个重写器上，所有翻译策略都比不翻译更差。

这就意味着，在真实部署时，工程师可以先快速计算一下ΔH，如果这个数字很大，说明翻译策略值得投入；如果接近零或为负，说明直接跳过翻译更明智。这比跑完整的搜索实验要便宜得多。

ΔH之所以只在同步翻译模式下有预测力，而在单独翻译文档的模式下没有，恰恰是因为"模态错位"问题——单独翻译文档时，查询和文档根本就不在同一种语言里，ΔH测量的词汇多样性提升完全派不上用场，搜索效果主要由语言错位主导，ΔH自然就失去了预测力。

八、不同AI翻译器，结论一样吗——跨家族验证

为了确认研究结论不只是某个AI翻译器的特有结果，研究团队把核心实验用DeepSeek和Codestral重复做了一遍，选取了区分度最大的两个测试任务：CT-Contest（代码密集型）和CosQA（自然语言密集型）。

在代码密集的CT-Contest上，完全自然语言策略对Qwen重写器平均得分0.81，对DeepSeek得0.65，对Codestral得0.72——三者都是各自重写器下最好或并列最好的策略。这一点相当稳定，说明"自然语言翻译在代码搜索上有效"这个结论，是任务本身决定的，不是哪个AI翻译的特性。

但三种策略之间的相对排名却因重写器而异：Qwen的结果完全符合风格润色＜伪代码＜自然语言的单调顺序；Codestral的最佳策略反而是风格润色（得0.74，比其自然语言翻译的0.72还高一点点）；DeepSeek的伪代码得分（0.53）比风格润色（0.58）还低——顺序完全乱了。这说明，三种策略的具体排名取决于翻译AI本身的特性，而不是一个普遍规律。

好消息是，ΔH对三个重写器都有预测能力。即使三个重写器的策略排名不同，ΔH都能正确地指向每个重写器下最好的策略——因为ΔH是从实际产生的翻译文本里计算出来的，天然就反映了那个重写器的翻译特性。

在CosQA上，三个重写器的翻译策略都比原始基准差，无一例外。DeepSeek的平均最高分是0.17，Codestral是0.17，Qwen是0.22，而原始基准是0.24到0.38。这证明翻译策略在自然语言查询场景下的失效，是这类任务本身的固有性质，不是某个特定翻译模型的问题。

九、混合任务和翻译器大小——更多细节里的规律

在混合型搜索任务（查询和文档都混合了代码和自然语言）上，三种翻译策略的效果差距大幅收窄。在同步翻译模式下，伪代码和自然语言并列得到了0.26的平均分（略高于基准的0.24），风格润色为0.25，三者相差不超过0.01。混合任务的收益几乎全来自CodeFeedback-MT这个子任务（从0.07提升到0.10，相对提升43%），而在StackOverflow-QA上提升非常有限。

在单独翻译文档的模式下，自然语言翻译是混合任务上唯一平均得分低于基准的配置（0.21 vs 0.24）——这与代码密集型任务上的模式一致，单独翻译文档但查询不翻译，自然语言这种改动最大的策略反而最容易"出错"。

研究团队还做了一个"翻译器大小"的额外实验，使用来自同一个系列（Qwen2.5-Coder-Instruct）的1.5B、3B、7B、14B四个不同规模的模型，在CT-Contest上测试翻译效果随模型大小的变化。整体规律是模型越大搜索效果越好——14B的版本在几乎所有编码器和策略组合上都优于1.5B。但这个规律并非铁板一块：MoSE-18在伪代码策略上，14B模型（0.33）甚至比7B模型（0.44）得分还低，说明更大的模型不一定在每个具体情况下都胜出，收益与硬件成本的权衡需要具体情况具体分析。

十、算一算账——翻译到底划不划算

研究团队还做了一个实际部署成本的估算，让这项研究的结论落地到工程实践层面。

在一张H100-80GB的GPU上运行Qwen3-Coder-30B（以FP16精度、vLLM框架，512词上下文），对四个CoIR测试集约38000个代码片段完成一次完整的自然语言翻译，大约需要16.5个GPU小时。风格润色稍快，大约11个GPU小时。这是一次性的离线成本，翻译完可以一直用。

查询端的翻译（每来一个搜索请求都要调用AI翻译一次）额外增加约725毫秒的解码延迟。在搜索响应时间要求不高的场景（比如后台批处理）里，这个延迟完全可以接受；但在需要毫秒级响应的实时搜索场景里，就需要权衡了。

研究团队据此给出了一个部署决策框架：如果你用的是轻量级编码器，面对的是代码密集型的查询，ΔH计算出来比较大，那么投入AI翻译的成本是值得的，优先选用同步翻译查询和文档的方式，翻译策略选完全自然语言。如果你用的已经是强大的代码编码器，或者面对的查询本来就是自然语言为主，ΔH接近零，那就省掉翻译这一步，直接搜索。

这项研究也坦率地指出了自身的局限：测试只覆盖了三个开源AI翻译器，没有测试GPT-4o或Claude这类闭源前沿模型；测试集以Python代码为主，在低资源编程语言上的表现还未知；ΔH是语料库级别的汇总指标，不能预测单条查询的搜索效果；延迟估算假设的是单张GPU无批处理，实际工程环境中通过批处理和缓存优化后，成本可能会进一步降低。

说到底，这项研究告诉我们的，是一件听起来简单却非常有用的事：代码和语言，可以互相转化，而转化的程度，决定了搜索的效果。把代码翻译成白话文，让搜索引擎"读得懂"，对于那些原本连最基本功能都摸不清的轻量级搜索引擎来说，是一剂相当有效的提升药方。从0.23到0.74的跳跃，不是魔法，而是语言对齐的力量。

但翻译也不是万能的。当搜索引擎本身已经很强，当查询本来就是自然语言，当只翻译了文档却忘了查询——翻译反而会帮倒忙。研究给出的ΔH这个快速判断工具，提供了一种务实的解题思路：先算一算词汇多样性的变化，再决定要不要翻译，而不是无脑地把所有东西都扔给AI改写一遍。

对于普通用户，这项研究的直接影响可能还需要一段时间才能传导到你每天使用的代码搜索工具上。但下次你在某个IDE或代码搜索平台里发现，搜索结果突然变精准了，找到了以前怎么搜都找不到的那段代码——很可能背后就有类似的翻译机制在悄悄工作。

有兴趣深入了解这项研究细节的读者，可以通过论文编号arXiv:2605.08299找到完整原文，研究团队承诺所有实验提示词、重写模板和代码都将公开发布。

Q&A

Q1：代码搜索中的"向量嵌入"是什么意思，为什么它会出问题？

A：向量嵌入是把代码转换成一串数字（向量），通过比较数字间的距离来判断两段代码是否相似。它的问题在于，负责做转换的编码器通常过于依赖代码的外观（变量名、语法结构），而忽视了代码实际在做什么。两段功能完全一样但写法不同的代码，可能被判定为"不相似"，导致搜索结果不准确。

Q2：只翻译代码库而不翻译搜索查询为什么会让搜索变差？

A：因为搜索的本质是让查询和文档"说同一种语言"。如果把代码库全翻译成自然语言，但每次搜索时还是用原始代码来查，就像把菜单翻成了日语，却用中文去找菜名，语言对不上，匹配就会失败。这项研究发现，这种"只翻文档不翻查询"的方式，在62%的测试配置下反而让搜索效果比完全不翻译更差。

Q3：ΔH（词汇熵变化）怎么用来判断要不要用翻译策略？

A：ΔH衡量的是翻译前后代码词汇多样性的变化量。如果一段代码翻译成自然语言后ΔH很大（比如+1以上），说明翻译大幅丰富了词汇结构，搜索效果通常也会明显提升，值得投入翻译成本。如果ΔH接近零甚至为负（比如查询本来就是自然语言），说明翻译改变不了什么，甚至会破坏原有的信号，这时候直接跳过翻译步骤更聪明。