WEBVTT
Kind: captions
Language: zh-Hant

00:00:00.000 --> 00:00:03.700
最近有一個叫Jev的AI Model非常爆紅

00:00:03.960 --> 00:00:05.460
大家如果有上網

00:00:05.640 --> 00:00:08.920
應該都見到很多人討論這個AI Model

00:00:09.700 --> 00:00:11.500
這個叫Jev的AI Model

00:00:11.700 --> 00:00:15.920
其實是由一間叫TypeSafe AI的公司發佈的

00:00:15.920 --> 00:00:18.640
這間公司已經成立了2年

00:00:18.860 --> 00:00:22.920
只不過最近才發佈了這個Jev模型

00:00:23.180 --> 00:00:27.980
同時亦宣佈完成了一輪融資

00:00:28.100 --> 00:00:31.840
應該是Seed Round 籌集了大約4000萬美元

00:00:33.060 --> 00:00:38.700
這個叫Jev的AI Model 首先它不是大型語言模型

00:00:38.940 --> 00:00:44.440
例如ChatGPT、Gemini這些才是大型語言模型

00:00:44.580 --> 00:00:47.800
它們的性質像一個Chatbot 會跟你聊天

00:00:48.680 --> 00:00:53.500
它們執行你的任務之餘 亦可能會說很多廢話

00:00:53.840 --> 00:00:57.860
因為LLM的本質就是不停重複

00:00:58.680 --> 00:01:00.480
去Generate the Next Token

00:01:01.100 --> 00:01:05.900
但是這個Jev的AI Model 完全不是這樣的東西

00:01:06.400 --> 00:01:09.080
它技術方面的東西我稍後再說

00:01:09.080 --> 00:01:11.720
我先說一下它的創辦人

00:01:11.720 --> 00:01:15.860
TypeSafe AI這間公司的創辦人

00:01:15.860 --> 00:01:17.700
就是Diogo Almeida

00:01:18.330 --> 00:01:21.440
他之前在OpenAI工作

00:01:21.440 --> 00:01:28.340
他亦有參與InstructGPT這篇論文

00:01:29.540 --> 00:01:31.780
是作者之一 並有參與這項研究

00:01:31.980 --> 00:01:35.160
InstructGPT當然是非常重要

00:01:35.720 --> 00:01:40.820
因為例如在GPT-3之前

00:01:41.680 --> 00:01:48.920
大型語言模型的能力或訓練目標

00:01:49.140 --> 00:01:52.980
都是很單純地預測下一個字、下一個Token

00:01:53.580 --> 00:02:00.680
但自從OpenAI研究了InstructGPT之後

00:02:00.760 --> 00:02:06.040
它能夠將大型語言模型的Output

00:02:06.040 --> 00:02:12.500
與人類的意圖保持一致

00:02:12.500 --> 00:02:17.340
例如人類交給大型語言模型的任務

00:02:17.500 --> 00:02:22.900
可能你叫模型寫一封辭職信或一份計劃書

00:02:22.900 --> 00:02:27.140
模型就會根據你的任務和文字

00:02:27.680 --> 00:02:31.840
或計劃書的目的 去寫出那段文字

00:02:33.240 --> 00:02:37.560
自從有了InstructGPT之後

00:02:38.180 --> 00:02:42.820
大型語言模型才真正可以做到這樣的功能

00:02:42.820 --> 00:02:44.560
並且做得很準確

00:02:44.720 --> 00:02:51.740
而且InstructGPT亦確立了 強化學習的技術模式

00:02:54.360 --> 00:02:58.940
這個叫Jev的AI Model本質上是一個Decision Engine

00:02:59.420 --> 00:03:03.700
或者更準確地說 它算是一個Classifier Model

00:03:04.280 --> 00:03:10.320
舉一個例子 你有一封電郵和電郵的文字

00:03:10.560 --> 00:03:14.500
你想知道這封電郵究竟是客戶電郵

00:03:14.500 --> 00:03:17.360
還是垃圾郵件

00:03:18.160 --> 00:03:23.320
使用方法就是將電郵的文字

00:03:23.320 --> 00:03:25.120
交給這個Jev的AI Model

00:03:25.120 --> 00:03:29.320
然後給它幾個選擇

