WEBVTT
Kind: captions
Language: zh

00:00:00.200 --> 00:00:01.533
谷歌内部又出现了

00:00:01.533 --> 00:00:03.166
一个叫carbon的模型

00:00:03.300 --> 00:00:05.700
有人用完之后把它的编程

00:00:05.700 --> 00:00:09.333
表现拿来跟Claudeopus 5.5比较

00:00:09.700 --> 00:00:12.300
但这轮竞争最值得追问的地方是

00:00:12.400 --> 00:00:14.166
模型越来越会写代码

00:00:14.300 --> 00:00:15.766
为什么企业离放心

00:00:15.766 --> 00:00:18.000
交出工作还是差那么远

00:00:18.266 --> 00:00:21.566
carbon的消息加上微软刚推出的decision

00:00:22.200 --> 00:00:24.733
恰好把这个缺口摆到了台面上

00:00:24.800 --> 00:00:26.800
先把消息的分量放准

00:00:27.466 --> 00:00:29.166
carbon目前受到关注

00:00:29.500 --> 00:00:31.533
主要来自business Insider对

00:00:31.533 --> 00:00:33.200
谷歌内部材料的报道

00:00:33.333 --> 00:00:34.733
员工正在内部编程

00:00:34.733 --> 00:00:36.600
环境Jetbrains里测试它

00:00:36.800 --> 00:00:38.466
有人给出积极评价

00:00:38.466 --> 00:00:40.800
也有人提醒还需要更多测试

00:00:40.933 --> 00:00:44.166
这属于接触过产品的人的使用反馈

00:00:44.700 --> 00:00:46.800
它能说明谷歌正在试验什么

00:00:46.900 --> 00:00:48.100
暂时还回答不了

00:00:48.100 --> 00:00:50.000
公开产品最终有多强

00:00:50.133 --> 00:00:53.600
报道涉及Argon Barium和carbon几个名字

00:00:54.166 --> 00:00:55.966
公开亮相的Argon与内部

00:00:55.966 --> 00:00:57.866
候选版本的选择有关

00:00:58.166 --> 00:01:00.533
这些代号容易制造一种错觉

00:01:00.700 --> 00:01:02.900
好像元素名称排到后面

00:01:03.000 --> 00:01:04.700
性能就自动升一级

00:01:05.300 --> 00:01:06.800
开发流程里却经常

00:01:06.800 --> 00:01:08.866
同时存在多个候选版本

00:01:09.000 --> 00:01:11.666
名字可以帮助团队区分实验

00:01:11.700 --> 00:01:13.933
不能拿来替代完整的测评

00:01:14.166 --> 00:01:16.066
其中最容易被传播的

00:01:16.066 --> 00:01:17.933
是员工把carbon的编程

00:01:17.933 --> 00:01:20.533
感觉与Opus5.5放在一起谈

00:01:21.133 --> 00:01:22.766
这个比较有新闻价值

00:01:22.766 --> 00:01:24.733
因为编程已经成为前沿

00:01:24.733 --> 00:01:26.733
模型竞争的重要场景

00:01:26.766 --> 00:01:30.500
但员工熟悉的仓库使用的工具以及

00:01:30.500 --> 00:01:33.733
愿意交给模型的任务都会影响体验

00:01:34.100 --> 00:01:35.566
一个团队觉得顺手

00:01:35.666 --> 00:01:37.666
距离跨行业稳定领先

00:01:37.733 --> 00:01:39.666
还需要经过公开检验

00:01:39.866 --> 00:01:41.366
谷歌并没有在这篇报道

00:01:41.366 --> 00:01:43.500
中披露carbon的参数规模

00:01:44.100 --> 00:01:45.466
外界也没有因此拿到

00:01:45.466 --> 00:01:47.133
可以复现的完整测试

00:01:47.366 --> 00:01:48.900
所以庞然大物适合

00:01:48.900 --> 00:01:50.600
表达市场对它的期待

00:01:50.666 --> 00:01:52.733
不能直接写成参数记录

00:01:52.933 --> 00:01:54.866
真正有用的问题是

00:01:54.866 --> 00:01:56.600
它能不能把工作做完

00:01:56.733 --> 00:01:58.000
而且做完以后

00:01:58.000 --> 00:01:59.466
别人敢不敢接手

00:01:59.533 --> 00:02:01.533
这个区别落到编程上

00:02:01.566 --> 00:02:02.800
很容易看出来

00:02:03.400 --> 00:02:05.900
让模型生成一个独立的小程序

00:02:06.066 --> 00:02:08.066
通常可以很快看到成果

00:02:08.333 --> 00:02:11.466
让它接手一套已经运行多年的系统

00:02:11.533 --> 00:02:13.000
情况就复杂了

00:02:13.000 --> 00:02:14.600
某个函数看起来多余

00:02:15.000 --> 00:02:16.100
可能正好处理一个

00:02:16.100 --> 00:02:17.733
老客户的特殊情况

00:02:18.000 --> 00:02:19.200
模型删掉它

00:02:19.466 --> 00:02:21.266
测试暂时照样通过

00:02:21.400 --> 00:02:23.366
客户第二天才会发现问题

00:02:23.500 --> 00:02:26.966
企业付钱买的是经过验证的修改

00:02:27.666 --> 00:02:29.166
代码只是修改过程

00:02:29.166 --> 00:02:30.700
留下的一部分结果

00:02:30.966 --> 00:02:32.966
模型需要找到相关模块

00:02:33.266 --> 00:02:34.666
理解接口约束

00:02:34.966 --> 00:02:37.533
再检查改动有没有影响别处

00:02:37.766 --> 00:02:40.100
某些任务还得等待构建完成

00:02:40.666 --> 00:02:41.700
读错误日志

00:02:41.866 --> 00:02:43.200
重新定位问题

00:02:43.366 --> 00:02:45.200
每个环节都可能让第一次

00:02:45.200 --> 00:02:48.466
生成时的漂亮答案失去价值因此

00:02:48.466 --> 00:02:51.166
内部工程师愿意继续使用一个模型

00:02:51.400 --> 00:02:52.700
往往比一张孤立的

00:02:52.700 --> 00:02:54.266
成绩表更值得关注

00:02:54.700 --> 00:02:57.166
他们已经知道哪些建议会浪费时间

00:02:57.333 --> 00:02:59.000
也知道哪些回答看似

00:02:59.000 --> 00:03:00.733
复杂却解决不了问题

00:03:00.866 --> 00:03:02.266
如果carbon能在日常

