WEBVTT
Kind: captions
Language: zh

00:00:00.000 --> 00:00:01.040
google正在补齐

00:00:01.040 --> 00:00:01.700
ai

00:00:01.700 --> 00:00:05.140
成为长期研究伙伴所需要的三种能力

00:00:05.240 --> 00:00:07.800
ai已经能写代码读论文

00:00:07.800 --> 00:00:09.040
也能在几秒钟内

00:00:09.040 --> 00:00:11.640
给出一套看起来完整的研究方案

00:00:11.640 --> 00:00:15.040
但只要把任务从十分钟拉长到十小时

00:00:15.100 --> 00:00:16.780
问题马上就会暴露

00:00:16.780 --> 00:00:19.240
他会忘记前面验证过什么

00:00:19.400 --> 00:00:21.740
会沿着错误方向反复试探

00:00:21.940 --> 00:00:24.600
会把过时信息当成当前状态

00:00:24.780 --> 00:00:26.300
也会在遇到专业数据

00:00:26.300 --> 00:00:28.280
时突然失去判断力

00:00:28.500 --> 00:00:30.300
模型回答的像专家

00:00:30.500 --> 00:00:31.940
距离真正参与研究

00:00:31.940 --> 00:00:32.800
还有很长的路要走

00:00:32.800 --> 00:00:34.980
仍然隔着一整套运行系统

00:00:35.200 --> 00:00:37.340
Google最近公布的三项进展

00:00:37.580 --> 00:00:39.500
刚好对准了这三个缺口

00:00:40.140 --> 00:00:42.740
antigravity teamwork负责组织多个

00:00:42.740 --> 00:00:45.940
智能体长期协作skill state试图

00:00:45.940 --> 00:00:48.980
解决长任务里的状态失控timesfm

00:00:48.980 --> 00:00:52.540
3.0则把基础模型推进到时间序列

00:00:52.540 --> 00:00:55.500
预测这种专业场景三者尚未被

00:00:55.500 --> 00:00:58.380
Google宣布为一套已经集成的产品

00:00:58.680 --> 00:01:00.080
但它们放在一起

00:01:00.200 --> 00:01:02.080
透露出的方向很清楚

00:01:02.200 --> 00:01:05.480
下一轮AI竞争重点开始从

00:01:05.480 --> 00:01:07.300
模型一次能达多聪明

00:01:07.880 --> 00:01:09.480
转向系统能不能连续

00:01:09.480 --> 00:01:11.500
几天做对一件复杂的事

00:01:11.600 --> 00:01:12.900
这也是研究伙伴

00:01:12.900 --> 00:01:14.740
四个字真正难的地方

00:01:15.140 --> 00:01:18.180
研究工作很少靠一次灵感直接完成

00:01:18.340 --> 00:01:19.800
一个数学证明可能要

00:01:19.800 --> 00:01:21.700
同时探索十几条路线

00:01:22.200 --> 00:01:23.480
硬件模拟器需要

00:01:23.480 --> 00:01:25.740
反复编译运行和对照

00:01:26.180 --> 00:01:29.080
企业预测还要理解变量之间的关系

00:01:29.200 --> 00:01:33.100
人类团队会分工会质疑会记录失败

00:01:33.280 --> 00:01:35.380
也会在关键节点换方法

00:01:35.480 --> 00:01:37.500
单个聊天窗口没有这些机制

00:01:38.080 --> 00:01:39.900
再长的上下文也只是把

00:01:39.900 --> 00:01:42.180
更多材料塞给同一个决策者

00:01:42.400 --> 00:01:44.980
teamwork先动的是组织方式

00:01:45.200 --> 00:01:47.140
普通的多智能体系统

00:01:47.280 --> 00:01:49.680
通常由一个主智能体拆任务

00:01:49.800 --> 00:01:52.200
再把工作交给几个子智能体

00:01:52.380 --> 00:01:54.140
这个办法处理资料整理

00:01:54.140 --> 00:01:55.980
和代码分工已经够用

00:01:56.380 --> 00:01:57.600
碰到开放研究却

00:01:57.600 --> 00:01:59.300
很容易出现危险局面

00:01:59.400 --> 00:02:01.380
第一个智能体提出了一个方向

00:02:01.480 --> 00:02:03.780
后面的智能体默认它是对的

00:02:04.380 --> 00:02:07.000
所有人开始在同一条错误路线加速

00:02:07.600 --> 00:02:08.700
参与者越多

00:02:08.700 --> 00:02:10.540
错误反而包装的越完整

00:02:10.780 --> 00:02:12.480
teamwork给不同任务设置

00:02:12.480 --> 00:02:13.940
了不同的协作模式

00:02:14.480 --> 00:02:16.380
不能拆开的代码问题进入

00:02:16.380 --> 00:02:18.400
反复测试和修改的循环

00:02:18.600 --> 00:02:20.580
可以拆开的工程任务交给

00:02:20.580 --> 00:02:22.740
多个工作单元并行完成

00:02:23.140 --> 00:02:24.700
再由批评者检查

00:02:24.880 --> 00:02:27.700
数学证明则同时生成多套候选策略

00:02:27.940 --> 00:02:29.480
每套策略旁边都安排

00:02:29.480 --> 00:02:31.300
一个专门找漏洞的角色

00:02:31.600 --> 00:02:32.940
系统还会根据任务

00:02:32.940 --> 00:02:35.080
进展临时增加智能体

00:02:35.080 --> 00:02:36.800
或者改变团队结构

00:02:36.980 --> 00:02:38.880
任务开始时判断简单

00:02:38.940 --> 00:02:41.140
做到一半发现复杂度上升

00:02:41.540 --> 00:02:42.800
它可以继续扩张

00:02:43.100 --> 00:02:45.200
而不是被最初的分工锁死

00:02:45.300 --> 00:02:48.000
这里最值得注意的功能叫long proof

00:02:48.540 --> 00:02:49.700
开放Google数学问题

00:02:49.700 --> 00:02:51.280
经常出现一种情况

00:02:51.500 --> 00:02:54.180
某条路线在前10步都很漂亮

00:02:54.300 --> 00:02:56.000
做到第50步才发现

00:02:56.000 --> 00:02:57.600
一个无法补救的漏洞

00:02:57.980 --> 00:02:59.300
传统智能体可能已经把

00:02:59.300 --> 00:03:01.480
这条路线写进长上下文

00:03:01.600 --> 00:03:03.400
之后不断受到它的影响

