WEBVTT

00:00:00.000 --> 00:00:02.300
你有没有过这种很无力的经验?

00:00:02.300 --> 00:00:05.000
叫AI帮你整理一份跨部门的会议报告。

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

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

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

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

00:00:27.500 --> 00:00:29.980
2026年9月的头两天

00:00:29.980 --> 00:00:32.400
Meta接连丢出了两项更新

00:00:32.400 --> 00:00:34.840
没有吹什么通用人工智能的牛皮

00:00:34.840 --> 00:00:38.480
却精准踩中了这些大家天天吐槽的痛点

00:00:38.480 --> 00:00:41.760
一个负责把真实世界里的声音听得更清楚

00:00:41.760 --> 00:00:44.780
一个负责把复杂的常任务做得更稳

00:00:44.780 --> 00:00:48.720
有人看完数据说Meta终于要在代理人战场超车了

00:00:48.720 --> 00:00:50.420
也有人冷静算完成本

00:00:50.420 --> 00:00:52.540
发现事情根本没有这么简单

00:00:52.540 --> 00:00:54.180
今天我们就不吹不黑

00:00:54.180 --> 00:00:57.220
把官方技术文件第三方独立评测

00:00:57.220 --> 00:01:00.140
还有那些藏在角落的小字限制

00:01:00.140 --> 00:01:01.840
全部摊开来讲

00:01:01.840 --> 00:01:04.620
看看这两款产品到底走到了哪一步

00:01:04.620 --> 00:01:07.300
又有哪些东西是营销不会告诉你的

00:01:07.300 --> 00:01:08.860
我们不从结论讲起

00:01:08.860 --> 00:01:12.280
因为真正有价值的判断往往都藏在每一个

00:01:12.280 --> 00:01:13.380
但是后面

00:01:13.380 --> 00:01:17.300
先帮大家把最容易搞混的产品线界限画清楚

00:01:17.300 --> 00:01:20.100
这也是很多自媒体最常讲错的地方

00:01:20.100 --> 00:01:24.160
9月1日登场的是Muse Voice Transcribe语音转写模型

00:01:24.160 --> 00:01:28.160
9月2日接棒上线的是Muse Spark 1.3代理人模型

00:01:28.160 --> 00:01:30.560
两天连续发布核心产品

00:01:30.560 --> 00:01:34.340
这在Meta Superintelligence Labs的历史上并不常见

00:01:34.340 --> 00:01:38.520
也能看出他们在2026年下半年的竞争焦虑

00:01:38.520 --> 00:01:39.500
但更重要的是

00:01:39.500 --> 00:01:41.780
很多人到现在还搞不清楚

00:01:41.780 --> 00:01:43.960
Muse Spark和Muse Glimmer

00:01:43.960 --> 00:01:46.860
根本是两条完全不同的路线

00:01:46.860 --> 00:01:48.180
不能混为一谈

00:01:48.180 --> 00:01:51.280
Muse Spark走的是云端前沿代理人路线

00:01:51.280 --> 00:01:52.720
权重完全必圆

00:01:52.720 --> 00:01:54.820
目前只开放API呼叫

00:01:54.820 --> 00:01:57.560
官方只说未来有开放权重的规划

00:01:57.560 --> 00:01:59.000
但既没有时间表

00:01:59.000 --> 00:02:01.280
也没说会用哪种授权条款

00:02:01.280 --> 00:02:03.420
所以你绝对不能把它理解成

00:02:03.420 --> 00:02:05.700
马上就可以下载来本地跑

00:02:05.700 --> 00:02:08.540
而Muse Glimmer是拥有300亿参数

00:02:08.540 --> 00:02:11.860
采用Apache 2.0授权的本地方案

00:02:11.860 --> 00:02:14.140
主打消费级显示卡就能执行

00:02:14.140 --> 00:02:14.780
讲白一点

00:02:14.780 --> 00:02:17.100
Spark负责把能力堆到最高

00:02:17.100 --> 00:02:19.680
强企业级和高端开发者市场

00:02:19.680 --> 00:02:21.840
Glimmer负责把能力扑到最广

00:02:21.840 --> 00:02:24.100
占领开源生态和终端装置

00:02:24.100 --> 00:02:28.680
这种双轨策略其实刚好对应了Meta在AI产业的定位转变

00:02:28.680 --> 00:02:33.400
前几年大家提到Meta的AI第一个想到的就是Lama系列开源模型

00:02:33.400 --> 00:02:34.960
靠免费打天下

00:02:34.960 --> 00:02:37.980
跟OpenAI的全B原路线正面抗衡

00:02:37.980 --> 00:02:40.060
但到了2026年

00:02:40.060 --> 00:02:43.760
整个行业的竞争已经从比参数 比跑分

00:02:43.760 --> 00:02:46.900
进到比代理人 比落地场景的阶段

00:02:46.900 --> 00:02:50.140
Meta必须拿出足够强的B原顶端产品

00:02:50.140 --> 00:02:51.600
才能跟GPT系列

00:02:51.600 --> 00:02:53.700
Gemini系列抢商业客户

00:02:53.700 --> 00:02:56.760
同时又不能丢掉开源生态的优势

00:02:56.760 --> 00:02:59.240
为什么要花这么多时间讲这件事

00:02:59.240 --> 00:03:00.540
因为如果你误以为

00:03:00.540 --> 00:03:02.580
Spark 1.3是开源模型

00:03:02.580 --> 00:03:04.660
就会产生错误的部署预期

00:03:04.660 --> 00:03:08.220
如果你以为Glimmer只是Spark的缩小版

00:03:08.220 --> 00:03:11.700
就会低估两者在设计目标上的根本差异

00:03:11.700 --> 00:03:13.160
另外从迭代节奏来看

00:03:13.160 --> 00:03:15.500
Muse系列从7月的1.1版

00:03:15.500 --> 00:03:17.360
首次连上邮件行事例

00:03:17.360 --> 00:03:23.160
并能制作投影片到8月初1.2版聚焦大型程式库与复杂真错

00:03:23.160 --> 00:03:25.700
甚至能连续1000多次工具呼叫

00:03:25.700 --> 00:03:30.260
在24小时内反复编写编译GPU核心程式

00:03:30.260 --> 00:03:33.600
8月中再加入图像与视频理解能力

00:03:33.600 --> 00:03:37.140
到9月的1.3版转向打磨长期任务的可用性

00:03:37.140 --> 00:03:40.500
几乎保持每个月一次大版本更新的速度

00:03:40.500 --> 00:03:43.000
这种快速迭代在AI圈不算稀奇

