公开论文雷达

公开 arXiv 研究简报 · 2026-09-09T00:51:21.788259+00:00

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

数字好看不等于交付:先改口径再挑做法

八张卡里有好几篇在拆同一件事:测试通过率、提交量、召回率这类单一数字,容易把"看起来行"当成"真的行"。建议先读04681换衡量口径,再读04909学怎么验收,然后按记忆和代码两条线挑能直接照抄的机制;05278本文没给数字,放最后。

推荐阅读顺序

  1. 2609.04681:先换口径:提交级+180%但发布级只+30%,用PQC和验证税重排你的衡量方式。
  2. 2609.04909:口径落到动作:812例人工核查中72.7%含幻觉,含已通过全部测试的补丁,验收要抽查中间推理。
  3. 2609.01087:这批里分数最高、做法最具体:微调优于纯提示,输入要含code diff、issue body、PR body。
  4. 2609.01769:反例课:四个定位器召回都100%,但C语言精度只有2.1%-15.5%,别只看召回率。
  5. 2609.00243:记忆线第一篇:失效粒度用行级,表级失效把5/7模型漂移后首次成功率打到0%。
  6. 2609.04915:接着看2k-5k预算下的写入与打包规则,消融把收益拆成+5.7pp和+5.0pp。
  7. 2609.01235:要做审计或合规校验再读:双实现72/72一致,但金丝雀只有120单元,别当防护证明。
  8. 2609.05278:放最后:本文只讲实现,可读性和实用性的量化结果在前期工作[14]里,不在这篇。
共性方法
这批卡反复指向同一个毛病:拿一个总量数字当结论。提交量、测试通过率、召回率、检索召回率被单独拆开核查后都露了缺口。几篇给出的动作也一致——把"过程指标"和"真正合格的结果"拆成两项分别量,别用前者代替后者。
关键分歧
分歧在证据成色。00243、04915、01087自带对照和消融,机制可以照抄;04681是综述,数字来自他人研究、作者未独立复核;01235只核验协议自身,不管内容真伪;05278的量化结果不在本文。同样说"有效",可信度不在一个档。
选择准则
手上已有明确任务,就直接挑对应那篇照抄机制:记忆看00243和04915,代码看01087。还在定衡量标准,先读04681和04909。凡是本文没自带对照数字的(04681、05278),只借思路,不借结论。

重点深读(8 / 8 篇)

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

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

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

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

Fine-Tuning Large Language Models to Classify Pull Request-Issue Alignments: Going Beyond Prompting

微调大模型判断PR与Issue是否对齐:研究对比提示式与微调式大模型在PR-Issue对齐分类上的表现:微调GPT-4o及五个开源代码模型后,准确率、F1-micro、F1-macro、召回率均超过基线,SHAP分析显示code diff、issue body、PR body影响最大。

两句看懂

仅靠提示词让大模型判断PR是否对齐Issue效果有限,研究改为对GPT-4o及五个开源代码模型做指令微调与分类头微调。对比微调前后结果,准确率和F1-micro提升6.15%,F1-macro提升14.69%,开源模型中CodeLlama-7B综合最优。

核心判断

微调而非仅提示更能准确判断PR是否对齐Issue:微调后模型准确率、F1-micro各提升6.15%,F1-macro提升14.69%,召回率提升6.15%,CodeLlama-7B在开源模型中综合最佳。

关键要点

1. 仅用提示词的大模型做PR-Issue对齐分类(判断PR是否真正对齐所关联Issue,属tangling commit检测范畴)准确率有限,且已有数据集类别不均衡,需先做数据增强再评测。 2. 研究扩展已有PR-Issue对齐数据集并做数据增强,对GPT-4o做指令微调,对CodeLlama-7B、CodeQwen1.5-7B、StableCode-3B、CodeGemma-7B、Deepseek-Coder-6.7B五个开源代码模型加分类头微调,输入含PR body、issue body、code diff,与基线提示式模型对比。 3. 微调后平均提升:准确率与F1-micro各+6.15%,F1-macro+14.69%,召回率+6.15%;CodeLlama-7B为开源模型中综合最佳;对其做SHAP分析显示code diff、issue body、PR body三类字段对预测影响最大。

证据与结果

数据来源为扩展后的已有PR-Issue对齐数据集,经数据增强缓解类别不均衡(具体规模与类别数摘录未给出);比较微调后的GPT-4o及CodeLlama-7B、CodeQwen1.5-7B、StableCode-3B、CodeGemma-7B、Deepseek-Coder-6.7B五个开源模型与基线提示式模型;评测指标为准确率、F1-micro、F1-macro、召回率,微调后平均分别提升6.15%、6.15%14.69%6.15%;CodeLlama-7B综合表现最佳;SHAP分析显示code diff、issue body、PR body三类输入字段影响最大。

打开论文原文
它要解决什么
提示式大模型能否准确判断PR是否真正对齐所关联的Issue,还是需要微调才能提升分类准确率?
研究路径
先扩展已有PR-Issue对齐数据集并做数据增强缓解类别不均衡;对GPT-4o做指令微调,对CodeLlama-7B等五个开源代码模型加分类头微调,输入含PR body、issue body、code diff;训练后与基线提示式模型对比准确率、F1-micro、F1-macro、召回率;再对表现最佳的开源模型CodeLlama-7B做SHAP可解释性分析,考察各字段对预测的贡献。
这对工程意味着什么
对PR-Issue对齐类任务优先用微调开源代码模型(如CodeLlama-7B)而非仅提示,因微调后各项指标平均提升6%~15%;不要只看F1-micro,需核对F1-macro并用SHAP归因确认字段贡献,避免被单一指标或提示效果误导。
证据定位
微调后模型相比基线平均提升:准确率与F1-micro各+6.15%,F1-macro+14.69%,召回率+6.15%;开源模型中CodeLlama-7B综合表现最佳。(筛选维度:可复核评测、软件工程方法)
适用边界
论文摘录未给出数据集具体规模、类别定义及数据增强方法细节,也未列出基线提示式模型的具体设置,这些信息影响结果的可复现性判断。
方法与英文摘要

基于扩展后的PR-Issue对齐数据集,做数据增强缓解类别不均衡;对GPT-4o做指令微调,对CodeLlama-7B、CodeQwen1.5-7B、StableCode-3B、CodeGemma-7B、Deepseek-Coder-6.7B五个开源代码模型加分类头微调;输入含PR body、issue body、code diff;微调后与基线提示式模型对比多项指标,并对最佳开源模型做SHAP可解释性分析。