00:03:29.340 --> 00:03:31.980
A是客戶電郵 還是B是垃圾郵件

00:03:32.500 --> 00:03:35.180
如果它告訴你這是客戶電郵

00:03:35.180 --> 00:03:41.500
你可能想知道這封電郵是投訴 還是一般查詢

00:03:42.140 --> 00:03:45.140
如果是投訴 客戶現在是否很生氣

00:03:45.780 --> 00:03:50.000
模型不是寫文章 亦不會長篇大論

00:03:50.000 --> 00:03:54.920
它回傳的Output只是你給的選擇

00:03:55.040 --> 00:03:58.800
它會作出選擇 或給每個選擇一個機率

00:03:58.960 --> 00:04:02.960
又或者你問它是或不是

00:04:02.960 --> 00:04:05.560
它會給出是與不是的機率或分數

00:04:07.380 --> 00:04:12.000
為甚麼大家熱烈討論這個模型 這麼興奮

00:04:12.000 --> 00:04:18.260
原因是現在尤其是使用AI Agent時

00:04:19.400 --> 00:04:25.240
AI Agent很多時會呼叫大型語言模型

00:04:26.120 --> 00:04:31.640
最大的問題是 這些AI Agent不停呼叫大型語言模型時

00:04:31.880 --> 00:04:34.640
哪怕你只是做很少的事

00:04:34.880 --> 00:04:38.640
模型在背後其實真的會做Inference

00:04:38.640 --> 00:04:43.000
用很多Token長篇大論 雖然大部分人都不會看

00:04:43.560 --> 00:04:46.600
但事實上它就是消耗了這麼多Token

00:04:49.420 --> 00:04:53.160
其實Jev這個AI Model的運作並不複雜

00:04:53.340 --> 00:04:57.020
它和大型語言模型最重要的分別在於

00:04:57.020 --> 00:05:01.820
你除了要給它問題或任務的文字之外

00:05:01.820 --> 00:05:05.860
還必須要給一系列的選擇

00:05:06.100 --> 00:05:08.220
選擇可能很簡單 是一個是非題

00:05:08.220 --> 00:05:12.240
Jev就在Yes or No之間做選擇

00:05:12.320 --> 00:05:14.540
或者分配一個概率

00:05:15.040 --> 00:05:20.080
或者是一個MCQ A至E五個答案中

00:05:20.820 --> 00:05:23.400
哪一個正確 或者機會率最大

00:05:24.020 --> 00:05:29.380
你最多可以給255個選擇

00:05:30.200 --> 00:05:33.020
記住選擇是必須的

00:05:33.580 --> 00:05:40.980
舉一個例子 現在一間診所裡有一位45歲女病人

00:05:41.120 --> 00:05:45.480
她的BP是184/112 沒有特別症狀

00:05:45.480 --> 00:05:50.520
亦沒有特別不適 測試結果正常

00:05:50.740 --> 00:05:55.640
究竟這個女人需不需要去急症室

00:05:55.760 --> 00:06:00.100
或者她的情況有多危急 有多緊急

00:06:00.100 --> 00:06:04.180
以1至5評分 5最緊急 1不緊急

00:06:04.320 --> 00:06:07.800
Jev的應用場景就是這樣

00:06:08.720 --> 00:06:16.540
為方便一些做Tech的朋友試用Jev的AI Model

00:06:16.540 --> 00:06:21.480
我亦寫了一些Code作為Example

00:06:22.040 --> 00:06:25.540
給大家參考試用 亦已放上GitHub

00:06:25.820 --> 00:06:29.940
而最重要的是 我亦測試了一些任務

00:06:29.980 --> 00:06:32.040
當然我們做醫學人工智能

00:06:37.060 --> 00:06:40.780
剛才我提到那位女士血壓這麼高的情況下

00:06:40.960 --> 00:06:43.660
究竟有多危急 需不需要去A&E

00:06:43.960 --> 00:06:49.300
就是這些例子 當然這些例子本身是有答案的

00:06:49.940 --> 00:06:57.500
然後我們測試Jev在這些情境上表現好不好

00:06:58.160 --> 00:06:59.800
LLM的表現又好不好

00:06:59.860 --> 00:07:05.340
又或者你將Qwen 27B的Model 放到你的Mac上運行