00:03:02.266 --> 00:03:04.000
任务里减少反复解释

00:03:04.100 --> 00:03:05.600
减少审查后的返工

00:03:05.766 --> 00:03:08.766
这种体验就可能转化成真实需求

00:03:09.666 --> 00:03:12.100
现在的报道提供了一个观察入口

00:03:12.166 --> 00:03:13.900
还没有给出最终结论

00:03:14.100 --> 00:03:16.700
接下来要看的是连续工作能力

00:03:16.766 --> 00:03:19.966
单次回答做对和一连串操作做对

00:03:19.966 --> 00:03:21.333
难度差别很大

00:03:21.600 --> 00:03:23.733
一个代理可能正确理解需求

00:03:23.900 --> 00:03:25.166
却选错文件

00:03:25.333 --> 00:03:26.900
也可能改对文件

00:03:26.933 --> 00:03:28.566
却漏跑相关测试

00:03:28.733 --> 00:03:30.400
最后汇报完成的时候

00:03:30.466 --> 00:03:31.366
他甚至可能没有

00:03:31.366 --> 00:03:33.066
注意到工具已经报错

00:03:33.500 --> 00:03:35.600
用户看到的一个结果背后

00:03:35.600 --> 00:03:37.566
其实经过了很多次判断

00:03:37.700 --> 00:03:39.000
用一个纯粹释义的

00:03:39.000 --> 00:03:40.733
算式就能理解风险

00:03:41.000 --> 00:03:43.100
假设10个步骤彼此独立

00:03:43.400 --> 00:03:45.766
每一步成功率都是95%

00:03:45.900 --> 00:03:48.966
10步全部成功的概率也只有大约6成

00:03:49.166 --> 00:03:51.333
这并非carbon的测试数据

00:03:51.600 --> 00:03:54.200
实际任务也未必满足独立假设

00:03:54.366 --> 00:03:55.900
这个例子只是提醒

00:03:56.266 --> 00:03:58.366
长任务会放大局部失误

00:03:58.900 --> 00:04:00.100
单步表现不错

00:04:00.166 --> 00:04:01.933
不能保证整体可靠

00:04:02.100 --> 00:04:04.933
真正成熟的系统必须允许纠错

00:04:05.200 --> 00:04:06.666
工具执行失败

00:04:06.866 --> 00:04:08.366
代理要发现失败

00:04:08.766 --> 00:04:11.666
发现之后还得知道应该换方法

00:04:11.733 --> 00:04:13.366
还是停下来询问

00:04:13.466 --> 00:04:14.933
更麻烦的情况是

00:04:14.933 --> 00:04:16.166
工具没有报错

00:04:16.166 --> 00:04:18.166
但结果不符合业务要求

00:04:18.333 --> 00:04:21.133
比如系统成功发出了一封邮件

00:04:21.566 --> 00:04:23.133
收件人却选错了

00:04:23.300 --> 00:04:24.733
技术执行成功

00:04:24.800 --> 00:04:26.100
业务已经出事

00:04:26.266 --> 00:04:29.166
这也是编程模型值得研究的原因

00:04:29.866 --> 00:04:32.500
软件开发能提供比较明确的反馈

00:04:33.100 --> 00:04:34.600
编译器会报错

00:04:34.700 --> 00:04:35.966
测试会失败

00:04:36.200 --> 00:04:37.933
运行结果可以检查

00:04:38.533 --> 00:04:41.600
模型有机会利用这些反馈修正操作

00:04:41.733 --> 00:04:44.133
相比完全凭主观判断的任务

00:04:44.300 --> 00:04:47.266
这种环境更适合测量长流程能力

00:04:47.933 --> 00:04:49.800
不过测试覆盖不到的业务

00:04:49.800 --> 00:04:52.200
规则仍然需要其他检查

00:04:52.366 --> 00:04:53.766
评估carbon时

00:04:53.766 --> 00:04:56.700
可以先观察它遇到失败的表现

00:04:56.766 --> 00:04:58.400
第一次没有解决问题

00:04:58.600 --> 00:05:00.900
会不会继续重复同一套方案

00:05:01.066 --> 00:05:02.900
面对相互矛盾的文件

00:05:03.166 --> 00:05:04.966
会不会主动查找依据

00:05:05.333 --> 00:05:07.466
已经花费很多时间之后

00:05:07.900 --> 00:05:10.566
会不会为了尽快结束而宣称成功

00:05:10.700 --> 00:05:12.533
这些行为比生成答案

00:05:12.533 --> 00:05:14.300
时的语气有多自信

00:05:14.300 --> 00:05:16.733
更接近企业真正担心的事

00:05:16.866 --> 00:05:18.800
内部测试还有一层价值

00:05:19.366 --> 00:05:22.166
谷歌的工程环境能够提供真实任务

00:05:22.466 --> 00:05:25.166
让模型遇到教科书上没有的麻烦

00:05:25.166 --> 00:05:27.766
但这种环境也会引入条件差异

00:05:27.900 --> 00:05:30.600
如果gensky提供了更好的代码检索

00:05:30.700 --> 00:05:32.866
或者自动准备好了上下文

00:05:32.933 --> 00:05:35.200
最终体验就包含工具的贡献

00:05:35.733 --> 00:05:38.266
模型和工程系统应该一起评估

00:05:38.333 --> 00:05:41.533
不能把所有提升都归到模型权重上

00:05:41.600 --> 00:05:43.766
外界经常把新模型的进步

00:05:43.766 --> 00:05:45.933
想成一次训练带来的跳跃

00:05:46.300 --> 00:05:48.200
实际产品可能同时改了

00:05:48.200 --> 00:05:50.166
提示方式和工具调用

00:05:50.566 --> 00:05:52.366
也可能换了检索方法

00:05:52.533 --> 00:05:54.100
调整了计算预算

00:05:54.300 --> 00:05:55.966
哪怕底层模型相同

00:05:55.966 --> 00:05:57.866
任务完成率也可能变化

00:05:57.966 --> 00:05:59.900
看到内部版本好用

00:06:00.000 --> 00:06:02.400
更稳妥的追问是哪些改进

00:06:02.400 --> 00:06:04.333
能够保留到正式服务里

00:06:04.466 --> 00:06:05.800
这就牵涉到成本

00:06:06.000 --> 00:06:08.400
测试时允许模型思考很久

00:06:08.500 --> 00:06:09.966
调用很多次工具

00:06:10.066 --> 00:06:11.900
容易换来更好的结果