00:03:03.700 --> 00:03:06.700
long proof会让多条路线并行竞争

00:03:06.940 --> 00:03:09.380
每一条都接受反驳者的压力测试

00:03:09.580 --> 00:03:12.000
被否定的路线不会彻底消失

00:03:12.400 --> 00:03:14.780
其中有用的局部想法会留下

00:03:14.940 --> 00:03:18.100
失败原因则进入共享的陷阱记录

00:03:18.280 --> 00:03:21.100
接下来系统把选中的策略拆成

00:03:21.100 --> 00:03:23.080
带有依赖关系的子问题

00:03:23.180 --> 00:03:25.940
能够同时处理的部分并行推进

00:03:26.000 --> 00:03:27.740
必须等待前置结论的

00:03:27.740 --> 00:03:29.540
部分按照顺序执行

00:03:29.600 --> 00:03:32.180
每个子问题内部还会展开一轮候选

00:03:32.400 --> 00:03:33.480
批评和综合

00:03:33.700 --> 00:03:36.500
研究过程由此从一条不断变长

00:03:36.500 --> 00:03:40.080
的思维链变成一张可以检查回

00:03:40.080 --> 00:03:43.200
退和重新分配资源的工作网络

00:03:43.380 --> 00:03:44.380
Google声称

00:03:44.780 --> 00:03:47.140
这套方法参与处理了7项数学

00:03:47.140 --> 00:03:49.600
和理论计算机科学开放问题

00:03:49.980 --> 00:03:51.580
涉及稀疏凸优化

00:03:51.900 --> 00:03:54.280
子空间近似向量嵌入

00:03:54.340 --> 00:03:56.480
量化和矩阵分解等方向

00:03:56.580 --> 00:03:58.980
5项结果形成了公开论文

00:03:59.080 --> 00:04:01.740
大部分结论经过人类专家审查

00:04:01.980 --> 00:04:04.100
new cycles相关证明则

00:04:04.100 --> 00:04:06.380
使用Lin进行形式化验证

00:04:06.780 --> 00:04:10.380
Google还报告Gemini3.7Flash和3.1Pro

00:04:10.380 --> 00:04:14.740
配合long proof在TCS bench上达到71%

00:04:14.800 --> 00:04:18.000
此前报告的成绩为67.7%七

00:04:18.000 --> 00:04:20.580
七项成果的验证方式各不相同

00:04:20.900 --> 00:04:22.900
题目数量反而次要

00:04:23.680 --> 00:04:26.480
nutcycles可以把证明翻译进Lin

00:04:26.800 --> 00:04:30.000
让形式系统逐步检查逻辑是否成立

00:04:30.340 --> 00:04:33.680
稀疏凸优化和子空间近似则

00:04:33.680 --> 00:04:36.200
需要领域专家判断问题设定

00:04:36.680 --> 00:04:39.580
证明边界和既有文献之间的关系

00:04:39.900 --> 00:04:42.300
AI能够生成一份很长的证明

00:04:42.300 --> 00:04:43.980
不代表它自动知道自己

00:04:43.980 --> 00:04:46.200
是否遗漏了学界默认条件

00:04:46.800 --> 00:04:49.500
不同研究对象需要不同验收工具

00:04:50.000 --> 00:04:52.140
这也是研究系统无法只靠

00:04:52.140 --> 00:04:54.940
一个总评分解决的原因long proof

00:04:55.580 --> 00:04:57.200
保留失败路线还有

00:04:57.200 --> 00:04:58.940
一个容易被低估的价值

00:04:59.080 --> 00:05:01.280
科研里的失败通常很贵

00:05:01.500 --> 00:05:03.080
同一条思路可能被

00:05:03.080 --> 00:05:04.980
不同研究者重复尝试

00:05:05.280 --> 00:05:07.180
直到很晚才发现障碍

00:05:07.680 --> 00:05:08.900
如果系统能够记录某

00:05:08.900 --> 00:05:10.600
个引理为何不成立

00:05:10.740 --> 00:05:12.780
哪个边界条件造成反例

00:05:12.940 --> 00:05:14.380
下一轮搜索就能

00:05:14.380 --> 00:05:16.180
绕开已经确认的死路

00:05:16.200 --> 00:05:19.140
这个能力不会直接出现在答对率里

00:05:19.500 --> 00:05:21.280
却可能决定系统能否在

00:05:21.280 --> 00:05:23.340
几天后继续有效工作

00:05:23.400 --> 00:05:26.000
但失败记录也会产生新的风险

00:05:26.140 --> 00:05:28.080
一条路线被早期反驳

00:05:28.280 --> 00:05:31.140
不代表它在修改假设后仍然无效

00:05:31.280 --> 00:05:33.900
一个批评智能体给出的否定

00:05:34.000 --> 00:05:35.700
本身也可能是错的

00:05:36.000 --> 00:05:37.700
teamwork需要保留意义

00:05:37.800 --> 00:05:39.300
又不能让错误意义

00:05:39.300 --> 00:05:41.180
永久封死搜索空间

00:05:41.300 --> 00:05:42.980
他公开展示了竞争

00:05:43.100 --> 00:05:44.680
批评和综合的框架

00:05:44.900 --> 00:05:46.980
怎样给不同意见分配权重

00:05:47.100 --> 00:05:50.080
怎样在后续证据出现时恢复旧路线

00:05:50.140 --> 00:05:52.380
仍是决定系统上限的细节

00:05:52.540 --> 00:05:53.980
这些成绩有分量

00:05:53.980 --> 00:05:55.540
也需要正确理解

00:05:55.980 --> 00:05:59.600
71% 是在Google内部测试中的最高层级

00:05:59.940 --> 00:06:02.000
部分研究任务使用的并行

00:06:02.000 --> 00:06:04.600
规模高于公众版本的默认配置

00:06:04.800 --> 00:06:06.340
公开用户可以在付费

00:06:06.340 --> 00:06:09.100
Antigravity计划里调用teamwork预览

00:06:09.540 --> 00:06:11.380
但不能据此认定普通

00:06:11.380 --> 00:06:13.680
账户会复现所有研究结果

00:06:13.900 --> 00:06:16.400
解决7个开放问题同样不该被

00:06:16.400 --> 00:06:19.740
简化成AI独立完成7次数学突破

00:06:19.800 --> 00:06:20.780
题目选择

00:06:21.200 --> 00:06:24.180
资料边界结果验收和最终

00:06:24.180 --> 00:06:26.980
责任仍然掌握在人类专家手中

