发表机构
Toronto Metropolitan University; Flybits（多伦多都会大学; Flybits）
机构由 AI 辅助整理，请以论文原文为准。AI 中文总结
针对Python依赖冲突导致代码执行失败的问题，提出混合流水线PLLM+，优先采用确定性重放与验证，必要时回退到LLM修复；在HG2.9K基准上解决1,500/2,891个片段，平均耗时从368.7秒降至71.8秒。
AI 中文摘要
Python生态系统中的依赖冲突源于不兼容的版本约束、缺失的包以及未记录的兼容性关系，导致许多真实世界的代码片段在执行时失败。本文提出了PLLM+，一种混合依赖修复流水线，并在包含2,891个依赖失败片段的HG2.9K基准上进行了评估。PLLM+在调用基于LLM的修复之前，优先采用成本较低的确定性步骤：基于静态AST的解释器推断、从竞赛提供的解决方案数据库中重放历史上成功的依赖配置，以及对候选包版本进行实时PyPI验证。当这些步骤未能解决某个案例时，系统会回退到结构化的基于LLM的修复循环，该循环包含类型化错误分类和Proposer/Critic智能体。在HG2.9K上，PLLM+解决了2,891个片段中的1,500个，而PLLM基线解决了1,169个。它还将每个片段的平均运行时间从368.7秒减少到71.8秒。大多数成功的修复来自重放已知配置：1,500个成功修复中有1,495个由解决方案数据库产生，而LLM回退则额外贡献了5个修复。这些结果表明，在此基准设置中，确定性重用先前验证的依赖配置是一种简单有效的策略，而基于LLM的修复则作为次要回退，用于处理先前解决方案未覆盖的情况。
英文摘要
Dependency conflicts in Python ecosystems arise from incompatible version constraints, missing packages, and undocumented compatibility relationships, causing many real-world code snippets to fail at execution. This paper presents PLLM+, a hybrid dependency-repair pipeline evaluated on the HG2.9K benchmark of 2,891 dependency-failing snippets. PLLM+ prioritizes inexpensive deterministic steps before invoking LLM-based repair: static AST-based interpreter inference, replay of historically successful dependency configurations from the competition-provided solutions database, and live PyPI validation of candidate package versions. When these steps do not resolve a case, the system falls back to a structured LLM-based repair loop with typed error classification and Proposer/Critic agents. On HG2.9K, PLLM+ solves 1,500 out of 2,891 snippets, compared with 1,169 solved by the PLLM baseline. It also reduces average runtime from 368.7 to 71.8 seconds per snippet. Most successful fixes come from replaying known configurations: 1,495 of the 1,500 successful fixes are produced by the solutions database, while the LLM fallback accounts for 5 additional fixes. These results suggest that, in this benchmark setting, deterministic reuse of previously validated dependency configurations is a simple and effective strategy, with LLM-based repair serving as a secondary fallback for cases not covered by prior solutions.