00:06:12.100 --> 00:06:13.400
正式上线之后

00:06:13.400 --> 00:06:16.533
服务需要承受大量用户同时请求

00:06:16.733 --> 00:06:18.133
等待时间过长

00:06:18.266 --> 00:06:19.733
普通用户会放弃

00:06:19.866 --> 00:06:21.900
每个任务的计算费用太高

00:06:22.366 --> 00:06:23.933
企业即使喜欢效果

00:06:23.933 --> 00:06:25.966
也未必愿意大规模采购

00:06:26.000 --> 00:06:29.266
所以一次内部体验要成为商业突破

00:06:29.400 --> 00:06:31.266
需要经过几道现实关卡

00:06:31.466 --> 00:06:32.400
同样的任务

00:06:32.466 --> 00:06:35.000
在可接受的时间里能不能做完

00:06:35.333 --> 00:06:36.566
用户增加之后

00:06:36.700 --> 00:06:38.333
服务质量能不能维持

00:06:38.566 --> 00:06:40.333
团队升级工具之后

00:06:40.366 --> 00:06:42.100
旧流程会不会失效

00:06:42.166 --> 00:06:44.366
这些问题没有一项能靠

00:06:44.366 --> 00:06:46.933
感觉像顶级模型直接解决

00:06:47.200 --> 00:06:50.000
却会决定产品最后有没有人续费

00:06:50.100 --> 00:06:52.100
再看已经公开的Argon

00:06:52.666 --> 00:06:54.100
谷歌的官方介绍

00:06:54.100 --> 00:06:56.166
采用分阶段开放安排

00:06:56.266 --> 00:06:59.066
涉及受信任的网路防御使用者

00:06:59.333 --> 00:07:01.266
随后逐步扩展访问

00:07:01.566 --> 00:07:03.300
公开产品和内部候选

00:07:03.300 --> 00:07:05.566
版本之间存在发布距离

00:07:05.733 --> 00:07:08.066
部分用户能接触到某项能力

00:07:08.200 --> 00:07:09.933
并不代表所有账户都

00:07:09.933 --> 00:07:11.566
已经拥有相同条件

00:07:11.900 --> 00:07:13.733
更不代表carbon已经成为

00:07:13.733 --> 00:07:15.466
公开可购买的服务

00:07:15.466 --> 00:07:18.066
这种距离也会让截图变得危险

00:07:18.600 --> 00:07:20.766
测试界面里出现某个名称

00:07:20.800 --> 00:07:22.466
可能只是灰度实验

00:07:22.733 --> 00:07:24.733
显示较长的上下文

00:07:24.733 --> 00:07:26.700
也可能对应特定入口

00:07:26.866 --> 00:07:29.066
用户最需要确认的是

00:07:29.066 --> 00:07:31.100
正式文档中的可用范围

00:07:31.900 --> 00:07:34.200
以及实际账户能否调用

00:07:34.300 --> 00:07:37.266
单张界面截图无法证明永久额度

00:07:37.333 --> 00:07:39.600
更无法承诺服务上线的时间

00:07:39.733 --> 00:07:42.300
上下文长度尤其容易引发误判

00:07:42.666 --> 00:07:44.366
能放进去很多资料

00:07:44.500 --> 00:07:46.600
只说明输入容量扩大

00:07:47.266 --> 00:07:49.200
模型能否找到关键证据

00:07:49.400 --> 00:07:52.133
能否区分新版文件和旧版文件

00:07:52.266 --> 00:07:53.600
还要另行测试

00:07:53.733 --> 00:07:56.533
一个系统把所有历史记录都塞进去

00:07:56.666 --> 00:07:57.966
可能增加信息

00:07:58.000 --> 00:07:59.400
也可能增加冲突

00:08:00.066 --> 00:08:01.000
资料越多

00:08:01.000 --> 00:08:02.933
选择依据的能力越重要

00:08:03.133 --> 00:08:05.133
企业真正需要的是可追溯

00:08:05.400 --> 00:08:07.800
模型说某条规则要求这样处理

00:08:07.933 --> 00:08:10.066
工作人员能否查到具体出处

00:08:10.300 --> 00:08:11.666
规则刚刚更新

00:08:11.966 --> 00:08:14.100
系统会不会仍然引用旧版

00:08:14.300 --> 00:08:15.466
同一段资料被不同

00:08:15.466 --> 00:08:17.200
部门解释成不同意思

00:08:17.533 --> 00:08:19.000
代理会怎样处理

00:08:19.100 --> 00:08:21.666
这些细节没有发布会上那么好看

00:08:21.933 --> 00:08:24.533
却直接决定自动化能走多远

00:08:24.700 --> 00:08:25.933
围绕carbon

00:08:25.933 --> 00:08:28.300
还有一个更容易制造轰动的词

00:08:28.933 --> 00:08:31.666
RSI也就是递归自我改进

00:08:31.933 --> 00:08:34.800
相关讨论把模型变强与模型

00:08:34.800 --> 00:08:37.333
帮助改进下一代模型联系起来

00:08:37.466 --> 00:08:39.166
但目前提到的内部测试

00:08:39.166 --> 00:08:41.266
报道并没有提供足够证据

00:08:41.700 --> 00:08:43.800
让外界宣布谷歌已经实现

00:08:43.800 --> 00:08:45.766
了完整的自主递归升级

00:08:46.066 --> 00:08:48.300
这里必须把几种过程拆开

00:08:48.400 --> 00:08:50.666
第一种过程是模型修改

00:08:50.666 --> 00:08:52.300
自己刚刚生成的答案

00:08:52.466 --> 00:08:54.466
编译失败后补一个导入

00:08:54.600 --> 00:08:56.600
测试失败后调整函数

00:08:56.666 --> 00:08:58.900
这属于当前任务里的纠错

00:08:59.200 --> 00:09:00.766
第二种过程是

00:09:00.766 --> 00:09:03.100
研究人员让模型参与开发

00:09:03.266 --> 00:09:05.866
帮助写实验代码或者分析结果

00:09:06.000 --> 00:09:07.800
它能够节约研究时间

00:09:08.500 --> 00:09:10.100
但研究方向和验收

00:09:10.100 --> 00:09:12.133
标准仍然可能由人决定

00:09:12.266 --> 00:09:14.133
更强的说法是系统

00:09:14.133 --> 00:09:15.800
自主提出改进方案

00:09:15.933 --> 00:09:17.533
完成训练和评估

00:09:17.666 --> 00:09:19.866
再确认新系统确实更好

