全部

GRPO-VPS 在可验证任务上换来了最高 2.6 点准确率提升和 13.7% 长度下降，我的判断是：这篇更像把 GRPO 从“只会看终局”拉回到“至少会看过程拐点”，补的是一个早就暴露的训练缺口，不是突然冒出来的新范式。 GRPO 这条线过去一年被捧得很高，核心卖点就是不用 critic，训练比 PPO 系更省，工程面也更干净。问题也一直很明显：同一条长推理轨迹里，前半段在铺路，后半段在跑偏，末端只给一个 outcome reward，梯度会把整条链子一起奖惩。结果就是两个老毛病：一是信用分配太糙，模型学不会到底哪一步有用；二是 overthinking，明明答案已经能收敛，模型还在继续写。GRPO-VPS 的动作不复杂：它不训练辅助奖励模型，也不做 Monte Carlo rollout，而是在分段边界探测“加上正确答案后，条件概率有没有上升”。这等于给每一段都塞了一个可验证的进展分数。这个想法我买账，因为它抓的正是 GRPO 最难受的那一刀。 我自己更在意两件事。第一，这个“过程监督”其实不是传统 PRM 那条路。去年大家在 process supervision 上折腾了很多，常见做法是人工步骤标注、训练 PRM 打分，或者用更强模型蒸馏中间步骤。那些方法的问题很一致：贵、脆、迁移差。GRPO-VPS 则绕开了“判断中间步骤是否好”的主观题，改问一个更硬的题：这一步之后，正确答案变得更像了吗。只要任务答案可验证，这个信号就成立。怎么说呢，这个转法挺聪明，因为它把过程监督从“语义评价”降成了“条件概率测量”。 第二，我对“不要额外模型”这层叙事要打个折。它确实没上 critic、没上 PRM、没跑 rollout，但它不是零成本。每个分段边界都要再做 probing，前向次数会上去。摘要没披露分段粒度、额外 FLOPs、wall-clock 开销，也没给训练吞吐变化。这个缺口不小。很多 RL 后训练方法 paper 里看着只加了一个小模块，落到集群上就是 20% 到 50% 的训练时延。我还没看到 PDF 里的消融，所以现在不能替它下“更高效”这个结论，只能说它把成本从模型侧挪到了推断探测侧。 这篇还有一个边界条件，不能装作没看见：它依赖正确答案可附加、可验证。数学题、代码题、规则明确的 QA 很合适。开放式写作、长时规划、产品决策这类任务就没这么顺。摘要说通用任务也有最高 2.4 点、长度降 4%，但正文片段没披露 benchmark 名称、验证器设计、答案格式约束，也没说“正确答案”在那些通用任务里是怎么定义的。如果所谓 general-domain 仍然是可判分问答，那外推到开放世界 agent 就要谨慎。我对这块有点怀疑，因为很多方法一离开 exact-match 或 unit-test 任务，优势就会迅速缩窄。 拿外部背景对一下，这篇的位置就更清楚了。DeepSeek 把 GRPO 这套训练叙事带火后，业内一直在找两种补丁：一种是补 reward，让终局信号更稳；一种是补 trace，让中间步骤别白白淹掉。GRPO-VPS 明显属于后者。它和 ReST、self-consistency、step-level verifier 这些工作有亲缘关系，但取舍更偏工程：不用再造一个会打分的老师，而是利用 base model 自己对正确答案的 belief 变化。这个思路的好处是简单，坏处是它默认了模型对“离正确答案更近”这件事已经有可读出的内部表征。要是 base model 本身 calibration 很差，probing 信号未必稳。摘要没披露不同基座模型的校准差异，也没说小模型和大模型谁收益更高，这个点我很想看。 我还想追问一个问题：长度下降 13.7% 到底是“少走弯路”，还是“更早停笔”。两者不是一回事。前者说明 credit assignment 真改善了。后者也可能只是模型更快学会短答风格，甚至有压缩推理链的副作用。去年不少 reasoning RL 论文都有这个坑，accuracy 和 token length 一起变化时，如果没有 pass@k、difficulty bucket、错误类型拆分，很难判断模型到底更会推理，还是更会收敛到模板化答案。这里摘要只给了总提升，没有给错误分布，我先保留一点疑心。 我整体是偏正面的。原因很简单：这篇没有假装解决 RLVR 的全部问题，它盯着 GRPO 一个具体缺陷下手，而且给出的机制是可复现的。只要你手里任务有标准答案，这种“边界 probing + 分段进展分数”很容易被抄进现有训练栈。可我不会把它吹成 reasoning 训练的下一站。它更像一块很实用的垫片，能让 GRPO 少犯一些粗糙错误。它能不能变成通用做法，得看三个正文还没给出的数：额外计算开销、分段策略敏感性、以及离开强验证任务后的衰减幅度。

DialToM 这篇论文把 ToM 测评切成两步，结果只有 Gemini 3 Pro 在 Functional ToM 上被点名过关。这个切法我买账，因为它直接戳穿了过去两年很多“ToM 已出现”的宽松口径：模型会选“他现在很生气”，不代表它真能沿着这个状态推出下一轮对话会怎么走。 摘要给出的核心机制很清楚。作者先测 Literal ToM，也就是心智状态识别。再测 Functional ToM，也就是只给状态画像，让模型预测哪条后续对话轨迹与该状态一致。这个设计比常见的角色设定问答更硬一点，因为它把“会描述”跟“会使用”拆开了。很多模型卡在第二步，说明前一类正确答案里混了不少语义模板匹配，不是稳定的社会推理。 这个结论跟过去一年我对 ToM 论文的感觉很一致。早些时候不少工作拿 false-belief、SocialIQA、或故事补全任务做证据，模型分数一高，就容易被解读成“具备心智理论”。问题是这些任务经常把叙事常识、语料频率、人物情绪词共现，全揉在一起。我一直觉得那类结果偏脆。DialToM 至少往前走了一步：它不只问你“懂没懂”，还问你“懂了以后能不能用”。这才接近产品里会撞到的场景，比如客服多轮安抚、陪伴对话、谈判代理。 我对“仅 Gemini 3 Pro 例外”这句会先保留一点。摘要没有披露样本量、题型分布、显著性检验、温度设置、提示词模板，也没说 Gemini 3 Pro 领先多少。只看摘要，我还不能把它读成“Gemini 已拿到社会推理代差”。这类 benchmark 很容易被多选题格式、选项措辞、或模型自带偏好放大。作者还说“人类与模型生成推断只有弱语义相似”，这点反而提醒我：有些模型即便答对，也未必走了接近人类的推理路径。 还有一层我比较在意。摘要写的是 natural human dialogue，这比合成对话强，但正文没披露语料来源、标注协议、文化语言分布、以及“human-verified”具体怎么做。要是数据主要来自单一平台、单一英语语域，Functional ToM 的失败里会混入语用风格迁移问题，不全是心智建模问题。我还没查到 GitHub 细节，现阶段不能替作者补这个洞。 说真的，这条对做 agent 的人更有用，不只是对 benchmark 圈有用。现在很多多轮 agent 框架喜欢把“用户状态”塞进 memory，然后默认规划器会自然用起来。DialToM 的结果像是在说：状态变量写进上下文，不等于模型能把它转成行动约束。你在 CRM、教培、医疗随访里看到的“前面都懂，后面还是说错话”，很可能就是这个断层。这个断层不是更长上下文就能自动补上，很多时候得靠显式状态机、策略约束，或者训练时把 rollout 本身纳入目标。 所以我对这篇的判断是：它没证明 LLM 没有 ToM，它证明了“把状态识别分数当成社会推理能力代理”这件事很不靠谱。论文把数据和代码放出来是加分项，后面有没有分量，要看两件事。第一，别的团队能不能在开放模型和闭源模型上复现 Gemini 3 Pro 的例外。第二，换成自由生成、对抗改写、跨文化对话后，这个差距还在不在。要是这两关过不了，DialToM 也会变成又一个只抓住题型偏好的 benchmark。

V-tableR1 用 4B 模型在表格基准上压过最高 18 倍参数开源模型，这个结果先别急着当成“视觉版 R1 时刻”。我更愿意把它看成一条很务实的研究路线：先挑一个结构最规整、奖励最好验、幻觉最容易抓现行的视觉场景，把过程监督 RL 真正跑通。这个判断我基本认同。多模态推理这两年有个老问题：最后答对，不等于中间看对。模型经常靠版式先验、关键词碰撞、局部数字记忆混过去。表格刚好把这件事钉死，因为单元格、行列、索引关系天然可程序化检查，奖励设计比自然图像、图表问答都干净得多。 文章给出的核心机制也对路：policy VLM 先产出显式视觉推理链，critic VLM 再给逐步反馈，最后用 PGPO 做优化。这里面我最在意的不是“critic-guided”这几个字，而是它承认了一件行业里一直没完全解决的事：结果奖励太稀疏，尤其到了视觉任务，单看 final answer 很容易把瞎猜也奖励了。去年到今年，大家在文本推理上已经把 process reward、verifier、self-critique 轮着试过一遍；多模态一直卡在 grounding 不稳。它现在拿表格这个离散结构做桥接，至少比直接在自然图片上喊“可验证视觉 CoT”靠谱得多。 但我对这条叙事有两个保留。第一，正文没披露基准名、相对 SFT 提升幅度、critic 成本、训练样本规模，这会直接决定这项工作到底是方法突破，还是任务挑得巧。表格领域有些 benchmark 泄漏和模板化很重，模型学会的是单元格定位套路，不一定是更广义的视觉推理。我还没查到它具体跑了哪些集合；如果主要是 WTQ、TabFact、ChartQA 一类邻近任务的变体，那“压过 18 倍参数”这句话信息量就没标题看着那么大。大模型在表格上经常吃亏，原因不是不会推理，而是 OCR 噪声、坐标对齐、长上下文格式化这些工程细节更伤泛化。 第二，我对显式 reasoning trace 一直有点怀疑，尤其在视觉里。链条写得长，不等于模型真在看。这个领域已经见过太多“先答后编理由”的情况，文本模型如此，多模态更严重。V-tableR1 的进步点在于 critic 按步骤扣分，理论上能压制这种后验编造；但 abstract 没说 critic 的标注来源、误判率、以及是否会把“写得像推理”奖励成新的风格偏置。如果 critic 本身就是另一个 VLM，它会不会继承同样的视觉错觉？这个问题没回答，我不会把它当成已解决。 说真的，这篇的价值更像“把表格做成多模态 RL 的小风洞”。这让我想到去年文本侧几条路线：DeepSeek-R1 把可验证任务当作 RL 起点，OpenAI 和 Anthropic 也都在代码、数学这类奖励可判定任务上先把推理链磨出来。V-tableR1 的思路和那套脉络是一致的，只是把可验证环境从 token 空间搬到了表格视觉空间。这个方向我很买账，因为多模态现在最缺的不是再堆一个更大 VLM，而是能稳定测出“你到底在看，还是在猜”的训练场。表格、图表、UI，这类半结构化视觉输入都适合干这个。 我没那么买账的是它往“fundamentally shifting multimodal inference”上拔高。这个说法有点过。表格是视觉任务里最接近符号推理的一档，像文档理解和屏幕代理的中间地带。你把表格上的 process-supervised RL 做成了，不自动推出它能迁移到开放场景视频、多对象空间关系、真实世界图像问答。跨版式、跨 OCR 质量、跨语言、跨分辨率还能不能稳，摘要里都没说。还有一件更现实的事：critic-guided RL 的训练和推理成本通常不会低。4B policy 很省参数，不等于系统总成本低；如果训练时挂一个 critic VLM，实际 recipe 未必比直接 SFT 廉价。 所以我对这篇的结论是：方向比分数更值钱，任务选择也很聪明，但证据还停在“表格这个受控环境里，过程监督 RL 有效”。这已经够重要了，因为多模态圈子太久没把“可验证过程”当主线。后面要不要高看一眼，就看三组缺失信息：具体 benchmark 与增幅、critic 带来的额外成本、以及离开表格后能否迁移到图表和文档页面。如果这些补全后还成立，这篇会比很多刷榜论文耐看得多。

