公开论文雷达

公开 arXiv 研究简报 · 2026-08-03T01:10:34.908530+00:00

先看结论和关键数字,再决定要不要读原文。候选只在首次出现时展示;旧候选若后来通过深读门槛,仍会进入重点。

八份卡片一个共识:模型输出要靠外部校验兜底

这八份卡片几乎都在做同一件事:不让LLM的输出直接算数,而是在模型和结论之间插一道机械校验——测试套件、Lean内核、Kani、校准沙箱或强制手工前置。差异在校验有多硬,以及证据披露得多实:有的给出可复算的修复数和F1,有的只报成功率、甚至不公开数值。想快速取用,先读揭示评测陷阱的三份。

推荐阅读顺序

  1. 2607.28587:先读:它证明基准本身会骗你,13.6%实例PR-Issue错对齐,读完才不会误信别家分数。
  2. 2607.26591:同样戳破只测单块高估能力,还给出协调者-提议者逐块修复架构,326/420修复数最硬可直接借鉴。
  3. 2607.27056:读它认清能力边界:显式事实好查,行为模式和人格特质逐层下滑,跨源抽象是当前硬短板。
  4. 2607.25970:方法论最完整的一份:讲清执行时间信号为何不可学,以及大输入+校准沙箱+门控奖励怎么修。
  5. 2607.21957:看闭环怎么防空洞规约:文档驱动+预检+Kani验证,别把'验证通过'当成规约有效。
  6. 2607.26306:把'代理不可信、内核兜底'做到极致,23合约全过但每个最高1亿token,读它权衡成本。
  7. 2607.28307:拿来即用的早期设计结论:少样本o3服务识别F1达0.97,但通信依赖过密须人工复核。
  8. 2607.28176:放最后:唯一的教育视角,五步脚手架把AI限定为辅助,但无对照组、不公开效果量。
共性方法
共同动作:都不信任模型的原始输出,而在模型之外挂一道校验来决定什么算数——测试套件、Lean内核、Kani、校准沙箱、专家盲评或强制手工前置。其中PAIChecker、Multi²Fixer、Setoka还顺带证明:沿用旧评测假设会系统性高估模型真实能力。
关键分歧
分歧在'校验有多硬'与'证据有多实'。硬端是机械可重放:Lean内核、Kani、测试套件给出确定验收;软端靠统计准确率、专家盲评甚至学生自我报告。证据披露也两极:RL优化、Multi²Fixer、微服务给可复算数值,EqiVM只报23全过不给失败率,TPACK不公开效果量。
选择准则
先按你能接受的错误代价选校验强度:formal场景(unsafe Rust/字节码)选内核级机械证明,工程修复选测试套件兜底,早期设计只当草案并人工复核。别用只披露成功率、无对照、不公开数值的结论去支撑高风险决策。

重点深读(8 / 8 篇)

形式化与程序验证(2 篇)

形式化与程序验证 5/30

Foundational Refinement Proofs for Deployed Bytecode, at the Price of Tokens

LLM驱动EVM字节码精化机械证明:在Lean中构建EqiVM框架,以前沿LLM为代理为任意来源EVM部署字节码自动生成逐合约精化机械证明,无需绑定源语言或编译工具链,对23个真实合约端到端验证成功,含以太坊主流稳定币系统组件。

两句看懂

已有EVM验证方案(已验证编译器、翻译验证器)分别牺牲通用性或完备性,均无法为任意来源部署字节码产出基础机械证明;本文用LLM代理在Lean框架EqiVM中自动为每合约生成精化机械证明。对23个以太坊真实合约(含主流稳定币合约主要组件)端到端验证全部成功,每合约最高耗费1亿token与100小时,证明经Lean内核机械重放验证。

核心判断

前沿LLM可为任意来源EVM部署字节码产出逐合约基础精化机械证明;23个真实合约(含主流以太坊稳定币合约)全部端到端成功,代价为每合约最高1亿token与100小时。

关键要点

1. 已有四类方案(已验证编译器、翻译验证器、携带证明代码、认证编译器)各自牺牲通用性、完备性或小可信基之一,均无法同时为任意来源字节码产出可重放基础机械证明,EVM审计被迫停留在启发式反编译器层。 2. EqiVM在Lean中形式化可执行EVM操作语义与规格语言,精化命题直接绑定部署字节码,未知代码调用纳入语义;LLM代理驱动逐合约证明搜索,Lean内核接受或拒绝,代理不被信任;23个以太坊主网真实合约(含主流稳定币系统主要组件)构成评估集。 3. 23个合约全部证明成功;每合约最高消耗1亿token与100小时,token成本为主要约束;字节码不可变性使证明终身有效;论文未报告失败案例或成功率分布,大规模批量适用性尚待验证。

证据与结果

评估集为23个以太坊主网真实合约,含主流稳定币系统大部分组件,字节码来源多样(不同Solidity编译器版本及手写汇编)。全部23个合约端到端证明成功;每合约最高消耗1亿token与100小时证明时间。证明可被Lean内核独立重放,无需信任证明代理。论文未提供失败案例数量或难度分层成功率,未与其他方法作定量比较。

打开论文原文
它要解决什么
前沿LLM能否为任意来源的EVM部署字节码自动生成可机械重放的精化证明,且不依赖特定编译器或源语言?
研究路径
EqiVM在Lean中定义可执行EVM操作语义与规格语言,精化命题直接针对部署字节码;LLM代理逐合约提交Lean证明脚本,遇阻则修复后重试;Lean内核机械验收,代理本身不被信任;未知代码调用作为语义一部分建模;最终产出可被Lean内核独立重放的机械证书。
这对工程意味着什么
对任意来源EVM字节码的高保证审计,可采用EqiVM框架配合LLM代理生成精化证书,替代依赖反编译器的人工审查;不应将Solidity源码层验证等同于对已部署字节码的保证。
证据定位
23个真实合约全部端到端证明成功,含以太坊主流稳定币系统大部分组件;每合约最高消耗1亿token与100小时,所有证明经Lean内核独立重放验证。(筛选维度:形式化验证)
适用边界
每合约最高1亿token与100小时的代价限制批量应用规模;评估集仅23个以太坊EVM合约,其他VM平台适用性未评估;论文未报告失败案例或成功率分布,难度边界不明确。
方法与英文摘要

