WEBVTT

00:00:00.000 --> 00:00:03.760
歡迎收聽聽書Podcast本大由壯菜工程師製作。

00:00:03.760 --> 00:00:11.840
那個現在想請你在腦海中稍微想像一下一個我們日常工作極度混亂的場景好了。

00:00:11.840 --> 00:00:13.160
嗯,多混亂。

00:00:13.160 --> 00:00:18.680
這是你正身處在一個可能有八個人同時講話的那種會議室裡面。

00:00:18.680 --> 00:00:20.080
哇,那真的很吵耶。

00:00:20.080 --> 00:00:21.520
對,超級吵。

00:00:21.520 --> 00:00:25.840
然後有人在為了那個專案的進度激烈爭論,

00:00:25.840 --> 00:00:28.880
然後旁邊可能還有人在小聲碎碎唸。

00:00:28.880 --> 00:00:31.680
重點是大家不但中英文夾雜

00:00:31.680 --> 00:00:34.640
還不斷互相搶話跟疊話

00:00:34.640 --> 00:00:36.040
這聽起來就是

00:00:36.040 --> 00:00:39.180
每天辦公室會發生的噩夢啊

00:00:39.180 --> 00:00:40.260
沒錯沒錯

00:00:40.260 --> 00:00:42.560
但這個時候如果你想像一下

00:00:42.560 --> 00:00:43.580
如果有一個助理

00:00:43.580 --> 00:00:45.600
能在你剛講完話的

00:00:45.600 --> 00:00:48.060
呃0.16秒以內

00:00:48.060 --> 00:00:50.340
立刻遞給你一份完美的逐字稿

00:00:50.340 --> 00:00:51.880
0.16秒

00:00:51.880 --> 00:00:53.500
這幾乎是同步了吧

00:00:53.500 --> 00:00:54.080
對

00:00:54.080 --> 00:00:56.280
而且這份逐字稿上面

00:00:56.280 --> 00:00:58.460
還清清楚楚的標記了

00:00:58.460 --> 00:01:00.620
刚刚哪一句话是谁说的

00:01:00.620 --> 00:01:03.920
甚至连两个人同时开口讲话的内容

00:01:03.920 --> 00:01:05.520
它都分得一清二楚

00:01:05.520 --> 00:01:08.960
这听起来真的很像某种科幻电影里

00:01:08.960 --> 00:01:10.300
才有的可怕科技对吧

00:01:10.300 --> 00:01:10.660
真的

00:01:10.660 --> 00:01:13.400
一般人听起来一定觉得这不可能啦

00:01:13.400 --> 00:01:15.540
但其实这已经不是科幻情节了

00:01:15.540 --> 00:01:17.240
它已经真实发生了

00:01:17.240 --> 00:01:19.940
就在2026年9月1日

00:01:19.940 --> 00:01:22.280
META的超级智慧实验室

00:01:22.280 --> 00:01:24.100
也就是那个MSL

00:01:24.100 --> 00:01:25.440
哦MSL

00:01:25.440 --> 00:01:25.740
对

00:01:25.740 --> 00:01:27.920
他们正式发布了最新的

00:01:27.920 --> 00:01:29.780
即时音讯感知模型

00:01:29.780 --> 00:01:32.040
叫做Muse Voice Transcribe

00:01:32.040 --> 00:01:33.640
Muse Voice Transcribe

00:01:33.640 --> 00:01:35.340
这名字听起来蛮厉害的

00:01:35.340 --> 00:01:36.320
这个技术啊

00:01:36.320 --> 00:01:38.860
它不仅做到了你刚刚描述的那种

00:01:38.860 --> 00:01:41.560
在极度混乱的场景下完美记录

00:01:41.560 --> 00:01:44.040
它甚至在多项基准测试里面

00:01:44.040 --> 00:01:47.480
直接击败了Google跟OpenAI的同级产品

00:01:47.480 --> 00:01:50.020
哇 直接打败两大巨头耶

00:01:50.020 --> 00:01:52.280
所以在这场为你量身打造的

00:01:52.280 --> 00:01:53.080
深度探跑中

00:01:53.080 --> 00:01:54.580
我们绝点不会只是你知道

00:01:54.580 --> 00:01:56.780
很无聊的去念那些声音的规格表

00:01:56.780 --> 00:01:58.180
对那太无聊了

00:01:58.180 --> 00:01:58.540
没错

00:01:58.540 --> 00:02:00.460
我们会带你彻底拆解

00:02:00.460 --> 00:02:02.880
这个打败众多科技巨头的核心技术

00:02:02.880 --> 00:02:04.460
去了解这个AI

00:02:04.460 --> 00:02:06.520
它是如何像我们人类大脑一样

00:02:06.520 --> 00:02:09.820
懂得在听话的时候去犹豫

00:02:09.820 --> 00:02:10.740
犹豫啊

00:02:10.740 --> 00:02:11.900
这个词用的很好

00:02:11.900 --> 00:02:12.380
对吧

00:02:12.380 --> 00:02:12.920
对吧

00:02:12.920 --> 00:02:16.360
然后这项技术将如何彻底颠覆你未来

00:02:16.360 --> 00:02:18.520
跟科技装饰互动的方式

00:02:18.520 --> 00:02:19.980
比如说你的Mac

00:02:19.980 --> 00:02:23.460
甚至是未来的那个AR智慧眼镜

00:02:23.460 --> 00:02:28.760
没错,不过其实要真正理解Muse Voice Transcribe到底有多强大

00:02:28.760 --> 00:02:30.300
我们必须先回头看看

00:02:30.300 --> 00:02:35.060
过去几年的语音辨识技术到底有多么的笨拙

