1
00:00:00,000 --> 00:00:02,300
你有没有过这种很无力的经验?

2
00:00:02,300 --> 00:00:05,000
叫AI帮你整理一份跨部门的会议报告。

3
00:00:05,000 --> 00:00:09,300
做到一半它忘了你要求的章节格式,用语音助手查形成。

4
00:00:09,300 --> 00:00:13,700
旁边同事插句话,它就把指令听成完全不相干的内容。

5
00:00:13,700 --> 00:00:20,500
只要任务超过三个步骤,需要跨两个以上工具,最后交付的结果一定歪掉大半。

6
00:00:20,500 --> 00:00:27,500
你大概也听过很多人说AI已经很聪明了,但真的拿来干活,总是卡在这些最不起眼的小地方。

7
00:00:27,500 --> 00:00:29,980
2026年9月的头两天

8
00:00:29,980 --> 00:00:32,400
Meta接连丢出了两项更新

9
00:00:32,400 --> 00:00:34,840
没有吹什么通用人工智能的牛皮

10
00:00:34,840 --> 00:00:38,480
却精准踩中了这些大家天天吐槽的痛点

11
00:00:38,480 --> 00:00:41,760
一个负责把真实世界里的声音听得更清楚

12
00:00:41,760 --> 00:00:44,780
一个负责把复杂的常任务做得更稳

13
00:00:44,780 --> 00:00:48,720
有人看完数据说Meta终于要在代理人战场超车了

14
00:00:48,720 --> 00:00:50,420
也有人冷静算完成本

15
00:00:50,420 --> 00:00:52,540
发现事情根本没有这么简单

16
00:00:52,540 --> 00:00:54,180
今天我们就不吹不黑

17
00:00:54,180 --> 00:00:57,220
把官方技术文件第三方独立评测

18
00:00:57,220 --> 00:01:00,140
还有那些藏在角落的小字限制

19
00:01:00,140 --> 00:01:01,840
全部摊开来讲

20
00:01:01,840 --> 00:01:04,620
看看这两款产品到底走到了哪一步

21
00:01:04,620 --> 00:01:07,300
又有哪些东西是营销不会告诉你的

22
00:01:07,300 --> 00:01:08,860
我们不从结论讲起

23
00:01:08,860 --> 00:01:12,280
因为真正有价值的判断往往都藏在每一个

24
00:01:12,280 --> 00:01:13,380
但是后面

25
00:01:13,380 --> 00:01:17,300
先帮大家把最容易搞混的产品线界限画清楚

26
00:01:17,300 --> 00:01:20,100
这也是很多自媒体最常讲错的地方

27
00:01:20,100 --> 00:01:24,160
9月1日登场的是Muse Voice Transcribe语音转写模型

28
00:01:24,160 --> 00:01:28,160
9月2日接棒上线的是Muse Spark 1.3代理人模型

29
00:01:28,160 --> 00:01:30,560
两天连续发布核心产品

30
00:01:30,560 --> 00:01:34,340
这在Meta Superintelligence Labs的历史上并不常见

31
00:01:34,340 --> 00:01:38,520
也能看出他们在2026年下半年的竞争焦虑

32
00:01:38,520 --> 00:01:39,500
但更重要的是

33
00:01:39,500 --> 00:01:41,780
很多人到现在还搞不清楚

34
00:01:41,780 --> 00:01:43,960
Muse Spark和Muse Glimmer

35
00:01:43,960 --> 00:01:46,860
根本是两条完全不同的路线

36
00:01:46,860 --> 00:01:48,180
不能混为一谈

37
00:01:48,180 --> 00:01:51,280
Muse Spark走的是云端前沿代理人路线

38
00:01:51,280 --> 00:01:52,720
权重完全必圆

39
00:01:52,720 --> 00:01:54,820
目前只开放API呼叫

40
00:01:54,820 --> 00:01:57,560
官方只说未来有开放权重的规划

41
00:01:57,560 --> 00:01:59,000
但既没有时间表

42
00:01:59,000 --> 00:02:01,280
也没说会用哪种授权条款

43
00:02:01,280 --> 00:02:03,420
所以你绝对不能把它理解成

44
00:02:03,420 --> 00:02:05,700
马上就可以下载来本地跑

45
00:02:05,700 --> 00:02:08,540
而Muse Glimmer是拥有300亿参数

46
00:02:08,540 --> 00:02:11,860
采用Apache 2.0授权的本地方案

47
00:02:11,860 --> 00:02:14,140
主打消费级显示卡就能执行

48
00:02:14,140 --> 00:02:14,780
讲白一点

49
00:02:14,780 --> 00:02:17,100
Spark负责把能力堆到最高

50
00:02:17,100 --> 00:02:19,680
强企业级和高端开发者市场

51
00:02:19,680 --> 00:02:21,840
Glimmer负责把能力扑到最广

52
00:02:21,840 --> 00:02:24,100
占领开源生态和终端装置

53
00:02:24,100 --> 00:02:28,680
这种双轨策略其实刚好对应了Meta在AI产业的定位转变

54
00:02:28,680 --> 00:02:33,400
前几年大家提到Meta的AI第一个想到的就是Lama系列开源模型

55
00:02:33,400 --> 00:02:34,960
靠免费打天下

56
00:02:34,960 --> 00:02:37,980
跟OpenAI的全B原路线正面抗衡

57
00:02:37,980 --> 00:02:40,060
但到了2026年

58
00:02:40,060 --> 00:02:43,760
整个行业的竞争已经从比参数 比跑分

59
00:02:43,760 --> 00:02:46,900
进到比代理人 比落地场景的阶段

60
00:02:46,900 --> 00:02:50,140
Meta必须拿出足够强的B原顶端产品

61
00:02:50,140 --> 00:02:51,600
才能跟GPT系列

62
00:02:51,600 --> 00:02:53,700
Gemini系列抢商业客户

63
00:02:53,700 --> 00:02:56,760
同时又不能丢掉开源生态的优势

64
00:02:56,760 --> 00:02:59,240
为什么要花这么多时间讲这件事

65
00:02:59,240 --> 00:03:00,540
因为如果你误以为

66
00:03:00,540 --> 00:03:02,580
Spark 1.3是开源模型

67
00:03:02,580 --> 00:03:04,660
就会产生错误的部署预期

68
00:03:04,660 --> 00:03:08,220
如果你以为Glimmer只是Spark的缩小版

69
00:03:08,220 --> 00:03:11,700
就会低估两者在设计目标上的根本差异

70
00:03:11,700 --> 00:03:13,160
另外从迭代节奏来看

71
00:03:13,160 --> 00:03:15,500
Muse系列从7月的1.1版

72
00:03:15,500 --> 00:03:17,360
首次连上邮件行事例

73
00:03:17,360 --> 00:03:23,160
并能制作投影片到8月初1.2版聚焦大型程式库与复杂真错

74
00:03:23,160 --> 00:03:25,700
甚至能连续1000多次工具呼叫

75
00:03:25,700 --> 00:03:30,260
在24小时内反复编写编译GPU核心程式

76
00:03:30,260 --> 00:03:33,600
8月中再加入图像与视频理解能力

77
00:03:33,600 --> 00:03:37,140
到9月的1.3版转向打磨长期任务的可用性

