2024 NTU GenAI MTK研究人員專題演講總結與 WebVTT 字幕 (License: Public Domain)

2024 NTU GenAI MTK研究人員專題演講 (上半場) 總結.md

2024 NTU GenAI MTK 研究人員專題演講 (上半場)

重點總結與知識點

YouTube: https://www.youtube.com/watch?v=UXL5H8MqNmw

重點

1. 聯發科創新基地介紹

   • 聯發科的全資子公司，專注於 AI 研究
   • 據點遍佈劍橋、倫敦和台灣大學
   • 開發多個開源模型和資料集，包含繁體中文領域

2. 繁體中文大型語言模型 Breeze 系列

   • Breeze 7B: 71 億參數，全面開源，推理速度快
   • Breeze 8x7: 420 億參數，採用混合專家模型 (MoE)，在台灣知識領域超越 GPT 3.5

3. 模型訓練與評測

   • 資料集：發布全台首個繁體中文評測集，包含推理能力、知識和聊天行為等面向
   • 詞彙擴充：針對中文特性進行詞彙擴充，提升模型對中文的理解能力
   • 訓練過程：預訓練資料量達 650GB，訓練時間長達 7000 個 H100 GPU 小時

4. 商業應用

   • 模型即服務 (Model as Service)：針對金融、政府等資料安全需求高的客戶提供地端部署方案

5. 技術細節

   • 中文詞彙擴充：解決 BPE 編碼在中文處理上的缺陷，提升模型效率和效果
   • 混合專家模型 (MoE)：提高模型參數效率，在訓練和推論階段都能加速
   • RAG (Retrieval Augmented Generation)：透過引入外部知識庫，提升模型回答問題的準確性和可信度
   • 長文本處理 (Long Context)：將模型上下文長度擴展至 32k tokens，並針對長文本訓練模型，使其能處理更長、更複雜的文本

知識點

• BPE (Byte Pair Encoding)： 一種常見的詞彙 tokenization 方法，但對中文處理存在缺陷
• 詞彙擴充： 針對中文特性擴充詞彙表，提升模型對中文的理解能力
• 混合專家模型 (MoE)： 將模型分為多個專家，根據輸入選擇性激活部分專家，提高參數效率
• RAG (Retrieval Augmented Generation)： 結合資訊檢索和文本生成，讓模型能夠利用外部知識庫回答問題
• 長文本處理 (Long Context)： 擴展模型上下文長度，使其能夠處理更長、更複雜的文本
• Lost in the middle： 長文本處理中，模型在處理文本中間部分資訊時表現較差的現象

待解決問題

• 如何有效解決長文本處理中的 "Lost in the middle" 現象

總結

聯發科在大型語言模型和語音辨識技術方面取得了顯著進展，特別是在繁體中文領域的貢獻。他們發布的開源模型和資料集，以及對模型訓練和評測方法的探索，都為學術界和業界提供了寶貴的資源。未來，他們將繼續致力於開發更強大、更易用的 AI 技術，並探索其在各個領域的應用。

2024 NTU GenAI MTK研究人員專題演講 (下半場) 總結.md

2024 NTU GenAI MTK 研究人員專題演講 (下半場)

重點總結與知識點

YouTube: https://www.youtube.com/watch?v=0mZVhVipdfY

重點

• 探討如何結合自動語音辨識 (ASR) 與大型語言模型 (LLM) 以提升語音辨識的準確度。
• 介紹 MediaTek Research 最新提出的 Generative Fusion Decoding (GFD) 技術，實現 ASR 與 LLM 的 step-by-step fusion。
• 展示 GFD 技術如何解決 ASR 與 LLM token 體系不一致的問題，並透過實驗結果證明其效能優於傳統方法。

知識點

1. 語音辨識現況與挑戰

   • 現今主流語音辨識系統 (如 Whisper) 仍容易出現錯誤，特別是在中文方面。
   • LLM 在理解語言和生成語法正確的句子方面表現出色。

2. 結合 ASR 與 LLM 的方法

   • Rescoring: 利用 LLM 對 ASR 輸出的多個候選句子進行評分，選擇分數最高的句子。
   • Generative error correction: 利用 LLM 理解 ASR 輸出的多個候選句子，並生成一個更正後的句子。

3. Generative Fusion Decoding (GFD) 技術

   • 目標： 實現 ASR 與 LLM 中間過程的資訊交換，並進行平行處理以加速運算。
   • 方法： 將 LLM tokenization 的結果考慮進去 ASR 的機率計算中，解決 ASR 與 LLM token 体系不一致的問題。
   • 優勢： 可準確估計 ASR 部分解碼序列的機率，實現 step-by-step fusion，並提升效率。

4. Clean Audience 技術

   • 在 Whisper 模型中加入 domain tag，透過微調提升特定領域的語音辨識效果。

5. GFD 技術的應用與優勢

   • 解決同音異字問題： 例如將「有意義的意義」正確辨識為「有意義的意義」。
   • 提升專有名詞辨識率： 例如正確辨識公司產品名稱、人名等。
   • 透過 point 引導模型： 例如告知模型當前場景或特定詞彙，提升辨識效果。
   • 處理 Code Switching： 例如正確辨識中英夾雜的語句。

6. 開源與未來發展

   • GFD 技術將開源，並開發更小巧的版本供商業應用。

7. 其他討論

   • 與 end-to-end LLM 語音辨識模型相比，GFD 技術的優缺點。
   • 聯發科創新中心在大型語言模型研究方面的發展方向。

總結

本次演講深入淺出地介紹了 GFD 技術如何結合 ASR 與 LLM 的優勢，提升語音辨識的準確度，並展示其在不同應用場景下的潛力，為語音辨識技術的發展提供了新的思路。

WebVTT 字幕：2024 NTU GenAI MTK研究人員專題演講 (上半場).vtt

WEBVTT
Kind: captions
Language: zh-tw

00:01:06.300 --> 00:01:12.840
今天我們很高興請到聯發科創新基地的宜昌跟湛然

00:01:12.840 --> 00:01:16.600
來跟我們分享聯發創新基地這幾年來的研究

00:01:16.600 --> 00:01:21.000
聯發創新基地近年來非常知名的一個研究就是

00:01:21.000 --> 00:01:24.080
繁體中文的大型語言模型的研究成果

00:01:24.080 --> 00:01:29.760
他們是第一個釋出繁體中文的大型語言模型的團隊

00:01:29.760 --> 00:01:33.380
相信他們是世界上第一個釋出繁體中文大型語言模型的團隊

00:01:33.380 --> 00:01:36.220
今天他們也會講語音相關的技術

00:01:36.220 --> 00:01:39.380
因為大家知道最近GT4釋出了

00:01:39.380 --> 00:01:41.600
Google也做了一個非常類似的東西

00:01:41.600 --> 00:01:43.760
語音的技術是未來非常重要的

00:01:43.760 --> 00:01:48.280
大家可以看看聯發科在語音技術上面有什麼樣的進展

00:01:48.280 --> 00:01:51.060
再來我們就給宜昌跟湛然一個熱烈的掌聲

00:01:52.060 --> 00:01:52.500
謝謝

00:01:57.440 --> 00:01:59.880
謝謝李老師的介紹

00:02:00.700 --> 00:02:03.160
我是宜昌,可以叫我YC

00:02:03.600 --> 00:02:05.880
我們還有另外一位是Jeff

00:02:05.880 --> 00:02:12.160
待會跟大家介紹語言模型跟語言辨識相關的研究

00:02:12.160 --> 00:02:13.660
當然我們是研究單位

00:02:14.260 --> 00:02:17.580
所以我們會盡量把這個東西變得更通識一點

00:02:17.580 --> 00:02:18.580
對,盡量

00:02:19.200 --> 00:02:20.720
如果待會兒聽不懂的話

00:02:20.720 --> 00:02:22.680
隨時都可以舉手包

00:02:22.680 --> 00:02:24.380
我們就盡可能的回答

00:02:27.940 --> 00:02:30.620
今天我們的整個議程的大綱

00:02:30.620 --> 00:02:32.240
有分為上半場跟下半場

00:02:32.240 --> 00:02:34.600
上下半場就給大家休息一下

00:02:34.600 --> 00:02:36.380
休息個15分鐘

00:02:36.380 --> 00:02:40.660
上半場我們會講我們在語言模型的研究

00:02:40.660 --> 00:02:44.300
下半場我們會講我們在語音辨識上面的研究

00:02:44.300 --> 00:02:45.440
上半場的話

00:02:45.440 --> 00:02:49.560
我們會講我們的開發的翻譯中文的語言模型

00:02:49.560 --> 00:02:51.419
有這個Breeze 7D

00:02:51.419 --> 00:02:53.300
以及這個Breeze 8x7

00:02:54.139 --> 00:02:57.780
以及我們講一下我們的比較特別的一些技術

00:02:57.780 --> 00:02:59.200
就是持錶擴充

00:02:59.200 --> 00:03:00.560
以及MOE

00:03:01.220 --> 00:03:04.080
還有有一些應用的增強版

00:03:04.080 --> 00:03:06.639
就是RIG跟Non-Context

00:03:06.639 --> 00:03:09.880
下半場我們會Focus在語音辨識

00:03:09.880 --> 00:03:16.220
尤其是我們最近在發表的一個新的架構

00:03:16.220 --> 00:03:17.760
那一開始我們會講說

00:03:17.760 --> 00:03:20.940
我們要怎麼用語言模型來讓這個

00:03:20.940 --> 00:03:23.720
語音辨識的效果變得更好

00:03:23.720 --> 00:03:25.380
接下來就是我們的模型

00:03:25.380 --> 00:03:28.340
Generated Fusion Decoding

00:03:28.340 --> 00:03:31.660
我們介紹一下我們這個新的研究的成果

00:03:31.660 --> 00:03:34.300
以及進一步衍生我們可以做到

00:03:34.300 --> 00:03:36.280
所謂的Contact Aware

00:03:36.280 --> 00:03:38.240
就是跟Contact比較有關係

00:03:38.240 --> 00:03:39.940
我們希望你可以下Point這種方式

00:03:39.940 --> 00:03:43.040
去影響你的語音辨識系統

00:03:43.040 --> 00:03:47.500
所以這是今天的我們的Outline

00:03:47.500 --> 00:03:49.740
那我們就先從上半場

00:03:49.740 --> 00:03:51.340
上半場我會先講

00:03:51.340 --> 00:03:52.220
然後後半

00:03:52.220 --> 00:03:57.840
後部分再給Jeff來講Non-Context跟RIG

00:03:57.840 --> 00:04:02.540
不免俗介紹一下我們這個聯發創新基地

00:04:02.540 --> 00:04:06.340
我們是聯發科的全資的子公司

00:04:06.340 --> 00:04:09.340
然後是作為聯發科的AI的研究院

00:04:10.100 --> 00:04:12.720
這是我們的老闆許大三

00:04:12.720 --> 00:04:17.160
然後我們在劍橋跟倫敦都有據點

00:04:17.160 --> 00:04:20.300
所以我們是一個跨國際的團隊

00:04:20.300 --> 00:04:23.740
然後我們每週都會有固定的開會

00:04:25.440 --> 00:04:28.100
我們台大的據點其實也就不遠

00:04:28.100 --> 00:04:29.920
就在學新館

00:04:29.920 --> 00:04:32.320
就是在後門

00:04:32.320 --> 00:04:34.839
辛亥路後門走近來一點

00:04:34.839 --> 00:04:35.640
比較深一點

00:04:35.640 --> 00:04:39.300
然後在左側那邊就有一棟新的館

00:04:39.300 --> 00:04:42.500
我們在二樓就是我們聯發創新基地的

00:04:42.500 --> 00:04:44.920
台大據點

00:04:44.920 --> 00:04:47.180
好那我們過去呢

00:04:47.180 --> 00:04:52.520
其實做了蠻多關於原模型或是NLP的相關研究

00:04:52.520 --> 00:04:54.760
在2022年的3月

00:04:54.760 --> 00:04:59.220
我們有跟這個陳運龍實驗室的

00:04:59.220 --> 00:05:00.440
這個學生他是intern

00:05:00.440 --> 00:05:05.220
共同發表了一個叫做Cell Bar的論文

00:05:05.220 --> 00:05:08.339
那如果大家知道台灣拉馬

00:05:08.339 --> 00:05:12.060
這個作者就是林彥廷博士

00:05:12.060 --> 00:05:13.260
博士候選人

00:05:13.260 --> 00:05:14.839
然後他就是那個時候

00:05:14.839 --> 00:05:18.779
一起在我們這邊做實習的學生

00:05:18.779 --> 00:05:21.220
然後就是發表這一篇

00:05:21.220 --> 00:05:24.140
那後來這個2022年的6月

00:05:24.140 --> 00:05:27.980
我們其實就已經開始在做原模型了

00:05:27.980 --> 00:05:31.339
那大家如果還記得Chair GPT發表的時間

00:05:31.339 --> 00:05:35.180
其實應該是在2022年的11月

00:05:35.180 --> 00:05:38.460
所以我們比Chair GPT更早了一步

00:05:38.460 --> 00:05:43.060
當然就是我們隨時都有在看這個學術的研究

00:05:43.060 --> 00:05:45.880
然後了解說原模型其實是

00:05:45.880 --> 00:05:49.000
接下來研究非常重要的一個技術

00:05:49.000 --> 00:05:52.920
所以我們那個時候就已經開始在做這部分的研究

00:05:52.920 --> 00:05:56.140
那沒想到後來有這麼大的突破

00:05:57.600 --> 00:05:59.180
那在後續呢

00:05:59.180 --> 00:06:02.480
我們就有跟一些學術單位去合作

00:06:02.480 --> 00:06:06.500
然後並且開源了第一個這個翻譯中文的模型

00:06:06.500 --> 00:06:09.100
是Brun的這個1B跟3B

00:06:09.100 --> 00:06:12.100
那所謂的1B跟3B其實是它的參數量

00:06:12.100 --> 00:06:14.460
1B就是10億參數

00:06:14.460 --> 00:06:17.120
然後3B是這個30億參數

00:06:17.120 --> 00:06:20.120
那這個參數量大家會覺得好像還蠻多的

00:06:20.120 --> 00:06:22.620
但是其實對於原模型來說

00:06:22.620 --> 00:06:27.900
1B跟3B其實都算是比較小型的這個模型

00:06:27.900 --> 00:06:30.880
像最近拉馬出出來的這個模型

00:06:30.880 --> 00:06:34.020
有這個8B的以及70B的

00:06:34.020 --> 00:06:37.940
然後他們還在持續的訓練200B的

00:06:37.940 --> 00:06:40.260
所以你就可以看到說這個原模型

00:06:40.260 --> 00:06:42.980
這真的非常的這個龐大

00:06:44.320 --> 00:06:47.500
那我們後來就是有寫了一些相關的論文

00:06:47.500 --> 00:06:49.700
這個Brun就是整個是開源的

00:06:49.700 --> 00:06:52.140
然後我們的這個整個做法

00:06:52.140 --> 00:06:54.600
我們都有把它公開

00:06:54.600 --> 00:06:58.580
在寫了一個這個翻譯中文的這個論文

00:06:58.580 --> 00:07:01.720
然後到2023年10月的時候

00:07:01.720 --> 00:07:07.020
我們發布了全台灣第一個這個翻譯中文的評測集

00:07:07.020 --> 00:07:09.820
那做AI其實最重要的就是

00:07:09.820 --> 00:07:11.520
就是到底要怎麼衡量你的系統

00:07:11.520 --> 00:07:13.600
因為我們在打造的是一個

00:07:13.600 --> 00:07:17.320
從資料去訓練出來的的玩意

00:07:17.320 --> 00:07:20.640
所以其實你如果不用一些評測的方法

00:07:20.640 --> 00:07:24.060
你用人去看其實都有所偏頗

00:07:24.060 --> 00:07:26.400
所以一樣的在原模型

00:07:26.400 --> 00:07:28.640
我們也需要一個評測

00:07:28.640 --> 00:07:31.780
那那個時候就是在整個台灣的學術界裡面

00:07:31.780 --> 00:07:33.660
沒有一個合適的評測集

00:07:33.660 --> 00:07:37.640
所以那個時候我們就到國外的相關的評測

00:07:37.640 --> 00:07:40.240
去學習你要怎麼做評測的

00:07:40.240 --> 00:07:43.140
然後建立的這樣一個評測

00:07:43.140 --> 00:07:46.440
然後發布給大家去做使用

00:07:46.440 --> 00:07:48.860
它是完全開源的

00:07:48.860 --> 00:07:50.520
那後來呢

00:07:50.520 --> 00:07:53.260
近期內我們今年的2月

00:07:53.260 --> 00:07:56.160
我們發布了一個叫做Breeze TV

00:07:56.160 --> 00:07:58.620
它是有71參數的這樣的模型

00:07:58.620 --> 00:08:00.600
也是全面的開源

00:08:00.600 --> 00:08:03.920
那這次我們達到首次在預訓練

00:08:03.920 --> 00:08:07.300
就是我們通常會做再次的預訓練

00:08:07.300 --> 00:08:12.740
把中文的能力去灌到原本國外開源的這些模型

00:08:12.740 --> 00:08:15.660
然後我們預訓練達到了650GB

00:08:15.660 --> 00:08:22.520
那這個應該算是全台灣首次達到這個量級的訓練量

00:08:22.520 --> 00:08:24.060
那後來呢

00:08:24.060 --> 00:08:25.720
我們用一樣的資料

00:08:25.720 --> 00:08:28.520
然後把它放到更大的模型

00:08:28.520 --> 00:08:32.540
到這個Meshware 8x7這樣的模型

00:08:32.540 --> 00:08:35.740
這個模型有42B的參數

00:08:35.740 --> 00:08:41.880
那我們就首次的在這個模型超越了現在的GPT 3.5

00:08:41.880 --> 00:08:44.200
不管在英文或是繁體中文

00:08:44.200 --> 00:08:45.679
我們都有去做比較

00:08:45.679 --> 00:08:46.840
那未來呢

00:08:46.840 --> 00:08:49.600
我們就是會不斷的再去做更好的模型

00:08:49.600 --> 00:08:51.580
也會做更好的研究

00:08:51.580 --> 00:08:54.200
然後目標就是要朝向GPT 4

00:08:57.480 --> 00:08:58.040
好

00:08:58.040 --> 00:09:03.700
那就來講一下我們所開源的這樣的資料集

00:09:03.700 --> 00:09:05.400
那這個資料集呢

00:09:05.400 --> 00:09:09.320
它最早就在這個去年的10月

00:09:09.320 --> 00:09:13.040
那目前已經迭代版本到了第二個版本

00:09:13.040 --> 00:09:18.040
那這個資料集裡面其中一個部分叫做TMMLU

00:09:18.840 --> 00:09:20.520
那這個TMMLU呢

00:09:20.520 --> 00:09:25.940
後續因為這個艾卡拉有看到這一塊的這個有一些不足之處

00:09:25.940 --> 00:09:30.500
所以他有把這個TMMLU再做一個跟版