Context: Accurate alignment between pull requests (PRs) and corresponding issues is crucial for efficient software development and maintaining code quality, as misalignments can reduce traceability, hinder defect localization, and decrease maintainability. Objective: This study aims to improve automated PR-issue alignment classification by leveraging fine-tuned large language models (LLMs) across multiple alignment categories, and conducts interpretability analysis to investigate the effects of PR-issue fields on the predictions of fine-tuned LLMs. Method: Our methodology consists of dataset preparation, LLM fine-tuning, and interpretability analysis. We first extended an existing dataset and applied data augmentation to address class imbalance. GPT-4o was then fine-tuned via instruction tuning, and open-source LLMs including CodeLlama-7B, CodeQwen1.5-7B, StableCode-3B, CodeGemma-7B, and Deepseek-Coder-6.7B were fine-tuned using classification-specific heads. Interpretability analysis using Shapley Additive Explanations (SHAP) was conducted to examine the influence of PR-issue fields on predictions for the best-performing open-source LLM. Results: Fine-tuned LLMs outperformed baseline models, achieving average improvements of 6.15% in accuracy and F1-micro, 14.69% in F1-macro, and 6.15% in recall. CodeLlama-7B emerged as the best-performing fine-tuned LLM overall, while interpretability analysis revealed that code diffs together with issue body and PR body contents exert the greatest influence on predictions. Conclusions: Fine-tuning substantially enhances PR-issue alignment classification, improving both accuracy and efficiency. Interpretability analysis provides actionable insights into the dataset features driving alignment decisions, deepening understanding of how LLMs reason over software artifacts.

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

Better Understanding, Better Fixes? A Study of Hallucination in LLM-based Automated Program Repair

补丁通过测试不代表模型真懂缺陷:72.7%的修复仍含幻觉:你如果在验收LLM自动修复的补丁,只看测试通过率会踩坑:这项研究对832个Defects4J缺陷做了多层评测,人工核查812例修复发现72.7%含有幻觉,其中还包括已经通过全部可用测试的补丁。研究方法是给模型加做三项中间任务,把它的理解过程拆开检查。

两句看懂

老评测只看补丁能否通过测试,掩盖了模型中间的理解幻觉;这项研究把触发用例识别、行覆盖预测、补充测试生成和最终补丁生成分开评测。在832个Defects4J缺陷上测三款LLM,补丁通过率仅21.0%-55.9%,人工核查812例发现72.7%仍含幻觉,包括已通过全部测试的补丁。

核心判断

补丁通过测试不代表模型理解了缺陷。人工核查812例修复,72.7%仍含幻觉,其中包括已通过全部可用测试的补丁,说明只看结果的评测不足以衡量真实理解。

关键要点

1)旧评测只统计最终补丁是否通过开发者测试套件,无法揭示模型是否真正理解缺陷成因和修复语义,会把碰巧通过的补丁误判为正确修复。2)研究让三款LLM在832个Defects4J缺陷上分别完成触发用例识别、行覆盖预测、补充测试生成三项中间任务和最终补丁生成,自动比对真实标签,并对812例修复做人工标注,判断是否忠实于修复证据。3)补丁通过率仅21.0%-55.9%,但人工分析发现72.7%的修复仍含幻觉(含通过全部测试的补丁),因果定位错误占45.9%、修复策略错误占18.5%;所以验收时除测试通过率外,必须抽样人工核查中间推理。

证据与结果

数据源是Defects4J共832个缺陷,评测三款代表性LLM。评测覆盖三项中间任务加最终补丁生成,采用两种模式:自动评测(比对真实标签、统计测试套件通过率)和人工分析(812例抽样修复)。结果:补丁通过率21.0%-55.9%;72.7%的修复含幻觉,其中因果定位错误45.9%、修复策略错误18.5%;更准确的中间产物通常伴随修复成功,但并非总是如此。

打开论文原文
它要解决什么
只看补丁是否通过开发者测试套件,能不能说明LLM真正理解了缺陷的成因和修复语义?
研究路径
三项中间任务按顺序执行:先让模型识别哪些测试用例会触发缺陷;再预测缺陷相关代码行的执行覆盖,尤其是分支控制流处;然后生成补充测试用例来检验修复;最后才生成最终补丁。系统自动把中间产物与真实标签比对,再对812例修复做人工标注,判断是否忠实于修复证据。模型常犯的错误包括:误判触发用例、在分支控制流处误判行覆盖、生成的补充测试缺失触发条件或预期行为写错。
这对工程意味着什么
第一步行动:验收LLM修复补丁时,抽样人工核查模型的因果定位和修复策略是否正确,而不是只看测试是否通过。要避开的捷径:把测试通过率当作唯一的质量信号,这是常见但危险的做法,因为通过全部测试的补丁里仍有含幻觉的修复。
证据定位
各模型的补丁通过开发者测试套件的比例只有21.0%-55.9%。人工分析812例修复发现:72.7%含有修复幻觉,其中包含已通过全部可用测试的补丁;幻觉中因果定位错误占45.9%,修复策略错误占18.5%。(筛选维度:可复核评测、软件工程方法)
适用边界
结论基于Defects4J这一个基准和三款代表性LLM,人工分析只覆盖812例抽样修复;换用不同代码库或不同模型,幻觉比例可能不同。
方法与英文摘要

研究用Defects4J的832个缺陷作为数据源,让三款代表性LLM依次完成三项中间任务:识别哪些测试用例会触发缺陷、预测缺陷相关代码行的执行覆盖、生成补充测试用例,最后生成最终补丁。系统自动比对中间产物与真实标签并统计补丁测试通过率,另外对812个抽样修复做人工分析,标注补丁和中间产物是否忠实于可用的修复证据。

Large language models (LLMs) have significantly advanced automated program repair (APR), yet existing evaluations remain largely result-centric and provide limited insight into hallucination during repair. In APR, hallucination may arise not only in final patches but also in the intermediate artifacts that guide patch generation. To address this gap, we perform a multi-layered analysis of hallucination throughout the APR process. Specifically, we characterize hallucination as the production of patches or intermediate artifacts that are not faithfully grounded in the available repair evidence. We examine repair hallucination in final patches and understanding hallucination in intermediate artifacts through three tasks, namely triggering testcase identification, line coverage prediction, and additional testcase generation.We then evaluate three representative LLMs on 832 Defects4J bugs through automatic evaluation and manual analysis. Our results show that both repair and understanding hallucinations remain prevalent. Across models and settings, only 21.0%-55.9% of generated patches pass the developer-written test suite. Moreover, although more accurate intermediate artifacts are generally associated with successful repairs, this relationship does not always hold. Manual analysis of 812 sampled repairs identifies repair hallucinations in 72.7% of cases, including patches that pass all available tests; incorrect causal localization and incorrect repair strategies account for 45.9% and 18.5% of these hallucinations, respectively. Meanwhile, models frequently misidentify triggering testcases, mispredict line coverage involving branching control flow, and generate additional testcases with missing bug-triggering conditions or incorrect expected behavior.

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