78
00:03:37,140 --> 00:03:40,500
几乎保持每个月一次大版本更新的速度

79
00:03:40,500 --> 00:03:43,000
这种快速迭代在AI圈不算稀奇

80
00:03:43,000 --> 00:03:47,680
但难得的是Meta几乎每一版都会附上明确的内部对比数据

81
00:03:47,680 --> 00:03:49,960
同时引用第三方评测结果

82
00:03:49,960 --> 00:03:52,880
给了外界一个相对透明的观察窗口

83
00:03:52,880 --> 00:03:55,220
很多人只盯着分数涨了多少

84
00:03:55,220 --> 00:03:58,020
却忽略了每一代版本的定位差异

85
00:03:58,020 --> 00:04:02,200
Spark 1.3并不是全面碾压1.2的终极进化

86
00:04:02,200 --> 00:04:05,600
而是针对代理人任务的可靠性做了针对性强化

87
00:04:05,600 --> 00:04:09,420
甚至在部分涨上下文指标上还出现了小幅退步

88
00:04:09,420 --> 00:04:11,240
这种有得有失的升级

89
00:04:11,240 --> 00:04:14,860
恰恰说明模型能力不是简单的线性叠加

90
00:04:14,860 --> 00:04:17,660
而是一连串的取舍与权衡

91
00:04:17,660 --> 00:04:19,960
如果你只看营销文案里的亮点

92
00:04:19,960 --> 00:04:23,140
很快就会在实际使用中发现落差

93
00:04:23,140 --> 00:04:25,500
如果你翻完这次的全部技术文件

94
00:04:25,500 --> 00:04:27,400
会发现最核心的关键词

95
00:04:27,400 --> 00:04:28,760
不是更高的分数

96
00:04:28,760 --> 00:04:30,280
也不是更多的参数

97
00:04:30,280 --> 00:04:32,300
而是长任务代理人

98
00:04:32,300 --> 00:04:33,440
什么意思

99
00:04:33,440 --> 00:04:36,500
就是让AI不再只是一次性回答一个问题

100
00:04:36,500 --> 00:04:39,160
而是像一个真正的执行助理一样

101
00:04:39,160 --> 00:04:41,220
接下一个模糊的需求

102
00:04:41,220 --> 00:04:43,480
自己拆解步骤 呼叫工具

103
00:04:43,480 --> 00:04:44,880
遇到问题回头问你

104
00:04:44,880 --> 00:04:46,100
碰到危险操作

105
00:04:46,100 --> 00:04:49,380
先停下来确认最后再交付完整的成果

106
00:04:49,380 --> 00:04:50,480
这听起来很美好

107
00:04:50,480 --> 00:04:53,680
但过去大部分代理人模型的问题无非三种

108
00:04:53,680 --> 00:04:55,880
要么不敢动手只会空泛回答

109
00:04:55,880 --> 00:04:58,680
要么乱动手做到一半偏离目标

110
00:04:58,680 --> 00:05:02,000
更常见的是干到一半彻底忘了最原始的要求

111
00:05:02,000 --> 00:05:05,020
Spark 1.3就是冲着这些痛点做的优化

112
00:05:05,020 --> 00:05:06,460
举个很实际的场景

113
00:05:06,460 --> 00:05:07,620
如果你跟模型说

114
00:05:07,620 --> 00:05:10,520
帮我整理上礼拜的三场客户会议记录

115
00:05:10,520 --> 00:05:11,800
做成部门简报

116
00:05:11,800 --> 00:05:14,120
把每个客户的行动项列出来

117
00:05:14,120 --> 00:05:15,440
最后寄给主管

118
00:05:15,440 --> 00:05:16,680
换做之前的模型

119
00:05:16,680 --> 00:05:19,780
很可能做到一半就忘了要按客户分类

120
00:05:19,780 --> 00:05:21,800
或者漏了寄信的步骤

121
00:05:21,800 --> 00:05:24,980
甚至为了凑数编造几个不存在的行动项

122
00:05:24,980 --> 00:05:27,920
而Spark 1.3的处理逻辑会完全不同

123
00:05:27,920 --> 00:05:30,280
一开始如果觉得需求不够清楚

124
00:05:30,280 --> 00:05:31,920
它会主动追问你

125
00:05:31,920 --> 00:05:34,800
简报要的是正式版本还是讨论版

126
00:05:34,800 --> 00:05:37,500
行动项要不要加上预计完成时间

127
00:05:37,500 --> 00:05:40,440
寄信的时候要不要附上原始记录档

128
00:05:40,440 --> 00:05:44,660
执行过程中如果发现某份会议记录打不开或者权限不足

129
00:05:44,660 --> 00:05:46,580
它会停下来跟你要资讯

130
00:05:46,580 --> 00:05:49,160
而不是硬着头皮编一个结果

131
00:05:49,160 --> 00:05:50,460
如果碰到删除档案

132
00:05:50,460 --> 00:05:51,640
发送批量邮件

133
00:05:51,640 --> 00:05:55,080
修改正式环境设定这类有不可逆风险的操作

134
00:05:55,080 --> 00:05:57,020
它一定会先跳出确认

135
00:05:57,020 --> 00:05:58,480
问你确定要执行吗

136
00:05:58,480 --> 00:05:59,980
不会自己直接动手

137
00:05:59,980 --> 00:06:00,880
更重要的是

138
00:06:00,880 --> 00:06:04,180
它能分辨你现在是在补充当前任务的资讯

139
00:06:04,180 --> 00:06:06,600
还是要打断手头的事做别的

140
00:06:06,600 --> 00:06:09,380
又或者是要开启一个全新的任务

141
00:06:09,380 --> 00:06:21,480
这听起来好像是基础能力,但在多轮对话里,很多模型会把用户随口的插画当成新指令,直接把之前的上下文全部覆盖掉,导致任务做到一半就断了。

142
00:06:21,480 --> 00:06:28,000
针对长期任务最常见的约束遗忘问题,Spark 1.3也做了专门强化。

143
00:06:28,000 --> 00:06:29,600
比如你一开始就说过

144
00:06:29,600 --> 00:06:31,880
所有输出都要用正体中文

145
00:06:31,880 --> 00:06:33,520
不能用外部图片素材

146
00:06:33,520 --> 00:06:35,400
数据不能超过指定范围

147
00:06:35,400 --> 00:06:37,160
他会在整个执行过程中

148
00:06:37,160 --> 00:06:38,760
反复检查这些条件

149
00:06:38,760 --> 00:06:41,380
而不是跑个五六步之后就全忘了

150
00:06:41,380 --> 00:06:42,440
最关键的一点

151
00:06:42,440 --> 00:06:44,920
是他对自身能力边界的判断

152
00:06:44,920 --> 00:06:46,400
过去很多代理人模型

153
00:06:46,400 --> 00:06:47,420
最危险的习惯

154
00:06:47,420 --> 00:06:48,880
就是任务做不完的时候

155
00:06:48,880 --> 00:06:50,120
会假装做完了

156
00:06:50,120 --> 00:06:51,260
然后生成一份

157
00:06:51,260 --> 00:06:52,860
看起来很完整的报告

158
00:06:52,860 --> 00:06:55,400
里面全是编造的数据和结论

159
00:06:55,400 --> 00:06:57,220
普通用户根本看不出来

