Meta 真的超車了？實測 Muse Spark 1.3 與 Voice Transcribe：真能幹活還是行銷話術？

Nairoby Hiraldo 首頁 每日列表 原始影片
實際影片長度：27:10.000。原文、繁中、雙語可點擊句子跳轉影片。
0:00.000–0:02.300
zh你有没有过这种很无力的经验?
0:02.300–0:05.000
zh叫AI帮你整理一份跨部门的会议报告。
0:05.000–0:09.300
zh做到一半它忘了你要求的章节格式,用语音助手查形成。
0:09.300–0:13.700
zh旁边同事插句话,它就把指令听成完全不相干的内容。
0:13.700–0:20.500
zh只要任务超过三个步骤,需要跨两个以上工具,最后交付的结果一定歪掉大半。
0:20.500–0:23.667
zh你大概也听过很多人说AI已经很聪明了,
0:23.667–0:25.000
zh但真的拿来干活,
0:25.000–0:27.500
zh总是卡在这些最不起眼的小地方。
0:27.500–0:29.980
zh2026年9月的头两天
0:29.980–0:32.400
zhMeta接连丢出了两项更新
0:32.400–0:34.840
zh没有吹什么通用人工智能的牛皮
0:34.840–0:38.480
zh却精准踩中了这些大家天天吐槽的痛点
0:38.480–0:41.760
zh一个负责把真实世界里的声音听得更清楚
0:41.760–0:44.780
zh一个负责把复杂的常任务做得更稳
0:44.780–0:48.720
zh有人看完数据说Meta终于要在代理人战场超车了
0:48.720–0:50.420
zh也有人冷静算完成本
0:50.420–0:52.540
zh发现事情根本没有这么简单
0:52.540–0:54.180
zh今天我们就不吹不黑
0:54.180–0:57.220
zh把官方技术文件第三方独立评测
0:57.220–1:00.140
zh还有那些藏在角落的小字限制
1:00.140–1:01.840
zh全部摊开来讲
1:01.840–1:04.620
zh看看这两款产品到底走到了哪一步
1:04.620–1:07.300
zh又有哪些东西是营销不会告诉你的
1:07.300–1:08.860
zh我们不从结论讲起
1:08.860–1:12.280
zh因为真正有价值的判断往往都藏在每一个
1:12.280–1:13.380
zh但是后面
1:13.380–1:17.300
zh先帮大家把最容易搞混的产品线界限画清楚
1:17.300–1:20.100
zh这也是很多自媒体最常讲错的地方
1:20.100–1:24.160
zh9月1日登场的是Muse Voice Transcribe语音转写模型
1:24.160–1:28.160
zh9月2日接棒上线的是Muse Spark 1.3代理人模型
1:28.160–1:30.560
zh两天连续发布核心产品
1:30.560–1:34.340
zh这在Meta Superintelligence Labs的历史上并不常见
1:34.340–1:38.520
zh也能看出他们在2026年下半年的竞争焦虑
1:38.520–1:39.500
zh但更重要的是
1:39.500–1:41.780
zh很多人到现在还搞不清楚
1:41.780–1:43.960
zhMuse Spark和Muse Glimmer
1:43.960–1:46.860
zh根本是两条完全不同的路线
1:46.860–1:48.180
zh不能混为一谈
1:48.180–1:51.280
zhMuse Spark走的是云端前沿代理人路线
1:51.280–1:52.720
zh权重完全必圆
1:52.720–1:54.820
zh目前只开放API呼叫
1:54.820–1:57.560
zh官方只说未来有开放权重的规划
1:57.560–1:59.000
zh但既没有时间表
1:59.000–2:01.280
zh也没说会用哪种授权条款
2:01.280–2:03.420
zh所以你绝对不能把它理解成
2:03.420–2:05.700
zh马上就可以下载来本地跑
2:05.700–2:08.540
zh而Muse Glimmer是拥有300亿参数
2:08.540–2:11.860
zh采用Apache 2.0授权的本地方案
2:11.860–2:14.140
zh主打消费级显示卡就能执行
2:14.140–2:14.780
zh讲白一点
2:14.780–2:17.100
zhSpark负责把能力堆到最高
2:17.100–2:19.680
zh强企业级和高端开发者市场
2:19.680–2:21.840
zhGlimmer负责把能力扑到最广
2:21.840–2:24.100
zh占领开源生态和终端装置
2:24.100–2:28.680
zh这种双轨策略其实刚好对应了Meta在AI产业的定位转变
2:28.680–2:33.400
zh前几年大家提到Meta的AI第一个想到的就是Lama系列开源模型
2:33.400–2:34.960
zh靠免费打天下
2:34.960–2:37.980
zh跟OpenAI的全B原路线正面抗衡
2:37.980–2:40.060
zh但到了2026年
2:40.060–2:43.760
zh整个行业的竞争已经从比参数 比跑分
2:43.760–2:46.900
zh进到比代理人 比落地场景的阶段
2:46.900–2:50.140
zhMeta必须拿出足够强的B原顶端产品
2:50.140–2:51.600
zh才能跟GPT系列
2:51.600–2:53.700
zhGemini系列抢商业客户
2:53.700–2:56.760
zh同时又不能丢掉开源生态的优势
2:56.760–2:59.240
zh为什么要花这么多时间讲这件事
2:59.240–3:00.540
zh因为如果你误以为
3:00.540–3:02.580
zhSpark 1.3是开源模型
3:02.580–3:04.660
zh就会产生错误的部署预期
3:04.660–3:08.220
zh如果你以为Glimmer只是Spark的缩小版
3:08.220–3:11.700
zh就会低估两者在设计目标上的根本差异
3:11.700–3:13.160
zh另外从迭代节奏来看
3:13.160–3:15.500
zhMuse系列从7月的1.1版
3:15.500–3:17.360
zh首次连上邮件行事例
3:17.360–3:23.160
zh并能制作投影片到8月初1.2版聚焦大型程式库与复杂真错
3:23.160–3:25.700
zh甚至能连续1000多次工具呼叫
3:25.700–3:30.260
zh在24小时内反复编写编译GPU核心程式
3:30.260–3:33.600
zh8月中再加入图像与视频理解能力
3:33.600–3:37.140
zh到9月的1.3版转向打磨长期任务的可用性
3:37.140–3:40.500
zh几乎保持每个月一次大版本更新的速度
3:40.500–3:43.000
zh这种快速迭代在AI圈不算稀奇
3:43.000–3:47.680
zh但难得的是Meta几乎每一版都会附上明确的内部对比数据
3:47.680–3:49.960
zh同时引用第三方评测结果
3:49.960–3:52.880
zh给了外界一个相对透明的观察窗口
3:52.880–3:55.220
zh很多人只盯着分数涨了多少
3:55.220–3:58.020
zh却忽略了每一代版本的定位差异
3:58.020–4:02.200
zhSpark 1.3并不是全面碾压1.2的终极进化
4:02.200–4:05.600
zh而是针对代理人任务的可靠性做了针对性强化
4:05.600–4:09.420
zh甚至在部分涨上下文指标上还出现了小幅退步
4:09.420–4:11.240
zh这种有得有失的升级
4:11.240–4:14.860
zh恰恰说明模型能力不是简单的线性叠加
4:14.860–4:17.660
zh而是一连串的取舍与权衡
4:17.660–4:19.960
zh如果你只看营销文案里的亮点
4:19.960–4:23.140
zh很快就会在实际使用中发现落差
4:23.140–4:25.500
zh如果你翻完这次的全部技术文件
4:25.500–4:27.400
zh会发现最核心的关键词
4:27.400–4:28.760
zh不是更高的分数
4:28.760–4:30.280
zh也不是更多的参数
4:30.280–4:32.300
zh而是长任务代理人
4:32.300–4:33.440
zh什么意思
4:33.440–4:36.500
zh就是让AI不再只是一次性回答一个问题
4:36.500–4:39.160
zh而是像一个真正的执行助理一样
4:39.160–4:41.220
zh接下一个模糊的需求
4:41.220–4:43.480
zh自己拆解步骤 呼叫工具
4:43.480–4:44.880
zh遇到问题回头问你
4:44.880–4:46.100
zh碰到危险操作
4:46.100–4:49.380
zh先停下来确认最后再交付完整的成果
4:49.380–4:50.480
zh这听起来很美好
4:50.480–4:53.680
zh但过去大部分代理人模型的问题无非三种
4:53.680–4:55.880
zh要么不敢动手只会空泛回答
4:55.880–4:58.680
zh要么乱动手做到一半偏离目标
4:58.680–5:02.000
zh更常见的是干到一半彻底忘了最原始的要求
5:02.000–5:05.020
zhSpark 1.3就是冲着这些痛点做的优化
5:05.020–5:06.460
zh举个很实际的场景
5:06.460–5:07.620
zh如果你跟模型说
5:07.620–5:10.520
zh帮我整理上礼拜的三场客户会议记录
5:10.520–5:11.800
zh做成部门简报
5:11.800–5:14.120
zh把每个客户的行动项列出来
5:14.120–5:15.440
zh最后寄给主管
5:15.440–5:16.680
zh换做之前的模型
5:16.680–5:19.780
zh很可能做到一半就忘了要按客户分类
5:19.780–5:21.800
zh或者漏了寄信的步骤
5:21.800–5:24.980
zh甚至为了凑数编造几个不存在的行动项
5:24.980–5:27.920
zh而Spark 1.3的处理逻辑会完全不同
5:27.920–5:30.280
zh一开始如果觉得需求不够清楚
5:30.280–5:31.920
zh它会主动追问你
5:31.920–5:34.800
zh简报要的是正式版本还是讨论版
5:34.800–5:37.500
zh行动项要不要加上预计完成时间
5:37.500–5:40.440
zh寄信的时候要不要附上原始记录档
5:40.440–5:44.660
zh执行过程中如果发现某份会议记录打不开或者权限不足
5:44.660–5:46.580
zh它会停下来跟你要资讯
5:46.580–5:49.160
zh而不是硬着头皮编一个结果
5:49.160–5:50.460
zh如果碰到删除档案
5:50.460–5:51.640
zh发送批量邮件
5:51.640–5:55.080
zh修改正式环境设定这类有不可逆风险的操作
5:55.080–5:57.020
zh它一定会先跳出确认
5:57.020–5:58.480
zh问你确定要执行吗
5:58.480–5:59.980
zh不会自己直接动手
5:59.980–6:00.880
zh更重要的是
6:00.880–6:04.180
zh它能分辨你现在是在补充当前任务的资讯
6:04.180–6:06.600
zh还是要打断手头的事做别的
6:06.600–6:09.380
zh又或者是要开启一个全新的任务
6:09.380–6:11.580
zh这听起来好像是基础能力,
6:11.580–6:13.047
zh但在多轮对话里,
6:13.047–6:16.530
zh很多模型会把用户随口的插画当成新指令,
6:16.530–6:19.280
zh直接把之前的上下文全部覆盖掉,
6:19.280–6:21.480
zh导致任务做到一半就断了。
6:21.480–6:28.000
zh针对长期任务最常见的约束遗忘问题,Spark 1.3也做了专门强化。
6:28.000–6:29.600
zh比如你一开始就说过
6:29.600–6:31.880
zh所有输出都要用正体中文
6:31.880–6:33.520
zh不能用外部图片素材
6:33.520–6:35.400
zh数据不能超过指定范围
6:35.400–6:37.160
zh他会在整个执行过程中
6:37.160–6:38.760
zh反复检查这些条件
6:38.760–6:41.380
zh而不是跑个五六步之后就全忘了
6:41.380–6:42.440
zh最关键的一点
6:42.440–6:44.920
zh是他对自身能力边界的判断
6:44.920–6:46.400
zh过去很多代理人模型
6:46.400–6:47.420
zh最危险的习惯
6:47.420–6:48.880
zh就是任务做不完的时候
6:48.880–6:50.120
zh会假装做完了
6:50.120–6:51.260
zh然后生成一份
6:51.260–6:52.860
zh看起来很完整的报告
6:52.860–6:55.400
zh里面全是编造的数据和结论
6:55.400–6:57.220
zh普通用户根本看不出来
6:57.220–7:01.260
zhBug1.3在训练时特别强化了这点遇到做不到的地方
7:01.260–7:02.860
zh他更倾向于直接说
7:02.860–7:04.160
zh我卡在这里了
7:04.160–7:05.500
zh我缺少这个资讯
7:05.500–7:09.240
zh而不是硬凑出一份看似完美的答案
7:09.240–7:12.060
zhMeta内部工程师对比1.2版本后发现
7:12.060–7:15.820
zh新版本平均减少了20%的工具呼叫次数
7:15.820–7:18.880
zh同时减少了25%的token消耗
7:18.880–7:21.340
zh这两个数字其实比跑分更有意义
7:21.340–7:24.020
zh工具呼叫减少代表模型更清楚
7:24.020–7:25.740
zh什么时候该用什么工具
7:25.740–7:28.580
zh不会无脑尝试所有选项来回绕路
7:28.580–7:30.000
zhToken消耗减少
7:30.000–7:31.680
zh代表推理效率提升
7:31.680–7:33.840
zh单位任务的成本直接下降
7:33.840–7:35.880
zh很多人不知道代理人任务的成本
7:35.880–7:38.300
zh通常是纯问答的3到5倍
7:38.300–7:40.120
zh因为要不断多轮推理
7:40.120–7:41.800
zh呼叫工具修正路线
7:41.800–7:43.080
zh所以效率的提升
7:43.080–7:44.520
zh直接决定了这项技术
7:44.520–7:46.220
zh能不能大规模商业化
7:46.220–7:47.380
zh不过也要说清楚
7:47.380–7:50.900
zh这两个数字是Meta内部测试场景下的结果
7:50.900–7:52.880
zh不是第三方独立评测
7:52.880–7:55.260
zh实际业务中因为场景更复杂
7:55.260–7:57.340
zh不一定能复现同样的比例
7:57.340–8:00.000
zh官方也举了几个典型的常任务场景
8:00.000–8:02.415
zh官方也举了几个典型的常任务场景,
8:02.415–8:05.584
zh比如工程领域的CAD模型搭配流体模拟数据。
8:05.584–8:07.848
zh最后按指定章节输出PDF报告,
8:07.848–8:10.565
zh音乐制作领域根据时间码定位错误音符,
8:10.565–8:12.980
zh从重复段落里挑出合适的替代片段。
8:12.980–8:14.920
zh保持所有音轨长度不变
8:14.920–8:16.040
zh再重新混音
8:16.040–8:18.640
zh这些场景的共同点就是步骤多
8:18.640–8:19.840
zh中间产物多
8:19.840–8:21.400
zh需要跨工具协作
8:21.400–8:23.860
zh差一步整个结果就不能用
8:23.860–8:24.940
zh从这个角度看
8:24.940–8:28.540
zhSpark 1.3根本不是一个聊天更厉害的模型
8:28.540–8:30.720
zh而是一个干活更稳的模型
8:30.720–8:33.580
zh它的评价标准早就不是会不会写诗
8:33.580–8:34.940
zh能不能解数学题
8:34.940–8:36.960
zh而是能不能在100步之后
8:36.960–8:38.780
zh还不偏离最初的目标
8:38.780–8:40.580
zh聊完了官方自己讲的升级
8:40.580–8:43.220
zh我们来看看第三方独立评测的数据
8:43.220–8:46.300
zh验证一下这些能力到底有没有落到实处
8:46.300–8:48.880
zh这次的数据全部来自Artificial Analysis
8:48.880–8:52.800
zh这是目前业界专门做代理人模型评测的独立机构
8:52.800–8:54.400
zh不是Meta自己跑的分
8:54.400–8:56.120
zh参考价值相对高一些
8:56.120–8:58.760
zh在他们的综合智慧指数榜单上
8:58.760–9:02.140
zhSpark 1.3的Shy版本拿到61分
9:02.140–9:06.220
zh还在有限预览阶段的Max版本拿到62分
9:06.220–9:08.400
zh比起1.2版本的57分
9:08.400–9:10.360
zhExia整整涨了4分
9:10.360–9:15.300
zh在AI评测里 4分的涨幅算不算大 要看在哪个区间
9:15.300–9:19.300
zh如果从30分涨到34分 那只是入门级的进步
9:19.300–9:24.320
zh但从57分涨到61分已经是第一梯队模型的明显提升
9:24.320–9:27.080
zh因为越往上 每一分的难度都越高
9:27.080–9:32.200
zh更有竞争力的其实是成本XJ版本完成一项综合指数任务
9:32.200–9:37.980
zh平均花费0.55美元 在所有得分超过59分的模型里是最低的
9:37.980–9:39.760
zh我们可以简单对比一下
9:39.760–9:40.640
zh同级别里
9:40.640–9:43.040
zhOpenAI的GPT-4O Advanced
9:43.040–9:44.100
zh做类似任务
9:44.100–9:45.560
zh大概要1.2美元
9:45.560–9:47.700
zhAnthropic的Cloud Opus
9:47.700–9:49.500
zh则要1.5美元左右
9:49.500–9:51.620
zhMeta差不多只要一半的价格
9:51.620–9:54.980
zh这对于需要大量呼叫API的企业用户来说
9:54.980–9:56.300
zh吸引力非常大
9:56.300–9:58.560
zh我们再拆开看具体任务的表现
9:58.560–10:00.280
enTile3-Bench Banking
10:00.280–10:02.680
zh是专门的银行代理人基准测试
10:02.680–10:05.240
zh模拟金融场景下的多步骤任务
10:05.240–10:06.340
zh1.2版本
10:06.340–10:08.740
zh当时只拿到35%的通过率
10:08.740–10:10.960
zhSHAE版本提升到47%
10:10.960–10:13.640
zhMAX版本更是达到52%
10:13.640–10:15.360
zh这个涨幅其实相当惊人
10:15.360–10:17.260
zh说明模型在处理合规
10:17.260–10:20.240
zh要求高步骤繁琐的金融任务时
10:20.240–10:22.840
zh可靠性比上一代强了很多
10:22.840–10:24.000
zh但也要客观说
10:24.000–10:25.580
zh47%的通过率
10:25.580–10:27.720
zh依然代表超过一半的任务
10:27.720–10:29.040
zh没办法完美完成
10:29.040–10:31.040
zh距离真正取代人类专员
10:31.040–10:32.780
zh还有非常远的距离
10:32.780–10:35.700
zh大概相当于入行半年的助理水平
10:35.700–10:38.980
zhTerminal-Bench 2.1是终端指令执行测试
10:38.980–10:41.300
zh1.2版本通过率80%
10:41.300–10:43.600
zhX-Shy提升到85%
10:43.600–10:45.300
zhMax到86%
10:45.300–10:46.620
zh这个分数看起来很高
10:46.620–10:48.640
zh但终端任务相对结构化
10:48.640–10:50.500
zh指令对错的标准很明确
10:50.500–10:52.240
zh能拿到高分并不意外
10:52.240–10:54.600
zh参考价值不如真实工作场景
10:54.600–10:57.320
zh真正值得注意的反而是一项退步的指标
10:57.320–11:00.100
zhAA-LCR长上下文基准
11:00.100–11:02.660
zh1.2版本有83%的正确率
11:02.660–11:05.240
zh1.3版本降到了79%
11:05.240–11:07.900
zh为什么长上下文能力反而退步了
11:07.900–11:10.060
zh难道模型越更新越差吗
11:10.060–11:10.920
zh当然不是
11:10.920–11:13.840
zh背后的原因是Spark 1.3调整了策略
11:13.840–11:15.140
zh遇到不确定的资讯
11:15.140–11:16.800
zh它更倾向于拒绝回答
11:16.800–11:18.660
zh而不是硬猜一个答案
11:18.660–11:20.780
zh也就是说它宁可少说几句
11:20.780–11:22.000
zh也不说错话
11:22.000–11:25.660
zh这种策略在AA-Omniscience准确率指标上
11:25.660–11:26.500
zh也能看出来
11:26.500–11:28.620
zh表面上准确率小幅回落
11:28.620–11:30.880
zh但幻觉率明显降低了
11:30.880–11:33.300
zh这其实是一个非常重要的取舍
11:33.300–11:34.960
zh你要更高的召回率
11:34.960–11:36.760
zh还是更高的准确率
11:36.760–11:38.060
zh对于普通用户来说
11:38.060–11:39.720
zh可能希望AI什么都能答
11:39.720–11:41.260
zh哪怕错一点也没关系
11:41.260–11:42.540
zh但对于企业用户
11:42.540–11:45.300
zh尤其是金融 医疗 法律这些领域
11:45.300–11:46.560
zh一个错误的答案
11:46.560–11:48.620
zh代价可能比没有答案大得多
11:48.620–11:51.160
zh之前就有企业用初代代理人模型
11:51.160–11:52.440
zh处理报销审核
11:52.440–11:55.500
zh结果模型编造了很多不存在的单据
11:55.500–11:57.600
zh造成了不小的财务漏洞
11:57.600–12:00.000
zh所以现在越是面向企业的模型
12:00.000–12:03.660
zh越把不编造放在比达对更高的优先级
12:03.660–12:04.760
zh从这个角度看
12:04.760–12:06.980
zh这项退步反而是一种进步
12:06.980–12:09.500
zh代表模型开始往实用化的方向走
12:09.500–12:11.700
zh而不是为了跑分应凑答案
12:11.700–12:13.340
zh另外很多人忽略的一点是
12:13.340–12:15.480
zhMAX版本的分数虽然更高
12:15.480–12:18.200
zh但代价是运算算力大幅增加
12:18.200–12:20.480
zh根据Artificial Analysis的测试
12:20.480–12:23.560
zh在GDPVAL-AAVFE任务里
12:23.560–12:27.540
zhMAX版本比SY多消耗约62%的推理量
12:27.540–12:29.540
zh就算是银行代理任务
12:29.540–12:31.780
zh也多了28%的算力
12:31.780–12:33.180
zh为什么会差这么多
12:33.180–12:36.060
zh因为MAX版本会做更多的自我检查
12:36.060–12:37.620
zh走更多的思维步骤
12:37.620–12:41.200
zh相当于人做事情的时候反复检查好几遍
12:41.200–12:43.260
zh自然更费时间更费算力
12:43.260–12:44.860
zh但正确率也更高
12:44.860–12:48.400
zh这其实带出了未来AI商业模式的一个可能方向
12:48.400–12:50.500
zh以后的模型不会只有单一档位
12:50.500–12:54.000
zh而是会根据任务的风险等级调整推理强度
12:54.000–12:55.140
zh低风险的闲聊
12:55.140–12:58.180
zh查资料用低档速度快又便宜
12:58.180–12:59.480
zh高风险的财务
12:59.480–13:01.180
zh法律任务用高档
13:01.180–13:03.220
zh更慢 更贵 但更可靠
13:03.220–13:05.160
zh用户可以按自己的需求选
13:05.160–13:07.020
zh而不是为了偶尔的高需求
13:07.020–13:08.940
zh全程付最贵的价格
13:08.940–13:10.860
zh当然 目前这还只是观察
13:10.860–13:13.820
zhMeta并没有正式推出这种分级定价
13:13.820–13:15.220
zh但从技术设计上
13:15.220–13:17.020
zh已经具备了这样的基础
13:17.020–13:18.660
zh最后 还要再强调一次
13:18.660–13:20.800
zhMax版本目前只是有限预览
13:20.800–13:23.540
zh只有少数合作机构和企业能拿到权限
13:23.540–13:25.440
zh普通开发者根本呼叫不到
13:25.440–13:27.920
zh所以你看到62分那个数字的时候
13:27.920–13:30.420
zh要知道它背后是更高的成本
13:30.420–13:32.300
zh更严格的访问限制
13:32.300–13:35.400
zh不能拿它去跟别人全面开放的API比
13:35.400–13:37.160
zh然后说Meta已经赢了
13:37.160–13:38.580
zh这种对比并不公平
13:38.580–13:40.920
zh看完了负责思考和执行的大脑
13:40.920–13:44.220
zh我们再转过头来讲这次连发的另一款产品
13:44.220–13:46.000
zh负责感知输入的耳朵
13:46.000–13:47.480
enMuse Voice Transcribe
13:47.480–13:48.980
zh很多人第一眼看到它
13:48.980–13:51.280
zh会觉得不就是个语音转文字吗
13:51.280–13:52.360
zh有什么特别的
13:52.360–13:53.980
zh但实际上它的设计思路
13:53.980–13:56.720
zh跟传统的自动语音识别完全不一样
13:56.720–13:58.640
zh传统的ASR比如Whisper
13:58.640–14:00.440
zh走的是离线转写路线
14:00.440–14:02.840
zh拿到整段音频之后再慢慢处理
14:02.840–14:04.840
zh可以利用上下文反复修正
14:04.840–14:05.880
zh准确率很高
14:05.880–14:06.960
zh但延迟也大
14:06.960–14:09.560
zh根本没办法用来做实时对话
14:09.560–14:11.380
zh而以前的实时语音助手
14:11.380–14:13.940
zh比如手机上的Siri Google助理
14:13.940–14:15.320
zh为了追求低延迟
14:15.320–14:17.540
zh只能听一小段就马上输出
14:17.540–14:19.160
zh结果准确率很差
14:19.160–14:20.140
zh稍微吵一点
14:20.140–14:22.960
zh有两个人叠话或者混个外文单字
14:22.960–14:24.020
zh结果就歪掉
14:24.020–14:25.960
zhMuse Voice Transcribe想解决的
14:25.960–14:27.600
zh就是又要准又要快
14:27.600–14:29.840
zh还要懂真实对话这个老难题
14:29.840–14:32.960
zh它的做法是把音频切成80毫秒的小块
14:32.960–14:34.940
zh每秒处理12月5日次
14:34.940–14:37.980
zh每一小块音频先转换成一个软Token
14:37.980–14:41.080
zh模型在判断是要继续等后面的声音
14:41.080–14:42.760
zh还是立刻输出文字
14:42.760–14:44.500
zh等到音频完全停止
14:44.500–14:46.620
zh系统会加入一个特殊标记
14:46.620–14:50.440
zh让模型把剩下没输出的文字一口气吐出来
14:50.440–14:53.500
zh其中最关键的技术叫做自适应延迟
14:53.500–14:57.080
zh模型不会给每个字都设定一样的等待时间
14:57.080–14:59.480
zh简单确定的内容就立刻输出
14:59.480–15:02.220
zh碰到需要后文才能判断的同音词
15:02.220–15:03.140
zh专有名词
15:03.140–15:05.940
zh就稍微多等一点点音频再决定
15:05.940–15:08.160
zh这其实很像人类的同步口译
15:08.160–15:10.060
zh译员会根据句子的难度
15:10.060–15:11.680
zh调整自己的滞后时间
15:11.680–15:13.040
zh不会一味求快
15:13.040–15:14.400
zh也不会一味求准
15:14.400–15:15.180
zh训练的时候
15:15.180–15:17.540
zhMeta把词 错误率和延迟时间
15:17.540–15:20.180
zh一起放进强化学习的奖励函数里
15:20.180–15:21.900
zh如果模型只追求准确
15:21.900–15:23.280
zh每句话都等很久
15:23.280–15:24.240
zh得分不会高
15:24.240–15:25.400
zh只追求速度
15:25.400–15:27.900
zh输出一大堆错字同样过不了关
15:27.900–15:32.460
zh最终目标就是在准确率和反应速度之间找到最佳平衡点
15:32.460–15:33.680
zh那实际表现如何
15:33.680–15:37.060
zh在Artificial Analysis的流逝语音榜单上
15:37.060–15:42.060
zhMuse Voice Transcribe的最终词错误率约3.1%
15:42.060–15:43.460
zh直接登上第一名
15:44.354–15:46.348
zh这个数字是什么概念?
15:46.348–15:48.342
zh在流逝实时的场景下,
15:48.342–15:52.530
zh3.1%已经非常接近人类专业数据员的水平,
15:52.530–15:55.123
zh人类大概是2%到3%左右,
15:55.123–15:58.114
zh相当于每讲100个字只错3个。
15:58.114–16:00.094
zh不过这里必须先打个预防针
16:00.094–16:02.894
zh这个成绩是英语流逝对话的测试结果
16:02.894–16:06.374
zh绝对不能直接套用到所有语言 所有场景
16:06.374–16:08.834
zh中文因为同音字多 声调复杂
16:08.834–16:13.214
zh同样的模型词错误率通常会比英语高2到3个百分点
16:13.214–16:17.294
zh如果是嘈杂环境 多人强化 或者带方言口音
16:17.294–16:19.014
zh表现还会再打折扣
16:19.014–16:22.834
zh官方也明确说 模型训练覆盖了70多种语言
16:22.834–16:25.734
zh其中只有25种经过充分验证
16:25.734–16:27.834
zh其他语言可能只是有训练过
16:27.834–16:30.234
zh但没有经过严格的效果评测
16:30.234–16:32.134
zh除了基础的转写准确率
16:32.134–16:34.194
zh还有几个功能特别值得一提
16:34.194–16:36.714
zh首先是原生的说话人分离
16:36.714–16:39.334
zh而且支持20人以上同时发言
16:39.334–16:42.094
zh传统的会议转写通常是先做语音识别
16:42.094–16:44.014
zh再另外用一套声文系统
16:44.014–16:45.714
zh判断每段话是谁说的
16:45.714–16:47.194
zh两个系统的时间轴
16:47.194–16:49.354
zh只要差一点点就会出现文字
16:49.354–16:50.474
zh人认错的情况
16:50.474–16:52.814
zhMeta是在同一个生成过程里
16:52.814–16:55.674
zh加入说话人切换标记和身份标签
16:55.674–16:58.434
zh检测到换人就先标一轮新发言
16:58.434–17:00.894
zh等听到足够声音再确定身份
17:00.894–17:03.014
zh时间轴的准确度会高很多
17:03.014–17:06.214
zh官方展示的长对话里包含多人插话
17:06.214–17:08.314
zh重叠发言 自然停顿
17:08.314–17:10.194
zh都能正确标记身份
17:10.194–17:13.734
zh这对于会议记录 访谈整理 客服记录来说
17:13.734–17:14.674
zh价值很高
17:14.674–17:18.214
zh因为后续的摘要系统拿到的不只是一整段文字
17:18.214–17:20.894
zh还知道谁提了问题 谁做了承诺
17:20.894–17:22.234
zh谁反对哪个方案
17:22.234–17:23.974
zh其次是端点侦测能力
17:23.974–17:27.474
zh人类对话本来就不会每次讲完都按个结束钮
17:27.474–17:30.794
zh系统要从语气停顿和上下文判断
17:30.794–17:33.474
zh对方只是喘口气还是真的说完了
17:33.474–17:35.014
zh如果端点判断不准
17:35.014–17:36.694
zh要么用户都讲完半天了
17:36.694–17:37.774
zh助手还没反应
17:37.774–17:39.234
zh要么用户还没说完
17:39.234–17:41.494
zh助手就急着插嘴体验都很差
17:41.494–17:42.814
enMuse Voice Transcribe
17:42.814–17:44.654
zh专门针对这点做了优化
17:44.654–17:47.514
zh能更准确判断语音的开始和结束
17:47.514–17:50.014
zh这也是代理人能自然对话的前提
17:50.014–17:51.894
zh第三个很实用的功能是
17:51.894–17:54.594
zh句内和句间的多语言自由切换
17:54.594–17:56.134
zh还有上下文偏制
17:56.134–17:58.374
zh现实中很多双语使用者
17:58.374–18:00.574
zh不会先切语言模式再讲话
18:00.574–18:02.994
zh中文句子里夹个英文专有名词
18:02.994–18:05.274
zh项目代号是家常便饭
18:05.274–18:06.954
zh旧的系统很容易把英文词
18:06.954–18:08.994
zh应转成发音相近的中文字
18:08.994–18:11.494
zh或者切换语言之后直接丢了半句话
18:11.494–18:12.994
enMuse Voice Transcribe
18:12.994–18:15.294
zh支持70多种语言的自由切换
18:15.294–18:18.254
zh还可以让用户提前输入常用的人名
18:18.254–18:19.734
zh公司名专业术语
18:19.734–18:21.714
zh模型碰到相近发音的时候
18:21.714–18:24.994
zh会优先选择这些符合上下文的词
18:24.994–18:27.654
zh比如医生可以提前录入药品名称
18:27.654–18:30.914
zh城市设计师可以加入函数名和项目代号
18:30.914–18:33.594
zh企业用户可以上传内部数语表
18:33.594–18:36.014
zh这样转写的准确率会大幅提升
18:36.014–18:38.154
zh甚至可以直接进入工作流程
18:38.154–18:39.714
zh不用再人工校对一遍
18:39.714–18:42.054
zh这才是语音转写真正的价值
18:42.054–18:44.254
zh不是把声音变成文字就好
18:44.254–18:46.234
zh而是变成能直接用的文字
18:46.234–18:47.874
zh目前Muse Voice Transcribe
18:47.874–18:49.614
zh已经接入Meta Model API
18:49.614–18:52.774
zh还有Meta AI4 Mac Muse Code Mac版本
18:52.774–18:55.494
zh用户可以按住FN键直接语音输入
18:55.494–18:58.314
zh把转写结果送到不同的应用程式里
18:58.314–19:00.834
zh不过有个隐私细节一定要讲清楚
19:00.834–19:04.734
zh官方网页演示的时候说麦克风音频只会用来生成转写
19:04.734–19:05.614
zh不会被保存
19:05.614–19:08.394
zh但这个承诺只限于网页演示场景
19:08.394–19:10.254
zh不等于所有API呼叫
19:10.254–19:13.014
zh所有产品部署都不会保存音频
19:13.014–19:15.354
zh如果你是透过API上传录音
19:15.354–19:16.694
zhMeta会不会保存
19:16.694–19:17.554
zh保存多久
19:17.554–19:19.254
zh会不会用来训练模型
19:19.254–19:22.774
zh都要看你签署的服务条款和数据处理协议
19:22.774–19:24.714
zh不能因为网页演示不保存
19:24.714–19:28.074
zh就理所当然认为所有场景都不保存
19:28.074–19:30.994
zh这在个资合规上是非常危险的认知
19:30.994–19:33.534
zh讲到这里就必须好好聊一下
19:33.534–19:35.034
zh隐私与安全的边界
19:35.034–19:37.354
zh这也是很多人看AI产品的时候
19:37.354–19:40.374
zh最容易忽略但绝对最重要的部分
19:40.374–19:42.854
zh先讲Muse Spark 1.3的安全设计
19:42.854–19:45.254
zh官方说这次提升了对提示注入
19:45.254–19:47.294
zh和对抗输入的抵抗能力
19:47.294–19:49.994
zh也更能识别哪些操作是不可逆的
19:49.994–19:51.054
zh提示注入是什么
19:51.054–19:53.254
zh就是攻击者在输入内容里
19:53.254–19:55.274
zh嵌入看不见的恶意指令
19:55.274–19:57.314
zh比如藏在PDF档案里
19:57.314–19:58.114
zh网页里
19:58.114–20:00.834
zh诱导AI代理人忽略原本的规则
20:00.834–20:02.554
zh去转发机密档案
20:02.554–20:03.974
zh修改设定甚至转账
20:03.974–20:06.434
zh2025年就曾经出现过
20:06.434–20:07.714
zh类似的攻击案例
20:07.714–20:10.754
zh让不少企业对AI代理人望而却步
20:10.754–20:13.774
zhSpark 1.3针对这类攻击做了专门训练
20:13.774–20:15.594
zh但这不代表它完全免疫
20:15.594–20:19.874
zh目前没有任何模型能100%防御所有提示注入攻击
20:19.874–20:21.594
zh识别不可逆操作也是一样
20:21.594–20:23.394
zh模型能标出删除档案
20:23.394–20:24.574
zh发送批量邮件
20:24.574–20:26.934
zh修改数据库这些高风险动作
20:26.934–20:28.334
zh要求用户确认
20:28.334–20:31.114
zh但光有模型层面的防护远远不够
20:31.114–20:33.814
zh官方自己也强调实际部署的时候
20:33.814–20:36.374
zh必须同时做好全线隔离
20:36.374–20:38.454
zh白名单和操作日志
20:38.454–20:41.514
zh全线隔离就是给代理人最小必要的全线
20:41.514–20:43.754
zh比如负责整理表格的助理
20:43.754–20:46.534
zh就不该有删除整个资料夹的权限
20:46.534–20:50.654
zh白名单就是只允许模型呼叫预先核准的
20:50.654–20:54.834
zh工具和API不能让它随便访问系统里的任何东西
20:54.834–20:58.954
zh操作日志就是把代理人所有执行动作都记录下来
20:58.954–21:01.134
zh方便事后审计和回溯
21:01.134–21:04.334
zh这三层防护都是资安领域的基本常识
21:04.334–21:07.754
zh却也是很多AI产品最容易省略的部分
21:07.754–21:09.614
zhMeta愿意主动强调这点
21:09.614–21:13.234
zh说明它是真的在考虑企业落地的实际需求
21:13.234–21:15.894
zh而不是只做展示用的技术demo
21:15.894–21:16.974
zh再回到语音部分
21:16.974–21:19.874
zh当语音转写加上代理人执行
21:19.874–21:23.534
zh再搭配Meta旗下的ray减班智慧眼镜
21:23.534–21:25.214
zh想象空间确实很大
21:25.214–21:28.694
zh手机上的语音助手要等你点开APP才能用
21:28.694–21:30.854
zh但眼镜可以一直戴在脸上
21:30.854–21:32.794
zh随时处在声音环境里
21:32.794–21:34.574
zh如果他能听懂谁在讲话
21:34.574–21:35.814
zh什么时候该接话
21:35.814–21:37.134
zh什么时候不该插嘴
21:37.134–21:39.954
zh就能在会议后自动整理每个人的行动项
21:39.954–21:42.014
zh访谈的时候自动标记重点
21:42.014–21:46.134
zh甚至日常聊天里提到的代办事项都能自动记下来
21:46.134–21:48.634
zh但这也带来了更尖锐的隐私问题
21:48.634–21:50.974
zh眼镜上的麦克风什么时候在听
21:50.974–21:52.874
zh听到的内容传到哪里去了
21:52.874–21:54.914
zh用户有没有明确的控制权
21:54.914–21:57.234
zh旁边的人知不知道自己正在被录音
21:57.234–22:00.234
zh这些问题目前都还没有完全公开的答案
22:00.234–22:04.274
zh不过我们可以从Meta的双轨策略里推出一个很合理的假设
22:04.274–22:06.954
zh未来轻量级的语音转写
22:06.954–22:08.534
zh简单的指令理解
22:08.534–22:12.294
zh很可能会直接跑在眼镜本地的端侧芯片上
22:12.294–22:13.534
zh不需要传到云端
22:13.534–22:15.294
zh敏感数据不会离开设备
22:15.294–22:17.034
zh大幅降低隐私风险
22:17.034–22:18.774
zh而复杂的常任务代理
22:18.774–22:19.934
zh多工具协作
22:19.934–22:22.694
zh再交给云端的Spark模型处理
22:22.694–22:25.634
zh刚好Meta有Glimmer这条本地开源路线
22:25.634–22:27.694
zh专门做轻量化端侧部署
22:27.694–22:30.634
zh刚好可以跟眼镜这类终端装置搭配
22:30.634–22:32.334
zh云端负责复杂思考
22:32.334–22:34.034
zh本地负责实时感知
22:34.034–22:36.274
zh既保证体验又兼顾隐私
22:36.274–22:40.194
zh这很可能就是Meta下一代AI入口的完整架构
22:40.194–22:42.834
zh当然这只是基于现有产品线的推测
22:42.834–22:44.754
zh官方还没有证实这个方向
22:44.754–22:46.794
zh讲完了技术亮点和想象空间
22:46.794–22:48.234
zh我们也得冷静下来
22:48.234–22:51.154
zh聊聊这次发布的口径边界和实际风险
22:51.154–22:54.114
zh首先Max版本目前只是有线预览
22:54.114–22:56.514
zh普通开发者能用的只有Shi版本
22:56.514–22:58.834
zh网上所有关于Max的评测数据
22:58.834–23:01.034
zh都来自少数拿到权限的机构
23:01.034–23:03.074
zh一般用户现在根本用不到
23:03.074–23:07.054
zh所以62分那个数字只能当成技术上限的参考
23:07.054–23:10.094
zh不能作为采购或者使用决策的依据
23:10.094–23:12.414
zh其次所有的基准测试数据
23:12.414–23:15.414
zh都是在标准化的干净环境里跑出来的
23:15.414–23:19.494
zh真实世界的场景只会更复杂更混乱
23:19.494–23:22.494
zh比如银行代理测试里的数据都是结构化的
23:22.494–23:24.154
zh格式统一全线清晰
23:25.087–23:26.443
zh但真实的企业里,
23:26.443–23:29.154
zh数据可能分散在十几个老旧系统里,
23:29.154–23:30.341
zh格式乱七八糟、
23:30.341–23:31.527
zh权限层层卡关。
23:31.527–23:37.207
zh你在测试里拿到47%的通过率,到了真实环境可能连30%都不到。
23:37.207–23:43.787
zh这不是Meta的问题 是所有AI模型评测的普遍现象 跑分永远不等于真实生产力
23:43.787–23:46.327
zh第三 关于开源的期待也要放低
23:46.327–23:51.754
zhSpark 1.3目前是完全避原的 官方只说未来有开放权重的规划
23:51.754–23:54.287
zh但没有时间表 也没有说授权条款
23:54.287–24:01.247
zh参考Meta之前Lama系列的节奏 通常是新一代出来之后才会把上一代的权重逐步开放
24:01.247–24:06.807
zh而且早期都是非商业授权 要等到更后面才会用更宽松的授权
24:06.807–24:10.007
zh所以不要期待短期内就能在自己的电脑上
24:10.007–24:12.987
zh跑Spark 1.3核心的代理人能力
24:12.987–24:16.127
zhMeta肯定会先握在手里当商业护城河
24:16.127–24:18.087
zh最后回到产业竞争的层面
24:18.087–24:20.447
zhMeta这次的更新确实扎实
24:20.447–24:25.027
zh在代理人可靠性和流逝语音转写上都往前走了一步
24:25.027–24:27.327
zh成本控制也做得很有竞争力
24:27.327–24:29.227
zh但要说已经赢了还太早
24:29.227–24:33.127
zhOpenEye的GPT系列代理人能力同样在快速迭代
24:33.127–24:37.847
zh谷歌的Gemini在多模态和端侧整合上有自己的优势
24:37.847–24:42.527
zhAnthropic在长上下文和安全合规上依然领先
24:42.527–24:46.927
zh还有Eleven Labs这类专业语音公司也在往代理人方向走
24:46.927–24:52.547
zhMeta现在的领先更像是某几个细分场景的小幅度领先
24:52.547–24:55.207
zh还远没有到拉开差距的程度
24:55.207–24:58.527
zh而且真正的竞争从来都不是比模型本身
24:58.527–25:02.807
zh而是比谁能先把技术变成用户愿意天天用的产品
25:02.807–25:04.927
zh谁能解决好隐私安全
25:04.927–25:06.967
zh权限这些麻烦的落地问题
25:06.967–25:08.247
zh模型再聪明
25:08.247–25:10.887
zh如果用户不敢把重要的工作交给他
25:10.887–25:12.587
zh那也只是个高级玩具
25:12.587–25:13.167
zh讲到这里
25:13.167–25:16.007
zh我们把这次Meta两款产品的技术细节
25:16.007–25:16.947
zh评测数据
25:16.947–25:18.107
zh产品线定位
25:18.107–25:19.027
zh隐私风险
25:19.027–25:21.187
zh还有产业格局全部拆完了
25:21.187–25:23.667
zh你会发现每一个亮眼的数据背后
25:23.667–25:25.307
zh都有一个限定条件
25:25.307–25:27.067
zh每一项技术突破的旁边
25:27.067–25:29.227
zh都站着一个带解决的问题
25:29.227–25:30.947
zh这不是说Meta做得不好
25:30.947–25:32.047
zh恰恰相反
25:32.047–25:34.567
zh只有当你看清了所有的边界和限制
25:34.567–25:36.587
zh才能真正评估它的价值
25:36.587–25:41.227
zhMuse Spark 1.3确实把常任务代理人的可靠性往前推了一步
25:41.227–25:43.027
zh成本优势也很明显
25:43.027–25:46.167
zhMuse Voice Transcribe在英语流逝转写上
25:46.167–25:48.187
zh做到了业界顶尖
25:48.187–25:50.827
zh准确率和延迟的平衡做得可圈可点
25:50.827–25:53.427
zh但它们都还只是阶段性的进展
25:53.427–25:56.067
zh离大家想象中什么都能做的AI助理
25:56.067–25:57.647
zh还有非常远的距离
25:57.647–25:59.707
zh2026年的AI产业
25:59.707–26:02.607
zh其实正在经历一个很重要的转向
26:02.607–26:05.447
zh前几年大家都在比谁的模型更大
26:05.447–26:06.747
zh谁的跑分更高
26:06.747–26:08.627
zh谁的牛皮吹得更响
26:08.627–26:12.087
zh但从今年开始竞争慢慢落到了实处
26:12.087–26:14.167
zh比的是谁能把长任务做稳
26:14.167–26:15.927
zh谁能把真实声音听懂
26:15.927–26:17.727
zh谁能让企业敢放心用
26:17.727–26:20.227
zh谁能把隐私控制在合理范围
26:20.227–26:22.847
zh那些看起来不怎么耀眼的细节优化
26:22.847–26:27.407
zh反而决定了产品能不能真正走进日常生活和工作流
26:27.407–26:28.267
zh就像造车
26:28.267–26:36.447
zh早期大家都比马力 比急速 等到市场成熟了 比的是隔音 是油耗 是故障率 是乘坐舒适度
26:36.447–26:39.987
zh这些才是决定你愿不愿意每天开的关
26:39.987–26:45.347
zh见如果你喜欢这种不吹不黑 把数据和限制都讲清楚的深度科技解析
26:45.347–26:48.947
zh欢迎订阅这个频道 并且打开通知小铃铛
26:48.947–26:54.787
zh我们会持续追踪AI代理人 语音交互 端策AI这些领域的最新进展
26:54.787–26:57.307
zh帮你过滤掉夸大的营销话术
26:57.307–26:59.727
zh留下真正值得关注的技术变化
26:59.727–27:01.327
zh也欢迎在留言区告诉我
27:01.327–27:04.287
zh你最期待AI帮你完成什么样的任务
27:04.287–27:05.927
zh是整理会议记录
27:05.927–27:07.887
zh还是处理繁琐的文书工作
27:07.887–27:09.647
zh我们下期影片再见
0:00.000–0:02.300
你有没有过这种很无力的经验?
0:02.300–0:05.000
叫AI帮你整理一份跨部门的会议报告。
0:05.000–0:09.300
做到一半它忘了你要求的章节格式,用语音助手查形成。
0:09.300–0:13.700
旁边同事插句话,它就把指令听成完全不相干的内容。
0:13.700–0:20.500
只要任务超过三个步骤,需要跨两个以上工具,最后交付的结果一定歪掉大半。
0:20.500–0:23.667
你大概也听过很多人说AI已经很聪明了,
0:23.667–0:25.000
但真的拿来干活,
0:25.000–0:27.500
总是卡在这些最不起眼的小地方。
0:27.500–0:29.980
2026年9月的头两天
0:29.980–0:32.400
Meta接连丢出了两项更新
0:32.400–0:34.840
没有吹什么通用人工智能的牛皮
0:34.840–0:38.480
却精准踩中了这些大家天天吐槽的痛点
0:38.480–0:41.760
一个负责把真实世界里的声音听得更清楚
0:41.760–0:44.780
一个负责把复杂的常任务做得更稳
0:44.780–0:48.720
有人看完数据说Meta终于要在代理人战场超车了
0:48.720–0:50.420
也有人冷静算完成本
0:50.420–0:52.540
发现事情根本没有这么简单
0:52.540–0:54.180
今天我们就不吹不黑
0:54.180–0:57.220
把官方技术文件第三方独立评测
0:57.220–1:00.140
还有那些藏在角落的小字限制
1:00.140–1:01.840
全部摊开来讲
1:01.840–1:04.620
看看这两款产品到底走到了哪一步
1:04.620–1:07.300
又有哪些东西是营销不会告诉你的
1:07.300–1:08.860
我们不从结论讲起
1:08.860–1:12.280
因为真正有价值的判断往往都藏在每一个
1:12.280–1:13.380
但是后面
1:13.380–1:17.300
先帮大家把最容易搞混的产品线界限画清楚
1:17.300–1:20.100
这也是很多自媒体最常讲错的地方
1:20.100–1:24.160
9月1日登场的是Muse Voice Transcribe语音转写模型
1:24.160–1:28.160
9月2日接棒上线的是Muse Spark 1.3代理人模型
1:28.160–1:30.560
两天连续发布核心产品
1:30.560–1:34.340
这在Meta Superintelligence Labs的历史上并不常见
1:34.340–1:38.520
也能看出他们在2026年下半年的竞争焦虑
1:38.520–1:39.500
但更重要的是
1:39.500–1:41.780
很多人到现在还搞不清楚
1:41.780–1:43.960
Muse Spark和Muse Glimmer
1:43.960–1:46.860
根本是两条完全不同的路线
1:46.860–1:48.180
不能混为一谈
1:48.180–1:51.280
Muse Spark走的是云端前沿代理人路线
1:51.280–1:52.720
权重完全必圆
1:52.720–1:54.820
目前只开放API呼叫
1:54.820–1:57.560
官方只说未来有开放权重的规划
1:57.560–1:59.000
但既没有时间表
1:59.000–2:01.280
也没说会用哪种授权条款
2:01.280–2:03.420
所以你绝对不能把它理解成
2:03.420–2:05.700
马上就可以下载来本地跑
2:05.700–2:08.540
而Muse Glimmer是拥有300亿参数
2:08.540–2:11.860
采用Apache 2.0授权的本地方案
2:11.860–2:14.140
主打消费级显示卡就能执行
2:14.140–2:14.780
讲白一点
2:14.780–2:17.100
Spark负责把能力堆到最高
2:17.100–2:19.680
强企业级和高端开发者市场
2:19.680–2:21.840
Glimmer负责把能力扑到最广
2:21.840–2:24.100
占领开源生态和终端装置
2:24.100–2:28.680
这种双轨策略其实刚好对应了Meta在AI产业的定位转变
2:28.680–2:33.400
前几年大家提到Meta的AI第一个想到的就是Lama系列开源模型
2:33.400–2:34.960
靠免费打天下
2:34.960–2:37.980
跟OpenAI的全B原路线正面抗衡
2:37.980–2:40.060
但到了2026年
2:40.060–2:43.760
整个行业的竞争已经从比参数 比跑分
2:43.760–2:46.900
进到比代理人 比落地场景的阶段
2:46.900–2:50.140
Meta必须拿出足够强的B原顶端产品
2:50.140–2:51.600
才能跟GPT系列
2:51.600–2:53.700
Gemini系列抢商业客户
2:53.700–2:56.760
同时又不能丢掉开源生态的优势
2:56.760–2:59.240
为什么要花这么多时间讲这件事
2:59.240–3:00.540
因为如果你误以为
3:00.540–3:02.580
Spark 1.3是开源模型
3:02.580–3:04.660
就会产生错误的部署预期
3:04.660–3:08.220
如果你以为Glimmer只是Spark的缩小版
3:08.220–3:11.700
就会低估两者在设计目标上的根本差异
3:11.700–3:13.160
另外从迭代节奏来看
3:13.160–3:15.500
Muse系列从7月的1.1版
3:15.500–3:17.360
首次连上邮件行事例
3:17.360–3:23.160
并能制作投影片到8月初1.2版聚焦大型程式库与复杂真错
3:23.160–3:25.700
甚至能连续1000多次工具呼叫
3:25.700–3:30.260
在24小时内反复编写编译GPU核心程式
3:30.260–3:33.600
8月中再加入图像与视频理解能力
3:33.600–3:37.140
到9月的1.3版转向打磨长期任务的可用性
3:37.140–3:40.500
几乎保持每个月一次大版本更新的速度
3:40.500–3:43.000
这种快速迭代在AI圈不算稀奇
3:43.000–3:47.680
但难得的是Meta几乎每一版都会附上明确的内部对比数据
3:47.680–3:49.960
同时引用第三方评测结果
3:49.960–3:52.880
给了外界一个相对透明的观察窗口
3:52.880–3:55.220
很多人只盯着分数涨了多少
3:55.220–3:58.020
却忽略了每一代版本的定位差异
3:58.020–4:02.200
Spark 1.3并不是全面碾压1.2的终极进化
4:02.200–4:05.600
而是针对代理人任务的可靠性做了针对性强化
4:05.600–4:09.420
甚至在部分涨上下文指标上还出现了小幅退步
4:09.420–4:11.240
这种有得有失的升级
4:11.240–4:14.860
恰恰说明模型能力不是简单的线性叠加
4:14.860–4:17.660
而是一连串的取舍与权衡
4:17.660–4:19.960
如果你只看营销文案里的亮点
4:19.960–4:23.140
很快就会在实际使用中发现落差
4:23.140–4:25.500
如果你翻完这次的全部技术文件
4:25.500–4:27.400
会发现最核心的关键词
4:27.400–4:28.760
不是更高的分数
4:28.760–4:30.280
也不是更多的参数
4:30.280–4:32.300
而是长任务代理人
4:32.300–4:33.440
什么意思
4:33.440–4:36.500
就是让AI不再只是一次性回答一个问题
4:36.500–4:39.160
而是像一个真正的执行助理一样
4:39.160–4:41.220
接下一个模糊的需求
4:41.220–4:43.480
自己拆解步骤 呼叫工具
4:43.480–4:44.880
遇到问题回头问你
4:44.880–4:46.100
碰到危险操作
4:46.100–4:49.380
先停下来确认最后再交付完整的成果
4:49.380–4:50.480
这听起来很美好
4:50.480–4:53.680
但过去大部分代理人模型的问题无非三种
4:53.680–4:55.880
要么不敢动手只会空泛回答
4:55.880–4:58.680
要么乱动手做到一半偏离目标
4:58.680–5:02.000
更常见的是干到一半彻底忘了最原始的要求
5:02.000–5:05.020
Spark 1.3就是冲着这些痛点做的优化
5:05.020–5:06.460
举个很实际的场景
5:06.460–5:07.620
如果你跟模型说
5:07.620–5:10.520
帮我整理上礼拜的三场客户会议记录
5:10.520–5:11.800
做成部门简报
5:11.800–5:14.120
把每个客户的行动项列出来
5:14.120–5:15.440
最后寄给主管
5:15.440–5:16.680
换做之前的模型
5:16.680–5:19.780
很可能做到一半就忘了要按客户分类
5:19.780–5:21.800
或者漏了寄信的步骤
5:21.800–5:24.980
甚至为了凑数编造几个不存在的行动项
5:24.980–5:27.920
而Spark 1.3的处理逻辑会完全不同
5:27.920–5:30.280
一开始如果觉得需求不够清楚
5:30.280–5:31.920
它会主动追问你
5:31.920–5:34.800
简报要的是正式版本还是讨论版
5:34.800–5:37.500
行动项要不要加上预计完成时间
5:37.500–5:40.440
寄信的时候要不要附上原始记录档
5:40.440–5:44.660
执行过程中如果发现某份会议记录打不开或者权限不足
5:44.660–5:46.580
它会停下来跟你要资讯
5:46.580–5:49.160
而不是硬着头皮编一个结果
5:49.160–5:50.460
如果碰到删除档案
5:50.460–5:51.640
发送批量邮件
5:51.640–5:55.080
修改正式环境设定这类有不可逆风险的操作
5:55.080–5:57.020
它一定会先跳出确认
5:57.020–5:58.480
问你确定要执行吗
5:58.480–5:59.980
不会自己直接动手
5:59.980–6:00.880
更重要的是
6:00.880–6:04.180
它能分辨你现在是在补充当前任务的资讯
6:04.180–6:06.600
还是要打断手头的事做别的
6:06.600–6:09.380
又或者是要开启一个全新的任务
6:09.380–6:11.580
这听起来好像是基础能力,
6:11.580–6:13.047
但在多轮对话里,
6:13.047–6:16.530
很多模型会把用户随口的插画当成新指令,
6:16.530–6:19.280
直接把之前的上下文全部覆盖掉,
6:19.280–6:21.480
导致任务做到一半就断了。
6:21.480–6:28.000
针对长期任务最常见的约束遗忘问题,Spark 1.3也做了专门强化。
6:28.000–6:29.600
比如你一开始就说过
6:29.600–6:31.880
所有输出都要用正体中文
6:31.880–6:33.520
不能用外部图片素材
6:33.520–6:35.400
数据不能超过指定范围
6:35.400–6:37.160
他会在整个执行过程中
6:37.160–6:38.760
反复检查这些条件
6:38.760–6:41.380
而不是跑个五六步之后就全忘了
6:41.380–6:42.440
最关键的一点
6:42.440–6:44.920
是他对自身能力边界的判断
6:44.920–6:46.400
过去很多代理人模型
6:46.400–6:47.420
最危险的习惯
6:47.420–6:48.880
就是任务做不完的时候
6:48.880–6:50.120
会假装做完了
6:50.120–6:51.260
然后生成一份
6:51.260–6:52.860
看起来很完整的报告
6:52.860–6:55.400
里面全是编造的数据和结论
6:55.400–6:57.220
普通用户根本看不出来
6:57.220–7:01.260
Bug1.3在训练时特别强化了这点遇到做不到的地方
7:01.260–7:02.860
他更倾向于直接说
7:02.860–7:04.160
我卡在这里了
7:04.160–7:05.500
我缺少这个资讯
7:05.500–7:09.240
而不是硬凑出一份看似完美的答案
7:09.240–7:12.060
Meta内部工程师对比1.2版本后发现
7:12.060–7:15.820
新版本平均减少了20%的工具呼叫次数
7:15.820–7:18.880
同时减少了25%的token消耗
7:18.880–7:21.340
这两个数字其实比跑分更有意义
7:21.340–7:24.020
工具呼叫减少代表模型更清楚
7:24.020–7:25.740
什么时候该用什么工具
7:25.740–7:28.580
不会无脑尝试所有选项来回绕路
7:28.580–7:30.000
Token消耗减少
7:30.000–7:31.680
代表推理效率提升
7:31.680–7:33.840
单位任务的成本直接下降
7:33.840–7:35.880
很多人不知道代理人任务的成本
7:35.880–7:38.300
通常是纯问答的3到5倍
7:38.300–7:40.120
因为要不断多轮推理
7:40.120–7:41.800
呼叫工具修正路线
7:41.800–7:43.080
所以效率的提升
7:43.080–7:44.520
直接决定了这项技术
7:44.520–7:46.220
能不能大规模商业化
7:46.220–7:47.380
不过也要说清楚
7:47.380–7:50.900
这两个数字是Meta内部测试场景下的结果
7:50.900–7:52.880
不是第三方独立评测
7:52.880–7:55.260
实际业务中因为场景更复杂
7:55.260–7:57.340
不一定能复现同样的比例
7:57.340–8:00.000
官方也举了几个典型的常任务场景
8:00.000–8:02.415
官方也举了几个典型的常任务场景,
8:02.415–8:05.584
比如工程领域的CAD模型搭配流体模拟数据。
8:05.584–8:07.848
最后按指定章节输出PDF报告,
8:07.848–8:10.565
音乐制作领域根据时间码定位错误音符,
8:10.565–8:12.980
从重复段落里挑出合适的替代片段。
8:12.980–8:14.920
保持所有音轨长度不变
8:14.920–8:16.040
再重新混音
8:16.040–8:18.640
这些场景的共同点就是步骤多
8:18.640–8:19.840
中间产物多
8:19.840–8:21.400
需要跨工具协作
8:21.400–8:23.860
差一步整个结果就不能用
8:23.860–8:24.940
从这个角度看
8:24.940–8:28.540
Spark 1.3根本不是一个聊天更厉害的模型
8:28.540–8:30.720
而是一个干活更稳的模型
8:30.720–8:33.580
它的评价标准早就不是会不会写诗
8:33.580–8:34.940
能不能解数学题
8:34.940–8:36.960
而是能不能在100步之后
8:36.960–8:38.780
还不偏离最初的目标
8:38.780–8:40.580
聊完了官方自己讲的升级
8:40.580–8:43.220
我们来看看第三方独立评测的数据
8:43.220–8:46.300
验证一下这些能力到底有没有落到实处
8:46.300–8:48.880
这次的数据全部来自Artificial Analysis
8:48.880–8:52.800
这是目前业界专门做代理人模型评测的独立机构
8:52.800–8:54.400
不是Meta自己跑的分
8:54.400–8:56.120
参考价值相对高一些
8:56.120–8:58.760
在他们的综合智慧指数榜单上
8:58.760–9:02.140
Spark 1.3的Shy版本拿到61分
9:02.140–9:06.220
还在有限预览阶段的Max版本拿到62分
9:06.220–9:08.400
比起1.2版本的57分
9:08.400–9:10.360
Exia整整涨了4分
9:10.360–9:15.300
在AI评测里 4分的涨幅算不算大 要看在哪个区间
9:15.300–9:19.300
如果从30分涨到34分 那只是入门级的进步
9:19.300–9:24.320
但从57分涨到61分已经是第一梯队模型的明显提升
9:24.320–9:27.080
因为越往上 每一分的难度都越高
9:27.080–9:32.200
更有竞争力的其实是成本XJ版本完成一项综合指数任务
9:32.200–9:37.980
平均花费0.55美元 在所有得分超过59分的模型里是最低的
9:37.980–9:39.760
我们可以简单对比一下
9:39.760–9:40.640
同级别里
9:40.640–9:43.040
OpenAI的GPT-4O Advanced
9:43.040–9:44.100
做类似任务
9:44.100–9:45.560
大概要1.2美元
9:45.560–9:47.700
Anthropic的Cloud Opus
9:47.700–9:49.500
则要1.5美元左右
9:49.500–9:51.620
Meta差不多只要一半的价格
9:51.620–9:54.980
这对于需要大量呼叫API的企业用户来说
9:54.980–9:56.300
吸引力非常大
9:56.300–9:58.560
我们再拆开看具体任务的表现
9:58.560–10:00.280
Tile3-Bench Banking
10:00.280–10:02.680
是专门的银行代理人基准测试
10:02.680–10:05.240
模拟金融场景下的多步骤任务
10:05.240–10:06.340
1.2版本
10:06.340–10:08.740
当时只拿到35%的通过率
10:08.740–10:10.960
SHAE版本提升到47%
10:10.960–10:13.640
MAX版本更是达到52%
10:13.640–10:15.360
这个涨幅其实相当惊人
10:15.360–10:17.260
说明模型在处理合规
10:17.260–10:20.240
要求高步骤繁琐的金融任务时
10:20.240–10:22.840
可靠性比上一代强了很多
10:22.840–10:24.000
但也要客观说
10:24.000–10:25.580
47%的通过率
10:25.580–10:27.720
依然代表超过一半的任务
10:27.720–10:29.040
没办法完美完成
10:29.040–10:31.040
距离真正取代人类专员
10:31.040–10:32.780
还有非常远的距离
10:32.780–10:35.700
大概相当于入行半年的助理水平
10:35.700–10:38.980
Terminal-Bench 2.1是终端指令执行测试
10:38.980–10:41.300
1.2版本通过率80%
10:41.300–10:43.600
X-Shy提升到85%
10:43.600–10:45.300
Max到86%
10:45.300–10:46.620
这个分数看起来很高
10:46.620–10:48.640
但终端任务相对结构化
10:48.640–10:50.500
指令对错的标准很明确
10:50.500–10:52.240
能拿到高分并不意外
10:52.240–10:54.600
参考价值不如真实工作场景
10:54.600–10:57.320
真正值得注意的反而是一项退步的指标
10:57.320–11:00.100
AA-LCR长上下文基准
11:00.100–11:02.660
1.2版本有83%的正确率
11:02.660–11:05.240
1.3版本降到了79%
11:05.240–11:07.900
为什么长上下文能力反而退步了
11:07.900–11:10.060
难道模型越更新越差吗
11:10.060–11:10.920
当然不是
11:10.920–11:13.840
背后的原因是Spark 1.3调整了策略
11:13.840–11:15.140
遇到不确定的资讯
11:15.140–11:16.800
它更倾向于拒绝回答
11:16.800–11:18.660
而不是硬猜一个答案
11:18.660–11:20.780
也就是说它宁可少说几句
11:20.780–11:22.000
也不说错话
11:22.000–11:25.660
这种策略在AA-Omniscience准确率指标上
11:25.660–11:26.500
也能看出来
11:26.500–11:28.620
表面上准确率小幅回落
11:28.620–11:30.880
但幻觉率明显降低了
11:30.880–11:33.300
这其实是一个非常重要的取舍
11:33.300–11:34.960
你要更高的召回率
11:34.960–11:36.760
还是更高的准确率
11:36.760–11:38.060
对于普通用户来说
11:38.060–11:39.720
可能希望AI什么都能答
11:39.720–11:41.260
哪怕错一点也没关系
11:41.260–11:42.540
但对于企业用户
11:42.540–11:45.300
尤其是金融 医疗 法律这些领域
11:45.300–11:46.560
一个错误的答案
11:46.560–11:48.620
代价可能比没有答案大得多
11:48.620–11:51.160
之前就有企业用初代代理人模型
11:51.160–11:52.440
处理报销审核
11:52.440–11:55.500
结果模型编造了很多不存在的单据
11:55.500–11:57.600
造成了不小的财务漏洞
11:57.600–12:00.000
所以现在越是面向企业的模型
12:00.000–12:03.660
越把不编造放在比达对更高的优先级
12:03.660–12:04.760
从这个角度看
12:04.760–12:06.980
这项退步反而是一种进步
12:06.980–12:09.500
代表模型开始往实用化的方向走
12:09.500–12:11.700
而不是为了跑分应凑答案
12:11.700–12:13.340
另外很多人忽略的一点是
12:13.340–12:15.480
MAX版本的分数虽然更高
12:15.480–12:18.200
但代价是运算算力大幅增加
12:18.200–12:20.480
根据Artificial Analysis的测试
12:20.480–12:23.560
在GDPVAL-AAVFE任务里
12:23.560–12:27.540
MAX版本比SY多消耗约62%的推理量
12:27.540–12:29.540
就算是银行代理任务
12:29.540–12:31.780
也多了28%的算力
12:31.780–12:33.180
为什么会差这么多
12:33.180–12:36.060
因为MAX版本会做更多的自我检查
12:36.060–12:37.620
走更多的思维步骤
12:37.620–12:41.200
相当于人做事情的时候反复检查好几遍
12:41.200–12:43.260
自然更费时间更费算力
12:43.260–12:44.860
但正确率也更高
12:44.860–12:48.400
这其实带出了未来AI商业模式的一个可能方向
12:48.400–12:50.500
以后的模型不会只有单一档位
12:50.500–12:54.000
而是会根据任务的风险等级调整推理强度
12:54.000–12:55.140
低风险的闲聊
12:55.140–12:58.180
查资料用低档速度快又便宜
12:58.180–12:59.480
高风险的财务
12:59.480–13:01.180
法律任务用高档
13:01.180–13:03.220
更慢 更贵 但更可靠
13:03.220–13:05.160
用户可以按自己的需求选
13:05.160–13:07.020
而不是为了偶尔的高需求
13:07.020–13:08.940
全程付最贵的价格
13:08.940–13:10.860
当然 目前这还只是观察
13:10.860–13:13.820
Meta并没有正式推出这种分级定价
13:13.820–13:15.220
但从技术设计上
13:15.220–13:17.020
已经具备了这样的基础
13:17.020–13:18.660
最后 还要再强调一次
13:18.660–13:20.800
Max版本目前只是有限预览
13:20.800–13:23.540
只有少数合作机构和企业能拿到权限
13:23.540–13:25.440
普通开发者根本呼叫不到
13:25.440–13:27.920
所以你看到62分那个数字的时候
13:27.920–13:30.420
要知道它背后是更高的成本
13:30.420–13:32.300
更严格的访问限制
13:32.300–13:35.400
不能拿它去跟别人全面开放的API比
13:35.400–13:37.160
然后说Meta已经赢了
13:37.160–13:38.580
这种对比并不公平
13:38.580–13:40.920
看完了负责思考和执行的大脑
13:40.920–13:44.220
我们再转过头来讲这次连发的另一款产品
13:44.220–13:46.000
负责感知输入的耳朵
13:46.000–13:47.480
Muse Voice Transcribe
13:47.480–13:48.980
很多人第一眼看到它
13:48.980–13:51.280
会觉得不就是个语音转文字吗
13:51.280–13:52.360
有什么特别的
13:52.360–13:53.980
但实际上它的设计思路
13:53.980–13:56.720
跟传统的自动语音识别完全不一样
13:56.720–13:58.640
传统的ASR比如Whisper
13:58.640–14:00.440
走的是离线转写路线
14:00.440–14:02.840
拿到整段音频之后再慢慢处理
14:02.840–14:04.840
可以利用上下文反复修正
14:04.840–14:05.880
准确率很高
14:05.880–14:06.960
但延迟也大
14:06.960–14:09.560
根本没办法用来做实时对话
14:09.560–14:11.380
而以前的实时语音助手
14:11.380–14:13.940
比如手机上的Siri Google助理
14:13.940–14:15.320
为了追求低延迟
14:15.320–14:17.540
只能听一小段就马上输出
14:17.540–14:19.160
结果准确率很差
14:19.160–14:20.140
稍微吵一点
14:20.140–14:22.960
有两个人叠话或者混个外文单字
14:22.960–14:24.020
结果就歪掉
14:24.020–14:25.960
Muse Voice Transcribe想解决的
14:25.960–14:27.600
就是又要准又要快
14:27.600–14:29.840
还要懂真实对话这个老难题
14:29.840–14:32.960
它的做法是把音频切成80毫秒的小块
14:32.960–14:34.940
每秒处理12月5日次
14:34.940–14:37.980
每一小块音频先转换成一个软Token
14:37.980–14:41.080
模型在判断是要继续等后面的声音
14:41.080–14:42.760
还是立刻输出文字
14:42.760–14:44.500
等到音频完全停止
14:44.500–14:46.620
系统会加入一个特殊标记
14:46.620–14:50.440
让模型把剩下没输出的文字一口气吐出来
14:50.440–14:53.500
其中最关键的技术叫做自适应延迟
14:53.500–14:57.080
模型不会给每个字都设定一样的等待时间
14:57.080–14:59.480
简单确定的内容就立刻输出
14:59.480–15:02.220
碰到需要后文才能判断的同音词
15:02.220–15:03.140
专有名词
15:03.140–15:05.940
就稍微多等一点点音频再决定
15:05.940–15:08.160
这其实很像人类的同步口译
15:08.160–15:10.060
译员会根据句子的难度
15:10.060–15:11.680
调整自己的滞后时间
15:11.680–15:13.040
不会一味求快
15:13.040–15:14.400
也不会一味求准
15:14.400–15:15.180
训练的时候
15:15.180–15:17.540
Meta把词 错误率和延迟时间
15:17.540–15:20.180
一起放进强化学习的奖励函数里
15:20.180–15:21.900
如果模型只追求准确
15:21.900–15:23.280
每句话都等很久
15:23.280–15:24.240
得分不会高
15:24.240–15:25.400
只追求速度
15:25.400–15:27.900
输出一大堆错字同样过不了关
15:27.900–15:32.460
最终目标就是在准确率和反应速度之间找到最佳平衡点
15:32.460–15:33.680
那实际表现如何
15:33.680–15:37.060
在Artificial Analysis的流逝语音榜单上
15:37.060–15:42.060
Muse Voice Transcribe的最终词错误率约3.1%
15:42.060–15:43.460
直接登上第一名
15:44.354–15:46.348
这个数字是什么概念?
15:46.348–15:48.342
在流逝实时的场景下,
15:48.342–15:52.530
3.1%已经非常接近人类专业数据员的水平,
15:52.530–15:55.123
人类大概是2%到3%左右,
15:55.123–15:58.114
相当于每讲100个字只错3个。
15:58.114–16:00.094
不过这里必须先打个预防针
16:00.094–16:02.894
这个成绩是英语流逝对话的测试结果
16:02.894–16:06.374
绝对不能直接套用到所有语言 所有场景
16:06.374–16:08.834
中文因为同音字多 声调复杂
16:08.834–16:13.214
同样的模型词错误率通常会比英语高2到3个百分点
16:13.214–16:17.294
如果是嘈杂环境 多人强化 或者带方言口音
16:17.294–16:19.014
表现还会再打折扣
16:19.014–16:22.834
官方也明确说 模型训练覆盖了70多种语言
16:22.834–16:25.734
其中只有25种经过充分验证
16:25.734–16:27.834
其他语言可能只是有训练过
16:27.834–16:30.234
但没有经过严格的效果评测
16:30.234–16:32.134
除了基础的转写准确率
16:32.134–16:34.194
还有几个功能特别值得一提
16:34.194–16:36.714
首先是原生的说话人分离
16:36.714–16:39.334
而且支持20人以上同时发言
16:39.334–16:42.094
传统的会议转写通常是先做语音识别
16:42.094–16:44.014
再另外用一套声文系统
16:44.014–16:45.714
判断每段话是谁说的
16:45.714–16:47.194
两个系统的时间轴
16:47.194–16:49.354
只要差一点点就会出现文字
16:49.354–16:50.474
人认错的情况
16:50.474–16:52.814
Meta是在同一个生成过程里
16:52.814–16:55.674
加入说话人切换标记和身份标签
16:55.674–16:58.434
检测到换人就先标一轮新发言
16:58.434–17:00.894
等听到足够声音再确定身份
17:00.894–17:03.014
时间轴的准确度会高很多
17:03.014–17:06.214
官方展示的长对话里包含多人插话
17:06.214–17:08.314
重叠发言 自然停顿
17:08.314–17:10.194
都能正确标记身份
17:10.194–17:13.734
这对于会议记录 访谈整理 客服记录来说
17:13.734–17:14.674
价值很高
17:14.674–17:18.214
因为后续的摘要系统拿到的不只是一整段文字
17:18.214–17:20.894
还知道谁提了问题 谁做了承诺
17:20.894–17:22.234
谁反对哪个方案
17:22.234–17:23.974
其次是端点侦测能力
17:23.974–17:27.474
人类对话本来就不会每次讲完都按个结束钮
17:27.474–17:30.794
系统要从语气停顿和上下文判断
17:30.794–17:33.474
对方只是喘口气还是真的说完了
17:33.474–17:35.014
如果端点判断不准
17:35.014–17:36.694
要么用户都讲完半天了
17:36.694–17:37.774
助手还没反应
17:37.774–17:39.234
要么用户还没说完
17:39.234–17:41.494
助手就急着插嘴体验都很差
17:41.494–17:42.814
Muse Voice Transcribe
17:42.814–17:44.654
专门针对这点做了优化
17:44.654–17:47.514
能更准确判断语音的开始和结束
17:47.514–17:50.014
这也是代理人能自然对话的前提
17:50.014–17:51.894
第三个很实用的功能是
17:51.894–17:54.594
句内和句间的多语言自由切换
17:54.594–17:56.134
还有上下文偏制
17:56.134–17:58.374
现实中很多双语使用者
17:58.374–18:00.574
不会先切语言模式再讲话
18:00.574–18:02.994
中文句子里夹个英文专有名词
18:02.994–18:05.274
项目代号是家常便饭
18:05.274–18:06.954
旧的系统很容易把英文词
18:06.954–18:08.994
应转成发音相近的中文字
18:08.994–18:11.494
或者切换语言之后直接丢了半句话
18:11.494–18:12.994
Muse Voice Transcribe
18:12.994–18:15.294
支持70多种语言的自由切换
18:15.294–18:18.254
还可以让用户提前输入常用的人名
18:18.254–18:19.734
公司名专业术语
18:19.734–18:21.714
模型碰到相近发音的时候
18:21.714–18:24.994
会优先选择这些符合上下文的词
18:24.994–18:27.654
比如医生可以提前录入药品名称
18:27.654–18:30.914
城市设计师可以加入函数名和项目代号
18:30.914–18:33.594
企业用户可以上传内部数语表
18:33.594–18:36.014
这样转写的准确率会大幅提升
18:36.014–18:38.154
甚至可以直接进入工作流程
18:38.154–18:39.714
不用再人工校对一遍
18:39.714–18:42.054
这才是语音转写真正的价值
18:42.054–18:44.254
不是把声音变成文字就好
18:44.254–18:46.234
而是变成能直接用的文字
18:46.234–18:47.874
目前Muse Voice Transcribe
18:47.874–18:49.614
已经接入Meta Model API
18:49.614–18:52.774
还有Meta AI4 Mac Muse Code Mac版本
18:52.774–18:55.494
用户可以按住FN键直接语音输入
18:55.494–18:58.314
把转写结果送到不同的应用程式里
18:58.314–19:00.834
不过有个隐私细节一定要讲清楚
19:00.834–19:04.734
官方网页演示的时候说麦克风音频只会用来生成转写
19:04.734–19:05.614
不会被保存
19:05.614–19:08.394
但这个承诺只限于网页演示场景
19:08.394–19:10.254
不等于所有API呼叫
19:10.254–19:13.014
所有产品部署都不会保存音频
19:13.014–19:15.354
如果你是透过API上传录音
19:15.354–19:16.694
Meta会不会保存
19:16.694–19:17.554
保存多久
19:17.554–19:19.254
会不会用来训练模型
19:19.254–19:22.774
都要看你签署的服务条款和数据处理协议
19:22.774–19:24.714
不能因为网页演示不保存
19:24.714–19:28.074
就理所当然认为所有场景都不保存
19:28.074–19:30.994
这在个资合规上是非常危险的认知
19:30.994–19:33.534
讲到这里就必须好好聊一下
19:33.534–19:35.034
隐私与安全的边界
19:35.034–19:37.354
这也是很多人看AI产品的时候
19:37.354–19:40.374
最容易忽略但绝对最重要的部分
19:40.374–19:42.854
先讲Muse Spark 1.3的安全设计
19:42.854–19:45.254
官方说这次提升了对提示注入
19:45.254–19:47.294
和对抗输入的抵抗能力
19:47.294–19:49.994
也更能识别哪些操作是不可逆的
19:49.994–19:51.054
提示注入是什么
19:51.054–19:53.254
就是攻击者在输入内容里
19:53.254–19:55.274
嵌入看不见的恶意指令
19:55.274–19:57.314
比如藏在PDF档案里
19:57.314–19:58.114
网页里
19:58.114–20:00.834
诱导AI代理人忽略原本的规则
20:00.834–20:02.554
去转发机密档案
20:02.554–20:03.974
修改设定甚至转账
20:03.974–20:06.434
2025年就曾经出现过
20:06.434–20:07.714
类似的攻击案例
20:07.714–20:10.754
让不少企业对AI代理人望而却步
20:10.754–20:13.774
Spark 1.3针对这类攻击做了专门训练
20:13.774–20:15.594
但这不代表它完全免疫
20:15.594–20:19.874
目前没有任何模型能100%防御所有提示注入攻击
20:19.874–20:21.594
识别不可逆操作也是一样
20:21.594–20:23.394
模型能标出删除档案
20:23.394–20:24.574
发送批量邮件
20:24.574–20:26.934
修改数据库这些高风险动作
20:26.934–20:28.334
要求用户确认
20:28.334–20:31.114
但光有模型层面的防护远远不够
20:31.114–20:33.814
官方自己也强调实际部署的时候
20:33.814–20:36.374
必须同时做好全线隔离
20:36.374–20:38.454
白名单和操作日志
20:38.454–20:41.514
全线隔离就是给代理人最小必要的全线
20:41.514–20:43.754
比如负责整理表格的助理
20:43.754–20:46.534
就不该有删除整个资料夹的权限
20:46.534–20:50.654
白名单就是只允许模型呼叫预先核准的
20:50.654–20:54.834
工具和API不能让它随便访问系统里的任何东西
20:54.834–20:58.954
操作日志就是把代理人所有执行动作都记录下来
20:58.954–21:01.134
方便事后审计和回溯
21:01.134–21:04.334
这三层防护都是资安领域的基本常识
21:04.334–21:07.754
却也是很多AI产品最容易省略的部分
21:07.754–21:09.614
Meta愿意主动强调这点
21:09.614–21:13.234
说明它是真的在考虑企业落地的实际需求
21:13.234–21:15.894
而不是只做展示用的技术demo
21:15.894–21:16.974
再回到语音部分
21:16.974–21:19.874
当语音转写加上代理人执行
21:19.874–21:23.534
再搭配Meta旗下的ray减班智慧眼镜
21:23.534–21:25.214
想象空间确实很大
21:25.214–21:28.694
手机上的语音助手要等你点开APP才能用
21:28.694–21:30.854
但眼镜可以一直戴在脸上
21:30.854–21:32.794
随时处在声音环境里
21:32.794–21:34.574
如果他能听懂谁在讲话
21:34.574–21:35.814
什么时候该接话
21:35.814–21:37.134
什么时候不该插嘴
21:37.134–21:39.954
就能在会议后自动整理每个人的行动项
21:39.954–21:42.014
访谈的时候自动标记重点
21:42.014–21:46.134
甚至日常聊天里提到的代办事项都能自动记下来
21:46.134–21:48.634
但这也带来了更尖锐的隐私问题
21:48.634–21:50.974
眼镜上的麦克风什么时候在听
21:50.974–21:52.874
听到的内容传到哪里去了
21:52.874–21:54.914
用户有没有明确的控制权
21:54.914–21:57.234
旁边的人知不知道自己正在被录音
21:57.234–22:00.234
这些问题目前都还没有完全公开的答案
22:00.234–22:04.274
不过我们可以从Meta的双轨策略里推出一个很合理的假设
22:04.274–22:06.954
未来轻量级的语音转写
22:06.954–22:08.534
简单的指令理解
22:08.534–22:12.294
很可能会直接跑在眼镜本地的端侧芯片上
22:12.294–22:13.534
不需要传到云端
22:13.534–22:15.294
敏感数据不会离开设备
22:15.294–22:17.034
大幅降低隐私风险
22:17.034–22:18.774
而复杂的常任务代理
22:18.774–22:19.934
多工具协作
22:19.934–22:22.694
再交给云端的Spark模型处理
22:22.694–22:25.634
刚好Meta有Glimmer这条本地开源路线
22:25.634–22:27.694
专门做轻量化端侧部署
22:27.694–22:30.634
刚好可以跟眼镜这类终端装置搭配
22:30.634–22:32.334
云端负责复杂思考
22:32.334–22:34.034
本地负责实时感知
22:34.034–22:36.274
既保证体验又兼顾隐私
22:36.274–22:40.194
这很可能就是Meta下一代AI入口的完整架构
22:40.194–22:42.834
当然这只是基于现有产品线的推测
22:42.834–22:44.754
官方还没有证实这个方向
22:44.754–22:46.794
讲完了技术亮点和想象空间
22:46.794–22:48.234
我们也得冷静下来
22:48.234–22:51.154
聊聊这次发布的口径边界和实际风险
22:51.154–22:54.114
首先Max版本目前只是有线预览
22:54.114–22:56.514
普通开发者能用的只有Shi版本
22:56.514–22:58.834
网上所有关于Max的评测数据
22:58.834–23:01.034
都来自少数拿到权限的机构
23:01.034–23:03.074
一般用户现在根本用不到
23:03.074–23:07.054
所以62分那个数字只能当成技术上限的参考
23:07.054–23:10.094
不能作为采购或者使用决策的依据
23:10.094–23:12.414
其次所有的基准测试数据
23:12.414–23:15.414
都是在标准化的干净环境里跑出来的
23:15.414–23:19.494
真实世界的场景只会更复杂更混乱
23:19.494–23:22.494
比如银行代理测试里的数据都是结构化的
23:22.494–23:24.154
格式统一全线清晰
23:25.087–23:26.443
但真实的企业里,
23:26.443–23:29.154
数据可能分散在十几个老旧系统里,
23:29.154–23:30.341
格式乱七八糟、
23:30.341–23:31.527
权限层层卡关。
23:31.527–23:37.207
你在测试里拿到47%的通过率,到了真实环境可能连30%都不到。
23:37.207–23:43.787
这不是Meta的问题 是所有AI模型评测的普遍现象 跑分永远不等于真实生产力
23:43.787–23:46.327
第三 关于开源的期待也要放低
23:46.327–23:51.754
Spark 1.3目前是完全避原的 官方只说未来有开放权重的规划
23:51.754–23:54.287
但没有时间表 也没有说授权条款
23:54.287–24:01.247
参考Meta之前Lama系列的节奏 通常是新一代出来之后才会把上一代的权重逐步开放
24:01.247–24:06.807
而且早期都是非商业授权 要等到更后面才会用更宽松的授权
24:06.807–24:10.007
所以不要期待短期内就能在自己的电脑上
24:10.007–24:12.987
跑Spark 1.3核心的代理人能力
24:12.987–24:16.127
Meta肯定会先握在手里当商业护城河
24:16.127–24:18.087
最后回到产业竞争的层面
24:18.087–24:20.447
Meta这次的更新确实扎实
24:20.447–24:25.027
在代理人可靠性和流逝语音转写上都往前走了一步
24:25.027–24:27.327
成本控制也做得很有竞争力
24:27.327–24:29.227
但要说已经赢了还太早
24:29.227–24:33.127
OpenEye的GPT系列代理人能力同样在快速迭代
24:33.127–24:37.847
谷歌的Gemini在多模态和端侧整合上有自己的优势
24:37.847–24:42.527
Anthropic在长上下文和安全合规上依然领先
24:42.527–24:46.927
还有Eleven Labs这类专业语音公司也在往代理人方向走
24:46.927–24:52.547
Meta现在的领先更像是某几个细分场景的小幅度领先
24:52.547–24:55.207
还远没有到拉开差距的程度
24:55.207–24:58.527
而且真正的竞争从来都不是比模型本身
24:58.527–25:02.807
而是比谁能先把技术变成用户愿意天天用的产品
25:02.807–25:04.927
谁能解决好隐私安全
25:04.927–25:06.967
权限这些麻烦的落地问题
25:06.967–25:08.247
模型再聪明
25:08.247–25:10.887
如果用户不敢把重要的工作交给他
25:10.887–25:12.587
那也只是个高级玩具
25:12.587–25:13.167
讲到这里
25:13.167–25:16.007
我们把这次Meta两款产品的技术细节
25:16.007–25:16.947
评测数据
25:16.947–25:18.107
产品线定位
25:18.107–25:19.027
隐私风险
25:19.027–25:21.187
还有产业格局全部拆完了
25:21.187–25:23.667
你会发现每一个亮眼的数据背后
25:23.667–25:25.307
都有一个限定条件
25:25.307–25:27.067
每一项技术突破的旁边
25:27.067–25:29.227
都站着一个带解决的问题
25:29.227–25:30.947
这不是说Meta做得不好
25:30.947–25:32.047
恰恰相反
25:32.047–25:34.567
只有当你看清了所有的边界和限制
25:34.567–25:36.587
才能真正评估它的价值
25:36.587–25:41.227
Muse Spark 1.3确实把常任务代理人的可靠性往前推了一步
25:41.227–25:43.027
成本优势也很明显
25:43.027–25:46.167
Muse Voice Transcribe在英语流逝转写上
25:46.167–25:48.187
做到了业界顶尖
25:48.187–25:50.827
准确率和延迟的平衡做得可圈可点
25:50.827–25:53.427
但它们都还只是阶段性的进展
25:53.427–25:56.067
离大家想象中什么都能做的AI助理
25:56.067–25:57.647
还有非常远的距离
25:57.647–25:59.707
2026年的AI产业
25:59.707–26:02.607
其实正在经历一个很重要的转向
26:02.607–26:05.447
前几年大家都在比谁的模型更大
26:05.447–26:06.747
谁的跑分更高
26:06.747–26:08.627
谁的牛皮吹得更响
26:08.627–26:12.087
但从今年开始竞争慢慢落到了实处
26:12.087–26:14.167
比的是谁能把长任务做稳
26:14.167–26:15.927
谁能把真实声音听懂
26:15.927–26:17.727
谁能让企业敢放心用
26:17.727–26:20.227
谁能把隐私控制在合理范围
26:20.227–26:22.847
那些看起来不怎么耀眼的细节优化
26:22.847–26:27.407
反而决定了产品能不能真正走进日常生活和工作流
26:27.407–26:28.267
就像造车
26:28.267–26:36.447
早期大家都比马力 比急速 等到市场成熟了 比的是隔音 是油耗 是故障率 是乘坐舒适度
26:36.447–26:39.987
这些才是决定你愿不愿意每天开的关
26:39.987–26:45.347
见如果你喜欢这种不吹不黑 把数据和限制都讲清楚的深度科技解析
26:45.347–26:48.947
欢迎订阅这个频道 并且打开通知小铃铛
26:48.947–26:54.787
我们会持续追踪AI代理人 语音交互 端策AI这些领域的最新进展
26:54.787–26:57.307
帮你过滤掉夸大的营销话术
26:57.307–26:59.727
留下真正值得关注的技术变化
26:59.727–27:01.327
也欢迎在留言区告诉我
27:01.327–27:04.287
你最期待AI帮你完成什么样的任务
27:04.287–27:05.927
是整理会议记录
27:05.927–27:07.887
还是处理繁琐的文书工作
27:07.887–27:09.647
我们下期影片再见
0:00.000–0:02.300
zh你有没有过这种很无力的经验?
你有没有过这种很无力的经验?
0:02.300–0:05.000
zh叫AI帮你整理一份跨部门的会议报告。
叫AI帮你整理一份跨部门的会议报告。
0:05.000–0:09.300
zh做到一半它忘了你要求的章节格式,用语音助手查形成。
做到一半它忘了你要求的章节格式,用语音助手查形成。
0:09.300–0:13.700
zh旁边同事插句话,它就把指令听成完全不相干的内容。
旁边同事插句话,它就把指令听成完全不相干的内容。
0:13.700–0:20.500
zh只要任务超过三个步骤,需要跨两个以上工具,最后交付的结果一定歪掉大半。
只要任务超过三个步骤,需要跨两个以上工具,最后交付的结果一定歪掉大半。
0:20.500–0:23.667
zh你大概也听过很多人说AI已经很聪明了,
你大概也听过很多人说AI已经很聪明了,
0:23.667–0:25.000
zh但真的拿来干活,
但真的拿来干活,
0:25.000–0:27.500
zh总是卡在这些最不起眼的小地方。
总是卡在这些最不起眼的小地方。
0:27.500–0:29.980
zh2026年9月的头两天
2026年9月的头两天
0:29.980–0:32.400
zhMeta接连丢出了两项更新
Meta接连丢出了两项更新
0:32.400–0:34.840
zh没有吹什么通用人工智能的牛皮
没有吹什么通用人工智能的牛皮
0:34.840–0:38.480
zh却精准踩中了这些大家天天吐槽的痛点
却精准踩中了这些大家天天吐槽的痛点
0:38.480–0:41.760
zh一个负责把真实世界里的声音听得更清楚
一个负责把真实世界里的声音听得更清楚
0:41.760–0:44.780
zh一个负责把复杂的常任务做得更稳
一个负责把复杂的常任务做得更稳
0:44.780–0:48.720
zh有人看完数据说Meta终于要在代理人战场超车了
有人看完数据说Meta终于要在代理人战场超车了
0:48.720–0:50.420
zh也有人冷静算完成本
也有人冷静算完成本
0:50.420–0:52.540
zh发现事情根本没有这么简单
发现事情根本没有这么简单
0:52.540–0:54.180
zh今天我们就不吹不黑
今天我们就不吹不黑
0:54.180–0:57.220
zh把官方技术文件第三方独立评测
把官方技术文件第三方独立评测
0:57.220–1:00.140
zh还有那些藏在角落的小字限制
还有那些藏在角落的小字限制
1:00.140–1:01.840
zh全部摊开来讲
全部摊开来讲
1:01.840–1:04.620
zh看看这两款产品到底走到了哪一步
看看这两款产品到底走到了哪一步
1:04.620–1:07.300
zh又有哪些东西是营销不会告诉你的
又有哪些东西是营销不会告诉你的
1:07.300–1:08.860
zh我们不从结论讲起
我们不从结论讲起
1:08.860–1:12.280
zh因为真正有价值的判断往往都藏在每一个
因为真正有价值的判断往往都藏在每一个
1:12.280–1:13.380
zh但是后面
但是后面
1:13.380–1:17.300
zh先帮大家把最容易搞混的产品线界限画清楚
先帮大家把最容易搞混的产品线界限画清楚
1:17.300–1:20.100
zh这也是很多自媒体最常讲错的地方
这也是很多自媒体最常讲错的地方
1:20.100–1:24.160
zh9月1日登场的是Muse Voice Transcribe语音转写模型
9月1日登场的是Muse Voice Transcribe语音转写模型
1:24.160–1:28.160
zh9月2日接棒上线的是Muse Spark 1.3代理人模型
9月2日接棒上线的是Muse Spark 1.3代理人模型
1:28.160–1:30.560
zh两天连续发布核心产品
两天连续发布核心产品
1:30.560–1:34.340
zh这在Meta Superintelligence Labs的历史上并不常见
这在Meta Superintelligence Labs的历史上并不常见
1:34.340–1:38.520
zh也能看出他们在2026年下半年的竞争焦虑
也能看出他们在2026年下半年的竞争焦虑
1:38.520–1:39.500
zh但更重要的是
但更重要的是
1:39.500–1:41.780
zh很多人到现在还搞不清楚
很多人到现在还搞不清楚
1:41.780–1:43.960
zhMuse Spark和Muse Glimmer
Muse Spark和Muse Glimmer
1:43.960–1:46.860
zh根本是两条完全不同的路线
根本是两条完全不同的路线
1:46.860–1:48.180
zh不能混为一谈
不能混为一谈
1:48.180–1:51.280
zhMuse Spark走的是云端前沿代理人路线
Muse Spark走的是云端前沿代理人路线
1:51.280–1:52.720
zh权重完全必圆
权重完全必圆
1:52.720–1:54.820
zh目前只开放API呼叫
目前只开放API呼叫
1:54.820–1:57.560
zh官方只说未来有开放权重的规划
官方只说未来有开放权重的规划
1:57.560–1:59.000
zh但既没有时间表
但既没有时间表
1:59.000–2:01.280
zh也没说会用哪种授权条款
也没说会用哪种授权条款
2:01.280–2:03.420
zh所以你绝对不能把它理解成
所以你绝对不能把它理解成
2:03.420–2:05.700
zh马上就可以下载来本地跑
马上就可以下载来本地跑
2:05.700–2:08.540
zh而Muse Glimmer是拥有300亿参数
而Muse Glimmer是拥有300亿参数
2:08.540–2:11.860
zh采用Apache 2.0授权的本地方案
采用Apache 2.0授权的本地方案
2:11.860–2:14.140
zh主打消费级显示卡就能执行
主打消费级显示卡就能执行
2:14.140–2:14.780
zh讲白一点
讲白一点
2:14.780–2:17.100
zhSpark负责把能力堆到最高
Spark负责把能力堆到最高
2:17.100–2:19.680
zh强企业级和高端开发者市场
强企业级和高端开发者市场
2:19.680–2:21.840
zhGlimmer负责把能力扑到最广
Glimmer负责把能力扑到最广
2:21.840–2:24.100
zh占领开源生态和终端装置
占领开源生态和终端装置
2:24.100–2:28.680
zh这种双轨策略其实刚好对应了Meta在AI产业的定位转变
这种双轨策略其实刚好对应了Meta在AI产业的定位转变
2:28.680–2:33.400
zh前几年大家提到Meta的AI第一个想到的就是Lama系列开源模型
前几年大家提到Meta的AI第一个想到的就是Lama系列开源模型
2:33.400–2:34.960
zh靠免费打天下
靠免费打天下
2:34.960–2:37.980
zh跟OpenAI的全B原路线正面抗衡
跟OpenAI的全B原路线正面抗衡
2:37.980–2:40.060
zh但到了2026年
但到了2026年
2:40.060–2:43.760
zh整个行业的竞争已经从比参数 比跑分
整个行业的竞争已经从比参数 比跑分
2:43.760–2:46.900
zh进到比代理人 比落地场景的阶段
进到比代理人 比落地场景的阶段
2:46.900–2:50.140
zhMeta必须拿出足够强的B原顶端产品
Meta必须拿出足够强的B原顶端产品
2:50.140–2:51.600
zh才能跟GPT系列
才能跟GPT系列
2:51.600–2:53.700
zhGemini系列抢商业客户
Gemini系列抢商业客户
2:53.700–2:56.760
zh同时又不能丢掉开源生态的优势
同时又不能丢掉开源生态的优势
2:56.760–2:59.240
zh为什么要花这么多时间讲这件事
为什么要花这么多时间讲这件事
2:59.240–3:00.540
zh因为如果你误以为
因为如果你误以为
3:00.540–3:02.580
zhSpark 1.3是开源模型
Spark 1.3是开源模型
3:02.580–3:04.660
zh就会产生错误的部署预期
就会产生错误的部署预期
3:04.660–3:08.220
zh如果你以为Glimmer只是Spark的缩小版
如果你以为Glimmer只是Spark的缩小版
3:08.220–3:11.700
zh就会低估两者在设计目标上的根本差异
就会低估两者在设计目标上的根本差异
3:11.700–3:13.160
zh另外从迭代节奏来看
另外从迭代节奏来看
3:13.160–3:15.500
zhMuse系列从7月的1.1版
Muse系列从7月的1.1版
3:15.500–3:17.360
zh首次连上邮件行事例
首次连上邮件行事例
3:17.360–3:23.160
zh并能制作投影片到8月初1.2版聚焦大型程式库与复杂真错
并能制作投影片到8月初1.2版聚焦大型程式库与复杂真错
3:23.160–3:25.700
zh甚至能连续1000多次工具呼叫
甚至能连续1000多次工具呼叫
3:25.700–3:30.260
zh在24小时内反复编写编译GPU核心程式
在24小时内反复编写编译GPU核心程式
3:30.260–3:33.600
zh8月中再加入图像与视频理解能力
8月中再加入图像与视频理解能力
3:33.600–3:37.140
zh到9月的1.3版转向打磨长期任务的可用性
到9月的1.3版转向打磨长期任务的可用性
3:37.140–3:40.500
zh几乎保持每个月一次大版本更新的速度
几乎保持每个月一次大版本更新的速度
3:40.500–3:43.000
zh这种快速迭代在AI圈不算稀奇
这种快速迭代在AI圈不算稀奇
3:43.000–3:47.680
zh但难得的是Meta几乎每一版都会附上明确的内部对比数据
但难得的是Meta几乎每一版都会附上明确的内部对比数据
3:47.680–3:49.960
zh同时引用第三方评测结果
同时引用第三方评测结果
3:49.960–3:52.880
zh给了外界一个相对透明的观察窗口
给了外界一个相对透明的观察窗口
3:52.880–3:55.220
zh很多人只盯着分数涨了多少
很多人只盯着分数涨了多少
3:55.220–3:58.020
zh却忽略了每一代版本的定位差异
却忽略了每一代版本的定位差异
3:58.020–4:02.200
zhSpark 1.3并不是全面碾压1.2的终极进化
Spark 1.3并不是全面碾压1.2的终极进化
4:02.200–4:05.600
zh而是针对代理人任务的可靠性做了针对性强化
而是针对代理人任务的可靠性做了针对性强化
4:05.600–4:09.420
zh甚至在部分涨上下文指标上还出现了小幅退步
甚至在部分涨上下文指标上还出现了小幅退步
4:09.420–4:11.240
zh这种有得有失的升级
这种有得有失的升级
4:11.240–4:14.860
zh恰恰说明模型能力不是简单的线性叠加
恰恰说明模型能力不是简单的线性叠加
4:14.860–4:17.660
zh而是一连串的取舍与权衡
而是一连串的取舍与权衡
4:17.660–4:19.960
zh如果你只看营销文案里的亮点
如果你只看营销文案里的亮点
4:19.960–4:23.140
zh很快就会在实际使用中发现落差
很快就会在实际使用中发现落差
4:23.140–4:25.500
zh如果你翻完这次的全部技术文件
如果你翻完这次的全部技术文件
4:25.500–4:27.400
zh会发现最核心的关键词
会发现最核心的关键词
4:27.400–4:28.760
zh不是更高的分数
不是更高的分数
4:28.760–4:30.280
zh也不是更多的参数
也不是更多的参数
4:30.280–4:32.300
zh而是长任务代理人
而是长任务代理人
4:32.300–4:33.440
zh什么意思
什么意思
4:33.440–4:36.500
zh就是让AI不再只是一次性回答一个问题
就是让AI不再只是一次性回答一个问题
4:36.500–4:39.160
zh而是像一个真正的执行助理一样
而是像一个真正的执行助理一样
4:39.160–4:41.220
zh接下一个模糊的需求
接下一个模糊的需求
4:41.220–4:43.480
zh自己拆解步骤 呼叫工具
自己拆解步骤 呼叫工具
4:43.480–4:44.880
zh遇到问题回头问你
遇到问题回头问你
4:44.880–4:46.100
zh碰到危险操作
碰到危险操作
4:46.100–4:49.380
zh先停下来确认最后再交付完整的成果
先停下来确认最后再交付完整的成果
4:49.380–4:50.480
zh这听起来很美好
这听起来很美好
4:50.480–4:53.680
zh但过去大部分代理人模型的问题无非三种
但过去大部分代理人模型的问题无非三种
4:53.680–4:55.880
zh要么不敢动手只会空泛回答
要么不敢动手只会空泛回答
4:55.880–4:58.680
zh要么乱动手做到一半偏离目标
要么乱动手做到一半偏离目标
4:58.680–5:02.000
zh更常见的是干到一半彻底忘了最原始的要求
更常见的是干到一半彻底忘了最原始的要求
5:02.000–5:05.020
zhSpark 1.3就是冲着这些痛点做的优化
Spark 1.3就是冲着这些痛点做的优化
5:05.020–5:06.460
zh举个很实际的场景
举个很实际的场景
5:06.460–5:07.620
zh如果你跟模型说
如果你跟模型说
5:07.620–5:10.520
zh帮我整理上礼拜的三场客户会议记录
帮我整理上礼拜的三场客户会议记录
5:10.520–5:11.800
zh做成部门简报
做成部门简报
5:11.800–5:14.120
zh把每个客户的行动项列出来
把每个客户的行动项列出来
5:14.120–5:15.440
zh最后寄给主管
最后寄给主管
5:15.440–5:16.680
zh换做之前的模型
换做之前的模型
5:16.680–5:19.780
zh很可能做到一半就忘了要按客户分类
很可能做到一半就忘了要按客户分类
5:19.780–5:21.800
zh或者漏了寄信的步骤
或者漏了寄信的步骤
5:21.800–5:24.980
zh甚至为了凑数编造几个不存在的行动项
甚至为了凑数编造几个不存在的行动项
5:24.980–5:27.920
zh而Spark 1.3的处理逻辑会完全不同
而Spark 1.3的处理逻辑会完全不同
5:27.920–5:30.280
zh一开始如果觉得需求不够清楚
一开始如果觉得需求不够清楚
5:30.280–5:31.920
zh它会主动追问你
它会主动追问你
5:31.920–5:34.800
zh简报要的是正式版本还是讨论版
简报要的是正式版本还是讨论版
5:34.800–5:37.500
zh行动项要不要加上预计完成时间
行动项要不要加上预计完成时间
5:37.500–5:40.440
zh寄信的时候要不要附上原始记录档
寄信的时候要不要附上原始记录档
5:40.440–5:44.660
zh执行过程中如果发现某份会议记录打不开或者权限不足
执行过程中如果发现某份会议记录打不开或者权限不足
5:44.660–5:46.580
zh它会停下来跟你要资讯
它会停下来跟你要资讯
5:46.580–5:49.160
zh而不是硬着头皮编一个结果
而不是硬着头皮编一个结果
5:49.160–5:50.460
zh如果碰到删除档案
如果碰到删除档案
5:50.460–5:51.640
zh发送批量邮件
发送批量邮件
5:51.640–5:55.080
zh修改正式环境设定这类有不可逆风险的操作
修改正式环境设定这类有不可逆风险的操作
5:55.080–5:57.020
zh它一定会先跳出确认
它一定会先跳出确认
5:57.020–5:58.480
zh问你确定要执行吗
问你确定要执行吗
5:58.480–5:59.980
zh不会自己直接动手
不会自己直接动手
5:59.980–6:00.880
zh更重要的是
更重要的是
6:00.880–6:04.180
zh它能分辨你现在是在补充当前任务的资讯
它能分辨你现在是在补充当前任务的资讯
6:04.180–6:06.600
zh还是要打断手头的事做别的
还是要打断手头的事做别的
6:06.600–6:09.380
zh又或者是要开启一个全新的任务
又或者是要开启一个全新的任务
6:09.380–6:11.580
zh这听起来好像是基础能力,
这听起来好像是基础能力,
6:11.580–6:13.047
zh但在多轮对话里,
但在多轮对话里,
6:13.047–6:16.530
zh很多模型会把用户随口的插画当成新指令,
很多模型会把用户随口的插画当成新指令,
6:16.530–6:19.280
zh直接把之前的上下文全部覆盖掉,
直接把之前的上下文全部覆盖掉,
6:19.280–6:21.480
zh导致任务做到一半就断了。
导致任务做到一半就断了。
6:21.480–6:28.000
zh针对长期任务最常见的约束遗忘问题,Spark 1.3也做了专门强化。
针对长期任务最常见的约束遗忘问题,Spark 1.3也做了专门强化。
6:28.000–6:29.600
zh比如你一开始就说过
比如你一开始就说过
6:29.600–6:31.880
zh所有输出都要用正体中文
所有输出都要用正体中文
6:31.880–6:33.520
zh不能用外部图片素材
不能用外部图片素材
6:33.520–6:35.400
zh数据不能超过指定范围
数据不能超过指定范围
6:35.400–6:37.160
zh他会在整个执行过程中
他会在整个执行过程中
6:37.160–6:38.760
zh反复检查这些条件
反复检查这些条件
6:38.760–6:41.380
zh而不是跑个五六步之后就全忘了
而不是跑个五六步之后就全忘了
6:41.380–6:42.440
zh最关键的一点
最关键的一点
6:42.440–6:44.920
zh是他对自身能力边界的判断
是他对自身能力边界的判断
6:44.920–6:46.400
zh过去很多代理人模型
过去很多代理人模型
6:46.400–6:47.420
zh最危险的习惯
最危险的习惯
6:47.420–6:48.880
zh就是任务做不完的时候
就是任务做不完的时候
6:48.880–6:50.120
zh会假装做完了
会假装做完了
6:50.120–6:51.260
zh然后生成一份
然后生成一份
6:51.260–6:52.860
zh看起来很完整的报告
看起来很完整的报告
6:52.860–6:55.400
zh里面全是编造的数据和结论
里面全是编造的数据和结论
6:55.400–6:57.220
zh普通用户根本看不出来
普通用户根本看不出来
6:57.220–7:01.260
zhBug1.3在训练时特别强化了这点遇到做不到的地方
Bug1.3在训练时特别强化了这点遇到做不到的地方
7:01.260–7:02.860
zh他更倾向于直接说
他更倾向于直接说
7:02.860–7:04.160
zh我卡在这里了
我卡在这里了
7:04.160–7:05.500
zh我缺少这个资讯
我缺少这个资讯
7:05.500–7:09.240
zh而不是硬凑出一份看似完美的答案
而不是硬凑出一份看似完美的答案
7:09.240–7:12.060
zhMeta内部工程师对比1.2版本后发现
Meta内部工程师对比1.2版本后发现
7:12.060–7:15.820
zh新版本平均减少了20%的工具呼叫次数
新版本平均减少了20%的工具呼叫次数
7:15.820–7:18.880
zh同时减少了25%的token消耗
同时减少了25%的token消耗
7:18.880–7:21.340
zh这两个数字其实比跑分更有意义
这两个数字其实比跑分更有意义
7:21.340–7:24.020
zh工具呼叫减少代表模型更清楚
工具呼叫减少代表模型更清楚
7:24.020–7:25.740
zh什么时候该用什么工具
什么时候该用什么工具
7:25.740–7:28.580
zh不会无脑尝试所有选项来回绕路
不会无脑尝试所有选项来回绕路
7:28.580–7:30.000
zhToken消耗减少
Token消耗减少
7:30.000–7:31.680
zh代表推理效率提升
代表推理效率提升
7:31.680–7:33.840
zh单位任务的成本直接下降
单位任务的成本直接下降
7:33.840–7:35.880
zh很多人不知道代理人任务的成本
很多人不知道代理人任务的成本
7:35.880–7:38.300
zh通常是纯问答的3到5倍
通常是纯问答的3到5倍
7:38.300–7:40.120
zh因为要不断多轮推理
因为要不断多轮推理
7:40.120–7:41.800
zh呼叫工具修正路线
呼叫工具修正路线
7:41.800–7:43.080
zh所以效率的提升
所以效率的提升
7:43.080–7:44.520
zh直接决定了这项技术
直接决定了这项技术
7:44.520–7:46.220
zh能不能大规模商业化
能不能大规模商业化
7:46.220–7:47.380
zh不过也要说清楚
不过也要说清楚
7:47.380–7:50.900
zh这两个数字是Meta内部测试场景下的结果
这两个数字是Meta内部测试场景下的结果
7:50.900–7:52.880
zh不是第三方独立评测
不是第三方独立评测
7:52.880–7:55.260
zh实际业务中因为场景更复杂
实际业务中因为场景更复杂
7:55.260–7:57.340
zh不一定能复现同样的比例
不一定能复现同样的比例
7:57.340–8:00.000
zh官方也举了几个典型的常任务场景
官方也举了几个典型的常任务场景
8:00.000–8:02.415
zh官方也举了几个典型的常任务场景,
官方也举了几个典型的常任务场景,
8:02.415–8:05.584
zh比如工程领域的CAD模型搭配流体模拟数据。
比如工程领域的CAD模型搭配流体模拟数据。
8:05.584–8:07.848
zh最后按指定章节输出PDF报告,
最后按指定章节输出PDF报告,
8:07.848–8:10.565
zh音乐制作领域根据时间码定位错误音符,
音乐制作领域根据时间码定位错误音符,
8:10.565–8:12.980
zh从重复段落里挑出合适的替代片段。
从重复段落里挑出合适的替代片段。
8:12.980–8:14.920
zh保持所有音轨长度不变
保持所有音轨长度不变
8:14.920–8:16.040
zh再重新混音
再重新混音
8:16.040–8:18.640
zh这些场景的共同点就是步骤多
这些场景的共同点就是步骤多
8:18.640–8:19.840
zh中间产物多
中间产物多
8:19.840–8:21.400
zh需要跨工具协作
需要跨工具协作
8:21.400–8:23.860
zh差一步整个结果就不能用
差一步整个结果就不能用
8:23.860–8:24.940
zh从这个角度看
从这个角度看
8:24.940–8:28.540
zhSpark 1.3根本不是一个聊天更厉害的模型
Spark 1.3根本不是一个聊天更厉害的模型
8:28.540–8:30.720
zh而是一个干活更稳的模型
而是一个干活更稳的模型
8:30.720–8:33.580
zh它的评价标准早就不是会不会写诗
它的评价标准早就不是会不会写诗
8:33.580–8:34.940
zh能不能解数学题
能不能解数学题
8:34.940–8:36.960
zh而是能不能在100步之后
而是能不能在100步之后
8:36.960–8:38.780
zh还不偏离最初的目标
还不偏离最初的目标
8:38.780–8:40.580
zh聊完了官方自己讲的升级
聊完了官方自己讲的升级
8:40.580–8:43.220
zh我们来看看第三方独立评测的数据
我们来看看第三方独立评测的数据
8:43.220–8:46.300
zh验证一下这些能力到底有没有落到实处
验证一下这些能力到底有没有落到实处
8:46.300–8:48.880
zh这次的数据全部来自Artificial Analysis
这次的数据全部来自Artificial Analysis
8:48.880–8:52.800
zh这是目前业界专门做代理人模型评测的独立机构
这是目前业界专门做代理人模型评测的独立机构
8:52.800–8:54.400
zh不是Meta自己跑的分
不是Meta自己跑的分
8:54.400–8:56.120
zh参考价值相对高一些
参考价值相对高一些
8:56.120–8:58.760
zh在他们的综合智慧指数榜单上
在他们的综合智慧指数榜单上
8:58.760–9:02.140
zhSpark 1.3的Shy版本拿到61分
Spark 1.3的Shy版本拿到61分
9:02.140–9:06.220
zh还在有限预览阶段的Max版本拿到62分
还在有限预览阶段的Max版本拿到62分
9:06.220–9:08.400
zh比起1.2版本的57分
比起1.2版本的57分
9:08.400–9:10.360
zhExia整整涨了4分
Exia整整涨了4分
9:10.360–9:15.300
zh在AI评测里 4分的涨幅算不算大 要看在哪个区间
在AI评测里 4分的涨幅算不算大 要看在哪个区间
9:15.300–9:19.300
zh如果从30分涨到34分 那只是入门级的进步
如果从30分涨到34分 那只是入门级的进步
9:19.300–9:24.320
zh但从57分涨到61分已经是第一梯队模型的明显提升
但从57分涨到61分已经是第一梯队模型的明显提升
9:24.320–9:27.080
zh因为越往上 每一分的难度都越高
因为越往上 每一分的难度都越高
9:27.080–9:32.200
zh更有竞争力的其实是成本XJ版本完成一项综合指数任务
更有竞争力的其实是成本XJ版本完成一项综合指数任务
9:32.200–9:37.980
zh平均花费0.55美元 在所有得分超过59分的模型里是最低的
平均花费0.55美元 在所有得分超过59分的模型里是最低的
9:37.980–9:39.760
zh我们可以简单对比一下
我们可以简单对比一下
9:39.760–9:40.640
zh同级别里
同级别里
9:40.640–9:43.040
zhOpenAI的GPT-4O Advanced
OpenAI的GPT-4O Advanced
9:43.040–9:44.100
zh做类似任务
做类似任务
9:44.100–9:45.560
zh大概要1.2美元
大概要1.2美元
9:45.560–9:47.700
zhAnthropic的Cloud Opus
Anthropic的Cloud Opus
9:47.700–9:49.500
zh则要1.5美元左右
则要1.5美元左右
9:49.500–9:51.620
zhMeta差不多只要一半的价格
Meta差不多只要一半的价格
9:51.620–9:54.980
zh这对于需要大量呼叫API的企业用户来说
这对于需要大量呼叫API的企业用户来说
9:54.980–9:56.300
zh吸引力非常大
吸引力非常大
9:56.300–9:58.560
zh我们再拆开看具体任务的表现
我们再拆开看具体任务的表现
9:58.560–10:00.280
enTile3-Bench Banking
Tile3-Bench Banking
10:00.280–10:02.680
zh是专门的银行代理人基准测试
是专门的银行代理人基准测试
10:02.680–10:05.240
zh模拟金融场景下的多步骤任务
模拟金融场景下的多步骤任务
10:05.240–10:06.340
zh1.2版本
1.2版本
10:06.340–10:08.740
zh当时只拿到35%的通过率
当时只拿到35%的通过率
10:08.740–10:10.960
zhSHAE版本提升到47%
SHAE版本提升到47%
10:10.960–10:13.640
zhMAX版本更是达到52%
MAX版本更是达到52%
10:13.640–10:15.360
zh这个涨幅其实相当惊人
这个涨幅其实相当惊人
10:15.360–10:17.260
zh说明模型在处理合规
说明模型在处理合规
10:17.260–10:20.240
zh要求高步骤繁琐的金融任务时
要求高步骤繁琐的金融任务时
10:20.240–10:22.840
zh可靠性比上一代强了很多
可靠性比上一代强了很多
10:22.840–10:24.000
zh但也要客观说
但也要客观说
10:24.000–10:25.580
zh47%的通过率
47%的通过率
10:25.580–10:27.720
zh依然代表超过一半的任务
依然代表超过一半的任务
10:27.720–10:29.040
zh没办法完美完成
没办法完美完成
10:29.040–10:31.040
zh距离真正取代人类专员
距离真正取代人类专员
10:31.040–10:32.780
zh还有非常远的距离
还有非常远的距离
10:32.780–10:35.700
zh大概相当于入行半年的助理水平
大概相当于入行半年的助理水平
10:35.700–10:38.980
zhTerminal-Bench 2.1是终端指令执行测试
Terminal-Bench 2.1是终端指令执行测试
10:38.980–10:41.300
zh1.2版本通过率80%
1.2版本通过率80%
10:41.300–10:43.600
zhX-Shy提升到85%
X-Shy提升到85%
10:43.600–10:45.300
zhMax到86%
Max到86%
10:45.300–10:46.620
zh这个分数看起来很高
这个分数看起来很高
10:46.620–10:48.640
zh但终端任务相对结构化
但终端任务相对结构化
10:48.640–10:50.500
zh指令对错的标准很明确
指令对错的标准很明确
10:50.500–10:52.240
zh能拿到高分并不意外
能拿到高分并不意外
10:52.240–10:54.600
zh参考价值不如真实工作场景
参考价值不如真实工作场景
10:54.600–10:57.320
zh真正值得注意的反而是一项退步的指标
真正值得注意的反而是一项退步的指标
10:57.320–11:00.100
zhAA-LCR长上下文基准
AA-LCR长上下文基准
11:00.100–11:02.660
zh1.2版本有83%的正确率
1.2版本有83%的正确率
11:02.660–11:05.240
zh1.3版本降到了79%
1.3版本降到了79%
11:05.240–11:07.900
zh为什么长上下文能力反而退步了
为什么长上下文能力反而退步了
11:07.900–11:10.060
zh难道模型越更新越差吗
难道模型越更新越差吗
11:10.060–11:10.920
zh当然不是
当然不是
11:10.920–11:13.840
zh背后的原因是Spark 1.3调整了策略
背后的原因是Spark 1.3调整了策略
11:13.840–11:15.140
zh遇到不确定的资讯
遇到不确定的资讯
11:15.140–11:16.800
zh它更倾向于拒绝回答
它更倾向于拒绝回答
11:16.800–11:18.660
zh而不是硬猜一个答案
而不是硬猜一个答案
11:18.660–11:20.780
zh也就是说它宁可少说几句
也就是说它宁可少说几句
11:20.780–11:22.000
zh也不说错话
也不说错话
11:22.000–11:25.660
zh这种策略在AA-Omniscience准确率指标上
这种策略在AA-Omniscience准确率指标上
11:25.660–11:26.500
zh也能看出来
也能看出来
11:26.500–11:28.620
zh表面上准确率小幅回落
表面上准确率小幅回落
11:28.620–11:30.880
zh但幻觉率明显降低了
但幻觉率明显降低了
11:30.880–11:33.300
zh这其实是一个非常重要的取舍
这其实是一个非常重要的取舍
11:33.300–11:34.960
zh你要更高的召回率
你要更高的召回率
11:34.960–11:36.760
zh还是更高的准确率
还是更高的准确率
11:36.760–11:38.060
zh对于普通用户来说
对于普通用户来说
11:38.060–11:39.720
zh可能希望AI什么都能答
可能希望AI什么都能答
11:39.720–11:41.260
zh哪怕错一点也没关系
哪怕错一点也没关系
11:41.260–11:42.540
zh但对于企业用户
但对于企业用户
11:42.540–11:45.300
zh尤其是金融 医疗 法律这些领域
尤其是金融 医疗 法律这些领域
11:45.300–11:46.560
zh一个错误的答案
一个错误的答案
11:46.560–11:48.620
zh代价可能比没有答案大得多
代价可能比没有答案大得多
11:48.620–11:51.160
zh之前就有企业用初代代理人模型
之前就有企业用初代代理人模型
11:51.160–11:52.440
zh处理报销审核
处理报销审核
11:52.440–11:55.500
zh结果模型编造了很多不存在的单据
结果模型编造了很多不存在的单据
11:55.500–11:57.600
zh造成了不小的财务漏洞
造成了不小的财务漏洞
11:57.600–12:00.000
zh所以现在越是面向企业的模型
所以现在越是面向企业的模型
12:00.000–12:03.660
zh越把不编造放在比达对更高的优先级
越把不编造放在比达对更高的优先级
12:03.660–12:04.760
zh从这个角度看
从这个角度看
12:04.760–12:06.980
zh这项退步反而是一种进步
这项退步反而是一种进步
12:06.980–12:09.500
zh代表模型开始往实用化的方向走
代表模型开始往实用化的方向走
12:09.500–12:11.700
zh而不是为了跑分应凑答案
而不是为了跑分应凑答案
12:11.700–12:13.340
zh另外很多人忽略的一点是
另外很多人忽略的一点是
12:13.340–12:15.480
zhMAX版本的分数虽然更高
MAX版本的分数虽然更高
12:15.480–12:18.200
zh但代价是运算算力大幅增加
但代价是运算算力大幅增加
12:18.200–12:20.480
zh根据Artificial Analysis的测试
根据Artificial Analysis的测试
12:20.480–12:23.560
zh在GDPVAL-AAVFE任务里
在GDPVAL-AAVFE任务里
12:23.560–12:27.540
zhMAX版本比SY多消耗约62%的推理量
MAX版本比SY多消耗约62%的推理量
12:27.540–12:29.540
zh就算是银行代理任务
就算是银行代理任务
12:29.540–12:31.780
zh也多了28%的算力
也多了28%的算力
12:31.780–12:33.180
zh为什么会差这么多
为什么会差这么多
12:33.180–12:36.060
zh因为MAX版本会做更多的自我检查
因为MAX版本会做更多的自我检查
12:36.060–12:37.620
zh走更多的思维步骤
走更多的思维步骤
12:37.620–12:41.200
zh相当于人做事情的时候反复检查好几遍
相当于人做事情的时候反复检查好几遍
12:41.200–12:43.260
zh自然更费时间更费算力
自然更费时间更费算力
12:43.260–12:44.860
zh但正确率也更高
但正确率也更高
12:44.860–12:48.400
zh这其实带出了未来AI商业模式的一个可能方向
这其实带出了未来AI商业模式的一个可能方向
12:48.400–12:50.500
zh以后的模型不会只有单一档位
以后的模型不会只有单一档位
12:50.500–12:54.000
zh而是会根据任务的风险等级调整推理强度
而是会根据任务的风险等级调整推理强度
12:54.000–12:55.140
zh低风险的闲聊
低风险的闲聊
12:55.140–12:58.180
zh查资料用低档速度快又便宜
查资料用低档速度快又便宜
12:58.180–12:59.480
zh高风险的财务
高风险的财务
12:59.480–13:01.180
zh法律任务用高档
法律任务用高档
13:01.180–13:03.220
zh更慢 更贵 但更可靠
更慢 更贵 但更可靠
13:03.220–13:05.160
zh用户可以按自己的需求选
用户可以按自己的需求选
13:05.160–13:07.020
zh而不是为了偶尔的高需求
而不是为了偶尔的高需求
13:07.020–13:08.940
zh全程付最贵的价格
全程付最贵的价格
13:08.940–13:10.860
zh当然 目前这还只是观察
当然 目前这还只是观察
13:10.860–13:13.820
zhMeta并没有正式推出这种分级定价
Meta并没有正式推出这种分级定价
13:13.820–13:15.220
zh但从技术设计上
但从技术设计上
13:15.220–13:17.020
zh已经具备了这样的基础
已经具备了这样的基础
13:17.020–13:18.660
zh最后 还要再强调一次
最后 还要再强调一次
13:18.660–13:20.800
zhMax版本目前只是有限预览
Max版本目前只是有限预览
13:20.800–13:23.540
zh只有少数合作机构和企业能拿到权限
只有少数合作机构和企业能拿到权限
13:23.540–13:25.440
zh普通开发者根本呼叫不到
普通开发者根本呼叫不到
13:25.440–13:27.920
zh所以你看到62分那个数字的时候
所以你看到62分那个数字的时候
13:27.920–13:30.420
zh要知道它背后是更高的成本
要知道它背后是更高的成本
13:30.420–13:32.300
zh更严格的访问限制
更严格的访问限制
13:32.300–13:35.400
zh不能拿它去跟别人全面开放的API比
不能拿它去跟别人全面开放的API比
13:35.400–13:37.160
zh然后说Meta已经赢了
然后说Meta已经赢了
13:37.160–13:38.580
zh这种对比并不公平
这种对比并不公平
13:38.580–13:40.920
zh看完了负责思考和执行的大脑
看完了负责思考和执行的大脑
13:40.920–13:44.220
zh我们再转过头来讲这次连发的另一款产品
我们再转过头来讲这次连发的另一款产品
13:44.220–13:46.000
zh负责感知输入的耳朵
负责感知输入的耳朵
13:46.000–13:47.480
enMuse Voice Transcribe
Muse Voice Transcribe
13:47.480–13:48.980
zh很多人第一眼看到它
很多人第一眼看到它
13:48.980–13:51.280
zh会觉得不就是个语音转文字吗
会觉得不就是个语音转文字吗
13:51.280–13:52.360
zh有什么特别的
有什么特别的
13:52.360–13:53.980
zh但实际上它的设计思路
但实际上它的设计思路
13:53.980–13:56.720
zh跟传统的自动语音识别完全不一样
跟传统的自动语音识别完全不一样
13:56.720–13:58.640
zh传统的ASR比如Whisper
传统的ASR比如Whisper
13:58.640–14:00.440
zh走的是离线转写路线
走的是离线转写路线
14:00.440–14:02.840
zh拿到整段音频之后再慢慢处理
拿到整段音频之后再慢慢处理
14:02.840–14:04.840
zh可以利用上下文反复修正
可以利用上下文反复修正
14:04.840–14:05.880
zh准确率很高
准确率很高
14:05.880–14:06.960
zh但延迟也大
但延迟也大
14:06.960–14:09.560
zh根本没办法用来做实时对话
根本没办法用来做实时对话
14:09.560–14:11.380
zh而以前的实时语音助手
而以前的实时语音助手
14:11.380–14:13.940
zh比如手机上的Siri Google助理
比如手机上的Siri Google助理
14:13.940–14:15.320
zh为了追求低延迟
为了追求低延迟
14:15.320–14:17.540
zh只能听一小段就马上输出
只能听一小段就马上输出
14:17.540–14:19.160
zh结果准确率很差
结果准确率很差
14:19.160–14:20.140
zh稍微吵一点
稍微吵一点
14:20.140–14:22.960
zh有两个人叠话或者混个外文单字
有两个人叠话或者混个外文单字
14:22.960–14:24.020
zh结果就歪掉
结果就歪掉
14:24.020–14:25.960
zhMuse Voice Transcribe想解决的
Muse Voice Transcribe想解决的
14:25.960–14:27.600
zh就是又要准又要快
就是又要准又要快
14:27.600–14:29.840
zh还要懂真实对话这个老难题
还要懂真实对话这个老难题
14:29.840–14:32.960
zh它的做法是把音频切成80毫秒的小块
它的做法是把音频切成80毫秒的小块
14:32.960–14:34.940
zh每秒处理12月5日次
每秒处理12月5日次
14:34.940–14:37.980
zh每一小块音频先转换成一个软Token
每一小块音频先转换成一个软Token
14:37.980–14:41.080
zh模型在判断是要继续等后面的声音
模型在判断是要继续等后面的声音
14:41.080–14:42.760
zh还是立刻输出文字
还是立刻输出文字
14:42.760–14:44.500
zh等到音频完全停止
等到音频完全停止
14:44.500–14:46.620
zh系统会加入一个特殊标记
系统会加入一个特殊标记
14:46.620–14:50.440
zh让模型把剩下没输出的文字一口气吐出来
让模型把剩下没输出的文字一口气吐出来
14:50.440–14:53.500
zh其中最关键的技术叫做自适应延迟
其中最关键的技术叫做自适应延迟
14:53.500–14:57.080
zh模型不会给每个字都设定一样的等待时间
模型不会给每个字都设定一样的等待时间
14:57.080–14:59.480
zh简单确定的内容就立刻输出
简单确定的内容就立刻输出
14:59.480–15:02.220
zh碰到需要后文才能判断的同音词
碰到需要后文才能判断的同音词
15:02.220–15:03.140
zh专有名词
专有名词
15:03.140–15:05.940
zh就稍微多等一点点音频再决定
就稍微多等一点点音频再决定
15:05.940–15:08.160
zh这其实很像人类的同步口译
这其实很像人类的同步口译
15:08.160–15:10.060
zh译员会根据句子的难度
译员会根据句子的难度
15:10.060–15:11.680
zh调整自己的滞后时间
调整自己的滞后时间
15:11.680–15:13.040
zh不会一味求快
不会一味求快
15:13.040–15:14.400
zh也不会一味求准
也不会一味求准
15:14.400–15:15.180
zh训练的时候
训练的时候
15:15.180–15:17.540
zhMeta把词 错误率和延迟时间
Meta把词 错误率和延迟时间
15:17.540–15:20.180
zh一起放进强化学习的奖励函数里
一起放进强化学习的奖励函数里
15:20.180–15:21.900
zh如果模型只追求准确
如果模型只追求准确
15:21.900–15:23.280
zh每句话都等很久
每句话都等很久
15:23.280–15:24.240
zh得分不会高
得分不会高
15:24.240–15:25.400
zh只追求速度
只追求速度
15:25.400–15:27.900
zh输出一大堆错字同样过不了关
输出一大堆错字同样过不了关
15:27.900–15:32.460
zh最终目标就是在准确率和反应速度之间找到最佳平衡点
最终目标就是在准确率和反应速度之间找到最佳平衡点
15:32.460–15:33.680
zh那实际表现如何
那实际表现如何
15:33.680–15:37.060
zh在Artificial Analysis的流逝语音榜单上
在Artificial Analysis的流逝语音榜单上
15:37.060–15:42.060
zhMuse Voice Transcribe的最终词错误率约3.1%
Muse Voice Transcribe的最终词错误率约3.1%
15:42.060–15:43.460
zh直接登上第一名
直接登上第一名
15:44.354–15:46.348
zh这个数字是什么概念?
这个数字是什么概念?
15:46.348–15:48.342
zh在流逝实时的场景下,
在流逝实时的场景下,
15:48.342–15:52.530
zh3.1%已经非常接近人类专业数据员的水平,
3.1%已经非常接近人类专业数据员的水平,
15:52.530–15:55.123
zh人类大概是2%到3%左右,
人类大概是2%到3%左右,
15:55.123–15:58.114
zh相当于每讲100个字只错3个。
相当于每讲100个字只错3个。
15:58.114–16:00.094
zh不过这里必须先打个预防针
不过这里必须先打个预防针
16:00.094–16:02.894
zh这个成绩是英语流逝对话的测试结果
这个成绩是英语流逝对话的测试结果
16:02.894–16:06.374
zh绝对不能直接套用到所有语言 所有场景
绝对不能直接套用到所有语言 所有场景
16:06.374–16:08.834
zh中文因为同音字多 声调复杂
中文因为同音字多 声调复杂
16:08.834–16:13.214
zh同样的模型词错误率通常会比英语高2到3个百分点
同样的模型词错误率通常会比英语高2到3个百分点
16:13.214–16:17.294
zh如果是嘈杂环境 多人强化 或者带方言口音
如果是嘈杂环境 多人强化 或者带方言口音
16:17.294–16:19.014
zh表现还会再打折扣
表现还会再打折扣
16:19.014–16:22.834
zh官方也明确说 模型训练覆盖了70多种语言
官方也明确说 模型训练覆盖了70多种语言
16:22.834–16:25.734
zh其中只有25种经过充分验证
其中只有25种经过充分验证
16:25.734–16:27.834
zh其他语言可能只是有训练过
其他语言可能只是有训练过
16:27.834–16:30.234
zh但没有经过严格的效果评测
但没有经过严格的效果评测
16:30.234–16:32.134
zh除了基础的转写准确率
除了基础的转写准确率
16:32.134–16:34.194
zh还有几个功能特别值得一提
还有几个功能特别值得一提
16:34.194–16:36.714
zh首先是原生的说话人分离
首先是原生的说话人分离
16:36.714–16:39.334
zh而且支持20人以上同时发言
而且支持20人以上同时发言
16:39.334–16:42.094
zh传统的会议转写通常是先做语音识别
传统的会议转写通常是先做语音识别
16:42.094–16:44.014
zh再另外用一套声文系统
再另外用一套声文系统
16:44.014–16:45.714
zh判断每段话是谁说的
判断每段话是谁说的
16:45.714–16:47.194
zh两个系统的时间轴
两个系统的时间轴
16:47.194–16:49.354
zh只要差一点点就会出现文字
只要差一点点就会出现文字
16:49.354–16:50.474
zh人认错的情况
人认错的情况
16:50.474–16:52.814
zhMeta是在同一个生成过程里
Meta是在同一个生成过程里
16:52.814–16:55.674
zh加入说话人切换标记和身份标签
加入说话人切换标记和身份标签
16:55.674–16:58.434
zh检测到换人就先标一轮新发言
检测到换人就先标一轮新发言
16:58.434–17:00.894
zh等听到足够声音再确定身份
等听到足够声音再确定身份
17:00.894–17:03.014
zh时间轴的准确度会高很多
时间轴的准确度会高很多
17:03.014–17:06.214
zh官方展示的长对话里包含多人插话
官方展示的长对话里包含多人插话
17:06.214–17:08.314
zh重叠发言 自然停顿
重叠发言 自然停顿
17:08.314–17:10.194
zh都能正确标记身份
都能正确标记身份
17:10.194–17:13.734
zh这对于会议记录 访谈整理 客服记录来说
这对于会议记录 访谈整理 客服记录来说
17:13.734–17:14.674
zh价值很高
价值很高
17:14.674–17:18.214
zh因为后续的摘要系统拿到的不只是一整段文字
因为后续的摘要系统拿到的不只是一整段文字
17:18.214–17:20.894
zh还知道谁提了问题 谁做了承诺
还知道谁提了问题 谁做了承诺
17:20.894–17:22.234
zh谁反对哪个方案
谁反对哪个方案
17:22.234–17:23.974
zh其次是端点侦测能力
其次是端点侦测能力
17:23.974–17:27.474
zh人类对话本来就不会每次讲完都按个结束钮
人类对话本来就不会每次讲完都按个结束钮
17:27.474–17:30.794
zh系统要从语气停顿和上下文判断
系统要从语气停顿和上下文判断
17:30.794–17:33.474
zh对方只是喘口气还是真的说完了
对方只是喘口气还是真的说完了
17:33.474–17:35.014
zh如果端点判断不准
如果端点判断不准
17:35.014–17:36.694
zh要么用户都讲完半天了
要么用户都讲完半天了
17:36.694–17:37.774
zh助手还没反应
助手还没反应
17:37.774–17:39.234
zh要么用户还没说完
要么用户还没说完
17:39.234–17:41.494
zh助手就急着插嘴体验都很差
助手就急着插嘴体验都很差
17:41.494–17:42.814
enMuse Voice Transcribe
Muse Voice Transcribe
17:42.814–17:44.654
zh专门针对这点做了优化
专门针对这点做了优化
17:44.654–17:47.514
zh能更准确判断语音的开始和结束
能更准确判断语音的开始和结束
17:47.514–17:50.014
zh这也是代理人能自然对话的前提
这也是代理人能自然对话的前提
17:50.014–17:51.894
zh第三个很实用的功能是
第三个很实用的功能是
17:51.894–17:54.594
zh句内和句间的多语言自由切换
句内和句间的多语言自由切换
17:54.594–17:56.134
zh还有上下文偏制
还有上下文偏制
17:56.134–17:58.374
zh现实中很多双语使用者
现实中很多双语使用者
17:58.374–18:00.574
zh不会先切语言模式再讲话
不会先切语言模式再讲话
18:00.574–18:02.994
zh中文句子里夹个英文专有名词
中文句子里夹个英文专有名词
18:02.994–18:05.274
zh项目代号是家常便饭
项目代号是家常便饭
18:05.274–18:06.954
zh旧的系统很容易把英文词
旧的系统很容易把英文词
18:06.954–18:08.994
zh应转成发音相近的中文字
应转成发音相近的中文字
18:08.994–18:11.494
zh或者切换语言之后直接丢了半句话
或者切换语言之后直接丢了半句话
18:11.494–18:12.994
enMuse Voice Transcribe
Muse Voice Transcribe
18:12.994–18:15.294
zh支持70多种语言的自由切换
支持70多种语言的自由切换
18:15.294–18:18.254
zh还可以让用户提前输入常用的人名
还可以让用户提前输入常用的人名
18:18.254–18:19.734
zh公司名专业术语
公司名专业术语
18:19.734–18:21.714
zh模型碰到相近发音的时候
模型碰到相近发音的时候
18:21.714–18:24.994
zh会优先选择这些符合上下文的词
会优先选择这些符合上下文的词
18:24.994–18:27.654
zh比如医生可以提前录入药品名称
比如医生可以提前录入药品名称
18:27.654–18:30.914
zh城市设计师可以加入函数名和项目代号
城市设计师可以加入函数名和项目代号
18:30.914–18:33.594
zh企业用户可以上传内部数语表
企业用户可以上传内部数语表
18:33.594–18:36.014
zh这样转写的准确率会大幅提升
这样转写的准确率会大幅提升
18:36.014–18:38.154
zh甚至可以直接进入工作流程
甚至可以直接进入工作流程
18:38.154–18:39.714
zh不用再人工校对一遍
不用再人工校对一遍
18:39.714–18:42.054
zh这才是语音转写真正的价值
这才是语音转写真正的价值
18:42.054–18:44.254
zh不是把声音变成文字就好
不是把声音变成文字就好
18:44.254–18:46.234
zh而是变成能直接用的文字
而是变成能直接用的文字
18:46.234–18:47.874
zh目前Muse Voice Transcribe
目前Muse Voice Transcribe
18:47.874–18:49.614
zh已经接入Meta Model API
已经接入Meta Model API
18:49.614–18:52.774
zh还有Meta AI4 Mac Muse Code Mac版本
还有Meta AI4 Mac Muse Code Mac版本
18:52.774–18:55.494
zh用户可以按住FN键直接语音输入
用户可以按住FN键直接语音输入
18:55.494–18:58.314
zh把转写结果送到不同的应用程式里
把转写结果送到不同的应用程式里
18:58.314–19:00.834
zh不过有个隐私细节一定要讲清楚
不过有个隐私细节一定要讲清楚
19:00.834–19:04.734
zh官方网页演示的时候说麦克风音频只会用来生成转写
官方网页演示的时候说麦克风音频只会用来生成转写
19:04.734–19:05.614
zh不会被保存
不会被保存
19:05.614–19:08.394
zh但这个承诺只限于网页演示场景
但这个承诺只限于网页演示场景
19:08.394–19:10.254
zh不等于所有API呼叫
不等于所有API呼叫
19:10.254–19:13.014
zh所有产品部署都不会保存音频
所有产品部署都不会保存音频
19:13.014–19:15.354
zh如果你是透过API上传录音
如果你是透过API上传录音
19:15.354–19:16.694
zhMeta会不会保存
Meta会不会保存
19:16.694–19:17.554
zh保存多久
保存多久
19:17.554–19:19.254
zh会不会用来训练模型
会不会用来训练模型
19:19.254–19:22.774
zh都要看你签署的服务条款和数据处理协议
都要看你签署的服务条款和数据处理协议
19:22.774–19:24.714
zh不能因为网页演示不保存
不能因为网页演示不保存
19:24.714–19:28.074
zh就理所当然认为所有场景都不保存
就理所当然认为所有场景都不保存
19:28.074–19:30.994
zh这在个资合规上是非常危险的认知
这在个资合规上是非常危险的认知
19:30.994–19:33.534
zh讲到这里就必须好好聊一下
讲到这里就必须好好聊一下
19:33.534–19:35.034
zh隐私与安全的边界
隐私与安全的边界
19:35.034–19:37.354
zh这也是很多人看AI产品的时候
这也是很多人看AI产品的时候
19:37.354–19:40.374
zh最容易忽略但绝对最重要的部分
最容易忽略但绝对最重要的部分
19:40.374–19:42.854
zh先讲Muse Spark 1.3的安全设计
先讲Muse Spark 1.3的安全设计
19:42.854–19:45.254
zh官方说这次提升了对提示注入
官方说这次提升了对提示注入
19:45.254–19:47.294
zh和对抗输入的抵抗能力
和对抗输入的抵抗能力
19:47.294–19:49.994
zh也更能识别哪些操作是不可逆的
也更能识别哪些操作是不可逆的
19:49.994–19:51.054
zh提示注入是什么
提示注入是什么
19:51.054–19:53.254
zh就是攻击者在输入内容里
就是攻击者在输入内容里
19:53.254–19:55.274
zh嵌入看不见的恶意指令
嵌入看不见的恶意指令
19:55.274–19:57.314
zh比如藏在PDF档案里
比如藏在PDF档案里
19:57.314–19:58.114
zh网页里
网页里
19:58.114–20:00.834
zh诱导AI代理人忽略原本的规则
诱导AI代理人忽略原本的规则
20:00.834–20:02.554
zh去转发机密档案
去转发机密档案
20:02.554–20:03.974
zh修改设定甚至转账
修改设定甚至转账
20:03.974–20:06.434
zh2025年就曾经出现过
2025年就曾经出现过
20:06.434–20:07.714
zh类似的攻击案例
类似的攻击案例
20:07.714–20:10.754
zh让不少企业对AI代理人望而却步
让不少企业对AI代理人望而却步
20:10.754–20:13.774
zhSpark 1.3针对这类攻击做了专门训练
Spark 1.3针对这类攻击做了专门训练
20:13.774–20:15.594
zh但这不代表它完全免疫
但这不代表它完全免疫
20:15.594–20:19.874
zh目前没有任何模型能100%防御所有提示注入攻击
目前没有任何模型能100%防御所有提示注入攻击
20:19.874–20:21.594
zh识别不可逆操作也是一样
识别不可逆操作也是一样
20:21.594–20:23.394
zh模型能标出删除档案
模型能标出删除档案
20:23.394–20:24.574
zh发送批量邮件
发送批量邮件
20:24.574–20:26.934
zh修改数据库这些高风险动作
修改数据库这些高风险动作
20:26.934–20:28.334
zh要求用户确认
要求用户确认
20:28.334–20:31.114
zh但光有模型层面的防护远远不够
但光有模型层面的防护远远不够
20:31.114–20:33.814
zh官方自己也强调实际部署的时候
官方自己也强调实际部署的时候
20:33.814–20:36.374
zh必须同时做好全线隔离
必须同时做好全线隔离
20:36.374–20:38.454
zh白名单和操作日志
白名单和操作日志
20:38.454–20:41.514
zh全线隔离就是给代理人最小必要的全线
全线隔离就是给代理人最小必要的全线
20:41.514–20:43.754
zh比如负责整理表格的助理
比如负责整理表格的助理
20:43.754–20:46.534
zh就不该有删除整个资料夹的权限
就不该有删除整个资料夹的权限
20:46.534–20:50.654
zh白名单就是只允许模型呼叫预先核准的
白名单就是只允许模型呼叫预先核准的
20:50.654–20:54.834
zh工具和API不能让它随便访问系统里的任何东西
工具和API不能让它随便访问系统里的任何东西
20:54.834–20:58.954
zh操作日志就是把代理人所有执行动作都记录下来
操作日志就是把代理人所有执行动作都记录下来
20:58.954–21:01.134
zh方便事后审计和回溯
方便事后审计和回溯
21:01.134–21:04.334
zh这三层防护都是资安领域的基本常识
这三层防护都是资安领域的基本常识
21:04.334–21:07.754
zh却也是很多AI产品最容易省略的部分
却也是很多AI产品最容易省略的部分
21:07.754–21:09.614
zhMeta愿意主动强调这点
Meta愿意主动强调这点
21:09.614–21:13.234
zh说明它是真的在考虑企业落地的实际需求
说明它是真的在考虑企业落地的实际需求
21:13.234–21:15.894
zh而不是只做展示用的技术demo
而不是只做展示用的技术demo
21:15.894–21:16.974
zh再回到语音部分
再回到语音部分
21:16.974–21:19.874
zh当语音转写加上代理人执行
当语音转写加上代理人执行
21:19.874–21:23.534
zh再搭配Meta旗下的ray减班智慧眼镜
再搭配Meta旗下的ray减班智慧眼镜
21:23.534–21:25.214
zh想象空间确实很大
想象空间确实很大
21:25.214–21:28.694
zh手机上的语音助手要等你点开APP才能用
手机上的语音助手要等你点开APP才能用
21:28.694–21:30.854
zh但眼镜可以一直戴在脸上
但眼镜可以一直戴在脸上
21:30.854–21:32.794
zh随时处在声音环境里
随时处在声音环境里
21:32.794–21:34.574
zh如果他能听懂谁在讲话
如果他能听懂谁在讲话
21:34.574–21:35.814
zh什么时候该接话
什么时候该接话
21:35.814–21:37.134
zh什么时候不该插嘴
什么时候不该插嘴
21:37.134–21:39.954
zh就能在会议后自动整理每个人的行动项
就能在会议后自动整理每个人的行动项
21:39.954–21:42.014
zh访谈的时候自动标记重点
访谈的时候自动标记重点
21:42.014–21:46.134
zh甚至日常聊天里提到的代办事项都能自动记下来
甚至日常聊天里提到的代办事项都能自动记下来
21:46.134–21:48.634
zh但这也带来了更尖锐的隐私问题
但这也带来了更尖锐的隐私问题
21:48.634–21:50.974
zh眼镜上的麦克风什么时候在听
眼镜上的麦克风什么时候在听
21:50.974–21:52.874
zh听到的内容传到哪里去了
听到的内容传到哪里去了
21:52.874–21:54.914
zh用户有没有明确的控制权
用户有没有明确的控制权
21:54.914–21:57.234
zh旁边的人知不知道自己正在被录音
旁边的人知不知道自己正在被录音
21:57.234–22:00.234
zh这些问题目前都还没有完全公开的答案
这些问题目前都还没有完全公开的答案
22:00.234–22:04.274
zh不过我们可以从Meta的双轨策略里推出一个很合理的假设
不过我们可以从Meta的双轨策略里推出一个很合理的假设
22:04.274–22:06.954
zh未来轻量级的语音转写
未来轻量级的语音转写
22:06.954–22:08.534
zh简单的指令理解
简单的指令理解
22:08.534–22:12.294
zh很可能会直接跑在眼镜本地的端侧芯片上
很可能会直接跑在眼镜本地的端侧芯片上
22:12.294–22:13.534
zh不需要传到云端
不需要传到云端
22:13.534–22:15.294
zh敏感数据不会离开设备
敏感数据不会离开设备
22:15.294–22:17.034
zh大幅降低隐私风险
大幅降低隐私风险
22:17.034–22:18.774
zh而复杂的常任务代理
而复杂的常任务代理
22:18.774–22:19.934
zh多工具协作
多工具协作
22:19.934–22:22.694
zh再交给云端的Spark模型处理
再交给云端的Spark模型处理
22:22.694–22:25.634
zh刚好Meta有Glimmer这条本地开源路线
刚好Meta有Glimmer这条本地开源路线
22:25.634–22:27.694
zh专门做轻量化端侧部署
专门做轻量化端侧部署
22:27.694–22:30.634
zh刚好可以跟眼镜这类终端装置搭配
刚好可以跟眼镜这类终端装置搭配
22:30.634–22:32.334
zh云端负责复杂思考
云端负责复杂思考
22:32.334–22:34.034
zh本地负责实时感知
本地负责实时感知
22:34.034–22:36.274
zh既保证体验又兼顾隐私
既保证体验又兼顾隐私
22:36.274–22:40.194
zh这很可能就是Meta下一代AI入口的完整架构
这很可能就是Meta下一代AI入口的完整架构
22:40.194–22:42.834
zh当然这只是基于现有产品线的推测
当然这只是基于现有产品线的推测
22:42.834–22:44.754
zh官方还没有证实这个方向
官方还没有证实这个方向
22:44.754–22:46.794
zh讲完了技术亮点和想象空间
讲完了技术亮点和想象空间
22:46.794–22:48.234
zh我们也得冷静下来
我们也得冷静下来
22:48.234–22:51.154
zh聊聊这次发布的口径边界和实际风险
聊聊这次发布的口径边界和实际风险
22:51.154–22:54.114
zh首先Max版本目前只是有线预览
首先Max版本目前只是有线预览
22:54.114–22:56.514
zh普通开发者能用的只有Shi版本
普通开发者能用的只有Shi版本
22:56.514–22:58.834
zh网上所有关于Max的评测数据
网上所有关于Max的评测数据
22:58.834–23:01.034
zh都来自少数拿到权限的机构
都来自少数拿到权限的机构
23:01.034–23:03.074
zh一般用户现在根本用不到
一般用户现在根本用不到
23:03.074–23:07.054
zh所以62分那个数字只能当成技术上限的参考
所以62分那个数字只能当成技术上限的参考
23:07.054–23:10.094
zh不能作为采购或者使用决策的依据
不能作为采购或者使用决策的依据
23:10.094–23:12.414
zh其次所有的基准测试数据
其次所有的基准测试数据
23:12.414–23:15.414
zh都是在标准化的干净环境里跑出来的
都是在标准化的干净环境里跑出来的
23:15.414–23:19.494
zh真实世界的场景只会更复杂更混乱
真实世界的场景只会更复杂更混乱
23:19.494–23:22.494
zh比如银行代理测试里的数据都是结构化的
比如银行代理测试里的数据都是结构化的
23:22.494–23:24.154
zh格式统一全线清晰
格式统一全线清晰
23:25.087–23:26.443
zh但真实的企业里,
但真实的企业里,
23:26.443–23:29.154
zh数据可能分散在十几个老旧系统里,
数据可能分散在十几个老旧系统里,
23:29.154–23:30.341
zh格式乱七八糟、
格式乱七八糟、
23:30.341–23:31.527
zh权限层层卡关。
权限层层卡关。
23:31.527–23:37.207
zh你在测试里拿到47%的通过率,到了真实环境可能连30%都不到。
你在测试里拿到47%的通过率,到了真实环境可能连30%都不到。
23:37.207–23:43.787
zh这不是Meta的问题 是所有AI模型评测的普遍现象 跑分永远不等于真实生产力
这不是Meta的问题 是所有AI模型评测的普遍现象 跑分永远不等于真实生产力
23:43.787–23:46.327
zh第三 关于开源的期待也要放低
第三 关于开源的期待也要放低
23:46.327–23:51.754
zhSpark 1.3目前是完全避原的 官方只说未来有开放权重的规划
Spark 1.3目前是完全避原的 官方只说未来有开放权重的规划
23:51.754–23:54.287
zh但没有时间表 也没有说授权条款
但没有时间表 也没有说授权条款
23:54.287–24:01.247
zh参考Meta之前Lama系列的节奏 通常是新一代出来之后才会把上一代的权重逐步开放
参考Meta之前Lama系列的节奏 通常是新一代出来之后才会把上一代的权重逐步开放
24:01.247–24:06.807
zh而且早期都是非商业授权 要等到更后面才会用更宽松的授权
而且早期都是非商业授权 要等到更后面才会用更宽松的授权
24:06.807–24:10.007
zh所以不要期待短期内就能在自己的电脑上
所以不要期待短期内就能在自己的电脑上
24:10.007–24:12.987
zh跑Spark 1.3核心的代理人能力
跑Spark 1.3核心的代理人能力
24:12.987–24:16.127
zhMeta肯定会先握在手里当商业护城河
Meta肯定会先握在手里当商业护城河
24:16.127–24:18.087
zh最后回到产业竞争的层面
最后回到产业竞争的层面
24:18.087–24:20.447
zhMeta这次的更新确实扎实
Meta这次的更新确实扎实
24:20.447–24:25.027
zh在代理人可靠性和流逝语音转写上都往前走了一步
在代理人可靠性和流逝语音转写上都往前走了一步
24:25.027–24:27.327
zh成本控制也做得很有竞争力
成本控制也做得很有竞争力
24:27.327–24:29.227
zh但要说已经赢了还太早
但要说已经赢了还太早
24:29.227–24:33.127
zhOpenEye的GPT系列代理人能力同样在快速迭代
OpenEye的GPT系列代理人能力同样在快速迭代
24:33.127–24:37.847
zh谷歌的Gemini在多模态和端侧整合上有自己的优势
谷歌的Gemini在多模态和端侧整合上有自己的优势
24:37.847–24:42.527
zhAnthropic在长上下文和安全合规上依然领先
Anthropic在长上下文和安全合规上依然领先
24:42.527–24:46.927
zh还有Eleven Labs这类专业语音公司也在往代理人方向走
还有Eleven Labs这类专业语音公司也在往代理人方向走
24:46.927–24:52.547
zhMeta现在的领先更像是某几个细分场景的小幅度领先
Meta现在的领先更像是某几个细分场景的小幅度领先
24:52.547–24:55.207
zh还远没有到拉开差距的程度
还远没有到拉开差距的程度
24:55.207–24:58.527
zh而且真正的竞争从来都不是比模型本身
而且真正的竞争从来都不是比模型本身
24:58.527–25:02.807
zh而是比谁能先把技术变成用户愿意天天用的产品
而是比谁能先把技术变成用户愿意天天用的产品
25:02.807–25:04.927
zh谁能解决好隐私安全
谁能解决好隐私安全
25:04.927–25:06.967
zh权限这些麻烦的落地问题
权限这些麻烦的落地问题
25:06.967–25:08.247
zh模型再聪明
模型再聪明
25:08.247–25:10.887
zh如果用户不敢把重要的工作交给他
如果用户不敢把重要的工作交给他
25:10.887–25:12.587
zh那也只是个高级玩具
那也只是个高级玩具
25:12.587–25:13.167
zh讲到这里
讲到这里
25:13.167–25:16.007
zh我们把这次Meta两款产品的技术细节
我们把这次Meta两款产品的技术细节
25:16.007–25:16.947
zh评测数据
评测数据
25:16.947–25:18.107
zh产品线定位
产品线定位
25:18.107–25:19.027
zh隐私风险
隐私风险
25:19.027–25:21.187
zh还有产业格局全部拆完了
还有产业格局全部拆完了
25:21.187–25:23.667
zh你会发现每一个亮眼的数据背后
你会发现每一个亮眼的数据背后
25:23.667–25:25.307
zh都有一个限定条件
都有一个限定条件
25:25.307–25:27.067
zh每一项技术突破的旁边
每一项技术突破的旁边
25:27.067–25:29.227
zh都站着一个带解决的问题
都站着一个带解决的问题
25:29.227–25:30.947
zh这不是说Meta做得不好
这不是说Meta做得不好
25:30.947–25:32.047
zh恰恰相反
恰恰相反
25:32.047–25:34.567
zh只有当你看清了所有的边界和限制
只有当你看清了所有的边界和限制
25:34.567–25:36.587
zh才能真正评估它的价值
才能真正评估它的价值
25:36.587–25:41.227
zhMuse Spark 1.3确实把常任务代理人的可靠性往前推了一步
Muse Spark 1.3确实把常任务代理人的可靠性往前推了一步
25:41.227–25:43.027
zh成本优势也很明显
成本优势也很明显
25:43.027–25:46.167
zhMuse Voice Transcribe在英语流逝转写上
Muse Voice Transcribe在英语流逝转写上
25:46.167–25:48.187
zh做到了业界顶尖
做到了业界顶尖
25:48.187–25:50.827
zh准确率和延迟的平衡做得可圈可点
准确率和延迟的平衡做得可圈可点
25:50.827–25:53.427
zh但它们都还只是阶段性的进展
但它们都还只是阶段性的进展
25:53.427–25:56.067
zh离大家想象中什么都能做的AI助理
离大家想象中什么都能做的AI助理
25:56.067–25:57.647
zh还有非常远的距离
还有非常远的距离
25:57.647–25:59.707
zh2026年的AI产业
2026年的AI产业
25:59.707–26:02.607
zh其实正在经历一个很重要的转向
其实正在经历一个很重要的转向
26:02.607–26:05.447
zh前几年大家都在比谁的模型更大
前几年大家都在比谁的模型更大
26:05.447–26:06.747
zh谁的跑分更高
谁的跑分更高
26:06.747–26:08.627
zh谁的牛皮吹得更响
谁的牛皮吹得更响
26:08.627–26:12.087
zh但从今年开始竞争慢慢落到了实处
但从今年开始竞争慢慢落到了实处
26:12.087–26:14.167
zh比的是谁能把长任务做稳
比的是谁能把长任务做稳
26:14.167–26:15.927
zh谁能把真实声音听懂
谁能把真实声音听懂
26:15.927–26:17.727
zh谁能让企业敢放心用
谁能让企业敢放心用
26:17.727–26:20.227
zh谁能把隐私控制在合理范围
谁能把隐私控制在合理范围
26:20.227–26:22.847
zh那些看起来不怎么耀眼的细节优化
那些看起来不怎么耀眼的细节优化
26:22.847–26:27.407
zh反而决定了产品能不能真正走进日常生活和工作流
反而决定了产品能不能真正走进日常生活和工作流
26:27.407–26:28.267
zh就像造车
就像造车
26:28.267–26:36.447
zh早期大家都比马力 比急速 等到市场成熟了 比的是隔音 是油耗 是故障率 是乘坐舒适度
早期大家都比马力 比急速 等到市场成熟了 比的是隔音 是油耗 是故障率 是乘坐舒适度
26:36.447–26:39.987
zh这些才是决定你愿不愿意每天开的关
这些才是决定你愿不愿意每天开的关
26:39.987–26:45.347
zh见如果你喜欢这种不吹不黑 把数据和限制都讲清楚的深度科技解析
见如果你喜欢这种不吹不黑 把数据和限制都讲清楚的深度科技解析
26:45.347–26:48.947
zh欢迎订阅这个频道 并且打开通知小铃铛
欢迎订阅这个频道 并且打开通知小铃铛
26:48.947–26:54.787
zh我们会持续追踪AI代理人 语音交互 端策AI这些领域的最新进展
我们会持续追踪AI代理人 语音交互 端策AI这些领域的最新进展
26:54.787–26:57.307
zh帮你过滤掉夸大的营销话术
帮你过滤掉夸大的营销话术
26:57.307–26:59.727
zh留下真正值得关注的技术变化
留下真正值得关注的技术变化
26:59.727–27:01.327
zh也欢迎在留言区告诉我
也欢迎在留言区告诉我
27:01.327–27:04.287
zh你最期待AI帮你完成什么样的任务
你最期待AI帮你完成什么样的任务
27:04.287–27:05.927
zh是整理会议记录
是整理会议记录
27:05.927–27:07.887
zh还是处理繁琐的文书工作
还是处理繁琐的文书工作
27:07.887–27:09.647
zh我们下期影片再见
我们下期影片再见