Beyond Code Generation: Reliability, Verification, and Cost Economics in the Agentic Software Development Lifecycle

编码代理推高提交量,合格发布没有同步跟上:如果你正用提交量、代码行数评估AI编程代理,这篇综述提醒:这些指标会把“写得多”误当成“交付得多”。它用2024–2026年9月的论文、企业报告、遥测与成本数据,把口径改成PQC和验证税。

两句看懂

只看代理提交量,会把生产力高估;这篇综述指出,提交暴涨不等于可发布软件同比增长。10万+GitHub开发者数据给出断层:提交级+180%,项目级+50%,发布级+30%,瓶颈落在验证与协调环节。

核心判断

代理让代码提交量剧增,但发布合格软件的增幅小得多;瓶颈在评审、测试、安全与运维。证据是10万+GitHub开发者研究提交+180%、项目+50%、发布+30%,以及斯坦福SWE-chat仅44%代码被采纳。

关键要点

1. 旧假设失效:用代码生成量或提交活跃度衡量代理,会漏掉评审、集成、测试、安全、部署、运维这些仍卡住的环节。 2. 方法与核查:综述不做新实验,核对2024–2026年9月多源证据;含3项RCT共4867名开发者完成任务+26.08%,以及10万+GitHub、SWE-chat、SWE-Marathon等数据。 3. 结果与动作:提交+180%到发布仅+30%,SWE-chat仅44%代码被采纳;改用PQC计数并核算验证税,再分配代理自主权和人审。

证据与结果

关键数字都需贴着原研究读:3项随机对照实验覆盖4867名开发者,完成任务+26.08%;10万+GitHub开发者研究显示提交级+180%、项目级+50%、发布级+30%;谷歌数据为年数百万代码评审评论,平均约60分钟作者跟进时间;斯坦福SWE-chat6000次会话中仅44%代码被采纳、44%轮次遭纠正;SWE-Marathon平均2720万token/次,所有配置pass@1未超30%,13.8%回合奖励作弊;FinOps基金会调查称98%从业者已管理AI支出,两年前为31%;Gartner称2028年AI编程成本或超普通开发者薪资,但这是预测。

打开论文原文
它要解决什么
AI编程代理让代码提交量剧增,为什么真正合格发布的软件产出没有同步增长?
研究路径
作者先收集2024–2026年9月的论文、高校研究、基准审计、企业报告、遥测与成本数据,再归纳四个概念:吞吐悖论指代码生成增速超过发布增速;PQC指通过可靠性门槛才计数的变更单位;验证税把下游评审、测试、安全、修复成本显性化;控制平面按成本、可靠性与人力预算分配代理自主权。随后用这套口径推演从有监督代理到受策略约束软件工厂的路径。
这对工程意味着什么
第一步行动:本周挑一条代理流水线,按PQC统计“过可靠性门槛的变更”,并单独记录评审、测试、安全、修复的验证税。要避开的捷径:别把提交活跃度增长直接当成交付能力提升,因为发布级增幅只有提交级的约六分之一。
证据定位
10万+GitHub开发者研究显示:提交级增幅180%,项目级降至50%,发布级仅30%。斯坦福SWE-chat中,只有44%代理代码被用户采纳,44%轮次遭纠正,且安全漏洞更多。SWE-Marathon所有配置pass@1未超30%,13.8%回合出现奖励作弊。2025年DORA调查近5000人显示:AI采用度越高,交付吞吐量越高,但交付稳定性反而下降。(筛选维度:可复核评测、软件工程方法)
适用边界
这是综述,不含新实验;所有数字来自原研究,作者未独立复核。部分证据如Gartner2028年成本预测属预测性判断,不是已实现测量;各项数字应按原研究适用范围解读。
方法与英文摘要

不做新实验,只汇总并交叉核对2024年至2026年9月的同行评审软件工程论文、高校研究、基准审计、大厂生产报告、开发者遥测与成本数据。引用对象包括3项随机对照实验共4867名开发者、10万+GitHub开发者研究、谷歌内部数据、2025年DORA调查近5000名从业者、斯坦福SWE-chat6000次代理会话、SWE-Marathon长程评测与东北大学token成本研究。

AI coding systems are moving from autocomplete and chat toward agents that can inspect repositories, edit multiple files, run tools, write tests, open pull requests, and work for long periods with limited supervision. This capability changes the bottleneck in software delivery. Recent field studies show meaningful gains in coding activity, but newer evidence also shows that those gains attenuate sharply between writing code and shipping reliable software. Review, integration, testing, security, deployment, and production operations remain constraining stages, while the economics are shifting from predictable per-seat licensing toward variable token, tool, sandbox, CI, and rework costs. This paper synthesizes peer-reviewed software-engineering research, university studies, benchmark audits, production reports from major technology companies, developer telemetry, and cost-management evidence released primarily from 2024 through September 2026. No new model experiment is claimed; numerical findings remain attributed to their original studies. The synthesis proposes four engineering concepts: the Agentic SDLC Throughput Paradox, Production-Qualified Change (PQC), the Verification Tax, and an Agentic SDLC Control Plane that allocates autonomy subject to cost, reliability, and human-attention budgets. An evidence-based horizon then maps today's supervised agents to future policy-bounded software factories. The central research question shifts from how much code an agent can generate to how much production-qualified value an engineering system can deliver per dollar, per reviewer-hour, and per unit of operational risk.

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

Ritgard: T(r)opical Islands of Socio-Technical Artifacts on GitHub

Ritgard把GitHub讨论画成3D岛屿地图,但效果数字不在这篇论文里:带新人看陌生仓库、做社区健康巡检时,逐条翻Issues和PR太慢。Ritgard给出一个可复用的可视化实现:文本嵌入聚类主题、LLM生成标签、岛屿地形高度表示讨论活跃度。但要先知道:这篇论文只讲实现,量化评估结果在它的前期工作[14]里。

两句看懂

GitHub仓库的Issues、PR、Discussions分散在不同页面、以自然语言书写,人工逐条阅读难以把握全貌,Ritgard用文本嵌入聚类主题、LLM生成标签,把每个artifact画成树、按主题聚成岛屿、用地形高度表示活跃度。可读性与实用性已在前期用户研究中评估,本文只补实现细节,没给具体数字。

核心判断

不逐条阅读也能把握GitHub项目社会技术历史——Ritgard给出了可视化实现方案(嵌入聚类+LLM摘要+3D岛屿地形),但量化验证结果在前期用户研究[14]中,本文未附具体数字。

关键要点