BatchLLM 这篇论文把吞吐拉到 vLLM、SGLang 的 1.3 至 10.8 倍，核心不是模型变了，而是它终于把“批处理请求本来就一起知道”这件事当成一等公民。我的判断很直接：这条价值不在单点算法有多新，而在它戳中了过去一年推理系统一个很实际的偏差——大家都按在线流式服务去卷 TTFT、chunked prefill、连续批处理，结果把离线大批任务里最稳定、最便宜的优化机会丢给了 LRU 和运气。 论文摘要给了三个机制。第一，全局识别共享前缀，不再等 KV cache 被动命中。第二，把共享前缀请求排在一起，避免可复用前缀被 LRU 过早驱逐。第三，优先调度解码占比更高的请求，再做面向吞吐的 token batching，用 prefill 和 decode 去填平 GPU 空洞。这个思路我买账，因为它利用的是 workload 先验，不是靠更激进的 kernel 魔法。很多企业批处理场景本来就长这样：同一个 system prompt、同一套 RAG 模板、同一批文档分类或代码审计任务，只改用户变量。你如果还把它当成一堆彼此独立的 streaming request 去跑，吞吐低并不冤。 我觉得有意思的是，这条路和 vLLM 过去的主线其实不冲突。PagedAttention 当年解决的是 KV 管理碎片化，让连续批处理更能撑住多请求并发；SGLang 这类系统则更强调前缀缓存、结构化程序执行、压低服务开销。BatchLLM 盯的是另一层：当你预先知道整批请求集合时，调度器该不该继续假装自己什么都不知道。答案显然是不该。说真的，这更像数据库和分布式系统的老问题回到了 LLM serving：知道查询计划，就别用通用启发式硬顶。 但我对 10.8 倍这个数字有警觉。摘要只说了 microbenchmark 加一个 typical industry workload，没有披露 workload 分布、前缀重合率、输入输出长度、batch 大小、GPU 型号，也没在这里说明基线配置是不是 fully tuned。这个缺口很关键。前缀共享一旦高，基线又主要依赖 LRU 命中，改成显式全局调度，倍数当然会很好看。可一旦请求更接近在线流量，前缀共享变弱、到达顺序不可重排、SLA 限制更紧，这套收益就会明显收缩。我自己没跑过这份代码，但从经验看，学术里“10 倍”落到真实生产，最后能稳定拿到 1.5 到 3 倍，已经算很能打。 还有一个我不太买账的地方：摘要把问题部分归因给“现有系统偏流式”，这个说法没错，但也有点挑软柿子。流式系统不是不知道批处理能重排，而是很多线上服务根本不能随便重排。谁先到谁先回、租户隔离、缓存污染、公平性、P99 延迟，这些约束一上来，最优吞吐调度就会变成局部最优。BatchLLM 适合的是离线任务、夜间批跑、评测集生成、大规模合成数据、批量代码修复这类场景。要是把论文标题里的收益直接投射到通用 API serving，这个说法我不认。 文章外的上下文也很清楚。过去一年，大家对推理优化的注意力很多放在 speculative decoding、更细的 paged KV、prefix cache、MoE serving、甚至 Blackwell 一类新硬件的 token economics 上。可企业成本里有一块一直很土：同模板任务成千上万条地重复跑。只要 system prompt 和检索模板高度重复，调度器知道“谁和谁共享前缀”，收益就不需要等新卡。这个角度其实有点像早期数据仓库把 scan 改成共享 scan，不性感，但省钱很实在。 我还注意到代码挂在 microsoft/MixLLM 的 batchllm_vllm_064 分支，这说明它大概率不是另起炉灶，而是在现有 serving 栈上做调度与 batching 改造。这个落地路径是对的，因为推理系统最后拼的不是论文里某个点子，而是你能不能塞进现网、能不能和缓存策略、admission control、租户配额一起活。正文没有披露部署复杂度、前缀识别开销、重排代价、以及当共享前缀图谱很稀疏时会不会适得其反。这些如果不展开，论文结论还差最后一公里。 所以我的结论是：这篇论文值得看，但别把它看成“vLLM 被打穿”那种标题党。它更像是在提醒行业，LLM inference 已经开始分层了。在线交互一层，目标是 TTFT 和尾延迟。离线大批一层，目标是 tokens per second per dollar。两层的最优系统不会一样。BatchLLM 把后者讲清楚了，这件事比那组最高 10.8 倍的数字本身更重要。

CEDAR 用两个独立 LLM 代理交错生成计划块和代码块，但摘要没有披露模型名、Kaggle 分数、任务名单和开源状态。我的判断先放前面：这篇的价值在“上下文编排”四个字，不在“自动做 Kaggle”这个标题。数据科学代理这条线一直卡在三个地方：上下文太乱、代码执行会漂、原始数据不能随便外送。CEDAR 至少正面处理了这三个坑，所以方向是对的；但没有成绩单，这还远没到能宣称“agentic data scientist”成立的程度。 我比较认同它把初始提示拆成 DS 专用字段，再让计划代理和代码代理交替工作的做法。Notebook 类任务和纯代码代理不一样。你不是一次性吐出脚本就完事，而是要在 EDA、特征处理、训练、报错修复之间反复切换。把“想什么”和“写什么”拆开，确实更像人在跑 Kaggle。过去一年不少 coding agent 都证明了一件事：长上下文不是药，状态管理才是。OpenAI 的 Deep Research、Anthropic 的 Claude Code、各家 browser agent 都在补同一个洞——不是模型不会写，而是它很容易在多步执行里丢掉约束、污染历史、重复犯错。CEDAR 说的 smart history rendering，我觉得就是冲这个洞去的。 把原始数据留在本地，只给 LLM 聚合统计和指令，这点也很实用。企业里很多表格任务卡的不是建模，而是数据出域。这个设计至少让它有一点落地味，不只是 Kaggle demo。我一直觉得“数据科学 agent”如果离不开把全表喂进模型，那商业上就先输一半。问题也在这里：只传 aggregate statistics，到底够不够支持特征发现、异常值判断、列间交互，这篇摘要没说。很多表格竞赛的胜负手就藏在行级模式里，聚合后会直接损失信号。这个 trade-off 是这篇最该给实验的地方，正文摘要没给。 我对“Kaggle canonical challenges”这几个字有点警觉。Kaggle 差别很大。Titanic、House Prices 这种入门题，和 Santander、Home Credit、OTTO 这类高维表格题，难度不是一个量级。我还没查到论文正文列了哪些题目；如果只是经典教学题，那它证明的是工作流可运行，不是能打。如果给了 private leaderboard、复现实验种子、每题 token 与执行成本，那这条的可信度会高很多。现在这些都没有。学界过去一年有不少 agent 论文喜欢展示“能完成端到端流程”，但不报 private LB，原因大家都懂：public LB 很容易被 prompt 和试错刷出来，泛化没那么好看。 还有一个我不太买账的地方：摘要把“市场价值巨大”放得很前，但没给任何成本结构。数据科学代理不是写个 baseline notebook 就算完。它要跑迭代，要执行代码，要调参，要处理失败恢复。这里的瓶颈常常不是模型能力，而是评估回路和算力预算。我自己也没跑过 CEDAR，不敢替它下死结论；但如果一次任务要十几轮代码生成和多次执行，账单与时延都会很快上去。去年很多软件工程 agent 的共同问题就是 demo 很顺，批量部署就贵得不对劲。CEDAR 没给这部分，我会先保留怀疑。 所以这篇我会把它看成一个对的研究方向，加上一份还不够硬的证据。上下文工程在 agent 时代确实越来越像主战场，尤其是数据科学这种长流程、强状态、强工具依赖的任务。可它现在还没跨过最关键的一步：把“能演示”变成“能比较”。没有模型、没有榜单、没有成本、没有仓库，同行只能判断思路，没法判断强度。

论文提出 Rays as Pixels，并用 1 个视频扩散模型联合建模视频与相机轨迹。这个事件的多源信号很弱，2 条成员实际是同一篇 arXiv 条目重复出现，标题也完全一致。这里没有媒体各自解读的分歧，只有论文摘要这一层官方自述，所以你看到的“共识”基本等于作者自己的 framing。 我先说判断：这个思路比很多“先估姿态，再做新视角生成”的两阶段方案更顺。原因不神秘，位姿估计和可控生成本来就互相约束，覆盖稀疏时更是这样。摘要把问题点说得很准：图像覆盖 sparse，或者 pose ambiguous 时，两件事拆开做会互相放大误差。作者的办法，是把 camera 表示成 dense ray pixels，也就是 raxels，让它和视频帧待在同一 latent space，再用 Decoupled Self-Cross Attention 一起去噪。这个设计至少在表意上是统一的，不再把相机当外部条件表硬塞进生成器。 这条我觉得有意思的地方，不在“第一个统一框架”这句 claim。学术摘要里 first model 这种表述我一向先打折。更有信息量的是，它想把三件事压进同一训练目标：从视频预测轨迹、给定图像和轨迹生成视频、给定图像同时补全视频和轨迹。你如果真能用 1 个模型把这三件事做通，说明模型学到的不是单向映射，而是某种 joint posterior 的近似。过去一年不少 3D-aware video 工作，还是把 camera 当 metadata、token 或额外 control stream 处理；这篇论文直接把 ray 几何变成“像素”，野心更大，也更合理。 我也得泼点冷水。正文摘要没有给出任何核心数字。4 个 tables 在摘要里没展开，pose estimation 提升多少、camera-controlled generation 指标是多少、训练数据规模多大、相机内参外参是否都建模、支持几帧上下文、轨迹长度多长，正文摘录都没披露。标题已经给出联合分布，正文没有披露 loss 配比、采样方式、推理成本。这些不是细枝末节。联合建模听起来很美，训练稳定性和数据标注成本往往才是能不能落地的分水岭。 还有一个我要保留怀疑：他们提出 closed-loop self-consistency test，检查“模型预测的位姿”和“按这些位姿渲染的视频”是否一致。这个测试当然比只看生成视频好，因为它至少在检验闭环。但闭环一致不自动等于对真实世界几何更准。模型完全可以在一个自洽但有偏的内部坐标系里表现很好。没有外部标定基准、没有跨数据集泛化数字，self-consistency 很容易高估实际几何能力。我自己没跑过这套评测，所以这里只能说，摘要里的这项实验设计是加分项，但还不够当铁证。 摘要还专门拿 Plücker embeddings 做消融，并说 shared latent 表示明显更有效。这个比较是对的，因为过去很多方法确实喜欢用 Plücker ray、extrinsics token、或者 separate encoder 去喂几何条件。可问题也在这：如果 baseline 只覆盖了几类经典几何编码，没有覆盖近一年更强的视频扩散骨干或多视图 transformer 变体，结论会偏乐观。项目页也许有更多细节，我还没查到。 放到更大的脉络里看，这篇论文踩中了一个正在升温的方向：视频生成开始从“像不像”转向“能不能被控制，能不能回到几何”。Sora 之后，行业最缺的从来不是再多一个会动的视频模型，而是能和相机、场景、编辑接口接起来的模型。最近一年很多 work 在补 camera control、4D consistency、world model 式表示，这篇是把 camera trajectory 直接拉进生成分布里。这个方向我认同，甚至觉得比单纯堆更长视频更有研究价值。 但这条事件别被“多源覆盖”误导。这里只有 arXiv 原文，没有独立媒体，没有复现实验，没有第三方 benchmark 解读。现在能下的判断只有两句：方法方向很对，证据还不够硬。等项目页、代码、评测细表出来，再看它到底是一个漂亮表述，还是视频几何联合建模里真能留下名字的工作。