作者在Lean中构建EqiVM,含可执行EVM操作语义与合约规格语言;精化命题直接针对部署字节码,未知代码交互纳入语义。以前沿商业LLM为证明代理,逐合约驱动Lean证明搜索,Lean内核机械验收,代理本身不被信任。评估集为23个以太坊主网真实合约,含主流稳定币系统主要组件,来源涵盖多个编译器版本及手写汇编。

Relating low-level executable code to a high-level account of its behavior has been a central concern of programming-language research for decades. From formally verified compilers to translation validators, certifying compilers, and proof-carrying code, each approach chooses between laborious but foundational mechanized proofs and automation that costs completeness, generality, and an increased trusted base. Recently, large language models (LLMs) have begun to change the economics of formal verification. Agentic proof development is now capable of producing machine-checked proofs at a scale and speed that were previously out of reach. In this paper, we evaluate the capabilities of LLMs to produce foundational, machine-checked proofs of refinement between executable code and its high-level specification, as post hoc, per-artifact certificates. We study this in the context of the Ethereum Virtual Machine (EVM), a low-level virtual machine that executes smart contracts on the Ethereum blockchain. We build EquiVM, a foundational framework in Lean comprising an executable EVM semantics and a specification language that characterizes the intended behavior of smart contracts, but commits to no source language or compilation toolchain. In EquiVM, refinement is stated for deployed bytecode of arbitrary provenance, interaction with unknown code is part of the semantics, and each proof is a replayable, machine-checked certificate. No previous technique achieves this combination. Using frontier commercial LLMs, twenty-three real-world contracts are proved end to end with minimal human guidance, among them most of the MakerDAO stablecoin system, at up to a hundred million tokens and a hundred hours of proof time per contract. We conclude that foundational mechanized proofs can now be bought at the price of tokens, and that this shift can reshape how verification frameworks are architected.

形式化与程序验证 5/30

KaPilot: LLM-Assisted Generation of Kani Specifications for Unsafe Rust Verification

多智能体自动生成unsafe Rust形式化规约:KaPilot以函数文档而非代码为主源,通过五智能体generate-precheck-verify闭环自动生成Kani规约。54个有ground truth的函数成功率88.9%,对比AutoSpec可验证规约+14.8%,等价或更强规约+25.9%。

两句看懂

现有LLM规约工具直接从代码派生规约,导致继承实现缺陷且空洞规约(contradictory preconditions)可无障碍通过验证,KaPilot改以函数文档为主源并引入五智能体generate-precheck-verify迭代闭环。在124个unsafe Rust函数上,有ground truth组成功率88.9%,57.4%规约等价或更强,对比AutoSpec可验

核心判断

以文档驱动替代代码驱动、配合多智能体闭环和逻辑蕴含选优,可自动生成高质量Kani规约;证据为88.9%成功率(有ground truth),57.4%等价或更强,对比AutoSpec可验证规约+14.8%。

关键要点

1. 现有LLM规约工具(如AutoSpec、SpecGen)以代码为主源:实现含缺陷时规约继承错误;更隐蔽的是,矛盾前置条件可形成空洞规约(vacuous spec),验证成功但无实质约束,既有框架缺乏自动检测此类问题的机制。 2. KaPilot以函数文档而非代码为主输入,SafetyReq提炼需求后驱动SpecGenerate生成规约;SpecPrecheck专项预检语法和空洞性,SpecVerify调用Kani返回反例后循环修改;多轮迭代生成候选集,最终由shuffle-and-implication按逻辑强度排序选优。 3. 54个有ground truth函数成功率88.9%,57.4%规约等价或更强;70个无ground truth函数成功率71.4%(低17.5pp),表明缺乏参考时质量边界下移;对比AutoSpec可验证规约+14.8%,等价或更强+25.9%,文档完整性是质量上限的关键约束。

证据与结果

评估集124个unsafe Rust函数分两组:54个附人工编写ground truth,70个无参考。成功标准:规约被Kani验证通过。质量标准:通过逻辑蕴含检查判断规约是否等价或强于ground truth。结果:有ground truth组成功率88.9%,其中57.4%等价或更强;无ground truth组成功率71.4%。基线对比AutoSpec:KaPilot可验证规约高14.8%,等价或更强规约高25.9%。失效诊断:空洞规约(contradictory preconditions导致前置条件为假)可通过Kani验证但无约束效力,SpecPrecheck专项拦截此类问题。

打开论文原文
它要解决什么
LLM生成规约时因代码中心化继承实现缺陷、输出不稳定且空洞规约可通过验证,如何系统打破这三个瓶颈?
研究路径
SafetyReq解析函数文档提取安全需求列表→SpecGenerate以需求为约束生成规约→SpecPrecheck检测语法错误和空洞规约→SpecVerify调用Kani,通过则入候选集,失败则将反例反馈给SpecGenerate→多轮后,shuffle-and-implication枚举候选对蕴含关系,选最强可验证规约输出。
这对工程意味着什么
部署KaPilot前优先保证unsafe函数文档完整覆盖安全前提条件,文档质量直接决定SafetyReq提取效果和最终规约覆盖率。避免以Kani验证通过作为规约质量的唯一判断标准,空洞规约可轻易通过验证但不提供任何实质约束。
证据定位
有ground truth组成功率88.9%,57.4%规约等价或强于ground truth;对比AutoSpec,可验证规约+14.8%,等价或更强规约+25.9%。(筛选维度:形式化验证)
适用边界
评估仅覆盖124个unsafe Rust函数,样本规模有限;无ground truth组成功率下滑至71.4%,表明缺乏参考时质量评估稳定性下降;SafetyReq依赖函数文档的完整性和准确性,文档缺失或误导时框架效果可能显著退化。
方法与英文摘要

数据集:124个unsafe Rust函数(54个有人工ground truth,70个无)。流程:SafetyReq从函数文档提炼安全需求→SpecGenerate依需求生成初始规约→SpecPrecheck语法预检→SpecVerify调用Kani验证→错误反馈驱动下一轮生成。多轮迭代产生候选集后,shuffle-and-implication策略枚举候选对间逻辑蕴含关系,选出最强可验证规约。