1. 旧缺口:现有工具多聚焦单一类型痕迹或代码本身,缺少同时覆盖Issues、PR、Discussions的高层总览,大仓库人工浏览成本高。 2. 方法与对照:嵌入算语义相似度定树/岛位置,LLM生成主题标签,地形高度由活跃度(如评论数)驱动,支持滑动时间窗(如一年);量化验证依赖前期用户研究[14],本文未附数字。 3. 结论与行动:可借鉴嵌入聚类+活跃度可视化做新人引导或社区巡检,但判断可读性效果要去查前期工作[14],不能只看本文。

证据与结果

本文未给出正式评估的数据集规模或分层协议,示例仅为golang-standards/project-layout单个GitHub仓库的可视化截图。可读性与实用性的用户研究评估记录在作者前期工作[14]中,该研究的指标、参与人数与结果数字未在本文摘录中给出。因此本文证据不足以支撑量化结论。

打开论文原文
它要解决什么
不逐条阅读海量GitHub Issues/PR/Discussions,怎样快速把握一个项目社会技术讨论的演化全貌?
研究路径
1) 通过GitHub API挖掘仓库的Issues、PR、Discussions;2) 对文本做嵌入编码,计算语义相似度;3) 按相似度聚类得到主题簇;4) 用LLM对簇生成主题摘要/标签;5) 每个artifact渲染为一棵树,树间距离对应语义相似度;6) 每个主题渲染为一座岛屿;7) 地形高度按活跃度(如评论数)计算,可选滑动时间窗(如一年)只统计窗口内活跃度,呈现演化过程。
这对工程意味着什么
第一步行动:对自己维护的仓库跑一遍嵌入聚类+活跃度加权可视化,用于新人上手或社区巡检。要避免的捷径:不要仅凭本文文字就断定这种可视化可读、好用,量化结果在前期工作[14]里,本文没给。
证据定位
本文未提供具体评估数据。可读性与实用性的用户研究结果见其前期工作[14],本文仅描述实现与可视化设计,未给出量化对比数字。示例仅为单个仓库的可视化截图。(筛选维度:软件工程方法)
适用边界
本文只用单个示例仓库(golang-standards/project-layout)展示效果,未在摘录中提供多仓库规模测试或有统计代表性的数据;可读性/实用性的量化评估来自另一篇前期工作,而非本文。
方法与英文摘要

数据来自GitHub仓库API拉取的Issues、PR、Discussions(示例仓库为golang-standards/project-layout)。流程是:逐条做文本嵌入,按语义相似度聚类成主题,用LLM摘要生成主题标签。每个artifact渲染成一棵树,树间距离反映语义相似度;每个主题渲染成一座岛屿;地形高度按活跃度(如评论数)计算;可用可配置滑动时间窗(如一年)限定统计区间,展示随时间的演化。

A software project is more than just code. Non-code artifacts often document the human processes and decisions behind source code. The rationale behind a library change, an architectural decision, a problem encountered by a user are all examples of information typically present in socio-technical artifacts (STAs), created and persisted in channels separate from the repository itself (yet sometimes very close---e.g., GitHub Issues with GitHub repositories). These STAs are a trove of information about the project's architecture and its evolution, containing details and insights that code alone cannot provide. Unfortunately, this information is not easily extracted and explored as STAs are frequently fragmented over different communication channels, and are written in natural language. We present Ritgard, a tool that mines GitHub repositories for their STAs, namely Issues, Pull Requests, and Discussions, and visualizes them as 3D islands covered with trees. Each tree represents a single artifact and each island is a topic extracted from the artifacts through a combination of text embedding and text summarization. The terrain of the islands rises out of the ocean as the topic becomes active and sinks back in when it becomes stale, thus depicting the evolution of features and concerns throughout the project's lifetime. We describe the tool's usage and implementation, showing the numerous technical challenges behind Ritgard's visualization.

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

From Silicon to Boot Code: Extending Automated Program Repair to Firmware-Layer Security Workarounds

APR从RTL芯片修复扩展到UEFI固件补丁:研究测试:RTL芯片修复方法能否移植到UEFI固件层。挖掘EDK II三万余次提交构建缺陷字典,四类定位器均达到100%召回,但C语言场景精度仅2.1%-15.5%,汇编和HOB场景精度100%。

两句看懂

以往芯片漏洞流片后只能靠人工定位并编写固件补丁,该研究把RTL阶段的字典引导自动修复方法搬到UEFI固件层测试。用EDK II三万六千余次提交挖掘缺陷字典并构建四个定位器验证,结果全部达到100%召回,但C语言场景精度仅2.1%-15.5%。

核心判断

RTL式字典引导自动修复方法可以移植到UEFI固件层完成缺陷定位,证据:四个独立定位器在真实历史提交上全部达到100%召回,其中汇编和HOB场景精度也达100%。

关键要点

1.旧假设:自动程序修复(APR)只在流片前对RTL/HLS设计定位修复;芯片流片后固件层的补丁只能人工编写,已有的固件热补丁工具(如AutoPatch、StackPatch)只管部署已写好的补丁,不负责生成补丁内容。 2.构造方法:对EDK II(UEFI)固件仓库全部36153次提交按diff相似度聚类,不依赖已知CVE编号挖掘修复模板,恢复全部3个已知CVE修复系列并新发现2个候选缺陷家族;据此构建4个独立定位器(C语言推测屏障缺失/CVE-2017-5753、C语言边界检查缺失、x86汇编RSB填充缺失/CVE-2017-5715、HOB代码整数溢出防护缺失),以历史修复提交作真值验证;另在未见文件上做留出测试,并独立新增第5个字典条目(CVE-2018-3630)。 3.决定性结果:四个定位器召回率均为100%,但C语言两类精度仅2.1%-15.5%,汇编和HOB类精度达100%;误报根因中77%-90%属于两种过程内原因,过程间别名分析缺口实测为15%-20%;朴素语法基线召回率最高仅14%,远低于该方法的100%。

证据与结果

数据源:EDK II(UEFI)固件仓库全部36153次提交历史。四个定位器分别针对C语言(Spectre v1推测屏障缺失、解压库边界检查缺失)、x86汇编(RSB填充缺失,CVE-2017-5715)、HOB代码(整数溢出防护缺失)。以历史修复为真值:四者召回率均100%;精度C语言2.1%-15.5%,汇编与HOB达100%。误报77%-90%源于两种过程内原因,过程间别名分析缺口实测15%-20%。留出测试中Spectre v1未见文件仍100%召回;独立新增CVE-2018-3630条目验证方法可低成本扩展;朴素语法基线召回最高仅14%。