这篇论文做对了一件常被金融合规团队反复追问的事：它没有把 LLM 当“会写结论的助手”，而是把分诊流程收紧成“证据约束下的决策器”。摘要给了 5 个核心数：PR-AUC 0.75、Escalate F1 0.62、citation validity 0.98、evidence support 0.88、counterfactual faithfulness 0.76。前 2 个讲效果，后 3 个讲可审计性。对 AML 这种高误报、高追责场景，后 3 个数我甚至觉得比前 2 个更关键，因为合规团队最后签字看的是“这条为什么升单、证据从哪来、改一处事实后结论会不会跟着变”。 我比较认同它把 supporting / contradicting / missing evidence 拆开写。很多“可解释 AI”系统卡在一个老问题：理由只是漂亮的事后文本，和模型判断没有绑定。这里至少用了一个更硬的检验——最小、合理的反事实扰动后，建议和理由要同步变化。counterfactual faithfulness 0.76 不算夸张，反而让我更愿意信一点；如果这里直接报到 0.95，我会先怀疑反事实构造太简单。问题也在这儿：摘要没披露反事实是人工写的、规则生成的，还是另一个模型生成的；没披露扰动空间多大；也没披露哪些字段最常让结论翻转。没有这些细节，0.76 还只是一个方向性信号，不够拿去进生产。 我一直觉得，金融里的 LLM 方案最容易被 PR 带偏到“解释性”三个字，实际落地时审计、法务、模型风险团队盯的是 provenance。这个框架把 citation validity 做到 0.98，至少说明它在“引用存在且格式正确”这件事上很严。可 citation validity 不等于 citation usefulness。引用能不能真的支撑升级决定，摘要只给了 evidence support 0.88，没给误差分布，也没说 12% 不支持的样本集中在哪类 typology。是 structuring、smurfing、shell-company 路径更难，还是客户画像和交易子图冲突时更难，正文外的信息目前没有。 外部对比上，这套思路其实更像过去一年企业里成熟一点的 RAG 审批流，而不是“让模型直接做判断”。医疗和法律文档助手也在走类似路线：先检索证据，再强制输出引用，再做一致性检查。差别在 AML 多了一层 transaction subgraph 和政策规则耦合，所以单纯的 RAG-only 往往不够。我没看到正文里的消融表，但摘要已经说了它比 rules、tabular、graph ML、LLM-only、RAG-only 都好。这个叙事我基本信，因为 AML 本来就是异构信号拼接任务：规则抓触发，图抓关系，文本抓政策与案情。把三者硬拆开，通常都不会赢。 但我对“public synthetic AML benchmarks”还是有明确保留。合成数据在 AML 研究里太常见了，原因大家都懂：真数据出不来。问题也很直接：合成图谱和交易行为通常比真实世界干净，概念漂移、对抗性规避、跨机构信息缺口都弱很多。0.75 的 PR-AUC 放在公开合成集上是可以看的数，不等于放进银行告警队列还能扛住。尤其是 escalation 这种少数类决策，Escalate F1 0.62 只说明“有用”，还谈不上“省人命”。如果银行现网升级率本来只有几个百分点，阈值一变，调查员负载就会立刻抖动。摘要没披露 base rate、告警量级、人工复核节省多少，也没说 latency 和 token 成本，这些才是采购时绕不过去的表。 我还想 push back 一点：作者把“governed, verifiable”讲得比较顺，但治理不只是输出格式受控。AML 的麻烦在于政策会变、地区会变、红旗规则会变，客户上下文也常有缺失。如果检索层没版本化，今天引用的政策条款和下周审计时看到的条款不是一个版本，再漂亮的 citation 也站不住。我没在摘要里看到 policy snapshot、evidence store versioning、或 case replay 机制。少了这层，系统更像一个写得规矩的 copilot，还不是完整的审计系统。 所以我的判断是：这篇的价值不在“LLM 能做 AML”，这个结论 2025 年大家就已经在试了；价值在它把可解释性往可核验推进了一步，而且用了反事实去卡“理由跟结论脱钩”这个老毛病。说真的，这个方向是对的。只是材料目前只有摘要，关键缺口还很多：基准构造、反事实生成、消融细节、成本延迟、版本治理都没披露。没这些，适合把它当成一套设计模式，不适合直接当成性能背书。

ZeroFolio 用预训练文本嵌入跑赢了 11 个 ASlib 场景里的手工特征基线，这个结果不小。它把算法选择压成三步：原始实例文件序列化、通用嵌入、加权 kNN。单配置赢了 10/11。双种子投票到 11/11。对做 AutoML 和组合优化的人，这不是小修小补。它在说一件更刺耳的事：很多年里我们给 SAT、MIP、CSP 设计的实例特征，信息密度未必比一个够强的 embedding 前端更高。 我买账的部分在这里。ASlib 这套基准本来就很吃特征工程。传统做法常是先造 instance features，再上随机森林、回归器或成对排序器。ZeroFolio 直接跳过那一步，还跨了 7 个领域。这个统一性很少见。我记得过去一年，LLM for optimization 那波论文大多卡在“会解释、不会选”。这篇反过来，不解释，直接选，而且只靠原始文本格式。这个方向比很多把求解器包装成 agent 的文章实在。 但“零领域知识”这个说法，我不太买账。它没有手工特征，没错。可它依赖一个更早被世界知识训练过的文本嵌入器。正文摘要没披露具体模型、维度、上下文长度、tokenization 细节，也没披露嵌入成本。要是嵌入器见过大量代码、约束、DIMACS 风格文件，它带进来的先验就不算零。还有一个问题更硬：ASlib 的训练测试拆分，是否会让格式相近的实例彼此靠近？如果是，kNN 吃到的可能先是“文件写法相似”，再是“求解难度相似”。摘要没给这部分控制实验，我自己会卡在这里。 文里点名了 3 个关键设计：逆距离加权、行打乱、曼哈顿距离。这个组合挺有意思。行打乱尤其说明作者自己也知道，模型可能过度依赖局部顺序和模板痕迹。换句话说，这更像“把原始实例当近似 bag-of-constraints”，而不是理解语义结构。这里有点像前几年 code embedding 在 clone detection 上的表现：先靠表面模式吃分，再慢慢逼近结构信息。能用，当然能用。别急着把它说成通用推理。 我还想看两个对照，摘要都没给。第一，跟更强的非参数基线比，比如直接在手工特征上做 kNN，或用 learned metric。现在它打的是随机森林特征基线，这个靶子不算最硬。第二，跨分布测试。比如按年份、生成器、实例规模切分，而不是常规随机拆分。算法选择这件事最怕训练集邻居泄露。你在 benchmark 上找到了“附近的旧题”，上线时用户丢来一个新生成器，命中率就会掉得很快。 说真的，这篇最有价值的，不是它宣告特征工程终结，而是它给了一个便宜且统一的默认起点。以后做新领域算法选择，先别花两个月手搓 80 个特征。先把原始文件喂给 embedding+kNN，打一个很难看的强基线，再决定要不要上领域知识。这个工作把 baseline 门槛抬高了。只是标题里的“zero domain knowledge”我会保留意见。没有看到嵌入模型细节和更硬的分布外验证前，这还不能当成普适结论。

WorkflowGen 这篇先给了两个数：中等相似查询成功率提升 20%，相对实时规划 token 消耗下降超过 40%。我的判断很直接，这条的价值在工程路径，不在能力前沿。它把 agent workflow 这件事从“每次都现场想一遍”改成“先查历史模板，再局部改写变量节点”。这个方向我认，因为很多企业代理场景本来就不是开放世界推理，重复结构远多于全新任务。你让模型每轮都从零规划，贵、慢、还容易把同一个坑踩第二次。 我对论文叙事也有保留。摘要反复讲 trajectory experience、error fingerprint、template induction，听着很完整，但正文公开信息很薄：只有定性对比，没给绝对样本规模，没披露 similarity 分桶阈值，没讲基座模型、工具数、任务分布、失败定义，也没看到标准 agent benchmark。少了这些，20% 和 40% 很难复现。中等相似查询这个条件尤其关键，因为这类方法天生吃 query distribution；如果生产流量大多落在高相似区，收益会更大，如果长尾很多，路由命中率就会掉得很快。 说真的，这个思路不是凭空冒出来的。我第一反应是它站在 2024 到 2026 这波 agent memory 和 workflow retrieval 的延长线上：LangGraph 一类框架早就在讲 durable execution，Anthropic、OpenAI 的 agent API 也都在往 tracing、tool state、run replay 靠。再往研究侧看，过去一年不少工作都在做 trajectory reuse、plan retrieval、case-based reasoning，只是名字不同。WorkflowGen 比较实在的一点，是把“经验”拆到节点级和工作流级两层，再配一个三层路由：直接复用、重写生成、全量初始化。这个设计至少符合线上系统的成本函数，因为不是所有请求都值得走完整规划。 但我有个疑虑没法跳过：他们把“只重生变量节点”讲成效率优势，这没错，可系统脆弱点也正好在这里。工作流里很多 bug 不是单节点参数错，而是上游一个小偏差改写了下游约束，最后整条 execution path 都漂了。局部重写能不能稳，取决于依赖图是不是显式、变量传播是不是可验证、异常指纹是不是覆盖主要故障模式。摘要没给这些机制细节。我自己没看到 formal check、回滚策略、或跨节点一致性验证，所以目前我更愿意把它看成“经验驱动的 workflow patching”，不是可证明稳定的 planner。 还有一点别忽略：这类方法最适合业务查询、表单流转、固定工具编排。场景越封闭，历史轨迹越值钱；场景越开放，历史轨迹越容易变成过时偏见。去年不少 agent 项目上线后遇到的就是这个问题——前 2 周命中率很好，工具接口一改、知识源一换，缓存下来的经验立刻老化。我还没查到这篇对 experience aging、冲突模板淘汰、在线评估有没有系统处理。如果没有，部署一段时间后维护成本会追上来。 所以我会把 WorkflowGen 放在一个更准确的位置：它像是给 agent 系统补上“执行经验层”，有实际落地味道，也很符合 2026 年大家开始算 token ROI 的行业气氛；但标题里的 adaptive generation 容易让人误以为这是新的规划范式。现有信息还支撑不到这个结论。要让我提高评价，至少得看到三样东西：绝对样本规模、相似度路由的阈值和误判代价、以及在公开 benchmark 或真实线上流量上的长期退化曲线。没有这些，这篇更像一份合理的系统 design note，不是已经坐实的通用方法。

BMBE 用“LLM 做传感器、贝叶斯引擎做诊断”这套分层，直接戳中了医疗 agent 这两年最别扭的问题：大家一直拿会说话，当成会推断。摘要给了三个硬主张：患者数据不进 LLM、后端可按人群替换且不用重训、便宜传感器加统计引擎能打过同家族前沿模型。这个方向我认可，因为它不是在修补 hallucination，而是在切断 hallucination 能接管诊断的权限。 我一直觉得，医疗场景比客服和 coding 更不适合端到端大模型。原因很简单，错了以后你要追责，要复盘，要知道是哪条证据把后验概率推上去。纯 LLM 医生在这件事上天然吃亏。去年的一批医疗问答和分诊工作，很多都能把平均分做得挺好看，但 calibration、coverage、拒答阈值一拆开就不好看。我记得 Med-PaLM 2 之后，业内讨论就已经转向“临床可用不等于 benchmark 高分”，只是大多数产品最后还是回到一个黑箱回答器，因为部署快。BMBE 这篇至少是在架构层面承认：语言生成和概率推断不是一回事。 但我对摘要里的“同家族前沿模型被便宜传感器+引擎击败”还是有保留。赢多少，按什么口径赢，正文这页没披露。准确率、AUROC、ECE、selective risk、每轮对话 token 成本、知识库构建成本，都没给。还有一个关键点也没展开：LLM 作为传感器时，结构化抽取本身会不会把病人描述压扁。医疗对话里最难的常常不是算后验，而是把“胸闷”“像被压着”“半夜更明显”这种自然语言，稳定映射成症状、时长、严重度和否定项。传感器这一层如果漏掉 10% 关键证据，后面的贝叶斯再可审计，也只是把错的输入算得很漂亮。 外部参照也很明确。过去一年，多数医疗 LLM 产品讲的是 guardrail、RAG、人工复核，很少有人把推理权彻底从模型里拿走。这个思路反而更像传统 expert system、probabilistic graphical model，外面套一个会对话的壳。听起来像倒车，我不这么看。医疗本来就是低容错、高审计行业，很多“老办法”当年输给深度学习，不是因为逻辑错，而是因为接口太差、知识维护太贵。现在 LLM 把自然语言接口补上，这类模块化系统又活过来了。 我还没查到 PDF 里的 17 张表和 12 张图，所以没法判断他们的 separation gap 到底有多稳，也不知道 adversarial patient communication 是口语噪声、方言、误导性表述，还是刻意攻击。要是只是在合成扰动上赢，这个说服力会打折。要是在人群迁移、低资源语言、不同医疗体系上还能靠替换 backend 顶住，那就不是论文技巧，而是产品路线。现在我给这条的判断很直接：方向对，证据还不够满。它最像的不是“更强医疗大模型”，而是一种把 LLM 降级使用的工程宣言。医疗 AI 迟早会走到这一步。