Rust's ownership and type system provide strong memory safety guarantees, but unsafe code still presents memory safety risks. Formal verification is crucial for ensuring memory safety, but writing precise specifications for unsafe Rust is challenging and largely manual. Large language models (LLMs) have shown promise in generating formal specifications but are often code-centric, prone to inheriting implementation flaws, and lack systematic quality assessment. In this paper, we present KaPilot, a multi-agent framework for automatically generating specifications to verify unsafe Rust memory safety using Kani. The process begins with lightweight program analysis and proof harness generation. The SafetyReq agent extracts a concise, refined list of safety requirements from the target Rust function's documentation, which guides the SpecGenerate agent in producing initial specifications that specify memory safety concerns. Then, the specifications are iteratively refined through a generate-precheck-verify loop involving SpecGenerate, SpecPrecheck, and SpecVerify agents, which assess quality and feed errors back. By executing this loop multiple times, KaPilot generates a set of candidate specifications. Finally, the shuffle-and-implication strategy is applied to systematically determine the best specification from these candidates. We evaluated KaPilot on 54 unsafe Rust functions with ground truth and 70 without. KaPilot achieved 88.9% and 71.4% specification generation success, respectively, with 57.4% of generated specifications equivalent to or stronger than the ground truth. Compared with AutoSpec, KaPilot produces 14.8% more verifiable specifications and 25.9% more equivalent-or-better specifications.

软件工程与仓库智能(4 篇)

软件工程与仓库智能 7/30

Integrating AI into Requirements Quality Learning in Software Engineering Education: A TPACK-Guided Empirical Study

结构化五步作业能把AI限定为需求分析助手,而不是替学生出答案:你在课程里引入AI工具时,最担心的是学生直接抄AI输出、跳过分析推理。这项研究给出了一种验证过的做法:用TPACK框架设计五步作业,强制手工分析在前、AI对比在后。72份硕士作业显示,学生以辅助分析为主,价值表述和可测试性维度提升最明显。

两句看懂

生成式AI进入需求工程实践后,教育中的AI集成普遍缺少系统教学理论支撑,研究者用TPACK框架设计了先手工后AI对比的五步作业,把多智能体AI工具嵌入硕士级需求工程课程。72份作业和反思报告的混合方法分析显示,这套脚手架有效把AI定位为分析辅助,价值表述和可测试性维度的学习增益最明显,可协商性效果不一。

核心判断

TPACK引导的结构化作业设计能把AI工具定位为分析辅助而非自动化替代;结构具体的维度(价值表述、可测试性)学习增益最明显,可协商性效果混合;证据来自72份硕士作业的混合方法分析。

关键要点

1. 旧有AI集成多停留在探索性实验,AI工具未与INVEST质量标准和教学序列对齐,学生倾向直接接受AI输出、绕过分析推理。 2. 研究依据TPACK框架把作业设计为五步序列:手工分析→多智能体AI对比→差异精化→同伴互评→结构化反思,环节顺序即控制手段,N=100、72份有效作业,定量评分加定性主题分析。 3. 结果:价值表述和可测试性改善最明显,可协商性效果混合,学生报告条件性信任而非盲从;做法是把手工分析放在AI之前并强制对比反思。

证据与结果

数据来自单一高校硕士需求工程课程,N=100名学生,72份完整作业纳入分析(未完整提交者排除)。评估按INVEST框架各质量维度打分,定性部分对反思报告和感知调查做主题分析。发现:价值表述和可测试性对齐改善最明显;可协商性等抽象维度效果混合;学生报告中等程度的可用性挑战;条件性信任和主动精化是主要的AI使用模式。研究无对照组,也未公开数值效果量。

打开论文原文
它要解决什么
结构化教学设计能否引导硕士生把AI用于需求质量分析推理,而不是直接采用AI的自动化输出?
研究路径
作业分五步执行:①学生先独立用INVEST框架分析用户故事质量;②用多智能体AI工具重新分析同一批故事;③对比两份分析,标注AI与自己的差异;④同伴互评检查分析一致性;⑤写结构化反思,评价AI的可信度与局限。手工推理被强制安排在AI使用之前,学生没有机会直接拿AI输出交差。
这对工程意味着什么
第一步行动:设计AI辅助作业时,先要求学生完成手工分析,再引入AI工具,并设置显式的对比环节,逼学生做批判性评估。要避开的捷径:把AI作业独立于质量标准框架之外——那样学生只会停留在表面使用,跳过真正的推理。
证据定位
72份作业的对比显示:价值表述和可测试性两个维度的对齐改善最明显;可协商性维度效果不稳定;学生报告的是条件性信任和主动精化,而不是无批判接受AI输出;可用性挑战为中等程度;研究未公开数值效果量。(筛选维度:可复核评测、软件工程方法)
适用边界
研究限于单一高校单门课程(N=100),没有对照组,学习增益无法确定来自AI工具本身还是作业结构设计;可协商性等抽象维度的评估部分依赖学生自我报告;结果能否推广到其他机构或课程尚待验证。
方法与英文摘要

研究在芬兰一所高校的硕士需求工程课程中进行,N=100名学生,72份完整作业纳入分析。作业按TPACK框架设计为五步:先手工用INVEST框架分析用户故事质量,再用多智能体AI工具重新分析同一批故事,对比两者差异,然后同伴互评,最后写结构化反思。数据采用混合方法:定量维度评分加上对反思报告和感知调查的定性主题分析。

The rapid adoption of generative Artificial Intelligence (AI) in software engineering (SE) practice creates a need for pedagogically grounded approaches to AI integration in SE education, especially in conceptually intensive subjects such as requirements engineering (RE). This study examines a TPACK-guided integration of a multi-agent AI tool into a master-level RE assignment on requirements quality analysis. Using a mixed-methods design (N=100; 72 submissions analysed), we examine how structured assignment design shaped students' AI use, affected their understanding of user story quality criteria, and influenced their perceptions of AI's benefits and limitations. Results show that students used the AI tool selectively, mainly as support for analysis and evaluation rather than automation. Alignment improvements were most evident for structurally concrete requirements quality dimensions, such as value articulation and testability, while negotiability showed mixed effects. Students reported conditional trust, active refinement, and increased awareness of quality criteria, alongside moderate usability challenges. The findings show that TPACK-guided scaffolding can align AI affordances with pedagogical goals and RE content, offering design guidance for responsible AI integration in RE education.

软件工程与仓库智能 7/30