影片筆記：Meta 真的超車了？實測 Muse Spark 1.3 與 Voice Transcribe：真能幹活還是行銷話術？

<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->

⚠️ 可先使用，仍有待修正項目

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

  • 待修正：逐字稿全文快速校讀未完成（已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。）
  • 待修正：逐字稿可先使用，但有待校正清單（segment=596 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

一句話總結

影片分析 Meta 於 2026 年 9 月發布的 Muse Spark 1.3（雲端閉源代理人模型）與 Muse Voice Transcribe（語音轉寫模型），指出前者強化長任務可靠性與成本效率，後者透過自適應延遲提升即時準確率，但兩者皆面臨隱私、真實場景適應性與商業化落地的挑戰，當前 AI 競爭核心已從跑分轉向落地場景與信任度。

核心重點

  • 產品線區分：釐清 Muse Spark 1.3（雲端閉源、API 呼叫）與 Muse Glimmer（本地開源、300 億參數）的定位差異，強調不可混為一談。
  • Muse Spark 1.3 核心能力：
  • 定位為「長任務代理人」，優化多步驟、跨工具任務的可靠性、防呆機制與成本效率。
  • 第三方數據顯示其在銀行與終端任務表現提升，但長上下文能力因降低幻覺率策略而略有退步。
  • 成本優勢明顯，但 Max 版本僅限有限預覽，Shy 版本為主要開放對象。
  • Muse Voice Transcribe 技術創新：
  • 解決傳統 ASR 在即時性與準確率間的矛盾，採用「自適應延遲」技術。
  • 在英語即時對話中詞錯誤率（WER）達 3.1%，具備說話人分離、端點偵測及多語言切換能力。
  • 隱私問題需嚴格區分網頁演示與 API 部署的數據保存條款。
  • 產業與隱私觀點：
  • 探討 Meta 透過 Ray-Ban 智慧眼鏡結合端側與雲端處理的潛在架構。
  • 指出當前 AI 競爭已從比跑分轉向比落地場景、隱私安全與商業化成本。