160
00:06:57,220 --> 00:07:01,260
Bug1.3在训练时特别强化了这点遇到做不到的地方

161
00:07:01,260 --> 00:07:02,860
他更倾向于直接说

162
00:07:02,860 --> 00:07:04,160
我卡在这里了

163
00:07:04,160 --> 00:07:05,500
我缺少这个资讯

164
00:07:05,500 --> 00:07:09,240
而不是硬凑出一份看似完美的答案

165
00:07:09,240 --> 00:07:12,060
Meta内部工程师对比1.2版本后发现

166
00:07:12,060 --> 00:07:15,820
新版本平均减少了20%的工具呼叫次数

167
00:07:15,820 --> 00:07:18,880
同时减少了25%的token消耗

168
00:07:18,880 --> 00:07:21,340
这两个数字其实比跑分更有意义

169
00:07:21,340 --> 00:07:24,020
工具呼叫减少代表模型更清楚

170
00:07:24,020 --> 00:07:25,740
什么时候该用什么工具

171
00:07:25,740 --> 00:07:28,580
不会无脑尝试所有选项来回绕路

172
00:07:28,580 --> 00:07:30,000
Token消耗减少

173
00:07:30,000 --> 00:07:31,680
代表推理效率提升

174
00:07:31,680 --> 00:07:33,840
单位任务的成本直接下降

175
00:07:33,840 --> 00:07:35,880
很多人不知道代理人任务的成本

176
00:07:35,880 --> 00:07:38,300
通常是纯问答的3到5倍

177
00:07:38,300 --> 00:07:40,120
因为要不断多轮推理

178
00:07:40,120 --> 00:07:41,800
呼叫工具修正路线

179
00:07:41,800 --> 00:07:43,080
所以效率的提升

180
00:07:43,080 --> 00:07:44,520
直接决定了这项技术

181
00:07:44,520 --> 00:07:46,220
能不能大规模商业化

182
00:07:46,220 --> 00:07:47,380
不过也要说清楚

183
00:07:47,380 --> 00:07:50,900
这两个数字是Meta内部测试场景下的结果

184
00:07:50,900 --> 00:07:52,880
不是第三方独立评测

185
00:07:52,880 --> 00:07:55,260
实际业务中因为场景更复杂

186
00:07:55,260 --> 00:07:57,340
不一定能复现同样的比例

187
00:07:57,340 --> 00:08:00,000
官方也举了几个典型的常任务场景

188
00:08:00,000 --> 00:08:12,980
官方也举了几个典型的常任务场景,比如工程领域的CAD模型搭配流体模拟数据。最后按指定章节输出PDF报告,音乐制作领域根据时间码定位错误音符,从重复段落里挑出合适的替代片段。

189
00:08:12,980 --> 00:08:14,920
保持所有音轨长度不变

190
00:08:14,920 --> 00:08:16,040
再重新混音

191
00:08:16,040 --> 00:08:18,640
这些场景的共同点就是步骤多

192
00:08:18,640 --> 00:08:19,840
中间产物多

193
00:08:19,840 --> 00:08:21,400
需要跨工具协作

194
00:08:21,400 --> 00:08:23,860
差一步整个结果就不能用

195
00:08:23,860 --> 00:08:24,940
从这个角度看

196
00:08:24,940 --> 00:08:28,540
Spark 1.3根本不是一个聊天更厉害的模型

197
00:08:28,540 --> 00:08:30,720
而是一个干活更稳的模型

198
00:08:30,720 --> 00:08:33,580
它的评价标准早就不是会不会写诗

199
00:08:33,580 --> 00:08:34,940
能不能解数学题

200
00:08:34,940 --> 00:08:36,960
而是能不能在100步之后

201
00:08:36,960 --> 00:08:38,780
还不偏离最初的目标

202
00:08:38,780 --> 00:08:40,580
聊完了官方自己讲的升级

203
00:08:40,580 --> 00:08:43,220
我们来看看第三方独立评测的数据

204
00:08:43,220 --> 00:08:46,300
验证一下这些能力到底有没有落到实处

205
00:08:46,300 --> 00:08:48,880
这次的数据全部来自Artificial Analysis

206
00:08:48,880 --> 00:08:52,800
这是目前业界专门做代理人模型评测的独立机构

207
00:08:52,800 --> 00:08:54,400
不是Meta自己跑的分

208
00:08:54,400 --> 00:08:56,120
参考价值相对高一些

209
00:08:56,120 --> 00:08:58,760
在他们的综合智慧指数榜单上

210
00:08:58,760 --> 00:09:02,140
Spark 1.3的Shy版本拿到61分

211
00:09:02,140 --> 00:09:06,220
还在有限预览阶段的Max版本拿到62分

212
00:09:06,220 --> 00:09:08,400
比起1.2版本的57分

213
00:09:08,400 --> 00:09:10,360
Exia整整涨了4分

214
00:09:10,360 --> 00:09:15,300
在AI评测里 4分的涨幅算不算大 要看在哪个区间

215
00:09:15,300 --> 00:09:19,300
如果从30分涨到34分 那只是入门级的进步

216
00:09:19,300 --> 00:09:24,320
但从57分涨到61分已经是第一梯队模型的明显提升

217
00:09:24,320 --> 00:09:27,080
因为越往上 每一分的难度都越高

218
00:09:27,080 --> 00:09:32,200
更有竞争力的其实是成本XJ版本完成一项综合指数任务

219
00:09:32,200 --> 00:09:37,980
平均花费0.55美元 在所有得分超过59分的模型里是最低的

220
00:09:37,980 --> 00:09:39,760
我们可以简单对比一下

221
00:09:39,760 --> 00:09:40,640
同级别里

222
00:09:40,640 --> 00:09:43,040
OpenAI的GPT-4O Advanced

223
00:09:43,040 --> 00:09:44,100
做类似任务

224
00:09:44,100 --> 00:09:45,560
大概要1.2美元

225
00:09:45,560 --> 00:09:47,700
Anthropic的Cloud Opus

226
00:09:47,700 --> 00:09:49,500
则要1.5美元左右

227
00:09:49,500 --> 00:09:51,620
Meta差不多只要一半的价格

228
00:09:51,620 --> 00:09:54,980
这对于需要大量呼叫API的企业用户来说

229
00:09:54,980 --> 00:09:56,300
吸引力非常大

230
00:09:56,300 --> 00:09:58,560
我们再拆开看具体任务的表现

231
00:09:58,560 --> 00:10:00,280
Tile3-Bench Banking

232
00:10:00,280 --> 00:10:02,680
是专门的银行代理人基准测试

233
00:10:02,680 --> 00:10:05,240
模拟金融场景下的多步骤任务

234
00:10:05,240 --> 00:10:06,340
1.2版本

235
00:10:06,340 --> 00:10:08,740
当时只拿到35%的通过率

236
00:10:08,740 --> 00:10:10,960
SHAE版本提升到47%

237
00:10:10,960 --> 00:10:13,640
MAX版本更是达到52%

238
00:10:13,640 --> 00:10:15,360
这个涨幅其实相当惊人

239
00:10:15,360 --> 00:10:17,260
说明模型在处理合规

240
00:10:17,260 --> 00:10:20,240
要求高步骤繁琐的金融任务时

241
00:10:20,240 --> 00:10:22,840
可靠性比上一代强了很多

