Longtail-SWE：让小众编程语言进入代码智能体评测

导语

软件工程智能体的能力评测，长期集中在少数主流语言和热门开源生态中。这样的测试集便于构建，却难以回答一个重要问题：当任务涉及函数式语言、较小众的移动开发语言或成熟度不同的生态时，代码智能体是否仍能理解需求、定位问题并完成仓库级修改？Longtail-SWE 正是针对这一缺口提出的基准。

核心要点

• 覆盖 13 种代表性不足的语言。 数据集包含 Clojure、Dart、Elixir、Erlang、F#、Haskell、Julia、Kotlin、Lua、OCaml、R、Scala 和 Swift，覆盖函数式编程、科学计算、移动开发及多种通用语言生态。
• 任务来自真实软件工程场景。 基准包含 202 个 issue-resolution 任务，每项任务都关联 GitHub issue 与对应 pull request，并配有可执行环境和测试。评测对象不是孤立的算法题，而是需要在真实代码库中理解需求并修改代码的问题。
• 把测试质量纳入基准构建。 研究采用“solver—judge—repairer”流程：先让求解器尝试任务，再由评审环节结合任务描述、求解轨迹与测试结果检查问题，最后修订描述或测试。修订目标包括减少对合法替代实现的误判，也减少测试过于宽松而接受错误实现的情况。
• 同时关注能力、稳定性与成本。 项目评估九种模型配置，并分析不同模型反复尝试时的解决一致性和资源使用情况。此外，研究还发布一组更容易的任务，方便较小模型参与比较。
• 配套材料完整。 数据集、可执行环境、构建与评测工具，以及智能体轨迹均对外发布，便于复现实验、检查任务质量和开发新的评测方法。

意义与影响

Longtail-SWE 的价值不只是增加了几种编程语言，更在于把“语言覆盖不足”和“测试是否可信”放在同一个评测设计中。小众生态中的候选任务往往数量有限，任务描述模糊或测试缺陷会导致有价值的问题被提前淘汰；而完全依赖参考补丁的测试，也可能把一种实现方式误当成唯一正确答案。该项目尝试利用求解过程本身发现这些风险，再对任务进行修复，这为仓库级基准的质量控制提供了可复用思路。

对模型开发者而言，这类基准可以揭示模型在训练数据较少、工具链不同或语言范式变化时的泛化能力。对评测研究者而言，跨语言任务、重复尝试的一致性和资源使用等维度，有助于避免只看单次成功率。需要注意的是，素材只介绍了数据集构建方式与评测设置，并未给出九种模型的具体排名或整体性能结论，因此 Longtail-SWE 更适合作为开放的评测基础设施，而不是一个预先宣布胜负的排行榜。

来源：Hugging Face Daily Papers