詳細大綱

I. 前言：AI 落地的真實痛點

  • 當前 AI 助手在跨部門報告、多步驟任務、跨工具協作中的不穩定性。
  • Meta 於 2026 年 9 月連續發布兩項更新，精準回應上述痛點。
  • 釐清產品線界限的重要性，避免誤解部署預期。

II. Muse Spark 1.3：雲端前沿代理人模型

  • 產品定位與發布時間：
  • 9 月 2 日發布，Muse Spark 1.3 代理人模型。
  • 與 Muse Glimmer（300 億參數、Apache 2.0、本地部署）區分。
  • Spark 目前僅開放 API 呼叫，無明確開放權重時間表。
  • 迭代歷史與策略：
  • 從 7 月 1.1 版到 9 月 1.3 版，每月大版本更新。
  • 1.3 版針對代理人任務可靠性強化，非全面壓倒性進化。
  • 核心能力：長任務代理人：
  • 定義：從一次性回答轉向執行助理角色（拆解步驟、呼叫工具、回頭確認、風險暫停）。
  • 優化痛點：解決忘記要求、偏離目標、編造數據等問題。
  • 機制：主動追問模糊需求、權限檢查、不可逆操作確認、區分補充資訊與新任務。
  • 能力邊界判斷：傾向承認「卡住」而非編造完整報告。
  • 效率與成本：
  • Meta 內部數據：工具呼叫減少 20%，Token 消耗減少 25%。
  • 代理人任務成本通常為純問答的 3-5 倍，效率提升對商業化至關重要。
  • 第三方獨立評測數據 (Artificial Analysis)：
  • 綜合智慧指數：Shy 版本 61 分，Max 版本 62 分（1.2 版為 57 分）。
  • 成本對比：Shy 版本平均 $0.55/任務，低於 GPT-4O Advanced ($1.2) 與 Cloud Opus ($1.5)。
  • 特定基準測試：
  • Tile3-Bench Banking（銀行代理人）：1.2 版 35% -> Shy 47% -> Max 52%。
  • Terminal-Bench 2.1（終端指令）：1.2 版 80% -> Shy 85% -> Max 86%。
  • AA-LCR 長上下文基準：1.2 版 83% -> 1.3 版 79%（退步原因：傾向拒絕回答而非硬猜，降低幻覺率）。
  • Max 版本代價：推理量增加約 62%（GDPVAL-AAVFE 任務），算力消耗大。
  • 未來趨勢：可能發展出依風險等級調整推理強度的分級定價模式。