00:06:27.080 --> 00:06:28.280
它在工程任务上的

00:06:28.280 --> 00:06:30.180
表现更容易看清价值

00:06:30.540 --> 00:06:33.000
Google让teamwork从头构建了一个

00:06:33.000 --> 00:06:35.980
乱序执行的risk v周期级模拟器

00:06:36.140 --> 00:06:39.280
这个模拟器可以启动XV6操作系统

00:06:39.580 --> 00:06:42.100
并运行100多项标准基准

00:06:42.280 --> 00:06:43.680
研究团队把它与

00:06:43.680 --> 00:06:45.940
boom处理器的参考结果比较

00:06:46.200 --> 00:06:48.480
在未见过的工作负载上

00:06:48.500 --> 00:06:51.940
平均周期对齐误差为0.71%

00:06:51.940 --> 00:06:53.900
为了防止系统只是在输出

00:06:53.900 --> 00:06:56.100
一个看起来能跑的项目

00:06:56.300 --> 00:06:58.740
开发过程加入了两阶段验证

00:06:59.080 --> 00:07:00.880
还使用与主环境隔离的

00:07:00.880 --> 00:07:03.180
Spike进行持续所部对照

00:07:03.240 --> 00:07:06.400
这类任务不靠一句高质量回答取胜

00:07:07.080 --> 00:07:10.200
一个处理器模拟器涉及取指解码

00:07:10.280 --> 00:07:14.080
乱序调度缓存异常处理和周期精度

00:07:14.200 --> 00:07:16.180
任何一个模块的错误都可能

00:07:16.180 --> 00:07:18.540
在几十万条指令之后才出现

00:07:18.880 --> 00:07:20.580
teamwork能发挥作用

00:07:20.600 --> 00:07:22.540
靠的是让不同角色负责

00:07:22.540 --> 00:07:25.140
实现测试质疑和众合

00:07:25.580 --> 00:07:27.600
并把验证嵌进工作流

00:07:28.000 --> 00:07:30.080
模型本身提供推理能力

00:07:30.180 --> 00:07:31.800
协作机制负责把这种

00:07:31.800 --> 00:07:33.940
能力约束在工程流程里

00:07:33.940 --> 00:07:36.540
更有说服力的证据来自开源项目

00:07:36.800 --> 00:07:39.540
teamwork对Eigen和Polyhash

00:07:39.780 --> 00:07:41.280
提出了性能优化

00:07:41.340 --> 00:07:43.180
部分改动通过正常

00:07:43.180 --> 00:07:45.340
代码审查进入上游项目

00:07:45.480 --> 00:07:47.280
实验报告里的漂亮数字可以

00:07:47.280 --> 00:07:49.480
受到环境和选择方式影响

00:07:49.600 --> 00:07:51.900
外部维护者愿意接收代码

00:07:52.000 --> 00:07:55.280
至少说明改动不只存在于演示页面

00:07:55.540 --> 00:07:56.580
他开始碰到真实

00:07:56.580 --> 00:07:58.680
软件世界最麻烦的部分

00:07:58.880 --> 00:08:01.100
旧代码兼容性测试

00:08:01.100 --> 00:08:03.080
要求和他人的审查意见

00:08:03.340 --> 00:08:05.980
Polyhash的结果还展示了研究

00:08:05.980 --> 00:08:08.080
伙伴与代码助手的差别

00:08:08.800 --> 00:08:11.580
Google报告相关改动让64线程下的

00:08:11.580 --> 00:08:14.180
初始插入吞吐量提高约两倍

00:08:14.300 --> 00:08:17.180
单线程整体性能提高约1.5倍

00:08:17.540 --> 00:08:19.500
与flat hash map相比

00:08:19.540 --> 00:08:21.880
内存还减少约25%

00:08:21.980 --> 00:08:24.540
性能优化往往存在交换条件

00:08:24.740 --> 00:08:27.500
一处更快可能换来另一处更慢

00:08:27.800 --> 00:08:29.400
一种数据分布有效

00:08:29.400 --> 00:08:31.940
也可能在另一种负载下失灵

00:08:32.180 --> 00:08:33.880
只有通过基准代码

00:08:33.880 --> 00:08:35.540
审查和维护者判断

00:08:35.740 --> 00:08:38.100
优化才有机会进入真实项目

00:08:38.140 --> 00:08:40.740
这也是teamwork模式比自动生成

00:08:40.740 --> 00:08:43.000
整个项目更值得关注的地方

00:08:43.540 --> 00:08:44.940
研究和工程的价值

00:08:44.940 --> 00:08:46.880
很少由代码行数决定

00:08:47.100 --> 00:08:48.780
系统需要提出假设

00:08:48.980 --> 00:08:50.540
选择测量方法

00:08:50.680 --> 00:08:52.000
识别性能瓶颈

00:08:52.140 --> 00:08:53.780
再接受外部审查

00:08:53.900 --> 00:08:56.000
生成代码只是其中一步

00:08:56.300 --> 00:08:58.880
Google把成果送进现有开源社区

00:08:59.140 --> 00:09:00.900
相当于让智能体进入一个

00:09:00.900 --> 00:09:03.580
由人类规则历史兼容性和

00:09:03.580 --> 00:09:05.400
公开讨论组成的环境

00:09:05.700 --> 00:09:07.380
难度远高于在封闭

00:09:07.380 --> 00:09:09.500
演示里让测试全部变绿

00:09:09.680 --> 00:09:12.340
teamwork解决了谁和谁一起做的问题

00:09:12.780 --> 00:09:14.740
长任务还有另一个隐蔽故障

00:09:15.180 --> 00:09:16.740
智能体每执行一步

00:09:16.800 --> 00:09:19.200
通常都会把观察结果工具

00:09:19.200 --> 00:09:21.980
输出和中间推理追加到对话

00:09:22.100 --> 00:09:23.700
10步以后还能管理

00:09:23.900 --> 00:09:25.000
100步以后

00:09:25.180 --> 00:09:27.380
上下文就会变成混合了当前

00:09:27.380 --> 00:09:30.700
事实过期结论和失败尝试的仓库

00:09:31.180 --> 00:09:32.800
模型每次行动之前

00:09:32.980 --> 00:09:34.480
都要重新从这堆

00:09:34.480 --> 00:09:36.180
文字里恢复世界状态

00:09:36.340 --> 00:09:37.800
人类做长期项目时

00:09:37.800 --> 00:09:39.000
不会这样工作