242
00:10:22,840 --> 00:10:24,000
但也要客观说

243
00:10:24,000 --> 00:10:25,580
47%的通过率

244
00:10:25,580 --> 00:10:27,720
依然代表超过一半的任务

245
00:10:27,720 --> 00:10:29,040
没办法完美完成

246
00:10:29,040 --> 00:10:31,040
距离真正取代人类专员

247
00:10:31,040 --> 00:10:32,780
还有非常远的距离

248
00:10:32,780 --> 00:10:35,700
大概相当于入行半年的助理水平

249
00:10:35,700 --> 00:10:38,980
Terminal-Bench 2.1是终端指令执行测试

250
00:10:38,980 --> 00:10:41,300
1.2版本通过率80%

251
00:10:41,300 --> 00:10:43,600
X-Shy提升到85%

252
00:10:43,600 --> 00:10:45,300
Max到86%

253
00:10:45,300 --> 00:10:46,620
这个分数看起来很高

254
00:10:46,620 --> 00:10:48,640
但终端任务相对结构化

255
00:10:48,640 --> 00:10:50,500
指令对错的标准很明确

256
00:10:50,500 --> 00:10:52,240
能拿到高分并不意外

257
00:10:52,240 --> 00:10:54,600
参考价值不如真实工作场景

258
00:10:54,600 --> 00:10:57,320
真正值得注意的反而是一项退步的指标

259
00:10:57,320 --> 00:11:00,100
AA-LCR长上下文基准

260
00:11:00,100 --> 00:11:02,660
1.2版本有83%的正确率

261
00:11:02,660 --> 00:11:05,240
1.3版本降到了79%

262
00:11:05,240 --> 00:11:07,900
为什么长上下文能力反而退步了

263
00:11:07,900 --> 00:11:10,060
难道模型越更新越差吗

264
00:11:10,060 --> 00:11:10,920
当然不是

265
00:11:10,920 --> 00:11:13,840
背后的原因是Spark 1.3调整了策略

266
00:11:13,840 --> 00:11:15,140
遇到不确定的资讯

267
00:11:15,140 --> 00:11:16,800
它更倾向于拒绝回答

268
00:11:16,800 --> 00:11:18,660
而不是硬猜一个答案

269
00:11:18,660 --> 00:11:20,780
也就是说它宁可少说几句

270
00:11:20,780 --> 00:11:22,000
也不说错话

271
00:11:22,000 --> 00:11:25,660
这种策略在AA-Omniscience准确率指标上

272
00:11:25,660 --> 00:11:26,500
也能看出来

273
00:11:26,500 --> 00:11:28,620
表面上准确率小幅回落

274
00:11:28,620 --> 00:11:30,880
但幻觉率明显降低了

275
00:11:30,880 --> 00:11:33,300
这其实是一个非常重要的取舍

276
00:11:33,300 --> 00:11:34,960
你要更高的召回率

277
00:11:34,960 --> 00:11:36,760
还是更高的准确率

278
00:11:36,760 --> 00:11:38,060
对于普通用户来说

279
00:11:38,060 --> 00:11:39,720
可能希望AI什么都能答

280
00:11:39,720 --> 00:11:41,260
哪怕错一点也没关系

281
00:11:41,260 --> 00:11:42,540
但对于企业用户

282
00:11:42,540 --> 00:11:45,300
尤其是金融 医疗 法律这些领域

283
00:11:45,300 --> 00:11:46,560
一个错误的答案

284
00:11:46,560 --> 00:11:48,620
代价可能比没有答案大得多

285
00:11:48,620 --> 00:11:51,160
之前就有企业用初代代理人模型

286
00:11:51,160 --> 00:11:52,440
处理报销审核

287
00:11:52,440 --> 00:11:55,500
结果模型编造了很多不存在的单据

288
00:11:55,500 --> 00:11:57,600
造成了不小的财务漏洞

289
00:11:57,600 --> 00:12:00,000
所以现在越是面向企业的模型

290
00:12:00,000 --> 00:12:03,660
越把不编造放在比达对更高的优先级

291
00:12:03,660 --> 00:12:04,760
从这个角度看

292
00:12:04,760 --> 00:12:06,980
这项退步反而是一种进步

293
00:12:06,980 --> 00:12:09,500
代表模型开始往实用化的方向走

294
00:12:09,500 --> 00:12:11,700
而不是为了跑分应凑答案

295
00:12:11,700 --> 00:12:13,340
另外很多人忽略的一点是

296
00:12:13,340 --> 00:12:15,480
MAX版本的分数虽然更高

297
00:12:15,480 --> 00:12:18,200
但代价是运算算力大幅增加

298
00:12:18,200 --> 00:12:20,480
根据Artificial Analysis的测试

299
00:12:20,480 --> 00:12:23,560
在GDPVAL-AAVFE任务里

300
00:12:23,560 --> 00:12:27,540
MAX版本比SY多消耗约62%的推理量

301
00:12:27,540 --> 00:12:29,540
就算是银行代理任务

302
00:12:29,540 --> 00:12:31,780
也多了28%的算力

303
00:12:31,780 --> 00:12:33,180
为什么会差这么多

304
00:12:33,180 --> 00:12:36,060
因为MAX版本会做更多的自我检查

305
00:12:36,060 --> 00:12:37,620
走更多的思维步骤

306
00:12:37,620 --> 00:12:41,200
相当于人做事情的时候反复检查好几遍

307
00:12:41,200 --> 00:12:43,260
自然更费时间更费算力

308
00:12:43,260 --> 00:12:44,860
但正确率也更高

309
00:12:44,860 --> 00:12:48,400
这其实带出了未来AI商业模式的一个可能方向

310
00:12:48,400 --> 00:12:50,500
以后的模型不会只有单一档位

311
00:12:50,500 --> 00:12:54,000
而是会根据任务的风险等级调整推理强度

312
00:12:54,000 --> 00:12:55,140
低风险的闲聊

313
00:12:55,140 --> 00:12:58,180
查资料用低档速度快又便宜

314
00:12:58,180 --> 00:12:59,480
高风险的财务

315
00:12:59,480 --> 00:13:01,180
法律任务用高档

316
00:13:01,180 --> 00:13:03,220
更慢 更贵 但更可靠

317
00:13:03,220 --> 00:13:05,160
用户可以按自己的需求选

318
00:13:05,160 --> 00:13:07,020
而不是为了偶尔的高需求

319
00:13:07,020 --> 00:13:08,940
全程付最贵的价格

320
00:13:08,940 --> 00:13:10,860
当然 目前这还只是观察

321
00:13:10,860 --> 00:13:13,820
Meta并没有正式推出这种分级定价

322
00:13:13,820 --> 00:13:15,220
但从技术设计上

323
00:13:15,220 --> 00:13:17,020
已经具备了这样的基础

324
00:13:17,020 --> 00:13:18,660
最后 还要再强调一次

325
00:13:18,660 --> 00:13:20,800
Max版本目前只是有限预览

326
00:13:20,800 --> 00:13:23,540
只有少数合作机构和企业能拿到权限

327
00:13:23,540 --> 00:13:25,440
普通开发者根本呼叫不到

328
00:13:25,440 --> 00:13:27,920
所以你看到62分那个数字的时候

329
00:13:27,920 --> 00:13:30,420
要知道它背后是更高的成本

