Skip to main content

7-9月Paper Reading

· 21 min read
Tags:
ayanami

放点觉得有意思的部分和没意思的部分。

SAE用于AI搜索的可解释性​

2026-06-08

先放上最近看到的有趣的一篇：https://arxiv.org/abs/2605.29507

AI搜的可解释性一直是疑难杂症问题，纵然有多向量归因、cite等做法，使用起来场景限制也很大。这篇文章把SAE用到了AI搜上还是令人挺新奇的。

大体上就是，取embedder的SAE将稠密特征变成稀疏特征，然后对某个SAE特征f，在文档集合里面选f激活比较高的，LLM总结得到f的可解释释义。

可能觉得这样novelty太低或者做不work，所以文章花了很大力气在讲一个米奇妙妙设计：在做SAE之前，先做一次特征增强。大体上是把embedding任务分成三类——一类QA，一类意图，一类总结，用LLM产出这三类的带COT的文档，重新生成嵌入，这样先在大方向上分离的再进行SAE抽小特征。

不做这样的特征增强几乎完全没训出来。

由于不太懂可解释性，感觉是有趣的做法，就是不知道那个可疑的图带来了多大的性能提升。但反正我尝试把SAE直接用到我的工作里面的时候直接和random差不多，所以这个trick应该还是重要的。

Socratic-SWE：自进化Coding Agent的深度解剖​

接下来评这篇，前两天刚出的，感觉要得罪人了，又是本校网红组的paper：

Socratic-SWE: Self-Evolving Coding Agents via Trace-Derived Agent Skills https://arxiv.org/abs/2606.07412

方法云山雾罩的，绕一大堆公式，看起来非常promising但细究下来可疑的地方很多，慢慢细讲。

文章target很直接，自进化通过写更好的skill的方式提升端到端性能。采用的是Qwen3.5-9B同时做出题员Generator和解题者Solver，在SWE Smith上训，然后在SWE-bench系列测，标准操作。

但它用了几个让我觉得非常奇怪的做法：

  1. skill自进化是没有品味的，做烂的topic，我直接开地图炮，我觉得这方面现有的文章几乎都是rubbish
  2. 非常常见的Generator看错误轨迹对应出题，然后Solver解题的self play做法，虽然我非常质疑这样出出来的题目就是overfit，9B的模型既要改代码又要写测试还要设计query，设计出来的肯定是没法看的
  3. 为了让2看起来Promising，文章采用了一个很难以证伪的做法：让LLM和skill一起被更新——我又更新Generator，又更新Solver，又更新skill，最后说端到端性能提升协同进化。消融只做了1.不更新skill 2.换LLM RL的算法，并没有做固定LLM frozen的消融，这是非常奇怪的。你既然claim skill被更新了是主要收益，那原始模型+skill不应该有明显提升吗？感觉上，让LLM和skill一起动像是在让LLM过拟合system prompt
  4. 文中大量的神秘超参数。首先上来就是一个0.5/0.3/0.2的lambda加权，又是Generator Reward里面有一个神秘的梯度cosine，claim说这是为了让Generator出的题真的对Solver LLM的更新有帮助。我真的懒得喷梯度cosine，高维向量几乎均为处处正交是不知道的，要么show给我原始的log证明不是0，要么就是代码实现都错了

经典图画一堆公式一堆概念一堆绕来绕去，细究满头问号。核心novelty就是那个疑惑的RL操作。

关于自进化这个方向，我不是很想做。我觉得一万个人有一万个自进化，另一个是我觉得现在的自进化完全是在工程的基础上套概念拼novelty，非常空的说法。不如老实把长文能力、IF能力之类做好。

自进化中唯一有意思的​

看到的自进化相关的只有一个HL engineering比较有意思，LLM用规则进行自进化，很严格的限制了自进化的范围，并用标准的RL gym局限了任务类型：

https://trinkle23897.github.io/learning-beyond-gradients/#zh

另外一个可以看的是翁家翌做的，挺有意思——不是规则限定自进化，而是自进化的方式是写规则而不是写skill这种黑盒叠黑盒。

说白了这就像是自动生成证明或者AutoML，屎山可解释性总比模型强，控制好屎山的出入口就行直接当黑盒优化。

关于OPD、自蒸馏与Cursor的讨论​

关于Online Policy Distillation（OPD），推荐两篇：

OPD能这么火确实是学术炒工业冷饭炒没活了。不过我觉得这事最神秘的是Cursor用这个方法做出来了。Cursor的特权信息可能真有明确的真实信号，毕竟真实用户多轮反馈轨迹。如果从gt和hint泄露问题估计会非常大。

所有做SWE的人都知道gt有问题，SWE的gt能有50%正确率都了不得了，严判+无人工的话。

Dockerless：无环境训练的Verifier​