III. Muse Voice Transcribe：感知輸入的耳朵

  • 發布時間：9 月 1 日，Muse Voice Transcribe 語音轉寫模型。
  • 技術架構與創新：
  • 區別於傳統離線 ASR（如 Whisper）與低延遲但低準確率的即時助手。
  • 技術：80 毫秒音頻切片、每秒處理 12 月 5 日次（註：原文如此）、軟 Token 轉換、自適應延遲。
  • 自適應延遲：根據內容確定性調整等待時間，類似人類同步口譯。
  • 訓練目標：強化學習獎勵函數平衡詞錯誤率與延遲時間。
  • 表現數據：
  • Artificial Analysis 流逝語音榜單第一名，詞錯誤率約 3.1%。
  • 接近人類專業數據員水平（2%-3%），但僅限英語即時對話。
  • 中文及其他語言表現可能因同音字、聲調、環境噪音而下降。
  • 僅 25 種語言經過充分驗證，其餘 70 多種語言覆蓋情況不明。
  • 關鍵功能：
  • 原生說話人分離：支援 20 人以上同時發言，同一生成過程標記身份，提升時間軸準確度。
  • 端點偵測：優化語氣、停頓與上下文判斷，避免助手插嘴或反應遲緩。
  • 多語言自由切換與上下文偏制：支援 70 多種語言切換，允許預錄專有名詞（人名、公司名、術語）以提升準確率。
  • 部署與隱私：
  • 已接入 Meta Model API、Meta AI4 Mac、Muse Code Mac 版本。
  • 隱私警示：網頁演示不保存音頻，但 API 呼叫與產品部署的數據保存條款需視服務協議而定，存在個資合規風險。