MultiFixer: A Coordinator-Proposer Based Multi-Agent Framework For Fixing Multi-Hunk Bugs

逐块协调修复:Multi²Fixer把Defects4J修复数推到420个的新高:如果你用LLM做自动修复,现有评测只覆盖约58%的缺陷,你可能一直高估了模型的真实修复能力。Multi²Fixer用协调者-提议者多智能体架构逐块迭代修复多块缺陷,在Defects4J 835个缺陷上修复326个,配合更强基础模型达420个,创下该基准最高记录。

两句看懂

现有LLM修复方法只评测单块缺陷,主动排除了Defects4J中352个多块缺陷(评测覆盖率约58%),但近50%的真实缺陷涉及多块修改;Multi²Fixer用协调者-提议者分工和逐块迭代生成,把多块修复拆成有序的协调子任务。在835个缺陷上验证,相同基础模型下修复326个(含46个多块),配合更强基础模型达420个,刷新Defects4J最高记录。

核心判断

多块缺陷修复的关键是协调跨位置的修复顺序并逐块迭代生成。Multi²Fixer在835个缺陷上修复326个(含46个多块),配合更强基础模型达420个,均优于同等条件下的现有基线。

关键要点

1. 旧假设的失效:现有方法只覆盖483/835个单块缺陷(约58%),主动排除352个多块缺陷;但近50%真实缺陷涉及多块修改,块数一多,单步整体生成的修复成功率就急剧下降。 2. 方法与对照检查:BugAnalyzer定位缺陷并构建上下文,Coordinator规划跨位置修复顺序,Proposer逐块迭代生成,两阶段精炼先查语法再验语义;实验覆盖Defects4J 835个缺陷及VUL4J、SEC-bench、PatchEval多块子集,与基线在相同基础模型下对比。 3. 决定性结果与行动:相同基础模型下修复326个(含46个多块,95个独特修复),优于所有基线;配合更强基础模型达420个创纪录;做多块修复应改用有序逐块迭代,做评测应覆盖多块子集。

证据与结果

Defects4J共835个缺陷:单块483个、多方法62个、多文件27个,与现有APR基线在相同基础模型下比较修复数量。结果:相同模型修复326个(含46个多块、62个跨方法、27个跨文件,95个独特修复);VUL4J修复24个(含5个多块);SEC-bench多块子集修复11个,PatchEval多块子集修复19个,后两者均在弱基础模型条件下优于所有基线;配合更强基础模型共修复420个,创Defects4J最高记录。关键失效模式:块数增加时,单步整体生成的修复成功率急剧下降。

打开论文原文
它要解决什么
现有LLM修复评测主动回避多块缺陷:它们只评测单块缺陷,排除了Defects4J中352个多块缺陷。真正的问题是:跨方法、跨文件的协调修复,能否靠多智能体分工加逐块迭代生成来解决?
研究路径
BugAnalyzer调用工具分析缺陷位置,构建细粒度修复上下文。Coordinator受生成-识别不对称原理启发,制定跨方法或跨文件的修复执行顺序。Proposer按这个顺序逐块生成候选补丁。两阶段精炼先校验语法正确性,再用测试套件验证语义正确性;未通过则迭代重新生成,直到补丁通过测试。
这对工程意味着什么
第一件事:构建APR评测时覆盖全部复杂度层级,把多块子集算进去,而不是只测单块缺陷。要避开的捷径:不要在多块场景里用单步整体生成图省事,也不要只报告单块修复率——那会系统性高估模型在真实多块缺陷上的能力。
证据定位
相同基础模型下修复326个缺陷,其中46个多块、62个跨方法、27个跨文件,优于所有比较基线。配合更强基础模型修复420个,创Defects4J最高记录。漏洞基准上:VUL4J修复24个(含5个多块),SEC-bench多块子集修复11个,PatchEval多块子集修复19个,且都是在弱基础模型条件下优于所有基线。(筛选维度:可复核评测、软件工程方法)
适用边界
实验以Java缺陷为主(Defects4J),多块修复效果在其他编程语言或缺陷类型上的泛化能力未经验证。生成-识别不对称原理在供文本摘录中仅作为启发提及,量化依据未充分展示。
方法与英文摘要

数据集用Defects4J全部835个缺陷(含多方法62个、多文件27个子集),外加VUL4J、SEC-bench、PatchEval三个漏洞基准的多块子集。流程分四步:BugAnalyzer用工具增强分析定位缺陷并构建细粒度修复上下文;Coordinator规划跨位置的修复顺序;Proposer按顺序逐块迭代生成候选补丁;两阶段精炼先校验语法、再通过测试套件校验语义,不通过就迭代重新生成。

Automated Program Repair (APR) has benefited greatly from Large Language Models (LLMs), but existing LLM-based APR methods still struggle with multi-hunk bugs that require coordinated changes across multiple locations. These bugs demand repository-level context understanding, repair-order scheduling, and effective hunk-level patch generation and selection. To address these challenges, we propose MultiFixer, a novel Coordinator-Proposer based multi-agent framework for multi-hunk repair. MultiFixer performs tool-augmented bug analysis, constructs fine-grained repair context, iteratively generates patches through a Coordinator-Proposer architecture, and applies two-stage patch refinement for syntactic and semantic correctness. We evaluate MultiFixer on 835 bugs from Defects4J and three vulnerability benchmarks. On Defects4J, MultiFixer fixes 326 bugs, including 62 multi-method and 27 multi-file bugs, and outperforms prior APR baselines in the reported comparisons with the same base model. Moreover, MultiFixer also fixes 46 multi-hunk bugs among 95 unique fixes. When combined with Claude-3.5-Sonnet, MultiFixer repairs 420 bugs, establishing a new state of the art on Defects4J. On VUL4J, MultiFixer repairs 24 real-world vulnerabilities, including 5 multi-hunk cases. On the multi-hunk subsets of SEC-bench and PatchEval, MultiFixer fixes 11 and 19 vulnerabilities, respectively, outperforming all compared baselines under GPT-3.5. These results demonstrate the effectiveness of MultiFixer for multi-hunk repair.

软件工程与仓库智能 6/30

PAIChecker: Uncovering and Checking PR-Issue Misalignment in SWE-Bench-Like Benchmarks