00:02:35.060 --> 00:02:39.020
笨拙,所以过去的方法很卡就对了

00:02:39.020 --> 00:02:43.480
超级卡,我们得先看看过去的那种拼装车系统

00:02:43.480 --> 00:02:44.220
拼装车

00:02:44.220 --> 00:02:48.160
对,因为过去如果你想要完成一份会议的逐字稿

00:02:48.160 --> 00:02:51.220
它其实不是一个单一的人工智慧在运作

00:02:51.220 --> 00:02:55.060
它是需要三套完全独立的系统来接力完成

00:02:55.060 --> 00:02:56.980
呃哪三套

00:02:56.980 --> 00:02:58.720
首先是那个ASR

00:02:58.720 --> 00:03:00.880
也就是自动语音辨识系统

00:03:00.880 --> 00:03:02.420
它只负责一件事情

00:03:02.420 --> 00:03:05.260
就是把听到的声音转成文字

00:03:05.260 --> 00:03:06.940
嗯就单纯听写而已

00:03:06.940 --> 00:03:07.400
没错

00:03:07.400 --> 00:03:11.180
接着这个文字和音讯会被丢给Diarization

00:03:11.180 --> 00:03:13.680
也就是说话者分离系统

00:03:13.680 --> 00:03:15.200
等等说话者分离

00:03:15.200 --> 00:03:18.420
这听起来就像是一个事后侦探也

00:03:18.420 --> 00:03:19.200
对对对

00:03:19.200 --> 00:03:21.160
它就是负责回头去分辨说

00:03:21.160 --> 00:03:24.680
现在这句话到底是会议室里面的哪个人说的

00:03:24.680 --> 00:03:27.300
然后最后还需要过一个叫做

00:03:27.300 --> 00:03:29.700
endpointing的端点侦测系统

00:03:29.700 --> 00:03:30.760
端点侦测

00:03:30.760 --> 00:03:32.180
这又是做什么的

00:03:32.180 --> 00:03:33.860
这个就是用来判断说

00:03:33.860 --> 00:03:36.080
这个人到底讲完话了没有

00:03:36.080 --> 00:03:38.280
系统该不该切断麦克风

00:03:38.280 --> 00:03:40.420
哇这听起来就像是一条

00:03:40.420 --> 00:03:43.540
非常老旧而且缺乏效率的工厂管线

00:03:43.540 --> 00:03:45.960
真的非常贴切的比喻

00:03:45.960 --> 00:03:49.000
你可以想象就是三个工人站在输送袋旁边

00:03:49.000 --> 00:03:50.720
第一个工人只顾着

00:03:50.720 --> 00:03:52.440
听声音写字

00:03:52.440 --> 00:03:53.920
然后把写好的纸条

00:03:53.920 --> 00:03:55.420
赶快传给第二个工人

00:03:55.420 --> 00:03:56.560
然后第二个工人

00:03:56.560 --> 00:03:57.840
再去对比声音

00:03:57.840 --> 00:03:59.260
猜这到底是谁说的

00:03:59.260 --> 00:04:01.280
最后再传给第三个工人

00:04:01.280 --> 00:04:02.360
去决定这句话

00:04:02.360 --> 00:04:03.580
是不是真的结束了

00:04:03.580 --> 00:04:04.060
没错

00:04:04.060 --> 00:04:05.300
就是这么繁琐

00:04:05.300 --> 00:04:07.440
而且只要其中一个环节出错

00:04:07.440 --> 00:04:09.720
整个流程就会大塞车

00:04:09.720 --> 00:04:10.140
真的

00:04:10.140 --> 00:04:11.280
我之前用过一些

00:04:11.280 --> 00:04:12.400
会议记录软体

00:04:12.400 --> 00:04:14.240
最常发生的惨剧就是

00:04:14.240 --> 00:04:15.000
那个

00:04:15.000 --> 00:04:17.680
A老板的话才刚讲到一半

00:04:17.680 --> 00:04:20.600
然后旁边B员工稍微咳嗽了一声

00:04:20.600 --> 00:04:22.580
哦对系统就切断了

00:04:22.580 --> 00:04:24.860
没错系统就以为A讲完了

00:04:24.860 --> 00:04:27.160
直接把句子无情切断

00:04:27.160 --> 00:04:29.240
然后还把后面半句算在B头上

00:04:29.240 --> 00:04:30.620
这超尴尬的

00:04:30.620 --> 00:04:32.740
这真的是传统架构的致命伤

00:04:32.740 --> 00:04:36.700
过去这种做法通常需要大量的事后处理

00:04:36.700 --> 00:04:38.700
也就是等你整段话都录完了

00:04:38.700 --> 00:04:41.640
系统才能开始跑这些复杂的对比流程

00:04:41.640 --> 00:04:44.600
所以根本不可能做到真正的及时

00:04:44.600 --> 00:04:48.780
所以Meta这次的做法是怎么解决这个问题的

00:04:48.780 --> 00:04:51.880
他们这次的做法可以说是破坏性的创新

00:04:51.880 --> 00:04:56.560
他们把三个工人的工作全部交给了一个超级大脑同时完成

00:04:56.560 --> 00:04:58.440
一个大脑全包了

00:04:58.440 --> 00:04:58.660
对

00:04:58.660 --> 00:05:00.240
Muse Voice Transcribe

00:05:00.240 --> 00:05:07.080
它其实是建构在Meta的Muse Spark家族之上的一款自回归多模态模型

00:05:07.080 --> 00:05:08.600
等一下先暂停一下

00:05:08.600 --> 00:05:11.380
那个自回归多模态模型

00:05:11.380 --> 00:05:15.120
这几个字听起来真的很像某种外星语言也