00:09:30.500 --> 00:09:32.040
那其實做得非常的好

00:09:33.040 --> 00:09:33.520
好

00:09:33.520 --> 00:09:35.540
那我來講一下就是在這個資料集裡

00:09:35.540 --> 00:09:37.220
我們衡量了哪些東西

00:09:37.960 --> 00:09:41.780
我們那個時候去找了國外的評測方式

00:09:41.780 --> 00:09:48.280
那從國外的評測方式我們總結出有三個面向對於模型的評估

00:09:48.280 --> 00:09:49.860
第一個面向叫做Reason

00:09:50.500 --> 00:09:51.780
就是推論能力

00:09:52.559 --> 00:09:54.780
所謂的推論能力就是我的這個

00:09:55.980 --> 00:09:59.080
所有的這個內容都已經給你看了

00:09:59.080 --> 00:10:01.800
然後請你去推出一些東西

00:10:01.800 --> 00:10:03.900
譬如說今天算數學

00:10:03.900 --> 00:10:06.700
也算是一種推論能力的表現

00:10:06.700 --> 00:10:08.720
或者是今天我

00:10:09.559 --> 00:10:11.200
我給他一個表格

00:10:11.200 --> 00:10:13.080
然後請他去理解這個表格

00:10:13.080 --> 00:10:15.980
其實也算是一種這個推論能力

00:10:15.980 --> 00:10:19.780
也就是推論能力不牽涉到有跟知識有關

00:10:19.780 --> 00:10:24.200
而是推論到模型對於文字的理解能力

00:10:24.900 --> 00:10:26.600
那第二個部分就是Knowledge

00:10:26.600 --> 00:10:28.660
就是比較好理解就是知識

00:10:28.660 --> 00:10:31.200
就是要記的部分他有沒有辦法記得很好

00:10:32.280 --> 00:10:34.020
然後第三個部分就是

00:10:34.020 --> 00:10:34.980
我這些都不看

00:10:34.980 --> 00:10:37.620
我去看那個模型跟我互動的時候

00:10:37.620 --> 00:10:39.679
有沒有很好用

00:10:39.679 --> 00:10:41.480
有沒有對我有產生幫助

00:10:41.480 --> 00:10:43.179
因為大家喜歡用Chad GPT

00:10:43.179 --> 00:10:44.880
其實是因為他可以

00:10:44.880 --> 00:10:47.580
很細緻的幫你去處理

00:10:47.580 --> 00:10:51.559
一些很複雜的這個Quant

00:10:51.559 --> 00:10:54.800
所以這第三項看的就是Chad Behavior

00:10:55.360 --> 00:10:56.860
那從Reason的部分

00:10:56.860 --> 00:11:01.900
我們就發布了一個就是Penguin Table的這個資料集

00:11:01.900 --> 00:11:07.040
這個資料集就是在衡量這個表格的理解能力

00:11:07.040 --> 00:11:08.940
然後這個為什麼有一個契爾呢

00:11:08.940 --> 00:11:10.940
因為他那個題目裡面就是會有

00:11:11.760 --> 00:11:13.380
今天我契爾在這邊

00:11:13.380 --> 00:11:16.320
然後請你把我契爾移到第三行

00:11:16.320 --> 00:11:17.440
之類的題目

00:11:17.440 --> 00:11:19.240
所以那個整個表格的問題裡面

00:11:19.240 --> 00:11:21.380
就充斥了很多的契爾

00:11:21.380 --> 00:11:23.160
然後契爾叫John啊

00:11:23.160 --> 00:11:24.940
契爾叫Tom啊什麼之類的

00:11:25.580 --> 00:11:27.940
所以就是要做Penguin Table

00:11:29.359 --> 00:11:31.860
好那關於知識的部分呢

00:11:31.860 --> 00:11:33.160
我們有兩個資料集

00:11:33.160 --> 00:11:34.540
一個是TDQA

00:11:34.540 --> 00:11:35.580
一個是TML

00:11:36.700 --> 00:11:37.840
TDQA呢

00:11:37.840 --> 00:11:40.580
他就是一個台灣的算是常識問題

00:11:41.500 --> 00:11:44.580
問他這個台灣的最高三是哪個三

00:11:45.300 --> 00:11:46.740
之類的這種問題

00:11:46.740 --> 00:11:48.700
然後TML U plus呢

00:11:48.700 --> 00:11:50.080
就是比較專業的問題

00:11:50.080 --> 00:11:53.660
我們有時候收集了國家的考試

00:11:53.660 --> 00:11:56.059
我們收集國中的機策

00:11:56.059 --> 00:11:57.460
或者是學測

00:11:57.460 --> 00:12:00.440
或是高中的指考等等的題目

00:12:00.440 --> 00:12:02.820
然後放在這個裡面

00:12:03.579 --> 00:12:05.500
那這些reasoning跟knowledge

00:12:05.500 --> 00:12:07.880
這三個data set都是用選擇題的方法

00:12:07.880 --> 00:12:11.940
所以其實就是有點像讓模型去做考試

00:12:11.940 --> 00:12:13.500
就是我給一個問題之後

00:12:13.500 --> 00:12:14.720
給ABC的選項

00:12:14.720 --> 00:12:17.140
然後模型就是選到底哪一個答案

00:12:17.140 --> 00:12:18.700
他覺得是哪個答案

00:12:18.700 --> 00:12:20.679
然後用這樣的方法去來評量

00:12:20.679 --> 00:12:23.380
我們的模型的這個成效

00:12:23.859 --> 00:12:26.940
那最後一點呢就是這個chat behavior

00:12:26.940 --> 00:12:29.820
這個衡量其實蠻微妙的

00:12:30.880 --> 00:12:32.420
就是你今天想要衡量

00:12:32.420 --> 00:12:34.720
你的模型的控制能力

00:12:34.720 --> 00:12:36.679
其實你很難藉由

00:12:36.679 --> 00:12:39.620
像考試這種方法去控制

00:12:39.620 --> 00:12:40.520
你可以想像說

00:12:40.520 --> 00:12:42.860
今天考試其實

00:12:43.420 --> 00:12:47.420
只在考你某一些方面的技能

00:12:47.940 --> 00:12:50.360
但是他不能不太能衡量

00:12:50.360 --> 00:12:52.380
就是完整的衡量一個人

00:12:52.380 --> 00:12:54.320
或是一個模型

00:12:54.320 --> 00:12:56.780
所以我們現在什麼公司

00:12:56.780 --> 00:12:59.140
其實都還是用面試的方法

00:12:59.140 --> 00:13:00.920
所以大家可以理解就是說

00:13:00.920 --> 00:13:02.679
如果你想要看他的behavior

00:13:02.679 --> 00:13:04.000
你比較像是在面試

00:13:04.000 --> 00:13:05.920
不是在給他做比試

00:13:06.580 --> 00:13:08.520
那面試的最後一個問題是

00:13:08.520 --> 00:13:11.520
我給他出一些題目讓他作答

00:13:11.520 --> 00:13:13.720
但是作答的好或不好

00:13:13.720 --> 00:13:18.880
沒辦法用一個很容易的指標去做評斷

00:13:20.900 --> 00:13:24.200
所以最簡單的方法就是靠人去盲測

00:13:24.200 --> 00:13:27.000
比如說你給兩個回答

00:13:27.000 --> 00:13:29.160
然後讓人去做評量

00:13:30.839 --> 00:13:32.780
可是這樣就很花時間

00:13:32.780 --> 00:13:35.160
然後也很花能力

00:13:35.700 --> 00:13:39.160
所以我們就採取了國外常做的做法

00:13:39.160 --> 00:13:41.720
就直接拿我們現在最好的語言模型

00:13:41.720 --> 00:13:43.420
來當評判者

00:13:43.420 --> 00:13:47.080
所以我們就採用了GPD-4來當評判者

00:13:47.080 --> 00:13:48.820
當然你可以想像到說

00:13:48.820 --> 00:13:52.160
GPD-4應該會給自己回答的分數會高一點

00:13:55.099 --> 00:13:58.100
所以我們就從這個三個面向

00:13:58.100 --> 00:14:00.860
然後收集了四個資料集

00:14:00.860 --> 00:14:05.100
來完整的對模型的各個方面去做評量

00:14:07.160 --> 00:14:10.059
所以我們最近開源的Breeze 7B

00:14:10.059 --> 00:14:11.540
它是71參數

00:14:11.540 --> 00:14:13.500
然後它全部是免費的

00:14:13.500 --> 00:14:17.660
大家可以在這個Hacking Face的QR code

00:14:17.660 --> 00:14:20.280
就可以拿到我們的模型

00:14:20.280 --> 00:14:22.020
然後給大家掃一下

00:14:22.020 --> 00:14:24.540
今天這一場有很多QR code要掃

00:14:24.540 --> 00:14:26.820
所以大家手機就是拿出來

00:14:26.820 --> 00:14:28.260
隨時Standby

00:14:30.540 --> 00:14:35.640
我們的基礎模型是用Mitra的7B

00:14:35.640 --> 00:14:37.700
我們有去做持錶的擴充

00:14:37.700 --> 00:14:40.660
就是因為國外的模型

00:14:40.660 --> 00:14:45.000
它其實不太會對繁體中文的一些特性去做處理

00:14:45.000 --> 00:14:49.880
所以它對於中文的詞彙其實是納入了非常少的

00:14:49.880 --> 00:14:54.680
所以我們擴充從原本的29K擴充到62K

00:14:54.680 --> 00:14:56.680
其實足足扣升了一倍

00:14:58.739 --> 00:15:00.180
這樣擴充的結果是

00:15:00.180 --> 00:15:03.580
它的整個推論的速度會增加一倍

00:15:03.580 --> 00:15:06.360
以及它的整個有效的長度

00:15:06.360 --> 00:15:09.720
也會達到一萬個字這麼多

00:15:09.720 --> 00:15:12.100
這邊我大概會再講仔細一點

00:15:12.100 --> 00:15:14.380
先讓大家看幾個數字就好了

00:15:14.380 --> 00:15:15.660
然後另外剛才講到說

00:15:15.660 --> 00:15:19.320
我們Chain了650GB這麼多的資料

00:15:19.320 --> 00:15:22.640
去擴充我們的中文的能力

00:15:22.640 --> 00:15:27.800
然後整個來說我們GPU的時間

00:15:27.800 --> 00:15:31.640
達到7000這麼長的H100的時間

00:15:34.000 --> 00:15:38.760
接下來就是我們的大一點的VC8成器

00:15:38.760 --> 00:15:42.440
這個VC8成器我們現在正在開展

00:15:42.440 --> 00:15:44.680
關於它的商業模式

00:15:44.680 --> 00:15:48.640
待會我會跟大家分享我們的商業的佈局

00:15:49.940 --> 00:15:56.140
這個大一點的模型我們是採用Mixer 8x7B

00:15:56.140 --> 00:15:58.360
這個8x7B是什麼意思呢?

00:15:58.360 --> 00:16:02.100
是代表它是一個混合專家模型

00:16:02.100 --> 00:16:05.180
或者說Mixer of Asperger這樣的一個模型

00:16:05.180 --> 00:16:07.820
它有8個專家

00:16:07.820 --> 00:16:11.380
8個專家我會選2個來做使用

00:16:11.380 --> 00:16:15.640
每一個專家大概是7B的大小

00:16:17.960 --> 00:16:21.640
一樣的我們去做持錶的擴增

00:16:22.940 --> 00:16:26.200
最終的結果就是我們在台灣的知識方面

00:16:26.200 --> 00:16:28.080
就贏過了GPT 3.5

00:16:28.080 --> 00:16:29.720
其實也蠻容易想像得到

00:16:29.720 --> 00:16:32.640
因為我們Chain了非常多台灣的預料

00:16:34.080 --> 00:16:36.300
在模型的使用上

00:16:36.300 --> 00:16:38.040
Behaviour的控制力上面

00:16:38.040 --> 00:16:40.640
我們跟GPT 3.5是同等級的

00:16:42.960 --> 00:16:48.140
這邊其實也不一定全部都是電資的學生

00:16:48.140 --> 00:16:51.900
所以可能有人對於商業佈局會有興趣

00:16:51.900 --> 00:16:54.220
所以我就花點時間來講一下

00:16:54.220 --> 00:16:58.180
我們想要用Reasy這個8x7的模型

00:16:58.180 --> 00:17:00.640
去開展怎麼樣的商業

00:17:01.600 --> 00:17:04.240
首先我們作為一個研究院

00:17:04.240 --> 00:17:08.600
其實我們的目標就是產生更好的模型

00:17:08.600 --> 00:17:11.300
更好用、成效更好的模型

00:17:11.300 --> 00:17:15.820
所以我們走一個Model as Service這樣的方式

00:17:15.820 --> 00:17:18.600
也就是說我們的服務就是提供模型

00:17:20.900 --> 00:17:23.200
這個東西有誰要買呢?

00:17:23.260 --> 00:17:25.320
我們看到的是在這個市場上面

00:17:25.320 --> 00:17:32.480
其實有些公司對於資料安全是有一些疑慮的

00:17:32.480 --> 00:17:34.660
比如說如果是金融行業

00:17:34.660 --> 00:17:36.400
或者是政府機關

00:17:36.400 --> 00:17:41.140
或者是跟國防有比較相關的這些行業

00:17:41.140 --> 00:17:46.540
他們其實資料都不太能出他們自家的機器

00:17:46.540 --> 00:17:52.300
但是在這個公司裡面其實有很多文字的資料

00:17:52.300 --> 00:17:53.600
如果有一個語言模型

00:17:53.600 --> 00:17:59.940
其實對他們來說是可以幫他們節省蠻多時間的

00:17:59.940 --> 00:18:01.960
以及增加生產力

00:18:01.960 --> 00:18:03.800
所以我們看到這樣的需求

00:18:03.800 --> 00:18:06.940
就想說我們可以去打這樣的一個市場

00:18:06.940 --> 00:18:12.400
所以我們的Bleach 807想要走的市場就是這個地端的方案

00:18:12.400 --> 00:18:17.700
當然這些公司其實可以把模型安置在自己的家裡

00:18:17.700 --> 00:18:21.000
然後去做他的一些需求

00:18:21.000 --> 00:18:22.160
這麼一來的話

00:18:22.160 --> 00:18:25.800
他的資料不用出去他自家的機器以外

00:18:25.800 --> 00:18:29.359
他可以用語言模型來做到很多的幫忙

00:18:29.359 --> 00:18:31.619
也增加他們的生產力

00:18:31.619 --> 00:18:36.619
當然我們還是想要維持一個專心在研究院的路上

00:18:37.400 --> 00:18:42.140
所以我們有跟其他的系統整合商去做合作

00:18:42.140 --> 00:18:47.619
讓系統整合商去使用我們的模型來去做業務的推展

00:18:51.560 --> 00:18:54.880
我們接下來進到比較技術的部分

00:18:54.880 --> 00:18:59.380
我們就先來看一下今天我們的語言模型

00:18:59.380 --> 00:19:02.380
是怎麼理解你的一句話的

00:19:03.100 --> 00:19:04.480
比如說這個句子

00:19:06.240 --> 00:19:10.060
我們怎麼讓這個模型來看這個句子呢

00:19:10.060 --> 00:19:13.780
我們通常會做一個步驟叫做Tokenization

00:19:13.780 --> 00:19:19.420
它會分成若干的這個詞的片段

00:19:19.420 --> 00:19:24.780
這支詞的片段每一個片段我都會給它一個Vector

00:19:24.780 --> 00:19:26.260
給它一個向量

00:19:26.260 --> 00:19:31.460
就是一些一堆的數值來表示這一個Token

00:19:31.460 --> 00:19:35.720
當然很重要的是在Transformer架構當中

00:19:35.720 --> 00:19:40.680
其實不具有位置的感知能力

00:19:40.680 --> 00:19:44.200
所以我們必須要提醒它現在在哪個位置

00:19:44.200 --> 00:19:48.080
所以我們會加一個Positional Embedding去給它

00:19:48.080 --> 00:19:54.100
最後把它合在一起就是我們輸進去模型的這個Token

00:19:54.100 --> 00:19:57.100
Token Embedding Sequence

00:19:57.900 --> 00:19:59.980
那為什麼要講這個呢

00:19:59.980 --> 00:20:03.040
我們想要講其實是Tokenization這一步

00:20:03.040 --> 00:20:08.960
我們通常在語言模型現在採用的Tokenization叫做BPE

00:20:08.960 --> 00:20:13.100
那它是Bipare Encoding這樣的一個簡稱

00:20:14.140 --> 00:20:17.920
那這種Tokenization的方法它是怎麼做呢

00:20:17.920 --> 00:20:21.700
顧名思義其實它是從Byte開始做起

00:20:22.400 --> 00:20:28.900
那藉由Byte去展開我們原本的這個文字

00:20:28.900 --> 00:20:34.100
並且我們用一些詞表去把這些Byte做Merge

00:20:34.100 --> 00:20:37.460
那我想用一個例子來讓大家理解這件事情

00:20:37.460 --> 00:20:42.680
比如說今天有一個英文Milk還有一個中文牛奶

00:20:43.520 --> 00:20:47.040
在機器裡面去理解這一個句子的時候

00:20:47.040 --> 00:20:48.660
它是用Byte來表示

00:20:48.660 --> 00:20:52.020
所以我們把它Byte給它Show出來給大家看

00:20:52.020 --> 00:20:53.580
就像這個樣子

00:20:53.580 --> 00:20:55.660
大家有沒有特別注意到

00:20:55.660 --> 00:21:01.100
中文是由3個Byte來表示一個中文

00:21:01.100 --> 00:21:02.660
應該可以有看到嘛

00:21:03.420 --> 00:21:05.580
那其實在大部分的中文來說

00:21:05.580 --> 00:21:09.760
都是用3個Byte來表示一個中文字

00:21:09.760 --> 00:21:10.660
那今天呢

00:21:11.340 --> 00:21:14.800
我們如果把每一個Byte當作一個Token來做的時候

00:21:14.800 --> 00:21:16.540
就會出現一個問題是

00:21:17.460 --> 00:21:21.500
它會用3個Token來表示牛這個字

00:21:21.500 --> 00:21:26.560
但是這3個Token其實它只是在機器裡面的Index的順序而已

00:21:26.560 --> 00:21:29.240
它其實並沒有意識

00:21:29.240 --> 00:21:33.020
它有意識的時候是它這3個要出現之後

00:21:33.020 --> 00:21:35.780
它才會有它的這個語意

00:21:35.780 --> 00:21:38.060
所以這件事是非常奇怪的事情

00:21:39.120 --> 00:21:40.859
所以一般來說

00:21:40.859 --> 00:21:45.420
在英文上你用Milk這樣一個一個Character放進去

00:21:45.420 --> 00:21:47.420
其實也是沒有什麼樣的語意的

00:21:47.960 --> 00:21:49.400
所以會做一件事情就是

00:21:49.400 --> 00:21:52.460
我們會做所謂的詞表的Merge