00:09:39.380 --> 00:09:41.280
工程师不会每天把几个月

00:09:41.280 --> 00:09:43.280
的聊天记录从头读一遍

00:09:43.340 --> 00:09:45.700
再猜代码现在编译到哪一步

00:09:45.980 --> 00:09:47.680
团队会维护任务看板

00:09:47.740 --> 00:09:48.780
测试状态

00:09:48.980 --> 00:09:50.940
风险清单和当前分值

00:09:51.180 --> 00:09:52.880
历史记录可以留档

00:09:53.180 --> 00:09:55.200
下一步决策依赖的却是

00:09:55.200 --> 00:09:57.000
一份清楚的当前状态

00:09:57.140 --> 00:09:59.600
把这个尝试放进智能体运行时

00:10:00.100 --> 00:10:02.180
每一步只给模型三类信息

00:10:02.500 --> 00:10:04.880
固定的任务规范当前结构化

00:10:04.880 --> 00:10:07.880
状态以及环境刚刚返回的新观察

00:10:08.100 --> 00:10:10.000
模型完成推理后提出

00:10:10.000 --> 00:10:12.140
状态修改和下一步动作

00:10:12.300 --> 00:10:14.940
运行时先验证修改是否合法

00:10:15.080 --> 00:10:16.280
再写入状态

00:10:16.540 --> 00:10:18.940
那一轮中间推理随后被丢弃

00:10:19.080 --> 00:10:21.100
不再跟着任务无限增长

00:10:21.180 --> 00:10:24.100
这与传统的上下文压缩有根本区别

00:10:24.700 --> 00:10:26.180
摘要方法仍然需要把

00:10:26.180 --> 00:10:28.100
过去重新写成一段文字

00:10:28.340 --> 00:10:30.300
信息可能在压缩时变形

00:10:30.680 --> 00:10:32.340
模型也要判断摘要里

00:10:32.340 --> 00:10:34.600
哪些内容仍然有效skill

00:10:35.340 --> 00:10:36.480
state直接规定哪些

00:10:36.480 --> 00:10:37.940
字段代表当前世界

00:10:38.180 --> 00:10:39.980
例如安全挑战可以只

00:10:39.980 --> 00:10:41.580
保留已经发现的标记

00:10:41.880 --> 00:10:43.180
测试过的假设

00:10:43.500 --> 00:10:44.500
活跃文件

00:10:44.600 --> 00:10:46.680
当前目录和命令摘要

00:10:46.940 --> 00:10:49.140
下一步行动读取这些字段

00:10:49.140 --> 00:10:50.200
不必回放

00:10:50.300 --> 00:10:51.800
全部终端输出

00:10:51.980 --> 00:10:54.680
论文给出的复杂度变化很直接

00:10:55.280 --> 00:10:57.540
传统追加历史的方式单次

00:10:57.540 --> 00:10:59.940
输入会随着任务长度增长

00:11:00.200 --> 00:11:01.800
累计TOKEN消耗可能

00:11:01.800 --> 00:11:03.600
接近任务步数的平方

00:11:03.780 --> 00:11:05.580
只要状态结构和最新

00:11:05.580 --> 00:11:07.400
观察的大小受到限制

00:11:07.980 --> 00:11:09.780
skill state每一步的提示

00:11:09.780 --> 00:11:11.940
规模可以保持在固定范围

00:11:12.400 --> 00:11:14.880
累计消耗随步数线性增加

00:11:15.100 --> 00:11:17.540
任务从几十步拉到几百步时

00:11:17.600 --> 00:11:19.740
这种差异会迅速放大

00:11:19.780 --> 00:11:22.200
在一项100步的仓库任务里

00:11:22.400 --> 00:11:24.980
Gemini3Flash使用普通react

00:11:24.980 --> 00:11:27.900
方法取得84%的成功率

00:11:28.140 --> 00:11:30.780
累计消耗约124万TOKEN

00:11:31.280 --> 00:11:34.100
skill state把成功率提高到94%

00:11:34.380 --> 00:11:36.380
累计TOKEN约6.5万

00:11:36.400 --> 00:11:37.540
到了200步

00:11:37.740 --> 00:11:40.500
react成功率下降到74%

00:11:40.900 --> 00:11:43.300
skill state仍保持94%

00:11:43.880 --> 00:11:45.940
论文在intercode CTF安全

00:11:45.940 --> 00:11:47.600
任务上的结果也显示

00:11:48.100 --> 00:11:51.140
skill state完成率为54.2%

00:11:51.200 --> 00:11:53.480
它高于几种对照运行方式

00:11:53.680 --> 00:11:55.400
同时把平均提示规模

00:11:55.400 --> 00:11:57.140
和总token压了下来

00:11:57.200 --> 00:11:59.500
更关键的实验是噪声测试

00:12:00.180 --> 00:12:02.200
研究人员向任务环境加入

00:12:02.200 --> 00:12:04.340
与状态无关的遥测信息

00:12:04.580 --> 00:12:07.340
普通提示在噪声变多后明显恶化

00:12:07.480 --> 00:12:10.000
因为无用信息也会一直留在历史里

00:12:10.800 --> 00:12:12.880
skill state只把影响后续

00:12:12.880 --> 00:12:14.580
行动的内容写进状态

00:12:14.940 --> 00:12:17.700
所以成功率保持在接近完整水平

00:12:17.800 --> 00:12:20.100
它展示了一条很实用的原则

00:12:20.480 --> 00:12:22.280
长任务的可靠性不只

00:12:22.280 --> 00:12:24.480
取决于模型能记住多少

00:12:24.580 --> 00:12:26.380
还取决于系统敢不敢

00:12:26.380 --> 00:12:28.180
丢掉已经没用的东西

00:12:28.300 --> 00:12:30.200
这个方案也有明显代价

00:12:30.780 --> 00:12:33.500
状态结构必须由人提前设计

00:12:34.080 --> 00:12:37.200
如果某条早期信息当时看起来无关

00:12:37.380 --> 00:12:39.280
后来才发现它很重要

00:12:39.700 --> 00:12:41.700
而它又没有进入状态字段

00:12:41.940 --> 00:12:43.980
这条线索可能已经丢失

00:12:44.180 --> 00:12:45.880
需要完整审计轨迹

00:12:45.980 --> 00:12:47.300
解释研究过程

00:12:47.300 --> 00:12:49.380
或者回看思路变化的任务

00:12:49.740 --> 00:12:51.700
也不能只保留当前状态