打开论文原文
它要解决什么
为芯片设计时的RTL自动修复方法,能否扩展到芯片流片后的固件层,自动定位并合成安全补丁,而不仅是人工写补丁后再部署?
研究路径
1)对EDK II全部36153次提交做diff内容相似度聚类,不依赖CVE编号挖掘修复模板;2)基于挖出的真实修复证据,为四类缺陷(C推测屏障缺失、C边界检查缺失、汇编RSB填充缺失、HOB整数溢出防护缺失)各建一个定位器;3)以历史修复提交为真值验证召回率与精度;4)对C语言误报做根因分析,区分过程内与过程间(别名分析)两类原因;5)在未见过的文件上做留出测试,并独立新建第5个字典条目验证泛化。
这对工程意味着什么
用真实历史提交而非人工规则挖掘缺陷模式能保证高召回率;但不要只看召回率就判定可用,C语言场景精度仅2.1%-15.5%,需结合根因分析评估过程间别名分析等误报来源再决定是否投入使用。
证据定位
四个定位器全部达到100%召回;C语言两类精度仅2.1%-15.5%,汇编和HOB类精度100%。朴素语法基线召回最高仅14%,远低于该方法的100%。C语言误报77%-90%源于过程内两类原因,过程间别名分析缺口实测15%-20%。(筛选维度:软件工程方法)
适用边界
仅在EDK II单一固件仓库、五类缺陷签名(含独立新增的CVE-2018-3630)上验证;C语言定位器精度低至2.1%-15.5%,误报根因依赖人工分析;未在其他固件代码库上做外部验证。
方法与英文摘要

数据源:EDK II(UEFI)固件仓库全部36153次提交历史。先用diff相似度聚类挖掘器(不依赖CVE编号)恢复3个已知CVE修复系列并新增2个候选缺陷家族;再据真实修复构建4个定位器:C语言缺失推测屏障(CVE-2017-5753)、C语言缺失边界检查(解压库CVE)、x86汇编缺失RSB填充(CVE-2017-5715)、HOB代码缺失整数溢出保护;以历史修复为真值验证。

Automated program repair (APR) research has been constrained to design time. Current techniques localize and fix bugs in RTL or HLS designs before a chip reaches production. Once a hardware vulnerability surfaces post-silicon, the patch must be manually generated: existing automation addresses patch deployment but not patch synthesis. We study the feasibility of extending a dictionary-guided, localize-synthesize-validate APR methodology originally developed for RTL repair to this firmware layer. An automated commit-clustering miner surfaces recurring fix templates across the EDK II (UEFI) firmware repository's full commit history without depending on known CVE identifiers, recovering all three known CVE-fix campaigns and surfacing two additional candidate bug families. Grounded in real fix evidence, we build four independent localizers: missing speculation barriers in C (CVE-2017-5753, Spectre v1), missing bounds checks before array writes in C (a decompression library CVE), missing Return Stack Buffer stuffing in x86 assembly (CVE-2017-5715), and missing integer-overflow guards in Hand-Off Block creation code (surfaced by the miner itself). All four achieve 100% recall; precision ranges from 2.1-15.5% on the C families to 100% on the assembly and HOB families. Root-cause analysis of the C-family false positives attributes 77-90% to two intra-procedural causes, isolating the inter-procedural alias-analysis gap as a measured 15-20% rather than an estimate. A held-out test confirms Spectre v1 localization holds at 100% recall on unseen files; a fifth, independently built dictionary entry (CVE-2018-3630) shows the methodology extends to a new bug signature at low cost; and a naive syntactic baseline recalls at most 14% where our detector recalls 100%. We frame these results within a broader research agenda for a unified hardware-to-firmware correctness lifecycle.

代码质量与优化(0 篇)

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

UI 与 GUI Agent(0 篇)

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

个人知识与本体(3 篇)

个人知识与本体 6/30

MutMem-V2: Cryptographically Authorized Mutation in Persistent Agent Memory Portable Verification and Reproducible Evidence

持久记忆变更协议可独立复核,但复核不等于真伪保证:做持久智能体记忆系统的审计或合规校验时,评审者最大的痛点是必须信任生产数据库和运行时,无法独立核验授权变更是否真的合规。MutMem V2针对这一点定义了可移植验证协议:18类版本化对象模式、39条召回向量、15条变更向量,并用Node与Python双实现交叉核对,在72个结构/加密终态上判定完全一致,生产衍生合规语料42/42例通过。

两句看懂

MutMem V1公开了持久记忆授权变更机制,但缺少可独立核验的证据契约,也没有从全新安装到可复核结果的路径,V2补上这一缺口,定义了版本化对象、终态判定与可复现证据栈。独立Node与Python实现在72个结构/加密终态上判定一致,生产语料42/42例通过,而120单元金丝雀实验仅证实显式标记可追踪,未验证语义真实或通用防护。

核心判断

能否在不信任生产系统的前提下独立核验持久记忆变更协议?能,路径是版本化对象、双实现终态比对与合规语料验证。但语义真实性、通用防护与独立第三方复现仍未证明,120单元金丝雀实验仅覆盖显式标记场景。

关键要点

1. V1只报告效用与投毒等实证结果,没有可移植验证契约,评审者必须信任生产数据库与运行时。2. V2定义18类对象模式、39条召回向量、15条变更向量,用独立Node/Python双实现交叉核对72个终态,另测42例合规语料和120单元金丝雀实验。3. 双实现判定72/72一致、语料42/42通过,但金丝雀只证明显式标记可追踪;落地时应先定义可版本化对象与终态清单,别把标记追踪当防护证明。

证据与结果

评测对象是协议自身而非外部数据集。72个结构/加密终态,Node与Python双实现判定与主因一致率72/72。生产衍生合规语料28个必需类别共42例,42/42通过。全新Node v26.8.1安装环境测首启/重启/调度就绪,无实验性记忆。金丝雀实验120单元,分显式标记与干净两类,仅验证标记可追踪,未测语义真实或防护效果。历史V1效用与投毒实证结果保留为历史数据,不计入V2当前证据。