SWE-bench基准13.6%实例存在PR-Issue错对齐:SWE-bench类基准假设每个PR与关联Issue完全对齐,但人工标注500条实例后发现13.6%存在错对齐(5类模式);41.2%从未被任何智能体解决的实例属于错对齐。PAIChecker三阶段多智能体系统在两个独立基准上最高达92.12%二分类准确率。

两句看懂

SWE-bench类基准用正则提取PR-Issue链接构建评测对,假设PR与Issue完全对齐,人工标注500条后发现13.6%(5类模式)违反该假设。PAIChecker三阶段多智能体系统(模式识别→跨智能体标签合成→代码校验)在SWE-Gym上达92.12%、SWE-bench Multilingual上达91.67%二分类准确率,均为四种LLM骨干最优。

核心判断

PR-Issue错对齐在SWE-bench类基准中普遍存在(13.6%)且与不可解率高度相关(41.2%);三阶段多智能体检测系统通过文本驱动、代码校验可达92.12%自动识别准确率。

关键要点

1. SWE-bench类基准的核心构建假设是每个PR与关联Issue唯一且完整对应,人工标注全量500条后发现13.6%违反该假设(5类模式,11个细粒度场景);131个排行榜智能体从未解决的实例中41.2%属错对齐,说明评测公平性受到实质损害,训练集中错对齐实例也会向模型引入错误监督信号。 2. PAIChecker遵循文本驱动、代码校验原则:第一阶段按预定义5类模式逐类识别,第二阶段跨多智能体合成标签以提升泛化性,第三阶段对代码差异作代码级验证渐进确认;输入为PR描述、Issue文本与代码差异,并通过GitHub API辅助获取上下文信息;三阶段设计使文本语义比对与代码语义校验解耦。 3. 在SWE-Gym和SWE-bench Multilingual两个独立基准上,PAIChecker以四种LLM骨干均取最优,最高二分类准确率分别达92.12%和91.67%;检测难点在于大规模代码修改的意图固有模糊性——直接从代码推断语义不可靠,因此文本侧先行、代码侧兜底是关键设计决策。

证据与结果

基础标注集:SWE-bench Verified全量500条实例,人工标注发现约68条(13.6%)错对齐,归入5类模式11个细粒度场景。自动检测评测:在SWE-Gym和SWE-bench Multilingual两个基准上评测,使用四种LLM骨干,指标为二分类准确率;PAIChecker在SWE-Gym上最高92.12%、SWE-bench Multilingual上最高91.67%,两个基准均取最优。影响量化:131个排行榜智能体从未解决的实例中41.2%属错对齐,直接关联评测可信度。

打开论文原文
它要解决什么
SWE-bench类基准用PR-Issue链接自动构建评测集时,错对齐比例有多高,能否用多智能体系统自动检测并分类?
研究路径
PAIChecker三阶段执行:①对PR描述与Issue文本按预定义5类错对齐模式逐类检查,明确匹配到具体场景;②汇集多个智能体的独立判断,交叉合成最终标签以减少单智能体误判;③对代码差异作代码级验证,渐进确认文本侧结论。设计原则:文本自然语言层比对先于代码层,以降低意图歧义。
这对工程意味着什么
向SWE-bench类基准或训练集加入新实例前,先过滤PR-Issue错对齐;不要仅凭PR描述中包含Issue编号就断定对齐——正则提取无法识别语义错对齐,需结合文本语义比对和代码级验证两步确认。
证据定位
PAIChecker在SWE-Gym和SWE-bench Multilingual两个基准上均超过全部四种LLM骨干下的对比基线,最高二分类准确率分别达92.12%和91.67%。(筛选维度:可复核评测、软件工程方法)
适用边界
人工标注仅覆盖SWE-bench Verified的500条实例;5类错对齐模式从同一数据集归纳,对其他编程语言或领域基准的模式覆盖完整性未经独立验证;检测准确率受所选LLM骨干能力影响。
方法与英文摘要

人工标注SWE-bench Verified全量500条实例,归纳5类错对齐模式(11个细粒度场景)。PAIChecker以通用智能体为基础,增加任务专用提示和GitHub API访问,分三阶段执行:①按预定义5类模式逐类识别;②跨多智能体合成标签;③对代码差异作代码级验证渐进确认。遵循文本驱动、代码校验原则,先比较PR描述与Issue文本语义,再对代码差异二次核验。在SWE-Gym和SWE-bench Multilingual两个基准上以四种LLM骨干评测。

SWE-bench-like benchmarks are widely used for evaluating LLM's issue resolution capability. They typically follow a common construction pipeline: each PR (Pull Request) is paired with its linked issue by extracting issue references from the PR description; the issue description is used as the problem statement, and the PR patch serves as the test oracle. However, due to the inherent complexity of developing and maintaining large repositories, such PR-Issue pairings are often misaligned in practice. In this work, we systematically study SWE-bench Verified instances, finding that 13.6% exhibit misalignment across five patterns in eleven fine-grained scenarios. To enable reliable and scalable construction of those benchmarks in the future, we propose PAIChecker, a multi-agent system for checking PR-Issue misalignment in SWE-bench-like benchmarks. Specifically, PAIChecker adopts a three-phase design that combines specific pattern identification, cross-agent label synthesis, and code-level validation, thereby enabling more accurate, generalizable, and progressively verified detection. Experiments on SWE-Gym and SWE-bench Multilingual show that PAIchecker achieves the best performance across all four LLM backbones, reaching up to 92.12% and 91.67% binary accuracy, respectively.

软件工程与仓库智能 6/30

From Textual Requirements to Microservice Architectures - A Comprehensive Evaluation of LLM-Based Design Synthesis

少样本提示下,o3可凭文本需求生成可用的微服务草案:服务识别F1达0.97,但通信依…:如果你在设计早期只有需求文档、没有代码,这份评测直接告诉你:用少样本提示驱动o3生成微服务架构,服务边界识别F1可达0.97,草案可用;但零样本输出的通信依赖过密、F1仅0.61,不能直接采用。研究用结构F1对比和专家盲评双轨验证了这一结论。

两句看懂

现有微服务分解方法以代码为中心(依赖静态依赖图、运行时追踪),在仅有文本需求的早期阶段无法适用;本研究令o3在零样本与少样本提示下从纯文本需求直接合成微服务架构。以Bookstore和PetClinic为被测系统,用结构F1和专家盲评双轨验证:少样本提示使服务识别F1从0.79升至0.97,通信恢复F1从0.61升至0.82。

