1. 从一份 arXiv cs.LG 汇总清单说起为什么值得逐条拆做机器学习这行的人几乎都有一个共同的困扰arXiv 上cs.LG这个分类每天新增的论文数量早就超过了任何人能逐篇精读的极限。我自己的习惯是每天早上花二十分钟扫一遍当天的汇总列表把标题和摘要过一遍挑出三到五篇真正值得深挖的剩下的归档备查。这个动作坚持了几年之后我发现一个规律——真正有价值的东西往往不是某一篇单独的论文而是同一天或同一周内几篇论文之间形成的共振同一个问题被不同团队从不同角度切入或者某个老问题突然出现了新的解法。这份 2026.09.25 的cs.LG汇总就是这样一个典型的共振日。从关键词和热搜词的分布来看当天的内容高度集中在几条主线上强化学习尤其是离线强化学习、因果强化学习、基于模型的强化学习、大语言模型LLM 的推理机制、评测榜单、微调与部署、以及机器学习的基础工程问题数据处理、模型检测、路径规划等。这几条线并不是孤立的它们之间存在着相当紧密的技术关联——比如因果推断工具被嵌入强化学习流程本质上是在解决 LLM 时代决策可解释性这个老问题的新变体。我写这篇东西的目的很明确不是给你一份论文列表的翻译而是把这批论文背后反映出的技术趋势、方法脉络和实操启示拆开来讲。如果你正在做强化学习相关的研究或工程落地或者正在跟进 LLM 的评测与微调又或者只是想把机器学习的基础打扎实这篇内容都能给你一些可以直接拿走用的东西。我会尽量把每个技术点讲透包括它为什么在这个时间点出现、解决了什么之前解决不了的问题、以及如果你要动手复现需要注意哪些坑。需要提前说明的是arXiv 汇总本身是公开的学术资源我在这里做的是基于公开信息的梳理和解读所有涉及具体方法的描述都尽量还原论文原意同时结合我自己在工程实践中的体会做补充。下面进入正题。2. 强化学习这条线从离线到因果再到基于模型2.1 离线强化学习Offline RL为什么还在被反复讨论热搜词里出现了iql离线强化学习和lag强化学习这两个词放在一起看很有意思。IQLImplicit Q-Learning是离线强化学习里一个绕不开的基线方法它的核心思路是不去显式地估计行为策略而是通过 expectile 回归来近似最优 Q 函数从而避免对分布外动作的过度估计。这个思路在 2021 年前后提出之后一直是离线 RL 的强基线。而 LAGLikelihood-based Actor-critic with Gaussian这类方法则代表了另一条路线通过显式建模策略的似然来约束动作选择让学习到的策略不要偏离数据集太远。为什么这两个词会在同一天的热搜里同时出现我的判断是当天cs.LG里大概率有论文在讨论离线 RL 中保守性与性能之间的权衡这个核心矛盾。离线 RL 的根本困难在于你只有一份固定的数据集不能和环境交互所以任何对分布外动作的乐观估计都可能导致灾难性的部署失败。IQL 用 expectile 回避了这个问题LAG 用似然约束来限制策略偏移本质上都是在回答同一个问题——在没有在线探索的情况下如何安全地逼近最优策略。如果你要动手复现这类方法有几个实操细节值得注意。第一expectile 参数 τ 的选择非常敏感τ 取 0.7 到 0.9 之间通常比较稳但具体值要看数据集的覆盖程度第二离线 RL 的评估不能只看最终回报还要看策略在数据集分布内的动作占比这个指标能提前预警部署风险第三数据集的归一化方式会显著影响训练稳定性我自己的经验是对状态和奖励分别做标准化动作空间如果是对称的也要做缩放。提示离线 RL 的论文里经常省略数据预处理细节但这一步对结果的影响可能比算法本身还大。复现时先把数据集的统计量打出来看看再决定归一化策略。2.2 因果强化学习CRL把因果推断嵌进决策流程热搜词里有一条描述得很准确因果强化学习的核心机制 crl将因果推断工具嵌入强化学习流程。这句话基本概括了 CRL 的技术定位。传统的强化学习学的是在状态 s 下做动作 a 会得到什么回报这是一个关联性的建模而因果强化学习想学的是做动作 a 对结果的因果效应是多少这是一个干预性的建模。两者的区别在分布内可能不明显但一旦环境发生变化关联性模型很容易崩溃而因果模型因为抓住了不变的结构泛化能力会强很多。CRL 的关键能力包括几个方面因果发现从观测数据中推断变量之间的因果图、干预建模估计 do-操作下的结果分布、反事实推理在给定观测的情况下推断如果做了不同动作会怎样。把这套工具嵌入 RL 流程通常的做法是在策略学习之前先学一个因果图然后用这个图来约束状态表示的学习或者在奖励函数的设计中引入因果效应估计。这里有一个很容易踩的坑因果发现本身是一个统计上很困难的问题在样本量不足或者噪声较大的情况下推断出的因果图可能完全错误。如果直接把错误的因果图喂给策略网络结果会比不用因果信息还差。我见过的一个比较稳妥的做法是把因果图当作一种软约束而不是硬结构——比如用因果图来设计辅助损失函数让状态表示在因果相关的维度上更敏感而不是强制网络按照因果图来组织。另一个值得注意的点是CRL 目前在实际工程中的落地案例还比较少大部分工作停留在仿真环境。如果你打算在真实业务里用建议先在仿真环境里验证因果结构的稳定性再考虑迁移。2.3 基于模型的强化学习MBRL样本效率的终极答案基于模型强化学习这个词在热搜里出现说明当天可能有 MBRL 相关的工作。MBRL 的核心思想是先学一个环境模型通常是动力学模型然后在这个模型里做规划或者生成虚拟经验来训练策略。它的最大优势是样本效率——因为模型可以反复使用不需要每次都和真实环境交互。但 MBRL 的困难也很明显模型误差会在多步展开中累积导致规划出来的策略在真实环境里表现很差。解决这个问题的常见思路有几种一是限制规划的长度只在短时域内信任模型二是用模型集成ensemble来估计不确定性在不确定性高的地方降低模型的使用权重三是把模型学习和策略学习交替进行让模型始终服务于当前策略的需求。从工程角度看MBRL 的实现复杂度比无模型方法高不少。你需要同时维护模型网络、策略网络、价值网络还要处理它们之间的训练节奏。我自己的经验是模型的学习率通常要比策略的学习率低一个数量级否则模型更新太快会导致策略训练不稳定。另外模型集成的数量一般取 5 到 7 个比较合适太少估计不准不确定性太多计算开销吃不消。2.4 多 AGV 路径规划强化学习在工业场景的落地样本热搜词里多agv路径规划强化学习是一个很具体的应用场景。AGV自动导引车在仓储和产线里的路径规划本质上是一个多智能体协作问题每台 AGV 要找到自己的最优路径同时不能和其他 AGV 冲突还要考虑整体吞吐量。传统的做法是用集中式的调度算法比如基于时间窗的 A* 或者冲突搜索CBS但这些方法在 AGV 数量增加时计算复杂度会爆炸。用强化学习来做这件事的优势在于可以把调度策略学成一个神经网络推理时几乎不花时间。但挑战也很直接多智能体环境的非平稳性每个智能体的策略都在变导致环境对彼此来说都是移动靶、奖励设计的困难怎么平衡个体效率和全局效率、以及仿真到现实的迁移仿真里的 AGV 动力学和真实设备总有差距。如果你要在这个方向做落地我的建议是先用集中式训练、分布式执行的框架CTDE比如 MADDPG 或者 QMIX 这类方法让训练时能看到全局信息执行时每个 AGV 只用自己的观测。奖励设计上除了到达目标的奖励一定要加碰撞惩罚和死锁惩罚否则学出来的策略很容易出现互相堵死的情况。3. LLM 这条线推理机制、评测与部署的现实问题3.1 LLM 的 token 机制key、query、value 到底在干什么热搜词里有一条很生动的描述llm的token三个点key我是谁、query我在找什么、value我能提供什么。这个类比虽然简化但抓住了注意力机制的核心。在 Transformer 的自注意力里每个 token 会生成三个向量Query我在找什么信息、Key我能被谁找到、Value我实际提供的信息。注意力权重就是 Query 和 Key 的点积用来决定每个位置应该从其他位置取多少信息最后加权求和 Value 得到输出。理解这个机制对实际工作有什么用至少有两个地方。第一当你做 prompt 工程时你其实是在影响 Query 和 Key 的匹配模式——把关键信息放在 prompt 的什么位置、用什么措辞会直接影响模型能不能找到它。第二当你做模型微调时注意力层的参数变化往往是最关键的因为微调本质上是在调整 Query、Key、Value 的投影矩阵让模型对特定任务的匹配模式更敏感。我自己的经验是在做长文本任务时把最重要的指令放在 prompt 的开头和结尾中间放支撑材料效果通常比均匀分布要好。这背后的原因就是注意力机制对首尾位置的偏好——虽然理论上自注意力是全局的但实际训练出来的模型确实对首尾更敏感。3.2 LLM as Judge自动评测的可靠性边界llm as judge这个热搜词反映的是当前 LLM 评测的一个主流做法用一个强模型来给另一个模型的输出打分。这个方法的吸引力很明显——人工评测太贵太慢而 LLM 评测可以自动化、可扩展。但它的可靠性一直有争议。从我实际使用的经验看LLM as Judge 在几个条件下比较可靠评测维度明确且单一比如回答是否包含事实错误、参考答案质量高、被评测模型和评测模型的能力差距不要太大。反过来如果评测维度模糊比如回答是否有帮助、或者评测模型和被评测模型是同一个系列结果就容易失真。一个比较实用的改进做法是成对比较而不是绝对打分。让评测模型在两个回答里选一个更好的比让它给一个回答打 1 到 10 分要稳定得多。另外评测的位置偏差position bias是真实存在的——同一个回答放在前面和后面评测结果可能不同。解决办法是交换位置各评一次取平均或者取一致的结果。注意LLM as Judge 的结果不要当作绝对真理它更适合用来做相对排序和快速筛选最终的关键决策还是要人工复核。3.3 微调 LLM 的数据问题聊天记录能不能直接用使用聊天记录模型精调llm这个热搜词指向一个很常见的需求手里有一堆业务聊天记录想拿来微调一个专属模型。这个想法本身没问题但直接拿原始聊天记录去微调几乎一定会出问题。首先是数据质量问题。真实聊天记录里充满了错别字、口语化表达、无关寒暄、以及不完整的对话。如果直接喂给模型模型会把这些噪声也学进去。我的做法是先做一轮清洗去掉长度过短的对话、去掉包含敏感信息的对话、把多轮对话整理成指令-响应的格式。其次是数据格式问题。微调 LLM 通常需要 instruction-input-output 这样的三元组格式而原始聊天记录是对话流需要做转换。转换的关键是确定哪一句是指令、哪一句是响应这个判断在有些对话里并不直观。还有一个容易被忽略的点是数据量。微调一个 7B 级别的模型通常需要几千到几万条高质量样本才能看到明显效果。如果只有几百条更合适的做法是用 prompt 工程或者 RAG而不是微调。我见过不少人拿一两百条数据去微调结果模型不仅没变好反而把通用能力给忘了——这就是过拟合的典型表现。3.4 本地运行 LLMGGUF 格式与安卓端的现实约束安卓本地运行gguf格式llm软件,支持安卓8这个热搜词反映的是端侧 LLM 的需求。GGUF 是 llama.cpp 生态里的一种模型格式它的优势是量化支持好、内存映射加载快、跨平台兼容性强。在安卓上运行 GGUF 模型核心挑战是内存和算力。一个 7B 模型即使量化到 4-bit也需要大约 4GB 的内存加上运行时开销实际需要 5GB 以上。安卓设备的内存管理比较激进后台应用容易被杀所以运行本地 LLM 时需要保持前台服务。算力方面CPU 推理的速度通常只有每秒几个 token体验上会比较慢如果有 GPU 或者 NPU 加速速度会好很多但需要模型格式和硬件驱动都支持。如果你要在安卓上做本地 LLM 应用我的建议是从小模型开始比如 1B 到 3B 参数的模型量化到 4-bit 或者更低。这样内存占用可以控制在 2GB 以内推理速度也能接受。另外模型文件要放在应用私有目录或者外部存储的特定路径加载时用内存映射的方式避免一次性读入内存导致 OOM。4. 机器学习基础工程那些容易被跳过但绕不开的环节4.1 数据处理机器学习流程里最不性感但最关键的一步热搜词里机器学习中的数据处理是什么和机器学习 应用流程放在一起说明很多人对数据处理的定位还是模糊的。我的理解是数据处理不是流程里的一个独立阶段而是贯穿始终的一条线。在数据收集阶段你要决定采什么、怎么采、采多少在数据清洗阶段你要处理缺失值、异常值、重复值在特征工程阶段你要做编码、缩放、衍生在训练阶段你还要做增强、采样、加权。一个常见的误区是把数据处理当成一次性的工作。实际上模型训练过程中发现的问题往往要回到数据处理阶段去解决。比如模型在某些样本上表现特别差可能是这些样本的标签有问题模型对某个特征过度依赖可能是这个特征的尺度没有处理好。我自己的习惯是在训练脚本里保留数据处理的完整 pipeline每次实验都能追溯到具体的数据版本和处理参数。4.2 机器学习检测模型监控与异常识别机器学习检测这个词比较宽泛可能指用机器学习做检测任务比如异常检测、欺诈检测也可能指对机器学习模型本身的检测比如模型监控、漂移检测。从当天的上下文看两种理解都有可能。如果是前者核心问题是正负样本极度不平衡。检测任务里异常样本通常只占千分之几甚至更低直接用准确率评估会完全失真。正确的做法是用 AUC-ROC、AUC-PR 或者 F1 这类对不平衡敏感的指标。训练时可以用重采样、代价敏感学习、或者异常检测专用的方法比如孤立森林、自编码器重构误差。如果是后者核心问题是分布漂移。模型上线之后输入数据的分布会随着时间变化导致模型性能下降。监控的关键是跟踪输入特征的统计量均值、方差、分位数和模型输出的分布一旦发现显著偏移就触发告警。我自己的经验是PSIPopulation Stability Index是一个很实用的漂移指标计算简单阈值也好定——一般 PSI 超过 0.1 就值得关注超过 0.25 就需要重新训练了。4.3 机器学习入门与期末复习知识体系的搭建方式热搜词里出现了机器学习入门、机器学习期末复习、机器学习西瓜书、吴恩达机器学习这些词说明这个领域的学习需求一直很旺盛。我自己的学习路径是这样的先用吴恩达的课程建立直觉知道每个算法在干什么然后读西瓜书《机器学习》周志华著把数学推导补上最后通过实际项目把知识固化下来。复习的时候我建议不要按章节顺序过而是按问题类型来组织。比如把所有分类算法放在一起对比逻辑回归、SVM、决策树、随机森林、GBDT它们各自适合什么场景、对数据有什么假设、计算复杂度如何。这种对比式的复习比线性复习效率高得多也更容易形成长期记忆。对于期末考试我的经验是重点掌握三类东西一是核心算法的推导比如 SVM 的对偶问题、EM 算法的收敛性二是评估指标的计算和含义准确率、召回率、F1、AUC三是过拟合和欠拟合的识别与处理。这三块基本覆盖了考试的大部分分值。5. 把这些线索串起来当天 arXiv 汇总反映的技术走向5.1 强化学习与 LLM 的融合正在加速从当天的关键词分布看强化学习和 LLM 不再是两个独立的圈子。RLHF基于人类反馈的强化学习已经是 LLM 训练的标准流程而更进一步的 RLAIF基于 AI 反馈的强化学习也在快速发展。同时LLM 开始被用作强化学习里的世界模型或者奖励模型这在一定程度上缓解了 MBRL 里模型误差累积的问题——因为 LLM 预训练时已经见过大量世界知识它作为先验比从零学一个动力学模型要靠谱得多。这个融合趋势对从业者的启示是如果你只懂强化学习不懂 LLM或者只懂 LLM 不懂强化学习未来的路会越走越窄。至少要对另一边的核心概念和常用工具有基本的了解。5.2 评测和可靠性成为 LLM 落地的瓶颈llm as judge、open llm leaderboard、llm request failed这些热搜词都指向同一个问题LLM 的评测和可靠性保障还没有成熟的方案。模型能力在快速提升但怎么知道它真的变好了、怎么保证它在生产环境里不出错这些问题还没有标准答案。我自己的做法是建立一套分层的评测体系底层是自动化指标困惑度、BLEU、ROUGE 等中层是 LLM as Judge 的相对排序顶层是人工抽检。三层结合既能保证覆盖率又能控制成本。另外生产环境一定要有 fallback 机制——当模型请求失败或者输出异常时要有降级方案不能直接把错误暴露给用户。5.3 端侧部署和隐私计算的需求在上升安卓本地运行gguf格式llm这个热搜词不是孤例。随着模型量化技术的成熟和端侧算力的提升越来越多的场景开始要求在本地运行模型而不是把数据传到云端。这背后的驱动力有两个一是隐私合规的要求越来越严二是端侧推理的延迟和成本优势在某些场景下比云端更明显。如果你在做端侧 LLM 相关的工作需要关注几个技术点模型量化4-bit、3-bit 甚至 2-bit、推理框架的硬件加速支持CPU、GPU、NPU、内存管理模型加载、KV cache 的优化、以及功耗控制。这些细节决定了端侧应用能不能真正可用。6. 我自己的 arXiv 跟踪方法从汇总到精读的完整流程说了这么多技术内容最后分享一下我跟踪 arXiv 的具体方法算是给同样有这个需求的人一个参考。第一步是订阅。arXiv 支持按分类订阅每日汇总cs.LG的列表会以邮件形式发送。我一般会在早上通勤的时候用手机扫一遍标题标记出感兴趣的。标记的标准很简单标题里出现了我当前工作相关的关键词或者标题的表述方式让我觉得这个问题有意思。第二步是粗筛。把标记的论文摘要快速读一遍判断是否值得精读。粗筛的时候我主要看三件事问题定义是否清晰、方法是否有新意、实验是否充分。如果摘要里全是套话或者实验只在 MNIST 这种玩具数据集上做基本就跳过了。第三步是精读。精读的论文我会打印出来用笔在纸上做批注。重点看方法部分的公式推导和实验部分的消融研究。如果论文有开源代码我会把代码拉下来跑一遍看看实际效果和论文报告的是否一致。这一步经常能发现论文里没写清楚的细节比如超参数的具体取值、数据预处理的方式。第四步是归档。精读过的论文我会整理成一个笔记记录核心贡献、方法要点、实验结论、以及我自己的评价。这个笔记积累到一定量之后就变成了一个很有用的知识库写论文或者做项目的时候可以快速检索。这套方法看起来简单但坚持下来需要一点自律。我的经验是不要贪多每天精读一篇就够了关键是持续。另外不要只读自己方向内的论文偶尔看看相邻方向的汇总往往能获得意想不到的灵感——当天的这份汇总里强化学习和 LLM 的交叉就是一个很好的例子。最后再提一个实操技巧arXiv 的论文 ID 是有规律的YYMM.NNNNN这样的格式前四位是年月后面是当月的序号。如果你看到一篇论文想找同期的其他工作可以直接用这个 ID 去检索往往能找到同一批上传的相关论文。这个技巧在追踪某个热点方向的时候特别有用。