ParetoSlider 这篇 paper 把多目标扩散对齐往前推了一步：作者声称在 SD3.5、FluxKontext、LTX-2 上，用 1 个连续偏好条件模型逼近整条 Pareto 前沿，还能达到或超过为固定权衡分别训练的基线。这个判断我基本买账，因为它打的不是“生成质量又涨了多少”，而是一个更工程化的痛点：同一条图像编辑链路里，prompt adherence、source fidelity、审美偏好本来就互相拉扯，过去常见做法是先把奖励按固定权重揉成 1 个标量，再为几个权重点各训 1 个 checkpoint。部署上很笨，产品上也僵。 我一直觉得，扩散模型后训练这条线过去一年有点被 LLM 对齐叙事盖住了，但图像侧其实更需要这种机制。原因很简单：图像任务的冲突目标比文本更显性。你做编辑时，文本跟随度高 10 分，原图保真常常就掉一截。早标量化的问题不在“数学不优雅”，而在它把选择权锁死在训练阶段。ParetoSlider 试图把这个选择权移回推理阶段，这比再发一个风格更强的新 checkpoint 实用得多。 外部参照也能看出这条路为什么成立。去年到今年，扩散后训练里常见的是单奖励优化，像美学分、偏好分、压 prompt 漂移，各自都能做，但一到多目标，很多方法还是固定 reward mixing。我记得在图像编辑和视频生成里，团队经常直接维护多个 LoRA 或多个 finetune 版本，按场景切模型。那套办法能跑，但运维成本高，评测也碎。ParetoSlider 如果真能用连续权重条件把 trade-off 学进去，价值不只是省 checkpoint，而是把“对齐目标”从离散 SKU 变成连续控制面。 但我对这篇的保留也很直接：摘要没给任何指标。论文说“matches or exceeds”，可没说超过多少、在哪些 reward 区间超过、是不是只在训练分布附近成立。Pareto front 这种说法听起来很顺，实际最容易藏问题的地方也是这里——你可以在中间几个权重点表现很好，边界点却塌掉；也可以平均分更高，但牺牲极端偏好下的可控性。正文如果没有完整曲线、不同偏好权重下的 win rate、以及和独立训练基线的采样预算对齐，我不会太早下结论。 还有一个我想追问的点：连续偏好条件是否真的学到了“可组合目标”，还是只是在几个离散权重点之间做平滑插值。这个区别很大。前者说明模型内部形成了比较稳定的 reward geometry，后者只是把 model soup 换了个说法。很多 conditional generation 方法在 demo 里 slider 很顺，离开训练过的权重区间就开始失真。摘要没有披露 extrapolation、OOD prompts、也没有讲权重采样策略，我还没法判断它属于哪一类。 说真的，这条我更愿意把它看成扩散版的“test-time preference interface”研究，而不是单纯一篇 MORL 论文。LLM 那边这两年已经有一堆人在做可调 verbosity、helpfulness-harmlessness 权衡、人格强度控制；图像侧现在才开始把这个接口认真做成训练目标。要是 ParetoSlider 的完整结果扎实，后面大概率会看到两件事：一是图像编辑产品减少多模型路由，二是视频模型也会跟进，因为视频里的时序一致性、指令服从、视觉保真冲突更狠。 我现在的结论不复杂：方向是对的，摘要证据还不够硬。标题已经给出“单模型、三骨干、连续控制”，正文摘要没披露具体 benchmark、奖励定义、采样成本和失败案例。没有这些，先别急着把它吹成通用解法。

PODS 把 GRPO 的更新样本裁成子集，并在论文所测设定里用至少 1.7× 更快速度追平 vanilla GRPO 的峰值测试准确率。这个结果有分量，因为它打的不是 rollout 生成，而是 RLVR 里一直最难受的那一段：更新侧显存重、通信重、吞吐差。 我对这条的第一判断是：这不是“再发一个更会采样的小技巧”，而是在给 RLVR 训练栈改成本结构。过去一年大家都在盯采多少条 rollout、奖励怎么做、长度怎么控。PODS 把问题改成另一句：既然 rollout 便宜、更新昂贵，那为什么每条 rollout 都要进 optimizer。这个想法很像大规模推荐和 active learning 里常见的“便宜收集，贵的只训一部分”。放到 LLM RL 里，点子不新，落到 GRPO 上就有用了，因为 GRPO 本来就依赖 group 内相对奖励，冗余样本一多，更新未必更值钱。 论文给的核心机制是 max-variance down-sampling，用奖励多样性挑子集，还给了 O(n log n) 实现。这里我觉得作者选的切口是对的。RLVR 场景里，很多 rollout 的信息量根本不均匀。对刷题型推理任务，常见情况是大部分样本奖励塌在同一侧，只有少数边界样本决定 policy 往哪偏。你把这批边界样本优先喂给更新器，梯度质量往往比“全吃”更高。这个判断和去年一批 rejection sampling、best-of-N、RFT 工程经验是合拍的：生成很多，学习少量高信息密度轨迹，常常比均匀吃完更省。 但我对“至少 1.7× 更快”还是有点警觉。摘要只说追平 vanilla GRPO 的峰值测试准确率，没披露四个关键口径：一是绝对准确率是多少；二是比较的是 wall-clock、step 数还是优化器更新时间；三是 rollout token 数有没有一并算进总成本；四是用了哪些模型规模和集群配置。这个差别很大。如果 rollout 生成占总时长已经过半，那更新侧省下来的 1.7×，落到端到端训练未必还有这么多。如果作者测的是单机或小规模多卡，通信优势到大集群上可能更明显；反过来，如果 benchmark 很短，长上下文推理未必复制同样收益。正文没在摘要里给这些数，我不会先把它当成通用结论。 我还想补一层文章外的上下文。GRPO 这套路子之所以火，和 DeepSeek-R1 一波公开化有很大关系：大家都看到了 verifiable reward 在数学、代码、规则型任务上的可操作性，也都撞上了同一个工程墙——采样能横向堆机器，更新一上来就吃显存、吃 all-reduce、吃 batch 组织。PODS 抓的就是这堵墙。它未必直接提高模型上限，但很可能提高“同样预算下，RL 值不值得开”的阈值。对很多团队，这比 benchmark 多 1 分更实际。 我自己的保留意见有两个。第一，按奖励方差挑样本，容易把训练推向“高分歧、低代表性”的区域。短期看收敛快，长期看分布覆盖可能变差，尤其在奖励稀疏或 reward hacking 风险高的任务上。第二，这套方法目前看更像为可验证奖励定制。到了偏主观偏好、长程 agent 任务、工具调用链很深的环境，奖励噪声更大，单看 reward diversity 够不够，我不确定。 所以这篇论文我会记成一句话：它在提醒大家，RLVR 的瓶颈不只在 reward design，也在“哪些样本值得更新”这个被低估的系统问题。要不要兴奋，得等正文里的绝对分数、token 预算、子集比例、模型尺寸和硬件表补齐。没有这些，1.7× 是个好信号，还不是结论。

pAI/MSc 把任务限定为“指定假设生成投稿草稿”，并声称把人工引导降几个数量级，但摘要没有给模型配置、基线、样本量。我的判断是，这条如果成，价值不在“AI 会做研究”，而在它把研究里最碎的三段流水线——文献对齐、形式化推导、实验补洞——压成一个可反复调用的协作接口。 这个定位我反而觉得靠谱。过去一年里，业内冒出来的“AI scientist”项目，像 Sakana AI 的那套自动生成 idea+run experiments+writeup，最容易翻车的环节一直不是写作，而是问题设定和结果筛选。假设一旦是人给的，系统空间立刻收窄很多，失败模式也更可控。理论研究这块尤其如此：你不需要 agent 凭空找题，你需要它先把定义、引理、相关工作、反例和实验 sanity check 串起来。这个工作很费时，也很适合多 agent 分工。 但我对“降几个数量级”这句有点警觉。数量级不是修辞，是至少 10 倍。要成立，正文至少得给出两类证据：一类是从 hypothesis 到初稿的总工时，对比人类手工流程；一类是草稿质量，比如定理证明错误率、引用幻觉率、实验可复现率。摘要一项都没给。没有这些，开源系统最多只能先被当成 research ops 工具，而不是研究生产力的明确跃迁。 我还有个现实层面的怀疑：ML theory 不是普通综述写作。数学论证里一个量词顺序写错，整页就废；实验支撑里一个 hidden assumption 没写清，投稿时就会被 reviewer 抓住。多智能体系统往往擅长铺陈，不擅长在这种高惩罚环境里稳定自检。OpenAI Deep Research、Google Gemini 的长链检索在资料整理上已经很强了，但一进严格证明，可靠性马上换了量级。我自己还没看完整论文，所以不敢下死结论；只看摘要，这更像“面向理论论文的 research IDE”，不是自动科学家。这个定位已经够有意思，没必要往大了讲。

这次其实只有 2 个来源，且标题完全一致：一个是 arXiv 条目，一个是 Takara 对同一篇论文的转述。这个覆盖面本身不说明社区已形成共识，只说明论文刚被索引，信息源基本收敛到作者摘要，没有二次采访，也没有独立复核。两边表述高度一致，不像市场在各自解读，更像是围着同一份 abstract 打转。 论文给出的最硬信息有 4 个：基座是 BentoML 服务栈；模型是预训练 RoBERTa 情感分类；负载分布用了 gamma 和 exponential；部署层面提到单节点 K3s 集群抗扰动。问题也很直接：正文没有披露延迟分位数、吞吐、并发规模、批大小、GPU/CPU 规格、优化前后提升幅度。标题说的是“Scalable AI Inference”，摘要也说“performance analysis and optimization”，但没有这些数字，你很难判断它到底是在优化 Python 服务开销、容器编排、模型运行时，还是仅仅把一个本来就不重的分类模型调顺了。 我对这条最大的保留意见就在这里：RoBERTa 情感分类是个很稳的选择，复现实验容易，变量也少；但它离 2026 年推理系统最痛的场景不近。今天大家卡的是长上下文 KV cache、prefill/decode 失衡、连续批处理、请求串扰、显存碎片、路由器和调度器抖动。拿一个 encoder-only 小模型去讨论“scalable inference”，能说明 Web 服务层、队列层、部署层的一部分问题，说明不了当下主流 LLM serving 的主战场。这个说法我不太买账，至少标题有点大。 当然，这不代表论文没价值。恰恰相反，工程界一直缺一种更朴素的研究：把负载分布、尾延迟、吞吐退化、故障恢复这些基础指标老老实实跑清楚。很多团队做内部服务压测，方法并不比这篇更规范。摘要里提到用 gamma 和 exponential 模拟 steady、bursty、high-intensity 流量，这个思路是对的，因为线上请求从来不是均匀分布。只要作者在正文里给了 p50/p95/p99、利用率、饱和点、以及优化项的显著性检验，这篇就能当成 BentoML/K3s 小规模部署的经验材料来看。 跟过去一年更有参考性的推理论文比，这篇的位置比较靠“通用服务工程”，不在“LLM 内核创新”。像 vLLM、SGLang、TensorRT-LLM、PagedAttention 这一线，价值都建立在明确机制和明确增益上：显存利用率怎么变，吞吐在多大 batch 下涨了多少，长短请求混跑时尾延迟怎么收敛。这篇摘要只说做了 runtime、service、deployment 三层优化，却没说每层改了什么。我还没查到 PDF 里的表格，如果没有逐层 ablation，这个结论会很虚。 还有一个细节得点出来：单节点 K3s 的“resilience during disruptions”能回答的是轻量集群在故障下怎么退化，不是生产级多区容灾。很多人看到 K3s、scalable、resilience 这几个词会自动脑补成云上大规模服务能力，这就有点过了。单节点本身就限定了故障域，恢复策略和跨节点调度不是一回事。 所以这条事件我会这样看：两家来源的统一口径来自同一篇论文，不是多方独立背书；论文的价值在方法论和可复现实验框架，不在它已经证明了“AI 推理服务该怎么做”；标题给得很满，摘要给的证据还不够。要不要认真看，取决于你是不是正在搭 BentoML 或小规模 K8s/K3s 推理栈。如果你关心的是大模型在线服务，这篇大概率只能给你外围经验，给不了核心答案。