00:09:19.866 --> 00:09:21.133
并继续下一轮

00:09:21.666 --> 00:09:23.166
要支撑这种说法

00:09:23.266 --> 00:09:25.500
至少需要看到比较完整的过程

00:09:25.700 --> 00:09:26.966
模型改了什么

00:09:27.000 --> 00:09:28.400
投入多少资源

00:09:28.500 --> 00:09:30.800
在哪些没见过的任务上进步

00:09:30.866 --> 00:09:32.933
出现退步又怎样处理

00:09:33.533 --> 00:09:34.733
少了这些信息

00:09:34.866 --> 00:09:37.500
自我进化很容易只剩一个标签

00:09:37.666 --> 00:09:39.333
尤其要防止把熟悉

00:09:39.333 --> 00:09:41.100
考试当成能力增长

00:09:41.500 --> 00:09:43.933
模型反复接触同一批测试

00:09:44.200 --> 00:09:46.500
可能越来越擅长那批测试

00:09:46.800 --> 00:09:49.133
研究人员就算没有刻意作弊

00:09:49.366 --> 00:09:51.266
选择实验的习惯也可能

00:09:51.266 --> 00:09:53.333
让结果偏向既有指标

00:09:53.700 --> 00:09:56.566
检验新版本需要留出独立的任务

00:09:56.666 --> 00:09:59.100
还要观察其他能力有没有被牺牲

00:09:59.466 --> 00:10:00.733
局部得分提高

00:10:00.800 --> 00:10:02.866
不能自动推出全面提升

00:10:03.100 --> 00:10:05.766
研究循环也受现实资源限制

00:10:06.166 --> 00:10:08.266
提出一个训练方案很快

00:10:08.600 --> 00:10:10.400
完成训练需要计算

00:10:10.533 --> 00:10:12.600
某些实验必须等待结果

00:10:13.133 --> 00:10:15.166
失败以后还得重新安排

00:10:15.366 --> 00:10:18.066
涉及真实世界数据或者硬件时

00:10:18.133 --> 00:10:19.400
等待会更长

00:10:19.566 --> 00:10:21.266
模型帮助研究并不

00:10:21.266 --> 00:10:23.333
意味着这些资源限制消失

00:10:23.533 --> 00:10:25.266
递归过程有没有发生

00:10:25.266 --> 00:10:26.533
与它能不能无限

00:10:26.533 --> 00:10:28.600
加速是两个不同问题

00:10:28.700 --> 00:10:31.566
这并不减损carbon可能具有的价值

00:10:32.066 --> 00:10:33.733
即使它只是把研究人员

00:10:33.733 --> 00:10:35.966
处理复杂代码的时间缩短

00:10:36.100 --> 00:10:37.566
也已经值得关注

00:10:37.700 --> 00:10:39.266
一个工具每天节约

00:10:39.266 --> 00:10:41.166
少量高技能人员的时间

00:10:41.566 --> 00:10:43.733
积累起来就可能改变开发节奏

00:10:43.800 --> 00:10:45.400
这样的进步可以测量

00:10:45.500 --> 00:10:47.466
也可以讨论商业意义

00:10:47.700 --> 00:10:49.500
无需提前附送智能

00:10:49.500 --> 00:10:51.366
爆炸已经开始的结论

00:10:51.500 --> 00:10:53.333
谷歌还有一个独特条件

00:10:53.600 --> 00:10:55.066
它既研发模型

00:10:55.066 --> 00:10:57.600
也经营开发工具和办公产品

00:10:58.266 --> 00:11:00.500
模型如果能够稳定处理工作

00:11:00.533 --> 00:11:03.166
有机会通过这些入口触达用户

00:11:03.300 --> 00:11:05.100
不过入口优势不会

00:11:05.100 --> 00:11:06.766
自动变成使用习惯

00:11:07.000 --> 00:11:08.300
企业已经建立的

00:11:08.300 --> 00:11:10.466
审批流程和权限规则

00:11:10.666 --> 00:11:13.566
往往比换一个聊天窗口难改的多

00:11:13.600 --> 00:11:15.733
想象一个普通的企业需求

00:11:16.100 --> 00:11:18.533
要求代理汇总某个项目的进展

00:11:18.766 --> 00:11:21.133
资料分散在邮件和文档中

00:11:21.466 --> 00:11:23.900
部分内容只有特定成员能看

00:11:24.066 --> 00:11:27.200
系统要先确认提问者有权访问什么

00:11:27.300 --> 00:11:29.700
再判断哪些资料仍然有效

00:11:29.766 --> 00:11:31.900
最终输出还得说明依据

00:11:32.066 --> 00:11:33.533
回答文字写的顺

00:11:34.100 --> 00:11:36.000
不代表整个流程已经合格

00:11:36.133 --> 00:11:39.100
如果任务升级成直接更新项目状态

00:11:39.100 --> 00:11:40.500
要求又高了一层

00:11:41.066 --> 00:11:42.366
更新哪条记录

00:11:42.500 --> 00:11:44.100
是否会通知客户

00:11:44.466 --> 00:11:45.800
谁有权批准

00:11:45.866 --> 00:11:47.566
都需要被明确设置

00:11:47.800 --> 00:11:50.600
能力增强会扩大可执行的动作

00:11:51.166 --> 00:11:52.933
也会扩大错误的影响

00:11:53.133 --> 00:11:54.166
模型越强

00:11:54.366 --> 00:11:57.200
企业对边界的要求往往越具体

00:11:57.600 --> 00:12:00.666
不能靠一句更智能略过去

00:12:00.666 --> 00:12:03.366
这里就轮到微软decision一登场了

00:12:03.466 --> 00:12:05.066
它关注的任务更窄

00:12:05.166 --> 00:12:06.966
给定问题和备选项

00:12:07.000 --> 00:12:08.800
输出各个选项的概率

00:12:09.200 --> 00:12:10.500
微软把它定位在

00:12:10.500 --> 00:12:12.333
决策与分类工作负载

00:12:12.933 --> 00:12:15.366
基于千问3.59B做后训练

00:12:15.666 --> 00:12:17.800
它选择处理大量重复的判断

00:12:18.200 --> 00:12:20.766
不要求所有问题都交给最大模型

00:12:20.966 --> 00:12:23.966
微软公布的测试覆盖36个基准

00:12:23.966 --> 00:12:25.533
约15万道问题

00:12:25.566 --> 00:12:29.100
并报告了相对GPT6索尔的延迟优势

00:12:29.266 --> 00:12:32.133
这些是厂商提供的评估试用条件