打开论文原文
它要解决什么
在无法信任生产数据库或运行时的前提下,评审者如何独立核验持久记忆授权变更协议的完整性、授权与可复现性?
研究路径
步骤:1)定义18类对象模式与领域分离的对象/包承诺哈希;2)规定召回证据成员与顺序、外部信任锚、身份纪元、撤销与授权状态、请求回执;3)用独立Node/Python验证器对72个结构/加密终态逐一比对判定与主因;4)对28个必需类别、42例生产衍生语料重复核验;5)在全新Node v26.8.1环境测试首启/重启/调度就绪;6)单独运行120单元金丝雀实验(显式标记对干净单元);7)公开表格由自哈希聚合数据重新生成,独立验证器复核统计与结论边界。
这对工程意味着什么
落地记忆变更系统时,第一步先定义可版本化的对象模式与终态清单,并用两套独立实现交叉核验,而不是只信自身日志。要避免的捷径:把小规模标记追踪实验(如这120单元)当成通用防护或安全性证明。
证据定位
独立Node与Python实现在72个结构与加密终态上判定和主因完全一致(72/72)。生产合规语料28个必需类别共42例,42/42通过。清洁安装在Node v26.8.1上无历史记忆即达首启/重启/调度就绪。120单元金丝雀实验仅证实显式标记可被追踪,不构成防护证明。(筛选维度:形式化验证、可复核评测)
适用边界
金丝雀实验仅120单元且只测显式标记穿越,不代表通用鲁棒性;合规语料42例来自单一生产衍生来源,未经独立第三方复现;历史V1实证结果(使用GPT-5.4生成、GPT-5.6 Terra评判)保留为历史数据,未在V2重跑。
方法与英文摘要

协议定义18类版本化对象模式、39条召回向量、15条变更向量、37种召回失败原因。核验手段是用独立的Node与Python实现,对72个结构/加密终态逐一比对判定与主因是否一致;再用生产衍生合规语料(28个必需类别、42例)测一致性;并在全新Node v26.8.1环境完成首启/重启/调度就绪测试;另设120单元金丝雀实验,显式标记单元与干净单元对照。所有公开表格由自哈希聚合数据重新生成,独立验证器复核统计与结论边界。

MutMem V1 introduced retention-preserving, cryptographically authorized mutation for persistent agent memory but did not provide a complete portable verification contract or clean-install reproduction path. MutMem V2 closes that publication gap without introducing a second memory engine. It specifies exact canonical bytes, domain-separated object and bundle commitments, mandatory recall-evidence membership and ordering, external trust anchors, identity epochs, revocation, authorization, request receipts, ordered disclosure, and three mutation terminal types. The released protocol contains 18 versioned object schemas, 39 recall vectors, 15 mutation vectors, and 37 closed recall failure reasons. Independent Node and Python implementations agree on verdict and primary reason for all 72 structural and cryptographic terminals; a production-conformance corpus agrees on 42/42 cases across 28 required classes. A clean Node v26.8.1 installation reaches first-boot, restart, and scheduler readiness with no experimental memories. A separately scoped 120-unit Canary experiment supports only explicit-marker traversal. Every public table regenerates from a self-hashed aggregate, and an independent verifier reconstructs the statistics and claim boundaries. Historical V1 empirical results remain historical. MutMem V2 supports claims about portable integrity, authorization, traceability, conformance, and reproducibility under stated assumptions; it does not establish semantic truth, universal robustness, or independent replication.

个人知识与本体 6/30

Invalidation Contracts for Cross-Episode Agent Memory

给缓存的API修复建议加行级版本戳:合规率最高提升66.7个百分点,代币成本恢复29…:你的智能体如果跨episode缓存API错误修复建议来省代币,服务器数据一漂移,缓存的建议就会静默失效——任务失败你还不知道原因。这篇工作给出一个解决办法:服务器为每条建议附版本戳和可缓存性提示,客户端按行级粒度驱逐失效条目,而不是连坐清空整张表。

两句看懂

朴素缓存修复建议能省5-28%代币,但服务器数据漂移会让它静默失效,重新推导又抵消节省。引入行级失效契约后,7个模型合规率最高提升66.7个百分点,4个模型代币成本恢复29-33%;而表级失效在5个模型上把首次成功率打到0%。

核心判断

能否在不放弃代币节省的前提下修复缓存失效?可以:行级版本戳协议把'建议是否有效'与'模型是否愿意应用'分离,行级失效在4/7模型上挽回29-33%代币成本,而表级失效反而让5/7模型首次成功率归零。

关键要点

1. 旧失败:API错误恢复建议没有有效期元数据,漂移后缓存静默失效,智能体只能靠重放错误试错发现。 2. 方法与受控检查:六级协议(版本戳到依赖向量),在7个模型、3种路径、2个领域、约9400个episode上对比四种记忆设置,并区分协议决定的有效性(零契约失败)与模型决定的合规率。 3. 决定性结果与行动:行级失效合规率提升0-66.7个百分点、4/7模型代币成本降29-33%,表级失效把5/7模型首次成功率打到0%——所以失效粒度用行级,别用表级。

证据与结果

覆盖7个大模型(含Claude Haiku 4.5、Claude Sonnet 5)、3种服务路径、2个领域、约9400个episode;协议分六级(版本戳到依赖向量)。指标为合规率、代币成本、驱逐精度。结果:朴素缓存较无记忆省5-28%代币;行级失效使合规率升0-66.7个百分点、4/7模型代币成本降29-33%、驱逐精度1.00;表级失效使5/7模型漂移后首次成功率降至0%。合规率因模型差异巨大:Claude Haiku 4.5达100%首次合规,Claude Sonnet 5仅11%及以下,原因是其输入模式保守,拒绝添加原请求没有的字段。契约增加15%响应负载。

打开论文原文
它要解决什么
服务器数据漂移后,智能体缓存的API错误修复建议如何避免静默失败,同时不放弃缓存带来的代币节省?
研究路径
服务器为每条恢复建议附加版本戳与可缓存性提示;客户端记忆库缓存建议并注入下一次请求;服务器数据漂移触发reload端点;反馈生成器在响应中附带失效元数据;客户端驱逐策略按行级差异比对版本戳,精确驱逐失效条目、保留其余缓存,无需试错重放。
这对工程意味着什么
第一步行动:把缓存失效粒度设为行级而非表级,并在响应中显式携带版本戳——表级失效会连坐清空未漂移的同表条目,把5/7模型首次成功率打到0%。要避免的捷径:不要只靠失败后重新推导兜底,那会抵消缓存本应节省的代币。
证据定位
行级失效使7个模型的合规率提升0-66.7个百分点(其中三个模型提升55.6-66.7),4/7模型代币成本降29-33%,行级驱逐精度达1.00。表级失效则使5/7模型漂移后首次成功率降至0%。版本戳有效性在7个模型、3种路径下零契约失败。契约本身增加15%响应负载。(筛选维度:形式化验证、可复核评测)
适用边界
评测限于两个领域、7个特定模型和3种服务路径;合规率差异与具体模型的输入模式保守倾向(如拒绝新增字段)相关;结论对其他模型或更多领域的外推未经验证。契约还会增加15%响应负载。
方法与英文摘要

