Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save doggy8088/412f1eb397c483d79c20a68ad77cddf5 to your computer and use it in GitHub Desktop.
Save doggy8088/412f1eb397c483d79c20a68ad77cddf5 to your computer and use it in GitHub Desktop.
2024 NTU GenAI MTK研究人員專題演講總結與 WebVTT 字幕 (License: Public Domain)

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 研究人員專題演講 (下半場)

重點總結與知識點

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
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
有嗎