00:07:05.340 --> 00:07:07.560
那就不需要Token 當然會較慢

00:07:07.660 --> 00:07:10.620
但它不需要花錢 亦是用你自己的電腦

00:07:11.000 --> 00:07:13.240
究竟效果又如何

00:07:13.360 --> 00:07:16.120
我們亦將結果放上去了

00:07:27.380 --> 00:07:29.680
I'm the king of the keys No crown on my dome

00:07:29.680 --> 00:07:32.780
ChatGPT spitting scripts Making AI my home

00:07:32.780 --> 00:07:35.780
Gemini twin flows Split brains in the zone

00:07:35.780 --> 00:07:38.420
DeepSeek visions Seeing truths never shown

00:07:38.420 --> 00:07:40.900
Claude in my corner Whisper moves like a sage

00:07:40.900 --> 00:07:43.580
Lines so clean Got em popping off the page

00:07:43.580 --> 00:07:45.780
I don't CD That's alphabet soup

00:07:45.780 --> 00:07:48.420
I'm the vibe of the code Making systems salute

00:07:48.420 --> 00:07:51.220
I'm the king of coding No crown no throne

00:07:51.220 --> 00:07:53.980
Turn words into magic I'm a vibe on my own

00:07:53.980 --> 00:07:56.580
Chatbots and cosmos Most the digital roam

00:07:56.580 --> 00:07:59.420
The king of coding in the cloud I'm home

00:08:02.480 --> 00:08:06.740
接著我說一下我對Jev這個AI Model的看法

00:08:07.900 --> 00:08:09.780
根據TypeSafe AI所說

00:08:09.960 --> 00:08:15.560
Jev這個AI Model的功能或定位

00:08:16.540 --> 00:08:19.400
又或者說它針對的痛點

00:08:19.400 --> 00:08:22.460
就是現今我們使用大型語言模型時

00:08:22.560 --> 00:08:25.320
尤其是使用Agent的時候

00:08:25.560 --> 00:08:30.020
Agent每一個步驟都會呼叫大型語言模型

00:08:30.200 --> 00:08:32.980
無論你用哪一個API 哪間公司的模型

00:08:33.120 --> 00:08:35.600
其實你每次呼叫的時候

00:08:35.760 --> 00:08:39.880
哪怕只是一個很簡單的決定

00:08:40.320 --> 00:08:42.120
或者一個很簡單的任務

00:08:42.200 --> 00:08:45.980
背後經常都會消耗很多Token

00:08:46.800 --> 00:08:51.080
它的論點是 這些Token是否真的必須這樣消耗

00:08:51.180 --> 00:08:55.240
因為老實說 你的AI Agent在背後做的事

00:08:55.880 --> 00:08:59.480
它在背後回傳的那些文字

00:08:59.480 --> 00:09:03.500
大部分時間只是AI Agent自己看 你不會看

00:09:03.980 --> 00:09:09.340
對大部分人來說 一些很Minor的決定

00:09:09.860 --> 00:09:12.200
你最重要是告訴我是或不是 做或不做

00:09:12.200 --> 00:09:14.260
或者用甚麼工具就可以

00:09:14.400 --> 00:09:17.300
為甚麼需要浪費這麼多Token

00:09:17.500 --> 00:09:21.700
這就是TypeSafe AI對Jev功能的看法

00:09:21.880 --> 00:09:24.340
又或者可以說是他們的Pitch

00:09:25.480 --> 00:09:28.600
毫無疑問 這個Pitch非常成功

00:09:28.660 --> 00:09:31.960
因為大家都感受到那種痛點

00:09:32.080 --> 00:09:37.680
因為大家用AI Agent去寫Program 寫Code

00:09:37.680 --> 00:09:39.900
你真的覺得好像在燒錢一樣

00:09:40.860 --> 00:09:45.380
但我的看法是 這是一個很好的Pitch

00:09:45.800 --> 00:09:50.040
但算不上是一個重大的技術突破

00:09:50.480 --> 00:09:56.960
因為如果從技術角度去看 我覺得Jev像一個Classifier Model

00:09:57.240 --> 00:10:00.480
當然它有理解語言的部分

00:10:00.560 --> 00:10:02.640
我相信這是Embedding Model做的事

00:10:02.760 --> 00:10:07.220
亦涉及一些Re-ranker的Algorithm

