LLM学会用反例辅助数学推理
LLM学会用反例辅助数学推理
技术上有个思路我觉得挺巧。他们没去硬找现成的数据，因为现有的 CounterMath 数据集只有 1,216 道题，根本不够喂给模型。他们搞了个“符号变异策略”，逻辑很简单：既然证明题很多，那就把那些本来能证明对的定理，人为地把它的假设条件删掉一部分。这样一来，定理不成立了，自然就需要反例来推翻它。通过这种“破坏”的方式，他们合成了一大堆带反例的题目，把数据量撑起来了。
另外，他们还设计了一个多奖励引导训练的框架。以前模型做不出来题，奖励信号就是 0，训练很难进行。他们把奖励拆解了，哪怕模型没完全搞定，只要在中间步骤（比如证明被丢弃的假设）表现好，也能拿到分数。实验结果显示，这种“找茬”训练不仅让模型生成反例的能力变强了，顺带把定理证明的性能也带上去了。这说明让模型学会“证伪”，确实能反过来帮它理解逻辑，比单纯死磕证明要管用。
LeWorldModel：首个端到端联合嵌入预测架构实现稳定世界模型
LeWorldModel，Yann LeCun 团队的新工作。这是个端到端的世界模型，不用预训练，也不用那些花里胡哨的“停止梯度”或者“指数移动平均”等黑科技，居然也能训练得很稳。
以前搞这种 Joint Embedding Predictive Architectures (JEPAs)，最头疼的就是“表征坍塌”，模型容易偷懒。为了防这个，大家通常得加一堆 Loss 项，或者干脆冻结 Encoder。这篇论文的思路我觉得挺巧，他们把 Loss 项从以前的 6 个超参数 砍到了 1 个。核心就是用了一个叫 SIGReg 的正则化项，强迫隐变量分布接近高斯分布，以此来保证特征多样性。
效果上确实有点东西。模型只有 15M 参数，在单张 GPU 上跑，规划速度比那些基于 Foundation Model 的世界模型快了 48 倍。虽然体量小，但在 2D 和 3D 的控制任务上，性能跟那些大模型打平。
更有意思的是他们做了一组物理测试。他们发现这个模型的隐空间里，居然自动编码了物理量（比如速度、位置），而且能识别出“违反物理常识”的异常情况。这说明它不光是记住了画面，而是真的学到了点物理世界的规律。对于想搞轻量级具身智能或者离线强化学习的朋友来说，这个方案确实值得一看。
MoE模型推理提速：预测专家策略减少内存占用
MoE（混合专家）模型显存不够用时推理会卡，这篇论文给了个实在的解法。
咱们都知道，MoE 虽然参数大，但算起来快，因为每个 Token 只过几个专家。但问题是，如果你的显存装不下所有专家，就得把专家放在 CPU 内存里，用的时候再搬到 GPU。这就像炒菜时发现酱油在隔壁邻居家，每次都要跑去拿，大部分时间都浪费在路上了。论文里有个数据很直观：在 Qwen3-30B-A3B 模型上，CPU-GPU 传输占了 84-88% 的时间，真正的计算反而没多少。
这帮人想了个挺巧的招，叫“专家预取”。既然算第 $L$ 层的时候必须等数据，不如顺便预测一下第 $L+1$ 层大概需要哪几个专家，趁着 GPU 在算第 $L$ 层的空档，提前把下一层的专家从 CPU 搬过来。他们发现，用当前层的“准隐藏状态”去猜下一层的路由，准确率还挺高。
更有意思的是，他们还搞了“投机执行”。要是预取的专家猜错了怎么办？通常这就得重来，但他们发现直接用猜错的专家算下去，对下游任务的精度影响微乎其微。这就省去了验证和回滚的开销。
实测下来，这套方案能带来 5% 到 14% 的 TPOT（每个输出 Token 的时间）降低。说实话，对于这种 I/O 密集型的场景，能压榨出 14% 的提速挺不容易的。代码已经开源了，如果你也在用显存跑大 MoE，可以试试他们的 YALIS 引擎。
Durable：6名工程师支撑3百万客户，日处理11亿tokens
Durable，做 AI 商业建站服务的。他们现在的体量是 6 个工程师支撑 300 万客户，每天要处理 11 亿个 tokens，一年下来是 3600 亿。
说实话，看到这个“人效比”我第一反应是怀疑，但看完细节觉得他们的技术选型确实有点东西。
最让我有共鸣的是他们关于“造轮子”的抉择。他们 CPTO Osama Khan 说得很直白：团队太小，根本没精力去搞多区域集群维护、SSL 证书管理这些破事。他们算了一笔账，如果自建，光是 SSL 终止这一项，为了支持海量客户的自定义域名，成本就得几千美元。更别提多租户环境下的安全隔离和 DDoS 防护了，这哪是做产品，简直是在做云厂商。
所以他们直接把底层全甩给了 Vercel，自己只专注做业务。这招确实省心，把 3-4 倍的基础设施成本 给降下来了。
在 AI 这块，他们的架构思路也挺务实。因为做的是多租户 SaaS，最怕的就是“上下文泄露”，A 公司的生意绝不能跑到 B 公司的流程里。他们没去搞什么复杂的模型微调，而是把重点放在了编排和隔离上。通过这种“模型编排”层，他们能随时切换模型供应商来优化成本和可靠性，而且能精确到每一个客户的 AI 花费。
这种“小团队干大事”的案例，核心不在于他们用了什么黑科技，而在于极度克制。每个工程师能产生 10 倍的杠杆效应，靠的不是加班，而是把所有非核心的脏活累活都外包出去了。
Vercel推出无需向量的知识代理方案
Vercel 开源了一个Knowledge Agent Template，核心思路是完全抛弃向量数据库，改用文件系统和 Bash 命令来做知识检索。
咱们做 RAG 的都知道，现在的标准动作是切分、向量化、存 Pinecone 或 Milvus。但 Vercel 觉得这事儿太复杂且不可控。他们发现，与其教模型理解新的向量空间，不如直接让它干它最擅长的事：读文件、跑 grep、找目录。
这方案技术上其实挺简单粗暴：把你的 GitHub 仓库、文档或者 YouTube 字幕存到 Postgres 里，然后通过 Vercel Workflow 同步到一个快照里。当有提问时，模型会在一个隔离的 Vercel Sandbox里直接执行 grep -r "pricing" docs/ 这种命令。
他们拿销售电话总结的 Agent 做了 A/B 测试，数据挺能打：成本从每次约 $1.00 降到了 $0.25，而且输出质量还变好了。
我觉得这思路最巧的地方在于可调试性。以前用向量，模型答错了，你只能看到它取了相似度 0.82 的那个块，至于为什么是 0.82 而不是 0.79，基本靠猜。现在用文件系统，你直接看 Trace 就知道它刚才是不是 cat 错文件了，或者是 grep 的范围写窄了。这根本不是在调参数，就是在修 Bug。
对于那种需要精确数值的结构化数据（比如定价、API 参数），这种确定性的检索方式确实比语义相似度更靠谱。不过这方案对模型的指令遵循能力要求高，要是模型连 Linux 命令都写不利索，这架构就跑不起来。
代理编程评估中基础设施噪声量化研究
大家平时看 SWE-bench 或者 Terminal-Bench 这种榜单，总觉得排在前面的模型比后面的强那么几个百分点，这差距似乎很精确。但这篇文章直接泼了盆冷水：基础设施配置带来的波动，就能达到 6 个百分点，这比榜单上头部模型之间的分差还要大。
这事儿其实挺有意思。以前跑静态代码生成，环境就是个摆设。现在跑 Agent，模型要自己写程序、装依赖、跑测试，运行环境直接变成了解题过程的一部分。Anthropic 在 Terminal-Bench 2.0 上做实验，把资源配额从严格限制（1x）一直加到无上限。结果发现，只要给足资源（超过 3x），成功率能直接拉升 6 个百分点（p < 0.01）。
这里面的门道在于“容错”。他们一开始用 Kubernetes 严格限制资源，把 CPU 和内存设成既保底又封顶的硬限制，结果 6% 的任务因为容器被 OOM（内存溢出）杀掉而失败。后来发现，官方榜单用的沙箱其实比较“宽容”，允许瞬时超配，这就导致大家其实不在同一条起跑线上。
更有意思的是数据的边际效应。在 1x 到 3x 这个区间，提升资源主要是减少了 Infra Error（基础设施错误），从 5.8% 降到了 2.1%，但这还没真正帮模型“解题”。一旦超过 3x，模型就开始玩“花活”了——成功率比错误率下降得还快。这时候模型敢拉巨大的依赖包、跑很重的子进程，比如那个 rstan-to-pystan 任务，给足了内存才能跑通。
说白了，现在的榜单如果不把资源配额写清楚，分数其实有点虚。限制严了，是在考模型写“穷游”代码的能力；限制宽了，是在考模型“挥霍”资源解题的能力。这两个方向都对，但混在一起打分，确实容易让人误读。
Replit发布Agent 4，AI自动解决90%合并冲突
Replit 发布了 Agent 4，宣称 AI 能自动解决 90% 的代码合并冲突，这事儿听着挺玄乎，但看了一下技术细节，确实有点东西。
以前多 Agent 并行干活最怕什么？怕它们同时改同一个文件，最后打架。Peter 他们的工程师团队这次是硬啃了这块骨头。现在的逻辑是，Agent 4 会先推理任务顺序，比如先做登录系统再做管理后台，确定好依赖关系后，能并行的就并行。一旦遇到冲突，模型会像人类工程师那样去理解意图并解决。90% 的情况它能自己搞定，剩下那 10% 的疑难杂症才扔给人来定夺。说实话，这个 90% 的成功率如果是真实生产环境的数据，那相当夸张，毕竟代码冲突这玩意儿有时候连人都得琢磨半天。
另外，Adi 提到的那个微虚拟机技术我觉得挺巧妙。为了让你感觉不到 Git 的复杂，他们每次开新任务都在云端秒级拉起一个隔离环境。Agent 在那个副本里瞎折腾，搞定了再合回来。这种“秒级”启动的隔离环境，配合上不按人头收费的协作模式，对那种拉个外部专家来临时救火的小团队很友好。
CEO Amjad 最后举了个例子，说有家公司用这玩意儿自动化搞营销任务，一年省了 100 万美元。虽然这种 Case Study 的数字通常得打个折看，但方向很明确：他们想把这个工具从“写代码的 IDE”变成“从 idea 到 shipped product”的流水线。
新理论解释Grokking延迟：表征相变的关键机制
关于 Grokking 现象的一篇论文——就是模型明明早就把训练集背得滚瓜烂熟了，但就是不泛化，非得再练上几千步，突然一下“顿悟”了。以前大家觉得这事儿挺玄学，这篇论文直接把它给数学化了，提出了个 “范数分离延迟定律”。
这帮作者做了一件挺巧的事儿，他们没去纠结具体的神经元怎么连接，而是从动力学的角度去看。他们发现，所谓的“顿悟”，其实就是模型在优化器的驱动下，试图从一个高范数的“记忆解”逃出来，滑向一个低范数的“结构解”的过程。
最让我觉得有意思的是他们推导出的那个延迟公式，结论非常反直觉但又在情理之中：延迟时间跟权重的范数比值的对数成正比。也就是说，如果那个死记硬背的解权重特别大，模型想爬出来就得花更久的时间。而且他们还量化了优化器的影响，比如 AdamW 的有效收缩率比 SGD 大，所以 AdamW 能 Grokking，SGD 在同样参数下可能就完全不行。
为了验证这个理论，他们跑了 293 次实验，涵盖了模加法、模乘法甚至稀疏奇偶性任务。数据显示，这个预测的准确度极高，R² > 0.97。这基本上就给 Grokking 盖棺定论了：它不是什么魔法，就是正则化训练下的一种必然的物理过程。以后谁再跟你扯“机器产生了意识”，直接把这个公式甩他脸上。