00:05:15.120 --> 00:05:18.160
如果我们要用最白话的方式来理解

00:05:18.160 --> 00:05:19.780
这到底是什么意思

00:05:19.780 --> 00:05:21.140
简单来说了

00:05:21.140 --> 00:05:22.580
多摩泰意味着

00:05:22.580 --> 00:05:25.380
这个模型它可以同时看懂文字

00:05:25.380 --> 00:05:26.920
也能听懂声音

00:05:26.920 --> 00:05:29.660
它不是只吃单一一种资料

00:05:29.660 --> 00:05:33.300
哦 就是眼观四面耳听八方的感觉

00:05:33.300 --> 00:05:33.720
没错

00:05:33.720 --> 00:05:35.100
那自回归的话

00:05:35.100 --> 00:05:37.260
就像是我们在玩文字接龙一样

00:05:37.260 --> 00:05:39.720
它会根据已经接收到的资讯

00:05:39.720 --> 00:05:41.940
不断去预测下一步是什么

00:05:41.940 --> 00:05:44.500
但最关键的突破在于

00:05:44.500 --> 00:05:47.060
Meta在同一个音讯串流里面

00:05:47.060 --> 00:05:49.120
直接引入了特殊的标记

00:05:49.120 --> 00:05:50.420
也就是TOKENS

00:05:50.420 --> 00:05:52.820
这完全打破了我们刚才说的

00:05:52.820 --> 00:05:54.340
那个三阶段管线

00:05:54.340 --> 00:05:54.920
标记

00:05:54.920 --> 00:05:57.340
在在实际运作的画面上

00:05:57.340 --> 00:05:58.840
到底会长什么样子

00:05:58.840 --> 00:05:59.860
你想象一下

00:05:59.860 --> 00:06:01.560
有一条连续的时间轴

00:06:01.560 --> 00:06:03.760
当模型在及时聆听的时候

00:06:03.760 --> 00:06:05.860
只要它侦测到换人说话了

00:06:05.860 --> 00:06:08.020
它不会去呼叫别的系统来帮忙

00:06:08.020 --> 00:06:08.900
那它怎么做

00:06:08.900 --> 00:06:11.940
它会直接在自己生成的文字流里面

00:06:11.940 --> 00:06:13.600
插入一个特殊的标记

00:06:13.600 --> 00:06:15.280
叫做Start of Turn

00:06:15.280 --> 00:06:17.380
也就是换人说话的标记

00:06:17.380 --> 00:06:18.980
然后紧接着标注

00:06:18.980 --> 00:06:21.260
这句话是Speaker A说的

00:06:21.260 --> 00:06:23.860
哇 直接在同一个时间轴上标出来

00:06:23.860 --> 00:06:24.820
对对对

00:06:24.820 --> 00:06:27.580
同样的 刚你停顿或者讲完的时候

00:06:27.580 --> 00:06:31.660
它也会立刻放入一个Speech Endpoint的语音结束标记

00:06:31.660 --> 00:06:33.960
等于说所有的文字内容

00:06:33.960 --> 00:06:36.580
还有身份辨识 语气停顿

00:06:36.580 --> 00:06:38.660
全都在同一个时间轴上

00:06:38.660 --> 00:06:41.820
由这个单一模型一次性全部吐出来

00:06:41.820 --> 00:06:43.020
没有错就是这样

00:06:43.020 --> 00:06:48.420
哇所以这代表着我们再也不用忍受那种很尴尬的语音输入时刻了耶

00:06:48.420 --> 00:06:52.440
你们一定有碰过平时对着手机讲话稍微停顿想个词

00:06:52.440 --> 00:06:54.060
系统就以为你讲完了

00:06:54.060 --> 00:06:56.120
对然后就无情的把你切断

00:06:56.120 --> 00:07:00.840
没错现在这个模型它能真正理解对话的节奏

00:07:00.840 --> 00:07:06.200
它知道你只是在脑袋里面那个卡词了而不是真的结束发言

00:07:06.200 --> 00:07:10.320
没错,这正是单一串流模型带来的巨大优势

00:07:10.320 --> 00:07:15.780
但其实,这背后隐藏着一个极度矛盾的工程难题

00:07:15.780 --> 00:07:17.020
怎么说?

00:07:17.480 --> 00:07:19.320
既然这是一个超级模型

00:07:19.320 --> 00:07:24.140
要及时处理所有的声音、身份和文字

00:07:24.140 --> 00:07:27.980
那他怎么知道什么时候该把文字吐出来?

00:07:28.460 --> 00:07:29.340
哦,对耶

00:07:29.340 --> 00:07:32.100
如果他一听到声音就立刻输出文字

00:07:32.100 --> 00:07:34.280
那肯定很容易听错嘛

00:07:34.280 --> 00:07:36.680
但如果他为了追求完美

00:07:36.680 --> 00:07:39.220
等听完整句话才输出

00:07:39.220 --> 00:07:41.440
那又失去了我们刚才说的

00:07:41.440 --> 00:07:42.720
及时的意义

00:07:42.720 --> 00:07:43.760
这真的很矛盾

00:07:43.760 --> 00:07:46.280
这就像我们人类大脑

00:07:46.280 --> 00:07:47.840
在听别人说话一样

00:07:47.840 --> 00:07:48.920
你想想看

00:07:48.920 --> 00:07:50.720
如果有人对我说苹果

00:07:50.720 --> 00:07:52.820
就很简单的日常词汇

00:07:52.820 --> 00:07:55.240
我的大脑几乎不需要思考

00:07:55.240 --> 00:07:56.520
马上就能写下来

00:07:56.520 --> 00:07:57.380
对 瞄懂