IV. 隱私、安全與產業格局

  • Muse Spark 1.3 安全設計：
  • 增強對提示注入（Prompt Injection）與對抗輸入的抵抗力。
  • 識別不可逆操作（刪除、批量發送、修改設定）並要求確認。
  • 企業部署建議：全線隔離、白名單、操作日誌。
  • Ray-Ban 智慧眼鏡與隱私：
  • 眼鏡隨時處於聲音環境，引發錄音與隱私控制問題。
  • 推測架構：輕量級語音轉寫與簡單指令在端側芯片運行，複雜代理人任務交由雲端 Spark。
  • 利用 Glimmer 本地開源路線進行端側部署，兼顧體驗與隱私。
  • 發布口徑與實際風險：
  • Max 版本僅有限預覽，Shy 版本為主要開放對象，62 分僅為技術上限參考。
  • 基準測試在乾淨環境進行，真實世界場景更複雜，跑分不等於真實生產力。
  • Spark 1.3 目前完全閉源，短期內無法本地運行，Meta 將作為商業護城河。
  • 產業競爭現狀：
  • Meta 在代理人可靠性與語音轉寫上有小幅度領先，但未拉開巨大差距。
  • 競爭對手：OpenAI (GPT 系列)、Google (Gemini)、Anthropic (長上下文與安全)、Eleven Labs。
  • 競爭核心：從比模型大小轉向比產品化、隱私安全與落地能力。