00:03:43.000 --> 00:03:47.680
但难得的是Meta几乎每一版都会附上明确的内部对比数据

00:03:47.680 --> 00:03:49.960
同时引用第三方评测结果

00:03:49.960 --> 00:03:52.880
给了外界一个相对透明的观察窗口

00:03:52.880 --> 00:03:55.220
很多人只盯着分数涨了多少

00:03:55.220 --> 00:03:58.020
却忽略了每一代版本的定位差异

00:03:58.020 --> 00:04:02.200
Spark 1.3并不是全面碾压1.2的终极进化

00:04:02.200 --> 00:04:05.600
而是针对代理人任务的可靠性做了针对性强化

00:04:05.600 --> 00:04:09.420
甚至在部分涨上下文指标上还出现了小幅退步

00:04:09.420 --> 00:04:11.240
这种有得有失的升级

00:04:11.240 --> 00:04:14.860
恰恰说明模型能力不是简单的线性叠加

00:04:14.860 --> 00:04:17.660
而是一连串的取舍与权衡

00:04:17.660 --> 00:04:19.960
如果你只看营销文案里的亮点

00:04:19.960 --> 00:04:23.140
很快就会在实际使用中发现落差

00:04:23.140 --> 00:04:25.500
如果你翻完这次的全部技术文件

00:04:25.500 --> 00:04:27.400
会发现最核心的关键词

00:04:27.400 --> 00:04:28.760
不是更高的分数

00:04:28.760 --> 00:04:30.280
也不是更多的参数

00:04:30.280 --> 00:04:32.300
而是长任务代理人

00:04:32.300 --> 00:04:33.440
什么意思

00:04:33.440 --> 00:04:36.500
就是让AI不再只是一次性回答一个问题

00:04:36.500 --> 00:04:39.160
而是像一个真正的执行助理一样

00:04:39.160 --> 00:04:41.220
接下一个模糊的需求

00:04:41.220 --> 00:04:43.480
自己拆解步骤 呼叫工具

00:04:43.480 --> 00:04:44.880
遇到问题回头问你

00:04:44.880 --> 00:04:46.100
碰到危险操作

00:04:46.100 --> 00:04:49.380
先停下来确认最后再交付完整的成果

00:04:49.380 --> 00:04:50.480
这听起来很美好

00:04:50.480 --> 00:04:53.680
但过去大部分代理人模型的问题无非三种

00:04:53.680 --> 00:04:55.880
要么不敢动手只会空泛回答

00:04:55.880 --> 00:04:58.680
要么乱动手做到一半偏离目标

00:04:58.680 --> 00:05:02.000
更常见的是干到一半彻底忘了最原始的要求

00:05:02.000 --> 00:05:05.020
Spark 1.3就是冲着这些痛点做的优化

00:05:05.020 --> 00:05:06.460
举个很实际的场景

00:05:06.460 --> 00:05:07.620
如果你跟模型说

00:05:07.620 --> 00:05:10.520
帮我整理上礼拜的三场客户会议记录

00:05:10.520 --> 00:05:11.800
做成部门简报

00:05:11.800 --> 00:05:14.120
把每个客户的行动项列出来

00:05:14.120 --> 00:05:15.440
最后寄给主管

00:05:15.440 --> 00:05:16.680
换做之前的模型

00:05:16.680 --> 00:05:19.780
很可能做到一半就忘了要按客户分类

00:05:19.780 --> 00:05:21.800
或者漏了寄信的步骤

00:05:21.800 --> 00:05:24.980
甚至为了凑数编造几个不存在的行动项

00:05:24.980 --> 00:05:27.920
而Spark 1.3的处理逻辑会完全不同

00:05:27.920 --> 00:05:30.280
一开始如果觉得需求不够清楚

00:05:30.280 --> 00:05:31.920
它会主动追问你

00:05:31.920 --> 00:05:34.800
简报要的是正式版本还是讨论版

00:05:34.800 --> 00:05:37.500
行动项要不要加上预计完成时间

00:05:37.500 --> 00:05:40.440
寄信的时候要不要附上原始记录档

00:05:40.440 --> 00:05:44.660
执行过程中如果发现某份会议记录打不开或者权限不足

00:05:44.660 --> 00:05:46.580
它会停下来跟你要资讯

00:05:46.580 --> 00:05:49.160
而不是硬着头皮编一个结果

00:05:49.160 --> 00:05:50.460
如果碰到删除档案

00:05:50.460 --> 00:05:51.640
发送批量邮件

00:05:51.640 --> 00:05:55.080
修改正式环境设定这类有不可逆风险的操作

00:05:55.080 --> 00:05:57.020
它一定会先跳出确认

00:05:57.020 --> 00:05:58.480
问你确定要执行吗

00:05:58.480 --> 00:05:59.980
不会自己直接动手

00:05:59.980 --> 00:06:00.880
更重要的是

00:06:00.880 --> 00:06:04.180
它能分辨你现在是在补充当前任务的资讯

00:06:04.180 --> 00:06:06.600
还是要打断手头的事做别的

00:06:06.600 --> 00:06:09.380
又或者是要开启一个全新的任务

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

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

00:06:28.000 --> 00:06:29.600
比如你一开始就说过

00:06:29.600 --> 00:06:31.880
所有输出都要用正体中文

00:06:31.880 --> 00:06:33.520
不能用外部图片素材

00:06:33.520 --> 00:06:35.400
数据不能超过指定范围

00:06:35.400 --> 00:06:37.160
他会在整个执行过程中

00:06:37.160 --> 00:06:38.760
反复检查这些条件

00:06:38.760 --> 00:06:41.380
而不是跑个五六步之后就全忘了

00:06:41.380 --> 00:06:42.440
最关键的一点

00:06:42.440 --> 00:06:44.920
是他对自身能力边界的判断

00:06:44.920 --> 00:06:46.400
过去很多代理人模型

00:06:46.400 --> 00:06:47.420
最危险的习惯

00:06:47.420 --> 00:06:48.880
就是任务做不完的时候

00:06:48.880 --> 00:06:50.120
会假装做完了

00:06:50.120 --> 00:06:51.260
然后生成一份

00:06:51.260 --> 00:06:52.860
看起来很完整的报告

00:06:52.860 --> 00:06:55.400
里面全是编造的数据和结论

00:06:55.400 --> 00:06:57.220
普通用户根本看不出来

00:06:57.220 --> 00:07:01.260
Bug1.3在训练时特别强化了这点遇到做不到的地方

00:07:01.260 --> 00:07:02.860
他更倾向于直接说

00:07:02.860 --> 00:07:04.160
我卡在这里了