SkillGraph 这篇论文把 49,831 条成功轨迹挖成有向加权图，并在 API-Bank 把 Kendall-τ 从 -0.433 拉到 +0.613；我对这个结果的判断很直接：它抓住了今天工具型 agent 一个被低估的故障点，很多系统不是不会找工具，而是不会把工具按可执行的依赖顺序排出来。 我一直觉得，社区这两年把“tool use”说得太像检索问题了。给任务，做 embedding，召回若干 API，再让模型挑一个或排个序，流程很顺，但里面偷偷混了两个完全不同的子问题。第一层是“哪些工具相关”，第二层是“这些工具能不能接上”。论文把这两层拆开，Stage 1 做 GS-Hybrid retrieval，Stage 2 用 pairwise reranker 学顺序，这个建模思路比 headline 里的 Set-F1 0.271 更有价值。Set-F1 0.271 不算高，ToolBench 上 16,000 个工具的空间也确实难，但 API-Bank 上 τ 从负数翻到正数，说明旧方法在结构化工作流里连顺序方向都经常排反。 这个结论跟过去一年 agent 实践很对得上。OpenAI、Anthropic、各家 framework 都在强调 function calling、tool schemas、structured outputs，可线上真正难调的经常不是 schema 合不合法，而是多工具链路里的 hidden state。先搜用户、再拿 user_id 查订单、再发退款，这种链条里第二步依赖第一步的字段，不在 tool description 里，也不是“退款 API”和“用户 API”语义接近就能学到的。LangGraph、AutoGen、CrewAI 这类框架过去一年都在补显式状态图和工作流编排，背后其实是同一个现实：纯 prompt 驱动的 agent 在跨工具状态传递上不稳定。SkillGraph 只是把这个工程痛点，往“图先验 + 排序学习”上推了一步。 我觉得作者最聪明的地方，是没有把图拿来直接替代语言模型，而是把它当 prior。这个路子像推荐系统里常见的“召回看语义，重排看行为”，也有点像搜索里的 learning-to-rank。LLM 负责理解任务意图，图负责补历史执行结构。说真的，这比“再训一个更大的工具使用模型”务实得多。过去一年你能看到很多工具 agent 论文继续堆 base model size，从 7B 到 70B，benchmark 有提升，但一碰到企业内部 API 或冷门操作链就掉得厉害，因为模型记住的是文档相关性，不是组织流程。SkillGraph 至少承认了一件事：工作流知识有一部分不在参数里，而在执行图里。 但我也有几个保留。第一，49,831 条“成功轨迹”听着不少，放到 16,000 个工具的组合空间里其实还是稀的。图先验很容易学到高频路径，低频但关键的长尾组合怎么办，正文没披露。第二，API-Bank 的提升非常大，-0.433 到 +0.613 这种跳幅让我会先看评测设定：候选集怎么给，负例怎么采，pairwise reranker 看到多少上下文，正文摘要没说。这个量级的提升有时说明方法有效，有时也说明 baseline 设得太接近“拿错问题做解”。第三，它依赖“成功轨迹”挖图，这对真实生产环境是优点也是限制。大公司有日志，小团队没有；私有 API 经常改版本，图会老化；权限、配额、时效性这些线上约束，图里未必编码得进去。 我还想补一个文章里没有的背景。ToolBench 这类 benchmark 过去就有一个老问题：很多任务更像离线规划，不太像线上 agent 的交互闭环。我没重新核实最新 leaderboard，但我记得不少方法在 ToolBench 上能把工具选得像样，一到真实业务就栽在参数传递、异常恢复、重试策略上。SkillGraph 这次把“顺序”单独拎出来，等于把 benchmark 从“选对名字”往“能不能执行”挪了一步，这个方向是对的。只是它还没碰到更麻烦的一层：当中间某一步返回空值、脏值、或格式漂移时，图先验怎么改写计划。若没有这一层，系统更像 workflow recommendation，而不是完整 agent control。 所以我对这篇的态度是：方向对，叙事也克制，离“通用工具 agent 的答案”还远。它最有价值的地方，不是 0.271 这个分，而是明确告诉大家，工具推荐和工具排序不能再共用一套语义相似度逻辑。谁还在用 embedding 相似度同时做召回和排序，基本就是把依赖图当文本分类题做。这个做法在 demo 里能跑，在结构化业务里迟早翻车。

FT 用 3 个标题覆盖同一事件，核心判断很一致：英国高收入员工更快使用 AI，职场数字鸿沟正在扩大。这里的信号不是“又一份 AI 调查”。信号是 FT 同时用科技、劳动力不平等、数字鸿沟三个叙事框架处理它，说明这已经从工具采用问题，变成收入结构问题。 这次多源结构有点特殊。3 个 member 都来自 ft-technology，不是 3 家独立媒体交叉验证。一个标题叫“The AI digital divide”，走的是社会分层框架；一个标题叫“High earners race ahead on AI as workplace divide widens”，把主语压到高收入员工；一个标题问“Will AI widen inequality between workers?”，把它放进劳动力收入差距。它们并没有提供互相独立的数据来源，只是同一编辑体系下的不同入口。覆盖宽度说明 FT 想把这件事抬成主题，不说明事实强度自动提高。 正文抓取内容很不完整。标题已给出“英国调查”“高收入员工采用更快”“职场差距扩大”，正文未披露样本量、调查机构、收入分组、AI 定义、采用频率、行业分布。没有这些字段，我不会把它当成严肃因果证据。比如“使用 AI”是每周用 ChatGPT 写邮件，还是公司内部接入 Microsoft 365 Copilot？是自报使用，还是日志观测？两者含义完全不同。自报会放大白领、管理层、技术岗的可见度；日志会更接近企业软件部署现实。 但我买这个方向。过去 12 个月企业 AI 落地的一个残酷事实是：最容易先吃到收益的人，不是最容易被替代的人，而是已经有自治权、数据权限、文字产出密度和试错空间的人。高收入知识工人通常有四个优势：能访问付费工具，能把任务拆成 prompt，能判断模型输出质量，能把省下的时间转成绩效。低收入岗位往往没有这些条件。客服、仓储、门店、护理、运输这些岗位，不是没有 AI，而是 AI 常常以监控、排班、质检、脚本约束的方式进入，不是以个人生产力工具进入。 这跟 2023 年那套“AI 会让低技能员工追上专家”的叙事有冲突。那套叙事有实验基础，比如客服、写作、编程教学里，低分位员工在受控任务中收益更大。但企业环境不是实验室。实验给每个人同一个工具、同一个任务、同一个评价标准。公司里，AI 权限先给总部、法务先卡基层、IT 先开白名单给管理层，培训预算先落到高薪岗位。机制一变，收益分布就反过来了。 我对“高收入员工 race ahead”这个表述也有一点警惕。它容易把结构性部署问题讲成员工个人积极性问题。高收入员工不是天生更愿意学 AI。他们的工作更可文本化，更可异步，更容易把模型输出塞进已有 workflow。律师、咨询、产品经理、投研、软件工程师的任务，有大量草稿、检索、总结、代码、表格和演示文稿。相比之下，低薪服务业岗位的 AI 接入点往往被公司掌握，员工没有采购权，也没有自动化自己任务的空间。 对 AI 从业者来说，这件事刺耳的地方在产品设计。很多 B2B AI 团队还在用“seat adoption”证明价值。可 seat 本身就是阶层变量。谁有企业邮箱、谁能装插件、谁能连内部知识库、谁能绕过数据合规审批，决定了谁先被统计成 AI 用户。你拿这个 adoption curve 去讲“组织整体效率提升”，其实漏掉了组织里大量没有 seat 的人。 外部对比也很直接。Microsoft 365 Copilot、Google Gemini for Workspace、ChatGPT Team/Enterprise 的价格和部署路径，天然偏向高薪白领部门。即便单席价格从几十美元降下来，真正的门槛也不是订阅费，而是权限、数据、培训和经理是否允许员工改变流程。开源模型和本地部署理论上能降低门槛，但普通员工不会自己拉 Ollama、接 RAG、做权限隔离。工具便宜不等于采用平等。 所以我不会把这条读成“AI 会自动扩大不平等”的宿命论。更准确的判断是：默认企业部署路径会扩大采用差距。要扭转它，靠模型再便宜一点不够。需要把 AI 嵌入低收入岗位的可控工作流，并把收益分配给员工，而不是只给管理层做监控仪表盘。正文没给调查细节，所以结论别拔太高；但 FT 反复推这个角度，说明主流财经媒体已经开始把 AI adoption 从技术扩散曲线，改按工资层级读了。这个转向对厂商销售话术很不友好，也更接近办公室里的真实情况。

论文直接否定了社会世界存在“真实数据生成分布”这个前提，并把矛头指向公平机器学习常用的抽样叙事。我的判断是，这篇东西打中的不是预测技术本身，而是研究社区长期默认的一层修辞：先说样本来自某个分布，再把标签、群体划分、损失函数、部署边界都藏进“估计误差”里。作者说经典学习理论几乎不用改，这句话很关键。它不是要把 PAC、ERM、泛化界全推翻，而是要你承认：在招聘、信贷、警务、医疗分诊这些场景里，数据对象、测量口径、决策目标先是制度选择，后才是统计对象。 这条我基本买账，因为过去几年社会技术研究已经反复撞到同一堵墙。Cathy O’Neil、Ruha Benjamin、Selbst 等人讲的都是一个问题：很多“公平”争论最后不是卡在优化器，而是卡在标签是谁定义、样本是谁被看见、未来是否会因模型介入而改写。分布稳定、独立同分布、未来像过去，这些假设在广告点击率还能勉强用，在保释风险和儿童福利分配上就很悬。Google 2019 年那篇《Fairness and Abstraction in Sociotechnical Systems》我记得也是这个脉络，只是没像这篇这么正面去拆“真实分布”本身。 但我也有个保留。标题和摘要给了强判断，正文片段没展示他们怎么处理不确定性、抽样噪声和反事实比较。你不能因为“社会世界没有真实分布”，就滑到“概率语言都别用了”。很多政策评估、因果推断、校准分析还是得靠概率对象，只是这些对象更适合作为建模约定，不该被说成自然存在物。要是作者最后只是把 distribution 换成 population，却不交代群体边界谁来定、时间漂移怎么处置，那只是换词，不是解决。说真的，这篇值得读全文，但目前只有摘要信息，我还没看到它把这一步走实。

这篇论文把问题设成“给一条多子任务流水线逐步选模型”，这个设定比现在大多数 router 论文都更接近 agent 落地。摘要给了一个关键信号：上游模型的输出，会改写下游模型的输入分布、token 成本和成功率。只要系统里有 summarize→verify→extract 这种链路，单步路由的独立同分布假设就已经不太成立了。作者拿 neural contextual bandit 做 sequential selection，还强调“不需要历史性能数据”。这点我觉得方向是对的，因为很多团队现在的 routing 现实就是：新模型一周一更，老 benchmark 过两天就失效，静态路由表根本撑不住。 但我对摘要里“优于其他 LLM selection algorithms”这句有保留。文章只说了 2 个真实数据集，没披露数据集名称、候选模型数量、子任务数、cost 定义、成功率口径，也没说对手是谁。是和简单的 UCB、Thompson Sampling 比，还是和近一年常见的 classifier router、reward model router、speculative cascade 比？这差很多。论文还说证明了 regret 对任务数是次线性的，这在 bandit 文献里是该有的理论姿势，不等于工程上就更好用。神经 contextual bandit 一旦遇到非平稳模型供应，比如 API 厂商悄悄换 checkpoint、价格改 tier、上下文窗口限速变化，理论前提经常先碎掉。摘要没有交代这块，我不会先替它补分。 我自己更在意的是，这条线和过去一年 routing 研究的偏移是对得上的。2024 到 2025 那波论文，很多还在做单 query 选 GPT-4 还是小模型，优化的是平均 cost 或 pass@1。可一旦进入 agent pipeline，错误不是独立累加，而是级联放大：第一步摘要丢了一个日期，第二步验证可能“验证”一段已经错的压缩信息，第三步抽取再把错结构化。这个问题在企业工作流里很常见，尤其是医疗、法务、财务文档。摘要里那个 medical records 例子就不是随手举的，它正好踩中高耦合链路。换句话讲，这篇论文至少抓到了一个真问题，不是在旧 benchmark 上再磨 0.8 个点。 我还有一个疑虑：作者把“无历史性能数据”当卖点，但 bandit 不是不需要数据，而是把离线数据需求换成在线探索成本。这个账在真实生产环境里很贵。你让系统边跑边学，谁来承担前几百次探索中的失败样本？如果是客服、投研、医疗摘要，探索失败不只是多花 token。摘要没有说明它怎么处理安全约束、失败代价上限、人工回退，正文如果也没有，这篇更像一个漂亮的在线学习框架，还不是能直接进高风险生产的方案。 还有个外部背景可以补一下。我印象里，近一年不少 LLM router 工作默认把“选模型”视作一个平面分类问题：看 query embedding、看长度、看领域标签，然后挑最便宜还能过线的模型。这个范式在 chatbot 上还能凑合，在多步 agent 上经常失真，因为你真正要选的不是某一步最强模型，而是整条链路的组合策略。前一步选贵模型，可能把后两步的失败率和 token 消耗都压下来，最后总成本反而更低。摘要已经明确说它在学这种链式依赖，这块我觉得比“用了 neural bandit”更有信息量。 所以我的判断是：问题定义值得认真看，实验结论先别急着信。标题和摘要已经给出 sequential routing、sublinear regret、2 个真实数据集，正文片段没披露 benchmark 细节、基线设置和在线探索代价。要是后文能把这些补齐，这篇会对 agent orchestration 很有参考价值；补不齐，它就还是一篇把正确问题讲明白、但离部署有距离的学术稿。

