开头先聊聊做这个系列的初衷。每天泡在论文堆里，最耗时间的其实不是读，而是"筛"。arXiv上新论文一天几百篇，加上各大顶会放出来的录用稿、各种预印本平台的热门文章，真正和自己研究方向相关的可能就那三五篇。我试着把每天筛选后的结果整理成一份速递，不是简单的标题列表，而是把每篇论文的核心思路、实验设计、值得借鉴的地方拆开讲。今天是Day 2，我筛了四个方向——注意力机制的长序列优化、多模态模型的数据效率、代码生成模型的自我纠错能力、小模型蒸馏的损失设计。这四篇有一个共同点：它们都不是"又刷了一个SOTA"式的灌水文章，而是真的在解决落地时会卡住的实际问题。

1. Day 2选文逻辑：本周我盯的三个研究方向

每天筛论文这事，我有个固定的流程：早上先看arXiv的更新列表，按标题过滤掉明显无关的，剩下的摘要逐条扫，遇上感兴趣的再点进正文看图表和实验设置。但光看arXiv不够，Hot Papers、Papers with Code上社区讨论热度高的文章也得扫一眼，有些虽然不是最新上传，但讨论量和复现次数能说明问题。

今天选这四篇，背后是我最近在纠结的几个问题。

第一个问题是长序列推理的内存瓶颈。现在模型的上下文窗口越开越大，从4K到32K再到128K甚至更长，但真正把长序列跑起来的时候，显存开销和计算复杂度是实打实的坎。注意力机制是平方复杂度，这个大家都很清楚，但工程上到底怎么优化才能在不牺牲效果的前提下跑得更快，最近陆续有文章给出新思路。

第二个问题是数据效率。多模态模型大家都会用了，但微调一个专用场景的模型，比如工业质检或者医疗影像分类，往往只有几千张标注图，怎么在数据有限的情况下把效果拉起来？这比单纯堆数据有意思得多。

第三个问题是代码生成模型的可靠性。现在代码模型写个函数、补全个模块已经很厉害了，但生成出来的代码对不对、能不能跑、有没有边界情况没处理，这些才是决定能不能进生产环境的关键。自我纠错是最近讨论很多的方向，但纠错机制本身的可信度是个问题。

这三个方向综合下来，我挑出四篇今天想重点讲的论文。选文标准有三个：第一，问题定义清楚，不是泛泛而谈；第二，方法有可复现性，代码或伪代码逻辑完整；第三，实验设计有对比价值，能看出方法在什么条件下有效、什么条件下失效。满足这三条的论文，才有细读的价值。

另外补充一句，我不太追顶会刚出录用的那种热门文章，反而更关注更新两个月到半年之间、已经被社区验证过一轮的工作。这个时候讨论区往往有复现反馈和失败经验，比只是看作者自说自话要丰富得多。

2. 注意力机制的新解法：一个降低KV缓存压力的轻量改造

第一篇论文讨论的是长序列推理场景下KV缓存占用过高的问题。这里先解释一下背景：Transformer在推理时，每生成一个token，都要把之前所有token的Key和Value缓存下来，叫KV cache，避免重复计算。上下文越长，KV cache越大。32K上下文跑起来，KV cache的显存占用可能比模型权重本身还大，这在服务端部署时是很现实的成本问题。

这篇论文的思路不算复杂，核心做法是把KV cache做了分块处理，并且在注意力计算时引入了块级别的稀疏选择。具体来说，不再是每个token都跟全部历史token算注意力，而是先把历史KV按位置分块，然后用一个轻量的查询机制判断当前token最需要关注哪几个块，只算这几个块的注意力分数。块内再用原来的标准注意力，整体复杂度从平方降到了接近线性。

我读完的第一反应是，这个思路其实之前也有人提过，但这篇有两个细节做得比较扎实。

第一个细节是分块策略的自适应性。作者不是用固定的块大小，而是根据输入序列的语义边界动态切分。比如代码场景，一个函数定义块、一个for循环块，自然形成一个逻辑单元；文档场景，一个段落甚至一个章节就是单元。这样做的好处是，稀疏选择关注的是"语义块"而不是"固定位置的token片段"，在长文档问答效果下降的问题上缓解了不少。