00:07:04.160 --> 00:07:05.500
我缺少这个资讯

00:07:05.500 --> 00:07:09.240
而不是硬凑出一份看似完美的答案

00:07:09.240 --> 00:07:12.060
Meta内部工程师对比1.2版本后发现

00:07:12.060 --> 00:07:15.820
新版本平均减少了20%的工具呼叫次数

00:07:15.820 --> 00:07:18.880
同时减少了25%的token消耗

00:07:18.880 --> 00:07:21.340
这两个数字其实比跑分更有意义

00:07:21.340 --> 00:07:24.020
工具呼叫减少代表模型更清楚

00:07:24.020 --> 00:07:25.740
什么时候该用什么工具

00:07:25.740 --> 00:07:28.580
不会无脑尝试所有选项来回绕路

00:07:28.580 --> 00:07:30.000
Token消耗减少

00:07:30.000 --> 00:07:31.680
代表推理效率提升

00:07:31.680 --> 00:07:33.840
单位任务的成本直接下降

00:07:33.840 --> 00:07:35.880
很多人不知道代理人任务的成本

00:07:35.880 --> 00:07:38.300
通常是纯问答的3到5倍

00:07:38.300 --> 00:07:40.120
因为要不断多轮推理

00:07:40.120 --> 00:07:41.800
呼叫工具修正路线

00:07:41.800 --> 00:07:43.080
所以效率的提升

00:07:43.080 --> 00:07:44.520
直接决定了这项技术

00:07:44.520 --> 00:07:46.220
能不能大规模商业化

00:07:46.220 --> 00:07:47.380
不过也要说清楚

00:07:47.380 --> 00:07:50.900
这两个数字是Meta内部测试场景下的结果

00:07:50.900 --> 00:07:52.880
不是第三方独立评测

00:07:52.880 --> 00:07:55.260
实际业务中因为场景更复杂

00:07:55.260 --> 00:07:57.340
不一定能复现同样的比例

00:07:57.340 --> 00:08:00.000
官方也举了几个典型的常任务场景

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

00:08:12.980 --> 00:08:14.920
保持所有音轨长度不变

00:08:14.920 --> 00:08:16.040
再重新混音

00:08:16.040 --> 00:08:18.640
这些场景的共同点就是步骤多

00:08:18.640 --> 00:08:19.840
中间产物多

00:08:19.840 --> 00:08:21.400
需要跨工具协作

00:08:21.400 --> 00:08:23.860
差一步整个结果就不能用

00:08:23.860 --> 00:08:24.940
从这个角度看

00:08:24.940 --> 00:08:28.540
Spark 1.3根本不是一个聊天更厉害的模型

00:08:28.540 --> 00:08:30.720
而是一个干活更稳的模型

00:08:30.720 --> 00:08:33.580
它的评价标准早就不是会不会写诗

00:08:33.580 --> 00:08:34.940
能不能解数学题

00:08:34.940 --> 00:08:36.960
而是能不能在100步之后

00:08:36.960 --> 00:08:38.780
还不偏离最初的目标

00:08:38.780 --> 00:08:40.580
聊完了官方自己讲的升级

00:08:40.580 --> 00:08:43.220
我们来看看第三方独立评测的数据

00:08:43.220 --> 00:08:46.300
验证一下这些能力到底有没有落到实处

00:08:46.300 --> 00:08:48.880
这次的数据全部来自Artificial Analysis

00:08:48.880 --> 00:08:52.800
这是目前业界专门做代理人模型评测的独立机构

00:08:52.800 --> 00:08:54.400
不是Meta自己跑的分

00:08:54.400 --> 00:08:56.120
参考价值相对高一些

00:08:56.120 --> 00:08:58.760
在他们的综合智慧指数榜单上

00:08:58.760 --> 00:09:02.140
Spark 1.3的Shy版本拿到61分

00:09:02.140 --> 00:09:06.220
还在有限预览阶段的Max版本拿到62分

00:09:06.220 --> 00:09:08.400
比起1.2版本的57分

00:09:08.400 --> 00:09:10.360
Exia整整涨了4分

00:09:10.360 --> 00:09:15.300
在AI评测里 4分的涨幅算不算大 要看在哪个区间

00:09:15.300 --> 00:09:19.300
如果从30分涨到34分 那只是入门级的进步

00:09:19.300 --> 00:09:24.320
但从57分涨到61分已经是第一梯队模型的明显提升

00:09:24.320 --> 00:09:27.080
因为越往上 每一分的难度都越高

00:09:27.080 --> 00:09:32.200
更有竞争力的其实是成本XJ版本完成一项综合指数任务

00:09:32.200 --> 00:09:37.980
平均花费0.55美元 在所有得分超过59分的模型里是最低的

00:09:37.980 --> 00:09:39.760
我们可以简单对比一下

00:09:39.760 --> 00:09:40.640
同级别里

00:09:40.640 --> 00:09:43.040
OpenAI的GPT-4O Advanced

00:09:43.040 --> 00:09:44.100
做类似任务

00:09:44.100 --> 00:09:45.560
大概要1.2美元

00:09:45.560 --> 00:09:47.700
Anthropic的Cloud Opus

00:09:47.700 --> 00:09:49.500
则要1.5美元左右

00:09:49.500 --> 00:09:51.620
Meta差不多只要一半的价格

00:09:51.620 --> 00:09:54.980
这对于需要大量呼叫API的企业用户来说

00:09:54.980 --> 00:09:56.300
吸引力非常大

00:09:56.300 --> 00:09:58.560
我们再拆开看具体任务的表现

00:09:58.560 --> 00:10:00.280
Tile3-Bench Banking

00:10:00.280 --> 00:10:02.680
是专门的银行代理人基准测试

00:10:02.680 --> 00:10:05.240
模拟金融场景下的多步骤任务

00:10:05.240 --> 00:10:06.340
1.2版本

00:10:06.340 --> 00:10:08.740
当时只拿到35%的通过率

00:10:08.740 --> 00:10:10.960
SHAE版本提升到47%

00:10:10.960 --> 00:10:13.640
MAX版本更是达到52%

00:10:13.640 --> 00:10:15.360
这个涨幅其实相当惊人

00:10:15.360 --> 00:10:17.260
说明模型在处理合规

00:10:17.260 --> 00:10:20.240
要求高步骤繁琐的金融任务时

00:10:20.240 --> 00:10:22.840
可靠性比上一代强了很多

00:10:22.840 --> 00:10:24.000
但也要客观说

00:10:24.000 --> 00:10:25.580
47%的通过率

