False Proximity: Frozen Code Embeddings Invert Similarity on Behaviourally Divergent Mutant Pairs
本文证明了冻结的 CodeBERT 嵌入会系统性地反转行为差异化变异对的相似性信号，错误地将其评分得比真正等价的代码更相似，从而揭示了此类嵌入反映的是表面接近性而非行为等价性，并表明其需要对比微调或基于执行的验证才能进行可靠的代码分析。
原始论文采用 CC BY 4.0 许可（https://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
在现代软件的广袤版图中，程序通常被视为仿佛在说一种计算机能瞬间理解并进行比较的语言。为了理解这种复杂性，研究人员开发了将代码行转化为高维空间中数学点的工具。将这些点想象成地图上的位置：如果两段代码在功能上相似，它们的点应该靠得很近。这种被称为“嵌入”（embedding）的方法已成为搜索代码、寻找重复程序或在不运行软件的情况下预测错误的标准方式。执行此任务最流行的工具依赖于在海量文本和代码上训练的模型，这些模型通过学习单词和符号排列方式中的模式来识别特征。普遍的假设一直是：如果两段程序在表面上看起来非常相似——共享相同的单词和结构——那么它们一定在做同样的事情。这一信念支撑着许多帮助开发者管理代码的自动化系统，但它建立在一个脆弱的直觉之上：即视觉上的相似性总是等于功能上的相似性。
一组研究人员试图通过一项严谨的实验来测试这一直觉，提出了一个简单但危险的问题：当两段程序看起来几乎完全相同，但功能却截然相反时，会发生什么？他们利用数千个真实的编程问题构建了一个受控环境。从 800 个不同的挑战集合中，他们收集了已知正确且功能等价（意味着它们以相同的方式解决问题）的代码对。然后，他们通过对一段正确的程序进行微小的单项改动，创建了第二组代码对——例如将一个“是”到“否”的条件翻转，将“大于”号换成“小于”号，或者反转列表的顺序。这些改动足够小，使得代码看起来几乎一样，但又足够严重，以至于程序在运行任何测试用例时都会失败。研究人员随后将这两组代码对输入到标准的代码比较工具中，以观察这些工具是否能分辨出正确程序与其损坏的、反向的孪生兄弟之间的区别。
结果不仅是无法区分，甚至完全颠倒了现实。当这些工具将损坏的反向程序与其原始版本进行比较时，它们给出的相似度评分竟然比比较两个完全不同且独立编写的正确解决方案还要高。事实上，在超过十分之九的比较中，这些工具都是错误的。那个本应衡量两段程序匹配程度的数学得分，实际上测量的是它们在表面上有多像。由于损坏的程序与原始程序共享几乎所有的单词和行，工具将其视为完美的匹配，完全忽略了它们的行为其实是截然相反的。这种现象在不同类型的代码改动和不同版本的比较工具中一致出现，表明这并非一个小故障，而是这些模型在未经过专门针对行为差异进行训练时，在解释代码方面存在的一个根本性缺陷。
研究人员随后调查了是否可以通过不需要重新训练庞大模型的低成本、简单调整来修复这一错误。他们尝试了旨在使代码点在空间中分布得更均匀的数学技巧，希望这能让差异更加显著。他们还尝试将代码比较与统计代码树中有多少行不同的结构分析相结合。这些方法都没有奏效。事实上，加入结构分析反而使问题变得更糟。因为损坏的程序在结构上与原始程序几乎完全相同——仅有一行的差异——所以结构化工具给了它们很高的相似性评分，从而强化了错误而非纠正错误。这些工具过于关注代码的表面外观，以至于无法察觉到功能的反转，即使研究人员明确尝试强迫它们观察得更深。
这项研究揭示了驱动现代代码搜索和重复检测技术的关键盲点。这些工具擅长寻找看起来相同的代码，但当被要求判断两段代码是否在做同样的事情时，尤其是当其中一段是另一段微妙的损坏版本时，它们具有极大的误导性。研究人员发现，对于这类特定的错误，使用冻结的、预训练模型的标准方法不仅是不精确的，而且是反向的。要可靠地辨别一个正确的函数与它的行为对立面，开发者不能仅仅依赖这些相似性评分。相反，他们必须要么使用包含这些错误实例的特定案例来重新训练模型，或者更可靠地，实际运行代码以观察其行为。研究结论指出，在做出这些改变之前，依赖这些相似性评分的系统将继续把一个损坏的程序误认为是一个完美的匹配，从而可能将关键的漏洞隐藏在显眼之处。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。