00:07:57.380 --> 00:07:58.700
但如果今天

00:07:58.700 --> 00:08:00.000
对方正在讲一段话

00:08:00.000 --> 00:08:10.240
但如果今天,對方正在講一個超級複雜的醫學專有名詞,或者是他講話含糊不清,甚至口音很重,我的大腦其實會稍微,呃,猶豫個零點幾秒。

00:08:10.240 --> 00:08:11.600
沒錯,會卡一下。

00:08:11.600 --> 00:08:19.820
对,就是要等它把所有的音节都发音完整了,然后我在脑海中拼错确认之后,我才敢写下来。

00:08:20.220 --> 00:08:24.040
这个AI模型难道也会模仿人类的这种犹豫吗?

00:08:24.360 --> 00:08:26.740
这个人类大脑的类比非常到位耶。

00:08:27.240 --> 00:08:31.160
其实META的工程师就是循着这个逻辑去设计的。

00:08:31.680 --> 00:08:36.800
他们在技术摆笔书里面把这个称之为自适应延迟技术。

00:08:37.160 --> 00:08:40.340
自适应延迟,听起来蛮高级的。

00:08:40.340 --> 00:08:50.520
为了做到这点,模型在接收音讯的时候,它会把声音切成极小极小的区块,精确来说是80毫秒一个区块。

00:08:50.760 --> 00:08:53.020
80毫秒,这也太短了吧?

00:08:53.460 --> 00:08:59.980
超短的,也就是说在一秒钟之内,模型会接收到12.5个音讯区块。

00:09:00.660 --> 00:09:06.160
而在接收到每一个80毫秒区块的当下,模型都必须做出一个决定。

00:09:06.340 --> 00:09:07.020
什么决动?

00:09:07.020 --> 00:09:10.200
就是我是要现在立刻输出文字

00:09:10.200 --> 00:09:14.240
还是我要输出一个特殊的Next Audio标记

00:09:14.240 --> 00:09:15.600
告诉自己说

00:09:15.600 --> 00:09:18.340
我需要再多听下一个音讯巨块

00:09:18.340 --> 00:09:19.420
这很酷耶

00:09:19.420 --> 00:09:21.900
但他怎么知道自己该不该等啊

00:09:21.900 --> 00:09:26.240
工程师到底是怎么教懂一个AI学会去内心的呢

00:09:26.240 --> 00:09:29.240
这里的关键就在于强化学习

00:09:29.240 --> 00:09:31.180
工程师在训练它的时候

00:09:31.180 --> 00:09:34.240
设计了一个非常严苛的奖励机制

00:09:34.240 --> 00:09:35.280
有多严苛

00:09:35.280 --> 00:09:39.900
他们把那个字错率的惩罚跟延迟时间的惩罚

00:09:39.900 --> 00:09:41.860
用惩罚结合在一起

00:09:41.860 --> 00:09:44.480
你可以想象这是一场极限挑战

00:09:44.480 --> 00:09:46.280
如果模型当个快手

00:09:46.280 --> 00:09:47.800
一听到声音就乱拆

00:09:47.800 --> 00:09:49.260
导致疯狂写错字

00:09:49.260 --> 00:09:50.560
他就会被扣分

00:09:50.560 --> 00:09:53.140
那如果他想当个腕面主义者呢

00:09:53.140 --> 00:09:53.740
哇

00:09:53.740 --> 00:09:58.080
如果他为了一个字等了两三秒才输说文字

00:09:58.080 --> 00:10:00.280
他一样会被狠狠扣分

00:10:00.280 --> 00:10:01.120
哇

00:10:01.120 --> 00:10:05.360
这就像是在训练一个极度严格的听打员

00:10:05.360 --> 00:10:07.260
你就是不能错

00:10:07.260 --> 00:10:08.760
但是你也不能慢

00:10:08.760 --> 00:10:10.820
就是这种严格的训练

00:10:10.820 --> 00:10:13.320
逼迫模型学会了去判断语境

00:10:13.320 --> 00:10:15.520
碰到简单的日常对话

00:10:15.520 --> 00:10:17.040
它就立刻秒翻

00:10:17.040 --> 00:10:19.420
碰到尖色的专有名词

00:10:19.420 --> 00:10:21.200
或者是模糊的发音

00:10:21.200 --> 00:10:24.520
它就会选择多等个几十毫秒

00:10:24.520 --> 00:10:27.920
收集更多声音特征之后再输出

00:10:27.920 --> 00:10:28.960
这蛮合理的

00:10:28.960 --> 00:10:29.520
对

00:10:29.520 --> 00:10:31.120
在工程界

00:10:31.120 --> 00:10:33.480
这被称回达到了Pareto Front

00:10:33.480 --> 00:10:36.480
也就是在速度与准确度之间

00:10:36.480 --> 00:10:39.500
找到了无法再被超越的最佳边界

00:10:39.500 --> 00:10:41.360
最终的结果是

00:10:41.360 --> 00:10:42.840
Muse Voice Transcribe

00:10:42.840 --> 00:10:44.440
从你讲完话

00:10:44.440 --> 00:10:46.800
到萤幕上出现正确文字

00:10:46.800 --> 00:10:49.520
只需要惊人的0.16秒

00:10:49.520 --> 00:10:50.040
等等

00:10:50.040 --> 00:10:53.140
我要在这里稍微挑战一下

00:10:53.140 --> 00:10:54.960
0.16秒

00:10:54.960 --> 00:10:57.340
人类大脑神经传导

00:10:57.340 --> 00:10:58.720
做出反应的时间

00:10:58.720 --> 00:11:00.240
搞不好都比这个慢

00:11:00.240 --> 00:11:03.960
一个AI模型要在这0.16秒内