00:10:25.580 --> 00:10:27.720
依然代表超过一半的任务

00:10:27.720 --> 00:10:29.040
没办法完美完成

00:10:29.040 --> 00:10:31.040
距离真正取代人类专员

00:10:31.040 --> 00:10:32.780
还有非常远的距离

00:10:32.780 --> 00:10:35.700
大概相当于入行半年的助理水平

00:10:35.700 --> 00:10:38.980
Terminal-Bench 2.1是终端指令执行测试

00:10:38.980 --> 00:10:41.300
1.2版本通过率80%

00:10:41.300 --> 00:10:43.600
X-Shy提升到85%

00:10:43.600 --> 00:10:45.300
Max到86%

00:10:45.300 --> 00:10:46.620
这个分数看起来很高

00:10:46.620 --> 00:10:48.640
但终端任务相对结构化

00:10:48.640 --> 00:10:50.500
指令对错的标准很明确

00:10:50.500 --> 00:10:52.240
能拿到高分并不意外

00:10:52.240 --> 00:10:54.600
参考价值不如真实工作场景

00:10:54.600 --> 00:10:57.320
真正值得注意的反而是一项退步的指标

00:10:57.320 --> 00:11:00.100
AA-LCR长上下文基准

00:11:00.100 --> 00:11:02.660
1.2版本有83%的正确率

00:11:02.660 --> 00:11:05.240
1.3版本降到了79%

00:11:05.240 --> 00:11:07.900
为什么长上下文能力反而退步了

00:11:07.900 --> 00:11:10.060
难道模型越更新越差吗

00:11:10.060 --> 00:11:10.920
当然不是

00:11:10.920 --> 00:11:13.840
背后的原因是Spark 1.3调整了策略

00:11:13.840 --> 00:11:15.140
遇到不确定的资讯

00:11:15.140 --> 00:11:16.800
它更倾向于拒绝回答

00:11:16.800 --> 00:11:18.660
而不是硬猜一个答案

00:11:18.660 --> 00:11:20.780
也就是说它宁可少说几句

00:11:20.780 --> 00:11:22.000
也不说错话

00:11:22.000 --> 00:11:25.660
这种策略在AA-Omniscience准确率指标上

00:11:25.660 --> 00:11:26.500
也能看出来

00:11:26.500 --> 00:11:28.620
表面上准确率小幅回落

00:11:28.620 --> 00:11:30.880
但幻觉率明显降低了

00:11:30.880 --> 00:11:33.300
这其实是一个非常重要的取舍

00:11:33.300 --> 00:11:34.960
你要更高的召回率

00:11:34.960 --> 00:11:36.760
还是更高的准确率

00:11:36.760 --> 00:11:38.060
对于普通用户来说

00:11:38.060 --> 00:11:39.720
可能希望AI什么都能答

00:11:39.720 --> 00:11:41.260
哪怕错一点也没关系

00:11:41.260 --> 00:11:42.540
但对于企业用户

00:11:42.540 --> 00:11:45.300
尤其是金融 医疗 法律这些领域

00:11:45.300 --> 00:11:46.560
一个错误的答案

00:11:46.560 --> 00:11:48.620
代价可能比没有答案大得多

00:11:48.620 --> 00:11:51.160
之前就有企业用初代代理人模型

00:11:51.160 --> 00:11:52.440
处理报销审核

00:11:52.440 --> 00:11:55.500
结果模型编造了很多不存在的单据

00:11:55.500 --> 00:11:57.600
造成了不小的财务漏洞

00:11:57.600 --> 00:12:00.000
所以现在越是面向企业的模型

00:12:00.000 --> 00:12:03.660
越把不编造放在比达对更高的优先级

00:12:03.660 --> 00:12:04.760
从这个角度看

00:12:04.760 --> 00:12:06.980
这项退步反而是一种进步

00:12:06.980 --> 00:12:09.500
代表模型开始往实用化的方向走

00:12:09.500 --> 00:12:11.700
而不是为了跑分应凑答案

00:12:11.700 --> 00:12:13.340
另外很多人忽略的一点是

00:12:13.340 --> 00:12:15.480
MAX版本的分数虽然更高

00:12:15.480 --> 00:12:18.200
但代价是运算算力大幅增加

00:12:18.200 --> 00:12:20.480
根据Artificial Analysis的测试

00:12:20.480 --> 00:12:23.560
在GDPVAL-AAVFE任务里

00:12:23.560 --> 00:12:27.540
MAX版本比SY多消耗约62%的推理量

00:12:27.540 --> 00:12:29.540
就算是银行代理任务

00:12:29.540 --> 00:12:31.780
也多了28%的算力

00:12:31.780 --> 00:12:33.180
为什么会差这么多

00:12:33.180 --> 00:12:36.060
因为MAX版本会做更多的自我检查

00:12:36.060 --> 00:12:37.620
走更多的思维步骤

00:12:37.620 --> 00:12:41.200
相当于人做事情的时候反复检查好几遍

00:12:41.200 --> 00:12:43.260
自然更费时间更费算力

00:12:43.260 --> 00:12:44.860
但正确率也更高

00:12:44.860 --> 00:12:48.400
这其实带出了未来AI商业模式的一个可能方向

00:12:48.400 --> 00:12:50.500
以后的模型不会只有单一档位

00:12:50.500 --> 00:12:54.000
而是会根据任务的风险等级调整推理强度

00:12:54.000 --> 00:12:55.140
低风险的闲聊

00:12:55.140 --> 00:12:58.180
查资料用低档速度快又便宜

00:12:58.180 --> 00:12:59.480
高风险的财务

00:12:59.480 --> 00:13:01.180
法律任务用高档

00:13:01.180 --> 00:13:03.220
更慢 更贵 但更可靠

00:13:03.220 --> 00:13:05.160
用户可以按自己的需求选

00:13:05.160 --> 00:13:07.020
而不是为了偶尔的高需求

00:13:07.020 --> 00:13:08.940
全程付最贵的价格

00:13:08.940 --> 00:13:10.860
当然 目前这还只是观察

00:13:10.860 --> 00:13:13.820
Meta并没有正式推出这种分级定价

00:13:13.820 --> 00:13:15.220
但从技术设计上

00:13:15.220 --> 00:13:17.020
已经具备了这样的基础

00:13:17.020 --> 00:13:18.660
最后 还要再强调一次

00:13:18.660 --> 00:13:20.800
Max版本目前只是有限预览

00:13:20.800 --> 00:13:23.540
只有少数合作机构和企业能拿到权限

00:13:23.540 --> 00:13:25.440
普通开发者根本呼叫不到