这篇论文抓得很准：self-consistency 在数学和代码任务里，确实经常把算力浪费在同一批高概率前缀上。DLE 的核心动作很直接——在截断解码树里按固定预算枚举不同叶子，少走已访问分支，还复用共享前缀。只看摘要，这比“独立采样 N 次再投票”更像一个工程上能落地的搜索改写，而不是再加一层花哨 reranking。 我对这条线一直是偏看好的，因为过去一年 test-time compute 的增益，很多都不是来自更长链路，而是来自更少重复。Tree-of-Thought、best-of-N、self-consistency、MCTS 变体，问题都一样：你愿意花 8 次、16 次、32 次采样预算时，重复前缀会把边际收益吃掉。DLE 至少正面处理了这个结构性浪费。摘要里提到两个收益来源，一个是算法层面的覆盖率更高，一个是系统层面的前缀复用更强，这两个点都说得通。尤其对代码生成，前 20 到 50 token 高度模式化，缓存命中率往往很高，少重复走这些前缀，延迟和 token 成本都该下降。 但我对摘要的胜出表述还是有点警觉。正文片段没有给 3 个关键条件：一是比较对象到底是 temperature-based self-consistency，还是带去重/缓存的强基线；二是“固定预算”按 token、按 wall-clock，还是按模型调用次数算；三是截断深度怎么设。少了这 3 个口径，DLE 打赢基线这句话信息量并不够。很多搜索法论文都会在“同样 sample 数”下赢，却在“同样延迟”下输，因为树遍历调度和 KV cache 管理并不免费。 还有一层我想补。这个方向和近一年的 speculative decoding、prefix caching、batch tree decoding，其实是同一类思路：别把每条候选轨迹都当成完全独立请求。我没查到这篇是否直接连接 vLLM、SGLang 或 TensorRT-LLM 的执行图；如果没有系统实现，只停在算法模拟，那离线上好看、线上一般的风险不小。说实话，我更想看的是：在 Qwen、DeepSeek 或 GPT-4 级别长推理模型上，给同等 token 预算，DLE 相对 best-of-N 能省多少实际生成 token，吞吐抬多少，准确率涨几点。标题已经给出方法名，摘要给了方向，正文片段没披露这些最硬的数。

POP 这篇最有价值的点，是它把“自博弈只适合可验证任务”往前推了一步。作者让 Qwen-2.5-7B 同时生成输入、输出、评分量表，再回到预训练语料上做约束。这个设计不是小修小补，它在碰后训练里最麻烦的一块：开放任务没有标准答案，reward model 又很容易学会迎合表面格式。 摘要给了两个机制。第一，同一模型先写 rubric，再按 rubric 打分训练。第二，把过程锚定在内容密集的预训练文本上，拉开发生生成与验证的间隔，压制 reward hacking 和 mode collapse。这个思路我觉得是对的。过去一年很多 self-play 工作都卡在数学、代码、工具调用，因为验收条件硬，奖励信号干净。开放式写作、医疗长问答、指令跟随一直难做，不是模型不会写，而是你很难稳定判断“写得好不好”。POP 等于先把判卷标准也内生化了。 我对这里的 pushback 也很直接：同一个 Qwen-2.5-7B 既出题、又答题、又写 rubric，闭环偏差很难天然消失。作者说预训练语料能制造 generation-verification gap，这个说法有启发，但摘要没披露 gap 是怎么量化的，也没说 rubric 质量怎么审计。没有这些细节，我不会默认它已经解决 self-rewarding 里最老的问题：模型给自己偏好的风格打高分，最后把分布越训越窄。Anthropic 和 OpenAI 过去在偏好优化上都反复遇到这类事，所以现在更常见的是人类偏好、外部 judge、对抗采样一起上，而不是单模型闭环。 外部参照也很明确。去年到今年，社区对 RLAIF、self-rewarding、constitutional-style critique 的兴趣一直在涨，但多数成果都依赖更强的 judge，或者限定在可验算任务。POP 如果真能只靠 7B 级模型，在开放任务上稳定产出可用后训练信号，意义不小：这会把“造高质量偏好数据”的门槛往下砍一截，尤其对没有 GPT-5 级教师模型预算的团队很实用。问题是，摘要只说“提升了”医疗长问答、创意写作、指令跟随，正文片段没给具体分数、样本数、训练 token、对照 baseline，也没说有没有牺牲事实性和长度控制。只看标题，我还没法判断这是方法突破，还是一组挑得比较友好的 benchmark。 我自己的结论是：方向值得认真看，证据还不够硬。要让我信这不是另一版“模型学会给自己发奖状”，至少得看到三样东西：一是和外部评审或人工评审的一致性；二是不同语料密度下的消融；三是 rubric 迁移到别的模型后还能不能打出同样排序。现在只有标题和摘要信息，这篇先记在“有潜力，但别急着复现神话”那一栏。

论文在 1,085 次实验里测试双组件架构，并把因果发现里的两个能力拆开：context graphs 提升切换后的推理准确率，dynamic behaviors 负责发现旧假设空间失效。我的判断很直接：这条如果结论站得住，它戳中的不是“LLM 会不会因果推理”，而是很多 agent 系统一直混着算的一笔账——搜索能力、记忆能力、框架切换能力，根本不是一回事。 我一直觉得，过去一年不少 agent 论文把失败都归因到“模型不够强”有点偷懒。很多时候不是模型不会在既定空间里做贝叶斯式更新，而是系统根本没有机制承认“我当前用的变量、规则、对象类型都错了”。这篇文章拿 blicket detector 范式来测这个点，方向是对的。发展心理学里，blicket 任务本来就是拿来测儿童怎么从观察和干预里形成新的因果表征。把它搬到 LLM agent 上，至少比单纯做多跳问答更接近“重构假设空间”这个硬问题。 abstract 给出的数字也有信息量。作者说，假设空间切换之后，94% 的准确率增益来自 context graphs；dynamic behaviors 的作用不是把答案做得更准，而是让系统意识到该换框架，避免过早锁死旧假设。这个拆法我比较买账。因为很多人把 agent scaffold 讲成一团浆糊：图结构、反思、工具调用、记忆、planner 全都往里塞，最后只报一个总分提升。这里至少试图回答“哪一层在干哪件事”。对做 agent infra 的人，这比再看一个 end-to-end 成绩单有用得多。 但我对这篇也有几处保留，而且都很关键。第一，正文只有 abstract，没披露基座模型、对照组、任务难度分层、统计显著性，也没说 1,085 次 trial 是几个任务模板乘出来的，还是跨多类环境独立采样。没有这些信息，94% 这个数字只能先当组件贡献分解的作者口径，不能直接当通用规律。第二，blicket 风格任务很适合测表示切换，却也很容易把世界压成低维离散因果图。系统在这种环境里能重构假设空间，不等于它到了开放世界 agent 场景还行。代码代理、网页代理、科研代理里的“范式切换”，通常夹杂工具失败、目标漂移、观测噪声和长时延反馈，难度高一截。 这条和过去一年几类工作能接上。我先想到的是 ReAct、Reflexion、Tree/Graph-of-Thought 这一脉。它们都在想办法让模型多走几步、多反思几次、多分叉几条搜索路径，但默认前提大多是问题空间已经给定。你在这张地图里绕路，不等于你会重画地图。更近一点，很多 browser agent 和 SWE agent 的改进，也是在提升“在既有任务表示下的探索效率”。这篇论文如果成立，它在补的是另一层：什么时候该承认 state representation 本身错了。说实话，这层能力比多 5 分 benchmark 更稀缺，因为它决定 agent 是卡死在错误抽象里，还是能自救。 我还想到一个外部参照：去年到今年，不少人把 memory 说成 agent 的总钥匙，长上下文一上去，系统就会“更懂任务”。我一直不太买这个说法。长上下文解决的是保留证据，不自动解决解释证据的框架更新。你可以把 200 页日志都塞进上下文，系统还是会在错误 ontology 里越想越偏。按这篇的分法，context graphs 像是把推理过程约束成类型化状态机，dynamic behaviors 像是一个“框架失效报警器”。这比单纯堆更多 memory slot 更接近工程上可控的办法。 还有一个我自己挺想看、但 abstract 没给的数据：dynamic behaviors 的误报率和漏报率各是多少。因为这类机制最怕两头翻车。误报高，系统会频繁切换假设空间，推理成本暴涨，还容易把简单问题做复杂。漏报高，系统还是会在旧框架里死扛。现实部署里，这个 trade-off 比平均准确率更重要。很多 agent 系统不是输在不会想，而是输在切换太慢或切换太勤。标题里讲“architectural scaffolding enables hypothesis-space restructuring”，我认同方向；但要说它已经解决这个问题，abstract 远远不够。 我的结论是：这篇论文把一个经常被混写的能力结构拆清了，价值不小。它不证明 LLM 已经接近人类式因果发现。它先证明了一件更朴素也更重要的事：如果系统里没有显式机制去侦测“当前假设空间不够用”，那你给再强的模型、再长的上下文、再复杂的搜索树，很多时候也只是更体面地卡住。后面要看全文能不能把 baseline、模型细节、切换成本和开放环境泛化补齐；补不齐的话，这条更像一篇概念上对、工程上还早的研究。

X-IONet用单个IMU把Go2上的ATE/RTE分别压低52.8%和41.3%，这组数比人类数据集上的14.3%和11.4%更说明问题：作者解决的不是“再提一点精度”，而是把原本跨平台直接失效的设定拉回可用区间。我对这条的判断是，它的价值主要在系统设计，不在某个新网络块。规则式专家选择、平台专属专家、位移不确定性输出、再接EKF，这是一套很典型也很务实的机器人栈，重点是承认不同运动体的惯性统计根本不一样。人走路的步态频谱、触地节律、机体刚性，和四足机器人差太多，硬拿RoNIN那套表征迁到Go2，掉点是正常结果，不掉才奇怪。 我想到的外部参照是 RoNIN 之后那批 learned inertial odometry 工作，很多方法在人类手持或腰挂场景里已经把纯IMU轨迹做得像样，但一换设备安装位姿、采样频率、或者运动形态，性能就明显散掉。机器人侧也一样，四足平台更常见的是 IMU + joint encoder + foot contact + LiDAR/VIO 做融合，单IMU本来就不是主流配置。放在这个背景里，X-IONet的意义不是“替代多传感器”，而是给极简、低成本、失效退化场景补一层可运行方案。这个定位我买账。 但我对“cross-platform”这个表述有点保留。正文只有摘要，没披露训练集混合比例、专家切换错误率、IMU安装位置是否统一、采样频率如何对齐，也没说Go2自采数据集规模。没有这些条件，跨平台更像“先判别人类/四足，再走各自专家”，不是一个模型天然学会了平台无关动力学。说实话，这种 route-then-specialize 的方法通常很好用，可泛化边界也很明确：一旦碰到没见过的跑跳、跌落、斜坡、载荷变化，规则分类器和专家网络可能一起失手。摘要里也没给实时性、功耗、延迟，机器人真上机时这些指标不比ATE次要。 还有一点我想继续追。作者输出位移和不确定性，再交给EKF融合，这说明他们自己也不完全信神经网络的瞬时预测，要靠滤波把误差模型收住。我反而觉得这是成熟信号，不是缺点。过去一年机器人里一个很清楚的趋势，就是端到端模型在感知上越来越强，但状态估计这层还在回到“学习模块给观测，经典滤波保底”。X-IONet也站在这条线上。标题给了跨平台，摘要给了降幅，正文没披露失效案例和消融细节；在看到这些前，我不会把它看成通用惯导的拐点，更像一篇很会选问题、也很懂落地约束的论文。

作者在 25 个模型、6 种语言里复现出一条很稳的规律：词形特征能在线性探针下持续读出，词汇身份在浅层最强，往深层一路变弱。我对这条结论是买账的，因为它跟很多人做 steering 时的手感一致：你在中后层还能把某个属性“读”出来，不代表你还能轻松把它“推”回去。论文把这个断层点明了，价值不小。 我觉得最有信息量的不是“词形一直可解码”，而是“中层激进降维会削弱干预效果，哪怕 probe accuracy 还高”。这句话直接捅到解释性研究这两年的老问题：probe 成绩很好看，因果作用却不跟着走。过去从 BERT、GPT-2 到后来的 logit lens、tuned lens，圈里一直在争一件事——隐藏状态里有信息，和模型在当前计算路径里依赖这份信息，是两回事。这个 paper 给了一个更结构化的解释：表示几何在中层被压缩后，线性可读性还能保留，但可操纵性先掉了。说真的，这比再报一个 probe F1 高多少更有用，因为它更接近 intervention 的边界。 这也顺手给“representation engineering”泼了点冷水。过去一年很多工作喜欢把线性方向、概念向量、残差流 patching 放在一个筐里讲，容易给人一种错觉：只要概念能被线性分离，就能稳定 steer。这个说法我一直不太买账。你看这篇的结果，至少在词汇身份和词形特征上，模型内部已经把“保留可读信息”和“保留可控接口”分开处理了。尤其是词汇身份随深度衰减，这很像 transformer 在往预测友好的压缩表示走：表层记住 token 是谁，深层更关心它对下一个 token 预测还剩多少条件价值。抽象一点讲，模型不是在“忘词”，是在丢掉对生成没那么值钱的局部标识。 我还挺喜欢它做了 6 种语言，而不是只盯英语。词形变化丰富的语言，通常更容易把 inflection 当成模型内部的稳定信号；这点如果只在英语上看，很容易低估。去年不少多语 probe 工作都碰到类似现象：形态信息比词面 identity 更“耐深层”。我没逐页核实验图，所以不想硬报具体语言差异；摘要只给了总结，没披露各语言的效应大小、方差和统计显著性，这些都决定结论有多硬。 我自己的保留意见也很明确。第一，线性探针很容易吃到 dataset artifact，尤其 lexical identity 这类任务，如果 tokenization、频率分布、词位上下文没控干净，浅层优势会被放大。标题和摘要没披露 probe 任务构造、负例采样、控制变量，我还不能判断这个风险压到了什么程度。第二，“steering effectiveness”具体怎么定义，正文摘要没写。是 logit shift、目标属性翻转率，还是下游任务指标？这三种口径差很多。第三，25 个模型听着不少，但上限只写到 Qwen2.5-7B。没有更大的闭源前沿模型，也没有近期长上下文架构，结论能不能外推到 GPT-5 级别系统，我不会直接点头。 不过就算有这些缺口，这篇还是有实用价值。做 interpretability 的人可以少把 probe accuracy 当终点，多看几何压缩和 intervention 灵敏度是不是同向变化。做 steering 的人也该更谨慎地挑层：中层未必是因为“概念最清楚”才好用，有时只是还没压缩到失去操作空间。等正文细节出来，我最想看两组东西：一是不同架构的中层压缩位置是否稳定，像 BERT、Llama、Qwen 之间有没有一致层段；二是 pretraining 过程中词形特征“早稳定”、词汇身份“晚演化”到底对应哪些训练 token 数区间。要是这两组数站得住，这篇就不只是 probe paper，而是在解释为什么很多 steering 方法到了中后层突然变钝。

