LoCoDiff

AbanteAI 推出了一项新的长上下文评估基准——LoCoDiff，专为衡量大模型在真实代码演化场景下的上下文处理能力而设计。

不同于依赖人工构造或填充文本的测试方式，LoCoDiff 直接从真实 Git 提交历史中提取数据，要求模型根据完整的变更记录，推理出目标文件的最终状态。这一任务模拟了开发者在阅读代码历史、理解重构过程或解决合并冲突时的实际挑战。

为什么需要一个新的长上下文基准？

当前许多长上下文能力的评估，往往基于合成数据或简单问答任务，难以反映模型在复杂软件工程任务中的真实表现。LoCoDiff 的设计目标是：

• 使用自然关联的内容：所有上下文来自真实项目的 Git 提交历史，语义连贯且具有实际意义。
• 无冗余信息：每一项提交差异都可能影响最终结果，不存在“可忽略”的上下文片段。
• 考察关键编码技能：重点测试模型对文件状态的持续跟踪能力——这是编码代理能否可靠工作的核心。
• 输出可验证、提示易生成：输入为标准 git log 输出，输出为具体代码文件，匹配精度可通过字符串完全比对判断。
• 支持长输出生成：部分任务需模型生成数百行代码，考验其结构化输出稳定性。
• 程序化构建能力强：任意 Git 仓库中的任意文件均可转化为测试用例，扩展性强。

值得一提的是，LoCoDiff 的全部代码、提示生成、实验运行、网站搭建及 GitHub 页面部署，均由 AbanteAI 开发的编码智能体 Mentat 独立完成。这本身也验证了该基准对自动化开发流程的支持能力。

核心发现：模型在长上下文中表现远未成熟

我们在多个主流大模型上运行了 LoCoDiff 基准测试，涵盖不同架构、推理模式与上下文长度（从几千到数万 token），得出以下关键结论：

1. 上下文越长，性能急剧下降

• 当提示长度低于 5k token 时，部分模型准确率接近 100%；
• 到 10k token 时，多数模型已出现明显退化；
• 达到 25k token 时，所有模型准确率均低于 50%。

我们最初设想用此基准探索百万级上下文窗口的潜力，但现实是：现有模型连 25k 的有效利用都尚未达标。

2. Claude 3.7 Sonnet Thinking 表现突出

在所有测试语言（Python、Zig、TypeScript、Rust、JavaScript）和上下文长度下，Claude 3.7 Sonnet Thinking 均取得最佳成绩。

尤其在长上下文场景中，它展现出更强的状态追踪能力——能够准确识别分支变更、合并冲突及其解决方案。这种能力正是优秀编码代理的关键特质。

3. 推理模型整体不如非推理模型

令人意外的是，在本任务中，“推理优先”模型并未体现出优势：

• DeepSeek Chat v3 优于 R1
• Gemini 2.5 Flash（非推理版）优于推理版
• GPT-4.1 优于 o3 和 o4-mini

唯一例外是 Claude 3.7 Sonnet Thinking，其推理版本显著优于非推理版本。这表明：并非所有推理机制都能有效分配计算资源，而 Sonnet 3.7 显然找到了更适合此类任务的策略。

方法详解：如何构建一次 LoCoDiff 测试？

每个测试用例的输入基于标准 Git 日志命令生成：

git log -p --cc --reverse --topo-order -- path/to/file

各参数含义如下：

• -p：显示每次提交的具体代码差异；
• --cc：展示合并提交相对于各父节点的双差异（diff against both parents）；
• --reverse：按时间正序排列（从最早到最新）；
• --topo-order：保证拓扑排序，父提交先于子提交出现。

这种方式确保模型接收到的是结构清晰、顺序合理的历史流，最大限度减少解析歧义。

数据集构成

基准包含 200 个文件，均匀分布于 5 个开源项目：

筛选条件：

• 近 6 个月内有修改；
• 最终文件大小 ≤ 12k tokens；
• 按目标提示长度均匀采样，最大不超过 100k tokens。

一个典型的 50k token 提示可能涵盖 50–150 次提交，涉及多分支演进与复杂合并逻辑，最终要求模型还原完整的最新代码。

所有测试用例、预期输出及模型响应均已开源，可供复现与分析。