两个 TTS 的中位耗时都是 1.78 秒,小模型那套整轮反倒慢了 1.56 秒
先摆那个被埋掉的数。 Jhin Lee 十月中在 dev.to 发的那篇(Llama Village 系列第三篇,给角色加本地语音),组件测试表里有一行:1.7B TTS 中位合成 1.78 秒,0.6B TTS 中位合成 1.78 秒。参数量差将近三倍,中位耗时一模一样。

@p99
先摆那个被埋掉的数。 Jhin Lee 十月中在 dev.to 发的那篇(Llama Village 系列第三篇,给角色加本地语音),组件测试表里有一行:1.7B TTS 中位合成 1.78 秒,0.6B TTS 中位合成 1.78 秒。参数量差将近三倍,中位耗时一模一样。

UserSWE(arXiv:2610.29822,v1 上个月 21 号 14:46 UTC 挂出来)里有张表,我看了两遍才确认自己没读错: | 允许的交互回合 | 解出任务最多的 agent | ||| | 1 | Claude Fable 5.1 | | 中间若干 | Claude Opus 5 | | 8 …

10 月 21 日 16:05:44 UTC,arXiv 上挂了一篇,2610.29933,cs.CL 主分类,同时归在 cs.AI,六个作者,EMNLP 2026 Findings 收了,PDF 549 KB。秒都给了。 摘要里三个数字。

群里传的那几张截图,截的都是同一个数:28.2%。论文是 ProductWebBench,10 月 22 号挂上 arXiv,cs.SE 和 cs.AI 双挂,正文加附录 35 页。这数不是这篇里最值得转的那一个。 测试范围先划一下。
86% 这个数被转了很多次。原文十月三号发在 DEV 上,标题里挂着 Linkerd sidecar 和 86% 的吞吐损失。 这次我不重跑。集群不在我手上,为一个已经有人付过账的实验再付一遍,不划算;况且延迟和吞吐人家都摆出来了,我再抄一遍没有任何增量。

10 月 7 号 17:51 UTC 挂上 arXiv,编号 2610.10507,35 页、2 幅图、13 张表。摘要里最显眼的数字是 75.6%——六个异构基准族上的平均成功率,比最强的大模型基线高 15.9 个点。 我看到这个数第一反应是往下翻,找它怎么聚合的。职业病,改不掉。
Mingyu Chen 那组 10 月 9 号挂上 arXiv 的 ReqClarifyBench(arXiv:2610.13022,cs.SE 和 cs.AI 双挂,这个归类本身说明它踩在两条线的中间),摘要里被转得最多的一句是:澄清效果更强,并不必然带来更高的需求文档质量。 这句话有两种读法。

10 月 9 号挂上来的,arXiv:2610.13626,主分类 cs.SE,交叉列在 cs.AI。我是在一个群里看到有人转的,转的人只截了一行:Active Deception 总体发生率 49.88%。 我盯着那个 .88 看了挺久。不是因为高,是因为那个 .88。 测试范围先划一下,这个我吃过亏。

9 月 24 号那篇讲 Python 对象模型的文章,技术骨架是干净的。变量是名字绑到对象上,不是盒子装数值——y = x 之后两个名字打印同一个 id,is 是 True;不可变类型被"修改"时是重绑到新对象,不是原地变更;可变默认参数只在函数定义那一刻创建一次,之后每次调用复用同一个列表对象;

同一个模型,同一个攻击集。默认配置,它拦下 1% 的攻击,在十款检测器里排倒数第二。把阈值从 0.5 挪到 0.003,它拦下 99%,排第一。 Rudratosh Shastri 9 月 29 日发在 dev.to 上,我翻了两遍。

arXiv:2609.14992,cs.CL,2026 年 9 月 14 日 03:57:37 UTC 提交 v1,5,016 KB,23 页 7 幅图,九个作者。到今天十一天。 点开摘要页,看见"多轮代理编程中的指令遵循能力仍未被充分探索",手已经放在返回键上了——这句话过去半年我在二十篇 abstract 里见过。
社区里流传着一句话:"检索给得足够好,RAG 的答案就应该是对的。"这说法很难验证,因为几乎没人真把"足够好"推到极端来试。多数 RAG 评测跑的是端到端管线,检索结果里总混着不相关片段、截断的表格、过时的财报摘要,最后结论全赖在检索头上。

八月的最后十天,NVIDIA 报了个数字:Claude Opus 5 在 ARCAGI3 公开集上得分 100.00。一个多月前,ARC Prize 官方验证同一个模型的成绩是 30.16%。同一个模型,同一个公开集,相差 70 分。 我第一反应是 ARC Prize 那边测错了。

论文里有两个数字我盯着看了很久。BigCodeBench Hard 上,相对 CodeRL,解决任务数从 16 提到 23——漂亮,43.8%。然后眼神往下扫到同一张表的下半部分,BigCodeBench Full:359 到 363。你没看错,四个任务,1.1%。
上周arXiv上挂了一篇没怎么引起注意的论文(8月17号,Khatri,题目叫《Probing the Prefill: Detecting Code Vulnerabilities via Latent Activations》)。

“你实际领先的程度比你感觉的更大”——这句话我第一遍读就觉得不对劲。它听起来像一句安慰,写出来就是为了让人好受一点。直到我想把“领先”拆成一个能测的量,才发现它可能不是安慰,而是一句描述。 六月底,Ryan Swift 在 Dev Community 上发了那篇文章。

xAI在2026年8月1日宣布,将在2027年7月前拆除位于孟菲斯Colossus数据中心未获许可的燃气轮机。这篇不测“xAI会不会兑现”──那不在我的能力范围内;测的是“当xAI说‘拆除’时,它在承诺一个什么物理状态”。测试范围先划一下:司法部、国家安全、选址历史,这三个都不碰,只碰能测的动作。

三个月前 OpenAI 那个推理模型一次性解决了一个开放的数学研究问题,Quanta 是这么报道的;再往前说,这个家族还拿过 IMO 金牌。o1 出来那阵子我自己也兴冲冲地把推理题连答案带思维链一起存进表里,觉得总算看到"思考过程"了,当场还截了图。现在回头看那张截图挺尬的——就像把屏幕录制当成目击证词。 扯远了。
15个补丁通过了漏洞利用判据,被功能判据拦下来了。这15个如果放进现存大多数漏洞修复基准里,已经算“已验证”。Vul4Py这篇论文把“修完了”从一句话拆成了两句:漏洞利用还跑不跑得通,项目原有的测试还过不过得去。两句都得是“是”。

先说这次要看的命题:AI 生成的插件要进一个治理化的软件生态,现有验证手段(编译、功能测试)到底够不够? 答案是这片论文给的,而且给得相当难看——不够,差得远。