00:21:52.460 --> 00:21:54.520
就是我去查表格

00:21:54.520 --> 00:21:57.560
那表格裡面如果這3個Token是黏在一起的

00:21:57.560 --> 00:21:58.500
就把它黏在一起

00:21:58.500 --> 00:22:00.300
當作一個Token來表示

00:22:00.300 --> 00:22:05.480
所以在英文有做特別的這個詞表之下

00:22:05.480 --> 00:22:07.340
你可以看到ILK

00:22:07.340 --> 00:22:09.320
它就不是分散成3個Token

00:22:09.320 --> 00:22:11.320
它被合成一個Token

00:22:11.320 --> 00:22:15.320
但是如果沒有對於中文詞表去做特別處理之下

00:22:15.900 --> 00:22:18.300
你的牛就會有3個Token來表示

00:22:18.300 --> 00:22:21.200
你的奶就會有3個Token來表示

00:22:21.200 --> 00:22:23.320
所以這就造成一個問題是

00:22:23.320 --> 00:22:24.680
這一些Token

00:22:24.680 --> 00:22:27.400
比如說17這個Token

00:22:27.400 --> 00:22:30.320
其實不代表任何語意的意思

00:22:30.320 --> 00:22:35.220
它必須要17899B這個併在一起才有牛這個意思

00:22:35.220 --> 00:22:38.640
所以顯然是有點奇怪的

00:22:38.640 --> 00:22:42.960
所以我們就有對中文去做這個詞表的擴充

00:22:42.960 --> 00:22:46.359
所以牛就不會再是3個Token

00:22:46.359 --> 00:22:47.980
就是一個Token來表示

00:22:47.980 --> 00:22:51.000
奶也會變成一個Token來表示

00:22:51.000 --> 00:22:53.040
甚至牛來兩個字

00:22:53.040 --> 00:22:55.100
可以合成一個Token來表示

00:22:55.100 --> 00:22:57.840
那此時我們在表示這個中文的時候

00:22:57.840 --> 00:23:02.640
就更能考量到中文的語言的特性

00:23:05.100 --> 00:23:06.780
那製作Tokenization的部分

00:23:06.780 --> 00:23:08.420
因為我們剛才講出了這個問題

00:23:08.420 --> 00:23:12.720
所以我們會了解到我們為什麼需要做詞表擴充

00:23:13.359 --> 00:23:17.400
我們在訓練語言模型其實會走三個步驟

00:23:17.400 --> 00:23:20.240
第一個步驟叫做Pretending

00:23:20.240 --> 00:23:23.359
這個Pretending就是我是一個模型

00:23:23.359 --> 00:23:26.480
我讓它學習文字兼容

00:23:26.480 --> 00:23:29.380
然後用大量的資料去學習文字兼容之後

00:23:29.380 --> 00:23:34.780
它就變成是一個可以把文字補全的一個模型

00:23:34.780 --> 00:23:37.800
那你就可以拿來做文章的生成

00:23:37.800 --> 00:23:43.040
然後甚至因為它學了非常多網路上面的資料

00:23:43.040 --> 00:23:45.859
所以你給一些些有推論的時候

00:23:45.859 --> 00:23:48.780
它就會像人類一樣的去推論

00:23:49.359 --> 00:23:51.859
往下生成下面的文字

00:23:51.859 --> 00:23:55.820
所以你就會產生一個幻覺說這個好像會思考

00:23:55.820 --> 00:23:58.359
但它只是很會去估下一個文字

00:23:58.359 --> 00:24:05.060
因為它看完了很多網路上面的人類的使用文字的行為

00:24:05.060 --> 00:24:09.359
它就會展現出像人類的效應

00:24:10.700 --> 00:24:13.900
但是今天如果是一個文章的補全器

00:24:13.900 --> 00:24:16.220
其實不是那麼的好用

00:24:16.220 --> 00:24:22.900
所以我們稍稍把它的行為調整成一個像聊天機器人的行為

00:24:22.900 --> 00:24:25.580
所以我們通常會製作Supervise by Tony

00:24:25.580 --> 00:24:29.600
給它看一些例子說今天人類如果問這個問題

00:24:29.600 --> 00:24:31.880
機器會怎麼回答

00:24:31.880 --> 00:24:35.619
然後用這樣的示範去調整整個模型的行為

00:24:35.619 --> 00:24:39.280
讓它變成一個可以做聊天的功能

00:24:39.280 --> 00:24:41.140
那聊天如果品質不是很好

00:24:41.140 --> 00:24:45.580
我們還可以進一步用RHF或是DPO來讓

00:24:46.180 --> 00:24:51.040
Sharebot變得更符合人類喜歡的回答

00:24:51.040 --> 00:24:52.700
然後所以呢

00:24:52.700 --> 00:24:54.119
跳很快

00:24:54.119 --> 00:24:57.700
接下來在講說我們VC其實有採用了

00:24:58.540 --> 00:25:01.700
Mitral Aspir就是一個混合專家模型

00:25:03.000 --> 00:25:03.520
好

00:25:03.520 --> 00:25:07.760
在這個Machinery其實有一個叫做Scaling Load

00:25:07.760 --> 00:25:12.340
這個Scaling Load簡單來講就是這個模型的參數越多

00:25:12.340 --> 00:25:13.680
訓練資料越多

00:25:13.680 --> 00:25:15.020
然後成效者越好

00:25:15.020 --> 00:25:16.700
其實是非常容易想到的

00:25:17.340 --> 00:25:20.160
但是如果今天你的參數越多

00:25:20.160 --> 00:25:25.480
其實就越增加訓練跟使用上面的困難

00:25:25.480 --> 00:25:27.160
那如何解決呢

00:25:27.920 --> 00:25:29.900
有一個理論叫做樂透理論

00:25:29.900 --> 00:25:34.260
這個理論就是說今天我們在訓練原模型的時候

00:25:34.260 --> 00:25:37.640
需要很大量的參數

00:25:37.640 --> 00:25:38.520
為什麼呢

00:25:38.520 --> 00:25:43.400
是因為我們要讓它搜尋的範圍更廣一點

00:25:43.400 --> 00:25:46.520
然後在搜尋範圍更廣一點的狀況之下

00:25:46.520 --> 00:25:50.359
它比較容易找到一條比較好的路徑

00:25:50.359 --> 00:25:51.460
但是呢

00:25:51.460 --> 00:25:52.460
它找到路徑之後

00:25:52.460 --> 00:25:54.740
它其實就不需要這麼多的參數

00:25:54.740 --> 00:25:57.060
就表示那個路徑不需要那麼多的參數

00:25:57.060 --> 00:25:58.520
所以這個就是樂透理論

00:25:58.520 --> 00:26:01.660
就好像是我如果樂透買多一點

00:26:01.660 --> 00:26:05.840
我就能更容易抽到這個頭獎

00:26:05.840 --> 00:26:07.400
所以這意味著就是說

00:26:07.400 --> 00:26:09.800
今天模型被訓練完成的時候

00:26:09.800 --> 00:26:13.880
有很多的參數其實都可以被割捨掉

00:26:13.880 --> 00:26:16.359
然後在我們這個Machine Learning裡面的講法

00:26:16.359 --> 00:26:17.760
就叫做sparsity

00:26:17.760 --> 00:26:19.800
就是稀疏性

00:26:19.800 --> 00:26:22.240
所以我們的MOE的模型

00:26:22.240 --> 00:26:25.880
其實就可以提供在訓練的時候的這種稀疏性

00:26:26.420 --> 00:26:28.280
讓它不用在訓練完之後

00:26:28.280 --> 00:26:30.859
再想辦法去把參數拿掉

00:26:30.859 --> 00:26:32.020
而是在訓練的時候

00:26:32.020 --> 00:26:34.100
就可以讓它有一些稀疏性

00:26:34.100 --> 00:26:36.380
那怎麼做出這個稀疏性呢

00:26:36.380 --> 00:26:38.080
在這張圖有說明就是說

00:26:38.080 --> 00:26:41.380
今天我在模型的一個部分

00:26:41.380 --> 00:26:44.580
我做了一個導流器

00:26:44.580 --> 00:26:46.580
這個導流器它可以跟我說

00:26:46.580 --> 00:26:49.400
我要選哪一些Aspir

00:26:49.400 --> 00:26:50.840
就是哪些專家

00:26:50.840 --> 00:26:52.660
那我們通常在八成七的時候

00:26:52.660 --> 00:26:54.140
就會用八個專家

00:26:54.140 --> 00:26:56.380
然後去選其中的兩個來做使用

00:26:57.080 --> 00:26:57.960
那這麼一來

00:26:57.960 --> 00:27:01.380
我們就可以為這個模型增加它的這個

00:27:01.380 --> 00:27:02.380
可以讓它有sparsity

00:27:03.379 --> 00:27:04.700
那我們訓練完之後

00:27:04.700 --> 00:27:06.300
在不管在訓練的時候

00:27:06.300 --> 00:27:07.380
或者在推論的時候

00:27:07.940 --> 00:27:10.640
這樣的sparsity都可以讓我們的訓練速度

00:27:10.640 --> 00:27:11.600
變得更快

00:27:11.600 --> 00:27:13.760
因為我們不用把所有的參數

00:27:13.760 --> 00:27:15.640
都進行訓練跟使用

00:27:17.660 --> 00:27:20.400
好那接下來帶幾個demo

00:27:20.400 --> 00:27:22.260
就是我們Breezy的demo

00:27:22.260 --> 00:27:23.480
那我們剛才講到說

00:27:23.480 --> 00:27:25.400
我們有做持錶擴充

00:27:25.400 --> 00:27:26.740
那持錶擴充之後

00:27:27.680 --> 00:27:30.960
一個Token能表示中文的字眼變多了

00:27:30.960 --> 00:27:33.119
所以它其實速度就會加快

00:27:33.119 --> 00:27:34.280
所以你看我們的速度

00:27:34.280 --> 00:27:35.619
如果跟原本的模型來說

00:27:35.619 --> 00:27:37.640
是double的這個關係

00:27:38.280 --> 00:27:40.080
用這個表示一下

00:27:40.080 --> 00:27:47.000
這個感覺的速度的差異

00:27:47.000 --> 00:27:49.700
好那左邊是Mistral

00:27:49.700 --> 00:27:50.700
右邊就是我們Breezy

00:27:50.700 --> 00:27:51.780
所以你可以看到這個

00:27:51.780 --> 00:27:54.520
有一個很明顯的速度上的差異

00:27:54.520 --> 00:27:57.520
那源自於就是我們的持錶的擴充

00:27:58.359 --> 00:27:59.940
那這同時代表就是說

00:27:59.940 --> 00:28:02.500
我們今天模型部署到廠商那邊

00:28:02.500 --> 00:28:05.640
他們使用的成本是會下降一半的

00:28:06.960 --> 00:28:08.940
好那另外呢

00:28:08.940 --> 00:28:11.720
我們在這個台灣的知識上面的表現

00:28:11.720 --> 00:28:13.080
過去B3.5

00:28:13.080 --> 00:28:15.500
然後這邊有一些數據我就不細講

00:28:15.500 --> 00:28:17.340
那這些數據就是源自於我們的

00:28:17.340 --> 00:28:19.840
衡量的這個評測

00:28:19.840 --> 00:28:21.460
那這邊有一個demo就是

00:28:21.460 --> 00:28:24.660
今天在台灣的這個使用場域當中

00:28:24.660 --> 00:28:27.460
其實有一些專業的知識

00:28:27.460 --> 00:28:29.340
比如說在銀行當中呢

00:28:29.340 --> 00:28:33.320
它有一些關於洗錢防治的相關措施

00:28:33.320 --> 00:28:35.240
那如果去問一個

00:28:35.240 --> 00:28:38.620
不是很懂台灣專業的這樣的模型的話

00:28:38.620 --> 00:28:41.600
其實這題會產生很多的幻覺

00:28:41.600 --> 00:28:43.660
所以我們就來看一下那個

00:28:43.660 --> 00:28:45.160
我們Breezy的表現

00:28:45.160 --> 00:28:48.480
我們就問他這個要採取什麼樣的措施

00:28:48.480 --> 00:28:50.760
來防治洗錢

00:28:51.320 --> 00:28:52.920
那你看他提到一個非常

00:28:52.920 --> 00:28:57.320
台灣的銀行其實常用到的KYC的這個詞

00:28:59.280 --> 00:29:00.400
以及呢

00:29:00.400 --> 00:29:04.660
他有講到說要做這個員工培訓

00:29:04.660 --> 00:29:06.140
還有這邊蠻重要的

00:29:06.140 --> 00:29:09.360
資料導存要這個五年以上

00:29:09.360 --> 00:29:11.460
這個其實在如果待過銀行業

00:29:11.460 --> 00:29:13.180
就會知道這個東西

00:29:14.020 --> 00:29:15.360
然後另外呢

00:29:15.360 --> 00:29:19.100
他還點出了一個很重要的這個準則

00:29:19.100 --> 00:29:22.500
一個這個叫做FATF的準則

00:29:22.500 --> 00:29:23.780
所以你可以看到說

00:29:23.780 --> 00:29:26.180
我們的Breezy在這個台灣的知識上面

00:29:26.180 --> 00:29:28.180
其實表現非常好

00:29:28.180 --> 00:29:32.180
那原因當然就是因為我們訓練非常多台灣的文本

00:29:33.880 --> 00:29:35.280
好那另外呢

00:29:35.280 --> 00:29:36.940
就是除了知識方面

00:29:36.940 --> 00:29:40.380
其實使用者在使用原模型的時候

00:29:40.380 --> 00:29:43.480
也蠻在意他的這個操控能力的

00:29:43.480 --> 00:29:45.180
就是使用起來到底好不好用

00:29:45.700 --> 00:29:48.180
那所以我們在這個這個

00:29:48.700 --> 00:29:50.600
中文跟英文上面我們都

00:29:50.600 --> 00:29:52.540
就是有去做評測這件事情

00:29:52.540 --> 00:29:54.220
然後我們的這個效果是

00:29:54.220 --> 00:29:57.080
同等級的

00:29:57.080 --> 00:29:59.020
所以他可以幫助我們做一些

00:29:59.020 --> 00:30:01.220
比較複雜的商業的操作

00:30:01.880 --> 00:30:03.920
譬如說今天我一個例子是

00:30:03.920 --> 00:30:05.220
我請他扮演一個

00:30:07.280 --> 00:30:11.500
然後團隊想要實作一個站內的推薦系統

00:30:11.500 --> 00:30:12.680
然後請他思考一下

00:30:12.680 --> 00:30:15.720
如何幫助工程團隊來規劃時程

00:30:15.720 --> 00:30:18.940
並且最後用這個語法來表示甘特圖

00:30:18.940 --> 00:30:21.660
所以這是一個非常複雜的過程

00:30:21.660 --> 00:30:23.840
那我們可以看到我們的Breezy

00:30:23.840 --> 00:30:24.840
的表現

00:30:27.560 --> 00:30:30.720
那首先呢他有如我所這個

00:30:30.720 --> 00:30:33.840
這個命令的就是去做這個規劃

00:30:35.600 --> 00:30:37.240
他做完規劃之後呢

00:30:37.240 --> 00:30:40.840
他就開始用這個語法來生成這個

00:30:41.580 --> 00:30:42.840
甘特圖

00:30:50.620 --> 00:30:52.840
好那生成完了甘特圖之後呢

00:30:53.080 --> 00:30:56.080
我們就把這段程式碼把它複製起來

00:31:00.740 --> 00:31:04.080
然後貼到那個可以顯示甘特圖的網站

00:31:06.760 --> 00:31:09.800
好就看到這個是Breezy為我們的PM

00:31:09.800 --> 00:31:12.260
所展示的這個甘特圖

00:31:12.260 --> 00:31:14.420
所以這樣的模型呢

00:31:14.420 --> 00:31:16.080
他的這個操控能力

00:31:16.660 --> 00:31:19.080
足夠讓我們在商業上面可以做使用

00:31:20.480 --> 00:31:22.080
好那接下來呢

00:31:22.080 --> 00:31:24.680
有RAG跟Long Context的部分

00:31:24.680 --> 00:31:32.940
就由我們的Jeff來為大家介紹

00:31:32.940 --> 00:31:34.500
好謝謝YC

00:31:34.500 --> 00:31:35.180
我是Jeff

00:31:35.180 --> 00:31:38.620
那接下來就由我來介紹RAG跟Long Context

00:31:38.620 --> 00:31:40.460
那RAG就是

00:31:40.460 --> 00:31:43.440
在這個商業情景

00:31:43.440 --> 00:31:45.760
下是原模型

00:31:45.760 --> 00:31:47.460
很重要的一環

00:31:47.460 --> 00:31:50.260
因為就是如果能夠對Document去做

00:31:50.260 --> 00:31:52.900
問答能夠去萃取裡面的內容

00:31:52.900 --> 00:31:54.260
或是去整理

00:31:54.840 --> 00:31:55.960
整理出一個Summary的話

00:31:55.960 --> 00:31:57.920
會對我們去快速

00:31:57.920 --> 00:32:01.300
瀏覽這些Document是有很大的幫助

00:32:01.300 --> 00:32:04.720
那RAG的架構就如這張圖所顯示的

00:32:04.720 --> 00:32:06.260
就是可能你要有一個

00:32:06.860 --> 00:32:08.100
很大的Database

00:32:08.100 --> 00:32:10.260
那就要從裡面去選擇

00:32:10.780 --> 00:32:12.640
數個相關的Document

00:32:12.640 --> 00:32:14.220
去併到

00:32:14.220 --> 00:32:16.640
Large Language Model的Context裡面

00:32:16.640 --> 00:32:18.520
再用Prompt的方式去

00:32:18.520 --> 00:32:21.520
會依著這個Context去回答問題

00:32:24.180 --> 00:32:27.980
所以在RAG的Retrieval要做的事情就是

00:32:27.980 --> 00:32:31.020
可能要從一個100萬筆的Database

00:32:31.020 --> 00:32:34.520
去選出3到5筆相關的內容

00:32:35.720 --> 00:32:37.700
那在做這件事情的時候

00:32:37.700 --> 00:32:39.800
通常會有一個

00:32:39.800 --> 00:32:40.640
Intermediate step

00:32:40.640 --> 00:32:42.380
會先去選出

00:32:42.380 --> 00:32:43.960
100個

00:32:44.560 --> 00:32:45.880
比較接近的內容

00:32:45.880 --> 00:32:47.940
最後再用Re-ranking的方式

00:32:47.940 --> 00:32:50.160
去篩出最後的3到5筆

00:32:50.160 --> 00:32:53.040
這樣子能夠提升最後的成效

00:32:53.040 --> 00:32:55.880
那這兩個篩選方式有什麼不同呢

00:32:56.440 --> 00:32:59.240
一種方式通常是使用By Encoder

00:32:59.240 --> 00:33:01.220
那第二種方式是Re-ranker

00:33:01.220 --> 00:33:02.840
那這兩個本質上的差別