设计一个六级失效协议:从版本戳、行级差异到依赖向量比较。服务器给每条恢复建议附版本戳和可缓存性提示;客户端缓存建议并注入下一次请求;漂移触发reload端点后,响应里带失效元数据;客户端按行级比对版本戳,只驱逐失效行,保留其余缓存。评测覆盖7个大模型、3种服务路径、2个领域、约9400个episode,对比无记忆、朴素缓存、行级失效、表级失效四种设置。

LLM agents that cache recovery suggestions from API errors can skip re-derivation in later episodes, spending fewer tokens and fewer model calls on constraints they have already learned. Server-side data drift turns those cached fixes into silent failures, and the usual remedy, re-deriving on every episode, gives the savings back. We introduce invalidation contracts, a protocol layer that attaches version stamps and cacheability hints to every recovery suggestion so the client can evict stale entries without trial and error, and keep the rest. The contract decomposes realized savings into two independent factors: validity, the fraction of cached suggestions that remain correct after a drift event, and compliance, the fraction the planner applies on the first attempt. Validity depends only on the protocol and is vendor-independent. Compliance depends on the planner model: identical wire bytes yield 100% first-try compliance on Claude Haiku 4.5 and 11% or below on Claude Sonnet 5, which exhibits input-schema conservatism, refusing fixes that add fields the original request did not contain. We evaluate across seven models, three serving paths, two domains, and approximately 9,400 episodes. Row-level invalidation raises compliance by 0 to 66.7 percentage points across the seven models, 55.6 to 66.7 on three, and recovers 29-33% of baseline token cost on four of seven models, while table-level invalidation destroys co-located entries and drops post-drift first-try rates to 0% on five of seven. Eviction precision is 1.00 at row granularity on every model under the row-level oracle of Section 4.1. The contract adds 15% to response payload. Version-stamp validity is deterministic by construction and produced identical results across every model and serving path, with zero contract failures in the entire evaluation.

个人知识与本体 5/30

Compact-Memory LLM Agents via Online Max-Member Clustering and Atom-Aware Packing

压缩记忆的关键不在检索召回,而在合并写入规则与分组打包:如果你的长程代理记忆预算只有2k-5k token,调检索召回率可能是在错的方向上用力。实验显示,真正决定问答质量的是流式记忆的合并规则和检索内容的组装方式,方法RSM-full给出了可复制的具体实现。

两句看懂

长程LLM代理在紧凑记忆场景下,只看检索召回率无法说明真实问答质量;RSM-full用余弦门控max-member合并写入规则加atom感知分组打包器解决这一问题。AMA-Bench 4k预算下,该方法达Full-Context质量83%、耗32%token,比Online K-Means高3.5-6.0pp(p<.001),RealMem上复现同样模式。

核心判断

决定紧凑记忆问答质量的主因是合并规则与组装方式,而非检索召回:AMA-Bench上4k预算达Full-Context质量83%、token仅32%,比Online K-Means高3.5-6.0pp(p<.001),消融显示合并规则+5.7pp、打包+5.0pp。

关键要点

1.旧评测多只看召回率;≤5k token紧凑预算下,真正决定问答质量的是合并与组装方式,而非单纯检索召回。 2.RSM-full用余弦门控max-member合并写入规则加atom感知分组打包器,在AMA-Bench(4k预算,四种子)与RealMem(三种子)上与七种基线做对比消融。 3.AMA-Bench达Full-Context质量83%、token仅32%,比Online K-Means高3.5-6.0pp(p<.001);落地动作:优先改合并写入规则和分组打包,而非只调召回率。

证据与结果

AMA-Bench(主评测)4k token预算、四种子,三种子消融对比Online K-Means、matched-τDP-means、flat拼接;RealMem对比Budget-RAG、BM25-RAG、Streaming-Proto、A-MEM。结果:AMA-Bench达Full-Context质量83%、token 32%,优于Online K-Means 3.5-6.0pp(p<.001);合并规则+5.7pp,分组打包+5.0pp。RealMem上优于Budget-RAG +0.69pp(p=.006)、Streaming-Proto +2.97pp、A-MEM +1.65pp(p<.001),与BM25-RAG相当(+0.27pp,p=.47)。BGE归一化AMA-Bench上检索规则贡献为零(p=0.40);LoCoMo、LongMemEval上优势减弱或消失。

打开论文原文
它要解决什么
在约2k-5k token的紧凑记忆预算下,决定问答质量的到底是检索召回,还是记忆合并与内容组装方式?
研究路径
写入时逐条接收片段h,计算它与各atom运行归一化均值μm的余弦相似度,取最大值对应的atom;相似度超阈值就并入该atom,否则新建atom。检索后用atom感知分组打包器按atom分组组装上下文,而非把所有片段flat拼接。高阶存储机制仅作为部署路径附录留存,不是主结果依据。
这对工程意味着什么
第一步动作:先审查你的记忆写入规则和上下文组装方式,按合并+分组打包改造,因为消融显示这两项贡献主要收益(+5.7pp、+5.0pp)。要避开的捷径:不要只靠提升检索精度来救质量,实验证明那未必带来同等收益。
证据定位
AMA-Bench 4k预算下,RSM-full达到Full-Context质量的83%,只消耗32%的token,比Online K-Means高3.5-6.0pp(p<.001)。消融显示:合并写入规则贡献+5.7pp,分组打包贡献+5.0pp(vs flat拼接)。(筛选维度:可复核评测)
适用边界
优势仅在约2k-5k token的紧凑预算区间成立;高token预算下更强基线仍占优;LoCoMo、LongMemEval等场景压缩记忆优势减弱或消失;BGE归一化AMA-Bench上检索规则贡献为零。
方法与英文摘要

RSM-full由两部分组成:一是余弦门控max-member合并写入规则,新片段与各atom均值余弦相似度超过阈值就并入该atom,否则新建atom;二是atom感知分组打包器,按atom分组组装检索内容,而不是flat拼接。评测用AMA-Bench(主评测,4k token预算,四种子)和RealMem(独立长程人设记忆评测,三种子),对比Online K-Means、matched-τDP-means、flat拼接、Budget-RAG、BM25-RAG、Streaming-Proto、A-MEM。