330
00:13:30,420 --> 00:13:32,300
更严格的访问限制

331
00:13:32,300 --> 00:13:35,400
不能拿它去跟别人全面开放的API比

332
00:13:35,400 --> 00:13:37,160
然后说Meta已经赢了

333
00:13:37,160 --> 00:13:38,580
这种对比并不公平

334
00:13:38,580 --> 00:13:40,920
看完了负责思考和执行的大脑

335
00:13:40,920 --> 00:13:44,220
我们再转过头来讲这次连发的另一款产品

336
00:13:44,220 --> 00:13:46,000
负责感知输入的耳朵

337
00:13:46,000 --> 00:13:47,480
Muse Voice Transcribe

338
00:13:47,480 --> 00:13:48,980
很多人第一眼看到它

339
00:13:48,980 --> 00:13:51,280
会觉得不就是个语音转文字吗

340
00:13:51,280 --> 00:13:52,360
有什么特别的

341
00:13:52,360 --> 00:13:53,980
但实际上它的设计思路

342
00:13:53,980 --> 00:13:56,720
跟传统的自动语音识别完全不一样

343
00:13:56,720 --> 00:13:58,640
传统的ASR比如Whisper

344
00:13:58,640 --> 00:14:00,440
走的是离线转写路线

345
00:14:00,440 --> 00:14:02,840
拿到整段音频之后再慢慢处理

346
00:14:02,840 --> 00:14:04,840
可以利用上下文反复修正

347
00:14:04,840 --> 00:14:05,880
准确率很高

348
00:14:05,880 --> 00:14:06,960
但延迟也大

349
00:14:06,960 --> 00:14:09,560
根本没办法用来做实时对话

350
00:14:09,560 --> 00:14:11,380
而以前的实时语音助手

351
00:14:11,380 --> 00:14:13,940
比如手机上的Siri Google助理

352
00:14:13,940 --> 00:14:15,320
为了追求低延迟

353
00:14:15,320 --> 00:14:17,540
只能听一小段就马上输出

354
00:14:17,540 --> 00:14:19,160
结果准确率很差

355
00:14:19,160 --> 00:14:20,140
稍微吵一点

356
00:14:20,140 --> 00:14:22,960
有两个人叠话或者混个外文单字

357
00:14:22,960 --> 00:14:24,020
结果就歪掉

358
00:14:24,020 --> 00:14:25,960
Muse Voice Transcribe想解决的

359
00:14:25,960 --> 00:14:27,600
就是又要准又要快

360
00:14:27,600 --> 00:14:29,840
还要懂真实对话这个老难题

361
00:14:29,840 --> 00:14:32,960
它的做法是把音频切成80毫秒的小块

362
00:14:32,960 --> 00:14:34,940
每秒处理12月5日次

363
00:14:34,940 --> 00:14:37,980
每一小块音频先转换成一个软Token

364
00:14:37,980 --> 00:14:41,080
模型在判断是要继续等后面的声音

365
00:14:41,080 --> 00:14:42,760
还是立刻输出文字

366
00:14:42,760 --> 00:14:44,500
等到音频完全停止

367
00:14:44,500 --> 00:14:46,620
系统会加入一个特殊标记

368
00:14:46,620 --> 00:14:50,440
让模型把剩下没输出的文字一口气吐出来

369
00:14:50,440 --> 00:14:53,500
其中最关键的技术叫做自适应延迟

370
00:14:53,500 --> 00:14:57,080
模型不会给每个字都设定一样的等待时间

371
00:14:57,080 --> 00:14:59,480
简单确定的内容就立刻输出

372
00:14:59,480 --> 00:15:02,220
碰到需要后文才能判断的同音词

373
00:15:02,220 --> 00:15:03,140
专有名词

374
00:15:03,140 --> 00:15:05,940
就稍微多等一点点音频再决定

375
00:15:05,940 --> 00:15:08,160
这其实很像人类的同步口译

376
00:15:08,160 --> 00:15:10,060
译员会根据句子的难度

377
00:15:10,060 --> 00:15:11,680
调整自己的滞后时间

378
00:15:11,680 --> 00:15:13,040
不会一味求快

379
00:15:13,040 --> 00:15:14,400
也不会一味求准

380
00:15:14,400 --> 00:15:15,180
训练的时候

381
00:15:15,180 --> 00:15:17,540
Meta把词 错误率和延迟时间

382
00:15:17,540 --> 00:15:20,180
一起放进强化学习的奖励函数里

383
00:15:20,180 --> 00:15:21,900
如果模型只追求准确

384
00:15:21,900 --> 00:15:23,280
每句话都等很久

385
00:15:23,280 --> 00:15:24,240
得分不会高

386
00:15:24,240 --> 00:15:25,400
只追求速度

387
00:15:25,400 --> 00:15:27,900
输出一大堆错字同样过不了关

388
00:15:27,900 --> 00:15:32,460
最终目标就是在准确率和反应速度之间找到最佳平衡点

389
00:15:32,460 --> 00:15:33,680
那实际表现如何

390
00:15:33,680 --> 00:15:37,060
在Artificial Analysis的流逝语音榜单上

391
00:15:37,060 --> 00:15:42,060
Muse Voice Transcribe的最终词错误率约3.1%

392
00:15:42,060 --> 00:15:43,460
直接登上第一名

393
00:15:44,354 --> 00:15:58,114
这个数字是什么概念?在流逝实时的场景下,3.1%已经非常接近人类专业数据员的水平,人类大概是2%到3%左右,相当于每讲100个字只错3个。

394
00:15:58,114 --> 00:16:00,094
不过这里必须先打个预防针

395
00:16:00,094 --> 00:16:02,894
这个成绩是英语流逝对话的测试结果

396
00:16:02,894 --> 00:16:06,374
绝对不能直接套用到所有语言 所有场景

397
00:16:06,374 --> 00:16:08,834
中文因为同音字多 声调复杂

398
00:16:08,834 --> 00:16:13,214
同样的模型词错误率通常会比英语高2到3个百分点

399
00:16:13,214 --> 00:16:17,294
如果是嘈杂环境 多人强化 或者带方言口音

400
00:16:17,294 --> 00:16:19,014
表现还会再打折扣

401
00:16:19,014 --> 00:16:22,834
官方也明确说 模型训练覆盖了70多种语言

402
00:16:22,834 --> 00:16:25,734
其中只有25种经过充分验证

403
00:16:25,734 --> 00:16:27,834
其他语言可能只是有训练过

404
00:16:27,834 --> 00:16:30,234
但没有经过严格的效果评测

405
00:16:30,234 --> 00:16:32,134
除了基础的转写准确率

406
00:16:32,134 --> 00:16:34,194
还有几个功能特别值得一提

407
00:16:34,194 --> 00:16:36,714
首先是原生的说话人分离

408
00:16:36,714 --> 00:16:39,334
而且支持20人以上同时发言

409
00:16:39,334 --> 00:16:42,094
传统的会议转写通常是先做语音识别

410
00:16:42,094 --> 00:16:44,014
再另外用一套声文系统

411
00:16:44,014 --> 00:16:45,714
判断每段话是谁说的

412
00:16:45,714 --> 00:16:47,194
两个系统的时间轴

413
00:16:47,194 --> 00:16:49,354
只要差一点点就会出现文字