核心判断

o3能从纯文本需求生成微服务架构,少样本提示效果显著优于零样本。证据来自两个系统的F1对比:服务识别FS=0.97 vs ZS=0.79,通信恢复FS=0.82 vs ZS=0.61,以及专家盲评一致认为FS输出更模块化、连贯、合理。

关键要点

1. 旧假设失效:现有分解方法以代码为中心,仅有文本需求的早期阶段无法使用,LLM能否仅凭需求文本生成完整架构此前缺乏系统实证。 2. 方法与受控检查:固定o3模型,在Bookstore和PetClinic上控制提示策略(ZS/FS),每条件单次执行;定量算服务识别与通信恢复F1,定性由专家盲评四维度。 3. 决定性结果与行动:服务识别FS F1=0.97(ZS=0.79),通信恢复FS F1=0.82(ZS=0.61且架构过密);早期设计可用少样本提示出草案,但通信依赖须人工复核,切勿直接采用零样本输出。

证据与结果

被测系统为Bookstore和PetClinic(均为小型系统),每条件单次执行,共4次生成(2系统×2提示)。定量轨用精确率、召回率、F1衡量生成架构与参考架构的结构对齐;定性轨由专家盲评正确性、完整性、模块性、合理性,并综合开放反馈。关键数据:服务识别ZS F1=0.79、FS F1=0.97;通信恢复ZS F1=0.61(高召回低精度,架构过密)、FS F1=0.82(虚假依赖减少)。

打开论文原文
它要解决什么
仅凭文本需求(无代码),LLM能否直接生成结构合理的微服务架构?提示策略(零样本 vs 少样本)如何影响服务识别与通信恢复的精度?
研究路径
o3接收系统文本需求(无代码)。ZS提示仅描述任务本身,FS提示额外附加示例架构片段,让模型参照样例组织输出。模型输出服务列表及服务间交互依赖。随后与人工实现的参考架构对比计算精确率、召回率、F1;再由不知提示条件的专家对正确性、完整性、模块性、合理性四维度打分,并收集开放式反馈做描述性综合。
这对工程意味着什么
第一步行动:早期设计阶段用少样本提示(附带示例架构)驱动o3生成微服务草案,服务边界识别F1可达0.97。要避开的捷径:不要把零样本输出的过密通信图直接纳入设计,其通信恢复F1仅0.61,依赖关系需额外人工审查。
证据定位
少样本提示全面占优:服务识别FS F1=0.97,ZS仅0.79;通信恢复是更难的子任务,ZS产生过密架构(高召回低精度,F1=0.61),FS将F1提升至0.82并削减了无支撑依赖。专家盲评一致认为FS架构更模块化、连贯、合理。(筛选维度:可复核评测、软件工程方法)
适用边界
仅评测Bookstore和PetClinic两个小型系统,每条件单次执行(无重复采样)。结果属o3模型特定和情境特定,不能推广为模型无关结论;未覆盖大型复杂系统,参考架构本身也可能存在设计偏差。
方法与英文摘要

研究使用OpenAI o3,对Bookstore和PetClinic两个小型系统分别在零样本(ZS)和少样本(FS)提示下各执行一次,输入仅为自然语言需求文本。ZS提示只描述任务,FS提示额外附加示例架构片段。生成的架构走两步评测:先与人工实现的参考架构对比,计算服务识别和通信恢复的精确率、召回率、F1;再由不知提示条件的专家对正确性、完整性、模块性、合理性四个维度盲评打分,并对开放反馈做描述性综合。

Microservice architectures have become dominant for modernizing monolithic systems, yet identifying appropriate services remains challenging and largely manual. Existing decomposition approaches are predominantly code-centric, limiting applicability in early design stages where only textual requirements are available. Despite advances in Large Language Models (LLMs), limited empirical evidence exists on their ability to synthesize complete microservice architectures from natural-language requirements, including service definitions and inter-service interactions. This study investigates whether an LLM can bridge requirements engineering and architectural design, generating architectures solely from textual requirements and evaluating structural agreement and perceived quality of results. We conduct a mixed-method study using OpenAI o3 under zero-shot (ZS) and few-shot (FS) prompting across two systems (Bookstore, PetClinic), one execution per system/condition. Architectures are evaluated through (i) comparison with reference architectures using precision, recall, and F1-score for service identification and communication recovery, and (ii) a blinded expert assessment of correctness, completeness, modularity, and plausibility, plus open feedback synthesis. OpenAI o3 identifies services with higher agreement under FS prompting (F1 = 0.79 for ZS versus = 0.97 for FS). Communication recovery is more challenging: ZS produces dense architectures with high recall but low precision (F1 = 0.61), while FS improves agreement, reaching F1 = 0.82 and reducing unsupported dependencies. Expert evaluation corroborates these results, with FS architectures perceived as more modular, coherent, and plausible than ZS outputs. OpenAI o3 shows potential for requirements-driven synthesis when guided by exemplar prompting. Results are model- and context-specific from two small systems, not model-independent proof.

代码质量与优化(1 篇)

代码质量与优化 6/30

Reinforcement Learning for Code Optimization

执行时间可学习的代码优化强化学习:直接将执行时间追加至RL奖励几乎不提升速度(p30仅+0.6点),三阶段改造——DMC-Optim大输入测集+校准沙箱、三信号奖励组合+离线模拟器、适配GRPO——使速度信号可学习,CWM 32B严格top-50% pass@1从30.7%升至50.4%。

两句看懂

标准RLVR将执行时间叠加到二值正确奖励,p30仅变化+0.6点且可能损害正确率;本文以DMC-Optim大输入沙箱、三信号奖励组合(c/g/q)加离线模拟器筛选配置、适配GRPO三阶段改造使速度信号可学习。在DMC-Optim pτ指标下,CWM 32B top-50% pass@1从30.7%升至50.4%,top-30%相对提升125%,沙箱退化场景领先标准RLVR 10

核心判断

执行时间信号可学习的前提是四条链路同时满足:大输入测例区分解速度、校准沙箱保证时序可比、门控奖励阻断快但错误的路径、适配优化器稳定稀疏梯度;CWM 32B top-30%相对提升125%,复杂度改进率达人类一半(14% vs. 28%)为证。

关键要点