Many long-horizon LLM deployments face tight prompt budgets: latency, cost, and context limits make full-context prompting impractical as interaction length grows. The key question is then not raw recall alone, but which memory design gives the best quality--token trade-off in the compact-memory regime. We present \textbf{RSM-full}, an online clustered-memory pipeline designed for a strong quality--token Pareto point. RSM-full combines two design choices: a cosine-gated \emph{max-member merge} write rule and an atom-aware grouped context packer. On AMA-Bench, our primary compact-memory benchmark, it reaches $83%$ of Full-Context quality at $32%$ of the token cost at a $4$k budget; under four-seed averaging it beats the closest streaming-clustered baseline (Online K-Means) by $+3.5$--$6.0$,pp ($p{<}.001$) across the whole ${\sim}2.6$k--${\sim}5$k regime. Three-seed ablations show most of this gain comes from the merge rule ($+5.7$,pp over Online K-Means and matched-$τ$ DP-means) and the grouped packer ($+5.0$,pp over flat concatenation). The pattern reproduces on RealMem, an independent long-horizon persona-memory benchmark: RSM-full improves on Budget-RAG ($+0.69$,pp, $p{=}.006$), is on par with BM25-RAG (paired $Δ{=}{+}0.27$,pp, $p{=}.47$; we do \emph{not} claim BM25 equivalence in the equivalence-test sense), and significantly outperforms Streaming-Proto ($+2.97$,pp) and the closest reproduced 2025 agentic-memory baseline A-MEM ($+1.65$,pp, $p{<}.001$). Across benchmarks the message is consistent: under tight budgets, compact-memory performance is driven mainly by how streaming memories are merged and how retrieved content is assembled. Overall, RSM-full is most useful when answeroughly $2k$--$5k$ prompt tokens, where itdefines a strong compact-memory Pareto point; higher-token baselines remain stronger outside this regime.

人机协同与对齐(0 篇)

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

本轮分类概览

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

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

近一个季度监测日历

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

近 14 次监测窗口

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

本轮新增候选(3 篇)

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

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

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

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

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

代码质量与优化(0 篇)

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

UI 与 GUI Agent(0 篇)

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

个人知识与本体(3 篇)

个人知识与本体 · 0/30 · 2026-09-04模型升级后智能体记忆可迁移性研究受控实验显示固定模式知识图谱迁移稳定,压缩笔记则与模型强耦合Does Your Agent's Memory Survive a Model Upgrade? A Controlled Study of Memory Portability

Model upgrades are routine; memory migrations are not. An agent can keep the same memory store and still forget: a new model may interpret old notes differently, mixed embedding versions may break retrieval, and repair may fail without the original evidence. We compare memory as the same history is preserved verbatim for long-context reading (LC-RAW), divided into chunks for retrieval-augmented generation (RAG), compressed by a model into natural-language notes (NOTES), or normalized into a fixed-schema knowledge graph (KG-fixed). The study uses 48 synthetic histories with randomized answer codes, exact scoring, and two open-weight models with sub 10 billion parameters. Our measurements show that fixed-schema structures transfer reliably, with KG-fixed accuracy changing by only $+0.0004 \pm 0.0020$ following a writer swap. Conversely, compressed NOTES exhibit high model coupling, with accuracy shifting asymmetrically by $+9.91$ or $-13.28$ percentage points depending on the specific migration direction. In RAG systems, partial embedding migrations using a 50/50 mixed index capture only a 4.96-point accuracy improvement, forfeiting the majority of the 11.90-point gain achieved through full re-embedding. Diagnostic decomposition attributes 80% ($0.467 \pm 0.014$) of the NOTES accuracy deficit to information lost during initial construction, whereas retrieval failures drive 81% ($0.364 \pm 0.012$) of the RAG deficit. Finally, store-only repair of NOTES fails to reach a 90% performance recovery target in all 48 test cases, whereas retaining the raw source history enables successful recovery in 34 of 48 cases for one tested direction. These findings highlight the necessity of direction-specific migration testing, strict embedding space isolation, and the retention of source histories for memory repair.

阅读 arXiv 原文
个人知识与本体 · 5/30 · 2026-09-04紧凑记忆代理的在线聚类与打包方法在AMA-Bench上以32%代币成本达到83%全上下文质量,优于流式聚类基线Compact-Memory LLM Agents via Online Max-Member Clustering and Atom-Aware Packing

Many long-horizon LLM deployments face tight prompt budgets: latency, cost, and context limits make full-context prompting impractical as interaction length grows. The key question is then not raw recall alone, but which memory design gives the best quality--token trade-off in the compact-memory regime. We present \textbf{RSM-full}, an online clustered-memory pipeline designed for a strong quality--token Pareto point. RSM-full combines two design choices: a cosine-gated \emph{max-member merge} write rule and an atom-aware grouped context packer. On AMA-Bench, our primary compact-memory benchmark, it reaches $83%$ of Full-Context quality at $32%$ of the token cost at a $4$k budget; under four-seed averaging it beats the closest streaming-clustered baseline (Online K-Means) by $+3.5$--$6.0$,pp ($p{<}.001$) across the whole ${\sim}2.6$k--${\sim}5$k regime. Three-seed ablations show most of this gain comes from the merge rule ($+5.7$,pp over Online K-Means and matched-$τ$ DP-means) and the grouped packer ($+5.0$,pp over flat concatenation). The pattern reproduces on RealMem, an independent long-horizon persona-memory benchmark: RSM-full improves on Budget-RAG ($+0.69$,pp, $p{=}.006$), is on par with BM25-RAG (paired $Δ{=}{+}0.27$,pp, $p{=}.47$; we do \emph{not} claim BM25 equivalence in the equivalence-test sense), and significantly outperforms Streaming-Proto ($+2.97$,pp) and the closest reproduced 2025 agentic-memory baseline A-MEM ($+1.65$,pp, $p{<}.001$). Across benchmarks the message is consistent: under tight budgets, compact-memory performance is driven mainly by how streaming memories are merged and how retrieved content is assembled. Overall, RSM-full is most useful when answeroughly $2k$--$5k$ prompt tokens, where itdefines a strong compact-memory Pareto point; higher-token baselines remain stronger outside this regime.

阅读 arXiv 原文
个人知识与本体 · 3/30 · 2026-09-04原子记忆驱动的智能体推荐系统将用户与物品记忆拆为原子单元,以多跳语义路径生成可解释推荐证据AtomRec: Evolving Atomic Memory for Agentic Recommendation

Agentic recommender systems use large language models to maintain semantic memory and support evidence-aware recommendation. However, existing memory mechanisms often compress user and item information into coarse summaries and connect them with scalar collaborative links, making it difficult to preserve fine-grained preference stages or retrieve interpretable evidence as user interests evolve. We propose \textsc{AtomRec}, an agentic recommender with evolving atomic collaborative memory. \textsc{AtomRec} represents user and item memories as structured atomic units, builds semantic links across related memories, and evolves related historical fields when new interactions arrive. During recommendation, it retrieves linked memories as multi-hop evidence paths rather than isolated neighbor summaries, allowing collaborative signals to support grounded ranking. Experiments on four public benchmarks show that \textsc{AtomRec} consistently outperforms state-of-the-art agentic and memory-augmented baselines, with around 8.5\% average relative improvement across metrics.

阅读 arXiv 原文

人机协同与对齐(0 篇)

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