**当AI编程助手遇到"老手带新手"的问题**
先起始于一个有着熟悉感的场景, 开始讲述。假定你身为一家公司的技术主管, 手下会有十个程序员, 是同时在处理同一个具备复杂性的系统漏洞的。且当每个人付出几个小时忙碌忙活之后, 你会采取怎样的做法呢? 你大致不会只是任性随意地选取一份上交给老板, 而是会去把所有人的工作记录都翻找出来, 查看究竟谁的思路最为清晰, 谁又到底踩了哪些方面的坑, 谁是那种快要靠近答案的状态, 接着综合这些详尽而细致的信息, 要么挑选出最佳状态的那份, 要么促使他们彼此之间相互借鉴参考, 然后再来开启一轮攻克漏洞的操作实施。
这一场景, 恰是此篇论文力图解决的关键问题。只是此处的“程序员”被替换成了AI, 并且那个“系统漏洞”被替换成了GitHub上切实存在的代码问题。研究团队想要弄明白: 当一个AI编程助手能够多次尝试去解决同一个问题时, 究竟怎样才可以让后续的尝试切实比先前的更为聪慧, 而非仅仅是以另外的方式重蹈覆辙?
**一、为什么这个问题比想象的难得多**
有一个在过去几年里于AI领域颇为流行的做法被称作“测试时扩展计算”, 简单来讲就是, 当AI回答问题之际, 并非匆忙仅给出一个答案, 而是使其多思考几次, 随后从之中挑选出最为优质的那个。此方法在诸如数学解题、撰写短文这类任务里成效颇佳, 因答案相对简短, 极易比较出哪一个更为出色。
但AI编程助手所做的工作并非如此这般。当AI助力人们修复一个实实在在的代码错误之际, 它所要开展的工作绝不仅仅是写下几行代码而已。它得先是透彻领会整个代码仓库的架构, 寻觅到有可能出现问题的文件, 运行相关命令进行全面测试, 瞅见了报错信息方可进行相应调整, 其过程就如同一位实打实的程序员坐在电脑跟前开展工作那般。像这样的一整套完整工作流程, 研究团队将其定义为一次特定的“轨迹”（rollout）。
一次轨迹或许包含几十步操作记录, 甚至七八十步操作记录。你能够将它想象成程序员一份完整全天工作记录情况, 其中有他查看过哪些文件, 执行过哪些命令, 看到并观察到了什么样输出, 又做出了哪些决定。如此一类工作记录, 其含有内容庞杂到了极点, 阅读起来相当耗费精力, 并且还充斥着数量众多重复终端输出情况, 以及死胡同之类属于探索范畴低价值信息。
正因为是这样, 用于短答案设计的那套“多选一”办法根本就没办法使用起来。你没有办法把两个长度达到几千行的工作日志丢给AI讲“帮我对比一下哪一个更好”, 因为AI自身也会被那一堆噪音给淹没, 导致判断出现偏差。更不要说把一个程序员的工作记录提供给另一个程序员, 让他从中去学习思考“下次该如何改进”——那得阅读多长时间呢?
这便是研究团队所发觉的核心阻碍, 对于AI编程助手而言, 测试期间多次去尝试的瓶颈并非是“尝试的次数尚未足够多”, 而是“究竟要怎样将先前的尝试转化为切实有用的信息”！
**二、解题思路：给每次尝试写一份"精华摘要"**
倘若问题在于“原始记录呈现出极为杂乱、冗长的状态, 以至于难以进行相互比较以及再次使用”, 那么解决方案便清晰可见了: 针对每一次的尝试撰写一份具备结构性的精简要点概述。
研究团队促使AI, 在每一回达成一轮工作之后, 将那份繁杂冗长的工作日志, “凝练提取”为一份简洁的结构化文档。这份文档会记述此次尝试的核心假设是怎样的, 做了哪些重要决定, 获取了哪些进步, 又于何处陷入困境, 失败的缘由或许是什么。一切杂乱无章的终端输出、重复的文件读取操作, 全部省略不计。
这一做法听着简单, 然而却是整个研究的根基所在。有了这份摘要, 原本两件极难的事情变得可行起来: 其一，将多份摘要相互比对, 判定哪次尝试质量更优；其二, 把高质量的摘要当作“经验”提供给下一轮尝试, 使AI在开启新一轮工作之前便能站在前人的基础之上。
存在两件事情, 恰好对应着研究团队所设计的, 是两个核心方法, 其中一个被称作“递归锦标赛投票”, 另外一个被称作“并行蒸馏精炼”。
**三、从混战到决赛：递归锦标赛投票的工作方式**
取足球联赛来作类比, 若你来从32支球队当中去选出冠军, 不会让所有球队同时进行一场混战, 而是先分成组, 每组选出一个获胜者, 再让这些获胜者相互去对抗, 一轮一轮进行淘汰, 一直到最后决出冠军。这个过程称作是“锦标赛制”。
这个思路便是研究团队所设计的“递归锦标赛投票”（RTV）。倘若AI针对同一个编程问题进行了16次独立尝试, 那么首先要将16份摘要两两进行配对。接着让AI当作“裁判”去阅读这两份摘要, 进而判断哪一次尝试更有成为正确解法的可能性。每对摘要的比较并非只做一次判断, 而是要重复进行8次判断。随后依据少数服从多数的原则选出胜者, 如此一来能够减少单次判断所产生的偶然误差了。第一轮比较完毕之后, 16次进行尝试的变为8次成为胜者, 而后接着两两相互对比, 8次变成4次, 4次变成2次, 2次变成1次, 最终挑选出在整个群体之中质量最为高的那次尝试。
为何运用两两对比, 而非径直将所有摘要一次性给予AI并说“挑选最佳的”呢? 研究团队开展了一项饶有趣味的实验, 专门对不同“组大小”的效果予以比较。结果发觉, 两两对比（每组两份摘要）的效果显著超越四选一、八选一、十六选一。缘由其实并不难领会: 当着你一并展开比较的候选项越多。所包含的信息量越大, 裁判反倒越易于由于信息过多而致使判断失误；而两两对比, 此任务简洁明了。判断的质量自然而然会更高。
与此同时, 实验有新发现, 即投票次数愈多, 最终结果愈稳定, 从仅投一次票至投16次票, 效果持续增进, 不过在8次投票之后, 提升幅度开始有所减缓, 所以最终方案确定为每组比较投8次票。
单独运用这个方法之时, 效果已然颇为可观: 针对SWE - Bench Verified此一测试平台（其中皆为GitHub上真实的代码问题）, Claude - 4.5 - Sonnet的平均解题率由67.4%提升至73.6%；针对另一个名为Terminal - Bench v2.0的测试平台（专门用以测试在命令行环境里解决复杂任务的能力）, 同一个模型的得分从40.6%跃升为54.6%。仅靠"选得更准"这一件事，提升就如此显著。
**四、站在前人肩膀上：并行蒸馏精炼的运作逻辑**
仅仅“选得准”是远远不行的。研究团队怀揣着更为野心勃勃的念头, 那便是: 后来的AI可否不仅仅是在前辈们的成果当中挑选其一, 而是切实能够从前辈们的经验里汲取到东西, 进而在下一次做得比前辈们每一次做得都更为出色呢?
在这个过程当中, 一个研究团队, 对一个已经存在的方法的框架进行了借助, 并且进行了改造, 从而将其称呼为“并行蒸馏精炼”（PDR）。
具体来讲, 第一轮的时候, 要让AI去做16次独立的尝试, 在每次尝试终结之后, 都会生成一份精华摘要出来。紧接着, 运用上一节所介绍的锦标赛办法, 从中挑选出质量最为高的4份摘要, 把它们当作“经验材料”。而后, 开启第二轮尝试, 同样是16次, 不过这次在每次尝试开始以前, AI会先去读那4份精华摘要, 弄清楚前人究竟发现了什么、踩了哪些问题重重的坑、最具希望的方向究竟是哪里, 之后再在全新的、毫无杂质干净的环境里着手展开工作句号。
有一个细节是值得特别去留意的, 第二轮的每次尝试都是于“新环境”之中开启的, 并非在第一轮所留下的半成品代码之上延续, 这恰似一位程序员阅读完同事的工作笔记后, 自行从起始处着手去做, 而非顺着同事编写了一半的代码继续编写, 为何要如此去做呢, 是由于第一轮留下的半成品代码或许方向已然有误, 又或者已将某些东西改坏了, 要是继续在上面进行修改, 极有可能会越改越杂乱. 从起始处开始, 反倒会更为简洁。
出于弄明白“读几份前人摘要最为合适”的目的, 那支研究团队特意对三种做法做了比较, 这三种做法分别是, 仅仅阅读自己上一回的摘要, 随机抽取4份摘要加以阅读, 运用锦标赛方式挑选出最优的4份来阅读。其结果相当明晰, 阅读多份摘要远比只读自身那份强得多。拿Gemini-3.1-Pro来说, 只读自己的一份时, 第二轮平均解题比率仅从72.7%提升至73.8%, 提升幅度极小；换成随机选4份来读, 提升到了76.9%；再通过锦标赛选取出最好的4份来读, 竟然达到了79.3%。
揭示了这样一个道理: 这个结果, 很有意思, 即精华摘要质量, 直接决定下一轮 AI 能学到多少东西。研究团队进一步做了更细致分析, 按“提供的 4 份参考摘要里有几份是来自成功解题的尝试”对所有任务分组, 然后看每组里第二轮的平均解题率。极为规律的结果呈现是, 当参考摘要里不存在任何一份成功实例的时候, 第二轮解题的比率趋向于零, 当存在一份成功实例的时候求解比率大约是33%, 当存在两份成功实例的时候求解比率约为55%, 当存在三份成功实例的时候求解比率约为85%, 当全部四份均为成功案例时新一轮中求解准确率高达99%以上。
这表明成功的经验自身就是最为出色的老师。要是你读的皆为失败记录, 即便写得极为详尽, 也极度难以实现突破；但只要能够看到一些成功的实例, 再繁杂的问题都存有被复现以及超越的希望。
**五、把两个方法合而为一：完整的工作流程**
两种方法各自具备不同优势: 一方面, 锦标赛式投票拥有在众多候选方案当中精准挑选的能力；另一方面, 蒸馏精炼有着促使人工智能表现更为出色的本事。将这二者予以融合, 便构建起了研究团队的完备方案。
整个流程是按照四步来进行的 , 第一步是针对同一个编程问题去实施连续16次独立的尝试。而在每次尝试做完的时候 , 均要为其去打造生成精华摘要 , 第二步是采用锦标赛投票的形式从16份摘要里挑选出4份质量是最高的 , 将这4份作为" 精选经验库", 第三步需要依据这4份精选摘要 , 开启16次新的尝试 , 每次尝试都要先去阅读这4份摘要 , 接着在新环境里从最开始的部分开展工作。第四步是针对第二轮的16次尝试再次进行一次锦标赛投票 , 从其中筛选出最终答案。
这个流程于“开发”和“探索”之间维系了一种难以察觉的平衡, 一方面, 借由锦标赛挑选出4份最为出色的摘要, 这属于“聚焦”, 即将注意力汇聚于最具潜力的方向之上；另一方面, 第二轮依旧进行16次独有的尝试而非仅开展1次, 这是在“保持多样性” —— 不同的尝试或许会从4份摘要当中获取各异的灵感, 探寻出风格各不相同的解题途径, 后续通过最后一轮锦标赛筛选出最终答案。
**六、实验结果：数字背后的真实意义**
研究团队在两个测试平台上, 开展了对于Claude - 4.5 - Opus、Gemini - 3.1 - Pro、Claude - 4.5 - Sonnet、Gemini - 3 - Flash以及GPT - 5 - 0825这五个不同顶尖AI模型的全面测试, 其中一个测试平台是SWE - Bench Verified（包含500道真实GitHub代码问题）, 另一个测试平台是Terminal - Bench v2.0（包含88道复杂命令行任务）。
结果于所有的模型之上, 皆展现出了一致的增进趋向。将Claude - 4.5 - Opus当作例子, 在SWE - Bench Verified里, 仅仅一次尝试时的解题比率为70.9%, 历经完整的方法处置之后就达到了77.6%, 增进了大约6.7个百分点；于Terminal - Bench v2.0上, 从47.0%提升至59.1%, 提升的幅度超过了12个百分点。Gemini-3.1-Pro, 在一个平台上, 提升程度是从百分之七十二点三提升到百分之七十六点六, 在另一个平台上, 提升程度则是从百分之五十二点五提升到百分之六十四点八。
通常情况下, 不同模型于Terminal - Bench v2.0上的提升幅度, 要比对SWE - Bench Verified得到的提升幅度普遍更大, 这和两个测试平台各自具备的任务特性存在关联, Terminal - Bench v2.0的任务难度相对更大, 并且解题路径之间的差异性也更大, 所以经由多轮尝试以及经验积累所取得的收益也就更显著。
有一组数据格外值得予以关注, 研究团队发觉, 开展第二轮16次相关尝试期间, 平均所需的操作步数, 仅仅约为第一轮的一半左右。以Claude - 4.5 - Opus作为例子来讲, 在SWE - Bench Verified方面, 第一轮平均为41步, 而到了第二轮就下降到了14步；在Terminal - Bench v2.0上边初始为24步, 第二轮时降到了12步。这表明, AI在阅读完前人的精华摘要以后, 对于整个代码库的结构, 对于问题所在的位置, 对于最有可能奏效的解法, 都有了更为清晰的认知, 无需再去做那些类似“摸黑探路”般的操作, 而是能够更为直接地迈向答案。效率近乎翻倍, 并且成功率也同步提升, 这是一个会收到双赢效果的结果。
**七、那些原本无解的题，也被做出来了**
研究团队, 将一组, 特别有意思的发现, 称作"新解法发现"。这是指, 某个AI模型, 在第一轮的16次独立尝试当中, 所有尝试均以失败告终；然而, 在第二轮, 也就是读完前人失败摘要之后所进行的第二轮尝试里, 成功解决了此问题。
Terminal - Bench v2.0上, 这般情形总共出现了13个任务。以Claude - 4.5 - Opus来说, 它在第一轮的时候, 完全没办法解出“gpt2 - codegolf”这道题目（这道题要求用不超过5000字节的C语言代码去实现GPT - 2语言模型的文字生成）, 然而在第二轮, 等读完了前四次失败尝试的摘要以后, 成功写出了一个3467字节、能够正确运行的C程序。
再更极端些的是“large-scale-text-editing”这道题目, 于研究测试的五个模型之内, 第一轮的时候, 居然没有任何一个模型能够成功去完成这个任务, 然而, Gemini-3.1-Pro 在第二轮的时候, 读过了自己四次失败尝试的摘要之后, 成功把它给解决掉了, 这就意味着, 借助让 AI 从自身失败当中“提炼经验”这事, 可以开启原本超出其能力范畴之外的任务。
对此背后之中的机制, 研究团队开展了定性分析。就“sparql - university”任务来讲, 第一轮历经四次尝试, 结果均告失败, 然而在这四次里边, 有一回察觉到了关键规律所在: 欧盟国家的条件以及学生人数超过10人的条件, 并非需要同时满足同一个系, 而是属于两个相互独立的条件。第二轮时, AI阅读了这个摘要, 随后直接将此关键发现写入了自身的解题策略当中, 最终成功把问题给解决掉了。
**八、精华摘要究竟好在哪里：与原始记录的对比**
研究团队并非仅仅提出了这个方法, 还特意针对一个核心假设进行了验证, 这个核心假设是, 究竟是精华摘要更佳, 还是直接采用原始工作日志效果也大致相当?
结论相当确然: 精华摘要于每一种场景状况下均胜过原始日志。于锦标赛投票阶段之时, 以摘要来做比较的最终解题率向来高于径直比较原始日志的方案, 并且此优势在越臻于后期的比较轮次里越显著, 缘由乃在于越到末尾, 剩余的候选方案间差异越发细微, 所需进行针对细节更为敏感的比较, 此时原始日志当中充斥的噪音便成了巨大的干扰因素, 而摘要却能够精准地呈现出差异之所在。
这个发现为研究团队的核心论点提供了支持, 那就是**"信息表示", 而非"计算量", 才是AI编程助手在测试时, 影响扩展计算能力的关键问题所在**！同样的计算预算下, 最终收益大小是由信息表示与传递经历的形式来决定的。
**九、锦标赛裁判本身的准确性**
研究团队另外做了一件事情, 这件事情是衡量AI在充当“裁判”时候的判断准确程度, 具体的方法是, 从所有涵盖“有成功尝试以及有失败尝试”的对比组当中, 统计AI实际挑选出成功那一方的比例。
结果呈现出来, 表明在Terminal - Bench v2.0之上的判断精准率通常是高于SWE - Bench Verified。研究团队剖析觉得, 之所以如此, 是由于SWE - Bench的任务诉求在于判定代码变动的些微差别以及被隐匿的测试实例, 然而Terminal - Bench的任务在命令行输出当中存在更直观可察觉到的成功或者失败的依据, 所以裁判进行判断会更为容易。
从总体看来, 各个模型的裁判准确比率大概是处于六十%至八十五%的范围之内。这个数值表明的是, 虽说 AI 裁判具备有效性, 然而并非十全十美——尚且存有能够改进的余地。研究团体同样指出, 在将来的时候, 能够专门针对“达成组间比较判定”此项事宜来对 AI 开展专项训练, 又或者引入专门的裁判模型, 这些做法都极有可能进一步提升成效。要特别指出的是, Gemini - 3.1 - Pro在充当裁判之际, 其准确率相对而言偏低, 这致使它于最后一轮锦标赛投票里的提升幅度, 相较于其他模型更小, 第二轮平均解题率是76.2%, 最终所选答案的解题率为76.6%, 提升幅度仅仅0.4个百分点。
**十、这项研究打开了一扇新的大门**
终究而言, 这篇论文所表达的内容实则能够以一言蔽之: 就AI编程助手来讲, 使其“进行更多回的尝试”是具备价值的, 然而价值的具体程度全然取决于你怎样去运用那些尝试所留存的信息了。最初的工作日志杂乱无章、篇幅冗长且极难再度利用；可是经过提炼的精粹摘要, 却能够摇身一变成为极为有效的“经验传承”媒介——不但能够用以更为精准地挑选出优质方案, 还能够用来助力下一轮尝试起点更上一层楼。
研究团队也坦率表示, 这套方法此时此刻存在显著的局限性, 精华摘要保存的是对以往尝试的文字叙述, 并非那些尝试期间实际生成的代码产物、测试脚本或者调试工具。研究团队给出了一个有吸引力的未来方向, 即能否使AI不祇是在全新环境里从起始点着手运作, 而是切实承接前一轮次尝试里产生的那些具有价值的中间成果, 比方说撰写了半数的补丁、创建的测试用例句、编写的调试工具? 要是能够达成这事儿 ， “ 从前人的经验里学习 ” 并不只是阅览一下笔记 , 而是切实接过前人手上的工具等 , 也就是站在前人挖好的坑的旁边持续往下挖掘了。
---
Q&A
疑问一: SWE - Bench Verified究竟是什么东西, Terminal - Bench v2.0又是什么玩意儿, 并且它们之间存在着怎样的区别呢?
A说, 这是用于评测AI编程助手能力的两个测试平台, SWE - Bench Verified收录了GitHub上的真实代码缺陷修复任务, 有500道之多, 考察了AI能不能如真实程序员那样去定位以及修复代码库当中的问题。Terminal - Bench v2.0收录了88道复杂的命令行任务, 这些任务更侧重于考察AI在真实终端环境中处理系统级任务的能力。其任务难度普遍更高, 解题路径变化也更大。所以在这个平台上, 经过多轮改进带来的提升幅度更显著。
问题2: 递归形式的锦标赛里的投票为何要采用两两相互对比的方式, 直接一次性将所有对象全部放在一起进行比较难道不行么?
研究团队针对“每组比较几份摘要”所产生的效果专门做了测试, 其得出的结论为, 候选项越少, 比较质量便越高。当把所有摘要一同扔进来进行比较时, AI裁判所面临的信息量过于庞大, 进而容易造成判断失准的情况；然而每次仅较量两份, 此项任务简单且明确, 裁判的准确率会更高。多轮那种两两淘汰的总体效果, 显著优于一次性的大比例比较。除此之外, 每次比较还通过重复投票8次以取多数这一方式, 进一步削减了单次判断期间出现的偶然误差, 使得最终挑选出的结果更加可靠。
第三个问题: 为什么并行蒸馏精炼不允许人工智能直接在第一轮生成的代码基础上面继续进行修改、完善进而延续下去, 而是要从最开始的起点着手开始重新来过呢?
A: 由于第一轮留存下来的半成品代码自身或许就存在问题, 解题的方向有可能出现错误, 又或者是已经将某些部分改坏了。在存在错误的代码根基上持续进行修改, 极有可能会越改越混乱。从一开始做起, 让人工智能在阅读完前人的精华摘要之后, 把对于问题的理解以及最具希望的解法方向带入到全新的工作环境当中, 反而能够更加干净、更加高效地寻得正确的答案。实验的结果同样支持此种判断: 第二轮从一开始便进行的尝试平均仅仅需要第一轮大约一半的操作步数。