00:33:02.840 --> 00:33:06.180
可以看到它的推進的過程

00:33:06.180 --> 00:33:08.420
在By Encoder裡面

00:33:09.020 --> 00:33:11.080
Query是轉成Embedding

00:33:11.080 --> 00:33:12.940
然後Document也轉成Embedding之後

00:33:12.940 --> 00:33:14.820
兩者之間算了一個分數

00:33:14.820 --> 00:33:17.540
那Re-ranker則是透過模型

00:33:17.540 --> 00:33:21.500
直接對Query跟Document的Pair

00:33:21.500 --> 00:33:23.680
來去做評價去算分數

00:33:23.680 --> 00:33:26.380
那這樣的差異其實是蠻巨大的

00:33:26.380 --> 00:33:31.100
因為當By Encoder可以分開處理兩者的時候

00:33:31.100 --> 00:33:35.500
Document的Embedding都可以事先做好

00:33:35.500 --> 00:33:39.280
所以我可以快速的去篩選出

00:33:39.280 --> 00:33:41.360
用By Encoder去篩選出結果

00:33:41.360 --> 00:33:43.600
那最後的Re-ranker則會比較花時間

00:33:43.600 --> 00:33:46.600
那以實際上數字的

00:33:47.820 --> 00:33:49.360
實際上花的時間

00:33:49.360 --> 00:33:51.560
我有查到一篇資料是說

00:33:51.560 --> 00:33:54.920
在一個四千萬的Database裡面

00:33:54.920 --> 00:34:00.060
如果你是用By Encoder去選出前面的幾筆的話

00:34:00.060 --> 00:34:02.460
大概就是小於100毫秒就可以完成

00:34:02.460 --> 00:34:04.940
可是如果你要用Re-ranker

00:34:04.940 --> 00:34:07.360
以一個很小的模型Bird來說

00:34:07.360 --> 00:34:09.620
光用Bird來去Re-rank

00:34:09.620 --> 00:34:14.860
你只要把整個四千萬的Document

00:34:14.860 --> 00:34:16.500
跟你的Query相關

00:34:16.500 --> 00:34:19.360
你就要花五十個小時才能夠

00:34:19.360 --> 00:34:21.540
算完一筆Query最好的結果

00:34:21.540 --> 00:34:23.080
所以這樣做法是不實際的

00:34:23.080 --> 00:34:25.800
所以我們會希望有這個

00:34:25.800 --> 00:34:27.620
Two Stage的approach

00:34:29.440 --> 00:34:32.280
那在RAG的Generation裡面

00:34:32.280 --> 00:34:34.880
我們最關注的問題是Halucination

00:34:34.880 --> 00:34:37.000
因為Halucination就會導致

00:34:38.799 --> 00:34:41.000
它的提供的解答是不可信的

00:34:42.020 --> 00:34:43.020
所以解決Halucination

00:34:43.020 --> 00:34:45.180
是RAG裡面很重要的一環

00:34:45.180 --> 00:34:47.340
那解決的方法大部分都是

00:34:47.340 --> 00:34:50.620
依著Chain of Thought的方式去實現

00:34:50.620 --> 00:34:52.320
Chain of Thought就是一個

00:34:52.320 --> 00:34:54.360
請語言模型在回答問題的時候

00:34:54.360 --> 00:34:58.620
也要把思路歷程去輸出出來

00:34:58.620 --> 00:35:01.440
那在語言模型輸出思路歷程的過程中

00:35:01.440 --> 00:35:08.239
它就能夠對於文章也有進一步的理解反思

00:35:08.239 --> 00:35:13.340
那它最終的結果就會比較接近真實的情境

00:35:13.340 --> 00:35:15.920
那Chain of Thought也有演變出很多的變體

00:35:15.920 --> 00:35:17.739
譬如說Chain of Verification

00:35:17.739 --> 00:35:20.400
Chain of Verification是要求模型

00:35:20.400 --> 00:35:24.020
先萃取出裡面確定的知識之後

00:35:24.020 --> 00:35:27.120
要一步一步從這個知識推導成

00:35:27.120 --> 00:35:31.260
可以被Inference的其他的敘述

00:35:31.260 --> 00:35:34.620
那在產生很多都是正確的敘述之後

00:35:34.620 --> 00:35:38.440
再去回答就能夠比較答得對這樣

00:35:38.440 --> 00:35:41.480
那Chain of Note則是另一種做法是

00:35:42.060 --> 00:35:45.000
希望模型先去做筆記這樣子

00:35:45.000 --> 00:35:48.480
它就是引入各個不同的Note Pad

00:35:48.480 --> 00:35:52.300
去讓模型對於文章先做各式的總結

00:35:52.300 --> 00:35:54.440
那之後再可以依著這些總結

00:35:54.440 --> 00:35:55.880
去產生最後的結果

00:35:57.120 --> 00:36:00.180
那所以這個在REG裡面

00:36:00.180 --> 00:36:04.760
Generation的成效是一個很好的研究的方向

00:36:04.760 --> 00:36:08.420
那如果希望對這件事情

00:36:08.420 --> 00:36:10.980
Prompting去做調整的話

00:36:10.980 --> 00:36:15.840
最重要的是它的Prompt需要是比較General的寫法

00:36:15.840 --> 00:36:20.160
因為在這個REG情境是講求非常高的Recall

00:36:20.160 --> 00:36:22.500
意思就是說如果

00:36:22.500 --> 00:36:24.120
如果有一個Prompt

00:36:24.120 --> 00:36:25.840
它針對某些情境可以Work

00:36:25.840 --> 00:36:27.840
某些情境不能Work的話

00:36:27.840 --> 00:36:30.400
那這樣子它很容易壞掉

00:36:30.400 --> 00:36:33.080
還要去找出一個Fallback的解答

00:36:33.799 --> 00:36:35.160
所以在Prompting的時候

00:36:35.160 --> 00:36:36.980
最好是適用於每一個問題

00:36:36.980 --> 00:36:40.120
它都能夠按照同樣的流程去做回答

00:36:40.120 --> 00:36:43.820
這樣子才會有一個比較好的REG系統

00:36:43.820 --> 00:36:46.739
那在想這樣Prompt的過程中

00:36:46.739 --> 00:36:50.719
很好的一個方向是去以時間來換取準確度

00:36:50.719 --> 00:36:52.660
因為像Chain of Thought的模式就是

00:36:52.660 --> 00:36:54.700
希望語言模型不要直接回答

00:36:54.700 --> 00:36:56.580
要先思考過後再回答

00:36:56.580 --> 00:37:00.200
那當然只要有思考就會有合力度的問題

00:37:00.200 --> 00:37:01.300
所以你可以

00:37:01.300 --> 00:37:03.120
你有不同層次的思考

00:37:03.120 --> 00:37:04.700
所以只要想說

00:37:05.420 --> 00:37:09.120
怎麼樣去讓這個思考的邏輯再更整理一點

00:37:09.120 --> 00:37:12.920
就有辦法去提升REG的成效

00:37:12.920 --> 00:37:15.640
那當然也可以考慮

00:37:15.640 --> 00:37:18.480
就是以訓練的方式來去達成這件事情

00:37:18.480 --> 00:37:22.000
因為如果能夠產生出一個好的

00:37:22.000 --> 00:37:24.660
Input Output的Formulation的話

00:37:24.660 --> 00:37:27.620
你可以把這個思考模式訓練到語言模型中

00:37:27.620 --> 00:37:29.120
或許它本來不會

00:37:29.120 --> 00:37:31.300
只是因為它不知道要這樣子去做

00:37:31.300 --> 00:37:33.340
但是透過資料訓練之後

00:37:33.340 --> 00:37:36.380
以一個更好的思考模式去回答

00:37:36.380 --> 00:37:41.300
它學會它就可以在REG上面有更好的表現

00:37:41.300 --> 00:37:44.300
那這個是我們利用達哥平台

00:37:44.300 --> 00:37:47.800
來展示Brixie REG的結果

00:37:48.620 --> 00:37:54.080
可以看到我們先引入了一個履歷的Example

00:37:54.080 --> 00:37:56.180
這裡面就是有很多的履歷

00:37:56.180 --> 00:37:58.800
有各式各樣不同的背景等等

00:37:59.360 --> 00:38:01.360
那它是一個PDF的格式

00:38:01.360 --> 00:38:03.680
我們把它輸入到系統之後

00:38:03.680 --> 00:38:06.820
會有一個PDF Partial去處理這些變成文字

00:38:06.820 --> 00:38:09.640
接下來我們就可以對這個PDF去問問題

00:38:09.640 --> 00:38:13.100
那它就可以推薦一個合適的專案經理

00:38:13.100 --> 00:38:16.040
來進行商品規劃跟商務發展

00:38:16.040 --> 00:38:17.540
並且請它說明原因

00:38:17.540 --> 00:38:19.140
而且還要整理成表格

00:38:19.880 --> 00:38:21.580
透過這個REG系統

00:38:21.580 --> 00:38:24.520
Brixie就有辦法去達到這個任務

00:38:24.520 --> 00:38:27.040
可以看到它有列出各個不同的Sample

00:38:27.040 --> 00:38:29.320
然後它的優勢是什麼

00:38:33.279 --> 00:38:35.380
接下來是Long Context的部分

00:38:35.380 --> 00:38:38.320
Long Context也是蠻重要的一個

00:38:38.320 --> 00:38:39.900
語言模型的改進的方法

00:38:39.900 --> 00:38:41.840
因為有了Long Context之後

00:38:41.840 --> 00:38:46.060
我們就可以對文件等級的

00:38:46.060 --> 00:38:49.219
出入去做更好的understanding

00:38:49.219 --> 00:38:51.400
所以我們就做了

00:38:51.400 --> 00:38:55.260
從8K延長到32K的Brixie跟Brixie

00:38:55.260 --> 00:38:56.640
Brixie的部分也是一樣

00:38:56.640 --> 00:38:59.300
有開源在Honeyface上

00:38:59.300 --> 00:39:01.739
這個32K到底是多長呢

00:39:01.739 --> 00:39:05.280
其實它就是差不多40K

00:39:05.280 --> 00:39:07.620
4萬個中文字

00:39:07.620 --> 00:39:08.840
所以其實是可以

00:39:08.840 --> 00:39:13.020
吃下很多正常大小的文件

00:39:13.020 --> 00:39:14.580
我們在Long Context裡面

00:39:14.580 --> 00:39:16.520
做了兩件事情

00:39:16.520 --> 00:39:18.800
第一件事情是我們把它的Base

00:39:18.800 --> 00:39:20.840
從1萬scale到100萬

00:39:21.460 --> 00:39:23.840
這個Base其實它就是裡面

00:39:24.380 --> 00:39:26.840
embedding的一個Zeta

00:39:26.840 --> 00:39:29.460
影響它旋轉角度的一個值

00:39:29.460 --> 00:39:31.260
這個後面會再細講

00:39:31.260 --> 00:39:32.739
我們改了這個Base之後

00:39:32.739 --> 00:39:35.840
我們就拿長的Data來去訓練它

00:39:35.840 --> 00:39:38.440
長的Data有中文、英文

00:39:38.440 --> 00:39:40.840
還有AirData跟Code這樣

00:39:44.520 --> 00:39:46.620
要講這個Base scaling之前

00:39:46.620 --> 00:39:48.380
就必須要再更細緻的講

00:39:48.380 --> 00:39:49.900
Position Encoding

00:39:49.900 --> 00:39:52.120
Position Encoding就是一種

00:39:52.120 --> 00:39:55.840
可以去讓模型知道位置關係的一種方法

00:39:57.160 --> 00:40:00.020
以一個很簡單的想法來講

00:40:00.020 --> 00:40:01.880
如果我有一個Sign的函數

00:40:01.880 --> 00:40:08.960
在不同的X的位置去選到Sign的這個值

00:40:08.960 --> 00:40:11.600
我就可以透過Sign值之間的差異

00:40:11.600 --> 00:40:16.739
來去決定這兩個字之間的距離到底是多遠的

00:40:16.739 --> 00:40:19.620
可是如果這樣子做會有一個問題是

00:40:19.620 --> 00:40:21.180
它是一個週期函數

00:40:21.180 --> 00:40:24.340
所以在長度的維度下

00:40:24.340 --> 00:40:26.700
會遇到相同重複的值

00:40:26.700 --> 00:40:28.280
所以遇到重複的值的時候

00:40:28.280 --> 00:40:30.520
就無法知道它到底是在

00:40:30.520 --> 00:40:33.239
靠近0的位置還是其實它是靠近8192

00:40:33.239 --> 00:40:35.520
只是剛好值是一樣的

00:40:36.700 --> 00:40:37.880
那另外一種想法是

00:40:37.880 --> 00:40:40.340
那我可以把它的週期變得非常長

00:40:40.340 --> 00:40:42.580
如果把週期變得非常長的話

00:40:42.580 --> 00:40:45.560
那它每一個點的值都會不一樣

00:40:45.560 --> 00:40:48.280
那就有辦法去合理化這件事情

00:40:48.280 --> 00:40:51.020
可是這樣的問題是太近的值

00:40:51.759 --> 00:40:55.380
如果我要知道距離是1跟距離是2的差別

00:40:55.380 --> 00:40:56.840
值會非常的靠近

00:40:56.840 --> 00:40:59.739
會很難以辨識兩者的差異

00:40:59.739 --> 00:41:02.940
所以在做法上就是引入各個不同的週期

00:41:02.940 --> 00:41:05.840
都會納進來考慮

00:41:05.840 --> 00:41:08.060
那如此一來我就可以透過

00:41:08.060 --> 00:41:11.560
在不同頻率的位置

00:41:11.560 --> 00:41:13.739
就可以知道這兩個字到底是短的

00:41:14.819 --> 00:41:15.739
還是中的

00:41:16.660 --> 00:41:19.739
或是它是其實這兩個字是距離很遠的

00:41:22.400 --> 00:41:24.400
那在base等於

00:41:24.400 --> 00:41:26.200
本來的模型是base等於1萬

00:41:26.200 --> 00:41:28.219
其實在這個base等於1萬的情況下

00:41:28.219 --> 00:41:32.520
它的週期就足以去涵蓋到3萬2的長度

00:41:32.520 --> 00:41:35.560
所以理論上是不需要再做任何的調整

00:41:35.560 --> 00:41:38.800
可是實務上這個是沒有辦法達成的

00:41:38.800 --> 00:41:40.739
因為當你訓練在小的

00:41:40.739 --> 00:41:42.719
當訓練在8000的

00:41:42.719 --> 00:41:45.080
模型只訓練在8000的context links的時候

00:41:45.080 --> 00:41:48.300
它generalize到長的能力就不見了

00:41:48.300 --> 00:41:50.020
那可以看到這張表是

00:41:50.020 --> 00:41:51.620
不過這張是lama1

00:41:51.620 --> 00:41:54.840
它只有訓練在2048的context window

00:41:54.840 --> 00:42:00.800
那可以發現到它在evaluate在更長的context window的時候

00:42:00.800 --> 00:42:02.860
perplexity就急劇的上升

00:42:02.860 --> 00:42:05.200
那perplexity就可以想像是

00:42:05.200 --> 00:42:08.560
模型針對這個去值的合理度來做評價

00:42:08.560 --> 00:42:10.600
那越低的話就是越合理

00:42:10.600 --> 00:42:14.760
那它如果長度一超過這個預訓練的值的時候

00:42:14.760 --> 00:42:17.160
它就會perplexity激增

00:42:17.160 --> 00:42:19.600
就代表說模型就不再覺得它是合理了

00:42:19.600 --> 00:42:21.580
那模型不再覺得它是合理的情況下

00:42:21.580 --> 00:42:23.840
這樣的輸入就沒有辦法

00:42:23.840 --> 00:42:27.840
它就沒辦法針對文章正確的輸出

00:42:28.940 --> 00:42:30.540
那右邊這張

00:42:30.540 --> 00:42:36.280
右下角這張圖是針對base scaling的一些研究

00:42:36.280 --> 00:42:39.360
那它的主要的理論就是說

00:42:39.360 --> 00:42:41.860
在有base scaling的情況下

00:42:41.860 --> 00:42:44.700
有一些維度的positional encoding可以

00:42:44.700 --> 00:42:47.700
好像是在8000長度的時候看過

00:42:47.700 --> 00:42:51.560
所以它就會有從8000有點放大到64000的感覺

00:42:51.560 --> 00:42:53.560
所以在訓練上會比較容易

00:42:53.560 --> 00:42:56.219
就是對base scaling做的一個解釋

00:42:56.219 --> 00:42:58.160
那事實上很多的其他的模型

00:42:58.860 --> 00:43:01.300
在延長到更長的時候也會做base scaling

00:43:01.300 --> 00:43:06.239
所以我們就依序著之前的work也做了同樣的事情

00:43:07.580 --> 00:43:09.800
那long context要怎麼evaluate呢

00:43:09.800 --> 00:43:13.200
有一個toy case是Gemina也有去測試的

00:43:13.200 --> 00:43:14.640
叫做passkey retrieval

00:43:14.640 --> 00:43:16.940
passkey retrieval這個任務非常簡單

00:43:16.940 --> 00:43:19.780
它就是一段一直重複的文章

00:43:19.780 --> 00:43:21.560
The sky is blue, the grass is green等等的

00:43:21.760 --> 00:43:23.480
然後中間就藏了一個key

00:43:23.480 --> 00:43:25.620
一個key就是大概五個字元

00:43:25.620 --> 00:43:27.760
那它就一直重複這一段去

00:43:28.840 --> 00:43:30.760
達到它context length的長度

00:43:31.300 --> 00:43:34.940
那這個對於人類來說非常簡單的問題

00:43:34.940 --> 00:43:37.600
最後就是要retrieve它的key是什麼

00:43:37.600 --> 00:43:41.040
那這個對於人類來說很簡單的問題呢

00:43:41.040 --> 00:43:45.860
語言模型其實達的不算到完美

00:43:45.860 --> 00:43:48.180
可以看到說Breeze 我們Breeze模型

00:43:48.180 --> 00:43:50.840
其實在大部分的情況下都是綠的

00:43:50.840 --> 00:43:53.660
就是都有超過百分之八十的證據

00:43:53.660 --> 00:43:56.640
可是也就代表說還是會有一些case

00:43:56.640 --> 00:44:00.860
它是沒有辦法知道在context中的key是哪裡

00:44:00.860 --> 00:44:03.900
所以這是long context的一個問題

00:44:03.900 --> 00:44:05.800
在context增加的情況下

00:44:05.800 --> 00:44:09.200
其實是要retrieve到正確的答案

00:44:09.200 --> 00:44:10.680
是還是會有一點困難的

00:44:10.680 --> 00:44:13.840
不是跟它短的時候是一模一樣的

00:44:15.400 --> 00:44:18.980
那有人就針對這個任務再去擴增

00:44:18.980 --> 00:44:22.380
因為這個任務對於有一些模型來說都已經封頂了

00:44:22.380 --> 00:44:25.900
所以再去把它加到更難的方法