00:12:52.080 --> 00:12:54.600
论文目前主要验证单智能体

00:12:54.740 --> 00:12:57.900
多个智能体同时修改同一份状态时

00:12:57.940 --> 00:12:58.940
会不会覆盖

00:12:59.140 --> 00:13:01.140
冲突又该由谁裁决

00:13:01.300 --> 00:13:02.880
仍然没有充分答案

00:13:03.080 --> 00:13:04.140
论文对小模型的

00:13:04.140 --> 00:13:05.880
失败分析进一步说明

00:13:06.100 --> 00:13:08.800
结构化状态并不会自动带来可靠性

00:13:09.100 --> 00:13:11.580
Gemma开放权重模型在100步

00:13:11.580 --> 00:13:14.080
任务中只有42%的得分

00:13:14.280 --> 00:13:16.580
68%的失败来自过早

00:13:16.580 --> 00:13:18.540
覆盖或删除重要状态

00:13:18.900 --> 00:13:21.880
20%属于结构和类型错误

00:13:22.180 --> 00:13:25.200
还有12%是JSON语法问题

00:13:25.480 --> 00:13:28.380
运行时可以拒绝格式错误的更新

00:13:29.100 --> 00:13:30.980
却无法保证模型对什么

00:13:30.980 --> 00:13:32.740
值得保留的判断正确

00:13:33.000 --> 00:13:34.100
状态越短

00:13:34.340 --> 00:13:35.940
写错一个字段造成

00:13:35.940 --> 00:13:37.600
的影响可能越集中

00:13:37.800 --> 00:13:39.100
承受系统因此需要

00:13:39.100 --> 00:13:40.800
同时保存两层记录

00:13:41.200 --> 00:13:43.780
决策层读取精简的当前状态

00:13:44.100 --> 00:13:46.000
审计层保存完整日志

00:13:46.280 --> 00:13:48.280
出现异常时能够追溯

00:13:48.740 --> 00:13:50.780
前者控制成本和注意力

00:13:50.800 --> 00:13:53.540
后者承担调查合规和复现

00:13:53.940 --> 00:13:57.080
skilled state论文强调丢弃中间推理

00:13:57.200 --> 00:13:59.000
适合追求执行效率

00:13:59.180 --> 00:14:02.280
医疗金融和关键基础设施

00:14:02.280 --> 00:14:04.380
可能要求更严格的留痕

00:14:04.780 --> 00:14:08.680
怎样在隐私成本与可追责之间取舍

00:14:08.880 --> 00:14:11.080
会决定它能进入哪些行业

00:14:11.280 --> 00:14:12.800
状态结构的设计也

00:14:12.800 --> 00:14:14.880
可能成为新的专业岗位

00:14:15.340 --> 00:14:17.200
过去的提示工程关注

00:14:17.200 --> 00:14:18.900
怎样把问题问清楚

00:14:19.540 --> 00:14:20.900
长任务系统更需要

00:14:20.900 --> 00:14:22.780
定义任务进行到哪一步

00:14:22.780 --> 00:14:24.500
应该有哪些字段表示

00:14:24.680 --> 00:14:26.680
供应链任务要记录订单

00:14:26.880 --> 00:14:28.880
交付风险和库存约束

00:14:29.080 --> 00:14:32.100
代码任务要记录分支测试和依赖

00:14:32.300 --> 00:14:33.780
科研任务则要记录

00:14:33.780 --> 00:14:36.280
假设证据和未解决问题

00:14:36.340 --> 00:14:38.580
同一个模板无法覆盖所有领域

00:14:39.000 --> 00:14:41.780
领域专家会重新进入系统设计中心

00:14:41.940 --> 00:14:44.980
现有证据还不足以把skill state写成

00:14:44.980 --> 00:14:48.100
teamwork已经采用的底层记忆系统

00:14:48.700 --> 00:14:51.380
风控材料没有给出这种集成关系

00:14:51.740 --> 00:14:53.400
它们分别击中了长期

00:14:53.400 --> 00:14:54.900
智能体的两处故障

00:14:55.180 --> 00:14:57.500
teamwork防止多个智能体集体

00:14:57.500 --> 00:14:59.500
沿着错误方向自我强化

00:14:59.880 --> 00:15:01.480
skill state防止任务

00:15:01.480 --> 00:15:03.380
历史把当前判断淹没

00:15:03.580 --> 00:15:05.380
未来的研究系统很可能

00:15:05.380 --> 00:15:07.180
同时需要这两种能力

00:15:07.880 --> 00:15:09.680
Google是否会把它们合并

00:15:09.700 --> 00:15:11.900
仍要看后续产品和论文

00:15:11.980 --> 00:15:14.940
第三项能力来自Timesfm 3.0

00:15:15.100 --> 00:15:16.780
它看起来没有数学证明和

00:15:16.780 --> 00:15:19.100
多智能体团队那么戏剧化

00:15:19.180 --> 00:15:21.080
却可能最接近企业每天

00:15:21.080 --> 00:15:22.940
真正要花钱解决的问题

00:15:23.080 --> 00:15:25.980
大量现实决策建立在时间序列上

00:15:26.340 --> 00:15:29.100
零售商要预测下周每家门店的销量

00:15:29.200 --> 00:15:31.700
电网要估计明天每小时的负荷

00:15:32.080 --> 00:15:33.980
云平台要提前分配容量

00:15:34.180 --> 00:15:36.780
工厂要判断设备何时可能异常

00:15:36.980 --> 00:15:39.140
语言模型擅长处理文字

00:15:39.340 --> 00:15:42.100
时间序列要求模型理解趋势

00:15:42.380 --> 00:15:46.080
周期突变变量联动和外部条件

00:15:46.780 --> 00:15:48.880
一个预测错几个百分点

00:15:48.880 --> 00:15:50.500
可能对应库存积压

00:15:50.740 --> 00:15:52.940
能源浪费或者服务中断

00:15:53.180 --> 00:15:56.400
传统做法往往给不同业务单独建模

00:15:56.580 --> 00:15:58.500
某个商品用一套模型

00:15:58.540 --> 00:16:00.880
另一个地区重新调参数

00:16:01.180 --> 00:16:03.100
遇到节假日促销和

00:16:03.100 --> 00:16:05.380
天气还要增加外生变量

00:16:05.700 --> 00:16:06.900
这个流程需要数据

00:16:06.900 --> 00:16:08.580
科学团队长期维护