00:11:03.960 --> 00:11:05.100
切分音讯

00:11:05.100 --> 00:11:06.740
决定要不要等待

00:11:06.740 --> 00:11:09.040
还要辨识是谁说话

00:11:09.040 --> 00:11:10.380
并伸出文字

00:11:10.380 --> 00:11:13.920
他怎么可能在这么短的时间内运算完

00:11:13.920 --> 00:11:15.820
却不吃垮电脑的效能

00:11:15.820 --> 00:11:18.520
这真的是个非常好的质疑

00:11:18.520 --> 00:11:20.340
直觉上做这么多事情

00:11:20.340 --> 00:11:22.160
应该会严重拖慢系统

00:11:22.160 --> 00:11:23.060
对啊

00:11:23.060 --> 00:11:24.600
听起来运算量超大的

00:11:24.600 --> 00:11:26.660
但实际情况恰好相反

00:11:26.660 --> 00:11:29.060
正因为它舍去了过去那种

00:11:29.060 --> 00:11:32.580
三套系统互相传递资料的管线架构

00:11:32.580 --> 00:11:35.380
它省去了系统之间来回沟通

00:11:35.380 --> 00:11:38.300
和对时间轴的庞大运算成本

00:11:38.300 --> 00:11:40.800
就不用大家互相等来等去

00:11:40.800 --> 00:11:41.400
没错

00:11:41.400 --> 00:11:43.880
一个单一的自回归模型

00:11:43.880 --> 00:11:46.280
只要硬体的记忆体频宽足够

00:11:46.280 --> 00:11:48.560
它处理连续串流的效率

00:11:48.560 --> 00:11:51.740
其实远比传统的分工合作还要快得多

00:11:51.740 --> 00:11:53.240
这也就是为什么

00:11:53.240 --> 00:11:56.960
它能压榨出0.16秒这种极限速度

00:11:56.960 --> 00:11:58.680
哇 原来是这样

00:11:58.680 --> 00:12:02.280
理论和底层机制听起来确实很惊人啦

00:12:02.280 --> 00:12:03.640
但我们都知道

00:12:03.640 --> 00:12:06.720
实验室里面的数据是一回事

00:12:06.720 --> 00:12:09.620
把模型丢进残酷的真实世界

00:12:09.620 --> 00:12:12.120
面对各种混乱的对话场景

00:12:12.120 --> 00:12:14.000
那又是另外一回事了嘛

00:12:14.000 --> 00:12:16.960
它在真实环境中的表现到底怎么样

00:12:16.960 --> 00:12:20.040
那我们就来看看知名的AI评测机构

00:12:20.040 --> 00:12:23.200
Artificial Analysis给出的硬数据吧

00:12:23.200 --> 00:12:26.900
在纯英文的即时串流测试里面

00:12:26.900 --> 00:12:31.240
Muse Voice Transcribe的字错率仅仅只有3.1%

00:12:31.240 --> 00:12:32.480
3.1%

00:12:32.480 --> 00:12:34.460
这算是很好的成绩吗

00:12:34.460 --> 00:12:35.560
非常好

00:12:35.560 --> 00:12:36.700
这是什么概面

00:12:36.700 --> 00:12:40.140
它直接击败了目前语音领域的王者

00:12:40.140 --> 00:12:42.180
也就是那个11实验室

00:12:42.180 --> 00:12:44.400
他们的3.6%

00:12:44.400 --> 00:12:45.940
哦 11 labs

00:12:45.940 --> 00:12:46.480
对

00:12:46.480 --> 00:12:51.360
它也赢过了Oper AI的GPT Live Transcribe的3.9

00:12:51.360 --> 00:12:54.260
甚至把Google在8月才刚发布的

00:12:54.260 --> 00:12:56.900
German Live 3.5 Transcribe Live的4.0

00:12:56.900 --> 00:12:58.420
都抛在脑后

00:12:58.420 --> 00:13:00.820
哇 全部斩压耶

00:13:00.820 --> 00:13:01.340
没错

00:13:01.340 --> 00:13:04.300
而且在讲者辨识错误率上

00:13:04.300 --> 00:13:06.500
它的错误率只有17.5%

00:13:06.500 --> 00:13:09.320
这个数字甚至赢过了市面上许多

00:13:09.320 --> 00:13:13.080
允许你事后慢慢处理的那种非即时模型

00:13:13.080 --> 00:13:15.540
不过我觉得我们必须拉回现实一下

00:13:15.540 --> 00:13:17.640
我们的听众最关心的

00:13:17.640 --> 00:13:20.700
绝对不是在一个纯英文

00:13:20.700 --> 00:13:23.160
大家都自证强缘的环境里面

00:13:23.160 --> 00:13:23.900
它有多准

00:13:23.900 --> 00:13:24.980
嗯 确实

00:13:24.980 --> 00:13:25.480
对嘛

00:13:25.480 --> 00:13:26.520
我们在排湾

00:13:26.520 --> 00:13:29.420
平时讲话可是中阴夹杂的耶

00:13:29.420 --> 00:13:30.540
像是那个

00:13:30.540 --> 00:13:31.800
我明天有个meeting

00:13:31.800 --> 00:13:33.460
记得remind我一下

00:13:33.460 --> 00:13:36.340
这种句子才是我们最正式的日常啊

00:13:36.340 --> 00:13:38.940
Meta其实在这方面下了很大的功夫

00:13:38.940 --> 00:13:40.840
这款模型发布的时候

00:13:40.840 --> 00:13:43.160
就已经支援了70多种语言

00:13:43.160 --> 00:13:46.200
其中有25种是经过完整验证的

00:13:46.200 --> 00:13:47.380
最厉害的是