V. 結論

  • Muse Spark 1.3 與 Muse Voice Transcribe 均為階段性進展，離理想 AI 助理仍有距離。
  • 2026 年 AI 產業轉向：比長任務穩定性、真實聲音理解、企業信任度與隱私控制。
  • 細節優化決定產品能否進入日常生活與工作流。

工具 / 模型 / 名詞整理

  • Meta 內部產品/模型：
  • Muse Voice Transcribe（語音轉寫模型）
  • Muse Spark 1.3（代理人模型）
  • Muse Spark（Shy 版本、Max 版本）
  • Muse Glimmer（300 億參數、Apache 2.0 授權、本地方案）
  • Muse Code Mac
  • Meta AI4 Mac
  • Meta Superintelligence Labs
  • Ray-Ban 智慧眼鏡（原文提及 "ray減班智慧眼鏡"，疑為 Ray-Ban 聽寫錯誤，但依規則保留原樣或標註疑點，此處列為原文提及名稱）
  • Meta Model API
  • 競爭對手產品/模型：
  • Whisper（傳統自動語音識別）
  • Siri（手機語音助手）
  • Google 助理
  • GPT 系列 / GPT-4O Advanced（OpenAI）
  • Gemini 系列（Google）
  • Cloud Opus（Anthropic）
  • Eleven Labs
  • 測試基準/機構：
  • Artificial Analysis（第三方獨立評測機構）
  • 綜合智慧指數
  • Tile3-Bench Banking（銀行代理人基準測試）
  • Terminal-Bench 2.1（終端指令執行測試）
  • AA-LCR 長上下文基準
  • AA-Omniscience 準確率指標
  • GDPVAL-AAVFE 任務
  • 技術概念/術語：
  • 代理人（Agent）
  • 提示注入（Prompt Injection）
  • 幻覺率（Hallucination Rate）
  • 詞錯誤率（WER, Word Error Rate）
  • 自適應延遲（Adaptive Latency）
  • 端點偵測（Endpoint Detection）
  • 全線隔離（Sandboxing）
  • 白名單（Whitelist）
  • 軟 Token
  • 強化學習（Reinforcement Learning）

