LongCodeBench: Evaluating Coding LLMs at 1M Context Windows

模型的上下文长度在过去几年中迅速增长，从几千个标记扩展到数百万个标记。现代长上下文模型的极端上下文规模使得构建现实的长上下文基准变得困难，这不仅是因为收集百万级上下文任务的成本高昂，还因为在现实中找到需要如此大规模上下文的应用场景也颇具挑战。我们确定代码理解与修复是长上下文模型的一个自然测试领域和挑战任务，并引入了 LongCodeBench (LCB)，这是一个用于测试大语言模型在长上下文场景中编码能力的基准。我们的基准通过从真实的 GitHub 问题中提取数据，构建了问答任务（LongCodeQA）和修复漏洞任务（LongSWE-Bench），从而测试长上下文语言模型在现实且重要的环境中的理解和修复能力。我们精心对基准的复杂性进行了分层，从而使我们能够评估不同规模的模型，范围涵盖了从通义千问2.5 14B 指令模型到谷歌的旗舰 Gemini 模型。我们发现，对于所有模型而言，处理长上下文仍然是一个弱点，例如 Claude 3.5 Sonnet 的性能从 29% 下降到 3%，而通义千问2.5 的性能则从 70.2% 下降到 40%。

论文试图解决长上下文模型（Long-Context Language Models, LCLMs）在实际应用场景中的表现评估问题，特别是针对代码理解和修复任务。这是一个新问题，因为随着模型上下文长度从数千扩展到数百万标记，构建现实的长上下文基准测试变得困难。

论文提出使用代码理解和修复作为长上下文模型的自然测试平台，并引入了名为LongCodeBench（LCB）的基准测试。该基准通过从GitHub问题中提取真实场景，设计了问答（LongCodeQA）和漏洞修复（LongSWE-Bench）任务，用于评估模型在不同复杂度下的性能。相比现有研究，这篇论文首次系统性地将代码领域与长上下文建模结合，填补了这一空白。

1. 提出了一个分层的复杂度设计，能够评估不同规模模型（如Qwen2.5、Gemini等）在长上下文任务中的表现；2. 使用真实的GitHub数据构建任务，确保了任务的实用性和挑战性；3. 发现所有模型在长上下文任务中仍存在显著弱点，例如Claude 3.5 Sonnet和Qwen2.5的性能大幅下降；4. 数据集和任务设计开源，为未来研究提供了基础；5. 值得继续研究的方向包括改进模型对超长上下文的理解能力以及探索更多实际应用场景。

最近的相关研究包括：1.《Evaluating Long-Context Understanding in Large Language Models》探讨了长上下文理解的通用方法；2.《LLaMA-Adapter: Efficient Tuning of Language Models with Thousands of Tokens》研究了如何高效微调长上下文模型；3.《Scaling Laws for Autoregressive and Latent Language Models》分析了上下文长度对模型性能的影响；4.《CodeParrot: A Foundation Model for Code Generation》专注于代码生成的基础模型。这些研究共同推动了长上下文建模和代码处理技术的发展。