414
00:16:49,354 --> 00:16:50,474
人认错的情况

415
00:16:50,474 --> 00:16:52,814
Meta是在同一个生成过程里

416
00:16:52,814 --> 00:16:55,674
加入说话人切换标记和身份标签

417
00:16:55,674 --> 00:16:58,434
检测到换人就先标一轮新发言

418
00:16:58,434 --> 00:17:00,894
等听到足够声音再确定身份

419
00:17:00,894 --> 00:17:03,014
时间轴的准确度会高很多

420
00:17:03,014 --> 00:17:06,214
官方展示的长对话里包含多人插话

421
00:17:06,214 --> 00:17:08,314
重叠发言 自然停顿

422
00:17:08,314 --> 00:17:10,194
都能正确标记身份

423
00:17:10,194 --> 00:17:13,734
这对于会议记录 访谈整理 客服记录来说

424
00:17:13,734 --> 00:17:14,674
价值很高

425
00:17:14,674 --> 00:17:18,214
因为后续的摘要系统拿到的不只是一整段文字

426
00:17:18,214 --> 00:17:20,894
还知道谁提了问题 谁做了承诺

427
00:17:20,894 --> 00:17:22,234
谁反对哪个方案

428
00:17:22,234 --> 00:17:23,974
其次是端点侦测能力

429
00:17:23,974 --> 00:17:27,474
人类对话本来就不会每次讲完都按个结束钮

430
00:17:27,474 --> 00:17:30,794
系统要从语气停顿和上下文判断

431
00:17:30,794 --> 00:17:33,474
对方只是喘口气还是真的说完了

432
00:17:33,474 --> 00:17:35,014
如果端点判断不准

433
00:17:35,014 --> 00:17:36,694
要么用户都讲完半天了

434
00:17:36,694 --> 00:17:37,774
助手还没反应

435
00:17:37,774 --> 00:17:39,234
要么用户还没说完

436
00:17:39,234 --> 00:17:41,494
助手就急着插嘴体验都很差

437
00:17:41,494 --> 00:17:42,814
Muse Voice Transcribe

438
00:17:42,814 --> 00:17:44,654
专门针对这点做了优化

439
00:17:44,654 --> 00:17:47,514
能更准确判断语音的开始和结束

440
00:17:47,514 --> 00:17:50,014
这也是代理人能自然对话的前提

441
00:17:50,014 --> 00:17:51,894
第三个很实用的功能是

442
00:17:51,894 --> 00:17:54,594
句内和句间的多语言自由切换

443
00:17:54,594 --> 00:17:56,134
还有上下文偏制

444
00:17:56,134 --> 00:17:58,374
现实中很多双语使用者

445
00:17:58,374 --> 00:18:00,574
不会先切语言模式再讲话

446
00:18:00,574 --> 00:18:02,994
中文句子里夹个英文专有名词

447
00:18:02,994 --> 00:18:05,274
项目代号是家常便饭

448
00:18:05,274 --> 00:18:06,954
旧的系统很容易把英文词

449
00:18:06,954 --> 00:18:08,994
应转成发音相近的中文字

450
00:18:08,994 --> 00:18:11,494
或者切换语言之后直接丢了半句话

451
00:18:11,494 --> 00:18:12,994
Muse Voice Transcribe

452
00:18:12,994 --> 00:18:15,294
支持70多种语言的自由切换

453
00:18:15,294 --> 00:18:18,254
还可以让用户提前输入常用的人名

454
00:18:18,254 --> 00:18:19,734
公司名专业术语

455
00:18:19,734 --> 00:18:21,714
模型碰到相近发音的时候

456
00:18:21,714 --> 00:18:24,994
会优先选择这些符合上下文的词

457
00:18:24,994 --> 00:18:27,654
比如医生可以提前录入药品名称

458
00:18:27,654 --> 00:18:30,914
城市设计师可以加入函数名和项目代号

459
00:18:30,914 --> 00:18:33,594
企业用户可以上传内部数语表

460
00:18:33,594 --> 00:18:36,014
这样转写的准确率会大幅提升

461
00:18:36,014 --> 00:18:38,154
甚至可以直接进入工作流程

462
00:18:38,154 --> 00:18:39,714
不用再人工校对一遍

463
00:18:39,714 --> 00:18:42,054
这才是语音转写真正的价值

464
00:18:42,054 --> 00:18:44,254
不是把声音变成文字就好

465
00:18:44,254 --> 00:18:46,234
而是变成能直接用的文字

466
00:18:46,234 --> 00:18:47,874
目前Muse Voice Transcribe

467
00:18:47,874 --> 00:18:49,614
已经接入Meta Model API

468
00:18:49,614 --> 00:18:52,774
还有Meta AI4 Mac Muse Code Mac版本

469
00:18:52,774 --> 00:18:55,494
用户可以按住FN键直接语音输入

470
00:18:55,494 --> 00:18:58,314
把转写结果送到不同的应用程式里

471
00:18:58,314 --> 00:19:00,834
不过有个隐私细节一定要讲清楚

472
00:19:00,834 --> 00:19:04,734
官方网页演示的时候说麦克风音频只会用来生成转写

473
00:19:04,734 --> 00:19:05,614
不会被保存

474
00:19:05,614 --> 00:19:08,394
但这个承诺只限于网页演示场景

475
00:19:08,394 --> 00:19:10,254
不等于所有API呼叫

476
00:19:10,254 --> 00:19:13,014
所有产品部署都不会保存音频

477
00:19:13,014 --> 00:19:15,354
如果你是透过API上传录音

478
00:19:15,354 --> 00:19:16,694
Meta会不会保存

479
00:19:16,694 --> 00:19:17,554
保存多久

480
00:19:17,554 --> 00:19:19,254
会不会用来训练模型

481
00:19:19,254 --> 00:19:22,774
都要看你签署的服务条款和数据处理协议

482
00:19:22,774 --> 00:19:24,714
不能因为网页演示不保存

483
00:19:24,714 --> 00:19:28,074
就理所当然认为所有场景都不保存

484
00:19:28,074 --> 00:19:30,994
这在个资合规上是非常危险的认知

485
00:19:30,994 --> 00:19:33,534
讲到这里就必须好好聊一下

486
00:19:33,534 --> 00:19:35,034
隐私与安全的边界

487
00:19:35,034 --> 00:19:37,354
这也是很多人看AI产品的时候

488
00:19:37,354 --> 00:19:40,374
最容易忽略但绝对最重要的部分

489
00:19:40,374 --> 00:19:42,854
先讲Muse Spark 1.3的安全设计

490
00:19:42,854 --> 00:19:45,254
官方说这次提升了对提示注入

491
00:19:45,254 --> 00:19:47,294
和对抗输入的抵抗能力

492
00:19:47,294 --> 00:19:49,994
也更能识别哪些操作是不可逆的

493
00:19:49,994 --> 00:19:51,054
提示注入是什么

494
00:19:51,054 --> 00:19:53,254
就是攻击者在输入内容里

495
00:19:53,254 --> 00:19:55,274
嵌入看不见的恶意指令

496
00:19:55,274 --> 00:19:57,314
比如藏在PDF档案里

497
00:19:57,314 --> 00:19:58,114
网页里

498
00:19:58,114 --> 00:20:00,834
诱导AI代理人忽略原本的规则

