[Paper] 神经符号 仓库级代码定位

Source: arXiv - 2604.16021v1

概述

论文 “Neurosymbolic Repo-level Code Localization” 揭示了当今代码定位基准中的一个隐藏缺陷：这些基准充斥着明显的关键词线索（文件名、函数标识符），使模型能够通过简单的字符串匹配作弊。为了推动模型进行真正的结构推理，作者提出了 Keyword‑Agnostic Logical Code Localization (KA‑LCL) 挑战以及一个新的基准 KA‑LogicQuery，它去除了所有命名提示。他们提出的解决方案 LogicLoc 将大型语言模型（LLMs）与 Datalog 的确定性能力相结合，在使用更少的 LLM 令牌的情况下，实现了准确且可验证的定位。

关键贡献

• 识别“关键词快捷键”偏差 在现有的基于问题的代码定位数据集中。
• 形式化 KA‑LCL 并创建 KA‑LogicQuery 基准，迫使模型推理程序结构而非词汇线索。
• LogicLoc 框架：一个神经符号流水线，(1) 从代码库中提取事实谓词，(2) 使用 LLM 合成 Datalog 规则，(3) 通过解析器门控检查和基于变异的诊断验证并细化这些规则，(4) 在高性能推理引擎上执行已验证的 Datalog 程序。
• 实证证据 表明，最先进（SOTA）仅 LLM 方法在 KA‑LogicQuery 上出现灾难性性能下降，而 LogicLoc 恢复了高准确率。
• 效率提升：LogicLoc 在传统基准上实现了可比或更好的结果，且 显著降低了 token 使用量 并 加快了端到端延迟，因为结构遍历被卸载到确定性引擎。

方法论

1. 基准构建 (KA‑LogicQuery)

   • 精选了一组真实世界的问题，这些问题的目标代码无法仅凭文件路径或函数名推断。
   • 每个查询都需要对控制流、数据流或 API 使用模式进行推理（例如，“找到打开套接字并写入 JSON 的方法”）。

2. 神经符号流水线 (LogicLoc)

   • 事实抽取：静态分析前端解析整个代码库，生成 Datalog 事实，如 calls(MethodA, MethodB)、defines(ClassX, MethodY)、usesVar(MethodZ, VarV)。
   • LLM 提示：将自然语言的问题描述连同一个 模板 一起输入大型语言模型（如 GPT‑4），模板要求模型生成捕获所需逻辑约束的 Datalog 规则。
   • 解析器门控验证：首先检查生成的规则是否符合语法；语法错误的规则在执行前即被拒绝。
   • 基于变异的诊断反馈：系统对规则的部分内容进行变异（例如翻转谓词），观察对结果集的影响，并向 LLM 提供具体的反例，以便其细化程序。
   • 确定性执行：规则通过验证后，在优化的推理引擎（如 Soufflé）上运行，生成满足逻辑查询的精确源码文件/方法集合。

3. 评估

   • 在 KA‑LogicQuery 以及标准的 issue‑驱动数据集（如 Defects4J、CodeSearchNet）上，将 LogicLoc 与领先的仅 LLM 基线（如 Codex、GPT‑4）进行比较。
   • 测量 准确率、令牌消耗 和 实际运行时延。

结果与发现

• 灾难性下降：当关键词提示被移除时，SOTA LLM 的表现骤降至接近随机，证实它们高度依赖词汇捷径。
• LogicLoc 的恢复：通过将结构化推理委托给 Datalog，LogicLoc 在困难基准上实现了超过 3 倍的准确率提升。
• 效率：由于 Datalog 引擎以确定性方式处理图遍历，LLM 只需生成简洁的规则片段，从而大幅削减标记使用量和推理时间。
• 鲁棒性：在仍包含关键词提示的常规基准上，LogicLoc 仍保持竞争力，表明神经符号方法在存在词汇线索的情况下并未牺牲性能。

实际影响

• 更可靠的自动调试：能够建议导致错误的文件或方法的工具现在可以基于更深层的程序语义工作，减少因名称巧合导致的误报。
• 可扩展的代码搜索：企业可以使用符号事实对海量代码库进行索引，并按需运行逻辑查询，使开发者能够定位复杂模式的实现（例如，“所有验证 JWT 令牌的地方”）。
• 降低云成本：通过显著削减 LLM 令牌消耗，LogicLoc 使大规模代码定位服务的运行成本更低，尤其是在需要每日处理数千个工单的 CI/CD 流水线中。
• 可解释性与审计：生成的 Datalog 规则作为明确的、可读的人类规范，说明为何选择特定代码片段，便于合规审查和知识转移。
• 混合 AI IDE 的基础：IDE 扩展可以将 LLM 驱动的自然语言辅助与确定性的符号后端相结合，提供创造力与正确性兼具的体验。

限制与未来工作

• 静态分析依赖：LogicLoc 的事实提取依赖于准确的解析；具有动态特性的语言（例如 JavaScript 的运行时 eval）可能导致事实不完整。
• 规则合成复杂度：虽然 LLM 能处理大多数情况，但极其复杂的逻辑约束仍可能生成格式错误的 Datalog，需要更复杂的反馈回路。
• 基准范围：KA‑LogicQuery 虽经精心策划，但覆盖的推理模式有限；需要更广泛的基准（例如跨语言或多仓库查询）来全面评估通用性。

未来方向

• 将事实模型扩展以捕获运行时信息（例如类型推断、污点分析）。
• 融入强化学习，使 LLM 能基于执行结果迭代改进规则生成。
• 探索其他符号引擎（例如 Prolog、SMT 求解器）以实现更丰富的约束域。

作者

• Xiufeng Xu
• Xiufeng Wu
• Zejun Zhang
• Yi Li

论文信息

• arXiv ID: 2604.16021v1
• 类别: cs.SE, cs.AI
• 发布日期: April 17, 2026
• PDF: 下载 PDF