第二个细节是训练策略。作者没有让模型在推理时才套上稀疏注意力的外壳，而是在训练阶段就用同样的分块稀疏策略。这意味着模型从训练时就学会了在稀疏模式下有效分配注意力，而不是训练时用全注意力、推理时才切换稀疏，避免了训练-推理不一致带来的效果下降。这个点我觉得是这工作最值得学的地方，因为很多近似注意力方法都栽在训练和推理不一致上。

实验部分，作者在32K和128K两种上下文长度下做了评测，用的模型规模是7B。对比基线是标准全注意力，以及另外两种主流的近似注意力方法。结果上，在128K长度的文档检索和摘要任务上，他们的方法把推理时的峰值显存占用降了接近40%，同时保持了和全注意力相近的准确率。注意是"接近"，不是完全一样，在部分长距离依赖敏感的任务上还是有1到2个百分点的回落。

实操层面的启发，如果你也在做长文本推理的工程优化，又不打算引入复杂的核函数或者自定义CUDA算子，这种分块稀疏注意力的思路值得试。它本质上是在用"更聪明的索引"换"更少的计算和内存"。我自己的经验是，这类方法效果的上限取决于块划分的质量，所以预处理阶段对文本结构做一次轻量的解析会很有帮助——比如代码的缩进层级、Markdown的标题结构，都可以作为分块的自然边界。另外，稀疏度不是越激进越好，块数量从8试到32，一般能找到一个效果和速度的平衡点。

3. 数据效率视角：多模态模型如何在小样本下微调不崩

第二篇论文来自多模态方向，讨论的是视觉-语言模型在小规模数据集上微调时的稳定性问题。这个问题的现实场景很典型：你想把一个通用图文模型用到某个特定的工业场景，比如识别电路板上的焊接缺陷，或者分类一批特定品类的商品图，手上只有几千张标注数据，而且标注质量参差不齐。直接全量微调，模型很容易过拟合，甚至出现灾难性遗忘——原来会的通用知识反而忘了。

这篇论文提出了一套组合方案，概括起来是"冻结主干+分层学习率+正则化约束"三件套。

冻结主干这个思路不稀奇，很多人都在用，但作者特别分析了应该冻结到哪一层。他们的结论是，视觉编码器的后半部分和文本编码器的大部分都可以冻结，真正需要更新的是跨模态对齐的投影层，以及语言模型端最靠近输出的那几层。这个结论和我自己微调图文模型的体验一致——更新的参数越少，模型的稳定性越好，而且收敛速度反而更快。

分层学习率的设计也值得展开说。作者把需要更新的参数按照离输出端的距离分成三组，离输出最近的层用正常学习率，中间层用0.1倍学习率，底部的适配器层用0.01倍学习率。这样处理之后，模型微调后在新任务上的表现，和保持通用图文理解能力这两个目标之间，做到了比统一学习率好得多的平衡。

第三件套正则化约束，用的是logit蒸馏。具体做法是，微调时同时让模型的输出逼近两个目标：一个是真实标注的one-hot分布，另一个是微调前模型对同一张图的预测分布。那个蒸馏项的系数设成0.5的时候效果最好。作者的实验显示，在只有2000张图的二分类缺陷检测任务上，这套方案比直接全量微调准确率高了约7个百分点，而且模型在通用图文检索的评测集上只掉了不到1个点，而全量微调掉了接近9个点。

这个工作对实际做项目的人参考价值很大。我们现在接了不少垂直领域的图文模型需求，数据量通常都不大。以前习惯性上来就全量微调，然后被过拟合折磨。看到这篇论文后，我特意按他的分层学习率设置在自己的数据上试了一遍，收敛确实更平滑，训练过程基本没有出现loss震荡的情况。顺带提一句，如果你用的是开源图文基座模型，改造起来也不难，就是在配置里区分一下各层的learning rate multiplier，PyTorch的param group就能实现。

有个小地方要提醒，这套方案适合微调，但不适合从头训练一个多模态模型。如果你手上的是完全没有经过预训练的模型，冻结主干就没有意义了。另外，数据标注质量在这个方案里依然关键，因为正则化约束会让模型倾向于保留原有知识，如果新任务的标注本身噪声很大，模型反而更难拟合到噪声上——这算是这套方法的一个副作用，但整体上利大于弊。