00:16:08.880 --> 00:16:11.580
模型迁移到新场景时也容易失效

00:16:11.800 --> 00:16:13.480
时间序列基础模型

00:16:13.480 --> 00:16:15.400
希望学习更通用的规律

00:16:15.740 --> 00:16:17.200
用一个预训练模型

00:16:17.200 --> 00:16:19.180
直接处理大量陌生任务

00:16:19.400 --> 00:16:22.700
TIMESFM3.0大约有3亿参数

00:16:22.700 --> 00:16:25.100
支持单变量和多变量预测

00:16:25.140 --> 00:16:26.740
也能接收协变量

00:16:26.780 --> 00:16:27.940
所谓多变量

00:16:28.140 --> 00:16:29.540
是让模型同时理解

00:16:29.540 --> 00:16:31.400
几个彼此影响的序列

00:16:31.600 --> 00:16:34.980
例如价格销量库存和客流

00:16:35.180 --> 00:16:37.100
协变量则可以分成两类

00:16:37.180 --> 00:16:38.900
一类只有过去数据

00:16:39.100 --> 00:16:40.980
另一类在未来已经知道

00:16:41.340 --> 00:16:43.280
比如节假日安排电价

00:16:43.280 --> 00:16:45.000
计划或者促销日程

00:16:45.200 --> 00:16:47.100
这些信息进入预测后

00:16:47.100 --> 00:16:48.600
模型才能区分正常

00:16:48.600 --> 00:16:50.540
季节变化和真正异常

00:16:50.700 --> 00:16:53.180
它采用Stack mixing Transformer架构

00:16:53.400 --> 00:16:55.280
引入varied attention处理

00:16:55.280 --> 00:16:56.940
不同变量之间的关系

00:16:57.380 --> 00:16:59.200
归一化机制则用来减少

00:16:59.200 --> 00:17:01.300
不同序列尺度带来的干扰

00:17:01.600 --> 00:17:03.940
训练材料包括去除评测

00:17:03.940 --> 00:17:06.000
重叠后的时间序列数据

00:17:06.180 --> 00:17:09.180
也纳入截至2023年11月的

00:17:09.180 --> 00:17:11.140
Wikipedia页面访问量

00:17:11.340 --> 00:17:14.600
截至2022年底的Google Trends热门查询

00:17:14.940 --> 00:17:18.380
合成数据和增强数据同样进入训练

00:17:18.540 --> 00:17:19.900
这些细节说明

00:17:19.980 --> 00:17:21.800
所谓通用预测能力依然

00:17:21.800 --> 00:17:24.700
建立在大规模多来源序列上

00:17:24.700 --> 00:17:26.880
时间序列模型最怕数据泄露

00:17:27.540 --> 00:17:29.880
训练集如果包含评测其信息

00:17:30.080 --> 00:17:31.600
或者同一序列的片段

00:17:31.600 --> 00:17:33.380
同时进入训练和测试

00:17:33.580 --> 00:17:35.300
排名会显得异常漂亮

00:17:35.540 --> 00:17:36.580
Google特别说明

00:17:36.580 --> 00:17:38.400
gift Evals训练数据排除了

00:17:38.400 --> 00:17:40.540
与Fbench重叠的数据集

00:17:40.880 --> 00:17:42.700
目的就是降低这种问题

00:17:42.980 --> 00:17:43.900
即便如此

00:17:44.340 --> 00:17:47.280
三个基准第一仍然属于发布方报告

00:17:47.540 --> 00:17:49.700
企业部署前还要在自己的

00:17:49.700 --> 00:17:52.600
时间跨度异常条件和业务

00:17:52.600 --> 00:17:54.580
损失函数上重新验证

00:17:54.700 --> 00:17:56.100
预测准确率也不能

00:17:56.100 --> 00:17:57.680
单独决定业务价值

00:17:58.200 --> 00:18:00.200
库存系统更关心缺货和

00:18:00.200 --> 00:18:02.400
积压哪一种错误代价更高

00:18:02.780 --> 00:18:05.380
电网预测必须关注极端峰值

00:18:05.780 --> 00:18:08.200
金融公开则可能在意尾部事件

00:18:08.380 --> 00:18:10.600
一个模型平均误差更低

00:18:10.740 --> 00:18:13.480
未必在最昂贵的错误上表现更好

00:18:13.600 --> 00:18:15.980
Timesfm提供分位数预测

00:18:16.100 --> 00:18:18.540
让使用者看到不同可能区间

00:18:19.080 --> 00:18:20.380
这比只交付一个单

00:18:20.380 --> 00:18:22.180
点数字更适合决策

00:18:22.340 --> 00:18:25.000
但最后仍需业务规则解释风险

00:18:25.340 --> 00:18:28.280
Google列出了Fbench time Benchmark

00:18:28.580 --> 00:18:30.480
和JIFF Evals三个主要

00:18:30.480 --> 00:18:32.500
时间序列基础模型评测

00:18:32.680 --> 00:18:36.080
并称TIMESFM3.0均排名第一

00:18:36.200 --> 00:18:39.740
Fbench包含100项多样化现实预测任务

00:18:40.080 --> 00:18:42.380
timebenchmark覆盖50个领域

00:18:42.380 --> 00:18:44.680
数据集和98项评估任务

00:18:44.900 --> 00:18:48.140
这个结果说明基础模型路线正在从

00:18:48.140 --> 00:18:51.900
文本图像继续向企业数字世界扩张

00:18:52.140 --> 00:18:54.280
timesfm的商业价值不止

00:18:54.280 --> 00:18:56.000
来自一次预测精度

00:18:56.400 --> 00:18:58.540
统一模型可以减少每个部门

00:18:58.540 --> 00:19:01.200
重复训练和维护小模型的成本

00:19:01.380 --> 00:19:03.580
也更适合被智能体调用

00:19:03.800 --> 00:19:05.680
一个负责供应链的智能体

00:19:05.680 --> 00:19:09.180
如果能够读取订单库存和物流数据

00:19:09.280 --> 00:19:12.000
再调用时间序列模型生成预测

00:19:12.140 --> 00:19:15.100
它才有机会提出可执行的采购方案

00:19:15.400 --> 00:19:17.180
缺少这一层专业工具

00:19:17.540 --> 00:19:19.740
通用智能体往往只能根据

00:19:19.740 --> 00:19:21.980
文字描述给出宽泛建议

00:19:22.200 --> 00:19:24.380
Google在这个方向还有分发优势