1. 旧假设缺口:标准RLVR以二值pass/fail为奖励,直接追加原始执行时间后p30仅+0.6点(最低-0.3点),失败路径为时序噪声掩盖速度差异、稀疏奖励使梯度消失、快但错误的代码被误奖励,三条链路叠加使信号崩溃。 2. 构建与控制变量:DMC-Optim提供大输入测例,CES远程沙箱校准时序基准;奖励由c(正确门控)、g(优化门控)、q(质量分)三信号组合;离线模拟器1 CPU×分钟内回放人类参考解以AUC排序候选环境,筛出最优配置再启动8–32 GPU节点在线训练。 3. 关键结果与边界:最优配置下CWM 32B top-50% pass@1从30.7%升至50.4%,top-30%相对提升125%;LCB上赢得83%中位样本速度比较;复杂度类改进率14% vs. 人类28%,仍有约一半差距;沙箱退化时鲁棒配置领先标准RLVR 100–200%,执行环境质量是结论的硬约束。

证据与结果

主测集DMC-Optim,指标pτ(解正确且不慢于人类参考第τ百分位,τ=100/50/30逐级加严)。Qwen 2.5 7B:top-50% 18.0%31.3%;CWM 32B:top-50% 30.7%50.4%,top-30% 7.7%19.1%(相对+125%)。LCB辅助测集:CWM 32B赢得83%中位样本速度比较。沙箱退化实验:鲁棒配置领先标准RLVR 100–200%。复杂度类改进率14% vs. 人类28%。失败诊断:测例过小时q信号噪声淹没速度差异;GRPO批量不足时稀疏奖励导致训练不稳定;快但错误的代码可获速度奖励污染信号。

打开论文原文
它要解决什么
将执行时间纳入RL奖励时,时序噪声、奖励稀疏和GRPO不稳定三条链路如何导致失败,如何同时修复使速度信号可学习?
研究路径
①DMC-Optim大输入测例让慢解与快解在时序上可区分;②CES远程沙箱校准测量基准;③预执行过滤器按绝对/相对标准筛选优化测例;④执行时施加per-test时限;⑤后执行将时序按人类参考分布排名得到质量分q;⑥离线模拟器回放人类解以AUC排序候选环境;⑦选出最优配置后在8–32 GPU节点扩大批量运行GRPO。
这对工程意味着什么
在执行性能RL项目中:先建校准沙箱和大输入测例,再用离线模拟器筛选奖励配置,最后启动在线训练;避免将平均运行时直接叠加到二值奖励——该做法在小输入测例上几乎无信号,且可能奖励快速错误代码,反而损害正确率。
证据定位
DMC-Optim最强配置:Qwen 2.5 7B top-50% pass@1 18.0%31.3%,CWM 32B 30.7%50.4%;top-30% CWM 32B相对提升125%;沙箱退化时较标准RLVR高100–200%;LCB上CWM 32B赢得83%中位样本速度比较;复杂度类改进率14% vs. 人类28%。(筛选维度:可复核评测、软件工程方法)
适用边界
DMC-Optim源自竞技编程题目,未测试工业代码库或仓库级修改场景;人类参考分布来自提交排行榜,存在历史版本偏差;结果对沙箱质量敏感(退化场景单独报告),低质沙箱环境下结论迁移性尚不确定。
方法与英文摘要

三阶段:①构建DMC-Optim(大输入优化测例+远程校准沙箱CES区分解速度);②用正确性门控c、优化门控g、质量分q组合奖励,离线RL模拟器回放人类参考解排序候选配置(1 CPU×分钟),再以8–32 GPU节点启动在线训练;③调整GRPO批量与评估适配稀疏噪声奖励。测试模型Qwen 2.5 7B与CWM 32B,指标pτ要求解正确且不慢于人类参考第τ百分位,τ越小越严。

RL for code correctness is now established: have the model generate a program, run it against hidden test cases, and reward solutions that pass. Extending this to code optimization seems straightforward: just add execution time to the reward. But in practice, once timing drives the reward, small problems in measurement noise, reward sparsity, or GRPO instability overwhelm the signal and make RL fail: generated solutions are barely faster, and more of them can fail. We make execution time learnable through three stages: (1) how code is tested, by building DMC-Optim with large optimization tests and a calibrated sandbox; (2) how speed is turned into reward, by composing correctness and speed in the RL environment and using an offline simulator to predict the most promising configurations; and (3) how the model learns from that reward, by adapting GRPO and evaluation to the sparser, noisier timed-execution setting. On DMC-Optim, the strongest optimization-aware configurations improve strict top-50% pass@1 from 18.0% to 31.3% on Qwen 2.5 7B and from 30.7% to 50.4% on CWM 32B. These gains further increase at stricter percentiles such as top-30%, with 125% relative improvement for CWM 32B, while preserving pure-correctness scores. When the timing sandbox is degraded, robust optimization RL reaches 100% to 200% improvement over standard RLVR, depending on the evaluation criterion. On LCB, CWM 32B wins up to 83% of median-sample speed comparisons against standard RLVR. Relative to the fastest correct human submissions per problem, it reaches about half the human rate of complexity-class improvements (14% vs. 28%).

UI 与 GUI Agent(0 篇)

本轮没有通过深读证据门的重点论文。

个人知识与本体(1 篇)

个人知识与本体 4/30

Setoka: A Benchmark for Hierarchical User Understanding in Personalized Agents over Heterogeneous Data

Setoka:异构数据四层用户理解评测基准:现有记忆基准只测对话历史中的显式事实检索,无法衡量行为模式与人格特质等抽象推断能力。Setoka定义语义记忆/情节记忆/行为模式/人格特质四层体系,用心理测量流水线合成10用户×23模式的异构数据,评测3模型×5记忆系统,确认系统在抽象层性能逐级下滑。

两句看懂

现有记忆基准只测对话历史中的显式事实检索,无法衡量Agent对行为模式和人格特质的推断能力;Setoka定义四层用户理解体系,用心理测量流水线合成10用户×23模式异构数据集,对3个LLM×5套记忆系统分层评测。结果显示语义记忆表现最好,情节记忆次之,行为模式和人格特质任务性能进一步下滑,确认当前记忆系统的核心短板在于跨源整合与抽象归纳。

核心判断