00:13:25.440 --> 00:13:27.920
所以你看到62分那个数字的时候

00:13:27.920 --> 00:13:30.420
要知道它背后是更高的成本

00:13:30.420 --> 00:13:32.300
更严格的访问限制

00:13:32.300 --> 00:13:35.400
不能拿它去跟别人全面开放的API比

00:13:35.400 --> 00:13:37.160
然后说Meta已经赢了

00:13:37.160 --> 00:13:38.580
这种对比并不公平

00:13:38.580 --> 00:13:40.920
看完了负责思考和执行的大脑

00:13:40.920 --> 00:13:44.220
我们再转过头来讲这次连发的另一款产品

00:13:44.220 --> 00:13:46.000
负责感知输入的耳朵

00:13:46.000 --> 00:13:47.480
Muse Voice Transcribe

00:13:47.480 --> 00:13:48.980
很多人第一眼看到它

00:13:48.980 --> 00:13:51.280
会觉得不就是个语音转文字吗

00:13:51.280 --> 00:13:52.360
有什么特别的

00:13:52.360 --> 00:13:53.980
但实际上它的设计思路

00:13:53.980 --> 00:13:56.720
跟传统的自动语音识别完全不一样

00:13:56.720 --> 00:13:58.640
传统的ASR比如Whisper

00:13:58.640 --> 00:14:00.440
走的是离线转写路线

00:14:00.440 --> 00:14:02.840
拿到整段音频之后再慢慢处理

00:14:02.840 --> 00:14:04.840
可以利用上下文反复修正

00:14:04.840 --> 00:14:05.880
准确率很高

00:14:05.880 --> 00:14:06.960
但延迟也大

00:14:06.960 --> 00:14:09.560
根本没办法用来做实时对话

00:14:09.560 --> 00:14:11.380
而以前的实时语音助手

00:14:11.380 --> 00:14:13.940
比如手机上的Siri Google助理

00:14:13.940 --> 00:14:15.320
为了追求低延迟

00:14:15.320 --> 00:14:17.540
只能听一小段就马上输出

00:14:17.540 --> 00:14:19.160
结果准确率很差

00:14:19.160 --> 00:14:20.140
稍微吵一点

00:14:20.140 --> 00:14:22.960
有两个人叠话或者混个外文单字

00:14:22.960 --> 00:14:24.020
结果就歪掉

00:14:24.020 --> 00:14:25.960
Muse Voice Transcribe想解决的

00:14:25.960 --> 00:14:27.600
就是又要准又要快

00:14:27.600 --> 00:14:29.840
还要懂真实对话这个老难题

00:14:29.840 --> 00:14:32.960
它的做法是把音频切成80毫秒的小块

00:14:32.960 --> 00:14:34.940
每秒处理12月5日次

00:14:34.940 --> 00:14:37.980
每一小块音频先转换成一个软Token

00:14:37.980 --> 00:14:41.080
模型在判断是要继续等后面的声音

00:14:41.080 --> 00:14:42.760
还是立刻输出文字

00:14:42.760 --> 00:14:44.500
等到音频完全停止

00:14:44.500 --> 00:14:46.620
系统会加入一个特殊标记

00:14:46.620 --> 00:14:50.440
让模型把剩下没输出的文字一口气吐出来

00:14:50.440 --> 00:14:53.500
其中最关键的技术叫做自适应延迟

00:14:53.500 --> 00:14:57.080
模型不会给每个字都设定一样的等待时间

00:14:57.080 --> 00:14:59.480
简单确定的内容就立刻输出

00:14:59.480 --> 00:15:02.220
碰到需要后文才能判断的同音词

00:15:02.220 --> 00:15:03.140
专有名词

00:15:03.140 --> 00:15:05.940
就稍微多等一点点音频再决定

00:15:05.940 --> 00:15:08.160
这其实很像人类的同步口译

00:15:08.160 --> 00:15:10.060
译员会根据句子的难度

00:15:10.060 --> 00:15:11.680
调整自己的滞后时间

00:15:11.680 --> 00:15:13.040
不会一味求快

00:15:13.040 --> 00:15:14.400
也不会一味求准

00:15:14.400 --> 00:15:15.180
训练的时候

00:15:15.180 --> 00:15:17.540
Meta把词 错误率和延迟时间

00:15:17.540 --> 00:15:20.180
一起放进强化学习的奖励函数里

00:15:20.180 --> 00:15:21.900
如果模型只追求准确

00:15:21.900 --> 00:15:23.280
每句话都等很久

00:15:23.280 --> 00:15:24.240
得分不会高

00:15:24.240 --> 00:15:25.400
只追求速度

00:15:25.400 --> 00:15:27.900
输出一大堆错字同样过不了关

00:15:27.900 --> 00:15:32.460
最终目标就是在准确率和反应速度之间找到最佳平衡点

00:15:32.460 --> 00:15:33.680
那实际表现如何

00:15:33.680 --> 00:15:37.060
在Artificial Analysis的流逝语音榜单上

00:15:37.060 --> 00:15:42.060
Muse Voice Transcribe的最终词错误率约3.1%

00:15:42.060 --> 00:15:43.460
直接登上第一名

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

00:15:58.114 --> 00:16:00.094
不过这里必须先打个预防针

00:16:00.094 --> 00:16:02.894
这个成绩是英语流逝对话的测试结果

00:16:02.894 --> 00:16:06.374
绝对不能直接套用到所有语言 所有场景

00:16:06.374 --> 00:16:08.834
中文因为同音字多 声调复杂

00:16:08.834 --> 00:16:13.214
同样的模型词错误率通常会比英语高2到3个百分点

00:16:13.214 --> 00:16:17.294
如果是嘈杂环境 多人强化 或者带方言口音

00:16:17.294 --> 00:16:19.014
表现还会再打折扣

00:16:19.014 --> 00:16:22.834
官方也明确说 模型训练覆盖了70多种语言

00:16:22.834 --> 00:16:25.734
其中只有25种经过充分验证

00:16:25.734 --> 00:16:27.834
其他语言可能只是有训练过

00:16:27.834 --> 00:16:30.234
但没有经过严格的效果评测

00:16:30.234 --> 00:16:32.134
除了基础的转写准确率

00:16:32.134 --> 00:16:34.194
还有几个功能特别值得一提

00:16:34.194 --> 00:16:36.714
首先是原生的说话人分离

00:16:36.714 --> 00:16:39.334
而且支持20人以上同时发言

00:16:39.334 --> 00:16:42.094
传统的会议转写通常是先做语音识别