00:19:24.700 --> 00:19:26.900
timesfm较早版本已经进入

00:19:26.900 --> 00:19:30.200
bigqueryml和googlesheets等产品生态

00:19:30.580 --> 00:19:32.300
企业不需要先搭一套全新

00:19:32.300 --> 00:19:34.100
平台便可以在熟悉的数据

00:19:34.100 --> 00:19:35.980
工具中接触预测能力

00:19:36.180 --> 00:19:40.680
TIMESFM3.0公开了Pytorch权重和使用方式

00:19:41.000 --> 00:19:44.000
但现有资料没有证明3.0权重已经

00:19:44.000 --> 00:19:46.900
同步替换这些产品里的所有版本

00:19:46.980 --> 00:19:48.580
产品整合能走多快

00:19:48.680 --> 00:19:51.100
仍需以Google后续公告为准

00:19:51.280 --> 00:19:54.540
许可证也是一个容易被忽略的限制

00:19:55.300 --> 00:19:57.600
timesfm代码仓库采用

00:19:57.740 --> 00:20:00.980
Apache2.03.0预训练权重

00:20:00.980 --> 00:20:03.580
却使用单独的非商业许可证

00:20:03.880 --> 00:20:05.940
研究者可以下载和实验

00:20:06.500 --> 00:20:09.780
默认权重目前不允许用于商业生产

00:20:09.800 --> 00:20:12.100
把它简单称为完全开源

00:20:12.300 --> 00:20:13.540
企业拿来就能用

00:20:13.540 --> 00:20:14.780
会误导观众

00:20:15.580 --> 00:20:18.200
Google开放了能力展示和研究入口

00:20:18.280 --> 00:20:20.400
同时保留了商业化控制权

00:20:20.480 --> 00:20:22.740
把这三项工作放回同一张图

00:20:22.940 --> 00:20:24.540
Google的策略开始显形

00:20:25.080 --> 00:20:27.380
teamwork负责扩大搜索空间

00:20:27.380 --> 00:20:30.300
让多个智能体竞争和互相纠错

00:20:30.600 --> 00:20:32.380
skilled state试图控制长

00:20:32.380 --> 00:20:33.940
任务的状态和成本

00:20:34.200 --> 00:20:37.380
timesfm 3.0提供专业预测能力

00:20:37.540 --> 00:20:40.280
协作状态专业工具

00:20:40.700 --> 00:20:42.740
构成AI参与长期研究和

00:20:42.740 --> 00:20:44.480
工程工作的三根支柱

00:20:45.000 --> 00:20:47.180
这条路线也解释了为什么单纯

00:20:47.180 --> 00:20:50.700
扩大模型参数带来的惊喜正在减少

00:20:51.000 --> 00:20:53.080
模型可以在基准上更聪明

00:20:53.540 --> 00:20:56.000
复杂项目仍然会被组织问题拖垮

00:20:56.200 --> 00:20:57.700
给一个人更高智商

00:20:57.780 --> 00:20:59.940
不代表他自动拥有实验室

00:21:00.140 --> 00:21:02.480
项目管理制度和专业仪器

00:21:02.600 --> 00:21:04.080
AI系统也一样

00:21:04.200 --> 00:21:06.000
模型负责提出和判断

00:21:06.280 --> 00:21:07.880
编排系统负责调度

00:21:08.100 --> 00:21:10.540
状态系统负责记录当前事实

00:21:10.980 --> 00:21:12.580
专业模型负责处理通用

00:21:12.580 --> 00:21:14.580
语言能力覆盖不到的数据

00:21:14.880 --> 00:21:17.100
Google在这一轮竞争里的优势

00:21:17.540 --> 00:21:20.300
来自这些组件之间潜在的闭环

00:21:20.740 --> 00:21:21.980
它有Gemini模型

00:21:21.980 --> 00:21:25.100
也有antigravity这个智能体工作界面

00:21:25.340 --> 00:21:28.200
cloud和bigquery可以承接企业数据

00:21:28.400 --> 00:21:31.540
专业能力则覆盖科学代码和预测

00:21:31.700 --> 00:21:33.940
只要这些产品真正连起来

00:21:33.980 --> 00:21:36.740
Google出售的将是一套能进入研究

00:21:36.740 --> 00:21:39.100
流程和生产系统的工作环境

00:21:39.580 --> 00:21:42.080
聊天机器人只是其中一个入口

00:21:42.080 --> 00:21:44.000
这个闭环真正形成后

00:21:44.080 --> 00:21:46.340
用户的购买单位也会变化

00:21:46.600 --> 00:21:48.500
企业过去按模型调用

00:21:48.500 --> 00:21:50.200
次数购买智能能力

00:21:50.380 --> 00:21:52.680
未来可能按完成的研究活动

00:21:52.700 --> 00:21:55.700
工程任务或预测工作流付费

00:21:55.900 --> 00:21:57.900
模型选择会退到系统内部

00:21:58.400 --> 00:21:59.940
简单步骤调用Flash

00:22:00.140 --> 00:22:01.700
困难判断切换Pro

00:22:02.140 --> 00:22:04.280
时间序列交给timesfm

00:22:04.340 --> 00:22:06.300
代码验证交给测试工具

00:22:06.400 --> 00:22:08.900
客户关心的是任务有没有完成

00:22:09.300 --> 00:22:10.500
证据是否充分

00:22:10.540 --> 00:22:11.800
成本能否预测

00:22:12.080 --> 00:22:14.080
Google已经在antigravity里提供

00:22:14.080 --> 00:22:16.580
动态子智能体异步任务

00:22:16.700 --> 00:22:18.980
定时执行和自定义角色

00:22:19.300 --> 00:22:22.000
teamwork继续向上增加协作模式

00:22:22.500 --> 00:22:24.500
他还把antigravity扩展到

00:22:24.500 --> 00:22:27.380
命令行IDE和企业平台

00:22:27.540 --> 00:22:29.900
每一个入口都在降低智能体

00:22:29.900 --> 00:22:32.180
进入现有工作的迁移成本

00:22:32.300 --> 00:22:33.900
研究人员不必为了使用

00:22:33.900 --> 00:22:35.780
智能体放弃代码仓库

00:22:36.380 --> 00:22:37.700
企业也不必把全部

00:22:37.700 --> 00:22:39.600
数据搬进一个聊天网页

00:22:39.780 --> 00:22:42.400
竞争对手当然会走同一方向

00:22:42.540 --> 00:22:44.800
多智能体编排结构化