00:13:47.380 --> 00:13:51.280
它原生就支援句子内部的鱼马转换

00:13:51.280 --> 00:13:52.140
鱼马转换

00:13:52.140 --> 00:13:55.220
意思是它不需要我去切换那个语言设定

00:13:55.220 --> 00:13:56.780
就能自动听懂吗

00:13:56.780 --> 00:13:57.100
是的

00:13:57.100 --> 00:13:59.740
在官方释出的测试来源里面

00:13:59.740 --> 00:14:02.820
有一段充满硬核科技术语的中文录音

00:14:02.820 --> 00:14:04.080
测试者说

00:14:04.080 --> 00:14:06.980
用Olama跑了向Meta的Muse Glamour

00:14:06.980 --> 00:14:11.540
直接deploy在我的NVIDIA RTX 3090上

00:14:11.540 --> 00:14:14.960
我这句话里面充满了英文专有名词数字

00:14:14.960 --> 00:14:18.320
而且中英文切换完全是随机的耶

00:14:18.320 --> 00:14:18.720
没错

00:14:18.720 --> 00:14:21.860
母亲不需要任何提示就能无缝辨识

00:14:21.860 --> 00:14:24.020
还能根据文法的上下文

00:14:24.020 --> 00:14:25.780
去自动校正评字

00:14:25.780 --> 00:14:27.580
说到真实世界的混乱

00:14:27.580 --> 00:14:29.080
我看到资料里面

00:14:29.080 --> 00:14:31.800
还有一个让我下巴掉下来的测试

00:14:31.800 --> 00:14:33.200
你说那个爬山的那个吗

00:14:33.200 --> 00:14:33.840
对对对

00:14:33.840 --> 00:14:36.260
那个是一个长达一小时的音档

00:14:36.260 --> 00:14:39.140
里面竟然有11个人

00:14:39.140 --> 00:14:41.040
在洛杉矶讨论爬山

00:14:41.040 --> 00:14:43.500
甚至还聊到遇到土狼的经历

00:14:43.500 --> 00:14:44.660
你想想看

00:14:44.660 --> 00:14:47.080
11个人在闲聊耶

00:14:47.080 --> 00:14:48.660
一定有人在大笑

00:14:48.660 --> 00:14:50.040
有人互相抢话

00:14:50.040 --> 00:14:52.340
背景绝对还有各种环境噪音

00:14:52.340 --> 00:14:53.420
这对AI来说

00:14:53.420 --> 00:14:55.040
根本是地狱级的考验

00:14:55.040 --> 00:14:55.580
真的

00:14:55.580 --> 00:14:58.220
结果系统竟然能精准的

00:14:58.220 --> 00:15:00.040
把那11个人的发言

00:15:00.040 --> 00:15:02.120
一次不漏的拆解开来

00:15:02.120 --> 00:15:04.280
还标上speakerA到K

00:15:04.280 --> 00:15:06.900
这如果叫人类的听答员来做

00:15:06.900 --> 00:15:08.140
听个10分钟

00:15:08.140 --> 00:15:09.740
绝对崩溃磁石吧

00:15:09.740 --> 00:15:11.360
但这在技术上

00:15:11.360 --> 00:15:12.740
到底是怎么办到的

00:15:12.740 --> 00:15:13.820
如果两个人

00:15:13.820 --> 00:15:16.060
在同一微秒重叠讲话呢

00:15:16.060 --> 00:15:17.380
这就是我们刚刚说的

00:15:17.380 --> 00:15:20.180
多模态标记发挥威力的地方了

00:15:20.180 --> 00:15:22.520
当两个人同时讲话的时候

00:15:22.520 --> 00:15:25.560
传统系统的音轨会整个混在一起

00:15:25.560 --> 00:15:27.560
变成无法辨识的噪音

00:15:27.560 --> 00:15:29.680
嗯就胡称一团

00:15:29.680 --> 00:15:30.140
对

00:15:30.140 --> 00:15:31.940
但Muse Voice Transcribe

00:15:31.940 --> 00:15:35.440
因为是从极短的80毫秒音讯区块

00:15:35.440 --> 00:15:36.460
去提取特征

00:15:36.460 --> 00:15:39.440
它可以同时触发多个讲者的token

00:15:39.440 --> 00:15:41.060
可以同时触发

00:15:41.060 --> 00:15:41.600
没错

00:15:41.600 --> 00:15:44.460
它会在文字流里面并行输出

00:15:44.460 --> 00:15:46.300
Speaker A说了这一段

00:15:46.300 --> 00:15:48.660
同时Speaker B正在说那一段

00:15:48.660 --> 00:15:50.500
它不是单线程的处理

00:15:50.500 --> 00:15:52.460
而是能像解开毛线球一样

00:15:52.460 --> 00:15:55.020
把交织在一起的音讯分离出来

00:15:55.020 --> 00:15:56.920
这技术真的蛮扯的

00:15:56.920 --> 00:15:59.760
不过身为替台湾听众把关的酒色

00:16:04.500 --> 00:16:06.000
哦,什麼事實?

00:16:06.000 --> 00:16:14.700
就是,根據台灣知名科技媒體電腦王阿達的實際測試,這項技術目前有一個在地化的致命缺陷。

00:16:14.700 --> 00:16:16.100
嗯,在地化

00:16:16.100 --> 00:16:20.660
对,尽管你对着麦克风说的是很标准的台湾繁体中文

00:16:20.660 --> 00:16:26.040
它目前在荧幕上输出的文字依然全都是,呃,简体中文

00:16:26.040 --> 00:16:28.140
这确实蛮麻烦的