00:44:25.900 --> 00:44:27.540
那更難的方法主要有兩種

00:44:27.540 --> 00:44:29.380
第一種就是retrieve number

00:44:29.380 --> 00:44:33.800
就是我把5個digit的key改成一個十位數的數字

00:44:33.800 --> 00:44:35.739
然後接下來再更難一點呢

00:44:35.739 --> 00:44:38.380
是我直接裡面有一個kv pair

00:44:38.380 --> 00:44:39.860
就是有一個鑰匙

00:44:39.860 --> 00:44:41.860
然後鑰匙會找到一個值

00:44:41.860 --> 00:44:45.120
那這個鑰匙跟值大概都是20個位元

00:44:45.120 --> 00:44:47.120
那可以發現到說

00:44:48.100 --> 00:44:50.620
即便是這樣子非常微小的調整

00:44:50.620 --> 00:44:52.600
理論上應該還是很簡單的任務

00:44:52.600 --> 00:44:54.580
但是就已經有模型

00:44:54.580 --> 00:44:56.880
在後面的任務就已經不太行了

00:44:56.880 --> 00:44:59.460
那在retrieve kv上面

00:44:59.460 --> 00:45:07.239
像cloud2就沒有到很好的retrieve的準確率

00:45:07.239 --> 00:45:10.120
所以這也是需要改進的方向

00:45:11.280 --> 00:45:15.719
那這個是我們用bricksy32k做的一個demo

00:45:15.719 --> 00:45:18.460
那它可以讀下整本的小王子

00:45:18.460 --> 00:45:20.480
再去裡面做問答

00:45:20.480 --> 00:45:22.300
可以看到這是我們的輸入

00:45:22.820 --> 00:45:25.300
那這邊輸入只有一部分

00:45:26.020 --> 00:45:27.960
所以答案是在最上面

00:45:27.960 --> 00:45:32.320
就是有一本真實的故事

00:45:32.320 --> 00:45:34.280
那可以看到這個滑

00:45:34.280 --> 00:45:35.360
是要滑蠻久的

00:45:35.360 --> 00:45:38.520
因為它是一個蠻長的梳子

00:45:38.520 --> 00:45:40.580
那選到最下面之後

00:45:40.580 --> 00:45:45.820
我們就會問它一個關於第一章的問題

00:45:45.820 --> 00:45:48.520
稍微給它轉一下

00:45:53.160 --> 00:45:56.200
那這個它看了這麼長的context之後

00:45:56.200 --> 00:45:59.620
它還是能夠正確的回答這樣的問題

00:45:59.620 --> 00:46:04.540
所以就代表它有對於長文的整個通盤

00:46:04.540 --> 00:46:09.540
去整個位置都能夠attend這個能力

00:46:15.380 --> 00:46:18.520
好那另外最後講一個

00:46:18.520 --> 00:46:20.480
也是有被發現的現象

00:46:20.480 --> 00:46:21.700
叫做lost in the middle

00:46:21.700 --> 00:46:24.300
就是在這個長文的情況下

00:46:24.300 --> 00:46:27.600
其實在各個位置上面

00:46:27.600 --> 00:46:29.840
正確答案在各個不同位置上面

00:46:29.840 --> 00:46:32.260
是對模型有不同的難度的

00:46:32.260 --> 00:46:34.080
比如說如果是放在最前面

00:46:34.080 --> 00:46:36.000
其實模型很容易看得到

00:46:36.000 --> 00:46:38.880
如果是放在偏後面一點模型

00:46:38.880 --> 00:46:40.080
也蠻容易答對

00:46:40.080 --> 00:46:42.340
可是在中間的情況下

00:46:42.340 --> 00:46:45.440
可以看到中間這邊低於紅線這部分

00:46:45.440 --> 00:46:50.560
如果是放到5到15位的位置的話

00:46:50.560 --> 00:46:54.180
它的accuracy就會驟降

00:46:54.180 --> 00:46:58.080
那這個也是之後可以來改進的方向

00:46:59.080 --> 00:47:01.780
好那這就是上半場的全部內容

00:47:01.780 --> 00:47:15.540
那現在進到Q&A時間

00:47:16.100 --> 00:47:17.739
請教一下張宇哥

00:47:18.540 --> 00:47:21.160
那個長window那個roadblock打開之後

00:47:21.160 --> 00:47:22.620
它那個lost in the middle

00:47:22.620 --> 00:47:24.760
那兩件事情是

00:47:26.540 --> 00:47:28.480
好像提到這個好像沒繼續講

00:47:29.239 --> 00:47:31.000
那個是future roadblock還是

00:47:31.000 --> 00:47:34.380
我只是要提說就是在這個

00:47:34.380 --> 00:47:36.340
當放很多文件的時候

00:47:36.340 --> 00:47:39.580
文件的位置會影響到正確答案

00:47:39.580 --> 00:47:40.340
對對對

00:47:40.340 --> 00:47:43.100
那如果用roadblock給它打開之後呢

00:47:43.100 --> 00:47:46.000
那它還是attend的位置還是會

00:47:47.640 --> 00:47:50.460
就是把那個long content給它打開之後

00:47:51.300 --> 00:47:53.020
那這件事情

00:47:53.740 --> 00:47:56.820
我想知道它能不能回覆說

00:47:56.820 --> 00:47:59.000
這麼長的文章裡面

00:47:59.000 --> 00:48:01.000
中間那個部分的東西之類的

00:48:04.200 --> 00:48:06.000
這好奇喔

00:48:07.880 --> 00:48:11.140
從我們passkey retrieval上面看的話

00:48:11.140 --> 00:48:12.960
是它的

00:48:12.960 --> 00:48:15.300
它能夠在無論key是在哪裡

00:48:15.300 --> 00:48:18.500
都能夠正確的被attend到並輸出這樣子

00:48:18.500 --> 00:48:21.000
但是我們沒有測在這個

00:48:21.920 --> 00:48:23.020
沒有跟lost in the middle

00:48:23.020 --> 00:48:24.800
測在完全一樣的情景

00:48:24.800 --> 00:48:27.100
所以如果要知道可能還是要

00:48:27.860 --> 00:48:30.960
那個lost in the middle那一篇的那個

00:48:30.960 --> 00:48:33.320
它所問的問題是比較難的

00:48:33.320 --> 00:48:35.540
它不是只是把東西抽出來

00:48:36.200 --> 00:48:37.640
所以它就會發現說

00:48:37.640 --> 00:48:38.880
那個問比較困難的問題

00:48:38.880 --> 00:48:40.520
它擺在中間

00:48:40.520 --> 00:48:42.020
它就會表現比較不好

00:48:43.739 --> 00:48:50.800
那這些東西都是已經有做過long context的延伸了嗎

00:48:50.800 --> 00:48:54.900
所以把它那個long content把它打開

00:48:54.900 --> 00:48:56.420
那個是意味著什麼

00:48:56.420 --> 00:48:59.480
是意味著說我要找到這麼長sequence的文章

00:48:59.480 --> 00:49:00.800
一起留下去訓練嗎

00:49:00.800 --> 00:49:05.160
rope的部分是我們會把rope先加長

00:49:05.160 --> 00:49:07.920
然後加長之後會再做訓練

00:49:08.600 --> 00:49:11.980
那rope加長是讓它在

00:49:11.980 --> 00:49:14.380
為了到場的時候會做得比較好

00:49:14.380 --> 00:49:16.180
就在contentary training的階段嗎

00:49:16.180 --> 00:49:21.219
並且是你把它延伸有點像是做內插

00:49:21.219 --> 00:49:24.380
所以原本短短的被你延伸到場的時候

00:49:24.380 --> 00:49:26.440
那你中間的值就不用訓練了

00:49:26.440 --> 00:49:29.160
所以你就可以從小的去放到大的

00:49:29.160 --> 00:49:31.600
所以32k是長度的意思嗎

00:49:31.600 --> 00:49:32.780
32k是token的數

00:49:34.520 --> 00:49:37.380
所以算一次net token要對32k進去

00:49:38.080 --> 00:49:39.900
就是我們在做contentary training的時候

00:49:39.900 --> 00:49:41.380
就會勸導這個長度

00:49:41.380 --> 00:49:41.920
沒錯

00:49:46.440 --> 00:49:50.380
好,來,還有沒有同學有問題想要現在問一下的呢

00:49:52.420 --> 00:49:53.160
有嗎

00:49:55.780 --> 00:49:59.180
我可以請問一下後來那個loss in the middle

00:49:59.180 --> 00:50:02.239
有沒有什麼解法

00:50:06.060 --> 00:50:08.480
這個老師問題有深度

00:50:09.820 --> 00:50:12.300
我們還沒有很好的解法

00:50:12.300 --> 00:50:14.160
老師有很好的解法

00:50:14.160 --> 00:50:18.040
沒有很好的解法

00:50:18.040 --> 00:50:23.500
有沒有同學想要現在問問題的呢

00:50:24.419 --> 00:50:25.140
有啊

00:50:25.140 --> 00:50:29.440
來,這邊

00:50:29.839 --> 00:50:31.480
我一直想要請問就是

00:50:31.480 --> 00:50:33.800
大家在問loss in the middle有沒有什麼上圖

00:50:42.339 --> 00:50:46.380
我想要請問他close book是說是所有的平均嗎

00:50:46.380 --> 00:50:47.420
因為它是一條

00:50:47.420 --> 00:50:49.719
對,平線

00:50:50.700 --> 00:50:51.760
它是把

00:50:52.880 --> 00:50:53.719
那是什麼意思

00:50:55.319 --> 00:50:57.560
就是沒有retrieve document的情況下

00:50:57.560 --> 00:50:59.200
直接回答對應的問題

00:50:59.200 --> 00:51:02.060
所以就是它是要說明說

00:51:02.060 --> 00:51:03.719
有些在某些

00:51:03.719 --> 00:51:05.160
如果放在某些位置的時候

00:51:05.160 --> 00:51:07.960
它甚至比不要放那個context還要長

00:51:07.960 --> 00:51:09.719
那請問你覺得為什麼可以這樣子

00:51:10.680 --> 00:51:11.500
就是為什麼

00:51:11.500 --> 00:51:14.000
譬如說在中間的時候

00:51:14.640 --> 00:51:15.680
為什麼你給它

00:51:15.680 --> 00:51:17.960
然後它會表現比較糟糕

00:51:19.120 --> 00:51:20.440
我想可能是因為

00:51:20.440 --> 00:51:22.280
就是它學到說

00:51:23.299 --> 00:51:24.700
當你給context的時候

00:51:24.700 --> 00:51:26.360
就一定要依著這個context回答

00:51:26.360 --> 00:51:28.420
所以它有嘗試著去看這個context

00:51:28.420 --> 00:51:30.100
可是它剛好就在中間

00:51:30.100 --> 00:51:30.920
它又看不太到

00:51:30.920 --> 00:51:32.280
所以它就沒有

00:51:32.280 --> 00:51:33.880
它沒有回歸到它本來

00:51:33.880 --> 00:51:36.219
沒有context的情況下會回答的這個問題

00:51:36.219 --> 00:51:38.239
所以等於說它可能回答出來的東西

00:51:38.239 --> 00:51:39.920
會是

00:51:39.920 --> 00:51:43.180
會是比較根據就是你給的可能前面或後面嗎

00:51:43.180 --> 00:51:44.460
如果即便你是問

00:51:45.160 --> 00:51:46.600
對,有可能是這樣子

00:51:47.960 --> 00:51:49.960
好,那就這樣

00:51:51.200 --> 00:51:53.960
有沒有同學要問問題的

00:51:55.219 --> 00:51:56.020
如果暫時沒有

00:51:56.020 --> 00:51:57.239
因為我們中間有休息時間

00:51:57.239 --> 00:51:57.960
大家有什麼問題

00:51:57.960 --> 00:51:59.800
我們可以留在最後再問

00:51:59.800 --> 00:52:01.360
我們休息五分鐘

00:52:01.360 --> 00:52:03.219
好,我們就休息五分鐘喔

00:52:03.219 --> 00:52:04.780
我們五分鐘後回來

WebVTT 字幕：2024 NTU GenAI MTK研究人員專題演講 (下半場).vtt

WEBVTT
Kind: captions
Language: zh-tw

00:00:08.039 --> 00:00:11.000
下半場就講語音相關的

00:00:12.899 --> 00:00:15.180
各位有留到現在

00:00:15.180 --> 00:00:19.000
所以我想各位對於我們公司是有興趣的

00:00:19.980 --> 00:00:23.000
我們這邊就是有一些QR Code可以掃

00:00:23.000 --> 00:00:25.980
所以我們有在增Intern

00:00:25.980 --> 00:00:30.640
然後有在增Engineer跟Scientist

00:00:30.640 --> 00:00:34.020
然後掃一下就可以來投履歷

00:00:34.020 --> 00:00:35.880
暑假也可以來實習

00:00:35.880 --> 00:00:38.020
其實還不錯的

00:00:38.020 --> 00:00:40.600
我們的實習的話

00:00:41.800 --> 00:00:45.100
其實就跟語言模型比較相關

00:00:46.220 --> 00:00:50.100
既然目前有一些語音相關的工作

00:00:50.100 --> 00:00:52.340
可能也有機會去碰觸到

00:00:52.340 --> 00:00:56.620
我們就會依照Scale的狀態

00:00:56.620 --> 00:00:58.380
去配置你的工作

00:00:59.060 --> 00:01:02.000
或是你有特別想要做什麼工作的

00:01:02.000 --> 00:01:04.180
關於語言模型或是語音的話

00:01:04.180 --> 00:01:06.500
也可以跟我們去說

00:01:06.500 --> 00:01:12.640
今天我們下半場就是講語音的研究

00:01:12.640 --> 00:01:16.459
其實Jeff是李宏義老師的學生

00:01:16.459 --> 00:01:19.620
所以是語音大將

00:01:19.620 --> 00:01:24.840
所以我們一起在MediaTek Research

00:01:24.840 --> 00:01:28.260
有做滿多跟語音相關的工作

00:01:28.260 --> 00:01:32.760
我們近期內有發布了一個新的技術

00:01:32.760 --> 00:01:39.560
叫做Generative Fusion Decoding

00:01:39.560 --> 00:01:42.319
待會Jeff也會跟大家介紹一下

00:01:42.319 --> 00:01:48.240
我後面會帶一些contextual的資訊跟data

00:01:48.240 --> 00:01:53.240
我們先請李宏義大將

00:02:01.780 --> 00:02:02.400
謝謝

00:02:03.240 --> 00:02:06.240
就進到語音辨識的部分

00:02:07.000 --> 00:02:11.380
語音辨識現在滿主流的Whisper

00:02:11.380 --> 00:02:13.760
是一個encoder decoder架構

00:02:13.760 --> 00:02:16.220
聲音輸進去這個encoder

00:02:16.220 --> 00:02:19.120
然後decoder就負責文字的輸出

00:02:21.040 --> 00:02:23.840
它除了transcribe外也可以做翻譯

00:02:24.940 --> 00:02:29.080
我們可以發現即便Whisper現在已經出到第三版了

00:02:29.080 --> 00:02:33.120
它還是很容易有一些明顯的錯誤

00:02:33.120 --> 00:02:34.520
尤其是在中文上面

00:02:34.520 --> 00:02:38.280
就是一看就知道句子是錯的

00:02:38.280 --> 00:02:40.520
但是我們在使用LM的時候

00:02:40.520 --> 00:02:42.200
很少觀察到這些錯誤

00:02:42.200 --> 00:02:44.139
LM雖然有時候會hallucinate

00:02:44.139 --> 00:02:47.240
可是它輸出來的句子大部分都是合文法的

00:02:47.240 --> 00:02:49.260
而且看起來是合理的

00:02:49.260 --> 00:02:52.600
所以我們就會希望能夠把這兩個系統結合起來

00:02:52.600 --> 00:02:56.540
去產生更好的語音辨識的結果

00:02:58.300 --> 00:03:00.460
最基礎的想法就是rescoring

00:03:00.460 --> 00:03:05.800
其實也很常被使用的一種方法

00:03:05.800 --> 00:03:08.139
rescoring就是在ASR裡面

00:03:08.940 --> 00:03:10.940
以這兩個句子來講

00:03:10.940 --> 00:03:13.260
recognize speech跟recognize speech

00:03:13.260 --> 00:03:16.600
其實語音上面是非常相似的

00:03:16.600 --> 00:03:20.040
所以ASR就會很困惑到底是選哪一個

00:03:20.040 --> 00:03:23.460
可是如果有經過語言模型的rescoring

00:03:23.460 --> 00:03:26.700
它就會知道說下面這個是比較合理的

00:03:26.700 --> 00:03:29.260
所以就會選擇下面的這組解法

00:03:31.180 --> 00:03:33.080
因為近期LM的興起

00:03:33.080 --> 00:03:36.120
我們也很多work在探討說

00:03:36.120 --> 00:03:38.560
prompting跟reasoning的ability能不能進來

00:03:38.560 --> 00:03:41.660
幫助到ASR的產生結果

00:03:41.660 --> 00:03:44.180
就是generative error correction

00:03:44.180 --> 00:03:45.700
就是在做這件事情

00:03:45.700 --> 00:03:50.500
它的做法就是我先用譬如說whisper

00:03:50.500 --> 00:03:52.400
去產生出五種結果

00:03:52.400 --> 00:03:54.960
這五種結果可能聲音有點相近

00:03:54.960 --> 00:03:57.120
可是它會有一些意思上的不一樣

00:03:57.120 --> 00:04:00.020
我就可以用語言模型來理解

00:04:00.020 --> 00:04:02.140
去產生一個最後的結果

00:04:02.140 --> 00:04:04.460
這樣子最大的優勢在於說

00:04:04.460 --> 00:04:06.660
經過這個語言模型理解的過程

00:04:07.320 --> 00:04:11.300
它是可以針對不同句的不同錯誤去同時改正的

00:04:11.300 --> 00:04:13.080
就不會像在rescoring的時候

00:04:13.080 --> 00:04:15.200
你只能對句子算出一個分數

00:04:15.200 --> 00:04:17.960
所以如果有兩個句子各錯一半的話

00:04:17.960 --> 00:04:19.220
那你就還是會錯

00:04:20.480 --> 00:04:22.580
還是最後會有一些錯誤

00:04:22.580 --> 00:04:24.180
generative error correction

00:04:24.180 --> 00:04:27.300
就有機會把這些錯誤也改正過來

00:04:28.180 --> 00:04:29.779
另外generative error correction

00:04:29.779 --> 00:04:31.520
還有一個很強大的點是

00:04:31.520 --> 00:04:36.020
它可以針對專有名詞去做改正

00:04:36.020 --> 00:04:37.500
就是說這些專有名詞

00:04:37.500 --> 00:04:41.300
即便在ASR輸出的時候完全沒有出現

00:04:41.300 --> 00:04:43.360
五個結果可能都是錯的

00:04:43.360 --> 00:04:45.880
但是它還是有辦法看著它的聲音

00:04:45.880 --> 00:04:47.120
然後理解的話