COMPASS 这篇最有价值的点，是作者把多语适配的问题重新放回“数据分布”上，而不是继续在共享参数和语言亲缘性上打转。论文声称它在 Phi-4-Mini、Llama-3.1-8B、Qwen2.5-7B 这 3 个模型族上，都优于按语言相似度挑辅助数据的基线。这个判断我基本认可，因为多语负迁移本来就不只发生在词表和语法层，更多时候是任务语义覆盖不均。你拿西语数据去补葡语，语言距离看着近，但如果目标流量里 40% 是法律问答、训练补进去的却是日常对话，最后照样掉点。用多语 embedding 加聚类去找“语义缺口”，至少方向是对的。 我对这条的积极评价，主要来自过去一年这类工作的共同结论：很多多语训练收益，其实不是“更多语言一起练”带来的，而是“更像目标分布的数据被挑出来”带来的。之前不少 work 已经证明，数据选择常常比继续堆 token 更划算，尤其是在 7B 到 8B 这个量级上。Llama 3 系列之后，业内对 multilingual continued pretraining 的热情其实降了一截，原因也简单：全量重训太贵，收益还不稳定。PEFT + 数据筛选因此变得更实用。COMPASS 选的是 language-specific adapter，而不是一个共享 LoRA 硬吃全部语言，这一步很务实。多语言共用一套低秩更新，干扰往往先出现在中低资源语言上，这个坑大家这两年都踩过。 但我对论文叙事也有两处保留。第一，摘要只说“优于 linguistic-similarity baselines”，没说幅度、显著性、训练预算是否对齐。是提升 0.8 分，还是 8 分，差别很大；是相同 token 预算下赢，还是因为它多看了更合适的数据，也得分开看。Global-MMLU、MMLU-ProX、OneRuler 这些 benchmark 覆盖了知识问答和长上下文，方向不错，可它们离真实线上分布还有距离。尤其 OneRuler 这类长上下文测试，常常更像检索与定位能力测试，不等于真实多语 agent 工作流。摘要没披露具体增益，我不会直接把它当成生产结论。 第二，我对 COMPASS-ECDA 的“持续学习”部分有点怀疑。标题和摘要给了一个很顺的故事：线上监测分布漂移，动态更新 adapter，既避免陈旧，又保留旧知识。问题是，生产里最难的从来不是“发现漂移”，而是“多久更一次、拿什么数据更、谁来验收没退化”。正文摘要没有更新频率、回滚机制、算力成本，也没有讲 drift threshold 怎么设。你要是每周更新一次 20 种语言 adapter，MLOps 复杂度会直接上去；你要是每季度才更，那很多热点领域早过时了。这个账不算清，持续版就还只是研究姿态，不是运维方案。 还有一个我想补的外部背景：过去一年很多团队做 multilingual PEFT 时，已经从“按语言划分”转向“按任务或领域划分”，因为语言标签本身太粗。比如客服、代码、法律、医疗，跨语言共享的往往是任务结构，不是语系亲缘。COMPASS 用语义簇替代语言相似度，算是顺着这个趋势往前推了一步。这也是我觉得它比老派 language-family sampling 更靠谱的原因。可它还没有回答另一个更尖的问题：语义簇是离线 embedding 空间里的簇，不一定等于线上高价值请求的簇。embedding 用哪一版、多语对齐误差多大、聚类粒度怎么定，都会影响最后抽样。摘要里这些关键条件都没披露。 所以这篇论文我会把它看成一个扎实的“数据选择框架”，不是已经完成闭环的 continual adaptation 系统。静态部分有工程价值，特别适合预算有限、又不想为每种语言单独全量微调的团队。持续部分我暂时不买账，除非作者后续补出 3 组信息：每次增量更新的 token/算力成本，线上漂移检测到更新生效的延迟，以及更新后旧 benchmark 的保留率。没有这 3 个数，COMPASS-ECDA 更像论文里很好看的最后一节。

CHASM 用 4992 条小红书样本测了现有 MLLM，结论很直接：zero-shot 和 in-context 都不够可靠。这个结果我基本买账。中文社媒里的隐性广告，本来就不是 OCR 加分类那种题。它更像三层信号叠加：图像摆拍、正文话术、评论区导购。只抓前两层，模型很容易把“像广告的真体验”判错，也会把“像日常分享的投放”放过。 这篇论文有价值，不在 4992 这个数字本身，而在它把评测目标放对了。过去很多内容审核 benchmark 盯毒性、仇恨、违规词，文本边界更清楚。隐性广告麻烦得多，因为平台上最常见的样本不是硬广，而是带一点生活感、再带一点交易转化的灰区内容。我印象里，英文世界更常测 disclosure、sponsored 标签、FTC 合规，中文平台这类公开数据一直很少。CHASM 至少把“中文、多模态、真实社媒场景”这三个条件绑到一起了。 我也有保留。正文只有摘要，没披露基线模型名单、分数、标注一致性、类别分布，也没说评论区信息在输入里怎么组织。没有这些，"不可靠" 这个判断还没法换算成部署标准。比如 F1 是 0.58 还是 0.78，平台决策完全不同。再比如正负样本如果接近均衡，那跟真实线上流量也会有偏差；真实场景里隐性广告占比通常低，漏判和误杀的成本不对称。 开源模型微调后明显提升，这点也符合这两年的经验。很多中文平台治理任务，通用大模型差在 domain prior，不是差在纯能力。给它看几千条高质量标注，收益往往比再堆 prompt 大。我寻思了一下，这跟去年不少视觉语言模型在电商质检、票据理解上的表现很像：zero-shot 不稳，进到垂类数据后会突然像样。但别把这读成“再做个微调就上线”。论文自己已经点了最难的两块：评论细微信号，图文结构差异。前者要求模型理解互动关系，不是单帖分类；后者要求它知道一张图里哪个元素是证据，哪个只是生活噪声。 我对另一个叙事也有点怀疑：把这件事完全交给端到端 MLLM。平台真要做风控，最后大概率还是多级系统。规则先筛一遍，图文模型给风险分，评论网络和账号历史再补证据，人工只看高风险池。单模型 benchmark 很重要，但它离可用审核链路还有一段。摘要没给这些系统层面的实验，所以这篇更像在说明“通用模型还不够”，不是已经给出生产解法。

作者把 gpt-oss-20b 的专家切换率从超过 50% 压到低于 5%。这不是小修小补，我觉得它碰到的是 MoE 过去两年一个很烦的硬伤：训练时按 token 动态路由很好看，部署时显存、预取、卸载全被高频抖动拖垮。 我一直觉得，很多 MoE 论文默认了一个过于干净的 serving 世界：专家已经在卡上，路由开销近似为零，跨卡流量也能吃下。现实没这么客气。Mixtral 8x7B 那波之后，业内就反复撞到同一个问题：参数总量能做大，活跃参数也能控住，但一旦专家集放不进单机显存，token 级切换会把 KV 之外的系统层复杂度直接抬高。这个工作把 RL 里的 option-critic 和 deliberation cost 搬进来，让模型学会“别每个 token 都换专家”，思路很顺，而且比重新预训练一个 MoE 便宜得多——摘要写的是 LoRA 加自蒸馏，说明作者在押后训练改造，而不是从头再烧一遍大集群。 但我对摘要里的胜利口径有保留。第一，90% base accuracy 这句并不轻。放在 MMLU 这种静态基准上，掉 10% 不是边角损失，很多场景已经过线变不过线。第二，正文现在只看到摘要，没看到 latency、吞吐、显存峰值、PCIe 或 NVLink 传输量，也没看到 expert load imbalance 怎么变。你说切换率从 50% 到 5%，我信这会帮预取和卸载；你说它因此“可用于高效 serving”，我还得看 end-to-end numbers。Nvidia、vLLM、DeepSpeed 这类系统论文过去也常见这种情况：机制上很对，最后线上收益只落成 1.2x 到 1.5x，因为瓶颈换地方了。 还有一个疑点。摘要说给“每层”加控制器，学什么时候切换、加载哪些专家。这个设计如果控制器本身不够轻，就会拿新的控制开销去换旧的路由开销。标题和摘要没披露控制器参数量、训练稳定性、序列长度敏感性，也没说长上下文下 option 会不会僵住。continual learning 也只是被提到，正文未披露实验。 说真的，这条论文我看好它成为一类很实用的 retrofit 技术，尤其适合已经有 dense base model、又想吃一点 MoE 推理红利的人。它未必会变成新的主流架构名词，倒很可能被 quietly 吸进推理栈里，变成“减少专家抖动”的默认手段。前提只有一个：作者得把服务侧账本补齐。没有 wall-clock、显存占用和不同 batch/seq 条件下的数据，这篇现在还停在“方向靠谱”，没到“工程可用”。

论文提出 SGT 用一个小型 LLM 生成补充文本，并在不改动底座模型的条件下追加到输入里。我的判断很直接：这条更像“推理时编译器”路线，不像模型训练路线；如果实验站得住，它对企业 agent 的价值会高过又一轮底座微调。 原因不复杂。很多 agent 任务掉点，不是底座模型完全不会，而是上下文组织差、工具说明散、计划步骤丢失。让一个便宜的小模型先写一段 task-specific supplement，再喂给更强的模型，本质上是在推理前做结构化预处理。这个想法跟 2024 到 2025 年那波 prompt optimization、self-refine、retrieval planning、memory shaping 很接近，只是这里把“补充内容生成”单独训练成了一个模块。说真的，这个方向我一直比较买账，因为它顺着成本曲线走：你不需要每次都碰 70B 以上底座，也不用等闭源模型开放微调接口。 但我对论文叙事有两个保留。第一，摘要只说“improving performance”，没给任何数字。没写是单步工具调用任务，还是长轨迹 agent benchmark；没写提升 2% 还是 20%；也没写成本增加多少 token。这个缺口很大。补充文本如果把输入拉长 30% 到 100%，在 API 计费场景里，省下的训练钱会被推理 token 吃回去。我还没看到他们怎么算总账。第二，很多这类方法容易偷偷吃到“额外测试时计算”红利。你表面上没改大模型，实际是在前面加了一个 learned prompt generator。学术上这当然成立，产品上也能用，但别把它包装成几乎零代价的能力跃迁。 文章里没有的上下文其实不少。去年到今年，业界已经反复验证一个事实：在工具使用、代码修复、网页导航这类 agent 任务上，轨迹质量和上下文编排经常比底座再加一点通用能力更重要。像 ReAct、Reflexion、DSPy、一些 router/planner 架构，核心都在“先把任务翻译成模型更容易解的格式”。SGT 的新意，如果我没理解错，不是这个大方向本身，而是把 supplement 生成器明确做成可训练、可替换、面向任务迁移的部件。这个定位是对的，因为闭源前沿模型更新太快了。你今天围着 GPT-5.x 或 Claude Sonnet 4.5 做后训练，三个月后 API 行为一变，很多工作就得重来；前置补丁层反而更耐版本波动。 我还有个疑虑：补充文本到底是在提升“推理质量”，还是只是在泄露更强的任务模板？这两者差很多。如果 supplement 主要学会把用户问题改写成更详细的 SOP，那它更像 prompt engineering automation。价值不是没有，但泛化往往有限。换一个工具集、一个网页 DOM、一个企业内部系统，模板就碎了。摘要没有给 benchmark 名称，也没有给跨模型迁移结果，所以现在还不能判断它是方法论，还是一个对特定任务分布有效的技巧。 我会愿意继续看全文，但前提很明确：得看到至少三组信息。第一，补充文本带来的准确率或成功率提升，按任务拆开给。第二，新增 token、延迟、总成本一起给。第三，换底座模型还能不能成立，比如从一个开源 8B/70B 到另一个闭源 API 是否仍有效。没有这三项，这篇就先当成“把 prompt optimizer 训练化”的一条研究线，不要急着上升成 agent 新范式。