00:22:44.800 --> 00:22:47.200
状态和专业模型都没有

00:22:47.480 --> 00:22:49.540
只属于Google的理论壁垒

00:22:49.780 --> 00:22:52.740
Google较难复制的部分是搜索

00:22:52.940 --> 00:22:56.100
云办公套件开发工具和自

00:22:56.100 --> 00:22:58.000
研模型形成的分发网络

00:22:58.340 --> 00:22:59.940
技术领先可以被追赶

00:23:00.080 --> 00:23:01.680
把能力送到企业已经

00:23:01.680 --> 00:23:03.680
存在的数据和流程里

00:23:03.740 --> 00:23:05.540
通常需要更长时间

00:23:05.780 --> 00:23:06.740
潜力越大

00:23:06.780 --> 00:23:08.600
成本问题越不能跳过

00:23:09.200 --> 00:23:11.480
teamwork的高质量结果依赖

00:23:11.480 --> 00:23:13.340
并行搜索和多轮验证

00:23:13.500 --> 00:23:16.280
同一个问题同时运行十几条路线

00:23:16.580 --> 00:23:20.100
会消耗更多推理资源Gemini 3.7

00:23:20.400 --> 00:23:23.080
Flash的速度和价格可以降低门槛

00:23:23.140 --> 00:23:25.180
却不会让算力成本消失

00:23:25.400 --> 00:23:27.100
公开预览版本刻意在

00:23:27.100 --> 00:23:29.000
能力和费用之间做平衡

00:23:29.180 --> 00:23:32.080
也说明实验室里最大化智能的配置

00:23:32.680 --> 00:23:35.200
很难直接成为每个用户的默认服务

00:23:35.400 --> 00:23:37.740
企业还要面对另一种成本

00:23:38.080 --> 00:23:40.600
skill点state需要设计状态结构

00:23:40.700 --> 00:23:43.900
timesfm需要干净且有意义的数据

00:23:44.000 --> 00:23:46.480
teamwork需要明确验收标准

00:23:46.600 --> 00:23:48.740
公司如果连流程指标和

00:23:48.740 --> 00:23:50.400
数据权限都没有理清

00:23:50.980 --> 00:23:53.800
接入更多智能体只会把混乱自动化

00:23:53.940 --> 00:23:56.400
研究伙伴能够加快一套好流程

00:23:56.700 --> 00:23:59.180
也能更快执行一套错误流程

00:23:59.380 --> 00:24:01.340
责任边界同样没有消失

00:24:01.580 --> 00:24:03.740
数学证明可以交给Ling验证

00:24:04.140 --> 00:24:06.900
代码可以用测试和上游审查把关

00:24:07.480 --> 00:24:09.080
时间序列预测却经常

00:24:09.080 --> 00:24:11.800
影响库存能源和资金配置

00:24:12.080 --> 00:24:13.580
模型给出结果以后

00:24:13.780 --> 00:24:15.600
谁确认数据没有偏差

00:24:16.100 --> 00:24:18.680
谁判断异常是否来自制度变化

00:24:18.940 --> 00:24:21.340
谁为错误决策承担后果

00:24:21.480 --> 00:24:22.680
这些问题不能交给

00:24:22.680 --> 00:24:24.580
一个置信度数字解决

00:24:25.080 --> 00:24:27.480
Google在teamwork介绍中反复强调

00:24:27.600 --> 00:24:30.180
人类仍然掌握目标和最终验收

00:24:30.380 --> 00:24:33.200
这句话点出了当前系统成立的前提

00:24:33.400 --> 00:24:36.140
智能体可以扩大候选方案数量

00:24:36.300 --> 00:24:37.880
也能更快找漏洞

00:24:38.300 --> 00:24:39.540
却不知道一个组织

00:24:39.540 --> 00:24:41.500
真正愿意承担什么风险

00:24:41.700 --> 00:24:43.880
研究方向的价值证据是否

00:24:43.880 --> 00:24:46.540
足够结果何时可以进入现实

00:24:46.540 --> 00:24:48.080
都需要有人签字

00:24:48.200 --> 00:24:50.280
所以AI成为长期研究

00:24:50.280 --> 00:24:52.180
伙伴的标志会很安静

00:24:52.480 --> 00:24:54.380
他开始连续工作几天

00:24:54.500 --> 00:24:56.800
知道当前项目处在哪一步

00:24:57.080 --> 00:24:59.700
他能主动找人反驳自己的方案

00:24:59.900 --> 00:25:02.180
也会调用合适的专业模型

00:25:02.340 --> 00:25:04.280
避免用语言猜数字

00:25:04.480 --> 00:25:06.180
他留下可检查的结果

00:25:06.200 --> 00:25:07.740
也接受外部验证

00:25:08.280 --> 00:25:10.800
某个模型宣布自己达到专家水平

00:25:10.880 --> 00:25:12.280
证明不了这些能力

00:25:12.480 --> 00:25:15.300
Google正在补齐的正是这些基础能力

00:25:15.580 --> 00:25:18.280
teamwork让AI学会组织争论

00:25:18.600 --> 00:25:21.700
skill state让它在长任务中保持清醒

00:25:21.900 --> 00:25:25.140
Times FM3.0让它进入专业预测

00:25:25.280 --> 00:25:27.700
三项技术还没有合成一个无缝系统

00:25:28.280 --> 00:25:30.680
距离可信赖的研究伙伴也差

00:25:30.680 --> 00:25:34.580
着权限安全责任和成本管理

00:25:34.580 --> 00:25:36.740
但竞争的目标已经变了

00:25:36.780 --> 00:25:38.940
过去的AI比赛看谁能在

00:25:38.940 --> 00:25:41.200
一分钟里给出最惊艳的答案

00:25:41.880 --> 00:25:43.100
接下来的比赛

00:25:43.200 --> 00:25:45.500
要看谁能在100个步骤之后

00:25:45.500 --> 00:25:47.580
仍然知道自己为什么这么做

00:25:47.740 --> 00:25:49.800
能把结果交给专家复核

00:25:50.140 --> 00:25:51.800
还能把整套流程控制

00:25:51.800 --> 00:25:53.680
在可承受的成本里

00:25:53.740 --> 00:25:56.140
Google这次释放的信号很明确

00:25:56.480 --> 00:25:57.880
模型负责起步

00:25:58.080 --> 00:25:59.700
产品要让智能长期

00:25:59.940 --> 00:26:02.080
稳定并且专业的工作