Dockerless这篇做的还可以的（唉同门捧臭脚）：https://arxiv.org/abs/2606.28436

省流： 基于"模型能无环境推理而不掉太多点"的观察，猜想能否无环境训练，则问题转化为做一个无环境的verifier。

方法则是类rubric，给到一个评估，先拆subquestion然后丢给subagent去explore & answer，再让一个模型聚合query、answer、gt、patch来进行verify。这里先拆后丢是一个希望获取更多角度的context的设计，尝试解决传统rubric judge下context window很难定并且很影响结果的问题。文章后续探索了拆的数量，表明k=4就差不多饱和了。

另一个insight是，training free的情况下，这类的测试时增强都是有上界的，所以利用原先的测试，把所有的rollout轨迹做拒绝采样，只留下能和原先测试gt judge一致的，做RFT。训出来这个verifier后，把这个送回去做无环境RL，发现效果不错。

我个人觉得重要的：

  • 这个拆了丢subagent确实解决了rubric的部分问题，很巧的思路
  • RFT的实验结论也确实是相对不同的角度，一般大家提无环境总是觉得环境做起来复杂麻烦正确性不好保证，这里的无环境从rollout时的行为来讲还挺有趣的，也体现了一定程度上researcher和engineer的思维方式不同

Pretrain数据构建学习​

2026-07-07

最近开始学习pretrain这边数据构建，先丢几篇感觉不错的：

Apple这篇写的是真不错： https://arxiv.org/html/2510.00866v4

NV这篇很符合直觉的工作，但感觉不如Apple那篇远甚： https://arxiv.org/html/2510.03264v1

由于并不熟这个领域，欢迎各位来帮忙丢论文。

Long Horizon Agent与General RL​

2026-07-13

https://arxiv.org/html/2601.16211v3

这一篇和coding没什么关系，但是是Naver Lab的，对他们的工作有比较高的好感于是看了看。描述的这个问题很有意思，感觉实质上对于Code Agent或许也有类似的关系，maybe可以研究一下。

https://arxiv.org/abs/2607.08964

这个bench看起来似乎能用来研究一些general的long horizon机制，先放一下。感觉似乎干了我之前想干的事情。

https://arxiv.org/html/2607.07508v1

General RL相关的，工程上的一种做法。

Language Model Harnesses as Compositional Generalizers​

2026-07-23

https://www.alphaxiv.org/abs/2607.language-model-harnesses

之前就很focus RLM，粗略地过了一遍这篇提出的insight感觉是很不错的。

Kimi的QK Clip与蒸馏中的Ranking Loss​

2026-08-06

等训练的过程中丢点东西吧，可能有空的话还是看点架构上的东西。

讲Kimi的QK clip的：

感觉还是很详细的。

除此之外最近有用到ranking loss，主要是解决MSE的过分锐化的问题： https://zhuanlan.zhihu.com/p/16484895233

读者不妨和AI讨论一下，为什么在真实"打标-训练"的黑盒蒸馏场景下，MSE会有不容易定阈值的问题，以及长尾的问题。虽然这两个问题实际上对应不同的需求场景，并且反直觉的是前者更为重要倒是。

关于数据量级的思考​

2026-08-07

最近有一个感觉是不同数据量级下的变化太大了。一个算法可能在10k、100k数据量work，在1000k就是负收益了。

对于不同大小的模型能吃下多少有效数据，理论上限性能大概是什么样子，不同训练阶段影响性能的卡点等，我觉得也是重要的经验能力，甚至某种意义上比各种算法trick重要得多。没有办法直接外推。

Google的C++ AI4SE实证分析​

2026-08-10

Google的C++ AI4SE实证分析：https://arxiv.org/html/2608.06640v1

需要更多这样的文章啊，感觉一篇大于100篇AI水文。

抖音多模态Embedding报告​

2026-08-10

抖音的多模态embedding报告：https://arxiv.org/pdf/2608.02148

很fashion的做法，指标也很不错，工业报告还是太全面了。居然看起来还是实习生solo的，牛逼。能看到许多之前工作的影子，但能全部组合上做出收益真不容易。

SFT vs RL的梯度正交性​

2026-08-10

https://arxiv.org/pdf/2608.03573

不错的可解释文章，展示方面下了功夫，well written。

RL和SFT的driven pattern不同是非常well known的事情，这里RL梯度方向的正交性是相当不奇怪的，MOPD的成功等大量先前的实验也佐证了这一点。但是SFT的不正交是一个有趣的发现和理论论证，以及这个不正交有严格的消融说明了梯度本身确实代表了下游评测集的性能退化。

另一个是都说SFT影响大、RL影响小，这里直观展示L2范数有~100倍的差异也是一个很不错的地方，让人有一个更定量的认识。