00:16:28.140 --> 00:16:32.560
对啊,不管设定怎么调,目前就是无法原声输出繁体字

00:16:32.560 --> 00:16:36.600
这对台湾的使用者来说绝对还是一个不小的痛点啊

00:16:36.600 --> 00:16:39.440
这的确是一个很明显的在地化缺陷

00:16:39.440 --> 00:16:43.140
其实这显示出虽然模型的听力没有问题

00:16:43.140 --> 00:16:46.740
它的神经网络完全能理解中文的语义

00:16:46.740 --> 00:16:48.260
听得懂但写出来不对

00:16:48.260 --> 00:16:48.720
没错

00:16:48.720 --> 00:16:51.780
但在最后的文字渲染与输出层面

00:16:51.780 --> 00:16:53.360
META的训练资料库

00:16:53.360 --> 00:16:56.160
可能还是过度向简体中文倾斜了

00:16:56.160 --> 00:16:58.880
这也反映了全球化大语言模型

00:16:58.880 --> 00:16:59.860
在落地的时候

00:16:59.860 --> 00:17:03.620
必然会面临到的文化与区域细节挑战了

00:17:03.620 --> 00:17:05.400
这部分就需要META后续

00:17:05.400 --> 00:17:06.820
透过微调来解决了

00:17:06.820 --> 00:17:08.640
既然提到META的策略

00:17:08.640 --> 00:17:11.460
我们来聊聊一个很反常的商业布局好了

00:17:11.460 --> 00:17:12.540
我们都知道

00:17:12.540 --> 00:17:16.320
Meta过去这一年来一直高举着开源的大旗

00:17:16.320 --> 00:17:19.920
把他们最大的AI模型免费开放给全世界

00:17:19.920 --> 00:17:21.600
对 开源界的老大哥

00:17:21.600 --> 00:17:22.300
没错

00:17:22.300 --> 00:17:26.620
但这一次Mail Voice Transcribe却选择了封闭权重

00:17:26.620 --> 00:17:28.800
也就是不开源了

00:17:28.800 --> 00:17:29.380
为什么

00:17:29.380 --> 00:17:32.220
这次Meta确实选择了一条不一样的路

00:17:32.220 --> 00:17:33.600
如果你是开发者

00:17:33.600 --> 00:17:35.780
你无法直接下载模型版身

00:17:35.780 --> 00:17:38.760
你必须透过Meta Model API来使用

00:17:38.760 --> 00:17:39.980
哦 要收费了

00:17:39.980 --> 00:17:42.080
不过收费其实相当低廉啦

00:17:42.080 --> 00:17:45.860
大约是每1000分钟的音讯收费3美元

00:17:45.860 --> 00:17:49.720
换算下来一个小时大概才0.18美元

00:17:49.720 --> 00:17:51.520
那真的蛮便宜的

00:17:51.520 --> 00:17:52.060
对

00:17:52.060 --> 00:17:56.680
另外一般使用者其实可以透过他们新推出的程式撰写工具

00:17:56.680 --> 00:17:58.020
叫做Muse Code

00:17:58.020 --> 00:18:03.500
或者是直接在Mac电脑上下载Meta AI的应用程式来使用这项技术

00:18:03.500 --> 00:18:05.700
所以这到底意味着什么

00:18:05.700 --> 00:18:11.620
Meta把这个听力超强的模型紧紧锁在自家的生态系里面

00:18:11.620 --> 00:18:14.600
甚至还跟Mac的键盘深度绑定

00:18:14.600 --> 00:18:18.580
Mark Zuckerberg到底在盘算什么更大的棋局

00:18:18.580 --> 00:18:22.520
这不仅仅是为了赚那个0.18美元吧

00:18:22.520 --> 00:18:25.180
绝对不是为了这点API的零头啦

00:18:25.180 --> 00:18:28.460
如果我们深入观察 Zuckerberg近期的内部发言

00:18:28.460 --> 00:18:32.300
他不断强调未来的AI必须是个人化的超级智慧

00:18:32.300 --> 00:18:33.980
个人化的超级智慧

00:18:33.980 --> 00:18:36.120
这听起来很抽象耶

00:18:36.120 --> 00:18:40.100
这跟一个语音转文字的模型有什么直接关系

00:18:40.100 --> 00:18:41.340
关系太大了

00:18:41.340 --> 00:18:43.920
如果AI要成为你最贴身

00:18:43.920 --> 00:18:45.420
最懂你的个人助理

00:18:45.420 --> 00:18:46.720
它就不能只是一个

00:18:46.720 --> 00:18:47.900
你对着手机大喊

00:18:47.900 --> 00:18:49.220
嘿帮我设定闹钟

00:18:49.220 --> 00:18:50.900
那种死板的声控工具

00:18:50.900 --> 00:18:53.580
Meta的最终目标是硬体

00:18:53.580 --> 00:18:54.840
特别是他们正在

00:18:54.840 --> 00:18:56.740
大力发展的AI视觉眼镜

00:18:56.740 --> 00:18:58.200
哦 AI眼镜

00:18:58.200 --> 00:18:58.960
你试想一下

00:18:58.960 --> 00:19:00.660
你戴着AI眼镜的一天好了

00:19:00.660 --> 00:19:02.840
你走在台北吵杂的街头

00:19:02.840 --> 00:19:04.260
旁边有车流声

00:19:04.260 --> 00:19:06.260
你正在点一杯珍珠奶茶

00:19:06.260 --> 00:19:08.160
店员问你要几分甜

00:19:08.160 --> 00:19:09.700
这时你旁边的朋友

00:19:09.700 --> 00:19:10.780
突然插花问你

00:19:10.780 --> 00:19:11.940
等下要去哪里