00:16:42.094 --> 00:16:44.014
再另外用一套声文系统

00:16:44.014 --> 00:16:45.714
判断每段话是谁说的

00:16:45.714 --> 00:16:47.194
两个系统的时间轴

00:16:47.194 --> 00:16:49.354
只要差一点点就会出现文字

00:16:49.354 --> 00:16:50.474
人认错的情况

00:16:50.474 --> 00:16:52.814
Meta是在同一个生成过程里

00:16:52.814 --> 00:16:55.674
加入说话人切换标记和身份标签

00:16:55.674 --> 00:16:58.434
检测到换人就先标一轮新发言

00:16:58.434 --> 00:17:00.894
等听到足够声音再确定身份

00:17:00.894 --> 00:17:03.014
时间轴的准确度会高很多

00:17:03.014 --> 00:17:06.214
官方展示的长对话里包含多人插话

00:17:06.214 --> 00:17:08.314
重叠发言 自然停顿

00:17:08.314 --> 00:17:10.194
都能正确标记身份

00:17:10.194 --> 00:17:13.734
这对于会议记录 访谈整理 客服记录来说

00:17:13.734 --> 00:17:14.674
价值很高

00:17:14.674 --> 00:17:18.214
因为后续的摘要系统拿到的不只是一整段文字

00:17:18.214 --> 00:17:20.894
还知道谁提了问题 谁做了承诺

00:17:20.894 --> 00:17:22.234
谁反对哪个方案

00:17:22.234 --> 00:17:23.974
其次是端点侦测能力

00:17:23.974 --> 00:17:27.474
人类对话本来就不会每次讲完都按个结束钮

00:17:27.474 --> 00:17:30.794
系统要从语气停顿和上下文判断

00:17:30.794 --> 00:17:33.474
对方只是喘口气还是真的说完了

00:17:33.474 --> 00:17:35.014
如果端点判断不准

00:17:35.014 --> 00:17:36.694
要么用户都讲完半天了

00:17:36.694 --> 00:17:37.774
助手还没反应

00:17:37.774 --> 00:17:39.234
要么用户还没说完

00:17:39.234 --> 00:17:41.494
助手就急着插嘴体验都很差

00:17:41.494 --> 00:17:42.814
Muse Voice Transcribe

00:17:42.814 --> 00:17:44.654
专门针对这点做了优化

00:17:44.654 --> 00:17:47.514
能更准确判断语音的开始和结束

00:17:47.514 --> 00:17:50.014
这也是代理人能自然对话的前提

00:17:50.014 --> 00:17:51.894
第三个很实用的功能是

00:17:51.894 --> 00:17:54.594
句内和句间的多语言自由切换

00:17:54.594 --> 00:17:56.134
还有上下文偏制

00:17:56.134 --> 00:17:58.374
现实中很多双语使用者

00:17:58.374 --> 00:18:00.574
不会先切语言模式再讲话

00:18:00.574 --> 00:18:02.994
中文句子里夹个英文专有名词

00:18:02.994 --> 00:18:05.274
项目代号是家常便饭

00:18:05.274 --> 00:18:06.954
旧的系统很容易把英文词

00:18:06.954 --> 00:18:08.994
应转成发音相近的中文字

00:18:08.994 --> 00:18:11.494
或者切换语言之后直接丢了半句话

00:18:11.494 --> 00:18:12.994
Muse Voice Transcribe

00:18:12.994 --> 00:18:15.294
支持70多种语言的自由切换

00:18:15.294 --> 00:18:18.254
还可以让用户提前输入常用的人名

00:18:18.254 --> 00:18:19.734
公司名专业术语

00:18:19.734 --> 00:18:21.714
模型碰到相近发音的时候

00:18:21.714 --> 00:18:24.994
会优先选择这些符合上下文的词

00:18:24.994 --> 00:18:27.654
比如医生可以提前录入药品名称

00:18:27.654 --> 00:18:30.914
城市设计师可以加入函数名和项目代号

00:18:30.914 --> 00:18:33.594
企业用户可以上传内部数语表

00:18:33.594 --> 00:18:36.014
这样转写的准确率会大幅提升

00:18:36.014 --> 00:18:38.154
甚至可以直接进入工作流程

00:18:38.154 --> 00:18:39.714
不用再人工校对一遍

00:18:39.714 --> 00:18:42.054
这才是语音转写真正的价值

00:18:42.054 --> 00:18:44.254
不是把声音变成文字就好

00:18:44.254 --> 00:18:46.234
而是变成能直接用的文字

00:18:46.234 --> 00:18:47.874
目前Muse Voice Transcribe

00:18:47.874 --> 00:18:49.614
已经接入Meta Model API

00:18:49.614 --> 00:18:52.774
还有Meta AI4 Mac Muse Code Mac版本

00:18:52.774 --> 00:18:55.494
用户可以按住FN键直接语音输入

00:18:55.494 --> 00:18:58.314
把转写结果送到不同的应用程式里

00:18:58.314 --> 00:19:00.834
不过有个隐私细节一定要讲清楚

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

00:19:04.734 --> 00:19:05.614
不会被保存

00:19:05.614 --> 00:19:08.394
但这个承诺只限于网页演示场景

00:19:08.394 --> 00:19:10.254
不等于所有API呼叫

00:19:10.254 --> 00:19:13.014
所有产品部署都不会保存音频

00:19:13.014 --> 00:19:15.354
如果你是透过API上传录音

00:19:15.354 --> 00:19:16.694
Meta会不会保存

00:19:16.694 --> 00:19:17.554
保存多久

00:19:17.554 --> 00:19:19.254
会不会用来训练模型

00:19:19.254 --> 00:19:22.774
都要看你签署的服务条款和数据处理协议

00:19:22.774 --> 00:19:24.714
不能因为网页演示不保存

00:19:24.714 --> 00:19:28.074
就理所当然认为所有场景都不保存

00:19:28.074 --> 00:19:30.994
这在个资合规上是非常危险的认知

00:19:30.994 --> 00:19:33.534
讲到这里就必须好好聊一下

00:19:33.534 --> 00:19:35.034
隐私与安全的边界

00:19:35.034 --> 00:19:37.354
这也是很多人看AI产品的时候

00:19:37.354 --> 00:19:40.374
最容易忽略但绝对最重要的部分

00:19:40.374 --> 00:19:42.854
先讲Muse Spark 1.3的安全设计

00:19:42.854 --> 00:19:45.254
官方说这次提升了对提示注入

00:19:45.254 --> 00:19:47.294
和对抗输入的抵抗能力

00:19:47.294 --> 00:19:49.994
也更能识别哪些操作是不可逆的