后面的机制解释的话，KL会趋向于小幅度更新之类的是非常直觉的结论，但GRPO的zero sum性质引导了正交性这个可能就没那么直接，还是对如何设计真正工业可用的xxPO/xxOPD有一些指导的。

至于论文的application的"并行强化学习"，感觉上像是对工业合版算法的简化，感觉有点过分粗暴了，并且如appendix消融显示的很依赖领域划分，感觉不是本文亮点。

SWE Refactor Bench​

https://arxiv.org/html/2608.09802v1

又看到自家文章了，但说实话感觉这篇不咋样，几个问题：

  1. 模型太老了，这篇文章拖了太久，寒假测的实验现在才发，最新的模型都已经是GPT 5.2了，感觉完全没有什么参考价值
  2. Refactor本质上怎么judge的交代不清。我觉得refactor应该是用类似ProgramBench的黑盒judge方法，但粗看下来本文章还是白盒黑盒混一起，用类SWE-bench的方式judge，也没有刻意讨论说refactor judge的过程中对于主要行为和边界行为的一致性的检查的保证。感觉上是yet another SWE-bench，虽然文章批评了SWE-bench系列的issue-test不匹配的错漏，但自己对于这个问题的保证方法也就是agent核查+人工检查，和SWE-bench并没有任何的区别，为什么要相信这里的人工比SWE-bench OpenAI的人工更好呢
  3. 部分结论已经过时。例如mini swe agent不如openhands、harness对模型性能表现很重要——首先这是非常well known的结论，完全不知道这个bench带来了什么新知；其次论文里面的表格细看都有明显的反这个结论的。我们知道前沿模型对于harness的依赖在逐渐减弱，如果使用opus5或者k3之类的模型，在不同的harness和数据集上，SWE表现都相当稳定。而论文里面的最大论据是GPT 5.2的从20到40的性能变化，但同一张表格里面就有Gemini-3-Pro的反向结论，以及甚至可以发现越强的模型性能变化越少，这也符合现在的认知
  4. Refactor真的是一个非常重要的问题吗？ 或者说，这种issue driven而不是spec driven的refactor符合真实场景吗？我们不妨回看可能甚至不太成功的rewrite Bun in Rust运动，也是一个totally spec driven的工作，并且refactor的另一个judge维度是所谓的代码整洁性和设计架构，而文章避过了这个问题，并没有给出除了测试之外更好的judge维度
  5. 文章强调了使用的是自动环境构建工具例如SWE Factory进行的构建，但在这里构建成功的，是否本身就带来了巨大的分布bias？能否给出一些难以构建的用例的存在证明？例如一个复杂的嵌入式库，它的构建就是困难的——而就在构建失败的筛选之中，自然就被筛掉了
  6. 修改的文件数或者说patch大小感觉只是一个间接指标，显然这个题相较于新的DeepSWE等bench是远不够难的，修改文件数多并不意味着这个问题就一定难，但文章避开了相关的讨论

核心问题：文章时效性太强了，现在文章拖太久就过时了。

SaliTrap Benchmark​

我不喜欢这个paper，这个问题我觉得很无聊，并且给出了一个非常无趣的结论。大意是说LLM存在"显著性偏差"，优先考虑显著的显式条件而非隐式的常识性前提条件。

Anything special? 这不值得写成一篇论文。这显然是一个指令遵循问题，并且是隐含指令的问题，御三家对于这个问题已经有相当全面的对齐描述。如果你认为这个问题很重要：

  • 有安全风险：应该构建实际越狱
  • 有隐含偏好：首先我们应该有实证分析证明这是一个问题而不仅仅是"当前的模型会不会做脑筋急转弯"，并且头部模型内部的对齐"通用价值观"是高于一般指令的。我认为通用价值观 > 一般指令 > 可能的预置知识是合理的，以及它在真正生产场景中存在问题，以及可能的如何解决

Another boring benchmark. 建议本文作者在对炒作的热点构建bench之前先阅读：

来了解一下对齐任务到底要解决什么问题。总之我认为这篇文章not even wrong。

OpenAI Reward-Seeking行为​

https://alignment.openai.com/measuring-reward-seeking

很神秘的模型行为。

合成数据评估标准​

有人问：既然提了分数不能准确体现数据的质量，我们还能用什么方法衡量一个合成数据集是好是坏？

我觉得合成数据的评估维度应该至少包括：

  1. 难度
  2. 区分度
  3. 多样性
  4. Scalable，成本和分布上是否合理，成本包含训练成本（loss token比例）和打标成本
  5. 泛化性，数据训了能不能在所有bench上都提点，换言之，这个数据到底想要让模型学什么pattern
  6. 有没有明显的垃圾
  7. 正确性，包括hack，本身是否well define等

这些问题不是丢给模型就能度量的，模型肯定分不清。有部分可以通过半人力半agent管道的方式，即人不断校正agent，剩下的在做之前就应该由人想清楚。

Loading Comments...