00:04:47.120 --> 00:04:50.660
去把正確的專有名詞輸出出來

00:04:50.660 --> 00:04:56.520
譬如說Synopec、Nintendo、Zelda等等

00:04:57.219 --> 00:04:59.620
接下來就是進到我們的方法

00:04:59.620 --> 00:05:02.740
我們方法叫let's view step by step

00:05:04.000 --> 00:05:05.940
在進入這個方法之前

00:05:05.940 --> 00:05:07.740
想要來一個小小的QA

00:05:07.740 --> 00:05:11.760
就是我們這個標題其實是有思考過

00:05:11.760 --> 00:05:14.940
然後也想要致敬某一篇論文

00:05:14.940 --> 00:05:16.160
所以才取這個名字

00:05:16.160 --> 00:05:19.060
那有沒有人能夠答出這個論文

00:05:19.060 --> 00:05:22.940
我有準備一本筆記本可以送給大家

00:05:23.500 --> 00:05:26.060
有沒有人要回答看看這個標題

00:05:26.060 --> 00:05:31.380
可能是想要致敬哪一個論文的

00:05:38.160 --> 00:05:40.480
其實我看蠻多人想舉手

00:05:40.480 --> 00:05:41.380
但都幹舉手

00:05:41.380 --> 00:05:42.360
放個數1、2、3

00:05:42.360 --> 00:05:44.300
然後才可以直接舉手

00:05:45.120 --> 00:05:47.000
我從1數到3

00:05:47.000 --> 00:05:50.400
1、2、3

00:05:53.280 --> 00:05:54.220
這位同學

00:05:56.120 --> 00:05:57.600
3、4、5

00:05:57.600 --> 00:05:59.960
他要從哪一個論文走

00:05:59.960 --> 00:06:01.640
應該是let's view step by step

00:06:01.640 --> 00:06:04.140
2、3、4、5

00:06:04.940 --> 00:06:05.560
8

00:06:09.740 --> 00:06:10.980
算對

00:06:24.560 --> 00:06:25.180
不好意思

00:06:25.180 --> 00:06:26.460
我沒有想到那邊

00:06:26.460 --> 00:06:29.560
其實我那時候看到一個

00:06:29.560 --> 00:06:30.460
最近的論文

00:06:30.460 --> 00:06:32.720
let's verify step by step

00:06:32.720 --> 00:06:34.140
是OpenAI的論文

00:06:34.140 --> 00:06:35.540
然後就想要這個名字

00:06:35.540 --> 00:06:36.800
不過let's think step by step

00:06:36.800 --> 00:06:39.339
也確實是在同樣一個scope之下

00:06:39.339 --> 00:06:41.560
是感謝同學的回答

00:06:44.619 --> 00:06:47.560
我們這個paper已經放到archive上面了

00:06:48.560 --> 00:06:51.339
這篇論文最想做的事情

00:06:52.080 --> 00:06:54.040
就是intermediate feedback

00:06:54.040 --> 00:06:55.500
跟parallel decoding

00:06:55.500 --> 00:06:58.420
如同剛才看到rescoring

00:06:58.420 --> 00:07:00.260
或是generative error correction

00:07:00.260 --> 00:07:03.620
都是要ASR輸出完

00:07:03.620 --> 00:07:06.200
完整的結果之後再去進行評價

00:07:06.200 --> 00:07:08.800
這樣子可能會對中間的過程的資訊

00:07:08.800 --> 00:07:09.960
就會有疑似

00:07:09.960 --> 00:07:12.060
所以我們希望能夠在中間的部分

00:07:12.060 --> 00:07:13.500
就有評價

00:07:15.100 --> 00:07:16.840
也希望這個是

00:07:16.840 --> 00:07:18.520
不要像GR是pipeline的

00:07:18.520 --> 00:07:19.820
而是能夠平行處理的

00:07:19.820 --> 00:07:22.820
這樣子就可以加速整個的運行

00:07:30.840 --> 00:07:31.320
好

00:07:33.520 --> 00:07:35.360
所以我們現在要講說

00:07:35.360 --> 00:07:38.920
怎麼樣去實踐intermediate rescoring

00:07:38.920 --> 00:07:42.780
我們先從最後開始往回想

00:07:42.780 --> 00:07:44.800
就是如果今天已經出了一個句子

00:07:44.800 --> 00:07:46.160
Today we are going to talk about

00:07:46.160 --> 00:07:47.640
Automatic Speech Recognition

00:07:47.640 --> 00:07:49.460
如果已經出完句子的時候

00:07:49.460 --> 00:07:51.700
ASR對這個句子當然有一個評價

00:07:51.700 --> 00:07:55.120
所以ASR給他一個分數是可以做到的

00:07:55.120 --> 00:07:59.400
LM對他去做rescoring也是可以做到

00:07:59.400 --> 00:08:01.660
因為就是一個句子給一個分數

00:08:01.660 --> 00:08:05.320
所以這樣子的情境是可以達成的

00:08:05.320 --> 00:08:08.300
如果我們考慮某一個中間的步驟

00:08:08.300 --> 00:08:11.380
就是想像說ASR decode到一半的時候

00:08:11.380 --> 00:08:13.120
ASR decode出Today we are

00:08:13.920 --> 00:08:17.200
這樣子LM還能夠評價這個句子嗎

00:08:17.200 --> 00:08:18.300
以這個情境來說

00:08:18.300 --> 00:08:19.920
LM還是可以評價

00:08:19.920 --> 00:08:21.440
因為你只要把Today we are

00:08:21.440 --> 00:08:22.960
放進LM的tokenizer

00:08:22.960 --> 00:08:26.880
在經過LM之後就能夠算出一個分數

00:08:26.880 --> 00:08:29.360
可是這問題會出在哪裡呢

00:08:29.360 --> 00:08:31.840
如果說ASR只出了一個token

00:08:31.840 --> 00:08:34.200
然後這個token是tod的話

00:08:34.739 --> 00:08:38.240
ASR的token跟LM的token是mismatched

00:08:38.240 --> 00:08:38.960
它是boot

00:08:39.500 --> 00:08:40.960
它是沒有pk的

00:08:40.960 --> 00:08:43.700
所以LM會找不到這樣的一個token

00:08:43.700 --> 00:08:46.460
做法上如果你直接把tod

00:08:46.460 --> 00:08:50.340
用LM的tokenizer去tokenize的話

00:08:50.340 --> 00:08:53.920
它可能會產生出t接著o接著d這樣的結果

00:08:53.920 --> 00:08:56.720
可是這樣的結果去評價tod這個字的機率

00:08:56.720 --> 00:08:58.200
真的是合理的嗎

00:08:58.200 --> 00:09:00.020
因為如果你想像LM裡面

00:09:00.020 --> 00:09:02.340
會不會出現t接o接d這個sequence

00:09:02.860 --> 00:09:04.340
基本上是幾乎不可能的

00:09:04.340 --> 00:09:07.340
因為它出現一個完整的字的時候

00:09:08.160 --> 00:09:09.340
譬如說以這個例子

00:09:09.960 --> 00:09:11.580
其實ASR不是要說tod

00:09:11.580 --> 00:09:13.040
它是要說today

00:09:13.040 --> 00:09:14.260
它講到today的時候

00:09:14.260 --> 00:09:16.720
today就是在LM的詞標裡面

00:09:16.720 --> 00:09:23.200
所以LM其實是想要出today的

00:09:23.200 --> 00:09:26.280
只是迫於ASR只出了一個token

00:09:26.280 --> 00:09:30.900
導致它沒有辦法去出它想出的token

00:09:30.900 --> 00:09:32.720
所以我們要解決的就是

00:09:33.359 --> 00:09:38.040
LM在部分的decode的情形之下

00:09:38.040 --> 00:09:40.640
tod這個機率的估計是不好的

00:09:40.640 --> 00:09:44.420
所以我們希望把未來有可能出現的字

00:09:44.420 --> 00:09:46.260
也納進去機率的考慮

00:09:46.260 --> 00:09:48.020
那在納進去考慮之後

00:09:48.020 --> 00:09:51.440
我們就可以對任何一個sequence

00:09:51.440 --> 00:09:52.540
去做rescoring

00:09:52.540 --> 00:09:56.260
那就有辦法去做到step by step的fusion

00:09:57.560 --> 00:10:03.200
那這個是剛才的說明的

00:10:03.200 --> 00:10:06.179
轉換成一個圖解的格式

00:10:06.179 --> 00:10:08.300
就是如果有一個ASR的sequence

00:10:08.300 --> 00:10:11.960
已經出來是abcde fghijk

00:10:11.960 --> 00:10:14.260
然後它在LM的tokenization是

00:10:14.840 --> 00:10:17.240
t1 t2 t3 t4的話

00:10:17.240 --> 00:10:19.240
我們除了考量這個

00:10:19.240 --> 00:10:21.780
LM本來會tokenize的結果

00:10:21.780 --> 00:10:23.280
我們還需要考慮

00:10:23.860 --> 00:10:25.340
再經過幾步之後

00:10:25.340 --> 00:10:27.440
LM可能會出現的token

00:10:27.440 --> 00:10:29.500
也納進去機率的計算

00:10:29.500 --> 00:10:33.059
那把這些航資都納進去計算之後

00:10:33.059 --> 00:10:35.760
我們就可以準確的估出

00:10:35.760 --> 00:10:40.020
這個abcde f sequence的機率

00:10:40.020 --> 00:10:42.440
那就有辦法在LM跟ASR

00:10:42.440 --> 00:10:44.840
不同tokenize的情況下

00:10:44.840 --> 00:10:48.559
還能夠去做step by step的fusion

00:10:48.559 --> 00:10:51.300
詳細的算是可以看論文裡面

00:10:51.300 --> 00:10:55.440
有蠻清楚的表達出整個公式

00:10:56.500 --> 00:11:04.280
那接下來就由YC來講解後面的部分

00:11:06.580 --> 00:11:09.020
那剛才Jeff也點出了

00:11:09.020 --> 00:11:11.340
我們現在預料的問題就是

00:11:11.340 --> 00:11:15.640
我們今天LM跟ASR

00:11:15.640 --> 00:11:18.300
或者是我們這個模型其實也可以用在OCR

00:11:18.300 --> 00:11:21.340
因為OCR其實也是出文字

00:11:22.140 --> 00:11:24.440
那它的問題就在於

00:11:24.440 --> 00:11:27.980
兩者之間的token的體系不一樣

00:11:27.980 --> 00:11:29.900
我們剛才有講到一開始

00:11:29.900 --> 00:11:31.000
我也鋪梗了嘛

00:11:31.000 --> 00:11:34.480
我們要怎麼把句子放到模型裡面

00:11:34.480 --> 00:11:36.040
我們要做一個tokenization

00:11:36.040 --> 00:11:38.880
那如果今天你體系不一樣的兩個東西

00:11:38.880 --> 00:11:41.140
其實你要把它合在一起

00:11:41.140 --> 00:11:42.400
你就遇到問題

00:11:42.400 --> 00:11:44.300
所以如這個圖來看

00:11:44.300 --> 00:11:45.700
你可以看到說

00:11:45.700 --> 00:11:48.080
今天這個tester commission model

00:11:48.080 --> 00:11:51.280
它可以吃這個聲音

00:11:51.280 --> 00:11:54.679
或者是可以吃這個圖片的文字

00:11:54.679 --> 00:11:58.460
那經過這個decode的理解這個訊號了

00:11:58.460 --> 00:12:00.920
我們就可以用decode來一個一個的

00:12:00.920 --> 00:12:05.300
用token的方式來產生相應的文字

00:12:05.300 --> 00:12:08.059
那我同樣的可以用語言模型

00:12:08.059 --> 00:12:09.340
來做這件事情

00:12:09.340 --> 00:12:11.800
那如果你今天想要把它合在一起

00:12:11.800 --> 00:12:14.700
因為它們的體系不一致

00:12:14.700 --> 00:12:17.760
所以你其實是合不在一起的

00:12:17.760 --> 00:12:20.980
所以其實我們有做了一些數學的推導

00:12:20.980 --> 00:12:23.800
然後詳細的在論文裡面都可以看得到

00:12:23.800 --> 00:12:26.100
那個是我們寫到半夜

00:12:26.100 --> 00:12:27.800
寫到半夜四點的東西

00:12:27.800 --> 00:12:30.440
所以大家可以看一下這樣

00:12:31.059 --> 00:12:33.520
那我們的解決方法就是token space不一致

00:12:33.520 --> 00:12:35.460
那我們就把它換到by the space

00:12:35.460 --> 00:12:37.360
最小的顆粒度

00:12:37.360 --> 00:12:39.100
那就不會有問題了

00:12:39.100 --> 00:12:42.460
所以我們在by the space去做機率的估算

00:12:42.460 --> 00:12:45.780
那我們就可以讓這兩個體系合在一起

00:12:45.780 --> 00:12:48.920
去做一席的評估

00:12:48.920 --> 00:12:50.059
然後評估的時候

00:12:51.420 --> 00:12:55.500
左側我們通常會給它比較大的權重

00:12:55.500 --> 00:12:56.700
右側會比較小

00:12:56.700 --> 00:12:59.460
所以我們會用一個R來做這個平衡

00:13:00.320 --> 00:13:03.880
那它還是比較尊重語言模型

00:13:03.880 --> 00:13:07.880
比較尊重ASR的成果來做輸出

00:13:11.160 --> 00:13:13.740
那這邊我想要先打個岔

00:13:13.740 --> 00:13:15.700
回到我們過去

00:13:15.700 --> 00:13:20.880
我那個時候也是跟Jeff一起做的研究

00:13:20.880 --> 00:13:22.320
它叫Clean Audience

00:13:22.320 --> 00:13:25.440
所謂的Clean Audience就是這個英文有點微妙

00:13:26.280 --> 00:13:28.080
就是在聖經裡面

00:13:29.340 --> 00:13:34.679
有一些先知聽得到神的呼喚

00:13:34.679 --> 00:13:35.660
神的語

00:13:35.660 --> 00:13:37.960
就是Clean Audience這個字

00:13:37.960 --> 00:13:39.860
所以我們就希望說

00:13:40.640 --> 00:13:43.080
這個模型可以聽到言外之意

00:13:43.600 --> 00:13:45.340
所以我們就這樣命名

00:13:45.340 --> 00:13:46.520
然後我們沒有湊梗

00:13:46.520 --> 00:13:47.880
就是直接命名就不管

00:13:47.880 --> 00:13:49.380
就是這個名字

00:13:50.080 --> 00:13:52.080
那Clean Audience我們做什麼呢?

00:13:52.120 --> 00:13:55.220
我們在原本的whisper的架構當中

00:13:55.220 --> 00:13:59.140
我們在prefix加入一些domain的tag

00:13:59.140 --> 00:14:02.179
然後我們經過微調

00:14:02.179 --> 00:14:03.480
這要去做微調

00:14:03.480 --> 00:14:08.120
讓它可以更能利用到我domain的資訊

00:14:08.120 --> 00:14:10.220
來做語辨識

00:14:10.780 --> 00:14:12.440
所以這麼做就是譬如說

00:14:12.440 --> 00:14:14.059
你今天在一個場景

00:14:14.059 --> 00:14:15.960
譬如說這樣的講堂好了

00:14:15.960 --> 00:14:18.100
你就可以給一個tag說

00:14:18.100 --> 00:14:20.620
這是一個ML的letter

00:14:20.620 --> 00:14:22.700
然後它在語音辨識的時候

00:14:22.700 --> 00:14:27.180
它就知道你今天是在做ML的letter

00:14:27.180 --> 00:14:29.980
所以它的辨識效果會變得更好

00:14:29.980 --> 00:14:31.700
或者是今天是在醫院的場景

00:14:31.700 --> 00:14:34.000
我可以跟它說我現在在醫院的場景

00:14:34.000 --> 00:14:36.460
它就會更容易的aware到

00:14:36.460 --> 00:14:38.900
醫院會用到的用字

00:14:38.900 --> 00:14:42.940
所以Clean Audience是我們media tag research

00:14:42.940 --> 00:14:44.700
在語音這一塊

00:14:45.720 --> 00:14:49.020
做這種contagion的第一步

00:14:49.020 --> 00:14:51.860
就是用類似point的方式

00:14:51.860 --> 00:14:55.380
來影響語音模型的辨識率

00:14:55.380 --> 00:14:57.900
我們就進一步再延伸到

00:14:57.900 --> 00:14:59.940
今天待會會講的work

00:15:00.920 --> 00:15:05.100
其實也利用了相關的概念

00:15:05.100 --> 00:15:07.100
剛才我們講的

00:15:07.100 --> 00:15:09.080
我們把語言模型放上去之後

00:15:09.080 --> 00:15:15.280
它其實就已經可以讓效果提升了

00:15:15.280 --> 00:15:16.040
與此同時

00:15:16.040 --> 00:15:19.100
我們其實也可以靠著語言模型的point

00:15:19.100 --> 00:15:22.520
來做到我們之前在Clean Audience做的事情

00:15:23.840 --> 00:15:25.580
我們可以給它下一些point

00:15:25.580 --> 00:15:29.040
來讓它把語音辨識做得更好

00:15:30.300 --> 00:15:32.240
接下來我們就demo一下

00:15:32.240 --> 00:15:36.220
詳細的paper的數據大家可以

00:15:36.220 --> 00:15:38.120
剛才有掃嗎

00:15:39.479 --> 00:15:41.280
如果沒有掃我再回到這邊

00:15:41.280 --> 00:15:42.040
大家可以掃一下

00:15:42.820 --> 00:15:45.520
詳細的一些數據我們都放在paper裡面

00:15:45.520 --> 00:15:49.720
我們這邊就不贅述相關的實驗數據

00:15:49.720 --> 00:15:52.520
我們直接看幾個demo來感受一下

00:15:56.000 --> 00:15:58.500
一開始這邊就是

00:15:58.500 --> 00:16:00.620
在這個句子當中

00:16:00.620 --> 00:16:04.780
踴躍地提出意義對於團隊是很有意義的

00:16:04.780 --> 00:16:08.540
意義跟意義這兩個都是同音但是異字的

00:16:08.540 --> 00:16:10.420
如果你今天用whisper

00:16:10.420 --> 00:16:13.220
你就會發現說它會辨識得不好

00:16:13.220 --> 00:16:16.220
它會把兩個意義都變成有意義的意義

00:16:17.180 --> 00:16:19.820
有意義的意義好像兩個都通用

00:16:19.820 --> 00:16:21.600
就是具有意義的意義

00:16:22.880 --> 00:16:27.040
今天我們就可以用whisper

00:16:27.040 --> 00:16:28.620
我們的中文的模型

00:16:28.620 --> 00:16:29.660
再加上whisper

00:16:29.660 --> 00:16:33.360
然後用GFD這個算法去把它綁在一起

00:16:33.360 --> 00:16:35.600
其實你可以看到它在中文表現上

00:16:35.600 --> 00:16:37.600
這個意義就被還原回來