499
00:20:00,834 --> 00:20:02,554
去转发机密档案

500
00:20:02,554 --> 00:20:03,974
修改设定甚至转账

501
00:20:03,974 --> 00:20:06,434
2025年就曾经出现过

502
00:20:06,434 --> 00:20:07,714
类似的攻击案例

503
00:20:07,714 --> 00:20:10,754
让不少企业对AI代理人望而却步

504
00:20:10,754 --> 00:20:13,774
Spark 1.3针对这类攻击做了专门训练

505
00:20:13,774 --> 00:20:15,594
但这不代表它完全免疫

506
00:20:15,594 --> 00:20:19,874
目前没有任何模型能100%防御所有提示注入攻击

507
00:20:19,874 --> 00:20:21,594
识别不可逆操作也是一样

508
00:20:21,594 --> 00:20:23,394
模型能标出删除档案

509
00:20:23,394 --> 00:20:24,574
发送批量邮件

510
00:20:24,574 --> 00:20:26,934
修改数据库这些高风险动作

511
00:20:26,934 --> 00:20:28,334
要求用户确认

512
00:20:28,334 --> 00:20:31,114
但光有模型层面的防护远远不够

513
00:20:31,114 --> 00:20:33,814
官方自己也强调实际部署的时候

514
00:20:33,814 --> 00:20:36,374
必须同时做好全线隔离

515
00:20:36,374 --> 00:20:38,454
白名单和操作日志

516
00:20:38,454 --> 00:20:41,514
全线隔离就是给代理人最小必要的全线

517
00:20:41,514 --> 00:20:43,754
比如负责整理表格的助理

518
00:20:43,754 --> 00:20:46,534
就不该有删除整个资料夹的权限

519
00:20:46,534 --> 00:20:50,654
白名单就是只允许模型呼叫预先核准的

520
00:20:50,654 --> 00:20:54,834
工具和API不能让它随便访问系统里的任何东西

521
00:20:54,834 --> 00:20:58,954
操作日志就是把代理人所有执行动作都记录下来

522
00:20:58,954 --> 00:21:01,134
方便事后审计和回溯

523
00:21:01,134 --> 00:21:04,334
这三层防护都是资安领域的基本常识

524
00:21:04,334 --> 00:21:07,754
却也是很多AI产品最容易省略的部分

525
00:21:07,754 --> 00:21:09,614
Meta愿意主动强调这点

526
00:21:09,614 --> 00:21:13,234
说明它是真的在考虑企业落地的实际需求

527
00:21:13,234 --> 00:21:15,894
而不是只做展示用的技术demo

528
00:21:15,894 --> 00:21:16,974
再回到语音部分

529
00:21:16,974 --> 00:21:19,874
当语音转写加上代理人执行

530
00:21:19,874 --> 00:21:23,534
再搭配Meta旗下的ray减班智慧眼镜

531
00:21:23,534 --> 00:21:25,214
想象空间确实很大

532
00:21:25,214 --> 00:21:28,694
手机上的语音助手要等你点开APP才能用

533
00:21:28,694 --> 00:21:30,854
但眼镜可以一直戴在脸上

534
00:21:30,854 --> 00:21:32,794
随时处在声音环境里

535
00:21:32,794 --> 00:21:34,574
如果他能听懂谁在讲话

536
00:21:34,574 --> 00:21:35,814
什么时候该接话

537
00:21:35,814 --> 00:21:37,134
什么时候不该插嘴

538
00:21:37,134 --> 00:21:39,954
就能在会议后自动整理每个人的行动项

539
00:21:39,954 --> 00:21:42,014
访谈的时候自动标记重点

540
00:21:42,014 --> 00:21:46,134
甚至日常聊天里提到的代办事项都能自动记下来

541
00:21:46,134 --> 00:21:48,634
但这也带来了更尖锐的隐私问题

542
00:21:48,634 --> 00:21:50,974
眼镜上的麦克风什么时候在听

543
00:21:50,974 --> 00:21:52,874
听到的内容传到哪里去了

544
00:21:52,874 --> 00:21:54,914
用户有没有明确的控制权

545
00:21:54,914 --> 00:21:57,234
旁边的人知不知道自己正在被录音

546
00:21:57,234 --> 00:22:00,234
这些问题目前都还没有完全公开的答案

547
00:22:00,234 --> 00:22:04,274
不过我们可以从Meta的双轨策略里推出一个很合理的假设

548
00:22:04,274 --> 00:22:06,954
未来轻量级的语音转写

549
00:22:06,954 --> 00:22:08,534
简单的指令理解

550
00:22:08,534 --> 00:22:12,294
很可能会直接跑在眼镜本地的端侧芯片上

551
00:22:12,294 --> 00:22:13,534
不需要传到云端

552
00:22:13,534 --> 00:22:15,294
敏感数据不会离开设备

553
00:22:15,294 --> 00:22:17,034
大幅降低隐私风险

554
00:22:17,034 --> 00:22:18,774
而复杂的常任务代理

555
00:22:18,774 --> 00:22:19,934
多工具协作

556
00:22:19,934 --> 00:22:22,694
再交给云端的Spark模型处理

557
00:22:22,694 --> 00:22:25,634
刚好Meta有Glimmer这条本地开源路线

558
00:22:25,634 --> 00:22:27,694
专门做轻量化端侧部署

559
00:22:27,694 --> 00:22:30,634
刚好可以跟眼镜这类终端装置搭配

560
00:22:30,634 --> 00:22:32,334
云端负责复杂思考

561
00:22:32,334 --> 00:22:34,034
本地负责实时感知

562
00:22:34,034 --> 00:22:36,274
既保证体验又兼顾隐私

563
00:22:36,274 --> 00:22:40,194
这很可能就是Meta下一代AI入口的完整架构

564
00:22:40,194 --> 00:22:42,834
当然这只是基于现有产品线的推测

565
00:22:42,834 --> 00:22:44,754
官方还没有证实这个方向

566
00:22:44,754 --> 00:22:46,794
讲完了技术亮点和想象空间

567
00:22:46,794 --> 00:22:48,234
我们也得冷静下来

568
00:22:48,234 --> 00:22:51,154
聊聊这次发布的口径边界和实际风险

569
00:22:51,154 --> 00:22:54,114
首先Max版本目前只是有线预览

570
00:22:54,114 --> 00:22:56,514
普通开发者能用的只有Shi版本

571
00:22:56,514 --> 00:22:58,834
网上所有关于Max的评测数据

572
00:22:58,834 --> 00:23:01,034
都来自少数拿到权限的机构

573
00:23:01,034 --> 00:23:03,074
一般用户现在根本用不到

574
00:23:03,074 --> 00:23:07,054
所以62分那个数字只能当成技术上限的参考

575
00:23:07,054 --> 00:23:10,094
不能作为采购或者使用决策的依据

576
00:23:10,094 --> 00:23:12,414
其次所有的基准测试数据

577
00:23:12,414 --> 00:23:15,414
都是在标准化的干净环境里跑出来的

578
00:23:15,414 --> 00:23:19,494
真实世界的场景只会更复杂更混乱

579
00:23:19,494 --> 00:23:22,494
比如银行代理测试里的数据都是结构化的

580
00:23:22,494 --> 00:23:24,154
格式统一全线清晰