00:19:49.994 --> 00:19:51.054
提示注入是什么

00:19:51.054 --> 00:19:53.254
就是攻击者在输入内容里

00:19:53.254 --> 00:19:55.274
嵌入看不见的恶意指令

00:19:55.274 --> 00:19:57.314
比如藏在PDF档案里

00:19:57.314 --> 00:19:58.114
网页里

00:19:58.114 --> 00:20:00.834
诱导AI代理人忽略原本的规则

00:20:00.834 --> 00:20:02.554
去转发机密档案

00:20:02.554 --> 00:20:03.974
修改设定甚至转账

00:20:03.974 --> 00:20:06.434
2025年就曾经出现过

00:20:06.434 --> 00:20:07.714
类似的攻击案例

00:20:07.714 --> 00:20:10.754
让不少企业对AI代理人望而却步

00:20:10.754 --> 00:20:13.774
Spark 1.3针对这类攻击做了专门训练

00:20:13.774 --> 00:20:15.594
但这不代表它完全免疫

00:20:15.594 --> 00:20:19.874
目前没有任何模型能100%防御所有提示注入攻击

00:20:19.874 --> 00:20:21.594
识别不可逆操作也是一样

00:20:21.594 --> 00:20:23.394
模型能标出删除档案

00:20:23.394 --> 00:20:24.574
发送批量邮件

00:20:24.574 --> 00:20:26.934
修改数据库这些高风险动作

00:20:26.934 --> 00:20:28.334
要求用户确认

00:20:28.334 --> 00:20:31.114
但光有模型层面的防护远远不够

00:20:31.114 --> 00:20:33.814
官方自己也强调实际部署的时候

00:20:33.814 --> 00:20:36.374
必须同时做好全线隔离

00:20:36.374 --> 00:20:38.454
白名单和操作日志

00:20:38.454 --> 00:20:41.514
全线隔离就是给代理人最小必要的全线

00:20:41.514 --> 00:20:43.754
比如负责整理表格的助理

00:20:43.754 --> 00:20:46.534
就不该有删除整个资料夹的权限

00:20:46.534 --> 00:20:50.654
白名单就是只允许模型呼叫预先核准的

00:20:50.654 --> 00:20:54.834
工具和API不能让它随便访问系统里的任何东西

00:20:54.834 --> 00:20:58.954
操作日志就是把代理人所有执行动作都记录下来

00:20:58.954 --> 00:21:01.134
方便事后审计和回溯

00:21:01.134 --> 00:21:04.334
这三层防护都是资安领域的基本常识

00:21:04.334 --> 00:21:07.754
却也是很多AI产品最容易省略的部分

00:21:07.754 --> 00:21:09.614
Meta愿意主动强调这点

00:21:09.614 --> 00:21:13.234
说明它是真的在考虑企业落地的实际需求

00:21:13.234 --> 00:21:15.894
而不是只做展示用的技术demo

00:21:15.894 --> 00:21:16.974
再回到语音部分

00:21:16.974 --> 00:21:19.874
当语音转写加上代理人执行

00:21:19.874 --> 00:21:23.534
再搭配Meta旗下的ray减班智慧眼镜

00:21:23.534 --> 00:21:25.214
想象空间确实很大

00:21:25.214 --> 00:21:28.694
手机上的语音助手要等你点开APP才能用

00:21:28.694 --> 00:21:30.854
但眼镜可以一直戴在脸上

00:21:30.854 --> 00:21:32.794
随时处在声音环境里

00:21:32.794 --> 00:21:34.574
如果他能听懂谁在讲话

00:21:34.574 --> 00:21:35.814
什么时候该接话

00:21:35.814 --> 00:21:37.134
什么时候不该插嘴

00:21:37.134 --> 00:21:39.954
就能在会议后自动整理每个人的行动项

00:21:39.954 --> 00:21:42.014
访谈的时候自动标记重点

00:21:42.014 --> 00:21:46.134
甚至日常聊天里提到的代办事项都能自动记下来

00:21:46.134 --> 00:21:48.634
但这也带来了更尖锐的隐私问题

00:21:48.634 --> 00:21:50.974
眼镜上的麦克风什么时候在听

00:21:50.974 --> 00:21:52.874
听到的内容传到哪里去了

00:21:52.874 --> 00:21:54.914
用户有没有明确的控制权

00:21:54.914 --> 00:21:57.234
旁边的人知不知道自己正在被录音

00:21:57.234 --> 00:22:00.234
这些问题目前都还没有完全公开的答案

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

00:22:04.274 --> 00:22:06.954
未来轻量级的语音转写

00:22:06.954 --> 00:22:08.534
简单的指令理解

00:22:08.534 --> 00:22:12.294
很可能会直接跑在眼镜本地的端侧芯片上

00:22:12.294 --> 00:22:13.534
不需要传到云端

00:22:13.534 --> 00:22:15.294
敏感数据不会离开设备

00:22:15.294 --> 00:22:17.034
大幅降低隐私风险

00:22:17.034 --> 00:22:18.774
而复杂的常任务代理

00:22:18.774 --> 00:22:19.934
多工具协作

00:22:19.934 --> 00:22:22.694
再交给云端的Spark模型处理

00:22:22.694 --> 00:22:25.634
刚好Meta有Glimmer这条本地开源路线

00:22:25.634 --> 00:22:27.694
专门做轻量化端侧部署

00:22:27.694 --> 00:22:30.634
刚好可以跟眼镜这类终端装置搭配

00:22:30.634 --> 00:22:32.334
云端负责复杂思考

00:22:32.334 --> 00:22:34.034
本地负责实时感知

00:22:34.034 --> 00:22:36.274
既保证体验又兼顾隐私

00:22:36.274 --> 00:22:40.194
这很可能就是Meta下一代AI入口的完整架构

00:22:40.194 --> 00:22:42.834
当然这只是基于现有产品线的推测

00:22:42.834 --> 00:22:44.754
官方还没有证实这个方向

00:22:44.754 --> 00:22:46.794
讲完了技术亮点和想象空间

00:22:46.794 --> 00:22:48.234
我们也得冷静下来

00:22:48.234 --> 00:22:51.154
聊聊这次发布的口径边界和实际风险

00:22:51.154 --> 00:22:54.114
首先Max版本目前只是有线预览

00:22:54.114 --> 00:22:56.514
普通开发者能用的只有Shi版本

00:22:56.514 --> 00:22:58.834
网上所有关于Max的评测数据

00:22:58.834 --> 00:23:01.034
都来自少数拿到权限的机构