当前记忆系统擅长显式事实检索,但行为模式和人格特质等抽象推断任务性能显著更差;3个LLM×5套记忆系统在四层评测中均呈逐层下降规律,支持此结论。

关键要点

1. 现有记忆基准以单一对话历史为数据源,只考核显式事实检索准确率,无法捕捉行为模式和人格特质推断能力,导致记忆系统研究系统性忽视抽象理解维度,进而错误高估系统在个性化任务上的真实能力。 2. Setoka用心理测量采样保证人格特质组合的真实分布,为10个合成用户生成涵盖3种数据模型(非结构化文本、结构化记录、社交图)×23种模式的异构长期记录,按四层理解独立生成带溯源证据链的查询,以3个LLM×5套记忆系统正交组合控制变量。 3. 性能沿语义记忆→情节记忆→行为模式→人格特质四层逐级下滑;外向性等人格特质需同时整合日历群体活动、群聊活跃度、社交图谱连接数,单一数据源无法给出完整答案,确认跨源整合与长期行为抽象是当前记忆系统的硬性能力边界。

证据与结果

数据集:10个合成用户,23种模式,3种数据模型(非结构化文本如消息/笔记、结构化记录如联系人/日历、社交图),由心理测量流水线生成以规避隐私问题。评测矩阵:3个LLM×5套主流记忆系统正交组合。评测维度:语义记忆、情节记忆、行为模式、人格特质四层,各层独立计算准确率。核心结果:性能系统性逐层下降,语义记忆最优,人格特质最差,各LLM和记忆系统均呈此规律。失效诊断:外向性等人格特质需跨日历、群聊、社交图三类来源整合,单源检索无法覆盖完整证据,揭示跨源聚合是记忆系统的核心缺口。

打开论文原文
它要解决什么
记忆增强型个性化Agent能否胜任行为模式和人格特质等抽象用户理解任务,还是仅擅长显式事实检索?
研究路径
①用心理测量学采样真实分布人格特质组合,生成10个合成用户画像;②按23种模式为每用户合成跨非结构化文本、结构化记录、社交图三类数据源的长期异构记录;③按四层理解独立构造带溯源证据链的查询;④将查询输入3个LLM(各配5套记忆系统),逐层计算正确率并比较层间衰减幅度。
这对工程意味着什么
开发个性化Agent记忆时,先用四层分层评测定位系统的实际能力边界,再针对最薄弱层设计跨源整合机制;不要以单一检索准确率衡量记忆质量,这会掩盖系统在行为模式和人格特质推断上的真实失效。
证据定位
3个LLM×5套记忆系统均呈相同规律:语义记忆检索准确率最高,情节记忆次之,行为模式和人格特质层性能进一步大幅下降;确认抽象推断是当前记忆系统跨配置的系统性短板。(筛选维度:可复核评测)
适用边界
合成数据仅覆盖10个用户和23种模式,真实用户数据多样性未被充分模拟;心理测量框架限定了人格特质的覆盖范围;评测结论基于特定LLM和记忆系统组合,对未纳入系统的泛化程度需另行验证。
方法与英文摘要

用心理测量学采样真实分布的人格特质组合,为10个合成用户生成跨3类数据源(非结构化文本如消息/笔记、结构化记录如联系人/日历、社交图)的23种模式长期异构记录;按语义记忆/情节记忆/行为模式/人格特质四层独立构造带溯源证据的查询;将查询输入3个LLM(各配5套记忆系统),逐层统计回答正确率。

Personalized agents are increasingly applied to assist users across a wide range of tasks. Effective personalized assistance requires not only retrieving explicit facts from past interactions stored in agent memory, but also inferring abstract personal characteristics. However, existing memory benchmarks primarily evaluate whether an agent can retrieve information explicitly stated in conversational histories, failing to provide an effective assessment of deeper user understanding. In this work, we propose Setoka, a benchmark for evaluating memory-augmented personalized agents with hierarchical user understanding from heterogeneous data. Grounded in theories from cognitive and personality psychology, Setoka defines four levels of user understanding, i.e., semantic memory, episodic memory, behavior pattern, and personality trait. Moreover, to enable realistic yet privacy-preserving evaluation, we design a psychometrics-based pipeline that synthesizes diverse, coherent heterogeneous user data and queries at scale. Finally, we leverage Setoka to evaluate 3 language models combined with 5 memory systems for 10 synthetic users. Our comprehensive evaluation reveals that while existing systems perform well on semantic memory retrieval, their performance declines on episodic memory. Moreover, when dealing with behavior pattern and personality trait understanding tasks that require integrating heterogeneous and fragmented information dispersed over time, performance declines even further. These findings demonstrate that user understanding cannot be handled by simple fact retrieval, motivating the design of memory mechanisms for cross-source integration and abstraction over long-term user behavior.

人机协同与对齐(0 篇)

本轮没有通过深读证据门的重点论文。

本轮分类概览

同一论文只归入一个最先命中的赛道,避免重复计数;“新增候选”只统计首次展示的论文。

赛道新增候选重点
形式化与程序验证02
软件工程与仓库智能04
代码质量与优化01
UI 与 GUI Agent00
个人知识与本体01
人机协同与对齐00

近一个季度监测日历

北京时间。绿色表示有可阅读的新候选,灰蓝表示已监测但无新增,橙色表示部分降级;“无记录”不等于失败。

2026 年 6 月

1无记录2无记录3无记录4无记录5无记录6无记录7无记录8无记录9无记录10无记录11无记录12无记录13无记录14无记录15无记录16无记录17无记录18无记录19无记录20无记录21无记录22无记录23无记录24无记录25无记录26无记录27无记录28无记录29无记录30无记录

近 14 次监测窗口

仅展示公开源的聚合运行状态,不含提示词、全文或个人数据。

本轮新增候选(0 篇)

按赛道、评分和日期展开;中文标签用于导航,英文摘要用于核验。已展示过的旧候选不会每日重复。

形式化与程序验证(0 篇)

本轮该赛道没有候选论文。

软件工程与仓库智能(0 篇)

本轮该赛道没有候选论文。

代码质量与优化(0 篇)

本轮该赛道没有候选论文。

UI 与 GUI Agent(0 篇)

本轮该赛道没有候选论文。

个人知识与本体(0 篇)

本轮该赛道没有候选论文。

人机协同与对齐(0 篇)

本轮该赛道没有候选论文。