00:12:32.166 --> 00:12:33.133
需要保留

00:12:33.500 --> 00:12:36.400
官方也介绍了对输入脑洞的测试

00:12:36.600 --> 00:12:38.700
他们值得关注的地方是把

00:12:38.700 --> 00:12:41.300
一致性和速度当成产品指标

00:12:41.300 --> 00:12:42.966
不能据此断言任何

00:12:42.966 --> 00:12:45.166
业务场景都能照搬结果

00:12:45.266 --> 00:12:47.133
这种模型能放在哪里

00:12:47.200 --> 00:12:49.266
客服系统收到一条请求

00:12:49.366 --> 00:12:51.900
可以判断应当交给哪个业务组

00:12:52.566 --> 00:12:54.466
代理生成一份答案之后

00:12:54.533 --> 00:12:57.333
也可以根据预设标准分类检查

00:12:57.500 --> 00:12:59.466
是否需要人工复核

00:12:59.866 --> 00:13:02.366
可以被设计成一个明确选项

00:13:02.533 --> 00:13:04.800
这些都是工作流的应用释义

00:13:04.966 --> 00:13:06.933
不等于相关企业已经

00:13:06.933 --> 00:13:08.500
部署了同样的流程

00:13:08.866 --> 00:13:09.766
最有意思的是

00:13:09.766 --> 00:13:12.800
这类系统未必需要写出一大段解释

00:13:13.200 --> 00:13:14.800
业务有时只需要一个

00:13:14.800 --> 00:13:16.600
格式稳定的选择结果

00:13:17.266 --> 00:13:19.366
输出越容易被程序读取

00:13:19.500 --> 00:13:21.700
后面的动作就越容易安排

00:13:21.933 --> 00:13:24.000
大模型擅长展开思路

00:13:24.066 --> 00:13:25.700
专用判断模型则可以把

00:13:25.700 --> 00:13:27.966
计算集中在有限选择上

00:13:28.200 --> 00:13:30.333
两种能力有机会组合起来

00:13:30.466 --> 00:13:31.800
服务同一个任务

00:13:31.800 --> 00:13:33.800
但概率必须谨慎解释

00:13:34.300 --> 00:13:37.500
某个选项显示90%不等于当前

00:13:37.500 --> 00:13:39.600
答案拿到了真实性担保

00:13:39.933 --> 00:13:41.766
校准讨论的是一批预测

00:13:41.766 --> 00:13:43.866
与实际结果之间的关系

00:13:44.066 --> 00:13:46.100
企业需要在自己的数据上

00:13:46.100 --> 00:13:48.266
检查这种关系是否成立

00:13:48.400 --> 00:13:49.866
业务变化之后

00:13:50.100 --> 00:13:51.766
原来可靠的概率

00:13:52.133 --> 00:13:54.766
也可能需要重新评估比如

00:13:55.000 --> 00:13:57.966
一个系统在普通咨询里表现稳定

00:13:58.266 --> 00:14:00.066
遇到新的诈骗话术

00:14:00.100 --> 00:14:01.566
判断可能失准

00:14:01.900 --> 00:14:03.866
输入很像熟悉的类别

00:14:04.100 --> 00:14:05.700
实际风险却不同

00:14:06.000 --> 00:14:08.900
如果流程把高分直接当成放行许可

00:14:09.100 --> 00:14:11.800
评分错误就会沿着自动化继续传播

00:14:11.966 --> 00:14:15.100
可靠的设计需要给陌生情况留出口

00:14:15.700 --> 00:14:18.333
包括拒绝判断或者交给人处理

00:14:18.333 --> 00:14:20.000
这也解释了为什么判断

00:14:20.000 --> 00:14:22.100
模型的选项设置很重要

00:14:22.366 --> 00:14:24.466
如果只给执行和不执行

00:14:24.600 --> 00:14:27.200
一些模糊情况会被硬塞进去

00:14:27.566 --> 00:14:30.066
增加信息不足可能更符合业务

00:14:30.066 --> 00:14:32.266
但新增选项之后还要

00:14:32.266 --> 00:14:34.266
测试它是不是过度回避

00:14:34.500 --> 00:14:37.333
企业需要按照错误代价设计流程

00:14:37.766 --> 00:14:40.700
不能只追求一个漂亮的平均准确率

00:14:40.733 --> 00:14:43.333
不同错误的代价可以相差很大

00:14:43.800 --> 00:14:46.533
把普通咨询错分到另一个客服组

00:14:46.666 --> 00:14:48.533
可能只是多等几分钟

00:14:49.000 --> 00:14:50.933
把需要人工审批的支付

00:14:50.933 --> 00:14:53.200
操作判断成可以自动执行

00:14:53.933 --> 00:14:55.500
后果就严重得多

00:14:55.666 --> 00:14:57.266
模型在两类任务上

00:14:57.266 --> 00:14:59.000
得到相似的正确率

00:14:59.133 --> 00:15:01.566
也不代表承担了相似的风险

00:15:02.266 --> 00:15:04.066
评估必须看错在哪里

00:15:04.200 --> 00:15:05.700
微软官方给decision

00:15:06.000 --> 00:15:08.000
一列出的输入价格很低

00:15:08.166 --> 00:15:09.700
输出不另行收费

00:15:09.900 --> 00:15:12.900
并区分了当前可用入口和后续计划

00:15:13.466 --> 00:15:14.933
这个定价值得讨论

00:15:14.966 --> 00:15:17.766
但它只是模型调用的一部分成本

00:15:17.966 --> 00:15:20.100
系统还需要连接业务数据

00:15:20.333 --> 00:15:21.300
维护规则

00:15:21.500 --> 00:15:22.500
保存日志

00:15:22.666 --> 00:15:23.666
出了问题

00:15:23.766 --> 00:15:25.333
团队还得有人处理

00:15:25.733 --> 00:15:27.600
低价分类可以节约预算

00:15:27.766 --> 00:15:29.666
不能让整个工程免费

00:15:29.900 --> 00:15:31.100
延迟同样如此

00:15:31.300 --> 00:15:33.600
一个判断步骤明显变快

00:15:33.666 --> 00:15:35.266
如果整条流程大部分

00:15:35.266 --> 00:15:36.933
时间都在等待数据库

00:15:37.200 --> 00:15:39.200
用户感受到的改善就有限

00:15:39.600 --> 00:15:42.366
业务负责人需要测端到端时间

00:15:42.466 --> 00:15:44.400
每个模型单独跑得快