4. 代码生成模型的自我纠错：要的是"能发现错"，不是"能改对"

第三篇论文做的是代码生成模型的自我纠错评估。代码模型现在写代码的能力确实强，但"写完代码之后自己检查、自己改错"的能力到底怎么样？这篇论文设计了一组很精巧的实验，直接把这个问题拆开来看。

作者把自我纠错分成了三个阶段：发现错误、定位错误、修复错误。大多数研究把这三个阶段混在一起算一个端到端的准确率，但这篇论文单独评估了每个阶段的成功率，结论挺有意思。他们用一组包含了单行错误、跨行逻辑错误、类型错误、边界条件缺失的代码题，分别测试了多个主流代码模型。

结果大致是这样：在"发现错误"这个阶段，模型能成功判断代码有没有问题的比例其实挺高，普遍在70%以上；但到了"定位错误"，也就是指出具体是第几行、哪个变量出了问题，准确率就掉到了40%上下；再到"修复错误"，也就是给出一个正确的修改版本，准确率进一步掉到30%左右。换句话说，模型"知道自己写错了"和"知道错在哪"之间的差距非常大。

这篇论文还有一个发现让我印象很深：让模型自己生成的代码，和自己再检查这段代码，两个阶段使用同一个模型时，纠错成功率比用另一个模型来检查要低。作者猜测原因，是同一个模型在做检查和做修复时，容易陷入同样的思维模式，也就是"自己检查自己的代码容易先入为主"。反而是让一个不同的模型来检查，更容易发现前一个模型的盲区。这个现象在真实工程里也有对应——Code Review的时候，自己查自己的代码往往查不出问题，换个人来看很快就发现了。

方法论上，作者的评估框架是值得借鉴的。他把纠错过程做成一个可插拔的流水线，每一阶段的输入输出都是标准化的中间数据格式：检查阶段输出可疑行号和置信度，定位阶段输出具体的错误类型和关联变量，修复阶段输出patch。这样每个阶段可以单独替换成不同的模型或工具，也方便做消融实验。如果以后你要给自己的代码模型加自我纠错能力，按这个思路拆阶段实现，要比直接端到端prompt（提示模型直接修正）更容易定位瓶颈。

实操上，我的建议是，如果你正在做代码生成类的产品，别指望模型靠自我纠错把正确率拉高太多，更靠谱的做法是接一层外部的静态检查工具或测试用例验证。模型负责生成候选代码，静态检查负责第一轮过滤，测试用例负责第二轮验证，模型再做最后的小范围修复。这样一个流水线下来，最终通过率比单纯靠模型自我纠错能高出一截。论文里的数据也支持这个做法：当外部检查工具提供错误位置提示后，模型的修复成功率能从30%提升到接近60%。

这里也想顺带说一下评测指标的陷阱。只看"最终修复成功率"有一个问题：它没有区分错误是简单拼写错误还是深层的逻辑错误，所以两个模型如果最终修复率一样，实际能力可能差很远。这篇论文每个阶段单独算指标的方式，其实更接近工程实践里需要的信息。如果你打算复现这套评估框架，我给一个提醒：准备测试集的时候，尽量把错误类型标注做细，不然拆阶段的评估就失去了意义。

5. 小模型蒸馏不是简单的"瘦身"：损失函数的设计与温度策略

第四篇论文回到一个老话题——知识蒸馏，但讨论的是一个很容易被忽略的细节：温度参数和损失权重在小模型蒸馏里的敏感性。做过模型压缩的人都知道，蒸馏的基本框架是把大模型的软输出（soft label）当作小模型的学习目标，用KL散度算蒸馏损失，再加上小模型和真实硬标签之间的交叉熵损失。两个损失之间有个权重系数，温度T用来平滑大模型的输出分布。大多数论文都是拍脑袋定一组T和权重，然后整个实验都用这一组。这篇论文指出，这种做法在小模型容量明显不足的时候，会让蒸馏效果大打折扣。

论文的试验设计很系统：他们把教师模型从一个1.5B的模型蒸馏到0.5B的学生模型，把温度T从1到20每隔1取一个值、权重系数从0.1到0.9每隔0.1取一个值，做了一组完整的网格搜索，然后在新任务上的表现画成了热力图。结果有两个发现。