00:19:11.940 --> 00:19:14.200
哇 这个场景非常真实

00:19:14.200 --> 00:19:15.620
也非常混乱

00:19:15.620 --> 00:19:17.580
对 如果你的AI眼镜

00:19:17.580 --> 00:19:19.000
没有完美的机器听觉

00:19:19.000 --> 00:19:20.100
它就只是一个

00:19:20.100 --> 00:19:21.920
戴在脸上的笨重摄影机

00:19:21.920 --> 00:19:23.960
但有了Muse Voice Transcribe

00:19:23.960 --> 00:19:26.020
眼睛能在0.16秒内

00:19:26.020 --> 00:19:27.820
分辨出哪句是电源说的

00:19:27.820 --> 00:19:29.420
哪句是朋友说的

00:19:29.420 --> 00:19:31.160
还能过滤掉车流声

00:19:31.160 --> 00:19:33.120
没错 甚至刚你转头

00:19:33.120 --> 00:19:34.920
忘记朋友刚才问什么的时候

00:19:34.920 --> 00:19:36.740
AI已经把答案准备好

00:19:36.740 --> 00:19:38.320
投射在你的镜片上了

00:19:38.320 --> 00:19:40.040
哇 这画面感很强耶

00:19:40.040 --> 00:19:44.220
这就是为什么Meta现在让你只要在Mac电脑上按住FN键

00:19:44.220 --> 00:19:47.800
就能在任何视窗进行痊愈的及时听写

00:19:47.800 --> 00:19:50.200
这不是一个单纯的打字工具

00:19:50.200 --> 00:19:53.780
这是Meta在训练你习惯与AI无缝对话

00:19:53.780 --> 00:19:58.320
为未来的穿戴式硬体生态系铺设最底层的基础设施

00:19:58.320 --> 00:20:02.280
今天的探讨真的把很多点都串起来了

00:20:02.280 --> 00:20:05.800
我们现在正在见证一个历史性的转捩点

00:20:05.800 --> 00:20:09.880
机器在复杂环境下的听觉处理能力

00:20:09.880 --> 00:20:13.320
正在以前所未有的速度超越人类

00:20:13.320 --> 00:20:14.620
对,真的很快

00:20:14.620 --> 00:20:18.780
他能毫不犹豫地在0.16秒内处理资讯

00:20:18.780 --> 00:20:22.120
他能同时分辨十几个人的声音

00:20:22.120 --> 00:20:24.480
他甚至学会了像人类一样

00:20:24.480 --> 00:20:27.420
在困难的词汇上稍微犹豫一下

00:20:27.420 --> 00:20:31.440
没错,从过去笨重的三步骤拼装车系统

00:20:31.440 --> 00:20:34.560
进化到现在单一串流的超级模型

00:20:34.560 --> 00:20:37.840
这不仅仅是技术指标上的胜利而已

00:20:37.840 --> 00:20:41.720
更是人机互动方式的一次彻底革命

00:20:41.720 --> 00:20:42.900
真的是革命

00:20:42.900 --> 00:20:46.620
虽然目前还像是繁体中文资源不足这样的缺点

00:20:46.620 --> 00:20:49.720
但这项技术为未来AI眼镜

00:20:49.720 --> 00:20:52.600
和无缝语音互动所打下的基础

00:20:52.600 --> 00:20:55.900
其实已经预示了科技的下一步走向了

00:20:55.900 --> 00:20:56.220
真的

00:20:56.220 --> 00:20:59.280
在我们结束今天的深度探讨之前

00:20:59.280 --> 00:21:02.560
我想留给你们一个发人深审的问题

00:21:02.560 --> 00:21:04.080
想象一下

00:21:04.080 --> 00:21:06.320
如果未来的每一台装置

00:21:06.320 --> 00:21:07.700
每一副眼镜

00:21:07.700 --> 00:21:09.800
都能在0.16秒内

00:21:09.800 --> 00:21:11.300
完美记录下

00:21:11.300 --> 00:21:13.160
20个人在会议室里

00:21:13.160 --> 00:21:14.160
互相强化

00:21:14.160 --> 00:21:16.760
甚至私下碎碎念的内容

00:21:16.760 --> 00:21:18.460
并精准标记

00:21:18.460 --> 00:21:19.740
到底是谁说的

00:21:19.740 --> 00:21:21.280
这对我们的社会

00:21:21.280 --> 00:21:22.520
到底意味着什么

00:21:22.520 --> 00:21:23.060
嗯

00:21:23.060 --> 00:21:23.960
这蛮可怕的

00:21:23.960 --> 00:21:24.620
对吧

00:21:24.620 --> 00:21:26.260
当过去那种

00:21:26.260 --> 00:21:28.860
听过就算了的随性闲聊

00:21:28.860 --> 00:21:31.380
全部变成可以被精准搜寻

00:21:31.380 --> 00:21:32.780
被永久记录的

00:21:32.780 --> 00:21:35.100
完美数位逐字稿的时候

00:21:35.100 --> 00:21:37.500
这会让我们的工作与生活

00:21:37.500 --> 00:21:38.840
变得极度高效

00:21:38.840 --> 00:21:41.340
还是会让我们在每次开口之前

00:21:41.340 --> 00:21:43.820
都变得极度焦虑多疑呢

00:21:43.820 --> 00:21:46.240
这是一个值得你在关掉节目后

00:21:46.240 --> 00:21:47.860
好好思考的问题

00:21:47.860 --> 00:21:49.160
谢谢收听

00:21:49.160 --> 00:21:50.360
欢迎订阅分享

00:21:50.360 --> 00:21:51.600
听书Podcast频道

00:21:51.600 --> 00:21:52.620
我们下次见