论文用 Weisfeiler-Lehman 变体把节点分组，再把这些组写成颜色 token。这个设计打的不是图算法本身，打的是提示表面的“可读性偏置”。我对这条思路是买账的，因为很多 LLM 图任务失败，并不全是推理深度不够，前面那层序列化就已经把结构信息糟蹋了。数字标签、任意字母、节点 ID 这类编码对模型来说太像噪声占位符；颜色词至少带有人类语料里反复出现的稳定语义壳，attention 更容易挂住这些锚点。 但这篇现在只能先给到“方向对”，还给不到“结论稳”。摘要说在合成和真实数据、多类图任务上都有 considerable improvements，正文片段没给具体增幅，也没给基线细节。是比纯邻接表强，还是比 GraphML 风格文本强，还是比随机 token relabeling 强，片段里都没有。这个差别很大。要是只赢最弱基线，那价值有限；要是连 canonical ordering、BFS/DFS 序列化、位置标记这些更强文本化方案也能稳定赢，这才算一条新路。 我自己更在意两个机制。第一，颜色 token 可能不是因为“可解释”才有效，而是因为它们在预训练语料里频率高、分布稳、和别的词有天然关联。也就是说，收益未必来自人类可解释性，可能只是借了常见词汇的 embedding 先验。第二，WL 类本来就做了一次结构压缩。模型表现变好，可能主要来自预处理替 LLM 干了活，而不是 LLM 学会了更强的图推理。这个 pushback 很关键，因为如果提升主要来自 WL 预编码，那卖点应当写成“图特征工程接到提示上”，不是“LLM 更懂图了”。 这条线放到过去一年的脉络里，其实挺顺。GraphGPS、Graphormer、还有不少 graph-to-text 工作都在证明一件事：图结构进语言模型前，表示法比很多人以为的更重要。去年我看过几篇类似工作，会把节点角色写成 textual descriptors，常常比生硬 ID 稳；这个现象和代码任务里“有语义的变量名”优于 a1、b2 很像。LLM 对 token 形式高度敏感，这不是新发现，但很多 benchmark 论文还在假装输入表示是中性的。它从来都不是。 我还有个疑问没法从摘要里确认：这种颜色映射在图规模变大时怎么扩展。颜色词表如果太小，不同结构类会碰撞；词表如果太大，又会退化成另一种任意标签。WL 变体迭代多少轮、颜色集合大小、跨图是否共享映射，片段都没披露。还有 permutation invariance 也不能只靠颜色解决，节点线性化顺序还是会影响 prompt。要是作者没有把 ordering 单独控制，这个结论会打折。 所以我对这篇的判断是：想法是对的，证据还不够硬。它提醒大家，LLM 做图任务时先别急着怪模型不会推理，很多时候是你给它的“图语言”写得太差。可我不想把这篇直接吹成图推理突破；标题给了方法，摘要给了方向，最关键的增幅、基线、消融，正文片段还没展开。

HiPO 把 DPO 拆成 3 类推理片段，并在多个 7B 模型上跑赢基线；摘要没给分数、权重和评测设置。我的判断是，这篇东西的价值在训练接口，不在结果数字。它抓住了 DPO 在推理任务里的老问题：整段偏好只给终局信号，中间步骤写得乱、跳步、偷换条件，loss 也未必真罚得到。把 query clarification、reasoning steps、answer 分开算，本质是在不引入完整 RL 管线的前提下，把 credit assignment 往前推了一步。 这条路子我觉得比很多“再堆一个 search 框架”更实在。过去一年里，推理增强常见两条线：一条是 ReST、ReMA、RFT 这类带 rollout 或多轮反馈的做法，效果常常不错，训练和复现都偏重；另一条是 DPO、KTO、IPO 这类偏好优化，稳定、便宜，但对长链推理的中间错误不够敏感。HiPO 想吃两边的优点，所以它至少在研究方向上是对的。尤其数学题这种任务，错误经常不在最终答案句，而在第 3 步到第 6 步的约束传播。整段胜负标签会把这些细节抹平。 但我对论文现在这套叙事有保留。摘要说“多个 7B LLM”“多种常见数学基准”“GPT-4.1 评价组织性和一致性更好”，这些都像是该给表格的地方，结果一个关键数字都没露。提升了多少，1 分还是 10 分，没说。三段 loss 的权重怎么设，固定还是调参搜出来，没说。分段边界是人工标，规则切，还是模型切，没说。这个问题不小，因为层级方法最容易赢在 annotation 或 segmentation 规则，而不一定赢在优化目标本身。要是切分规则含了额外监督，拿它去对比普通 DPO 就不算干净。 我还想追问一个点：它是不是只适合答案结构很规整的数学文本。Math Stack Exchange 数据天然有“题目理解—推导—结论”这类显式段落，分三段很顺。换到代码修复、工具调用、开放问答，边界会模糊很多。比如 agent 轨迹里，观察、计划、调用、反思常常交错出现，硬切 3 段未必成立。我自己没看到正文，所以不能下死结论，但如果作者没有做跨任务验证，那这更像“针对数学格式优化的 DPO 变体”，还谈不上通用 adaptive reasoning。 还有个现实问题。摘要强调“保持 DPO 的计算效率和稳定性”，这个我部分相信，因为它没上 PPO 那种重采样管线。可分段 loss 往往会带来新的超参敏感性。去年很多偏好优化论文的问题都不是主公式，而是 beta、长度惩罚、chosen/rejected 构造方式一换，结论就变。我没查到 HiPO 是否做了权重鲁棒性实验；如果没有，工程上会很难直接照抄。 所以我现在的看法很简单：这个想法值得继续读，尤其适合手上已经有成对偏好数据、又嫌 RL 太重的团队；但在正文披露完整表格前，我不会把它当成 DPO 之后的下一站。我要看的不是“优于基线”这句话，而是三件具体东西：各基准绝对分数、三段权重的敏感性、去掉 segmentation 后还剩多少增益。没有这些，这篇更像一个合理的 research sketch，不是已经站稳的训练配方。

这篇论文提出了一套透明筛查框架，用有限可观测信息估算 LLM 训练与推理影响，但摘要没有披露误差范围、覆盖模型数、基准真值或验证条件。我的判断很直接：这事方向对，而且比一堆拍脑袋的“某模型更绿”报告严肃得多；可在没有校准结果前，它只能回答“量级大概在哪”，还回答不了“这个榜单能不能拿去做采购决策”。 我一直觉得，AI 能耗和碳排讨论最大的问题，不是大家不关心，而是闭源 API 把关键变量全藏起来了。你拿不到 GPU 型号、batch size、并发、PUE、区域电网强度、训练 token、重训频率，最后就只剩厂商口径和零散推断。这个框架至少做对了一件事：它承认自己不是直接测量，而是代理估算，还把来源链条摆出来。说真的，这比很多“我们精确估算了某家模型足迹”的论文诚实。过去一年这类工作里，我印象较深的是把查询成本、延迟、模型尺寸、硬件代际拼起来反推能耗的几类方法；问题也都一样，最后卡在误差传播。上游每个假设偏 20%，末端结果就能飘到没法看。摘要现在没给误差带，我不会把它当成稳定排名器。 还有个地方我有点怀疑：它把自然语言应用描述转换成有界环境估计，这一步很聪明，也很危险。聪明在于现实世界的需求输入本来就是“客服总结 500 字工单”“生成 30 秒广告脚本”这种任务描述；危险在于任务描述和实际调用路径之间，差了至少 3 个变量：prompt 模板、上下文长度、工具调用次数。一个“写摘要”任务，1000 输入 token 和 40k 输入 token，推理影响不是一个量级。去年不少企业上 RAG 后，向量检索和长上下文把总成本抬高，不是模型参数本身变大。如果框架只吃任务文本，不吃真实 token 分布、重试率和 tool use 轨迹，估算很容易系统性偏低。摘要没说这部分怎么补，我还没法买账。 外部参照也很关键。MLPerf Inference 这类基准能给硬件侧吞吐和能效，但它测的是受控 workload，不是闭源服务。云厂商偶尔会披露某代 TPU 或 GPU 的能效改进，可那是平台指标，不是具体模型服务指标。这篇论文想补的正是中间那层空白：从用户任务到服务影响的可复现代理。这个切口是对的。我自己更想看到它拿公开可复现的开源模型先做校准，比如 Llama、Qwen、Mistral 这类能在已知 GPU、已知 token 长度上跑出真值，再看代理法能否把误差压到可用范围。要是连开源场景都对不齐，放到 GPT 或 Claude 这种闭源服务上就更悬了。 我还想追问训练侧。摘要把训练和推理放在一起讲，但这两件事的数据可得性差太多。推理还能靠延迟、价格、上下文窗口、服务行为去反推；训练端涉及预训练轮次、去重策略、checkpoint 恢复、后训练、蒸馏、地域电力结构，黑箱程度高一个数量级。过去一年很多公司把“大模型训练一次的碳排”当 headline，但真正频繁发生、总量更大的，往往是持续后训练和大规模推理。要是这篇文章最后把训练影响也做成一个看起来很整齐的排行榜，我反而会警觉：整齐不等于可信。这里需要的不是漂亮单点值，而是宽区间、明确假设、可复算链接。 所以我对这条的态度是偏正面，但不会过度抬。它补的是方法论卫生，不是测量学突破。做 ESG、采购评估、模型治理的人会需要这种“先筛一遍再深挖”的工具；做系统的人则该盯两个硬指标：误差带有多宽，校准样本有多少。没有这两个数，在线 observatory 再好看，也容易滑成信息图产品。

EvoForest 这篇先给出一个扎眼结果：它在 2025 ADIA Lab Structural Break Challenge 上用 600 步进化拿到 94.13% ROC-AUC，高于公开冠军 90.14%。我对这个方向是有兴趣的，因为它瞄准的确实是很多表格任务的老问题：难点不在最后那层拟合，而在该算什么特征、该做什么组合、该把哪些不变量写进计算图里。用共享 DAG 存可复用结构，再让 LLM 按结构化反馈去变异，这个设计比“让模型直接吐特征工程代码”更像一个系统。 但我不太买“novel paradigm”这个标题口气。正文按 arXiv 摘要能看到的核心证据，只有一个比赛分数、一套 Ridge 读出器、一个 LLM 驱动变异环。关键缺口不少：没看到和纯遗传编程、符号回归、AutoML-Zero 风格搜索、AlphaEvolve 类流程的系统对照；没看到 600 步进化用了多少 token、多少候选图、多少随机种子；也没看到把 LLM 去掉、把共享 DAG 去掉、把低维连续参数去掉之后，各自掉多少分。没有这些，你很难判断增益来自“开放式进化”，还是来自“LLM 帮你写了不少比赛特化启发式”。 我想到的直接参照物有两类。一类是更老的 genetic programming 和 symbolic regression，它们几十年都在做“搜索该算什么”，问题一直是搜索空间爆炸、评估成本太高、结果不稳。另一类是这两年被重新炒热的 LLM-for-search 路线，像 Google 去年讲 AlphaEvolve，那套叙事也是“模型提议，外部评估器打分，再闭环迭代”。EvoForest 的差别在于它把候选程序限制进共享 DAG，还塞进低维可训练参数，这比纯文本程序搜索更省评估，也更容易复用中间节点。我觉得这点是论文里最像贡献的地方。说实话，这比“又一个 agent 自动做特征工程”要硬一些。 我还有一个疑虑。ADIA 这类结构突变任务本来就偏向非平稳时间序列和制度切换检测，手工构造统计量、门控、窗口摘要，经常比大而全的深网更占便宜。EvoForest 如果在这种任务里赢 3.99 分，说明它很适合“目标不可微、样本不算大、结构先验很关键”的问题；它不自动外推到通用表格学习，更不自动外推到视觉和语言。论文摘要也没给出第二个数据集。标题已经给出“novel machine-learning paradigm”，正文至少在摘要层面没有给出跨任务证据，我会把它先看成一个有意思的搜索框架，不是范式替代。 还有个现实问题：Ridge 读出器是这套方法成立的锚点。好处是评估快，坏处是你学到的中间表示会被线性头偏置。要是换成 logistic regression、GBDT、或者小 MLP 读出，结论还稳不稳，摘要没披露。我自己也没跑过这个 challenge，所以不装懂数据细节；但只看现在这版材料，我会把关注点放在两件事：一是作者是否开源进化轨迹和消融，二是它能不能在第二个完全不同的非微分目标上复现优势。做不到这两条，这更像一篇“比赛上分方法学”，还不是一个新门类。