Syntax Repair as Language Intersection
本文将有界语法修复形式化为上下文无关语言与无环莱文斯坦自动机的交集,以创建一个有限且可并行化的有效字符串修复候选空间,并通过 Python 实验证明这种受语法约束的方法显著提高了修复准确率。
原始论文采用 CC BY 4.0 许可(http://creativecommons.org/licenses/by/4.0/)。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性,请参阅原始论文。 阅读完整免责声明
想象一下,你正在编写程序,却不小心把一个左括号 ( 错打成了右括号 )。你的代码变红了,编译器在尖叫“错误!”,而你陷入了困境。大多数工具只会告诉你“出错了”,但它们并不知道你原本想如何修复它。这篇论文介绍了一种修复这些错误的新方法,名为 Tidyparse,它的作用不像是一个猜测者,更像是一个组织严密的图书管理员。
核心理念:“编辑邻域” (The Edit Neighborhood)
把你的错误代码想象成一间窗户破损的房子。作者提出了这样一个问题:“如果我们只被允许进行几次微小的改动,那么修复这个窗户的所有可能方式有哪些?”他们定义了你错误代码周围的一个“邻域”。如果你被允许进行最多 3 次编辑(比如添加一个字母、删除一个或交换一个),那么在这个邻域内存在着一组特定的字符串。
该论文的主要发现是:与其去猜测哪个修复方案是对的,不如通过数学方法计算出在该邻域内存在的每一个有效的修复方案。他们通过将两样东西结合在一起来实现这一点:
- 语法 (The Grammar): 编程语言(如 Python)的严格规则手册。
- 编辑图 (The Edit Map): 一张特殊的地图(称为 Levenshtein 自动机),展示了与你的错误代码在 3 次编辑 范围内的所有可能字符串。
当这两者发生交集(重叠)时,他们就能得到一个有限的列表,其中仅包含既符合语法规则又是你所输入的代码的“合法”修复方案。这就像是将浩瀚的可能性的海洋过滤成一小桶“合法”的修复方案。
他们反对什么
论文明确反对仅仅依靠大型 AI(如大语言模型)直接进行猜测的做法。
- “黑盒”问题: 作者指出,目前的 AI 模型经常会“幻觉”或编造出看起来正确但实际上并不符合语法的代码。他们还认为这些模型过于缓慢且低效,因为这些模型试图同时学习语法规则和写作风格。
- “单一修复”陷阱: 许多旧工具试图寻找仅仅一个“最佳”修复方案。作者认为这是危险的,因为可能存在多种有效的修复方式,而选择错误的那个(即使它是“最有可能”的一个)可能会破坏你的程序。他们认为我们需要先看到一个广泛的选项列表,然后再挑选最好的一个。
工作原理:三步舞曲
该系统并非盲目猜测,而是遵循一个严格的三步流程来寻找正确的修复:
- 交集 (过滤器/The Intersection): 首先,系统构建一个数学笼子。它将语言的语法和“编辑图”结合起来。这创建了一个包含在 3 次编辑 范围内所有可能的有效修复方案的列表。论文证明,对于短代码片段(少于 80 个 token),这个列表足够小,可以快速处理。
- 快速扫描 (侦察兵/The Fast Scan): 接下来,系统需要从列表中找出最有希望的候选方案。它使用一种超快、轻量级的解码器(基于一种称为“加权有限状态自动机”的方法)。你可以把它想象成一个在列表中奔跑的侦察兵,根据简单的模式检查哪些修复方案看起来最自然。它的速度极快,能在毫秒内扫描数千个选项。
- 重排序 (裁判/The Reranker): 最后,系统将前 512 个候选方案交给一个更聪明、更强大的 AI 模型(Transformer)。这个模型会将破碎的代码与候选修复方案放在一起进行观察,以决定人类作者实际的意图是什么。这一步被称为 “LaTeR”(Levenshtein 对齐的 Transformer 重排序器)。
结果:速度与准确度
作者在取自 Stack Overflow 的 2,238 个真实世界 Python 错误上进行了测试。
- 速度: 该系统可以在标准计算机上以不到 1 秒 的时间修复大多数错误。
- 准确度: 在寻找单一最佳修复方案(Top-1)时,他们的方法比以往的工具显著更准确。例如,当其他工具只能在极少数情况下得到正确答案时,Tidyparse 能更频繁地在首选建议中找到正确的修复方案,尤其是在需要 2 或 3 次编辑 的错误情况下。
- 完整性: 在测试中,他们发现对于数据集中约 90% 的错误,正确的修复方案都在系统的搜索限制范围内。然而,他们也注意到,在约 27% 的案例中(2,238 个中的 604 个),真实的修复方案并未出现在最终列表中。这是因为正确的修复方案要么离得太远(需要超过 3 次编辑),要么代码片段太长(超过 80 个 token),这意味着系统无法找到它,因为问题超出了其定义的搜索范围。
它目前做不到的事
论文非常明确地说明了其局限性。
- 它只修复语法,不修复逻辑: 系统确保代码遵循语法规则(如匹配括号),但它并不知道代码在逻辑上是否合理(如除以零)。它提供的修复方案在语法上是正确的,但人类仍需检查它们是否真的正确。
- 它需要短片段: 系统在处理短于 80 个 token 的代码片段时效果最好。如果破碎的代码非常庞大,处理可能的修复方案列表将会变得过于沉重。
- 它不是魔法: 如果用户的错误距离正确代码超过 3 次编辑,或者代码片段过长,系统可能会完全错过该修复方案。
总结
作者认为,通过将严格的数学规则(以确保代码有效)与智能 AI(以猜测人类的意图)相结合,我们可以比单纯使用 AI 更快、更准确地修复代码。他们开发了名为 Tidyparse 的工具来证明这一点。虽然它并不是能修复所有可能编程错误的完美方案,但它表明,对于小型、常见的错误,这种“搜索并排序”的方法远优于单纯的“猜测”。论文结论指出,这种方法为程序员提供了更流畅的体验,帮助他们在没有被微小的拼写错误卡住的情况下,快速回到编码工作中。
您所在领域的论文太多了?
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要,使用您的语言。