第一，最优温度不是一个固定值，而是和模型容量差异有关。教师和学生容量差距大的时候，最优温度偏高——大概在8到10之间；差距小的时候，最优温度偏低，2到4就够了。原因是温度高时软标签的分布更平滑，保留了更多"教师认为哪些答案比较接近"的信息，这对容量不足的学生模型来说，比硬标签提供了更多可学习的梯度。

第二，蒸馏损失的权重在容量差距大的时候需要更高。论文推荐的区间是0.6到0.8，而不是常见的0.5对半开。作者的解释是，小模型容量有限时，硬标签的交叉熵损失梯度会迅速把模型拉向尖锐的预测分布，把小模型本来就不多的表达能力占满，留给学习教师知识结构的空间就少了。这时候适当压低硬标签的权重，其实是在保护蒸馏通道。

我拿这个结论在自己手头的一个意图分类任务上试了一下：教师模型是7B的通用对话模型，学生压缩到300M参数。之前我一直用T=2、权重0.5的传统配置，在小类目上效果一直差口气。换了T=8、权重0.7之后，测试集准确率直接提了约4个百分点。这个提升完全没改模型结构，只是调了两组超参数，性价比很高。

这篇论文还有一个附带的观察值得提：温度参数不仅影响蒸馏损失项，对教师模型本身的输出分布也有影响。作者发现在高温度下，教师模型在低置信度样本上的输出分布包含的信息量更大，也就是说蒸馏时的"困难样本"其实比在低温度下更有教学价值。这一点在做蒸馏数据筛选时可以用来指导——不要只选教师高置信度的干净样本，适当加入一些教师自己也不太确定的样本，反而能让学生模型学得更扎实。

我给做模型压缩的同行一个建议：如果你要蒸馏一个小模型，先用论文里的这套网格搜索思路把T和权重摸一遍。不用搜索得太密，T取2、4、6、8、10这几个点，权重取0.5、0.6、0.7、0.8这几个点，20组实验跑完基本就能找到最优区间。比起在模型结构上反复调，超参数这块的收益往往更快。

6. 今天的阅读工具与筛选方法：从标题到精读的过滤漏斗

最后分享一个我每天筛选论文的具体流程，也算是对Day 2整个过程的复盘。很多刚入门的朋友问过我怎么从海量论文里找出值得精读的，我一般把这个过程当成一个三层漏斗。

第一层是标题和时间过滤。标题里如果出现明显跟我的方向无关的词，直接跳过。时间上我只看最近半年的更新。这一步能把几千篇过滤到一百篇左右。顺便说一句，我现在不太依赖单一渠道，arXiv的订阅RSS、Papers with Code的trending页面、还有几个我关注的实验室主页，三路信息放在一起对照着看。因为有些工作只挂在实验室主页上没有提交到arXiv，等arXiv版本出来往往已经过了好几个月。

第二层是摘要和图表扫描。一百篇里大概有二十篇能通过这层。看摘要的时候我特别留意一个问题：作者有没有明确写出"之前的方法存在什么不足，所以我才这么做"。能在摘要里把motivation说清楚的文章，正文质量一般不会差。如果摘要只是堆了一串名词、列了一堆指标提升，这种文章大概率是管线工程型的工作，除非指标真的好到离谱，不然我会跳过。

第三层是阅读结论和实验对比。剩下二十篇里，花时间精读的可能就四五篇，也就是一天做一份速递的量。精读时我看顺序是：先看实验部分的表格，搞清楚作者在跟谁对比、在哪些数据集上对比、提升到底有多大；再回头看方法部分，重点看有没有我在工程里能直接拿去用的trick；最后才是introduction，理解作者写这篇论文是想解决什么更大的问题。

今天这四篇论文，如果只挑一个最值得立刻动手复现的，我推荐第三篇的评估框架——把代码模型的自我纠错拆成发现、定位、修复三个阶段分别评估。这个不需要大量训练资源，只要有一个现成的代码模型和一组标注好的错误代码样本，半天时间就能跑出一份评估报告。而其他三篇偏方法研究，复现成本相对高一些，适合有训练资源的朋友尝试。明天我会继续按这个流程筛选，遇到方法上能直接落地的工作，会多花点篇幅拆细一些。