581
00:23:25,087 --> 00:23:31,527
但真实的企业里,数据可能分散在十几个老旧系统里,格式乱七八糟、权限层层卡关。

582
00:23:31,527 --> 00:23:37,207
你在测试里拿到47%的通过率,到了真实环境可能连30%都不到。

583
00:23:37,207 --> 00:23:43,787
这不是Meta的问题 是所有AI模型评测的普遍现象 跑分永远不等于真实生产力

584
00:23:43,787 --> 00:23:46,327
第三 关于开源的期待也要放低

585
00:23:46,327 --> 00:23:54,287
Spark 1.3目前是完全避原的 官方只说未来有开放权重的规划 但没有时间表 也没有说授权条款

586
00:23:54,287 --> 00:24:01,247
参考Meta之前Lama系列的节奏 通常是新一代出来之后才会把上一代的权重逐步开放

587
00:24:01,247 --> 00:24:06,807
而且早期都是非商业授权 要等到更后面才会用更宽松的授权

588
00:24:06,807 --> 00:24:10,007
所以不要期待短期内就能在自己的电脑上

589
00:24:10,007 --> 00:24:12,987
跑Spark 1.3核心的代理人能力

590
00:24:12,987 --> 00:24:16,127
Meta肯定会先握在手里当商业护城河

591
00:24:16,127 --> 00:24:18,087
最后回到产业竞争的层面

592
00:24:18,087 --> 00:24:20,447
Meta这次的更新确实扎实

593
00:24:20,447 --> 00:24:25,027
在代理人可靠性和流逝语音转写上都往前走了一步

594
00:24:25,027 --> 00:24:27,327
成本控制也做得很有竞争力

595
00:24:27,327 --> 00:24:29,227
但要说已经赢了还太早

596
00:24:29,227 --> 00:24:33,127
OpenEye的GPT系列代理人能力同样在快速迭代

597
00:24:33,127 --> 00:24:37,847
谷歌的Gemini在多模态和端侧整合上有自己的优势

598
00:24:37,847 --> 00:24:42,527
Anthropic在长上下文和安全合规上依然领先

599
00:24:42,527 --> 00:24:46,927
还有Eleven Labs这类专业语音公司也在往代理人方向走

600
00:24:46,927 --> 00:24:52,547
Meta现在的领先更像是某几个细分场景的小幅度领先

601
00:24:52,547 --> 00:24:55,207
还远没有到拉开差距的程度

602
00:24:55,207 --> 00:24:58,527
而且真正的竞争从来都不是比模型本身

603
00:24:58,527 --> 00:25:02,807
而是比谁能先把技术变成用户愿意天天用的产品

604
00:25:02,807 --> 00:25:04,927
谁能解决好隐私安全

605
00:25:04,927 --> 00:25:06,967
权限这些麻烦的落地问题

606
00:25:06,967 --> 00:25:08,247
模型再聪明

607
00:25:08,247 --> 00:25:10,887
如果用户不敢把重要的工作交给他

608
00:25:10,887 --> 00:25:12,587
那也只是个高级玩具

609
00:25:12,587 --> 00:25:13,167
讲到这里

610
00:25:13,167 --> 00:25:16,007
我们把这次Meta两款产品的技术细节

611
00:25:16,007 --> 00:25:16,947
评测数据

612
00:25:16,947 --> 00:25:18,107
产品线定位

613
00:25:18,107 --> 00:25:19,027
隐私风险

614
00:25:19,027 --> 00:25:21,187
还有产业格局全部拆完了

615
00:25:21,187 --> 00:25:23,667
你会发现每一个亮眼的数据背后

616
00:25:23,667 --> 00:25:25,307
都有一个限定条件

617
00:25:25,307 --> 00:25:27,067
每一项技术突破的旁边

618
00:25:27,067 --> 00:25:29,227
都站着一个带解决的问题

619
00:25:29,227 --> 00:25:30,947
这不是说Meta做得不好

620
00:25:30,947 --> 00:25:32,047
恰恰相反

621
00:25:32,047 --> 00:25:34,567
只有当你看清了所有的边界和限制

622
00:25:34,567 --> 00:25:36,587
才能真正评估它的价值

623
00:25:36,587 --> 00:25:41,227
Muse Spark 1.3确实把常任务代理人的可靠性往前推了一步

624
00:25:41,227 --> 00:25:43,027
成本优势也很明显

625
00:25:43,027 --> 00:25:46,167
Muse Voice Transcribe在英语流逝转写上

626
00:25:46,167 --> 00:25:48,187
做到了业界顶尖

627
00:25:48,187 --> 00:25:50,827
准确率和延迟的平衡做得可圈可点

628
00:25:50,827 --> 00:25:53,427
但它们都还只是阶段性的进展

629
00:25:53,427 --> 00:25:56,067
离大家想象中什么都能做的AI助理

630
00:25:56,067 --> 00:25:57,647
还有非常远的距离

631
00:25:57,647 --> 00:25:59,707
2026年的AI产业

632
00:25:59,707 --> 00:26:02,607
其实正在经历一个很重要的转向

633
00:26:02,607 --> 00:26:05,447
前几年大家都在比谁的模型更大

634
00:26:05,447 --> 00:26:06,747
谁的跑分更高

635
00:26:06,747 --> 00:26:08,627
谁的牛皮吹得更响

636
00:26:08,627 --> 00:26:12,087
但从今年开始竞争慢慢落到了实处

637
00:26:12,087 --> 00:26:14,167
比的是谁能把长任务做稳

638
00:26:14,167 --> 00:26:15,927
谁能把真实声音听懂

639
00:26:15,927 --> 00:26:17,727
谁能让企业敢放心用

640
00:26:17,727 --> 00:26:20,227
谁能把隐私控制在合理范围

641
00:26:20,227 --> 00:26:22,847
那些看起来不怎么耀眼的细节优化

642
00:26:22,847 --> 00:26:27,407
反而决定了产品能不能真正走进日常生活和工作流

643
00:26:27,407 --> 00:26:28,267
就像造车

644
00:26:28,267 --> 00:26:36,447
早期大家都比马力 比急速 等到市场成熟了 比的是隔音 是油耗 是故障率 是乘坐舒适度

645
00:26:36,447 --> 00:26:39,987
这些才是决定你愿不愿意每天开的关

646
00:26:39,987 --> 00:26:45,347
见如果你喜欢这种不吹不黑 把数据和限制都讲清楚的深度科技解析

647
00:26:45,347 --> 00:26:48,947
欢迎订阅这个频道 并且打开通知小铃铛

648
00:26:48,947 --> 00:26:54,787
我们会持续追踪AI代理人 语音交互 端策AI这些领域的最新进展

649
00:26:54,787 --> 00:26:57,307
帮你过滤掉夸大的营销话术

650
00:26:57,307 --> 00:26:59,727
留下真正值得关注的技术变化

651
00:26:59,727 --> 00:27:01,327
也欢迎在留言区告诉我

652
00:27:01,327 --> 00:27:04,287
你最期待AI帮你完成什么样的任务

653
00:27:04,287 --> 00:27:05,927
是整理会议记录

654
00:27:05,927 --> 00:27:07,887
还是处理繁琐的文书工作

655
00:27:07,887 --> 00:27:09,647
我们下期影片再见