今天照例把预印本平台AI板块的新论文过了一遍2026年10月这周的内容量依旧不小。我原本是打算只看标题挑几篇水文打发时间没想到越翻越觉得有几个方向值得坐下来记点东西。cs.AI这个分类现在混进来的内容非常杂有正经做理论分析的有纯工程报告也有大量只换了数据集就出来的增量工作甚至还有几篇一看摘要就知道是竞赛总结报告。但这种“杂”本身也是信息——它直接反映出社区当下最焦虑、最愿意投时间的问题是什么。从这批稿子看推理时计算怎么分配、视频生成怎么保证整段一致、智能体怎么长期记忆、数据合成怎么稳定提质量依然是最密集的几条线。安全和对齐方向不再是喊口号而是实打实给出了可复现的训练协议。下面我挑一些让我觉得有讨论价值的论文按方向拆开讲每篇附带一些我自己的判断和实测经验。有些论文我只有摘要和实验表格可看个别结论我也会标注出来大家当作导读参考即可。1. 推理时计算的新变化自适应预算与搜索式验证正在成为主流1.1 从“堆长度”转向“按需分配计算”第一篇让我停下来细看的是关于自适应推理预算的工作。过去两年大家做测试时计算思路比较粗暴给模型更大的生成预算比如增加思考轮数、扩大采样次数然后寄希望于准确性跟着涨。这周有一篇论文直接把问题定义成“如何为不同难度的问题分配不同的推理长度”并且提出了一个轻量预测器来动态决定某个输入应该用多少步思考。这篇的出发点很实际。作者在摘要里吐槽了一件事用固定预算跑推理时简单问题被白白浪费了大量计算。我特别认同这个观察。我自己在本地跑开源推理模型时最大的感受也是“该快的地方慢该慢的地方也慢”。一个判断侮辱性笑话的提问和一个需要多步反证的数学题在固定预算下消耗的资源几乎一样这显然不合理。论文给的方案核心是一个两阶段流程先用小模型快速预判难度再根据难度给主模型分配不同长度的思考预算。难度的衡量不是靠规则而是靠一组细粒度的分类标签训练出来的。我看了一下实验设计他们在多个基准上做了对比发现同样的总预算下自适应分配相比固定长度平均能带来3到5个点的提升而且在简单题上延迟下降非常明显。这个方向最大的价值在于低成本落地。它不是要求你换更大的模型也不要求改推理算法只是加了一个前置调度器这对生产环境很友好。不过论文的实验规模看起来还不大分类器的跨领域泛化能力问题没有完全回答如果测试集长尾分布明显预测器会不会把难题误判为简单题这个风险需要更多实验验证。1.2 搜索路径与结果验证的分离设计另一篇让我觉得有启发的论文讨论的是搜索式推理里的“验证”环节。现在很多方法在推理时引入搜索树让模型自己生成多条候选路径然后统一打分。但问题在于如果打分还是用同一个模型甚至还是用同一套参数验证就很容易变成“自己评价自己”产生系统性偏好。这篇论文把路径生成和结果验证拆成了两个独立组件一个负责扩展搜索树产生多样的解题路径另一个专门负责验证和排序。为了不让验证器偷懒他们还在训练中刻意加入了难度梯度让验证器必须真正计算而不是只看表面特征。我比较欣赏的是他们对“验证器错误”的分类分析他们把验证错误分成两类一类是“把正确路径判成错误”另一类是“把错误路径判成正确”。这个区分很有意思。前者会导致搜索效率下降实际结果未必错后者则直接污染最终答案是更危险的问题。论文用大量篇幅讨论如何通过数据配比抑制第二类错误我觉得这个经验值得做推理系统的同学直接吸收。不过老实说这个方案的工程成本不低。训练一个独立验证器相当于额外维护一套模型生命周期对小团队来说负担不小。论文没有给出详尽的蒸馏方案我认为如果能把验证器做小做轻这个方法在实际部署中的吸引力会翻倍。1.3 复现这类方法时容易踩的坑最近我自己跑了几组推理时计算的对照实验有几个坑值得写在这里评测集必须区分难度层次。如果你只在一个平均分较高的基准上看结果自适应预算的优势会被平均效应掩盖。建议自己按难度分桶统计重点看简单桶的延迟下降和困难桶的准确率保持。长度控制别只靠max token硬截。动态预算的核心是“让模型自己学会在多大空间内搜索”如果只改上限不改下限简单题还是会空转。需要配合提前终止机制或隐式停止训练。采样温度影响极大。搜索式推理和普通生成不同温度太低会让搜索树变窄变相削弱验证器的作用。我记了个经验值这类场景下温度在0.7到0.9之间是一个比较稳的区间但具体还要看基座模型本身。2. 视频与多模态的更新长一致性、可控生成和统一架构各有突破2.1 长视频生成的一致性处理这周视频生成方向最值得讨论的是一篇针对长视频一致性的方法论论文。现在的视频生成模型做短片段已经相当稳定但把时间线拉到几秒以上问题就开始冒头物体形变、场景渐变、角色外貌漂移这些都是老熟人。这篇论文提出了一种“锚点驱动”的生成结构把整段视频切成多个子片段用全局锚点固定关键语义信息再在各子片段之间做约束插值。我看完摘要后的判断是这条思路本质上是在视频生成里引入了类似关键帧动画的思路。每个子片段不需要从头生成语义只需要保证与前后锚点对齐。论文实验里特别展示了多镜头场景下人脸一致性的提升这是目前社区最关注也最缺数据的地方。但我对论文的实验规模有些保留。长视频评测非常昂贵论文使用的生成条数和视频长度都偏保守说服力有限。最理想的做法是补充更多人工评估维度比如“连续两分钟无漂移”这类极端场景。希望后续版本能有更大的评测量。2.2 可控生成从“给指令”走向“给结构”还有一篇关于可控视频生成的文章核心是把用户意图结构化。它不再要求用户用一句自然语言描述完整画面而是允许用户给出关键帧或布局草图模型再根据这些结构信息生成中间过渡。这种交互方式更接近导演的实际工作流先定分镜再补细节。这篇方法的工程细节我没仔细看但实验部分有一个数据很亮眼在动作控制准确率上比传统文本驱动方法提升了近一倍。原因是文本对视觉控制天然有歧义而关键帧和布局把歧义压缩到了最低。实践上这种接口也更适合和传统视频编辑软件做集成。如果你在做视频可控生成的产品我建议别只盯着端到端模型完全可以考虑这种“外部结构引导”的思路它能把用户意图中的模糊性提前消解掉。2.3 统一多模态架构的工程取舍这周还有一篇讨论统一多模态模型的论文主张用同一套词表同时处理图像、视频和音频输入并在一个大模型里完成理解与生成。整体架构没有特别大的创新更多是工程整合上的补全。我感兴趣的是论文对训练配比的详细记录。作者公开了他们如何安排不同模态的数据混合顺序先做图文对齐再引入视频最后才是音视频联合训练。这个顺序其实很讲究因为视频数据里包含时间信息训练动态一旦不稳定前面的图文能力会迅速遗忘。不过这种统一架构真正的问题是训练成本。论文没有公布完整算力消耗但从实验细节推断这不是一个普通实验室能复现的规模。我认为它的参考价值更多在方向判断上而不在于可以直接拿用的代码。对于只有单卡或少量算力的团队我更建议在已有模型上做适配层而不是从零训练统一模型。2.4 一个评测上的提醒多模态方向这周还有一堆“微调后刷新SOTA”的短文我基本都跳过了。我的判断标准很简单评测集如果太小、太固定刷新分数说明不了任何问题。尤其是长视频一致性评测目前标准非常不统一有的用CLIP相似度有的用目标检测IoU统计口径都不同横向对比根本没有意义。我自己现在的做法是自建一套固定的评测提示词池每次跑新模型都用同一套题来测虽然不完美但至少能看出相对变化。如果你也想做视频生成方向的测评建议尽早固定这个话题池不然后面换模型会缺可比数据。3. Agent继续向内收紧记忆、规划和评估成为三块硬骨头3.1 长期记忆的关键不是存储而是检索Agent方向这周的好几篇都集中在记忆机制上。有一篇针对长期交互中“记忆写入容易、检索困难”的问题提出了结构化记忆组织方案。它是把历史交互拆成多层索引底层是原始信息中层是关键事件摘要顶层是高层的目标与偏好。每次对话时模型先生成当前需求的语言表示再用它去匹配对应层次的记忆片段。这个方法解决的问题很现实。长期Agent失败的案例里大部分不是模型没能力而是它在关键时刻找不到自己早就知道的信息。摘要层太粗会丢失细节原始层太细又会被噪音淹没。论文提出了一个自动平衡的检索策略根据当前任务类型自动决定检索层级。我实操时也见过类似问题。一个Agent跑几十轮之后最常见的现象是它不是忘了而是被大量历史信息干扰导致注意力分散。所以我认为记忆系统设计的重心应该从“存什么”转向“怎么让正确信息在正确时间浮出水面”。3.2 规划模块从全量规划转向逐步验证另一篇Agent论文讨论的是规划与执行的解耦。过去很多Agent直接用大模型做全量规划一次生成完整的执行步骤。但一旦中间出现意外整条计划就得推翻重来。这篇论文采用的方式是“最小可执行单元”模型每一步只规划一个动作执行完再根据新状态决定下一步。这个思路在真实环境中更稳。尤其是需要调用外部API时环境的反馈往往和预期不一致逐步规划可以即时纠偏。代价是推理次数明显增加延迟变大。作者在论文里做了成本分析在多步任务的最终成功率上逐步规划比全量规划高出约20%但调用次数也同步增长了两到三倍。如果你的场景允许这种延迟我一定会推荐逐步规划。反过来说如果对实时性要求极高那就需要先对任务做复杂度预判简单任务用一次规划复杂任务再启用逐步模式做一个混合调度也是不错的选择。3.3 评估基准该重新审视Agent评测了本周有一篇关于Agent评测的批判性文章让我眼前一亮。作者分析了现有Agent基准的常见偏向大多数任务把“完成率”当作唯一指标却完全忽视了“资源消耗”和“恢复成本”。文章举了一个很生动的例子一个Agent虽然最终完成了任务但它中间反复调用了同一工具十几次如果换算成现实世界的API费用这个方案根本不具备可用性。作者提议把“路径效率”和“错误恢复能力”纳入评价矩阵单独建一套成本模型来算真实性价比。我完全赞同这个判断。Agent和静态模型评测不同它的过程本身就是结果的一部分。工具选错、参数传错、死循环重试这些行为即使最终被“意志力”修正在实际环境中也是不可接受的浪费。做Agent评测时大家应该至少记录三个维度成功率、平均调用次数、失败后的恢复速度。3.4 合成工具调用数据要加负样本这周还看到一篇专门构造Agent训练数据的论文核心建议是“不要只生成正确轨迹也要生成带错误的轨迹”。作者发现只用正确工具调用序列训练出来的模型遇到参数异常时完全不会自我修正。他们在数据里增加了大量“中途失败然后恢复”的轨迹训练出的模型在鲁棒性上明显更强。这一点我在实际调Agent时也有同感。工具调用本身是低成本动作但模型的自我监控能力却高度依赖是否见过错误样例。生产中跑Agent至少要在数据合成阶段刻意注入错误参数、空结果、网络超时这几种典型异常否则模型上线后很容易在第一个非理想输入上崩溃。4. 数据合成与低资源训练大家都在死磕数据质量4.1 从“生成更多”转向“按难度生成”数据合成方向这周有几篇值得关注。其中一篇主张把数据合成从“量”的竞争转向“质”的竞争。作者提出一个分阶段合成策略先评估模型当前能力边界然后针对边界附近的难度生成数据避免反复生成模型已经掌握的简单样本。这套思路其实就是主动学习的变种但它被引入到合成数据流程后效果非常明显。论文的实验里同样是用教师模型生成数据针对性按难度合成的方法在微调后的分数提升远超随机采样。我认为这个方向是当前合成数据研究里最有实用价值的一支因为它直接回答了“合成什么样的数据才有用”。低成本复现这个思路也不难。你可以用一个较小的评测集去探测模型的错误类型然后把错误案例的分布特征反馈给生成器定向补齐短板。不需要构建复杂的难度模型简单的类型聚类就能带来可感知的提升。4.2 数据配比一部分论文的经验值得参考有一篇论文专门讨论了多任务混合训练中的数据配比问题。它提出了一种数据贡献度估计方法可以在训练过程中动态调整各任务的采样比例。论文的核心观察是不同任务的数据在训练后期对损失的贡献差异极大继续平等采样是巨大的浪费。我看完他们的实验曲线发现这个动态配比策略在多个任务上都平稳收敛而且最终结果全面超过固定配比。它的代价是训练时需要额外做一轮边际评估对工程链路的要求高一些但方向是对的。对做预训练的团队来说动态数据配比可能比调更大学习率更容易带来收益。4.3 低资源场景下用少量优选样本做对齐对齐数据方向这周也有一篇非常实用的小规模案例作者只使用了不到三千条人工精筛的偏好数据就达到了超过大规模自动采样数据的对齐效果。关键差异在于他们的筛选标准不只看“哪个答案更好”还看“这个样本是否能暴露模型当前缺陷”。这个做法特别适合算力有限的小团队。现在大家都觉得RLHF需要海量数据但这篇论文证明了一个反直觉的结论如果你能精准找到模型最薄弱的区域哪怕只有几千条数据也能让对齐效果上一个台阶。我建议在启动大规模偏好数据收集之前先用现有模型做一次系统性的错误抽样再针对性构建小样本集这比立刻堆量要稳健得多。4.4 蒸馏不是万能的但蒸馏时机很关键最后提一篇关于知识蒸馏的论文。它讨论的问题不是“要不要蒸馏”而是“什么时候蒸馏”。作者对比了在预训练早期、中期和后期进行蒸馏的效果发现如果教师模型能力已经稳定那么早期蒸馏会把教师当前的错误模式固化到学生模型里导致学生后续很难再突破。这个结论提醒我重新审视很多团队的蒸馏流程。比较理性的做法是等教师模型基本收敛后再启动蒸馏或者采用两阶段蒸馏先用一个弱一些的教师做初步训练等学生能力提升后再换更强的教师进行精调。论文实验表明这种方式比直接用最强教师一步蒸馏的最终效果更好反直觉但合理。5. 端侧与高效推理的实用主义路线量化、剪枝与投机解码5.1 低比特量化新方案和绕不开的精度权衡这周的高效推理方向依然以量化为主。有一篇工作提出了混合精度量化策略它不对整个模型做统一比特数设定而是根据每个层对最终输出的敏感度自动分配不同比特数。敏感度通过一个代理任务计算计算量不大但能保留更多关键层的精度。我在端侧部署时常用的做法还是统一8比特量化简单省事。但一旦模型超过70亿参数统一量化的精度损失就开始肉眼可见。混合精度方案在这类场景下确实更有优势只是现在的实现大多还不成熟硬件支持也有门槛。如果是做原型验证可以先在关键Attention层保持16比特其他层用8比特也能获得大部分收益。5.2 结构化剪枝新思路动态找冗余另一篇论文讨论的是结构化剪枝它主张在训练过程中动态识别冗余头而非训练完成后一刀切。作者把剪枝过程建模成稀疏门控的优化问题让模型自己决定哪些头可以被关闭。训练结束后被关闭的头直接移除即可。相比传统剪枝这种嵌入训练的方式基本不会出现“剪完后需要大量微调才能恢复”的问题。但训练成本会有一定上升。对于已经训练好的存量模型这篇论文的方法就不适用了还是得用后训练剪枝。所以它更适合从预训练阶段就计划好要部署轻量模型的团队。5.3 投机解码优化小模型候选要更聪明地选投机解码这周也有更新。传统做法是让一个小模型先生成候选token再交给大模型批量验证。新工作提出了“多路候选”机制一次让多个不同的小模型并行生成候选再合并交给大模型验证。作者在摘要里给出的加速比数据非常可观推理侧吞吐提升了近三倍。这个思路的价值在于利用多个“弱势候选”的互补性增加每轮被接受的概率。不过实际部署时多个小模型同时运行同样会增加内存压力。如果硬件本身就是瓶颈则收益可能会被抵消。在单机多卡环境里这个方案可能更合适。5.4 端侧评测要改看真实吞吐高效推理类论文往往会在理想条件下报加速比但到了端侧场景理想条件很少存在。这里给大家一个建议看这类论文时重点看“端到端吞吐”和“峰值显存占用”而不是理论加速比。这两个指标才直接决定模型能否在目标设备上流畅运行。另外如果要在移动端或边缘设备部署建议关注整数算子是否完整支持、内存带宽是否够用以及长时间推理的散热问题。这些因素在论文的表格里看不到但在实际项目中往往决定一个方案到底能不能落地。6. 对齐与安全的新解法不止是调RLHF6.1 偏好优化让模型更稳、更可训练对比偏好优化的论文这周有好几篇其中一篇让我觉得有参考价值的是讨论了偏好优化和KL约束之间冲突的问题。作者指出现有偏好优化方法很容易在训练后期出现奖励上升但生成质量下降的矛盾现象根源是KL约束项与优化目标之间的不平衡。他们改进了约束目标的计算方式让模型在探索更优策略时不至于偏离原始分布太远。这个问题的确在真实对齐训练中很常见。很多团队会遇到“训完一轮后模型变乖了但变笨了”的困境本质就是过度调优。这篇论文提供的解法虽然不是全新的思路但约束项的改进确实能让训练曲线更稳定。如果你在做RLHF类的项目值得花时间看实验部分对不同KL系数的敏感性分析。6.2 红队测试走向“可重复”红队测试方向有一篇偏向基础设施建设的论文作者提出了一个结构化对抗性评估协议把红队攻击从“自由式脑洞”变成“按模板生成”。他们把越狱攻击拆解成多个可枚举的类别并为每个类别定义了一套生成规则和评估标准强调同一攻击模板要能在不同模型之间复现。这个方向对安全研究非常重要。过去的红队测试高度依赖个人经验A找到的攻击模式在B那里可能完全失效。结构化协议虽然会降低攻击方式的多样性但换来的是可对比性。我建议各家模型评估团队都建立自己的红队模板库就算不完全复用论文的协议思路也完全可以借鉴。6.3 可解释性用于安全定位“安全神经元”一篇挺有新意的论文尝试用可解释性工具直接干预模型安全行为。作者通过分析模型内部注意力头识别出与安全拒绝行为高度相关的神经元子集然后对这些区域做方向性抑制或增强从而在不需要完整微调的情况下改变模型的安全表现。这个思路如果能稳定复现未来的安全对齐可以做到更细粒度。不过论文也发现了明显的局限性目前这些安全相关神经元在模型间的迁移效果不佳A模型上定位的区域在B模型上并不能直接套用。即便如此把它看作是安全对齐的新工具维度而不是完全替代微调的方案我觉得判断是成立的。6.4 安全与可用性的平衡是工程问题这周安全方向的论文普遍有一个特点越来越务实。它们不再只讨论理论攻击面而是开始关注“加了防御后模型还愿不愿意回答问题”这个工程问题。有几篇工作专门研究了拒绝率的控制希望模型在防御有害请求的同时不误伤正常但敏感的话题讨论。这种平衡非常考验数据构造。如果你在做安全对齐的工程化我建议建立一个“安全敏感但合法”的测试集用来评估过度拒绝率。仅仅拦截恶意输入不够误杀率过高同样会影响产品体验。这批论文里关于如何构造该类平衡数据集的讨论正是实际落地中最稀缺的部分。7. 其他几篇值得顺带扫一眼的工作这周还有一些不太容易被标题吸引点击但内容质量不错的工作也一并罗列出来。一篇是讨论多模态模型“幻觉”成因的分析类论文。作者通过大量对照实验证明视觉幻觉在很大程度上不是视觉编码器的问题而是语言模型先天对某些高频文本模式的偏好导致的。这意味着解决多模态幻觉重点可能不在更强的视觉塔而在于控制解码阶段或修改训练目标。看到这个结论后我再排查幻觉问题时就不再只盯着视觉输入了而是会同时检查生成阶段的偏差。另一篇是让旧代码库适配新训练框架的工具类论文。它能够自动将旧式训练脚本转换成新的分布式执行格式并保持关键超参语义不变。相比端侧部署这类工程向论文的引用量通常不高但对团队迁移的实用价值极大。如果你也在维护老训练代码这篇的方法可以省下不少手工迁移时间。最后还有一篇对开源模型做大规模系统性评测的文章。他们的评测框架覆盖面很广包括数学推理、代码生成、工具调用、多语言能力等但在评测设计上对数据污染问题做了额外防范剔除了很多可能出现在预训练语料中的公开题目。我比较认同这种做法数据污染已经成为开源模型评测最大的干扰因素如果所有榜单都能这样做社区会比较清晰地看到真实水平。8. 我今天会优先精读的优先序最后分享一个我自己的阅读排序给大家做个参考。我会优先精读的是推理时计算那篇自适应预算的论文和偏好优化的改进工作。前者直接关系到部署成本属于可落地的性能优化后者因为我近期的对齐训练遇到过训练不稳定问题正好可以对照改进。其次会看长视频一致性的锚点方案和Agent记忆组织结构化那篇。这两个方向目前都处在工程落地前夜的阶段哪怕论文里的实现不够完美也会为后续项目提供一个大框架思路。至于各类“刷新SOTA”的短文我大概率会放到最后翻一遍摘要就行。现在是一个人人都可以录榜的时代论文提供的分数字已经很难说明问题真正重要的是方法里有没有值得迁移的组件性思路。带着这个标准去读论文效率会提升不少也不容易被热搜带节奏。
