值得读 Agent 系统 / AI 编程 / 多模态
追踪记录 ↗
Amal Irgashev、Shreya Talegaonkar · LangChain 工具与产品 2026-10-27
技术 persistent sandbox staged rendering
设计工具很容易陷入两难:预制组件越齐全,交付越稳定,作品也越容易长得一样。LangChain 复盘内部 Content Studio 时,提到早期曾准备 115 个界面组件;模型升级后,这套帮助旧模型完成任务的安排反而限制了变化。团队于是删去大部分硬编码设计规则,留下品牌与设计原则,让模型直接作更多视觉选择。这是团队的使用观察,并非单独控制模板数量的实验。
支撑这种自由的是一个能持续修改的项目。每个 Slack 讨论线程对应独立沙箱,代码、图片和视频素材留在项目目录里,后续要求可以接着做。主 Agent 处理方向与沟通,异步子 Agent 分担有明确文件归属的制作工作;团队知识、技能说明和记忆提供背景。仓库中的检查仍负责颜色、字体、图表计算等可明确判断的要求,审美取舍则交给模型与使用者。
视频制作还有一道实际的成本约束:先看故事板,再做低成本动态草稿,最后进入昂贵渲染。模型可以探索表达方式,却不能跳过这些阶段直接反复输出成片。团队称四个月生成了三千多份素材和八十多套幻灯片,公开了实现仓库;模型、服务和工作流同期都在变化,成本下降不能全归因于删规则。
查看大图 ↗ 图片暂不可用,请查看来源。
每个讨论线程保留项目和沙箱,主 Agent 可在异步制作期间继续接收方向调整。图中的代码量下降是团队迁移后的自报,不能归因于单一改动。LangChain 原文架构图;为评述系统结构保留整图及署名,未发现单独图片许可。 · 原文图示 · 图片出处 ↗ 编辑评读
这里应当重新考虑的是规则的用途。品牌色必须一致,是作品本身的要求;“只能从这批组件拼装”,可能只是旧模型能力不足时的补救。两者都写在提示或技能里,长期维护时却不能一视同仁。若把暂时的补救当成永久规范,新模型更擅长的做法就可能没有机会出现。
这套系统也说明,自由度与制作顺序可以分别安排。故事板便宜,适合比较构思;成片昂贵,适合落实已选方向。把早期试错留在低成本阶段,能让人更愿意尝试多种表达,而不是因为每次修改都要重做成片而过早定稿。它比单纯要求模型“多创新”更具体。
目前证据来自同一团队的复盘与公开实现,没有独立设计盲评。值得借鉴的是分类和比较方法:升级模型时,挑出几条曾用于补救能力的限制,对同一批任务分别保留和撤除,检查质量、返工与多样性,再决定是否删除。涉及品牌事实、授权素材和不可逆操作的要求,不能仅因模型变强就推定失效;这一比较是建议,尚未由本刊执行。
依据 1 · 依据 2
值得读 系统与效率 / 基础模型
追踪记录 ↗
Cartesia · H-Net 研究团队 研究进展 2026-10-28
技术 H-Net byte-level modeling
多数语言模型先用固定分词器把文字变成 token,再把它们交给神经网络。常见的 BPE 会把经常相邻的字节合并成词表单元;切法预先确定,遇到陌生语言、代码或特殊格式时未必合适。Cartesia 的 H-Net 从字节出发,让网络在训练中决定分组边界。轻量外层编码细节,主网络处理压缩后的序列,随后还原到字节位置并生成输出;同样结构还能嵌套,形成更深的层级。
这次长文的重要补充是比较条件。单层实验尽量匹配内外层结构、计算量、参数与压缩率,并在同一训练语料上重新训练 BPE。团队报告,在留出验证数据上,达到相同的每字节预测损失所需训练计算约少 22%;更大的优势出现在部分分布外数据。每字节损失衡量预测文本的能力,不等于任务答对率,也不直接代表实际机器上的训练速度。
两层实验进一步与 SmolLM3 比较,在每字节计算相近时,用约一万亿 token 等量数据达到后者约十一万亿训练规模的六项任务平均成绩。不过两者参数量并不完全相等,训练阶段和后期数据混合也不同,不能把十倍左右的差距全部归于分词。文章给出了更有力的扩展线索;新版结构的完整发布与他人重建,仍是下一步要看的证据。
编辑评读
值得改变的直觉是:输入单位不一定要在训练前固定。固定词表把压缩决策交给预处理,H-Net 则让这一决策与预测目标共同学习。当数据形式变化很大时,模型有机会把计算集中在更合适的语义尺度上;代价是增加了学习边界、压缩和恢复位置的结构复杂性。
单层严格对照与两层规模实验回答不同问题。前者较接近“在这些配平条件下,学习分组是否有益”,后者展示的是一整套架构和训练方案能走到哪里。将二者分开,既能看到能力机会,也避免把规模图上的差距误读成单一机制已经被完全隔离。
对工程团队而言,最有迁移价值的追问是自己的数据在哪些地方被固定切法拖累,例如混合语言、少见代码语法或长串格式符号。应先观察这些子集,而非仅看总体平均分。当前材料尚不足以判断服务延迟、批处理效率和后端实现成本;训练计算收益只有接到实际系统测量,才会成为部署收益。
依据 1
值得读 系统与效率 / 多模态
追踪记录 ↗
NVIDIA · 语音团队 模型动态 2026-10-28
技术 ASR MoE
一段录音可以有几种都合理的文字版本:保留口头语和逐字读法,把数字写成规范形式,或者整理成去掉停顿与重复的书面语。训练和评估若混用这些目标,模型即使听懂了,也可能被算错。NVIDIA 发布的 Nemotron 3.5 Transcribe 与 Granary v2 数据流水线,把这些输出形式明确分开,支持通过指令选择转写方式。
模型总参数约 300 亿、每次激活约 40 亿,结合状态空间层、Transformer 与专家混合结构。发布说明覆盖 40 种语言转写、31 种语言翻译,并对其中 13 种提供带说话人标记的输出。它面向已有录音,不是实时流式听写模型。Granary 则把音频分段、识别、幻觉检查及不同文字目标的生成串起来;公开清单约 46.3 万小时、48 种语言,不能与流水线处理过的全部音频时长混为一谈。
配套医疗转写案例显示,术语和目标拼写可以一起适配。团队用合成语音等材料微调,在与调参说话人分开的 2764 条留出样本上,将词错误率从 22.44% 降至 12.17%;通用 LibriSpeech 指标则由 1.54% 变为 1.69%,并非处处改善。包含调参样本的另一张全量结果表不能当作独立留出成绩。本期核对了原文口径,没有复现训练,也不把未来量化版本的吞吐预告当成当前可用表现。
语境:在 Nemotron 3.5 Transcribe 发布帖中描述与 Parakeet 的比较;自报使用四比特量化,未附完整数据。 · 读取时间:2026-10-29
逐句忠实转述(非原文) 他正在测试转写,感到新模型更慢、更重、错误率更高;仍准备检查内置翻译是否值得。他主动补充,四比特量化可能影响准确率,所以这段经验只能对应其当前配置,不能直接代表全精度模型。
编辑评读
这个发布可迁移的部分,是先定义“忠实”究竟指什么。病历需要规范术语,访谈研究可能必须保留犹豫和自我修正,字幕又有可读性要求。把它们都叫准确转写,会把产品选择藏进指标。应让目标样式、训练标签与评分规则一致,再比较模型。
医疗案例中,合成数据的价值也不只是增加小时数:它让少见术语和指定书写形式更频繁出现。但若调参者与测试说话人重叠,改善会更难解释。原文另列说话人隔离结果,正是必须保留的比较边界;通用集略退步也提示专门化需要衡量取舍。
早期用户报告与发布榜单并不完全一致。有人用四比特量化版本测试后,认为更慢、更重且错误更多,同时明确量化可能影响准确度。它不能推翻全精度报告,却提出实际选型必须回答的问题:在自己的语言、设备、输出样式与量化条件下,新增翻译或说话人能力是否抵得上资源成本。建议从同一批录音的错误类型和整段耗时开始比较,而不是只转抄总榜名次。
依据 1 · 依据 2 · 依据 3
值得读 评测与基准 / 多模态
追踪记录 ↗
OpenBMB / 面壁智能 模型动态 本期发现
技术 OCR verifier
扫描文件里的困难不只有字符模糊,还包括多栏阅读顺序、公式和表格结构。MiniCPM-OCR 系列把处理分成两个角色:约 13 亿参数的解析模型负责读,约 20 亿参数的 Jev 判别模型负责判断候选结果是否与图像一致。公开权重与实现让使用者能够分别选择解析和复核路径,而不必把所有工作塞进一次大模型回答。
解析流程先用版面检测切出区域,再逐块识别,最后按顺序拼成 Markdown。Jev 则同时查看区域图、候选文本以及候选重新渲染出的图像,输出一个分数。它可以帮助挑选候选或把可疑区域送给人工,但如果所有候选都错了,判别器不会凭空补出正确答案。模型卡报告 AUROC 为 93.6;这是区分正误样本的排序指标,不能写成“93.6% 的文件保证正确”。
团队在 RTX 5090、指定加速配置下报告约每秒 1.2 页,测量覆盖 OmniDocBench v1.6 的 1651 张图,页面并发为一但区域内部可以并行,不能外推为普通手机速度。实际问题也出现在模型之外:一位用户报告,开启图片区域 OCR 后,工程图文字已经识别出来,却在 Markdown 拼装时被空图片链接替代。维护者承认该路径需要修复;本轮未核实修复已经合入,因此保留问题发生的条件。
查看大图 ↗ 图片暂不可用,请查看来源。
同一区域的两种识别候选及 Jev 分数;红绿示例涉及字符、公式和表格。示例高低分不等于任意文档的校准正确概率。OpenBMB / MiniCPM-OCR 仓库原图,项目采用 Apache-2.0 许可。 · 原文图示 · 图片出处 ↗ 语境:针对提交 50b74eba 的工程图处理;开启图片区域 OCR,描述识别与最终拼装的差别。 · 读取时间:2026-10-29
逐句忠实转述(非原文) 他报告中间识别能读出工程图中文字,最终 Markdown 却只留下空图片链接;自定义图片格式也没有按预期插入文字。他希望在保留原图时一并交付已识别内容。这是具体流水线问题报告,不是模型完全无法识别工程图。
caowanxia123 · 原帖 / 原文 语境:维护者在同一问题下回应用户;与项目作者同源。 · 读取时间:2026-10-29
逐句忠实转述(非原文) 维护者确认需要修复该路径并表示会处理。本轮读到的问题关联了后续修改入口,但没有核实修复已经合入或验证成功,因此不把回应写成问题已解决。
编辑评读
判别模型的意义,是把人工注意力从整页平均分配,转向具体可疑区域。这样的流程是否省事,取决于分数阈值下有多少错误被放过,以及多少正确结果被送去复查。AUROC 只能帮助了解排序能力,真正的业务判断还需要接受结果的错误率与人工工作量。
工程图反馈进一步说明,端到端质量不能只盯识别模型。用户已经取得正确的中间文字,最终文件仍可能丢失它;换更强模型未必解决拼装阶段的缺陷。测试时应保存区域、识别候选和最终文档之间的对应关系,才能区分“没读懂”与“读懂后没交付”。
这里也有一个可复用的设计机会:生成器与判别器可以各自升级,并允许不同解析器提供候选。不过独立组件不自动意味着独立错误;相似训练资料、渲染方式和版面困难仍可能让它们一起失败。比较方案时,应加入候选全错、表格错位和公式符号替换等样本。这是从公开机制推导的验证建议,本刊没有运行这些测试。
依据 1 · 依据 2 · 依据 3
值得读 Agent 系统 / 评测与基准
追踪记录 ↗
Surge AI · DAYJOB 团队 研究进展 2026-10-28
技术 agent evaluation professional tasks
专业工作通常不会把所有关键条件写进提问。客户给来邮件、表格和历史文件,工作者还要发现哪里互相矛盾、哪种选择会触发额外条件,再交付能使用的结果。DAYJOB Tax 用 50 个税务工作环境模拟这种情况,合计 1789 份文件,单项任务中位数为 30 份,最大达到 123 份;材料由专家构造并分层审阅,不是真实客户资料的直接公开。
评分关注完整任务是否达标。以满足至少 95% 的评分项为通过线,发布页报告 Sonnet 5.5 单次通过率 10.8%、Fable 5.1 为 9.6%、Opus 5.5 为 9.2%。这些数值不能说成“模型只懂一成税法”,也不能在没有误差分析时据此宣布几种模型优劣已经分明:少量关键遗漏就可能让整项任务不过线。
原文举例,模型比较客户给出的两个出售时间,算出了两者的结果,却漏掉另一个决定资格的未来期限;另一个例子中,不同模型又对婚姻状态作出不同程度的未经确认假设。难点是从材料中找出尚未被问到、却会改变建议的问题。评论区既有用户说模型帮忙发现人工申报错误,也有人追问测试使用了什么工具和工作流。这些经验支持辅助复核的价值,但不是该基准的复现,更不构成个人税务建议。
语境:在 DAYJOB 讨论中谈自己作为海外美国公民核对申报草稿的经验;不是参加基准的用户。 · 读取时间:2026-10-29
逐句忠实转述(非原文) 他把自己准备的草稿和支持材料交给 Claude,既发现过汇率错误,也遇到模型因缺少背景提出误报、对模糊规则给出另一种解释,以及迟迟算不准估算税额。他认为它适合辅助检查,不适合丢入所有文件后期待无需核对的成品;此处是个人经验,不提供税务结论。
语境:针对该基准的工具与系统指令披露提出疑问。 · 读取时间:2026-10-29
逐句忠实转述(非原文) 他没有很快找到完整工具和指令设置,并提出专用工作流可能先整理要求再逐项核对。他问,这究竟是在测专业系统,还是模型自行组织工作并在上下文里跟踪要求的能力;这一建议尚不是已完成的改进实验。
编辑评读
这个基准使“能算”与“知道该算什么”之间的距离更具体。即使公式调用完全正确,若遗漏资格、时间或身份前提,最终建议仍然可能不合用。对类似的合同、运营或文档工作,值得迁移的不是税务规则本身,而是先从原始材料提取会改变方案的条件,再检查条件之间是否冲突。
低通过率也需要结合任务设计读。严格整项阈值适合提醒人注意交付缺口,却隐藏了错误的大小与修复难度。遗漏一项关键信息和多数计算都错,可能同样算失败;实际辅助流程的价值还要看人需要花多少时间核对与补救。用户自述模型发现错误,和无人介入整项通过率低,可以同时成立。
关于专用工作流的质疑值得留下。若先列条件、检索当前规则、使用确定性计算器再复核,表现可能改变;但这只是待测假设,不能据此抹掉已有结果,也不能说作者已经测过最佳专业系统。下一轮有价值的比较应公开工具、系统指令与人工介入范围,在同一任务上比较最终质量和修复成本。
依据 1