操作流程整理

*(註：本影片主要為產品分析與技術解讀，未提供具體用戶操作步驟，故此章節留白或僅記錄產品發布順序)*

  1. 發布順序：
  • 9 月 1 日：發布 Muse Voice Transcribe。
  • 9 月 2 日：發布 Muse Spark 1.3。
  1. 部署與接入：
  • Muse Voice Transcribe 已接入 Meta Model API、Meta AI4 Mac、Muse Code Mac 版本。
  • Muse Spark 1.3 目前僅開放 API 呼叫。

值得注意的限制或風險

  • 長上下文能力退步：Muse Spark 1.3 為降低幻覺率，傾向拒絕回答而非硬猜，導致 AA-LCR 長上下文基準測試分數從 1.2 版的 83% 降至 1.3 版的 79%。
  • 語言覆蓋不均：Muse Voice Transcribe 僅 25 種語言經過充分驗證，其餘 70 多種語言覆蓋情況不明，非英語表現可能因同音字、聲調、環境噪音而下降。
  • 隱私與數據保存：網頁演示不保存音頻，但 API 呼叫與產品部署的數據保存條款需視服務協議而定，存在個資合規風險。
  • Max 版本限制：Muse Spark 1.3 的 Max 版本僅限有限預覽，且推理量增加約 62%，算力消耗大；Shy 版本為主要開放對象。
  • 基準測試與真實場景落差：基準測試在乾淨環境進行，真實世界場景更複雜，跑分不等於真實生產力。
  • 閉源限制：Spark 1.3 目前完全閉源，短期內無法本地運行。

