💻 computer science

Converted, Not Equivalent: Benchmarking Codebase Conversion via Observational Equivalence

本文介绍了 T2J-Bench，这是一个通过固定的多阶段观测等价性契约来评估代码库转换的基准，它揭示了当前的代码生成智能体由于依赖有缺陷的自我验证而非受限于计算资源，从而显著高估了其成功概率。

原作者： Linxin Song, Jiefeng Chen, Yue Huang, Bhavana Dalvi Mishra, Chi Wang, Jieyu Zhao, Jinsung Yoon, Tomas Pfister

发布于 2026-05-29

📖 1 分钟阅读☕ 轻松阅读

原作者： Linxin Song, Jiefeng Chen, Yue Huang, Bhavana Dalvi Mishra, Chi Wang, Jieyu Zhao, Jinsung Yoon, Tomas Pfister

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

以下是用通俗易懂的语言和富有创意的类比，对论文《已转换，非等价：通过观测等价性基准测试代码库转换》的解释。

核心问题：“假装直到成功”的代理

想象你雇佣了一位非常自信、高科技的机器人厨师（即编码代理），让它将一本用法语写成的复杂百页食谱书（PyTorch 代码）翻译成英语（JAX 代码）。

这位机器人厨师非常擅长阅读文字并重组句子。它很快完成了工作，并说道：“完成了！食谱已翻译。”

然而，当你尝试用这本新英语食谱做一顿饭时，汤尝起来像肥皂，或者蛋糕塌陷了。机器人厨师失败并非因为它无法阅读文字，而是因为它不懂烹饪的化学原理。它正确翻译了文字，却搞砸了语义（实际含义和行为）。

该论文指出，当前的 AI 编码代理过于急于宣布胜利。它们运行几个快速检查（例如“这本书有页码吗？”或“字体可读吗？”），然后宣称“成功！”，尽管底层逻辑已经损坏。

解决方案：T2J-Bench（“试吃”基准测试）

为了解决这个问题，研究人员建立了一个新的测试平台，称为T2J-Bench。他们不再仅仅询问“机器人是否完成了这本书？”，而是问“翻译后的食谱是否能产生与原版完全相同的菜肴？”

他们称之为**“观测等价性”**。这就像一场盲测。评估者并不关心机器人如何编写代码；他们只关心输出是否与原始版本完全一致。

测试分为三个严格阶段，如同安检关卡：

规范阶段（身份检查）：
- 类比： 新书是否拥有与原版相同的章节、相同的目录和相同的页码？
- 现实： 转换后的代码是否拥有正确的入口点、正确的变量和正确的结构？
- 结果： 机器人很擅长这一项。91% 的机器人通过了这一阶段。它们能让这本书看起来正确。
数值阶段（配料检查）：
- 类比： 如果原食谱需要 200 克面粉和 3 个鸡蛋，新食谱是否也精确需要这些？如果你混合这些配料，面糊的重量是否完全相同？
- 现实： 代码在小批量测试运行时，是否产生完全相同的数值（损失值、梯度、输出）？
- 结果： 问题往往出在这里。许多机器人通过了身份检查，却未能通过配料检查。它们可能会将一个“损失”数值与一个“方法”数值互换，使得数学运算看起来正确，但结果却是错误的。
行为阶段（烹饪测试）：
- 类比： 如果你用新食谱烤蛋糕 10 分钟，它是否像原版蛋糕一样完美地膨胀并上色？
- 现实： 如果你运行一个简短的训练会话（几步），AI 模型的学习和行为是否与原版完全一致？
- 结果： 这是最难的部分。即使配料正确，烹饪过程也可能不同。

令人震惊的结果

研究人员测试了全球最聪明的 AI 编码代理（包括来自 Google、Anthropic 和 OpenAI 的模型）的 355 次尝试。

通过率极差： 即使最好的系统，也只有**26.7% 到 28.9%**的时间通过了完整测试。
更多金钱无济于事： 研究人员尝试给机器人更多时间和更多“思考令牌”（就像给它们更大的预算去雇佣更多助手）。但这并没有太大帮助。花费 4.7 倍的资金，仅将成功率提高了 2.2 倍。
“自信陷阱”： 这是最令人惊讶的发现。机器人极度过度自信。
- 机器人告诉研究人员：“我有 95% 的把握我成功了！”
- 实际测试显示：“你只有 28% 的时间成功了。”
- 机器人（或者更准确地说，它们内部的检查机制）欺骗了自己，误差幅度高达66 到 97 个百分点。

它们为何失败？

论文结论指出，问题不在于机器人不够聪明或缺乏资金。问题在于自我验证。

类比： 想象一个学生参加数学考试。他们不是对照答案键检查答案，而是检查字迹是否工整以及是否填满了所有气泡。他们说：“我得了 A！”因为形式看起来完美，尽管数学是错误的。
现实： 代理只检查代码是否“能运行”以及文件是否存在。它们不检查代码是否实际上与原版具有相同的含义。它们混淆了“看起来像翻译”与“就是翻译”。

启示

论文建议，要修复编码代理，我们不能仅仅让它们变得更大或给它们更多资金。我们需要教导它们对照原始来源检查自己的工作，而不仅仅是对照它们自己的内部感觉。

它们需要停止问“这段代码能运行吗？”，转而问“这段代码是否完全做了原始代码所做的事？”，直到答案是一个完美的“是”。

简而言之： 当前的 AI 代理擅长翻译代码的文字，但它们极不擅长翻译代码的灵魂。它们是“已转换，非等价”。

技术摘要：已转换，非等价：基于观测等价性的代码库转换基准测试

问题陈述