00:15:44.533 --> 00:15:46.600
系统之间来回传输很慢

00:15:46.600 --> 00:15:48.733
最终体验还是可能卡住

00:15:49.133 --> 00:15:50.533
局部性能只有放进

00:15:50.533 --> 00:15:52.733
流程里才知道实际价值

00:15:52.800 --> 00:15:55.200
把carbon和decision e放到一起

00:15:55.500 --> 00:15:57.500
竞争路线就更清楚了

00:15:57.933 --> 00:15:59.266
carbon受到关注

00:15:59.333 --> 00:16:00.700
因为它可能承担更

00:16:00.700 --> 00:16:02.800
复杂的生成和编程工作

00:16:03.600 --> 00:16:05.333
decision e则试图把高频

00:16:05.333 --> 00:16:07.100
选择变得便宜而稳定

00:16:07.166 --> 00:16:08.766
一个工作流完全可以

00:16:08.766 --> 00:16:10.600
同时需要这两类能力

00:16:10.733 --> 00:16:12.600
再让人保留重要审批

00:16:13.166 --> 00:16:15.100
企业采购的对象正在

00:16:15.100 --> 00:16:17.266
变成一整套任务完成方案

00:16:17.500 --> 00:16:19.133
模型之间怎样分工

00:16:19.133 --> 00:16:20.666
也会带来新的问题

00:16:20.966 --> 00:16:22.566
分类系统把任务分错

00:16:22.600 --> 00:16:25.166
大模型可能认真解决了错误的问题

00:16:25.200 --> 00:16:27.200
大模型输出的信息不完整

00:16:27.300 --> 00:16:30.766
后续评分也可能建立在缺失材料上

00:16:30.766 --> 00:16:32.400
多个组件串联之后

00:16:32.400 --> 00:16:33.900
责任必须能追溯

00:16:34.133 --> 00:16:37.100
系统应该记录每个阶段看到了什么

00:16:37.100 --> 00:16:38.400
做出了什么选择

00:16:38.566 --> 00:16:40.766
这类记录还有一个实际用途

00:16:41.066 --> 00:16:43.500
帮助团队判断应该升级哪一部分

00:16:43.900 --> 00:16:45.466
失败发生在检索

00:16:45.533 --> 00:16:47.866
就不该盲目换更贵的模型

00:16:48.533 --> 00:16:49.700
规则写的模糊

00:16:49.800 --> 00:16:51.366
就应该先修规则

00:16:51.600 --> 00:16:54.133
只有确实属于能力不足的任务

00:16:54.366 --> 00:16:56.200
升级模型才可能解决

00:16:56.300 --> 00:16:57.733
没有分阶段记录

00:16:58.166 --> 00:16:59.533
所有问题都会被归结

00:16:59.533 --> 00:17:01.600
成一句AI还不够强

00:17:01.666 --> 00:17:04.300
企业可以先选一个范围有限的任务

00:17:04.666 --> 00:17:06.500
保留原流程作为对照

00:17:07.200 --> 00:17:08.900
评价标准提前确定

00:17:08.966 --> 00:17:10.466
既记录完成时间

00:17:10.466 --> 00:17:12.100
也记录返工和错误

00:17:12.200 --> 00:17:13.366
这样做看起来没有

00:17:13.366 --> 00:17:14.933
全面上线那么热闹

00:17:15.133 --> 00:17:17.566
却更容易判断投入有没有回报

00:17:17.666 --> 00:17:18.966
任务边界清楚

00:17:19.166 --> 00:17:20.866
失败也更容易回滚

00:17:21.166 --> 00:17:23.733
团队能够积累真正有用的经验

00:17:23.933 --> 00:17:26.500
对照测试还要防止选择偏差

00:17:27.066 --> 00:17:29.733
员工往往把容易的任务交给AI

00:17:29.966 --> 00:17:31.900
把复杂任务留给自己

00:17:32.166 --> 00:17:33.733
最后看使用记录

00:17:34.000 --> 00:17:35.566
AI完成率很高

00:17:35.766 --> 00:17:37.266
人类耗时很长

00:17:37.300 --> 00:17:38.900
比较就已经不公平

00:17:39.200 --> 00:17:41.500
不同任务的难度必须被考虑

00:17:41.666 --> 00:17:44.200
否则一套未经校正的报表就

00:17:44.200 --> 00:17:46.300
可能推动错误的用工决定

00:17:46.500 --> 00:17:48.400
模型更新后也要重测

00:17:48.866 --> 00:17:51.700
企业可能喜欢新版本的总体表现

00:17:51.900 --> 00:17:54.666
却发现某个关键分类变差了

00:17:54.733 --> 00:17:56.400
如果自动切换版本

00:17:56.400 --> 00:17:58.533
没有复核就继续运行

00:17:58.866 --> 00:18:01.533
原先建立的流程可能悄悄失效

00:18:01.800 --> 00:18:04.333
稳定的模型服务需要版本管理

00:18:04.766 --> 00:18:08.000
重要任务还要允许暂时保留旧版本

00:18:08.333 --> 00:18:10.766
更新速度和部署速度可以不同

00:18:10.866 --> 00:18:13.333
成本评估也应覆盖失败的任务

00:18:13.866 --> 00:18:16.166
只算成功那一次的调用费用

00:18:16.266 --> 00:18:17.866
会漏掉之前的重试

00:18:18.166 --> 00:18:19.600
只算生成速度

00:18:19.733 --> 00:18:21.333
会漏掉人工检查

00:18:21.566 --> 00:18:23.066
团队需要知道

00:18:23.300 --> 00:18:26.200
完成一个合格任务总共花了多少钱

00:18:26.300 --> 00:18:28.733
发生严重错误的频率是多少

00:18:28.766 --> 00:18:29.933
这两个数字

00:18:30.600 --> 00:18:31.766
比每秒生成多少

00:18:31.766 --> 00:18:33.700
文字更接近商业决策

00:18:33.900 --> 00:18:37.100
这也是卡本后续最值得观察的方向

00:18:37.900 --> 00:18:39.566
公开测试如果出现

00:18:39.600 --> 00:18:42.400
应该看任务是否覆盖真实仓库

00:18:43.066 --> 00:18:44.700
测试条件是否一致

00:18:44.866 --> 00:18:46.766
失败记录是否完整

00:18:47.100 --> 00:18:48.200
产品如果上线

00:18:48.200 --> 00:18:50.066
应该看普通付费用户

00:18:50.100 --> 00:18:51.566
能够获得什么条件