00:10:07.920 --> 00:10:13.440
但我剛才說的這幾樣東西絕對不是新技術

00:10:13.740 --> 00:10:19.580
因為你也可以想像 你說的是4000萬美元的Funding

00:10:19.860 --> 00:10:23.820
如果你要做大型語言模型

00:10:24.060 --> 00:10:27.240
尤其要與現在市面上的Frontier Model競爭

00:10:27.340 --> 00:10:31.180
根本不夠錢 4000萬美元不可能做LLM

00:10:31.600 --> 00:10:38.140
你唯一可能做到突破的

00:10:38.140 --> 00:10:40.720
就是在剛才說的Classifier Model

00:10:40.980 --> 00:10:44.120
再加Embedding Model的層次上去做

00:10:44.840 --> 00:10:48.260
所以我覺得這個Pitch很好 亦是很好的Marketing

00:10:48.400 --> 00:10:50.280
至少現在這麼多人在討論

00:10:50.480 --> 00:10:53.840
取得Traction之後再籌集更多資金

00:10:54.020 --> 00:10:55.600
再想下一步怎樣做

00:10:55.720 --> 00:10:57.840
這可能是他們現在的策略

00:10:58.600 --> 00:11:03.720
所以我不覺得這是一個重大的技術突破

00:11:03.800 --> 00:11:05.980
反而另一位 我想是他的同事

00:11:06.060 --> 00:11:09.420
以前OpenAI的CTO

00:11:09.500 --> 00:11:11.780
那位女士 我不記得她叫甚麼名字

00:11:12.560 --> 00:11:15.840
她出來亦成立了一間AI公司

00:11:15.960 --> 00:11:18.180
那個反而算是一個技術突破

00:11:18.260 --> 00:11:20.200
因為她說的是用影像

00:11:21.140 --> 00:11:25.200
原生地作為語言模型的Input

00:11:25.700 --> 00:11:27.360
這其實是很難做到的

00:11:27.520 --> 00:11:30.700
我不是說她一定會成功

00:11:30.700 --> 00:11:34.620
但純粹從技術來說 前OpenAI CTO

00:11:35.400 --> 00:11:38.520
那位女士做的反而真的是技術突破

00:11:38.700 --> 00:11:40.200
而Jev不是

00:11:43.140 --> 00:11:49.000
所以要視乎你做的事、任務或決定有多複雜

00:11:49.380 --> 00:11:52.200
舉個例子 純粹做電郵分類

00:11:52.200 --> 00:11:54.920
可能你的公司每日有幾百封Email

00:11:55.620 --> 00:11:58.980
或者你做網店 每日有幾百個查詢

00:11:59.100 --> 00:12:05.840
你要對那些Email、查詢或客戶訊息

00:12:06.000 --> 00:12:08.500
純粹做分類 例如你的Ticket System

00:12:08.500 --> 00:12:10.980
要看那個Ticket有多Urgent

00:12:11.480 --> 00:12:14.700
如果很急 可能你會分為極急

00:12:14.700 --> 00:12:16.800
立即處理 客戶很生氣就先處理

00:12:16.800 --> 00:12:18.560
一般查詢就稍後

00:12:19.300 --> 00:12:23.500
如果純粹是電郵或客戶訊息

00:12:23.860 --> 00:12:26.700
用Jev這類模型 我覺得是對的

00:12:26.700 --> 00:12:29.700
因為一來成本會較便宜

00:12:29.820 --> 00:12:32.200
二來反應時間會較快

00:12:32.200 --> 00:12:36.400
而且這類System很多時未必即時自動回覆

00:12:36.940 --> 00:12:39.420
可能都會經過人手客服再覆核

00:12:39.540 --> 00:12:43.700
在這類情況下用Jev是合理的

00:12:43.700 --> 00:12:47.740
或者用Jev分類後再交給LLM處理亦可以

00:12:48.640 --> 00:12:53.200
但如果你做的事或任務有一定複雜程度

00:12:53.240 --> 00:12:56.500
你可能仍需要用回傳統語言模型

00:12:56.500 --> 00:13:00.740
就算你的任務純粹是做決定

00:13:00.860 --> 00:13:04.180
不涉及生成文章或回覆客戶Email