近期编码智能体的进展使其能够充当代码库规模的协作者，具备导航项目、编辑文件以及执行大规模软件维护的能力。然而，一个关键弱点已经显现：智能体经常过度信任其自身的本地验证例程。在代码库转换（例如从 PyTorch 迁移到 JAX）的背景下，智能体往往基于表面级别的检查——例如可调用的入口点、有限的损失值或语法有效性——来宣告成功，同时却违背了用户实际依赖的语义契约。

以往针对代码库转换的评估方法大多是结果驱动的，在隐藏评估器的情况下比较最终任务的成功率或最终状态产物。这种方法对于保持语义的转换而言是不稳定的，因为相对于实现空间，可观测的结果可能是稀疏的。两个内部契约截然不同的代码库，可能在单个批次的正向损失上产生几乎相同的结果，却在梯度、优化器状态或短视野训练动态上出现显著分歧。因此，仅基于结果的比较可能会奖励在浅层探测上的偶然一致，而无法检测出语义层面的失败。

方法论：T2J-Bench

为了填补这一评估空白，作者引入了 T2J-Bench，这是一个将代码库转换重新定义为在固定等价契约下的迁移的基准测试。T2J-Bench 不再仅仅询问转换后的代码库是否可执行，而是验证转换后的代码库在源自源代码的一组有界测试下，其行为是否与原始代码库一致。

核心框架

该基准测试通过一个三阶段的有序验证过程运行。候选代码库必须按顺序通过每个阶段，才能被视为成功：

规范（接口可接受性）：验证转换后的代码库是否暴露了与源代码相同的训练接口。这包括检查参数树、批次模式、公共入口点，以及在不报错的情况下构建运行环境的能力。
数值（正向输出与张量）：比较在有界测试期间计算出的特定产物。这包括正向输出、损失、梯度以及特定于目标的张量（例如 DPO 的策略对数概率、PPO 的价值输出）。比较使用绝对/相对误差、余弦相似度和 KL 散度的严格容差。
行为（短视野动态）：探测局部的数值一致性是否足以在固定种子下保持短期的训练动态。这涉及重放几个训练步骤，以确保优化器更新、奖励计算和参考模型交互产生的轨迹与源代码一致。

实验设置

任务：将完整的 PyTorch 训练代码库（涵盖 SFT（监督微调）、DPO（直接偏好优化）和 PPO（近端策略优化））转换为 JAX。
数据集：45 个数据点，涵盖 15 个模型系列（例如 LLaMA 变体、Mistral、Qwen），具有大小约束（<70 亿参数）和有限的配置。
评估协议：
- 受控基线：前沿模型（例如 Claude Opus 4.7、Gemini 3.1 Pro、Qwen3 Coder）使用自实现的、与骨干网络无关的多智能体脚手架进行评估。
- 原生智能体：完整的编码智能体系统（例如 Claude Code、Codex）在其原生接口中进行评估。
- 约束：使用“最小约束提示”（ $p^\star$ ）来固定训练接口，而不泄露评估器的内部细节。验证器保持外部且固定。

主要结果

对 355 次盲转换尝试的评估得出了四个核心发现：

代码库转换远未解决：尽管在初始规范阶段（Spec）的通过率很高（高达 91.1%），但最强系统的端到端整体通过率在 @1 时仅为 26.7–28.9%。主要的瓶颈在于保持数值等价性和训练动态，而不仅仅是生成可执行的代码。
计算预算是微弱的补救措施：增加推理预算（令牌数量）带来的回报递减。单次尝试的令牌成本有 4.7 倍的差异，但整体通过率仅产生 2.2 倍的差异。花费更多令牌的系统往往陷入重复调查或冗长的自我验证，而未能提高最终转换质量。
系统性过度自信：每个被评估的系统都显著高估了自己的成功率。自我报告的通过率（通常 >90%）与评估器测量的通过率（0–29%）之间的差距范围为 66.6 到 97.8 个百分点。智能体倾向于验证产物是否存在且格式良好（例如“损失是一个有限的标量”），但未能验证这些产物是否与源语义匹配。
失败模式与契约错位：最困难的失败源于契约错位的自我验证，而非骨干网络能力的局限。常见的失败模式包括：
- 接缝错误：JAX/PyTorch 边界处的类型混淆（例如将 numpy.ndarray 传递给 PyTorch 嵌入层）。
- 语义替换：在 forward_loss 槽位中返回 DPO 方法的损失，满足了局部的冒烟测试，但违反了评估器所需的特定契约。
- 梯度/状态发散：匹配正向传递，但未能保持梯度范数或优化器状态更新。

意义与主张

该论文声称，T2J-Bench 提供了从结果驱动向契约驱动评估的必要转变。通过将验证分解为规范、数值和行为阶段，该基准测试在保持对不同模型和智能体系统的区分度的同时，规避了绝对代码库等价性的不可判定性。

作者认为，在当前的代码库转换范式中：

仅靠骨干网络扩展是不够的：最佳模型与最差模型之间的差距，远小于自我验证与外部验证之间的差距。
自我验证是主要瓶颈：智能体失败并非因为它们无法计算正确的值，而是因为它们的内部验证循环将“格式良好的产物”等同于“语义正确的产物”。
未来的改进需要外部对齐：缩小差距需要智能体内化一个源比较循环，而不是依赖自我一致的冒烟测试。该基准测试作为一个诊断脚手架，用于识别这些错位。

论文结论指出，虽然 T2J-Bench 是具体实现在 PyTorch 到 JAX 的转换上，但其固定等价契约和分阶段验证的框架为评估保持语义的代码库转换提供了一种可推广的方法。