00:16:39.820 --> 00:16:44.480
或者是說今天老師交代所有學生

00:16:44.480 --> 00:16:47.220
明天都要帶交代來學校

00:16:47.220 --> 00:16:48.800
那一樣的意思是

00:16:48.800 --> 00:16:51.980
兩個交代其實都是同音

00:16:51.980 --> 00:16:54.220
但是是意思不一樣的

00:16:54.220 --> 00:16:55.340
那如果是whisper

00:16:55.340 --> 00:16:57.820
他對語言的掌控能力沒那麼好

00:16:57.820 --> 00:17:00.240
他對中文不是那麼認識

00:17:00.240 --> 00:17:02.340
那他也想得到

00:17:02.340 --> 00:17:05.440
因為譬如說whisper在訓練中文的時候

00:17:05.440 --> 00:17:09.920
他看到的語料就比較限制在一些成對的資料上

00:17:09.920 --> 00:17:13.080
但是我們的原模型是看了650GB的

00:17:13.080 --> 00:17:15.920
這麼多的中文的文檔

00:17:15.920 --> 00:17:18.480
所以他對語言的掌控能力當然更好

00:17:18.480 --> 00:17:23.080
所以經過了兩個把它合在一起之後

00:17:23.080 --> 00:17:26.460
他就可以把兩個交代都交代清楚

00:17:29.940 --> 00:17:33.160
剛剛講說我們也可以去point這個模型

00:17:33.160 --> 00:17:37.800
譬如說今天可為意味著該點連續

00:17:37.800 --> 00:17:39.560
那如果你走在路上

00:17:39.560 --> 00:17:41.040
隨便跟人家講這句話

00:17:41.040 --> 00:17:42.600
別人也不知道你在講什麼

00:17:42.600 --> 00:17:44.280
那如果你給他一些hint

00:17:44.280 --> 00:17:49.460
跟他說這一個的場景是在一個微積分相關的場景

00:17:49.460 --> 00:17:52.460
他就可以把這個可為給他辨識出來

00:17:52.460 --> 00:17:56.160
而且在我的模型我還會把可為加括號給他

00:17:57.020 --> 00:18:00.300
因為他就知道這個是一個詞組

00:18:00.300 --> 00:18:03.300
所以很重要特別強調一下

00:18:03.940 --> 00:18:06.160
所以你可以看到原模型要加進來之後

00:18:06.160 --> 00:18:08.040
我們用point就可以改

00:18:08.040 --> 00:18:12.140
讓他知道我們現在使用的環境

00:18:12.140 --> 00:18:16.140
然後來幫助語音辨識提升

00:18:17.520 --> 00:18:24.080
或者是說如果你今天這個文字裡面有一些比較罕用的文字

00:18:24.080 --> 00:18:26.080
譬如說日食這個文字

00:18:26.080 --> 00:18:27.940
他可能比較罕用

00:18:27.940 --> 00:18:30.740
所以原模型來辨識的時候

00:18:30.740 --> 00:18:33.359
他就不太懂日食

00:18:33.359 --> 00:18:36.940
然後他就覺得可能是綠食吧

00:18:38.220 --> 00:18:40.440
這句話其實也不會有錯

00:18:41.980 --> 00:18:43.340
在這個情形之下

00:18:43.340 --> 00:18:44.740
我們就可以善用point

00:18:44.740 --> 00:18:49.740
你知道今天這個文檔裡面就是在講關於日食的事情

00:18:49.740 --> 00:18:53.000
那你就把日食給他偷偷提示給他

00:18:53.000 --> 00:18:55.940
讓他的辨識就會變得更好

00:18:55.940 --> 00:18:58.720
這個使用場景也可以用到企業端

00:18:58.720 --> 00:19:00.880
譬如企業有一些產品名

00:19:00.880 --> 00:19:03.500
或企業有一些董事長的名字

00:19:03.500 --> 00:19:04.760
總經理的名字

00:19:04.760 --> 00:19:07.160
這些名字whisper不會知道

00:19:08.480 --> 00:19:10.400
語音辨識的模型不會知道

00:19:10.400 --> 00:19:11.580
你就可以給他提示

00:19:11.580 --> 00:19:13.740
所以這個詞可以加一堆

00:19:13.740 --> 00:19:16.020
我們的paper裡面就是有做這個實驗

00:19:16.020 --> 00:19:17.900
就是加一堆詞給他

00:19:17.900 --> 00:19:21.220
然後其中有一些詞是有幫助到整個辨識

00:19:21.220 --> 00:19:24.380
提升就會有一個提升的效果

00:19:27.240 --> 00:19:32.340
那這邊是一個ATCO2的資料集的例子

00:19:32.340 --> 00:19:36.940
給大家展示一下一些比較神奇的用法

00:19:37.940 --> 00:19:42.960
ATCO2它是一個航班相關資訊的語音辨識問題

00:19:42.960 --> 00:19:46.520
那它就是這個塔台之間在溝通

00:19:46.520 --> 00:19:49.340
那我們可以來聽一下這一段

00:19:56.419 --> 00:19:59.320
好,那大家應該是聽了很糊嘛

00:19:59.320 --> 00:20:01.920
因為這個塔台這個音質不是很好

00:20:01.920 --> 00:20:03.580
然後你有沒有發現說

00:20:03.580 --> 00:20:05.240
就算我把文字修到這邊

00:20:05.240 --> 00:20:07.080
你也好像看不太懂

00:20:07.080 --> 00:20:07.660
對不對

00:20:08.960 --> 00:20:10.619
那可能是英文的關係

00:20:10.619 --> 00:20:11.880
所以我們把它翻成中文

00:20:16.119 --> 00:20:17.440
我們把它翻成中文

00:20:18.879 --> 00:20:20.160
還是看不懂

00:20:20.160 --> 00:20:20.960
對不對

00:20:21.460 --> 00:20:24.980
那可能是因為我們對塔台之間的溝通不是很了解

00:20:24.980 --> 00:20:30.560
所以我們就把塔台的相關溝通的規範

00:20:30.560 --> 00:20:31.859
把它找出來

00:20:31.859 --> 00:20:34.240
然後我們就仔細看

00:20:34.240 --> 00:20:35.300
這邊很多

00:20:35.300 --> 00:20:36.460
這個文字很多

00:20:36.980 --> 00:20:40.359
看完我們還是不是很了解

00:20:40.359 --> 00:20:41.980
所以怎麼辦呢

00:20:42.540 --> 00:20:44.980
我們就把整個文檔塞進去Pound裡面

00:20:45.940 --> 00:20:46.500
這樣

00:20:46.500 --> 00:20:48.000
你可以發現說

00:20:48.580 --> 00:20:50.980
我們在做完這件事情之後

00:20:50.980 --> 00:20:53.760
就有一個很長的進步

00:20:53.760 --> 00:20:55.660
你可以看到這個

00:20:55.660 --> 00:20:58.760
這個位置是還沒碰進去的這個

00:20:59.359 --> 00:21:00.119
是這個分數

00:21:00.119 --> 00:21:01.380
然後當碰進去之後

00:21:01.380 --> 00:21:03.520
它就有一個很明顯的drop

00:21:03.520 --> 00:21:04.859
所以語言模型

00:21:04.859 --> 00:21:07.260
它利用它的文字能力

00:21:07.260 --> 00:21:11.840
充分的理解航班資訊在用語是什麼樣的特色

00:21:11.840 --> 00:21:14.960
然後它就會幫助到語音模型在辨識的時候

00:21:14.960 --> 00:21:16.280
有一個很好的效果

00:21:16.280 --> 00:21:18.180
在我們Paper裡面就叫做

00:21:18.180 --> 00:21:21.900
印刷宣的Aware的特色

00:21:24.060 --> 00:21:25.560
那最後呢

00:21:25.560 --> 00:21:28.760
最後我們就有請大廳老師來

00:21:29.500 --> 00:21:31.820
為我們展現Core Switching

00:21:31.820 --> 00:21:34.980
這邊就是李宏偉老師的

00:21:34.980 --> 00:21:39.060
實驗室有發布一個中文很好的語料

00:21:39.060 --> 00:21:41.240
那我們就拿這個語料來做實驗

00:21:41.240 --> 00:21:42.619
然後我們就來看第一句

00:21:42.619 --> 00:21:43.740
這兩句都有一個特色

00:21:43.740 --> 00:21:45.300
都是會有Core Switching

00:21:45.300 --> 00:21:46.760
所謂的Core Switching就是中文

00:21:47.639 --> 00:21:48.820
跟另外一種語言

00:21:48.820 --> 00:21:50.880
就是兩種語言之間的交換

00:21:50.880 --> 00:21:54.380
然後在中文的環境其實很常出現Core Switching

00:21:54.380 --> 00:21:57.440
就是中文跟英文之間混著講的狀況

00:21:57.440 --> 00:21:59.020
尤其是ML的課程

00:21:59.020 --> 00:22:00.880
就會有一些專有名詞

00:22:02.160 --> 00:22:03.980
那首先第一句我們聽一下

00:22:09.119 --> 00:22:10.640
那你可以看到說

00:22:10.640 --> 00:22:13.600
如果今天Whisper是辨識這句話的時候

00:22:13.600 --> 00:22:17.359
它會辨識Recognization Base

00:22:17.359 --> 00:22:19.160
沒有E

00:22:19.160 --> 00:22:21.700
那你看這一句文法

00:22:21.700 --> 00:22:23.940
其實顯然就不是很正確

00:22:23.940 --> 00:22:26.619
因為要加D比較是合理的

00:22:26.619 --> 00:22:28.780
所以如果你今天語音辨識

00:22:28.780 --> 00:22:31.820
它的中文的能力已經不好了

00:22:31.820 --> 00:22:33.680
你又加了英文上去

00:22:33.680 --> 00:22:35.080
它就更難了

00:22:35.080 --> 00:22:37.040
所以Whisper來說它就做不到

00:22:37.040 --> 00:22:39.560
但是以語言模式來看這一句的時候

00:22:39.560 --> 00:22:41.480
我的Base一定要加D

00:22:41.480 --> 00:22:43.080
不加D一定是錯的

00:22:43.080 --> 00:22:45.540
所以它就會校正回來

00:22:45.540 --> 00:22:47.540
然後下面也是同樣的例子

00:22:47.540 --> 00:22:50.820
就是在這一區的英文當中

00:22:50.820 --> 00:22:54.040
如果你用形容詞其實才是對的

00:22:54.040 --> 00:22:56.400
用名詞是不對的

00:22:56.400 --> 00:22:58.720
所以我們在語言模型加進來的時候

00:22:58.720 --> 00:23:00.740
它就理解這件事情

00:23:00.740 --> 00:23:03.540
然後把Core Switching給做好

00:23:07.420 --> 00:23:12.840
以上就是我們的對語音辨識技術的介紹

00:23:12.840 --> 00:23:14.420
時間好像空了還差不多

00:23:15.040 --> 00:23:16.780
所以最後給大家Q&A

00:23:17.600 --> 00:23:19.840
好 那有沒有開那個

00:23:23.919 --> 00:23:25.600
我想問一下那個

00:23:26.159 --> 00:23:27.859
Rare Word的現成那個

00:23:27.859 --> 00:23:29.200
葉同學講就是說

00:23:29.200 --> 00:23:31.060
那你Prom裡面會給一些

00:23:31.060 --> 00:23:32.900
假設你知道這個文檔是什麼主題

00:23:32.900 --> 00:23:33.700
就把那個Prom

00:23:33.700 --> 00:23:35.540
像剛剛舉的例子是日史

00:23:36.279 --> 00:23:39.220
對 那我之前自己也有做過實驗

00:23:39.739 --> 00:23:41.580
就是我一直把Whisper Model

00:23:41.580 --> 00:23:42.619
就是也是給一個Prom

00:23:42.619 --> 00:23:45.020
然後也是一個

00:23:45.020 --> 00:23:47.540
特定領域的東西去辨識

00:23:47.540 --> 00:23:50.080
然後就給它一堆Keyword這樣子

00:23:50.080 --> 00:23:52.240
然後這樣反而是

00:23:52.240 --> 00:23:52.980
會載一些

00:23:52.980 --> 00:23:58.359
就是你說的那一堆語音

00:23:58.359 --> 00:24:00.140
裡面可能真的常常提到日史

00:24:00.140 --> 00:24:01.760
但是裡面一定有很多句子

00:24:01.760 --> 00:24:03.240
是沒有日史這兩個字

00:24:03.800 --> 00:24:07.040
我想問說那在那些沒有出現日史的

00:24:07.040 --> 00:24:08.800
那些句子當中不會變差嗎

00:24:08.800 --> 00:24:10.760
因為我之前在Whisper的時候

00:24:10.760 --> 00:24:12.540
就是給一堆關鍵字的時候

00:24:12.540 --> 00:24:14.760
反而是給太多的時候會反而

00:24:14.760 --> 00:24:16.820
在那些沒有關鍵字的區域

00:24:16.820 --> 00:24:18.080
上面會變差這樣子

00:24:18.780 --> 00:24:20.900
這是很有可能的

00:24:20.900 --> 00:24:22.800
所以我們在做這種Rare Word

00:24:22.800 --> 00:24:23.420
的實驗的時候

00:24:23.420 --> 00:24:25.940
我們都會加一大堆誤導它的字

00:24:25.940 --> 00:24:27.520
然後在我們的實驗裡面

00:24:27.520 --> 00:24:30.580
我們是加了100個誤導它的字

00:24:30.580 --> 00:24:32.840
那你就會發現說你如果

00:24:32.840 --> 00:24:34.980
可能用純粹Whisper把這些字

00:24:34.980 --> 00:24:35.920
加進去的時候

00:24:36.540 --> 00:24:39.060
它可能就會把原本對的弄錯

00:24:39.619 --> 00:24:41.920
但是語言模型有一個厲害之處

00:24:41.920 --> 00:24:45.859
因為你可以用很完整的文句告訴他說

00:24:45.859 --> 00:24:47.520
以下的這個字

00:24:47.520 --> 00:24:50.840
有可能會出現這一些字

00:24:50.840 --> 00:24:52.980
所以有這樣的提示之後

00:24:52.980 --> 00:24:53.960
它在產生的時候

00:24:53.960 --> 00:24:57.840
它就不一定要執意的去選這上面的字

00:24:57.840 --> 00:24:59.520
它是參考而已

00:24:59.520 --> 00:25:02.859
所以以我們現在的做法會更合理一點

00:25:02.859 --> 00:25:05.700
在這個使用場景會更合理一點

00:25:05.700 --> 00:25:06.520
所以在訓練的時候

00:25:06.520 --> 00:25:08.580
就是要給一堆誤導它的字

00:25:08.580 --> 00:25:10.980
沒有在使用的時候才會

00:25:10.980 --> 00:25:12.320
我們沒有任何訓練

00:25:12.320 --> 00:25:13.960
剛才那個架構就是

00:25:13.960 --> 00:25:16.160
我們把一個訓練好的ASR

00:25:16.160 --> 00:25:17.680
跟訓練好的LM

00:25:17.680 --> 00:25:19.020
然後就接起來

00:25:19.020 --> 00:25:19.920
就開始用

00:25:19.920 --> 00:25:21.580
沒有任何訓練

00:25:26.320 --> 00:25:28.320
我印象中Whisper那個

00:25:28.320 --> 00:25:30.619
好像他們前面不能夠塞太多東西

00:25:30.619 --> 00:25:31.400
對 沒錯

00:25:31.400 --> 00:25:32.580
那實作上是不是

00:25:33.520 --> 00:25:35.000
你只要去調出來

00:25:35.619 --> 00:25:38.060
你到底好像有點積累會不會

00:25:38.520 --> 00:25:41.240
就是譬如說我們加100個confusion

00:25:41.240 --> 00:25:42.560
我這件事情就做不到

00:25:42.560 --> 00:25:44.940
因為加進去它就爆掉了

00:25:44.940 --> 00:25:47.000
對 所以那個我們就沒有做這個部分

00:25:47.000 --> 00:25:48.140
因為那就是

00:25:48.140 --> 00:25:50.060
語言模型才能加這麼多的字

00:25:50.700 --> 00:25:53.760
然後像剛才航空資訊那一個

00:25:53.760 --> 00:25:56.140
我們也只是抽一些關鍵詞

00:25:56.140 --> 00:25:57.100
放到Whisper的時候

00:25:57.100 --> 00:25:59.800
所以實務上其實也沒什麼用

00:25:59.800 --> 00:26:02.000
對 實務上你要在Whisper裡面

00:26:02.000 --> 00:26:04.100
加很長的是做不太到

00:26:04.899 --> 00:26:06.600
但我想稍微補充一下

00:26:07.580 --> 00:26:09.060
是不是選錯或誤解

00:26:09.060 --> 00:26:10.200
就是剛才那個文字

00:26:10.200 --> 00:26:11.460
就比如說很長的

00:26:11.460 --> 00:26:13.080
有關那個航空資訊的文章

00:26:13.080 --> 00:26:15.240
它是加在LM上

00:26:15.240 --> 00:26:16.600
不是加給Whisper

00:26:18.119 --> 00:26:19.740
真正被pump的那個

00:26:19.740 --> 00:26:20.760
是LM

00:26:20.760 --> 00:26:23.100
你在剛剛那個時候還pump Whisper嗎

00:26:23.100 --> 00:26:24.100
我pump Whisper對不對

00:26:24.100 --> 00:26:26.740
我們發現pump還是有一點幫助

00:26:26.740 --> 00:26:27.960
所以我們能pump的時候

00:26:27.960 --> 00:26:29.380
就稍微pump它一下

00:26:29.380 --> 00:26:29.560
對

00:26:31.600 --> 00:26:37.560
有Whisper有pump

00:26:38.460 --> 00:26:39.680
然後有pump跟沒pump

00:26:40.520 --> 00:26:42.460
然後再加上我們的

00:26:42.460 --> 00:26:43.140
有pump跟沒pump

00:26:43.140 --> 00:26:44.820
所以有各種不同的組合都

00:26:49.460 --> 00:26:50.380
好 冠田

00:26:53.000 --> 00:26:54.380
那我想要問一下那個

00:26:55.420 --> 00:26:57.600
自從我把Token的RVT

00:26:57.600 --> 00:26:59.040
變成怪的Priority

00:26:59.040 --> 00:27:00.920
然後你怎麼定義那個

00:27:00.920 --> 00:27:02.800
什麼叫common的prefix

00:27:02.800 --> 00:27:04.600
那就開配合啦

00:27:06.400 --> 00:27:07.600
這硬喔

00:27:09.240 --> 00:27:22.260
我一定有放那個D-Hard

00:27:37.300 --> 00:27:39.359
欸 已經有三顆星星了

00:27:39.359 --> 00:27:40.800
誰點的

00:27:40.800 --> 00:27:43.600
今天早上還幹飯

00:27:49.920 --> 00:27:52.480
喔 那怎麼估算呢

00:27:53.879 --> 00:27:55.160
這張我寫的

00:27:56.660 --> 00:27:57.160
我寫的