00:13:04.520 --> 00:13:06.960
不需要生成文字 純粹做決定

00:13:07.040 --> 00:13:09.300
我想你仍是用回傳統語言模型

00:13:09.400 --> 00:13:12.240
例如Claude、GPT這類Frontier Model

00:13:12.540 --> 00:13:14.380
它們的判斷做得好

00:13:15.180 --> 00:13:18.200
原因是它們可能會一步一步地思考

00:13:18.200 --> 00:13:20.340
它們有Chain of Thought

00:13:21.080 --> 00:13:25.980
你可以選擇Thinking是High還是Low

00:13:25.980 --> 00:13:28.960
用多少思考力去做

00:13:29.500 --> 00:13:32.200
複雜的任務或判斷

00:13:32.200 --> 00:13:36.040
你可能真的需要看當中的細節

00:13:36.100 --> 00:13:38.980
或者重點 才可以作出結論

00:13:39.140 --> 00:13:42.820
而這個過程是做Chain of Thought

00:13:42.820 --> 00:13:45.620
真的要消耗Token

00:13:45.620 --> 00:13:48.680
你不可以說是浪費 不可以說不是必須

00:13:49.300 --> 00:13:55.100
很多時有些Tasks要看很多細節

00:13:55.100 --> 00:13:58.360
你不看細節 不讓它一步一步思考

00:13:58.360 --> 00:14:00.640
就有很大機會出錯

00:14:00.640 --> 00:14:02.820
例如一個男人有性病

00:14:02.900 --> 00:14:05.980
他是否一定出去鬼混 未必

00:14:06.380 --> 00:14:08.200
表面看似是這樣 但不一定

00:14:08.200 --> 00:14:10.320
他的女朋友濫交又行不行

00:14:10.740 --> 00:14:12.320
或者那個男人走過砵蘭街

00:14:12.480 --> 00:14:15.200
被水淋到後染上性病又行不行 很無辜

00:14:16.620 --> 00:14:22.960
我說到這裡 一定有些有識之士會在留言更正我

00:14:23.180 --> 00:14:26.140
如果你走過砵蘭街被水淋到

00:14:26.220 --> 00:14:28.800
在醫學上是絕對不會染上性病的

00:14:28.960 --> 00:14:31.500
因為DeepSeek、Gemini都是這樣說

00:14:33.280 --> 00:14:37.720
其實我想說 我做這些節目

00:14:37.900 --> 00:14:40.000
或這些題目這麼悶

00:14:40.000 --> 00:14:43.640
有時搞搞笑 搞搞氣氛都可以

00:14:43.640 --> 00:14:47.820
我覺得有時大家缺乏了一些幽默感

00:14:48.620 --> 00:14:52.260
就像上次我的影片 我說梅建國

00:14:53.260 --> 00:14:58.760
真的有網友很認真地留言說

00:14:59.840 --> 00:15:03.100
梅建國其實是網民搞笑的

00:15:03.260 --> 00:15:05.120
Allen竟然當真

00:15:05.200 --> 00:15:08.880
然後說這就證明了

00:15:09.040 --> 00:15:12.080
AI幻覺的最佳例證

00:15:12.920 --> 00:15:18.220
老實說 美斯是否真的叫梅建國 我真的不知道

00:15:18.220 --> 00:15:22.440
我不肯定 但我可以很肯定地告訴大家

00:15:22.960 --> 00:15:25.660
美斯是王敏德

00:15:28.260 --> 00:15:31.360
另一個問題是 OpenAI、Gemini

00:15:31.660 --> 00:15:35.180
或DeepSeek這類模型

00:15:35.280 --> 00:15:38.960
現在亦有推出所謂Mini或Flash版本

00:15:39.060 --> 00:15:42.200
它們針對的應用場景

00:15:42.200 --> 00:15:45.800
是一些不需要太多思考又要快的

00:15:46.160 --> 00:15:48.500
任務或工作

00:15:49.300 --> 00:15:52.720
當然Jev可以反駁

00:15:53.100 --> 00:15:56.840
這些Flash Model、Mini Model都會消耗Token

00:15:57.700 --> 00:16:01.980
但就我個人的使用經驗而言

00:16:02.060 --> 00:16:03.680
未必代表大多數人