逐字稿辨識疑點

  • segment 596: unnatural_sentence_boundary — 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語。
  • 「用语音助手查形成」：原文語句不通順，疑為聽寫錯誤，具體含義不明。
  • 「权重完全必圆」：疑為「權重完全閉源」之聽寫錯誤，但依規則標為疑點。
  • 「12月5日次」：在描述 Muse Voice Transcribe 處理頻率時出現，時間單位與次數單位混用，疑為聽寫錯誤（可能意指每秒處理次數，但具體數字或單位有誤）。
  • 「Shy版本」與「X-Shy」/「SHAE版本」：在描述 Spark 1.3 版本時，原文交替使用 Shy、X-Shy、SHAE，疑為同一版本名稱的不同聽寫或口誤。
  • 「GDPVAL-AAVFE任務」：此為特定測試任務名稱，拼寫特殊，疑為特定內部或第三方測試代碼，需查證。
  • 「Muse AI4 Mac」：產品名稱拼寫，疑為「Meta AI for Mac」或類似名稱之聽寫錯誤。
  • 「ray減班智慧眼鏡」：明顯為「Ray-Ban Meta 智慧眼鏡」之聽寫錯誤，但依規則標為疑點。
  • 「常任务」：多次出現，疑為「長任務」或「複雜任務」之聽寫錯誤。
  • 「真错」：在描述 1.2 版功能時出現，疑為「任務」或「錯誤」之聽寫錯誤。
  • 「全B原路线」/「B原顶端产品」：疑為「閉源」之聽寫錯誤。
  • 「插画」：在描述多輪對話中，疑為「話茬」或「插話」之聽寫錯誤。
  • 「正体中文」：原文使用此詞，若影片為繁體中文環境，可能為口誤或特定指稱，保留原樣。
  • 「流逝语音」/「流逝實時」：疑為「即時語音」或「流式語音」之聽寫錯誤。
  • 「端策AI」：結尾提及「端策AI」，疑為「端側 AI」之聽寫錯誤。

可延伸追問

  • Muse Spark 1.3 的 Shy 版本與 Max 版本在實際 API 呼叫中的價格差異與性能邊際效應為何？
  • Muse Voice Transcribe 在非英語語言（特別是中文）的具體 WER 數據與支援語言列表何時會公開？
  • Meta 如何確保 Muse Spark 1.3 在企業部署時，針對「提示注入」與「不可逆操作」的安全防護機制能有效抵禦進階攻擊？
  • Ray-Ban 智慧眼鏡的端側 AI 處理與雲端 Spark 代理人的具體協作架構與數據流轉細節為何？
  • Artificial Analysis 的第三方評測方法論與基準測試環境是否足以反映真實商業場景的複雜性？

尚未產生學習筆記

請在 Telegram 指令最後加上「學習」，例如：videonote 網址 英文 雙語 學習