00:27:57.160 --> 00:27:57.160


00:27:57.160 --> 00:27:57.160


00:27:57.160 --> 00:27:57.280
我寫的

00:27:59.060 --> 00:27:59.700
好

00:27:59.700 --> 00:28:01.020
這邊的這個M

00:28:01.020 --> 00:28:03.280
其實就是想要做一個轉換

00:28:04.320 --> 00:28:05.280
它的轉換就是

00:28:06.020 --> 00:28:09.859
我今天需要把原本在Token space

00:28:09.859 --> 00:28:13.020
計算機率這件事情轉換到以

00:28:13.020 --> 00:28:16.280
bybas的方式來做計算

00:28:17.320 --> 00:28:20.400
那如果這件事情要能做計算的話

00:28:20.400 --> 00:28:22.680
我們就可以把原本Token

00:28:23.400 --> 00:28:25.340
Google這個Archemesma的

00:28:25.340 --> 00:28:27.400
最好的那個Token的sequence

00:28:27.400 --> 00:28:29.900
把它換成是bysequence

00:28:31.060 --> 00:28:32.940
那所以這個轉換呢

00:28:32.940 --> 00:28:34.619
如果用nonef的寫法

00:28:34.619 --> 00:28:36.680
其實是寫成這一個式子

00:28:37.540 --> 00:28:40.680
那這個式子它所表達的是什麼呢

00:28:41.240 --> 00:28:42.740
它所表達的是說

00:28:42.740 --> 00:28:44.520
今天我在做計算的時候

00:28:44.520 --> 00:28:48.100
我的Token的prefix

00:28:48.100 --> 00:28:50.680
跟我的byte是吻合上的

00:28:51.580 --> 00:28:55.200
那這些就是由這個byte產生的機率

00:28:55.200 --> 00:28:58.900
因為後面的就會一路都是1下去

00:28:58.900 --> 00:29:00.680
所以在這個條件下

00:29:01.540 --> 00:29:04.180
成立我們把這個Token

00:29:04.180 --> 00:29:09.100
放到這個連成的這個機率裡面

00:29:09.100 --> 00:29:11.420
我們就可以估出每一條路徑

00:29:11.420 --> 00:29:15.080
它只要符合這一個條件

00:29:15.080 --> 00:29:16.860
把它相加在一起

00:29:16.860 --> 00:29:18.780
就能估出所有的

00:29:18.780 --> 00:29:21.000
那這個式子呢

00:29:21.000 --> 00:29:21.480
很難算

00:29:21.480 --> 00:29:23.340
因為它的這個複雜度是

00:29:23.340 --> 00:29:28.280
the capital size的長度次法

00:29:28.280 --> 00:29:30.280
基本上是算不來的

00:29:30.280 --> 00:29:32.680
所以我們這邊做了一個近視

00:29:32.680 --> 00:29:34.780
就是說我們假設

00:29:35.620 --> 00:29:37.440
Tokenization完之後

00:29:37.440 --> 00:29:39.740
那一條路徑的機率最高

00:29:39.740 --> 00:29:41.440
因為你在訓練的時候

00:29:41.440 --> 00:29:44.840
你都會用那個Tokenizer去做Tokenization

00:29:44.840 --> 00:29:47.240
所以這樣的序列的

00:29:47.240 --> 00:29:48.980
呈現方法是機率最高

00:29:48.980 --> 00:29:50.980
應該是可以想到的到

00:29:50.980 --> 00:29:52.440
就是在訓練資料之下

00:29:52.440 --> 00:29:53.460
這樣扛下去之後

00:29:53.460 --> 00:29:54.960
它是機率最高

00:29:54.960 --> 00:29:57.800
所以我們就只要算這個機率最高的

00:29:57.800 --> 00:29:58.840
main path

00:29:58.840 --> 00:30:02.900
旁邊的旁支像這樣展開來

00:30:02.900 --> 00:30:04.380
然後這就是旁支算一算

00:30:04.380 --> 00:30:06.380
我們就可以把這個機率算出來了

00:30:06.380 --> 00:30:08.180
所以有了這個假設之後

00:30:08.180 --> 00:30:12.240
我們的複雜度就會降到V乘上S

00:30:12.240 --> 00:30:14.900
就是這個vocabulary size乘上

00:30:14.900 --> 00:30:17.420
secretness

00:30:18.240 --> 00:30:21.280
所以它就會寫成這個式子

00:30:21.280 --> 00:30:23.900
你就把每一條路徑的機率都算一算

00:30:23.900 --> 00:30:25.420
就會變成這個式子

00:30:25.420 --> 00:30:28.840
那你就可以去估那個機率

00:30:28.840 --> 00:30:31.400
那個旁支是每一個Token

00:30:31.400 --> 00:30:32.820
然後也是最高的

00:30:32.820 --> 00:30:34.560
這是第二個高的式子

00:30:34.560 --> 00:30:35.240
不是

00:30:35.240 --> 00:30:37.160
就是那一個Token

00:30:37.160 --> 00:30:38.540
如果旁支可以

00:30:38.540 --> 00:30:40.600
混合bite

00:30:40.600 --> 00:30:42.600
當previce這個條件

00:30:42.600 --> 00:30:44.520
也就是說

00:30:44.520 --> 00:30:45.400
這裡

00:30:46.720 --> 00:30:49.600
T1 prompt就是其中一個旁支

00:30:49.600 --> 00:30:50.560
然後呢

00:30:50.560 --> 00:30:54.520
我們的bite是ABCDEFGHIJK

00:30:54.520 --> 00:30:56.460
所以這個T1 prompt

00:30:56.460 --> 00:30:57.980
它也是可可能的

00:30:57.980 --> 00:31:01.540
因為它ABCDEFIJKLM

00:31:02.220 --> 00:31:03.800
所以它也是可能的一種

00:31:03.800 --> 00:31:05.540
我們也要把它算進去

00:31:05.540 --> 00:31:08.540
只不過我們是限制在

00:31:09.760 --> 00:31:11.000
以manpass

00:31:11.000 --> 00:31:14.240
就是tokenization這條路徑的旁支而已

00:31:14.240 --> 00:31:15.460
如果你不這麼做

00:31:15.460 --> 00:31:17.620
你就要窮局所有的可能

00:31:17.620 --> 00:31:20.020
去吻合previce這個條件

00:31:20.020 --> 00:31:21.540
那就會算不完

00:31:24.700 --> 00:31:26.940
所以假設做那種

00:31:26.940 --> 00:31:29.940
有效應其實就是它規定的時候

00:31:29.940 --> 00:31:31.520
最高的那個pass

00:31:31.520 --> 00:31:32.480
它其實就是

00:31:32.480 --> 00:31:35.960
我經常考慮到這些奇怪real world這樣

00:31:35.960 --> 00:31:36.680
可以你們說

00:31:40.800 --> 00:31:42.400
然後大家可以

00:31:42.400 --> 00:31:43.020
這個

00:31:43.020 --> 00:31:46.480
幫我們按個星星

00:31:50.500 --> 00:31:52.820
那還有沒有其他問題呢

00:31:52.820 --> 00:31:56.480
大家有沒有問題要問的呢

00:31:58.660 --> 00:31:59.480
有啊

00:32:00.020 --> 00:32:01.680
有啊

00:32:02.480 --> 00:32:02.660
這邊

00:32:04.800 --> 00:32:06.540
請問學長就是

00:32:06.540 --> 00:32:08.660
如果是它這兩個模型

00:32:08.660 --> 00:32:10.400
在那個融合上

00:32:10.400 --> 00:32:12.960
會不會有latency的問題出現

00:32:12.960 --> 00:32:14.440
然後如果有latency的話

00:32:14.440 --> 00:32:18.580
那目前有沒有什麼方法讓它加速

00:32:18.580 --> 00:32:21.120
這個其實也是我們的賣點

00:32:21.120 --> 00:32:22.600
就是在過去

00:32:22.600 --> 00:32:24.540
譬如說你做nbas

00:32:24.540 --> 00:32:27.240
或是做這種gr

00:32:27.240 --> 00:32:29.800
你都是語音辨識跑完

00:32:29.800 --> 00:32:31.520
然後你有n個組合

00:32:31.520 --> 00:32:33.260
然後把這n個組合放到

00:32:33.260 --> 00:32:35.560
原模型去做

00:32:35.560 --> 00:32:36.900
這個校正

00:32:36.900 --> 00:32:39.500
所以你要先做完ASR

00:32:39.500 --> 00:32:40.660
再做校正

00:32:40.660 --> 00:32:43.200
但是現在我們把它合在一起了

00:32:43.200 --> 00:32:45.300
所以你可以平行出力

00:32:45.300 --> 00:32:48.900
所以它可以做到latency比較低

00:32:48.900 --> 00:32:50.800
即時性的效果

00:32:50.800 --> 00:32:53.080
那它那個實驗數據上有

00:32:53.080 --> 00:32:55.300
跟原本的比較說

00:32:55.300 --> 00:32:57.040
就是速度上差了多少

00:32:57.040 --> 00:33:00.480
在我們的paper我們現在比較專注的是算法

00:33:00.480 --> 00:33:02.320
沒有去衡量那個

00:33:02.320 --> 00:33:04.140
但未來應該會

00:33:04.140 --> 00:33:05.820
然後跟大家預告一下

00:33:05.820 --> 00:33:07.580
就是我們這個會開源

00:33:07.580 --> 00:33:11.480
就是please加上wisper這個會開源

00:33:11.480 --> 00:33:13.380
但我們會再研發一個

00:33:13.380 --> 00:33:15.100
比較小一點的

00:33:15.100 --> 00:33:16.440
做商用

00:33:16.440 --> 00:33:19.500
因為太大的latency

00:33:19.500 --> 00:33:20.400
還是比較大一點

00:33:21.340 --> 00:33:21.860
謝謝

00:33:23.180 --> 00:33:24.560
我稍微補充一下

00:33:24.560 --> 00:33:27.360
就是因為我們提到latency

00:33:27.360 --> 00:33:28.080
其實我們的

00:33:28.080 --> 00:33:30.640
我們主要是先證明

00:33:30.640 --> 00:33:33.360
這個理論上的這個

00:33:33.360 --> 00:33:33.920
complexity

00:33:33.920 --> 00:33:35.180
以及可行性

00:33:35.180 --> 00:33:36.420
所以我們在code的部分

00:33:36.420 --> 00:33:39.240
也還沒有實做這個平行化的過程

00:33:39.240 --> 00:33:41.080
但是這個是可以被達到

00:33:41.080 --> 00:33:43.920
因為就是有那些式子推導的結果

00:33:43.920 --> 00:33:46.080
就是它可以平行出力

00:33:48.440 --> 00:33:51.200
大家有沒有問題想要

00:33:51.200 --> 00:33:53.100
趁這個機會問的呢

00:33:58.900 --> 00:34:01.640
有關這個LLM rescoring的部分

00:34:01.640 --> 00:34:04.020
我有一個framework上的問題

00:34:04.020 --> 00:34:05.300
比較大的問題就是說

00:34:05.300 --> 00:34:07.200
我們現在走的是這個

00:34:07.200 --> 00:34:08.960
rescoring的路線

00:34:08.960 --> 00:34:10.500
比如說這個wisper

00:34:10.500 --> 00:34:11.340
up一個東西

00:34:11.340 --> 00:34:13.700
然後LLM去做rescoring

00:34:13.700 --> 00:34:15.580
那有考慮過

00:34:15.580 --> 00:34:17.920
現在場受的另外一個面向是

00:34:17.920 --> 00:34:19.600
直接把LLM的

00:34:19.600 --> 00:34:20.920
speeching code接在一起

00:34:20.920 --> 00:34:23.060
然後做個end to end的training

00:34:23.060 --> 00:34:24.460
當然這個比較麻煩

00:34:24.460 --> 00:34:24.940
也要training

00:34:24.940 --> 00:34:26.260
但就performance上

00:34:26.260 --> 00:34:29.260
這個有沒有什麼樣的經驗或比較呢

00:34:30.239 --> 00:34:31.900
是不是有點像鼓舞謎題呢

00:34:34.460 --> 00:34:35.920
這個部分就是

00:34:35.920 --> 00:34:37.100
有讀過一些paper

00:34:37.100 --> 00:34:40.260
可是好像我也沒辦法去

00:34:41.040 --> 00:34:42.060
去ground說

00:34:42.060 --> 00:34:45.580
它到底跟join fusion的

00:34:45.580 --> 00:34:47.739
成效上的差異在哪裡

00:34:47.739 --> 00:34:48.719
因為它還要training

00:34:48.719 --> 00:34:51.120
那training會受到一些data的影響

00:34:51.120 --> 00:34:52.660
不過我倒是有讀到

00:34:52.660 --> 00:34:54.620
一篇有趣的文章

00:34:54.620 --> 00:34:56.320
它是MIT發的

00:34:56.320 --> 00:34:57.200
我忘記名字是什麼

00:34:57.200 --> 00:34:59.080
但是它是說這個

00:34:59.080 --> 00:35:01.580
wisper decoder是

00:35:01.580 --> 00:35:05.160
attempt在noisy的speech的encoder上面

00:35:05.160 --> 00:35:05.660
意思就是說

00:35:05.660 --> 00:35:07.620
它speech encoder出來的東西

00:35:07.620 --> 00:35:09.420
好像還是有帶個noise的資訊

00:35:09.420 --> 00:35:10.980
然後decoder會把它劃掉

00:35:10.980 --> 00:35:14.020
所以現在我再讀到那篇論文之後

00:35:14.020 --> 00:35:16.600
我感覺現在直接把decoder扔掉

00:35:17.400 --> 00:35:19.660
然後扛住一個大語言模型的做法

00:35:19.660 --> 00:35:21.360
可能會傷害到這件事情

00:35:21.360 --> 00:35:22.980
那就需要data去repair

00:35:22.980 --> 00:35:24.980
那也可能還要再去探究說

00:35:24.980 --> 00:35:26.860
多少data可以repair到

00:35:26.860 --> 00:35:27.860
wisper decoder

00:35:28.680 --> 00:35:30.100
可能rama的decoder

00:35:30.100 --> 00:35:31.600
可以去正確attempt到

00:35:31.600 --> 00:35:32.840
wisper的noise

00:35:32.840 --> 00:35:33.800
noisy的encoder

00:35:35.560 --> 00:35:36.900
我知道說現在這個做法

00:35:36.900 --> 00:35:38.160
其實是一個很

00:35:39.040 --> 00:35:40.400
快速減變的做法

00:35:40.400 --> 00:35:42.160
因為你其實不需要trick任何東西

00:35:42.160 --> 00:35:43.660
你把兩個線路的模型接起來

00:35:43.660 --> 00:35:45.440
就可以boost the performance

00:35:48.060 --> 00:35:48.840
這邊到這邊

00:35:48.840 --> 00:35:59.820
大家有沒有什麼問題想問的呢

00:35:59.820 --> 00:36:00.840
有嗎

00:36:04.080 --> 00:36:05.500
我有些high level的問題

00:36:05.500 --> 00:36:06.880
不知道大家願不願意聊一聊

00:36:07.299 --> 00:36:08.820
那個聯發創新中心

00:36:08.820 --> 00:36:10.760
是在還沒有change vt的時候

00:36:10.760 --> 00:36:13.000
就在做大型語言模型了

00:36:13.000 --> 00:36:14.219
在還沒有change vt的時候

00:36:14.219 --> 00:36:16.520
你說要做類似大型語言模型這種東西

00:36:16.520 --> 00:36:19.219
應該還蠻多challenge的

00:36:19.219 --> 00:36:20.380
比如說質疑啊

00:36:20.380 --> 00:36:22.340
這個東西能做嗎

00:36:22.340 --> 00:36:24.520
你們怎麼支撐下來的

00:36:25.860 --> 00:36:27.140
因為我們其實是研究院

00:36:27.140 --> 00:36:28.860
比較自由一點

00:36:28.860 --> 00:36:30.520
所以題目我們可以去

00:36:31.120 --> 00:36:32.800
測一些

00:36:32.800 --> 00:36:34.660
其實跟公司的本業

00:36:34.660 --> 00:36:36.440
沒有關係的

00:36:36.440 --> 00:36:38.340
其實現在也一直在做

00:36:38.340 --> 00:36:41.360
其他的一些比較advanced的研究

00:36:41.360 --> 00:36:42.820
一直都有在進行

00:36:42.820 --> 00:36:45.780
所以並沒有太多的壓力

00:36:45.780 --> 00:36:48.920
我們可以比較自由的去發展

00:36:48.920 --> 00:36:50.520
了解了解

00:36:50.520 --> 00:36:51.140
謝謝

00:36:51.140 --> 00:37:00.320
大家還有沒有問題想要問的呢

00:37:00.320 --> 00:37:00.780
有嗎

00:37:01.840 --> 00:37:02.980
如果沒有的話

00:37:02.980 --> 00:37:05.780
我其實準備了小禮物

00:37:10.140 --> 00:37:11.260
其實是這樣子

00:37:11.780 --> 00:37:12.500
每一年

00:37:12.500 --> 00:37:14.860
我的機器學習的課程

00:37:14.860 --> 00:37:18.140
都會送給所有作業滿分的

00:37:18.140 --> 00:37:19.700
同學一個T恤

00:37:19.700 --> 00:37:21.140
今年沒有機器學習的課程

00:37:21.140 --> 00:37:21.900
所以沒有今年的

00:37:21.900 --> 00:37:22.960
但去年的有

00:37:22.960 --> 00:37:25.420
其實湛然哥穿的這件是2022年版

00:37:25.420 --> 00:37:27.020
是他當助教的時候

00:37:27.020 --> 00:37:28.260
自己設計的

00:37:28.260 --> 00:37:30.320
現在我送湛然哥

00:37:30.320 --> 00:37:33.360
倚昌哥2023年版的

00:37:33.880 --> 00:37:34.320
謝謝

00:37:38.700 --> 00:37:43.700
我要合照一下

00:37:43.700 --> 00:37:45.680
這好像設計的比你好看

00:38:02.480 --> 00:38:04.700
有人想要問問題的嗎

00:38:05.300 --> 00:38:06.219
如果沒有的話

00:38:06.219 --> 00:38:08.200
那我們就再次給兩

00:38:08.200 --> 00:38:09.660
我再跟大家合個照

00:38:09.660 --> 00:38:10.760
你要合個照

00:38:10.760 --> 00:38:11.540
怎麼做

00:38:13.700 --> 00:38:14.719
可以啊

00:38:16.800 --> 00:38:17.880
謝謝

00:38:17.880 --> 00:38:20.880
那你們可以熱情一點

00:38:33.580 --> 00:38:34.060
謝謝

00:38:39.640 --> 00:38:40.680
謝謝

00:38:46.760 --> 00:38:49.600
如果大家沒有問題的話

00:38:49.600 --> 00:38:52.640
那今天的掌聲就到這邊

00:38:52.640 --> 00:38:53.380
謝謝大家

00:38:53.380 --> 00:38:54.440
謝謝