00:23:01.034 --> 00:23:03.074
一般用户现在根本用不到

00:23:03.074 --> 00:23:07.054
所以62分那个数字只能当成技术上限的参考

00:23:07.054 --> 00:23:10.094
不能作为采购或者使用决策的依据

00:23:10.094 --> 00:23:12.414
其次所有的基准测试数据

00:23:12.414 --> 00:23:15.414
都是在标准化的干净环境里跑出来的

00:23:15.414 --> 00:23:19.494
真实世界的场景只会更复杂更混乱

00:23:19.494 --> 00:23:22.494
比如银行代理测试里的数据都是结构化的

00:23:22.494 --> 00:23:24.154
格式统一全线清晰

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

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

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

00:23:43.787 --> 00:23:46.327
第三 关于开源的期待也要放低

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

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

00:24:01.247 --> 00:24:06.807
而且早期都是非商业授权 要等到更后面才会用更宽松的授权

00:24:06.807 --> 00:24:10.007
所以不要期待短期内就能在自己的电脑上

00:24:10.007 --> 00:24:12.987
跑Spark 1.3核心的代理人能力

00:24:12.987 --> 00:24:16.127
Meta肯定会先握在手里当商业护城河

00:24:16.127 --> 00:24:18.087
最后回到产业竞争的层面

00:24:18.087 --> 00:24:20.447
Meta这次的更新确实扎实

00:24:20.447 --> 00:24:25.027
在代理人可靠性和流逝语音转写上都往前走了一步

00:24:25.027 --> 00:24:27.327
成本控制也做得很有竞争力

00:24:27.327 --> 00:24:29.227
但要说已经赢了还太早

00:24:29.227 --> 00:24:33.127
OpenEye的GPT系列代理人能力同样在快速迭代

00:24:33.127 --> 00:24:37.847
谷歌的Gemini在多模态和端侧整合上有自己的优势

00:24:37.847 --> 00:24:42.527
Anthropic在长上下文和安全合规上依然领先

00:24:42.527 --> 00:24:46.927
还有Eleven Labs这类专业语音公司也在往代理人方向走

00:24:46.927 --> 00:24:52.547
Meta现在的领先更像是某几个细分场景的小幅度领先

00:24:52.547 --> 00:24:55.207
还远没有到拉开差距的程度

00:24:55.207 --> 00:24:58.527
而且真正的竞争从来都不是比模型本身

00:24:58.527 --> 00:25:02.807
而是比谁能先把技术变成用户愿意天天用的产品

00:25:02.807 --> 00:25:04.927
谁能解决好隐私安全

00:25:04.927 --> 00:25:06.967
权限这些麻烦的落地问题

00:25:06.967 --> 00:25:08.247
模型再聪明

00:25:08.247 --> 00:25:10.887
如果用户不敢把重要的工作交给他

00:25:10.887 --> 00:25:12.587
那也只是个高级玩具

00:25:12.587 --> 00:25:13.167
讲到这里

00:25:13.167 --> 00:25:16.007
我们把这次Meta两款产品的技术细节

00:25:16.007 --> 00:25:16.947
评测数据

00:25:16.947 --> 00:25:18.107
产品线定位

00:25:18.107 --> 00:25:19.027
隐私风险

00:25:19.027 --> 00:25:21.187
还有产业格局全部拆完了

00:25:21.187 --> 00:25:23.667
你会发现每一个亮眼的数据背后

00:25:23.667 --> 00:25:25.307
都有一个限定条件

00:25:25.307 --> 00:25:27.067
每一项技术突破的旁边

00:25:27.067 --> 00:25:29.227
都站着一个带解决的问题

00:25:29.227 --> 00:25:30.947
这不是说Meta做得不好

00:25:30.947 --> 00:25:32.047
恰恰相反

00:25:32.047 --> 00:25:34.567
只有当你看清了所有的边界和限制

00:25:34.567 --> 00:25:36.587
才能真正评估它的价值

00:25:36.587 --> 00:25:41.227
Muse Spark 1.3确实把常任务代理人的可靠性往前推了一步

00:25:41.227 --> 00:25:43.027
成本优势也很明显

00:25:43.027 --> 00:25:46.167
Muse Voice Transcribe在英语流逝转写上

00:25:46.167 --> 00:25:48.187
做到了业界顶尖

00:25:48.187 --> 00:25:50.827
准确率和延迟的平衡做得可圈可点

00:25:50.827 --> 00:25:53.427
但它们都还只是阶段性的进展

00:25:53.427 --> 00:25:56.067
离大家想象中什么都能做的AI助理

00:25:56.067 --> 00:25:57.647
还有非常远的距离

00:25:57.647 --> 00:25:59.707
2026年的AI产业

00:25:59.707 --> 00:26:02.607
其实正在经历一个很重要的转向

00:26:02.607 --> 00:26:05.447
前几年大家都在比谁的模型更大

00:26:05.447 --> 00:26:06.747
谁的跑分更高

00:26:06.747 --> 00:26:08.627
谁的牛皮吹得更响

00:26:08.627 --> 00:26:12.087
但从今年开始竞争慢慢落到了实处

00:26:12.087 --> 00:26:14.167
比的是谁能把长任务做稳

00:26:14.167 --> 00:26:15.927
谁能把真实声音听懂

00:26:15.927 --> 00:26:17.727
谁能让企业敢放心用

00:26:17.727 --> 00:26:20.227
谁能把隐私控制在合理范围

00:26:20.227 --> 00:26:22.847
那些看起来不怎么耀眼的细节优化

00:26:22.847 --> 00:26:27.407
反而决定了产品能不能真正走进日常生活和工作流

00:26:27.407 --> 00:26:28.267
就像造车

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

00:26:36.447 --> 00:26:39.987
这些才是决定你愿不愿意每天开的关

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

00:26:45.347 --> 00:26:48.947
欢迎订阅这个频道 并且打开通知小铃铛

00:26:48.947 --> 00:26:54.787
我们会持续追踪AI代理人 语音交互 端策AI这些领域的最新进展

00:26:54.787 --> 00:26:57.307
帮你过滤掉夸大的营销话术

00:26:57.307 --> 00:26:59.727
留下真正值得关注的技术变化

00:26:59.727 --> 00:27:01.327
也欢迎在留言区告诉我

00:27:01.327 --> 00:27:04.287
你最期待AI帮你完成什么样的任务

00:27:04.287 --> 00:27:05.927
是整理会议记录

00:27:05.927 --> 00:27:07.887
还是处理繁琐的文书工作

00:27:07.887 --> 00:27:09.647
我们下期影片再见