00:18:51.700 --> 00:18:53.900
内部员工的惊喜很有吸引力

00:18:54.066 --> 00:18:55.366
可持续的服务体验

00:18:55.366 --> 00:18:56.800
才会决定市场位置

00:18:56.966 --> 00:18:59.100
还有一个会影响采购的因素

00:18:59.333 --> 00:19:01.366
任务到底由谁定义完成

00:19:02.100 --> 00:19:04.300
编程测试通常有预设目标

00:19:04.533 --> 00:19:06.566
企业请求却可能很模糊

00:19:06.766 --> 00:19:08.700
客户说希望页面更快

00:19:08.733 --> 00:19:10.300
可能指加载时间

00:19:10.366 --> 00:19:12.500
也可能指操作步骤太多

00:19:12.666 --> 00:19:14.300
模型直接优化代码

00:19:14.333 --> 00:19:16.733
未必解决客户最在意的问题

00:19:17.400 --> 00:19:19.766
复杂任务需要先确认目标

00:19:19.966 --> 00:19:22.100
随后才适合自动执行

00:19:22.166 --> 00:19:24.133
需求澄清也可以被评估

00:19:24.300 --> 00:19:26.400
系统能否识别缺失条件

00:19:26.466 --> 00:19:28.266
能否只问必要的问题

00:19:28.333 --> 00:19:30.000
都会影响合作体验

00:19:30.100 --> 00:19:31.800
每一步都要求人确认

00:19:31.900 --> 00:19:33.066
效率上不去

00:19:33.066 --> 00:19:33.933
什么都不问

00:19:33.933 --> 00:19:35.066
又容易走偏

00:19:35.333 --> 00:19:37.866
企业需要寻找合适的询问频率

00:19:37.866 --> 00:19:40.333
并按任务风险设置不同阈值

00:19:40.733 --> 00:19:42.333
这个问题通常比聊天

00:19:42.333 --> 00:19:44.366
回答是否自然更难处理

00:19:44.566 --> 00:19:46.533
长任务还会跨越时间

00:19:47.100 --> 00:19:48.866
代理今天拿到的资料

00:19:48.900 --> 00:19:50.400
明天可能被更新

00:19:51.166 --> 00:19:52.866
用户中途改变要求

00:19:53.000 --> 00:19:55.500
他得知道哪些工作可以保留

00:19:55.500 --> 00:19:56.666
哪些已经作废

00:19:56.933 --> 00:19:59.466
如果系统继续沿着旧目标执行

00:19:59.866 --> 00:20:02.333
能力再强也只是更快的做错事

00:20:02.400 --> 00:20:04.200
保存工作状态的同时

00:20:04.200 --> 00:20:06.133
还要允许目标发生变化

00:20:06.266 --> 00:20:08.500
这是长期运行的实际要求

00:20:08.600 --> 00:20:10.000
任务中断之后能否

00:20:10.000 --> 00:20:12.100
恢复也值得单独测试

00:20:12.700 --> 00:20:13.966
网路暂时断开

00:20:13.966 --> 00:20:16.200
已经完成的步骤是否会重复

00:20:16.400 --> 00:20:18.133
一项操作已经提交

00:20:18.133 --> 00:20:20.200
但确认消息没有返回

00:20:20.400 --> 00:20:22.366
代理会不会再提交一次

00:20:22.400 --> 00:20:24.066
这些情况在演示中很少

00:20:24.066 --> 00:20:26.766
出现在真实服务里却躲不开

00:20:27.366 --> 00:20:28.900
恢复机制做不好

00:20:29.133 --> 00:20:30.566
自动化就可能制造

00:20:30.566 --> 00:20:32.666
重复订单或者重复修改

00:20:32.766 --> 00:20:33.966
在这些问题上

00:20:33.966 --> 00:20:36.966
模型不一定需要独自解决所有细节

00:20:37.933 --> 00:20:39.900
应用可以记录操作状态

00:20:40.000 --> 00:20:41.300
阻止重复提交

00:20:41.300 --> 00:20:43.000
再让模型决定下一步

00:20:43.300 --> 00:20:45.866
确定性的程序负责确定性的约束

00:20:46.400 --> 00:20:49.100
模型处理需要理解和选择的部分

00:20:49.300 --> 00:20:51.533
企业能够把两者结合的多好

00:20:51.933 --> 00:20:53.466
会直接影响carbon这类

00:20:53.466 --> 00:20:55.366
强模型能发挥多少价值

00:20:55.566 --> 00:20:57.166
数据保密则决定哪些

00:20:57.166 --> 00:20:59.266
任务根本不能随意交出去

00:20:59.400 --> 00:21:01.766
代码仓库里可能包含商业逻辑

00:21:02.100 --> 00:21:03.966
文档里可能有客户信息

00:21:04.200 --> 00:21:06.100
企业选择模型需要查清

00:21:06.100 --> 00:21:08.333
数据保存方式和服务条款

00:21:08.733 --> 00:21:11.266
模型路由经过不同供应商时

00:21:11.300 --> 00:21:13.133
也要确认资料流向

00:21:13.366 --> 00:21:15.266
使用效果相似的两个服务

00:21:15.466 --> 00:21:17.333
合规条件可能完全不同

00:21:17.466 --> 00:21:19.600
由此还会出现迁移成本

00:21:20.100 --> 00:21:21.966
一个团队围绕某个模型

00:21:21.966 --> 00:21:24.166
调好了提示和评分规则

00:21:24.466 --> 00:21:26.766
换模型之后未必照样有效

00:21:26.966 --> 00:21:28.766
输出格式稍有变化

00:21:28.766 --> 00:21:30.800
下游程序就可能出错

00:21:30.966 --> 00:21:33.466
企业可以保留共同的任务接口

00:21:33.900 --> 00:21:35.800
再为不同模型做适配

00:21:35.933 --> 00:21:38.333
这样以后选择carbon或者其他候选

00:21:38.333 --> 00:21:41.266
服务才不至于重新搭建整个流程

00:21:41.400 --> 00:21:43.300
比较时也应该避免只

00:21:43.300 --> 00:21:44.766
挑自己擅长的任务

00:21:45.000 --> 00:21:47.533
一家模型擅长从零搭建页面

00:21:47.600 --> 00:21:49.800
另一家擅长修复旧项目

00:21:49.933 --> 00:21:52.333
两者都可以展示出经验结果

00:21:52.533 --> 00:21:54.166
采购方需要按照真实

00:21:54.166 --> 00:21:56.100
任务占比构建测试集

