逐字稿文字預覽
google正在补齐 ai 成为长期研究伙伴所需要的三种能力 ai已经能写代码读论文 也能在几秒钟内 给出一套看起来完整的研究方案 但只要把任务从十分钟拉长到十小时 问题马上就会暴露 他会忘记前面验证过什么 会沿着错误方向反复试探 会把过时信息当成当前状态 也会在遇到专业数据 时突然失去判断力 模型回答的像专家 距离真正参与研究 还有很长的路要走 仍然隔着一整套运行系统 Google最近公布的三项进展 刚好对准了这三个缺口 antigravity teamwork负责组织多个 智能体长期协作skill state试图 解决长任务里的状态失控timesfm 3.0则把基础模型推进到时间序列 预测这种专业场景三者尚未被 Google宣布为一套已经集成的产品 但它们放在一起 透露出的方向很清楚 下一轮AI竞争重点开始从 模型一次能达多聪明 转向系统能不能连续 几天做对一件复杂的事 这也是研究伙伴 四个字真正难的地方 研究工作很少靠一次灵感直接完成 一个数学证明可能要 同时探索十几条路线 硬件模拟器需要 反复编译运行和对照 企业预测还要理解变量之间的关系 人类团队会分工会质疑会记录失败 也会在关键节点换方法 单个聊天窗口没有这些机制 再长的上下文也只是把 更多材料塞给同一个决策者 teamwork先动的是组织方式 普通的多智能体系统 通常由一个主智能体拆任务 再把工作交给几个子智能体 这个办法处理资料整理 和代码分工已经够用 碰到开放研究却 很容易出现危险局面 第一个智能体提出了一个方向 后面的智能体默认它是对的 所有人开始在同一条错误路线加速 参与者越多 错误反而包装的越完整 teamwork给不同任务设置 了不同的协作模式 不能拆开的代码问题进入 反复测试和修改的循环 可以拆开的工程任务交给 多个工作单元并行完成 再由批评者检查 数学证明则同时生成多套候选策略 每套策略旁边都安排 一个专门找漏洞的角色 系统还会根据任务 进展临时增加智能体 或者改变团队结构 任务开始时判断简单 做到一半发现复杂度上升 它可以继续扩张 而不是被最初的分工锁死 这里最值得注意的功能叫long proof 开放Google数学问题 经常出现一种情况 某条路线在前10步都很漂亮 做到第50步才发现 一个无法补救的漏洞 传统智能体可能已经把 这条路线写进长上下文 之后不断受到它的影响 long proof会让多条路线并行竞争 每一条都接受反驳者的压力测试 被否定的路线不会彻底消失 其中有用的局部想法会留下 失败原因则进入共享的陷阱记录 接下来系统把选中的策略拆成 带有依赖关系的子问题 能够同时处理的部分并行推进 必须等待前置结论的 部分按照顺序执行 每个子问题内部还会展开一轮候选 批评和综合 研究过程由此从一条不断变长 的思维链变成一张可以检查回 退和重新分配资源的工作网络 Google声称 这套方法参与处理了7项数学 和理论计算机科学开放问题 涉及稀疏凸优化 子空间近似向量嵌入 量化和矩阵分解等方向 5项结果形成了公开论文 大部分结论经过人类专家审查 new cycles相关证明则 使用Lin进行形式化验证 Google还报告Gemini3.7Flash和3.1Pro 配合long proof在TCS bench上达到71% 此前报告的成绩为67.7%七 七项成果的验证方式各不相同 题目数量反而次要 nutcycles可以把证明翻译进Lin 让形式系统逐步检查逻辑是否成立 稀疏凸优化和子空间近似则 需要领域专家判断问题设定 证明边界和既有文献之间的关系 AI能够生成一份很长的证明 不代表它自动知道自己 是否遗漏了学界默认条件 不同研究对象需要不同验收工具 这也是研究系统无法只靠 一个总评分解决的原因long proof 保留失败路线还有 一个容易被低估的价值 科研里的失败通常很贵 同一条思路可能被 不同研究者重复尝试 直到很晚才发现障碍 如果系统能够记录某 个引理为何不成立 哪个边界条件造成反例 下一轮搜索就能 绕开已经确认的死路 这个能力不会直接出现在答对率里 却可能决定系统能否在 几天后继续有效工作 但失败记录也会产生新的风险 一条路线被早期反驳 不代表它在修改假设后仍然无效 一个批评智能体给出的否定 本身也可能是错的 teamwork需要保留意义 又不能让错误意义 永久封死搜索空间 他公开展示了竞争 批评和综合的框架 怎样给不同意见分配权重 怎样在后续证据出现时恢复旧路线 仍是决定系统上限的细节 这些成绩有分量 也需要正确理解 71% 是在Google内部测试中的最高层级 部分研究任务使用的并行 规模高于公众版本的默认配置 公开用户可以在付费 Antigravity计划里调用teamwork预览 但不能据此认定普通 账户会复现所有研究结果 解决7个开放问题同样不该被 简化成AI独立完成7次数学突破 题目选择 资料边界结果验收和最终 责任仍然掌握在人类专家手中 它在工程任务上的 表现更容易看清价值 Google让teamwork从头构建了一个 乱序执行的risk v周期级模拟器 这个模拟器可以启动XV6操作系统 并运行100多项标准基准 研究团队把它与 boom处理器的参考结果比较 在未见过的工作负载上 平均周期对齐误差为0.71% 为了防止系统只是在输出 一个看起来能跑的项目 开发过程加入了两阶段验证 还使用与主环境隔离的 Spike进行持续所部对照 这类任务不靠一句高质量回答取胜 一个处理器模拟器涉及取指解码 乱序调度缓存异常处理和周期精度 任何一个模块的错误都可能 在几十万条指令之后才出现 teamwork能发挥作用 靠的是让不同角色负责 实现测试质疑和众合 并把验证嵌进工作流 模型本身提供推理能力 协作机制负责把这种 能力约束在工程流程里 更有说服力的证据来自开源项目 teamwork对Eigen和Polyhash 提出了性能优化 部分改动通过正常 代码审查进入上游项目 实验报告里的漂亮数字可以 受到环境和选择方式影响 外部维护者愿意接收代码 至少说明改动不只存在于演示页面 他开始碰到真实 软件世界最麻烦的部分 旧代码兼容性测试 要求和他人的审查意见 Polyhash的结果还展示了研究 伙伴与代码助手的差别 Google报告相关改动让64线程下的 初始插入吞吐量提高约两倍 单线程整体性能提高约1.5倍 与flat hash map相比 内存还减少约25% 性能优化往往存在交换条件 一处更快可能换来另一处更慢 一种数据分布有效 也可能在另一种负载下失灵 只有通过基准代码 审查和维护者判断 优化才有机会进入真实项目 这也是teamwork模式比自动生成 整个项目更值得关注的地方 研究和工程的价值 很少由代码行数决定 系统需要提出假设 选择测量方法 识别性能瓶颈 再接受外部审查 生成代码只是其中一步 Google把成果送进现有开源社区 相当于让智能体进入一个 由人类规则历史兼容性和 公开讨论组成的环境 难度远高于在封闭 演示里让测试全部变绿 teamwork解决了谁和谁一起做的问题 长任务还有另一个隐蔽故障 智能体每执行一步 通常都会把观察结果工具 输出和中间推理追加到对话 10步以后还能管理 100步以后 上下文就会变成混合了当前 事实过期结论和失败尝试的仓库 模型每次行动之前 都要重新从这堆 文字里恢复世界状态 人类做长期项目时 不会这样工作 工程师不会每天把几个月 的聊天记录从头读一遍 再猜代码现在编译到哪一步 团队会维护任务看板 测试状态 风险清单和当前分值 历史记录可以留档 下一步决策依赖的却是 一份清楚的当前状态 把这个尝试放进智能体运行时 每一步只给模型三类信息 固定的任务规范当前结构化 状态以及环境刚刚返回的新观察 模型完成推理后提出 状态修改和下一步动作 运行时先验证修改是否合法 再写入状态 那一轮中间推理随后被丢弃 不再跟着任务无限增长 这与传统的上下文压缩有根本区别 摘要方法仍然需要把 过去重新写成一段文字 信息可能在压缩时变形 模型也要判断摘要里 哪些内容仍然有效skill state直接规定哪些 字段代表当前世界 例如安全挑战可以只 保留已经发现的标记 测试过的假设 活跃文件 当前目录和命令摘要 下一步行动读取这些字段 不必回放 全部终端输出 论文给出的复杂度变化很直接 传统追加历史的方式单次 输入会随着任务长度增长 累计TOKEN消耗可能 接近任务步数的平方 只要状态结构和最新 观察的大小受到限制 skill state每一步的提示 规模可以保持在固定范围 累计消耗随步数线性增加 任务从几十步拉到几百步时 这种差异会迅速放大 在一项100步的仓库任务里 Gemini3Flash使用普通react 方法取得84%的成功率 累计消耗约124万TOKEN skill state把成功率提高到94% 累计TOKEN约6.5万 到了200步 react成功率下降到74% skill state仍保持94% 论文在intercode CTF安全 任务上的结果也显示 skill state完成率为54.2% 它高于几种对照运行方式 同时把平均提示规模 和总token压了下来 更关键的实验是噪声测试 研究人员向任务环境加入 与状态无关的遥测信息 普通提示在噪声变多后明显恶化 因为无用信息也会一直留在历史里 skill state只把影响后续 行动的内容写进状态 所以成功率保持在接近完整水平 它展示了一条很实用的原则 长任务的可靠性不只 取决于模型能记住多少 还取决于系统敢不敢 丢掉已经没用的东西 这个方案也有明显代价 状态结构必须由人提前设计 如果某条早期信息当时看起来无关 后来才发现它很重要 而它又没有进入状态字段 这条线索可能已经丢失 需要完整审计轨迹 解释研究过程 或者回看思路变化的任务 也不能只保留当前状态 论文目前主要验证单智能体 多个智能体同时修改同一份状态时 会不会覆盖 冲突又该由谁裁决 仍然没有充分答案 论文对小模型的 失败分析进一步说明 结构化状态并不会自动带来可靠性 Gemma开放权重模型在100步 任务中只有42%的得分 68%的失败来自过早 覆盖或删除重要状态 20%属于结构和类型错误 还有12%是JSON语法问题 运行时可以拒绝格式错误的更新 却无法保证模型对什么 值得保留的判断正确 状态越短 写错一个字段造成 的影响可能越集中 承受系统因此需要 同时保存两层记录 决策层读取精简的当前状态 审计层保存完整日志 出现异常时能够追溯 前者控制成本和注意力 后者承担调查合规和复现 skilled state论文强调丢弃中间推理 适合追求执行效率 医疗金融和关键基础设施 可能要求更严格的留痕 怎样在隐私成本与可追责之间取舍 会决定它能进入哪些行业 状态结构的设计也 可能成为新的专业岗位 过去的提示工程关注 怎样把问题问清楚 长任务系统更需要 定义任务进行到哪一步 应该有哪些字段表示 供应链任务要记录订单 交付风险和库存约束 代码任务要记录分支测试和依赖 科研任务则要记录 假设证据和未解决问题 同一个模板无法覆盖所有领域 领域专家会重新进入系统设计中心 现有证据还不足以把skill state写成 teamwork已经采用的底层记忆系统 风控材料没有给出这种集成关系 它们分别击中了长期 智能体的两处故障 teamwork防止多个智能体集体 沿着错误方向自我强化 skill state防止任务 历史把当前判断淹没 未来的研究系统很可能 同时需要这两种能力 Google是否会把它们合并 仍要看后续产品和论文 第三项能力来自Timesfm 3.0 它看起来没有数学证明和 多智能体团队那么戏剧化 却可能最接近企业每天 真正要花钱解决的问题 大量现实决策建立在时间序列上 零售商要预测下周每家门店的销量 电网要估计明天每小时的负荷 云平台要提前分配容量 工厂要判断设备何时可能异常 语言模型擅长处理文字 时间序列要求模型理解趋势 周期突变变量联动和外部条件 一个预测错几个百分点 可能对应库存积压 能源浪费或者服务中断 传统做法往往给不同业务单独建模 某个商品用一套模型 另一个地区重新调参数 遇到节假日促销和 天气还要增加外生变量 这个流程需要数据 科学团队长期维护 模型迁移到新场景时也容易失效 时间序列基础模型 希望学习更通用的规律 用一个预训练模型 直接处理大量陌生任务 TIMESFM3.0大约有3亿参数 支持单变量和多变量预测 也能接收协变量 所谓多变量 是让模型同时理解 几个彼此影响的序列 例如价格销量库存和客流 协变量则可以分成两类 一类只有过去数据 另一类在未来已经知道 比如节假日安排电价 计划或者促销日程 这些信息进入预测后 模型才能区分正常 季节变化和真正异常 它采用Stack mixing Transformer架构 引入varied attention处理 不同变量之间的关系 归一化机制则用来减少 不同序列尺度带来的干扰 训练材料包括去除评测 重叠后的时间序列数据 也纳入截至2023年11月的 Wikipedia页面访问量 截至2022年底的Google Trends热门查询 合成数据和增强数据同样进入训练 这些细节说明 所谓通用预测能力依然 建立在大规模多来源序列上 时间序列模型最怕数据泄露 训练集如果包含评测其信息 或者同一序列的片段 同时进入训练和测试 排名会显得异常漂亮 Google特别说明 gift Evals训练数据排除了 与Fbench重叠的数据集 目的就是降低这种问题 即便如此 三个基准第一仍然属于发布方报告 企业部署前还要在自己的 时间跨度异常条件和业务 损失函数上重新验证 预测准确率也不能 单独决定业务价值 库存系统更关心缺货和 积压哪一种错误代价更高 电网预测必须关注极端峰值 金融公开则可能在意尾部事件 一个模型平均误差更低 未必在最昂贵的错误上表现更好 Timesfm提供分位数预测 让使用者看到不同可能区间 这比只交付一个单 点数字更适合决策 但最后仍需业务规则解释风险 Google列出了Fbench time Benchmark 和JIFF Evals三个主要 时间序列基础模型评测 并称TIMESFM3.0均排名第一 Fbench包含100项多样化现实预测任务 timebenchmark覆盖50个领域 数据集和98项评估任务 这个结果说明基础模型路线正在从 文本图像继续向企业数字世界扩张 timesfm的商业价值不止 来自一次预测精度
本次執行流程與問題處理
下達指令
預期流程
- 採用來源字幕（略過語音辨識）
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
1. 下載與語音辨識
工具：videonote-transcribe-url（主辨識管線：下載、Whisper 辨識與選稿）
處理：下載音訊、以 Whisper 辨識並選出最佳逐字稿
產出：yt_dlp_meta.json（影片元資料）、audio_16k_mono.wav（16kHz 單聲道音訊）、transcript.whisper.json（Whisper 辨識結果）、transcript.json（正式逐字稿）、transcript_selection_report.json（來源選擇報告）
耗時：3.2 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：51.1 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.2 秒
關係：依序執行
結果：完成
4. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.2 秒
關係：依序執行
結果：完成
5. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.3 秒
關係：依序執行
結果：完成
6. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.3 秒
關係：依序執行
結果：完成
7. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：0.3 秒
關係：依序執行
結果：完成
8. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：161.5 秒
關係：依序執行
結果：完成
9. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：0.6 秒
關係：依序執行
結果：完成
10. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：0.6 秒
關係：依序執行
結果：完成
手動來源字幕
自動來源字幕
Whisper 字幕
- 尚未產生
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
- 校正前 transcript.source.json 純文字 JSON
- 校正後 transcript.json 純文字 JSON
目前待解決問題與初步改善方向
- 逐字稿全文快速校讀未完成
已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。；RAPID_REVIEW_STATUS=REVIEW_REQUIRED_INVALID_OUTPUT
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。
- 音訊下載不穩定，需更新 cookies / PO token 後重試精進模式。