00:16:03.820 --> 00:16:07.940
但這類Flash Model

00:16:08.520 --> 00:16:12.600
無論你的prompt怎樣寫 我覺得都夠快亦夠便宜

00:16:12.800 --> 00:16:17.080
當然你不可以將它與Jev這類

00:16:17.760 --> 00:16:20.420
Classifier Model性質的東西比較

00:16:20.620 --> 00:16:25.760
但你說Flash Model是否真的很貴 我又覺得不是

00:16:25.860 --> 00:16:30.120
如果要我衡量任務的準確性

00:16:30.340 --> 00:16:33.920
即做出來的準確性 或判斷的準確性

00:16:35.380 --> 00:16:38.340
相對速度的Trade Off

00:16:38.480 --> 00:16:43.560
我寧願做慢一點 而不犧牲準確性

00:16:43.720 --> 00:16:45.740
如果你為了省錢

00:16:46.640 --> 00:16:54.580
而用Jev這類Model令你的決策出錯

00:16:54.720 --> 00:16:55.980
我覺得不太值得

00:16:56.460 --> 00:16:59.720
就算要等AI Agent 你先喝杯咖啡吧

00:16:59.840 --> 00:17:03.220
我覺得其實不是那麼Time Critical的事

00:17:03.340 --> 00:17:08.500
我覺得交回LLM去做會比較放心

00:17:09.480 --> 00:17:12.060
這就是我的結論

00:17:12.200 --> 00:17:14.700
但正如我剛才所說 他們的Pitch做得好

00:17:14.700 --> 00:17:17.660
因為這的確是一個痛點

00:17:17.840 --> 00:17:22.120
如果用Jev做一個Cheap Filter

00:17:22.300 --> 00:17:25.200
在大型語言模型之前先過濾

00:17:25.200 --> 00:17:28.200
或者有些任務很簡單就可以作決定

00:17:28.200 --> 00:17:30.980
我覺得用Jev是合理的

00:17:31.020 --> 00:17:37.040
但如果完全用Jev取代所有Decision Making

00:17:37.100 --> 00:17:38.800
這點我就不同意了

00:17:41.820 --> 00:17:46.320
這個叫Jev的AI Model 其實是向Jevons Paradox致敬

00:17:46.320 --> 00:17:52.160
Jevons Paradox是一個經濟學現象

00:17:52.160 --> 00:17:55.620
它說的是當技術進步到一定程度

00:17:55.940 --> 00:17:59.800
令某種資源的使用效率提高時

00:18:00.420 --> 00:18:04.100
該資源的總消耗量 我們很多時以為

00:18:05.280 --> 00:18:09.220
提高效率 整體上會用少了那些資源

00:18:09.880 --> 00:18:12.180
但很多時發現並不是

00:18:12.780 --> 00:18:16.700
其中一個例子是引擎的改進

00:18:16.700 --> 00:18:21.360
技術進步令引擎更省油

00:18:22.780 --> 00:18:28.580
省油之後 我們以為對燃油的整體需求會減少

00:18:28.700 --> 00:18:32.420
其實不但沒有減少 反而上升

00:18:32.620 --> 00:18:38.660
另一個例子是電訊 即數據傳輸技術

00:18:39.140 --> 00:18:41.680
例如4G、5G

00:18:42.480 --> 00:18:48.300
技術進步令數據傳輸速度更快

00:18:49.160 --> 00:18:51.040
或成本降低

00:18:51.160 --> 00:18:54.620
我們會否以為人們會用少了數據

00:18:54.800 --> 00:18:58.220
答案當然不是 現在的人不只看文字

00:18:58.300 --> 00:19:01.440
不只看圖片 就算看影片都可能要求高

00:19:01.540 --> 00:19:05.300
高質素的4K、8K串流影片

00:19:05.800 --> 00:19:08.060
或者會做更多以前沒有的事

00:19:08.860 --> 00:19:11.500
例如線上會議或線上遊戲等等

00:19:12.360 --> 00:19:15.280
數據的總消耗量

00:19:15.380 --> 00:19:19.640
並沒有因為技術提升而下跌

00:19:19.800 --> 00:19:24.820
其實Jevons Paradox就是說這樣的事

00:19:25.300 --> 00:19:27.440
好 時間到了 多謝大家