00:21:56.300 --> 00:21:59.100
很少遇到的高难问题可以单独关注

00:21:59.200 --> 00:22:01.866
不能让它完全代表日常使用成本

00:22:01.900 --> 00:22:04.600
还有用户经常忽略的等待分布

00:22:05.400 --> 00:22:06.866
平均耗时不错

00:22:06.900 --> 00:22:08.200
偶尔卡住很久

00:22:08.200 --> 00:22:10.066
同样会破坏工作安排

00:22:10.766 --> 00:22:14.133
客服和实时业务尤其需要看慢请求

00:22:14.333 --> 00:22:17.000
研究型任务能够容忍更长等待

00:22:17.100 --> 00:22:18.266
标准又不同

00:22:18.300 --> 00:22:20.700
用一个平均延迟比较所有产品

00:22:21.100 --> 00:22:23.900
很容易选出对业务并不合适的模型

00:22:24.300 --> 00:22:26.166
decision一这类模型的机会

00:22:26.166 --> 00:22:28.266
就来自任务需求的差别

00:22:28.666 --> 00:22:31.533
高频而简单的分类可以单独处理

00:22:31.800 --> 00:22:34.166
把昂贵计算留给复杂部分

00:22:34.733 --> 00:22:37.000
但路由系统自身也需要观察

00:22:37.000 --> 00:22:38.900
不能为了省一笔调用费

00:22:38.933 --> 00:22:40.933
让后面产生更多返工

00:22:41.200 --> 00:22:43.333
模型组合的价值应当

00:22:43.333 --> 00:22:46.100
体现为合格交付成本下降

00:22:46.266 --> 00:22:48.600
不能只体现在某个组件便宜

00:22:48.733 --> 00:22:50.400
对个人开发者同样

00:22:50.400 --> 00:22:52.133
可以用较小的方式验证

00:22:52.900 --> 00:22:55.566
选一批已经知道解决方法的旧问题

00:22:55.900 --> 00:22:56.800
隐藏答案

00:22:56.866 --> 00:22:58.600
让新工具独立尝试

00:22:58.733 --> 00:23:01.366
比较它使用的时间和修改范围

00:23:01.500 --> 00:23:03.533
再检查有没有新增问题

00:23:03.733 --> 00:23:06.266
这样的测试无法替代专业基准

00:23:06.500 --> 00:23:08.466
却能帮助判断新工具

00:23:08.466 --> 00:23:10.366
是否适合手上的项目

00:23:10.966 --> 00:23:13.700
减少仅凭宣传切换工具的成本

00:23:13.900 --> 00:23:15.200
网络安全相关能力

00:23:15.200 --> 00:23:16.533
还需要额外的边界

00:23:16.966 --> 00:23:19.166
模型能够发现复杂软件问题

00:23:19.300 --> 00:23:21.533
对防御工作可能很有帮助

00:23:21.866 --> 00:23:23.100
但使用者身份和

00:23:23.100 --> 00:23:24.966
操作权限必须被检查

00:23:25.266 --> 00:23:28.166
授权研究与未经许可的操作不能

00:23:28.166 --> 00:23:30.933
因为同样调用一个模型就混在一起

00:23:31.066 --> 00:23:33.300
安全发布的难点也包括让

00:23:33.300 --> 00:23:35.666
有益能力进入正确的工作流程

00:23:35.800 --> 00:23:38.266
把所有能力封成一个聊天窗口

00:23:38.600 --> 00:23:40.766
用户可能很难察觉这些差别

00:23:40.966 --> 00:23:43.866
企业却必须知道哪些动作只是建议

00:23:44.000 --> 00:23:45.933
哪些动作真的改变系统

00:23:45.966 --> 00:23:48.300
一次代码审查可以人工确认

00:23:48.533 --> 00:23:50.400
一次生产配置修改则

00:23:50.400 --> 00:23:51.966
需要更严格的审批

00:23:52.400 --> 00:23:54.300
产品越接近实际执行

00:23:54.400 --> 00:23:57.466
界面上越应该清楚的展示动作范围

00:23:57.666 --> 00:23:59.266
未来的竞争也就不会

00:23:59.266 --> 00:24:01.133
只停留在模型排行榜

00:24:01.666 --> 00:24:04.466
模型厂商需要证明复杂任务的能力

00:24:04.600 --> 00:24:07.200
工具平台需要证明连接可靠

00:24:07.500 --> 00:24:08.733
企业则要证明

00:24:08.733 --> 00:24:10.966
自动化确实节约总成本

00:24:11.166 --> 00:24:12.600
任何一环跟不上

00:24:12.966 --> 00:24:14.466
都可能让看起来领先

00:24:14.466 --> 00:24:16.500
的技术停在演示阶段

00:24:16.666 --> 00:24:18.666
这个过程没有统一的捷径

00:24:18.800 --> 00:24:21.000
只能靠连续的部署和复合

00:24:21.300 --> 00:24:24.666
carbon目前最重要的信号是谷歌内部

00:24:24.666 --> 00:24:27.700
的编程候选模型正在获得积极反馈

00:24:28.100 --> 00:24:29.600
这个信号值得追踪

00:24:29.766 --> 00:24:32.533
却不足以写成全面领先的事实

00:24:32.800 --> 00:24:34.600
微软decision亦提供了

00:24:34.600 --> 00:24:36.000
另一个观察角度

00:24:36.333 --> 00:24:39.533
AI产品还在向具体判断任务细分

00:24:39.700 --> 00:24:42.366
规模和专用化都可能带来价值

00:24:42.533 --> 00:24:44.966
最终要接受同一套业务验收

00:24:45.200 --> 00:24:46.566
开头的问题现在可以

00:24:46.566 --> 00:24:48.333
落到一个明确标准上

00:24:48.466 --> 00:24:51.066
企业离放心交出工作还有距离

00:24:51.100 --> 00:24:53.166
因为交付涉及连续判断

00:24:53.300 --> 00:24:55.133
而且错误有真实代价

00:24:55.500 --> 00:24:57.933
carbon如果确实是个强大的新模型

00:24:58.133 --> 00:25:00.966
最有说服力的证明就是帮助用户

00:25:00.966 --> 00:25:03.900
在可承受的成本下完成合格任务

00:25:04.166 --> 00:25:05.166
能被复核

00:25:05.200 --> 00:25:06.166
能被回滚

00:25:06.500 --> 00:25:08.300
下一次还能稳定做对

00:25:08.300 --> 00:25:10.200
这样的进步才会留在账上