WEBVTT
Kind: captions
Language: zh-TW

00:00:04.333 --> 00:00:04.700
哈囉，大家好

00:00:04.700 --> 00:00:05.800
歡迎收聽科技浪

00:00:05.833 --> 00:00:06.933
我是主持人哈利

00:00:06.966 --> 00:00:09.833
科技浪是一個白話跟你聊科技的 Podcast

00:00:09.866 --> 00:00:11.233
希望可以用簡單易懂

00:00:11.233 --> 00:00:16.466
但是又深入的方式，帶你了解時下最火的科技話題

00:00:16.500 --> 00:00:19.366
本期節目由犀牛盾贊助播出

00:00:19.366 --> 00:00:19.600
好

00:00:19.600 --> 00:00:20.866
那過去這一週

00:00:20.900 --> 00:00:23.733
就是算是蘋果發表會結束的第二週

00:00:23.766 --> 00:00:27.000
就是有一些初步的評測都已經出來了嘛

00:00:27.000 --> 00:00:27.200
對不對？

00:00:27.200 --> 00:00:30.533
我不知道大家看到這個 iPhone 18 Pro

00:00:30.566 --> 00:00:32.600
有沒有決定要購買呢？

00:00:32.633 --> 00:00:33.633
當然

00:00:33.666 --> 00:00:35.866
跟 17 Pro 比起來

00:00:35.900 --> 00:00:39.600
確實沒有多少的更新，對不對？

00:00:39.600 --> 00:00:41.866
但我自己還是會換

00:00:41.866 --> 00:00:45.800
因為我現在其實原本我的 iPhone

00:00:45.833 --> 00:00:51.000
我有很多支手機，那 iPhone 就是有一支 17 Pro

00:00:51.033 --> 00:00:54.300
它也算是我主要的手機之一

00:00:54.333 --> 00:00:58.166
那我還是會想換成 18 Pro，是為什麼呢？

00:00:58.166 --> 00:01:01.500
其實，老實說啦，單純看這個

00:01:01.500 --> 00:01:06.266
就目前看 CP 值，真的是沒有到那麼高，OK

00:01:06.566 --> 00:01:08.333
就你換了之後，你得到什麼？

00:01:08.433 --> 00:01:14.466
就更好的電池續航跟晶片效能以及相機

00:01:14.500 --> 00:01:16.966
那相機那邊就是有個可變光圈嘛

00:01:17.000 --> 00:01:17.700
對不對？

00:01:17.700 --> 00:01:19.000
然後當然還有顏色啦

00:01:19.500 --> 00:01:21.300
顏色對我來說還好啦

00:01:21.933 --> 00:01:23.700
好，那你就得到這些嘛

00:01:23.700 --> 00:01:26.600
那這個真的值得你多花那一兩萬塊嗎？

00:01:27.000 --> 00:01:29.066
我覺得對於很多人來說

00:01:29.066 --> 00:01:32.833
就現有的體驗來說是真的沒有到很值得，OK

00:01:33.066 --> 00:01:37.333
然後我自己本人，就我目前的使用狀況呢

00:01:37.333 --> 00:01:39.566
確實也真的沒有必要

00:01:39.600 --> 00:01:41.966
就是多花這一筆錢這樣子

00:01:42.000 --> 00:01:43.733
但我還是會換，是為什麼？

00:01:44.566 --> 00:01:47.766
因為我的想法是比較接近，我買了先放著

00:01:47.900 --> 00:01:51.033
這個能力我覺得我未來會用到，我買了先放著

00:01:51.200 --> 00:01:52.133
我現在還用不到

00:01:52.533 --> 00:01:56.566
我們今天這集業配時間比較長一點

00:01:56.600 --> 00:02:00.266
剛好願意跟大家分享一些我自己的想法

00:02:00.300 --> 00:02:02.633
我們現在都還沒講到業配產品

00:02:03.166 --> 00:02:07.000
反正我的想法就是，因為這個 iPhone 18 Pro

00:02:07.000 --> 00:02:11.100
他們用了這個新的晶片，叫做 A20 Pro 的晶片嘛

00:02:11.133 --> 00:02:11.666
對不對？

00:02:11.666 --> 00:02:14.433
它跟上一代 A19 Pro 比起來呢

00:02:14.466 --> 00:02:17.900
當然就是在各方面的表現都有提升啊

00:02:17.933 --> 00:02:18.966
那他們 demo

00:02:18.966 --> 00:02:21.866
很多打遊戲的散熱效果比較好啊等等的

00:02:21.900 --> 00:02:24.766
但那些評測員都沒有 demo 到的一點

00:02:24.766 --> 00:02:26.633
是它的 AI 運算的表現

00:02:26.900 --> 00:02:30.266
它的 AI 運算表現不是提升一點點而已喔

00:02:30.266 --> 00:02:31.500
提升非常多喔

00:02:31.566 --> 00:02:35.833
我看有一個網友發了他的測試在 X 上面

00:02:35.833 --> 00:02:40.900
他是跑 On-Device 的 Apple Foundation Model

00:02:40.933 --> 00:02:45.733
他發現一個長 prompt 的 time to first token

00:02:45.733 --> 00:02:50.633
直接從 A19 Pro 的 2000 多毫秒變成 1000 毫秒

00:02:50.666 --> 00:02:52.533
直接砍半

00:02:52.533 --> 00:02:54.666
整個 time to first token 都快非常多

00:02:54.900 --> 00:02:58.866
當然，我知道很多人就會說，蘋果根本就沒有 AI

00:02:58.900 --> 00:03:00.633
那你現在買來放著有什麼用？

00:03:00.633 --> 00:03:03.533
我覺得快了啦，真的快了啦

00:03:03.700 --> 00:03:05.166
你聽我們之前在分析

00:03:05.166 --> 00:03:07.266
Apple Intelligence 的那幾集

00:03:07.300 --> 00:03:09.700
Apple Foundation Model 的那幾集

00:03:09.700 --> 00:03:14.766
你就會知道蘋果在這邊已經有在做準備了

00:03:14.800 --> 00:03:17.400
尤其像這個更強的 Siri，iOS 27

00:03:17.433 --> 00:03:21.000
其實我不知道這個中文版到底什麼時候會推出

00:03:21.000 --> 00:03:22.766
但我覺得

00:03:22.766 --> 00:03:24.566
如果推出的時候

00:03:24.600 --> 00:03:29.100
大家中文版用到的是接近英文版的這種滿血狀態的話

00:03:29.100 --> 00:03:30.200
會很有感啦

00:03:30.233 --> 00:03:30.433
真的

00:03:30.466 --> 00:03:31.766
那如果你已經準備好

00:03:31.766 --> 00:03:33.633
要下單 iPhone 18 Pro 了

00:03:33.666 --> 00:03:35.300
手機殼也必須先準備好

00:03:35.300 --> 00:03:38.566
那這次要跟大家介紹我最近最喜歡的

00:03:38.600 --> 00:03:40.133
這個太空級防摔

00:03:40.133 --> 00:03:42.800
犀牛盾 AirX 極致氣墊緩衝殼

00:03:42.800 --> 00:03:45.666
那 AirX 的防護到底有多強呢？

00:03:45.700 --> 00:03:49.400
你知道犀牛盾他們把 AirX 送到瑞典太空中心

00:03:49.400 --> 00:03:52.733
進行超過三萬公尺近太空高度的摔落測試

00:03:52.766 --> 00:03:53.800
你沒聽錯喔

00:03:53.833 --> 00:03:55.000
三萬公尺

00:03:55.000 --> 00:03:59.800
那它經歷了，這個手機包著殼，經歷了極致低溫

00:03:59.833 --> 00:04:03.533
真空環境跟高空落下來的衝擊之後呢

00:04:03.533 --> 00:04:06.166
手機竟然還可以正常使用

00:04:06.166 --> 00:04:08.800
這個是創下了全新的世界紀錄的

00:04:08.833 --> 00:04:11.300
那 AirX 可以做到這件事情呢

00:04:11.333 --> 00:04:15.133
關鍵就在於 AirX 裡面有 360 度的包覆式氣囊

00:04:15.133 --> 00:04:18.700
搭配了這個犀牛盾獨家的內傷防護複合系統

00:04:18.733 --> 00:04:21.933
可以把摔落瞬間的衝擊力給分散吸收掉

00:04:21.933 --> 00:04:22.966
那你可以想像

00:04:23.000 --> 00:04:25.533
就是我們幫手機裝上了一圈安全氣囊

00:04:25.533 --> 00:04:28.466
可以降低摔落的受損機會

00:04:28.466 --> 00:04:29.733
如果你挑手機殼

00:04:29.766 --> 00:04:31.600
也很在意顏色跟手感的話

00:04:31.633 --> 00:04:36.100
可以看看犀牛盾的 SolidX 強化吸震緩衝殼

00:04:36.100 --> 00:04:37.533
這個 SolidX

00:04:37.566 --> 00:04:42.033
它的霧透系列可以透出 iPhone 本身的顏色

00:04:42.066 --> 00:04:45.733
很百搭，再加上它很細緻的磨砂質感

00:04:45.733 --> 00:04:47.233
摸起來很舒服

00:04:47.233 --> 00:04:49.800
也抗污耐髒。內側四個角落

00:04:49.833 --> 00:04:51.200
也是有緩衝槽的

00:04:51.233 --> 00:04:54.866
所以它的外型跟防護都有顧到

00:04:54.866 --> 00:04:58.100
也很好拆裝。另外也有其他的

00:04:58.133 --> 00:05:00.666
像是主打終身抗黃保固

00:05:00.700 --> 00:05:05.333
如果變黃了，可以免費換新的 Clear 透明殼系列

00:05:05.333 --> 00:05:09.100
以及全新的裸機感 Bumper 邊框殼

00:05:09.133 --> 00:05:12.966
連螢幕、鏡頭保護都可以一起備齊

00:05:13.000 --> 00:05:14.933
現在購買任何一款手機殼

00:05:14.933 --> 00:05:16.800
保護貼還有限時 7 折起

00:05:17.600 --> 00:05:19.200
舊殼也不要急著丟

00:05:19.233 --> 00:05:21.400
犀牛盾現在有 RHINOLOOP

00:05:21.400 --> 00:05:23.566
手機殼回收計畫的大進化

00:05:23.566 --> 00:05:26.466
加入官方會員，完成手機驗證

00:05:26.466 --> 00:05:28.533
再啟動舊殼回收的話

00:05:28.566 --> 00:05:31.100
新殼就可以折抵 500 塊

00:05:31.100 --> 00:05:33.766
那或是你在官網結帳的時候呢

00:05:33.800 --> 00:05:35.900
輸入我們哈利的折扣碼

00:05:35.900 --> 00:05:40.333
這個科技浪的限時折扣碼 i18-harry，小寫的 i

00:05:40.333 --> 00:05:44.133
然後 18，然後 dash harry，都是小寫的

00:05:44.166 --> 00:05:47.666
這個我們在本集資訊欄也會提供折扣碼

00:05:47.666 --> 00:05:51.766
你就可以訂單直接滿 700 塊，現折 100 塊，OK

00:05:52.166 --> 00:05:55.466
所以這個連結跟折扣碼都放在節目的資訊欄

00:05:56.033 --> 00:05:59.200
準備換新 iPhone 的朋友，可以記得去看看

00:05:59.233 --> 00:06:01.433
來幫新手機先把防護給準備好

00:06:01.800 --> 00:06:03.933
本集業配就到這邊結束，謝謝犀牛盾的贊助

00:06:04.333 --> 00:06:08.400
各位，我們必須得來聊聊 Jev，J-E-V，Jev

00:06:08.433 --> 00:06:10.666
過去這三天的社群媒體

00:06:10.666 --> 00:06:12.666
不管是 X 還是 Threads

00:06:12.700 --> 00:06:15.700
全部都是 Jev，怎麼滑都是看到 Jev

00:06:15.733 --> 00:06:19.866
十篇裡面至少七八篇都是 Jev，如果你不知道的話

00:06:19.866 --> 00:06:24.600
這個 Jev 是過去這一週 AI 圈最大的一個新聞

00:06:24.600 --> 00:06:28.700
所有人都在討論的一個新的 AI 模型

00:06:28.733 --> 00:06:32.533
那它是由一間叫做 TypeSafe AI 的公司在上禮拜推出的

00:06:33.000 --> 00:06:35.100
那你如果沒有聽過 TypeSafe AI 這間公司

00:06:35.100 --> 00:06:35.966
其實非常正常啦

00:06:35.966 --> 00:06:39.066
因為他們基本上在上禮拜之前是

00:06:39.066 --> 00:06:41.333
沒有人聽過的一間公司

00:06:41.366 --> 00:06:42.966
他們 2024 年成立

00:06:42.966 --> 00:06:46.366
但是兩年的時間他們都是在低調打造產品

00:06:46.366 --> 00:06:48.666
就是 Stealth Mode 這樣子

00:06:49.300 --> 00:06:55.400
那在上禮拜他們才終於就是推出他們的第一個模型

00:06:55.400 --> 00:06:58.866
然後就也讓大家了解知道他們這樣子

00:06:58.900 --> 00:07:03.400
那這模型一出來，馬上就是全網爆紅啊

00:07:03.433 --> 00:07:06.466
整個 AI 圈子沒有任何其他 topic

00:07:06.500 --> 00:07:09.833
大家都在講 Jev，那為什麼會這麼紅呢？

00:07:09.866 --> 00:07:12.633
就是現在 AI 模型整天都在推出嘛

00:07:12.633 --> 00:07:15.066
就是每個禮拜都有新模型推出來

00:07:15.100 --> 00:07:18.433
為什麼這個模型會得到這麼多關注？

00:07:18.466 --> 00:07:22.566
首先，最主要的原因是因為它不是一般的 AI 模型

00:07:22.866 --> 00:07:25.566
它不是一個 chatbot，也不是一個 AI agent

00:07:25.566 --> 00:07:27.400
它是一個 TypeSafe 把它稱作

00:07:27.433 --> 00:07:28.933
System 1 model 的模型

00:07:29.366 --> 00:07:30.766
好，那你聽這個名字

00:07:30.800 --> 00:07:32.766
原本你第一次看到就覺得，哇

00:07:32.800 --> 00:07:35.000
好像很炫砲耶，好像很神秘耶！

00:07:35.033 --> 00:07:38.066
什麼叫做 System 1 model？感覺好像很厲害

00:07:38.066 --> 00:07:41.300
然後你往下繼續看他們的這個宣傳文呢

00:07:41.300 --> 00:07:42.900
你會覺得越看越扯

00:07:42.933 --> 00:07:45.200
他們講了很多東西，像是說

00:07:45.233 --> 00:07:48.033
Jev 這個模型呢，是不會有幻覺的

00:07:48.066 --> 00:07:52.600
Zero Hallucinations，這個原本應該是 AI 模型

00:07:52.600 --> 00:07:56.866
這個 LLM 模型的一個致命痛點的幻覺問題

00:07:56.900 --> 00:07:58.433
他們竟然沒有

00:07:58.433 --> 00:07:59.333
然後還寫

00:07:59.366 --> 00:08:03.600
它的速度跟成本都是遠遠勝過現在的大型語言模型

00:08:04.033 --> 00:08:05.066
速度快多少倍？

00:08:05.466 --> 00:08:09.000
不是快一倍兩倍，是快兩百倍

00:08:09.533 --> 00:08:11.166
然後成本呢？

00:08:11.200 --> 00:08:12.600
便宜四百倍

00:08:13.100 --> 00:08:15.100
哇，看到這邊你真的會覺得說

00:08:15.133 --> 00:08:17.000
這個模型到底是何方神聖啊

00:08:17.300 --> 00:08:19.166
你就忍不住想要去研究它嘛

00:08:19.633 --> 00:08:21.166
那這是它爆紅的第一個原因

00:08:21.533 --> 00:08:22.900
它還有另外一個原因

00:08:23.233 --> 00:08:25.033
就是它的 Founder

00:08:25.033 --> 00:08:28.666
TypeSafe AI 的 CEO，其實背景很硬喔

00:08:28.800 --> 00:08:31.200
他的名字叫做 Diogo Almeida

00:08:31.233 --> 00:08:32.966
是一個蠻騷包的 CEO

00:08:33.633 --> 00:08:37.266
因為他去參加一些演講啊，Event

00:08:37.300 --> 00:08:41.500
都會穿著一個粉色的那種羽絨大衣，OK

00:08:42.066 --> 00:08:44.166
就很亮的很亮的那種粉色

00:08:44.600 --> 00:08:47.533
就有點像是那個 One Piece 的那個 Doflamingo 那樣子

00:08:47.933 --> 00:08:50.600
那反正，他的技術底子真的很硬喔

00:08:50.900 --> 00:08:53.700
他是 ChatGPT 的共同發明者之一

00:08:54.266 --> 00:08:55.800
差不多 2022 年

00:08:55.800 --> 00:08:57.933
OpenAI 在研究怎麼把

00:08:57.933 --> 00:09:02.033
GPT-3 這種只會做文字接龍的大型語言模型

00:09:02.033 --> 00:09:04.033
變成是一個 chatbot

00:09:04.033 --> 00:09:09.833
像是 ChatGPT 這種會跟你一來一往地聊天的模型

00:09:09.866 --> 00:09:11.800
那這背後最核心的技術呢

00:09:12.566 --> 00:09:15.733
就是後訓練，就是 RLHF 的這些技術

00:09:15.766 --> 00:09:19.600
就是 Diogo Almeida 當時在 OpenAI 研究的

00:09:19.800 --> 00:09:21.933
他們甚至後來出了一篇論文

00:09:21.966 --> 00:09:23.933
然後這個 Diogo Almeida

00:09:23.966 --> 00:09:26.100
是那篇論文的主要作者之一

00:09:26.266 --> 00:09:28.900
所以這整件事就是一個完美頭條嘛，對不對？

00:09:29.400 --> 00:09:29.633
哇

00:09:29.633 --> 00:09:31.766
這個 ChatGPT 的共同發明者之一

00:09:31.800 --> 00:09:33.733
竟然推出了一個 AI 模型

00:09:33.733 --> 00:09:36.600
比現在的模型快兩百倍

00:09:36.600 --> 00:09:38.333
然後還便宜四百倍

00:09:38.366 --> 00:09:41.400
然後還永遠不會產生幻覺。哇！

00:09:41.400 --> 00:09:43.700
天翻地覆，世界要改變啦！

00:09:43.733 --> 00:09:45.766
那當然啦，就一如既往

00:09:45.766 --> 00:09:50.200
其實很多這些 marketing 的講法都是比較偏炒作啦

00:09:50.233 --> 00:09:54.266
其實事實的狀況就是，天下沒有白吃的午餐

00:09:54.266 --> 00:09:54.566
好

00:09:54.600 --> 00:09:57.033
你今天要做到我們剛剛講的那三件事情呢

00:09:57.066 --> 00:10:00.933
你勢必要犧牲一點你們模型能夠做到的事

00:10:00.933 --> 00:10:03.533
那聽完今天這集 podcast 呢

00:10:03.566 --> 00:10:07.533
你就會完全理解 Jev 這個模型它到底是什麼

00:10:07.533 --> 00:10:09.166
它的運作原理又是什麼

00:10:09.200 --> 00:10:11.600
它的應用場景可以應用在哪些地方

00:10:11.600 --> 00:10:13.266
能夠解決哪些問題

00:10:13.266 --> 00:10:17.066
然後哪些場景是沒有辦法取代現在的 LLM 的

00:10:17.100 --> 00:10:19.266
以及它的實測狀況如何

00:10:19.700 --> 00:10:21.700
我自己也有簡單地去測試一下

00:10:22.166 --> 00:10:24.366
然後最後我覺得也是非常重要的一點

00:10:24.400 --> 00:10:25.433
就是 So what？

00:10:25.633 --> 00:10:28.366
有了 Jev 之後，又會發生什麼事情？

00:10:28.633 --> 00:10:31.866
這對於現在的 AI agent 的意義究竟是什麼？

00:10:32.300 --> 00:10:36.666
我覺得 Jev 當然不像是很多的文章一樣

00:10:36.700 --> 00:10:38.600
講得會改變世界

00:10:38.600 --> 00:10:44.133
但是它確實，必須說，是一個重要的技術趨勢

00:10:44.166 --> 00:10:46.000
它確實是會改變一些事情

00:10:46.533 --> 00:10:47.733
好，那首先呢

00:10:47.733 --> 00:10:50.766
我們就先從 Jev 到底是什麼開始聊起

00:10:51.300 --> 00:10:53.633
好，那當然這個 TypeSafe AI 是把它稱作

00:10:53.633 --> 00:10:55.666
一個 System 1 model 嘛，對不對？

00:10:56.100 --> 00:10:57.566
好，但你直接這樣子講

00:10:57.566 --> 00:10:59.300
沒有人會知道它是什麼的啦

00:10:59.600 --> 00:11:02.600
好，其實一個最精準的講法

00:11:02.633 --> 00:11:04.166
我會把它稱作一個

00:11:04.166 --> 00:11:08.300
LLM-based general-purpose classification model

00:11:08.333 --> 00:11:12.766
中文可以翻成基於大型語言模型的通用分類模型

00:11:12.766 --> 00:11:15.166
OK，那當然我知道 TypeSafe AI

00:11:15.200 --> 00:11:17.900
他們官方絕對不會認同這樣子的定義

00:11:17.933 --> 00:11:21.566
因為他們就是很明顯地想要跟 LLM 切割嘛

00:11:21.566 --> 00:11:22.866
然後做出差別

00:11:22.900 --> 00:11:24.766
才會把它叫做 System 1 model

00:11:24.800 --> 00:11:27.133
但是我覺得最精準的講法應該是這樣子

00:11:27.166 --> 00:11:28.466
我自己認為

00:11:28.466 --> 00:11:31.966
那當然這一句話聽起來很長很複雜

00:11:32.000 --> 00:11:33.766
很多人可能一時之間沒有辦法

00:11:33.766 --> 00:11:35.133
完全理解它是什麼意思

00:11:35.166 --> 00:11:36.900
所以我們把它 break down

00:11:36.933 --> 00:11:39.166
我們把它拆出幾個重要的觀念來看

00:11:39.166 --> 00:11:40.300
先看最後一句喔

00:11:40.333 --> 00:11:43.600
Jev 是一個 classification model 分類模型

00:11:43.633 --> 00:11:46.166
意思就是說它只能做分類工作

00:11:46.166 --> 00:11:48.966
它不能產生文字、圖片或是程式碼

00:11:49.000 --> 00:11:51.233
這邊其實就是跟一般的這些

00:11:51.266 --> 00:11:54.866
AI agent、AI chatbot 很不一樣的地方嘛

00:11:54.866 --> 00:11:55.766
對不對？

00:11:55.800 --> 00:11:57.466
所謂的分類工作呢

00:11:57.466 --> 00:12:01.700
就真的是針對一個情況或是一個物件去幫它做分類

00:12:01.733 --> 00:12:04.500
就比如說你拿到一個客服的訊息

00:12:04.500 --> 00:12:06.533
一個客人的抱怨的訊息

00:12:06.566 --> 00:12:08.400
那你要根據這個訊息

00:12:08.400 --> 00:12:11.366
分辨它究竟是一個技術相關的問題

00:12:11.366 --> 00:12:12.833
還是一個帳務相關的問題

00:12:12.866 --> 00:12:14.166
還是一個物流相關的問題

00:12:14.200 --> 00:12:14.866
等等

00:12:14.900 --> 00:12:19.800
或者是根據目前你看到的這一則 email 的內容呢

00:12:19.833 --> 00:12:22.900
去判斷它是不是釣魚信件

00:12:22.933 --> 00:12:25.800
OK，就兩種可能而已，是或是不是

00:12:25.800 --> 00:12:32.466
或者是根據履歷的內容以及你的徵才標準

00:12:32.466 --> 00:12:37.233
去判斷這個應徵者跟我們職缺的適合程度有幾分

00:12:37.266 --> 00:12:39.733
1 到 5 分，究竟有幾分這樣子

00:12:39.766 --> 00:12:43.366
好，那像這類型的工作呢，就是 Jev 在做的

00:12:43.366 --> 00:12:46.133
而且 Jev 也只能做這類型的工作

00:12:46.166 --> 00:12:49.100
它不會產生文字，也不會產生圖片，好

00:12:49.100 --> 00:12:52.900
你今天就是丟給它一個你要判斷的情況

00:12:52.933 --> 00:12:56.333
以及這個情況之下你目前的選項有哪些

00:12:56.333 --> 00:12:59.200
然後 Jev 就會直接吐給你一串機率分布

00:12:59.233 --> 00:13:01.033
好，這個機率分布呢

00:13:01.066 --> 00:13:03.966
就是你給它的選項當中的機率分布

00:13:03.966 --> 00:13:04.333
OK

00:13:04.366 --> 00:13:06.366
比如說 A 選項幾% 的機率

00:13:06.366 --> 00:13:09.266
B 選項幾% 的機率，C 選項幾% 這樣子

00:13:09.300 --> 00:13:12.133
像是你丟給它一個客服的訊息，內容就是說

00:13:12.166 --> 00:13:15.333
「我想知道一下我的包裹目前的進度。」

00:13:15.333 --> 00:13:19.800
那你下面就寫出，你現在要問的問題是

00:13:19.800 --> 00:13:22.500
請問這個客服的訊息呢

00:13:22.533 --> 00:13:24.766
它是哪一個類別的問題？

00:13:24.800 --> 00:13:27.400
然後下面有 A 選項：帳務

00:13:27.400 --> 00:13:30.300
B 選項：技術，C 選項：物流

00:13:30.333 --> 00:13:34.300
D 選項……然後你把這整坨東西丟給 Jev

00:13:34.300 --> 00:13:37.200
Jev 就會吐一個機率分布給你

00:13:37.233 --> 00:13:40.566
比如說帳務機率 2%，技術機率 1%

00:13:40.600 --> 00:13:42.466
然後物流機率 92%

00:13:42.466 --> 00:13:45.700
然後其他選項機率幾%、幾%、幾%

00:13:45.733 --> 00:13:49.066
你透過這個機率分布就可以看到說

00:13:49.066 --> 00:13:53.766
Jev 認為這個問題有 92% 的機會是跟物流相關的

00:13:53.766 --> 00:13:55.000
所以說，好

00:13:55.033 --> 00:13:58.333
這個，八成這個問題就是物流的問題這樣

00:13:58.366 --> 00:14:01.833
好，你覺得 Jev 可以幫你很快地去做出這個判斷

00:14:02.000 --> 00:14:05.033
然後同時，Jev 也不只是一個單純的分類模型

00:14:05.033 --> 00:14:07.400
它是一個通用的分類模型

00:14:07.433 --> 00:14:09.733
一個 general-purpose classification model

00:14:09.733 --> 00:14:11.066
那這句話在講的呢

00:14:11.100 --> 00:14:13.366
就是同樣一個 Jev 模型

00:14:13.400 --> 00:14:16.566
可以解決各式各樣不同的分類問題

00:14:16.566 --> 00:14:16.666
OK

00:14:16.800 --> 00:14:21.733
你不用再額外去訓練它去學習如何分類不同的問題

00:14:21.900 --> 00:14:23.966
它自己本來就可以靠著它的

00:14:23.966 --> 00:14:25.866
這個世界知識去進行判斷

00:14:26.266 --> 00:14:28.000
好，你只要 context

00:14:28.000 --> 00:14:30.766
就是你的問題的狀況，問題的敘述

00:14:30.800 --> 00:14:33.766
還有這個該給的資訊有給足

00:14:33.800 --> 00:14:37.066
它大部分的情況下都有能力可以自己判斷

00:14:37.100 --> 00:14:39.833
那當然啦，我覺得有些人可能會覺得說

00:14:39.866 --> 00:14:41.533
這不是理所當然的嗎？

00:14:42.166 --> 00:14:45.933
現在哪一個模型不是通用的嘛，對不對？

00:14:46.433 --> 00:14:47.600
但你必須要知道

00:14:47.633 --> 00:14:49.500
我覺得通用這件事情

00:14:49.533 --> 00:14:50.800
就是你還是得加在

00:14:50.833 --> 00:14:53.166
classification model 這個詞之前

00:14:53.166 --> 00:14:54.433
因為你要知道

00:14:54.466 --> 00:14:57.200
在 ChatGPT 時代之前

00:14:57.233 --> 00:15:00.100
我們那時候在講 AI，其實那時候

00:15:00.133 --> 00:15:01.000
甚至不是在講 AI

00:15:01.000 --> 00:15:03.366
在講 machine learning 那個時候

00:15:03.400 --> 00:15:04.433
在講 machine learning

00:15:04.466 --> 00:15:06.766
在講機器學習的時候呢

00:15:06.766 --> 00:15:09.500
classification，也就是分類問題

00:15:09.500 --> 00:15:11.533
一直以來都是一個大類別

00:15:11.566 --> 00:15:16.166
很多的機器學習的演算法都是為了分類問題而設計的

00:15:16.566 --> 00:15:20.066
那當然沒有任何一個演算法是可以像是現在 Jev

00:15:20.100 --> 00:15:24.233
像是現在那個 ChatGPT 這麼通用的

00:15:24.233 --> 00:15:28.766
全部都是針對一個你的特定問題

00:15:28.800 --> 00:15:32.666
特定領域的特定問題去訓練一個模型出來

00:15:32.700 --> 00:15:34.400
就比如說你們今天一個銀行

00:15:34.400 --> 00:15:37.966
想要大量去判斷你們客戶的違約機率有多高

00:15:38.000 --> 00:15:40.500
你就要準備大量的歷史資料

00:15:40.533 --> 00:15:42.733
一筆一筆都清楚地標示了

00:15:42.766 --> 00:15:45.166
這個客戶他的交易行為如何

00:15:45.166 --> 00:15:49.433
他的個人資料、基本資料，然後他是否有違約

00:15:49.433 --> 00:15:51.366
具體很多這種過去的資料

00:15:51.400 --> 00:15:53.666
就拿這些資料去訓練一個模型

00:15:53.833 --> 00:15:55.866
隨便看你要挑什麼樣子的演算法

00:15:56.233 --> 00:15:58.800
有一些比較統計 based 的演算法

00:15:58.800 --> 00:16:01.266
也有一些像是神經網路的演算法

00:16:01.633 --> 00:16:04.500
反正你挑一個演算法，然後就訓練這個模型

00:16:05.100 --> 00:16:07.366
那後續你就可以用

00:16:07.400 --> 00:16:11.466
這個模型去為新的客戶去進行預測

00:16:11.733 --> 00:16:15.533
預測看這個人有沒有違約的機率這樣子

00:16:15.900 --> 00:16:19.566
但很明顯地，同一個模型就只會做這件事情

00:16:19.866 --> 00:16:21.666
它不能同時也幫你去判斷一封

00:16:21.666 --> 00:16:23.333
email 到底是不是釣魚信件

00:16:23.766 --> 00:16:28.000
它只會做你訓練資料有丟給它的事情這樣子

00:16:28.533 --> 00:16:30.866
所以 classification model 已經是

00:16:30.866 --> 00:16:32.100
machine learning

00:16:32.133 --> 00:16:34.333
這個圈子當中已經很老的一個詞了

00:16:34.533 --> 00:16:37.833
然後也是大家鑽研很久的一個技術

00:16:38.166 --> 00:16:41.133
但是 Jev 我覺得可以說就是站在

00:16:41.166 --> 00:16:44.166
classification model 的頂端啦

00:16:44.300 --> 00:16:46.933
它是一個通用的模型

00:16:47.200 --> 00:16:50.466
任何問題，你不用訓練，不用找訓練資料

00:16:50.500 --> 00:16:52.733
丟給它，它就會做了這樣子

00:16:52.966 --> 00:16:55.066
那當然啦，有一些如果太偏的

00:16:55.100 --> 00:16:57.700
會需要大量領域知識的問題

00:16:57.700 --> 00:17:01.366
Jev 也不一定能夠直接就給出一個很好的答案

00:17:01.400 --> 00:17:04.100
就比如說，像我們剛剛舉的例子就蠻不錯的嘛

00:17:04.800 --> 00:17:07.933
銀行內部要去判斷一個客人他的違約機率

00:17:08.366 --> 00:17:10.700
那像這樣子的問題呢，因為網路上

00:17:10.700 --> 00:17:13.166
它在這個 Jev，我們待會會講到 Jev

00:17:13.200 --> 00:17:14.766
它是一個 LLM-based

00:17:14.800 --> 00:17:17.033
它有一個大型語言模型的基底

00:17:17.033 --> 00:17:20.066
它一樣是透過網路上的資料訓練出來的模型

00:17:20.533 --> 00:17:23.200
網路上的資料你全部都看過

00:17:23.233 --> 00:17:25.333
你也不一定可以建立起一個很好的直覺

00:17:25.366 --> 00:17:30.366
就是什麼樣子的客人容易違約嘛，對不對？

00:17:30.366 --> 00:17:34.866
通常還是要從銀行自己內部的資料去學習

00:17:34.866 --> 00:17:37.933
你才可以建立起這邊的直覺

00:17:38.366 --> 00:17:41.300
那這邊的問題可能 Jev 就沒有辦法解得很好

00:17:41.333 --> 00:17:43.700
但是其實絕大多數的問題啦

00:17:43.733 --> 00:17:47.566
然後很多也都是已經非常有商業價值的問題

00:17:47.566 --> 00:17:49.800
Jev 其實就直接可以解決了

00:17:49.833 --> 00:17:52.933
待會我們也可以在講應用場景的時候再多講一些

00:17:53.100 --> 00:17:55.033
好，那我們剛剛也有大概提到了嘛

00:17:55.066 --> 00:17:56.466
就是這個 Jev 的模型呢

00:17:56.466 --> 00:18:00.200
它之所以是一個通用的分類模型，它有通用能力呢

00:18:00.200 --> 00:18:02.400
也是因為它是用一個 LLM

00:18:02.433 --> 00:18:05.000
一個大型語言模型作為基底嘛

00:18:05.000 --> 00:18:05.433
對不對？

00:18:05.433 --> 00:18:06.900
那嚴格來說呢

00:18:06.933 --> 00:18:10.600
它是用一個預訓練完的 LLM 作為基底

00:18:10.600 --> 00:18:12.800
但是在後訓練的部分呢

00:18:12.800 --> 00:18:15.400
它的做法跟現在典型的 LLM

00:18:15.433 --> 00:18:18.133
跟 Agent 就開始有不一樣了

00:18:18.133 --> 00:18:21.133
它是在後訓練的這個階段開始分歧的，OK

00:18:21.533 --> 00:18:23.833
我們知道現在這些 LLM 的訓練主要

00:18:23.833 --> 00:18:26.333
就是分成兩個階段嘛，預訓練跟後訓練

00:18:26.633 --> 00:18:27.966
那預訓練階段

00:18:28.000 --> 00:18:32.033
就是讓這個模型大量地去看網路上的訓練資料

00:18:32.066 --> 00:18:35.833
然後去建立起基本的世界知識跟語言能力

00:18:35.833 --> 00:18:40.366
那後訓練的部分就是建立在這個基本的能力之上

00:18:40.400 --> 00:18:44.533
再去把這個模型形塑成人類想要的樣子

00:18:44.566 --> 00:18:46.966
或者是會使用工具的樣子

00:18:47.400 --> 00:18:49.800
所以 Jev 跟一般 LLM 的差別

00:18:49.800 --> 00:18:53.033
就是差在後訓練這一段的訓練方式不同嘛

00:18:53.066 --> 00:18:53.700
對不對？

00:18:53.700 --> 00:18:56.333
我們一樣經過一樣的預訓練

00:18:56.333 --> 00:18:59.566
就是做出了一個有世界知識的模型

00:19:00.000 --> 00:19:01.800
那假設你今天想要讓

00:19:01.800 --> 00:19:04.566
這個模型後續變成 ChatGPT 的話

00:19:04.600 --> 00:19:08.133
你就會先讓它理解怎麼樣子跟人類溝通

00:19:08.133 --> 00:19:10.633
怎麼樣子一搭一唱變成一個 chatbot

00:19:10.666 --> 00:19:13.733
然後再教它怎麼樣子去使用工具

00:19:13.766 --> 00:19:15.800
怎麼樣去解數學題目

00:19:15.833 --> 00:19:20.800
怎麼樣子去解決一個很長時間的 coding 題目等等的

00:19:20.800 --> 00:19:22.333
好，慢慢訓練這些事情

00:19:22.366 --> 00:19:24.500
然後它就變成了那個 GPT-6。好

00:19:24.500 --> 00:19:28.866
那如果你是想要把它變成 Jev 這樣子的模型的話呢

00:19:28.900 --> 00:19:32.566
你在後訓練的過程中就不要教它怎麼吐文字了

00:19:32.566 --> 00:19:34.800
不要教它給出完整的回答了

00:19:34.833 --> 00:19:37.666
就直接教它怎麼吐一個機率分布就好了

00:19:37.666 --> 00:19:40.766
就基於你的問題，你就是只能吐一個機率分布，OK

00:19:41.066 --> 00:19:44.566
就是把它硬是變成一個單純的選擇機器

00:19:44.733 --> 00:19:46.466
大概念基本上就是這樣子啦

00:19:46.600 --> 00:19:49.700
好，但如果你想要再更深一步了解的話呢

00:19:49.733 --> 00:19:52.866
我們接下來就來聊一些技術細節

00:19:52.866 --> 00:19:54.900
那如果你不想聽的話也沒關係

00:19:54.933 --> 00:19:57.700
就是本集資訊欄都有時間軸

00:19:57.700 --> 00:20:00.833
這個 part 會比較細一點，比較技術一點

00:20:00.866 --> 00:20:03.100
你就直接跳到下一個 part 就 OK 了

00:20:03.100 --> 00:20:06.066
反正我們知道這個後訓練的部分呢

00:20:06.100 --> 00:20:09.433
也是有分很多不同階段的嘛，對不對？

00:20:09.666 --> 00:20:12.366
有這個 supervised fine-tuning 啊

00:20:12.400 --> 00:20:13.833
有 RLHF 啊等等的

00:20:14.033 --> 00:20:16.666
每個階段都有它的目的

00:20:17.100 --> 00:20:18.100
像是 RLHF

00:20:18.100 --> 00:20:22.166
Reinforcement Learning from Human Feedback

00:20:22.200 --> 00:20:24.233
它在做的就是想辦法讓

00:20:24.233 --> 00:20:26.800
這個模型的回答更跟人類對齊

00:20:26.833 --> 00:20:31.800
就是說更自然，社會接受度更高，然後更安全

00:20:31.800 --> 00:20:36.900
給出大家真的會比較喜歡的一個回答

00:20:36.933 --> 00:20:39.633
另外一個 part 也是很有名的

00:20:39.633 --> 00:20:42.600
是最近這兩年興起的，叫做 RLVR

00:20:42.633 --> 00:20:47.266
Reinforcement Learning with Verifiable Rewards

00:20:47.733 --> 00:20:52.166
這邊在做的就是透過讓模型去解決像數學題

00:20:52.166 --> 00:20:54.166
像 coding 的問題

00:20:54.166 --> 00:20:59.533
像是一些 puzzle，像是一些 tool use 的 task

00:20:59.566 --> 00:21:02.266
這種有明確定義的解答

00:21:02.266 --> 00:21:05.666
明確可被驗證的結果的問題

00:21:05.700 --> 00:21:13.066
去訓練它的思考的能力，去嘗試解決方法的能力

00:21:13.100 --> 00:21:17.366
使用工具的能力，驗證答案的能力等等

00:21:17.366 --> 00:21:20.900
這個其實就是很多人在過去這兩年講到

00:21:20.933 --> 00:21:23.400
RL 的時候特別在指的東西

00:21:23.400 --> 00:21:26.033
就是在講 RLVR

00:21:26.066 --> 00:21:31.266
TypeSafe 他們基本上不做 RLVR，也不做 RLHF

00:21:31.300 --> 00:21:33.633
他們在做的是一種新的後訓練

00:21:33.666 --> 00:21:37.433
他們有發明一個新的詞，叫做 RLCD

00:21:37.433 --> 00:21:43.033
Reinforcement Learning for Calibrated Decisions

00:21:43.033 --> 00:21:47.000
Calibrated Decisions 的中文是叫做「校準決策」

00:21:47.000 --> 00:21:49.600
它的意思就是代表說

00:21:49.600 --> 00:21:52.333
它這個模型必須要能夠給出

00:21:52.366 --> 00:21:55.433
真的很符合現實的機率分布

00:21:55.433 --> 00:21:56.666
白話來說

00:21:56.700 --> 00:22:02.266
它並不是只是要求這個模型最後有選到對的分類

00:22:02.300 --> 00:22:04.066
選到對的選項而已

00:22:04.100 --> 00:22:09.266
它還會要求這個模型給出的機率分布是符合事實的

00:22:09.400 --> 00:22:11.000
應該說盡量接近事實

00:22:11.466 --> 00:22:15.066
因為真實世界中的很多問題也不是非黑即白的

00:22:15.300 --> 00:22:18.433
同樣的一件事情，同樣的一個回覆

00:22:18.466 --> 00:22:22.466
其實在各種不同的狀況之下也會有不一樣的解讀

00:22:22.466 --> 00:22:26.133
然後有時候也真的就是有一些機率成分在裡面嘛

00:22:26.166 --> 00:22:27.000
對不對？

00:22:27.333 --> 00:22:28.366
就比如說

00:22:28.366 --> 00:22:31.800
你今天的任務是判斷餐廳 Google

00:22:31.833 --> 00:22:36.033
評論下面的留言到底是正面的還是負面的

00:22:36.033 --> 00:22:42.100
假設有一句留言是寫說：「這間餐廳真的很扯」有寫到這句話

00:22:42.500 --> 00:22:44.500
那可能 80% 的情況之下

00:22:44.533 --> 00:22:47.700
這個人是覺得這間餐廳很爛，對不對？

00:22:48.100 --> 00:22:50.200
但其實同樣一句話也是可以

00:22:50.233 --> 00:22:52.000
就是比較少人這樣用啦

00:22:52.000 --> 00:22:54.366
但是可能 20% 的狀況之下

00:22:54.400 --> 00:22:57.633
有些人也是會把這句話拿來當稱讚嘛

00:22:57.666 --> 00:22:58.100
對不對？

00:22:58.100 --> 00:23:00.733
他可能說：「真的很扯 竟然做出這麼好吃的 burger！」嘛

00:23:00.766 --> 00:23:01.233
對不對？

00:23:01.633 --> 00:23:05.266
所以 TypeSafe AI 透過 RLCD 的訓練目標

00:23:05.300 --> 00:23:10.400
就是希望讓 Jev 遇到「這個餐廳真的很扯」這句話的時候呢

00:23:10.400 --> 00:23:14.866
它會吐出 80% 負面這樣子的一個答案

00:23:14.900 --> 00:23:18.033
那具體來說，這個 RLCD 究竟是怎麼做的？

00:23:18.066 --> 00:23:19.633
TypeSafe AI 沒有講

00:23:19.900 --> 00:23:21.900
這個算是他們的 Secret Sauce

00:23:21.900 --> 00:23:24.266
他們的商業機密的部分啦，對不對？

00:23:25.466 --> 00:23:29.900
Jev 的整個模型，他們有講的東西確實沒有很多

00:23:29.933 --> 00:23:31.733
它是一個閉源模型

00:23:32.400 --> 00:23:35.333
Jev，他們今天 TypeSafe 也就只有釋出

00:23:35.333 --> 00:23:37.533
Jev 的這個 API 的 endpoint

00:23:37.566 --> 00:23:41.200
所以說你能做的就是看到 Jev 這個 API

00:23:41.233 --> 00:23:43.900
你的 input、output 是什麼

00:23:43.900 --> 00:23:45.066
就這樣子而已

00:23:45.066 --> 00:23:47.866
你實在不知道這個模型它的架構是什麼

00:23:47.900 --> 00:23:49.733
然後它經過什麼樣子的訓練

00:23:49.733 --> 00:23:52.866
以及甚至它的 pure output 是什麼

00:23:52.866 --> 00:23:54.566
你其實也不太知道

00:23:54.600 --> 00:23:57.466
但在所有的商業機密當中呢

00:23:57.466 --> 00:24:01.100
最重要的，我覺得是 Data 跟 RLCD

00:24:01.400 --> 00:24:03.833
其實 Diogo 他本人也有大概講到這一點

00:24:04.633 --> 00:24:08.233
這個模型本身的架構其實沒有到非常重要啦

00:24:08.333 --> 00:24:11.800
雖然說他們確實說 Jev 的架構有一些更新

00:24:12.233 --> 00:24:14.866
它並不是真的就是跟現在的

00:24:14.866 --> 00:24:17.100
LLM 完全長得一模一樣

00:24:17.100 --> 00:24:19.033
只是訓練方式不一樣而已

00:24:19.033 --> 00:24:19.500
並沒有

00:24:19.766 --> 00:24:21.900
它架構上也是有一些創新

00:24:21.933 --> 00:24:24.700
但那個不是 Jev 它最厲害的地方

00:24:25.166 --> 00:24:29.166
Jev 它最厲害的地方是它的 RLCD 的 recipe

00:24:29.200 --> 00:24:32.333
它整個食譜跟它的訓練資料這樣子

00:24:32.866 --> 00:24:34.000
不知道他們怎麼搞的

00:24:34.266 --> 00:24:37.533
好，那這邊畢竟全部都是一個謎

00:24:37.566 --> 00:24:39.333
所以我們就也不講太多了

00:24:39.366 --> 00:24:41.000
就也沒有意義嘛，對不對？

00:24:41.033 --> 00:24:45.700
好，但針對這個模型的運作原理的技術細節

00:24:45.733 --> 00:24:48.300
我這邊可以給出一些我自己的猜測啦

00:24:48.300 --> 00:24:50.200
那當然我的猜測不一定對

00:24:50.200 --> 00:24:53.066
雖然說我去網路上，後來我去網路上看

00:24:53.066 --> 00:24:55.733
我發現也蠻多人跟我的想法一樣的

00:24:55.766 --> 00:24:57.266
但是它不一定對啦

00:24:57.300 --> 00:25:00.900
但是它，我覺得是對於大家建立起這個

00:25:00.933 --> 00:25:03.133
這樣子的模型怎麼運作

00:25:03.133 --> 00:25:05.566
我們的直覺是有點幫助的啦

00:25:05.566 --> 00:25:08.666
因為大方向應該就是這樣子

00:25:09.033 --> 00:25:10.966
我們知道一些大方向的東西

00:25:11.233 --> 00:25:18.366
首先我們知道的是它這個 API 的 input output 的 shape，跟它的這些字數的限制等等

00:25:18.766 --> 00:25:21.066
像是它的這個 input

00:25:21.066 --> 00:25:24.500
基本上你就是放你的問題的敘述

00:25:24.533 --> 00:25:27.400
應該說它是叫做 state 啦

00:25:28.166 --> 00:25:31.000
你現在的情況，你的前後文是什麼

00:25:31.333 --> 00:25:34.066
你現在在解決的是什麼問題

00:25:34.800 --> 00:25:37.733
還有 question 的部分

00:25:38.166 --> 00:25:41.633
question 就是你要 Jev 去回答的問題

00:25:41.833 --> 00:25:42.466
OK

00:25:42.466 --> 00:25:47.200
那這邊每個問題就是除了有問題本身的敘述以外呢

00:25:47.233 --> 00:25:51.400
也會有那個問題有哪些選項可以選，OK

00:25:51.433 --> 00:25:52.400
那選項

00:25:52.433 --> 00:25:55.600
每一題的選項最多是 255 個

00:25:55.633 --> 00:25:58.800
然後問題的數量本身沒有限制

00:25:58.833 --> 00:26:00.466
但是它有總 token 的限制

00:26:00.466 --> 00:26:02.100
總 token 的限制有兩個喔

00:26:02.133 --> 00:26:04.666
第一個是你整個 API request

00:26:04.700 --> 00:26:07.633
就是你的 state 加你的所有問題

00:26:07.666 --> 00:26:09.966
加你的所有選項不可以超過

00:26:09.966 --> 00:26:11.766
64K 的 token

00:26:11.800 --> 00:26:12.700
然後

00:26:12.733 --> 00:26:15.400
你的 state 加任意一個問題

00:26:15.400 --> 00:26:17.566
加那個問題的所有選項

00:26:17.600 --> 00:26:20.000
不可以超過 32K 的 token

00:26:20.033 --> 00:26:22.566
這些數字一看就知道

00:26:22.600 --> 00:26:27.200
不是 PM 隨便亂定的，它都是有意義的

00:26:27.200 --> 00:26:32.800
32K 你一看到就知道應該是跟 context length 有點關係

00:26:32.833 --> 00:26:37.366
然後 255、256 − 1，2 的八次方 − 1

00:26:37.400 --> 00:26:41.533
很明顯也是一個技術上限制的數字

00:26:41.566 --> 00:26:44.233
這邊就是我們的第一個線索

00:26:44.466 --> 00:26:48.333
還有另外一個線索，TypeSafe 的 CEO Diogo

00:26:48.333 --> 00:26:50.200
他會在 Hacker News

00:26:50.233 --> 00:26:53.066
Hacker News 就是一個技術論壇

00:26:53.066 --> 00:26:57.700
他會在這個技術論壇上回一些留言，他還蠻活躍的

00:26:57.733 --> 00:26:59.833
好，那他在回覆當中

00:26:59.833 --> 00:27:00.900
他有一次就有提到

00:27:00.933 --> 00:27:02.600
就是說確認了一件事情

00:27:02.633 --> 00:27:05.400
說這個 Jev 的運作原理

00:27:05.433 --> 00:27:07.566
就是把 LLM 產生的這個

00:27:07.600 --> 00:27:10.600
token probability distribution

00:27:10.600 --> 00:27:13.200
換成是針對目前問題的選項的

00:27:13.233 --> 00:27:16.033
probability distribution。好

00:27:16.033 --> 00:27:19.400
其實它的核心概念是這樣子。好

00:27:19.433 --> 00:27:23.366
這個是 CEO 認可的講法。那這什麼意思呢？

00:27:23.366 --> 00:27:25.600
首先我們知道現在這些 LLM

00:27:25.600 --> 00:27:27.700
我們看到它們的產出都是一個

00:27:27.733 --> 00:27:29.766
token 一個 token 吐出來嘛

00:27:29.766 --> 00:27:30.333
對不對？

00:27:30.366 --> 00:27:32.633
但它其實並不是算完之後就

00:27:32.633 --> 00:27:34.800
直接跳出一個 token 這樣

00:27:35.366 --> 00:27:39.433
它其實實際它吐出的產出是一個機率分布，OK

00:27:39.700 --> 00:27:42.933
每一個 token 背後它都是先吐出一個機率分布

00:27:42.966 --> 00:27:45.933
再從這個機率分布當中選出一個 token

00:27:45.933 --> 00:27:50.166
這個機率分布就是橫跨它的整個 vocabulary

00:27:50.200 --> 00:27:53.166
就是它能夠吐出的所有 token 當中

00:27:53.200 --> 00:27:58.366
每一個 token 作為下一個 token 的機率有多高

00:27:58.400 --> 00:28:01.933
那它不一定每次都選機率最高，有時候選機率第二

00:28:01.933 --> 00:28:05.133
有時候選機率第三的，看你的 temperature 調整

00:28:05.166 --> 00:28:07.833
但反正我們今天就是一直在從 LLM

00:28:07.833 --> 00:28:10.900
吐出的機率分布當中選一個 token 這樣

00:28:11.133 --> 00:28:14.033
那這樣 Jev 的概念其實也沒有差很多嘛

00:28:14.033 --> 00:28:14.800
對不對？

00:28:14.900 --> 00:28:16.733
它也是吐機率分布啊，對不對？

00:28:17.100 --> 00:28:20.333
只不過它的機率分布不是它所有能產生的

00:28:20.366 --> 00:28:22.233
token 之間的機率分布

00:28:22.233 --> 00:28:23.633
它根本不會產生 token

00:28:23.666 --> 00:28:28.366
它是針對目前這個問題的選項的機率分布，OK

00:28:28.833 --> 00:28:30.866
那但這邊就有個問題啦，就每次

00:28:30.900 --> 00:28:33.066
因為它是個通用模型嘛，對不對？

00:28:33.333 --> 00:28:36.833
它每次的選項數量可能不同啊，針對不同問題

00:28:36.866 --> 00:28:38.833
它可能有時候是非題就兩個選項

00:28:38.866 --> 00:28:42.500
有時候多選題，不是多選啦，就是選擇題

00:28:42.500 --> 00:28:44.466
可能十個選項之類的都有可能嘛

00:28:44.466 --> 00:28:45.033
對不對？

00:28:45.066 --> 00:28:48.100
那這邊就是，它怎麼做的呢？

00:28:48.400 --> 00:28:51.400
這部分就開始進入我猜測的部分了

00:28:51.666 --> 00:28:55.933
我猜測它的做法，我後來發現也蠻多人這樣講的

00:28:55.966 --> 00:28:59.666
就是它每次的 output 就是固定是一個

00:28:59.666 --> 00:29:03.266
255 個 element 的 classifier head

00:29:03.266 --> 00:29:04.366
簡單來說

00:29:04.366 --> 00:29:09.433
它每次就是吐出 255 個 element 的一個機率分布

00:29:09.466 --> 00:29:13.200
每一個 element，每一個元素，它的機率是幾%

00:29:13.233 --> 00:29:15.366
每次一定都會有 255 個

00:29:15.466 --> 00:29:19.100
那假設今天的問題只有五個選項的話

00:29:19.133 --> 00:29:22.666
那這五個選項就分別對應到那

00:29:22.700 --> 00:29:26.000
255 個 output 中的前五個

00:29:26.000 --> 00:29:29.133
好，那第六個開始後面的就全部都不要看

00:29:29.166 --> 00:29:30.800
要嘛就是全部都零啊

00:29:30.833 --> 00:29:32.333
要嘛就全部 mask 住啊

00:29:32.333 --> 00:29:34.633
就反正那邊都不重要，就不用看它們

00:29:34.666 --> 00:29:38.700
好，那就它一樣會吐出這 255 個的機率分布

00:29:38.933 --> 00:29:41.966
好，其實嚴格來說啦，好，這邊又更技術一點

00:29:42.000 --> 00:29:43.800
但就是它在吐的是 logits

00:29:43.833 --> 00:29:50.066
那這些 logits 後續才會透過一個叫做 softmax 的 function 把它換成機率分布這樣子

00:29:50.066 --> 00:29:53.033
但反正它今天能做到的事情就是

00:29:53.066 --> 00:29:55.633
吐出 255 個全部的 logits

00:29:55.666 --> 00:29:57.100
但只用前 5 個

00:29:57.100 --> 00:30:00.266
然後只拿前 5 個去算一個機率分布

00:30:00.266 --> 00:30:02.766
就是只拿前 5 個去丟那個 softmax

00:30:02.800 --> 00:30:05.400
然後算出每個的機率是多少

00:30:05.433 --> 00:30:06.566
然後加起來會是 100%

00:30:06.566 --> 00:30:10.600
所以你有點可以把它想像成是說一般的 LLM

00:30:10.633 --> 00:30:14.300
它在吐的這個機率分布是所有 token 的選項嘛

00:30:14.333 --> 00:30:17.633
那它可能，當然每個 LLM 的這個 vocabulary

00:30:17.666 --> 00:30:19.700
就是總字彙數量也不太一樣

00:30:19.733 --> 00:30:23.366
但可能假設你今天這個 LLM 的總字彙數是 10 萬個

00:30:23.400 --> 00:30:27.466
你總共可以吐出 10 萬個可能的 token。好

00:30:27.466 --> 00:30:33.833
那你就是每次，你都是產出一個 10 萬個 token 之間的機率分布這樣子。好

00:30:33.833 --> 00:30:36.466
但是這個 Jev 它的 token 總數呢

00:30:36.500 --> 00:30:40.300
它的詞彙總數你可以把它想像成是就只有 255 個

00:30:40.300 --> 00:30:44.366
OK，每次這些詞彙都會代表不一樣的東西

00:30:44.400 --> 00:30:47.366
但就是針對你目前問題的選項是什麼

00:30:47.366 --> 00:30:48.400
它就代表什麼

00:30:48.433 --> 00:30:50.666
然後我們要做的也不是只挑選

00:30:50.666 --> 00:30:52.500
一個 token 出來就好了

00:30:52.900 --> 00:30:57.533
我們要做的是把所有的選項算出一個機率分布

00:30:57.866 --> 00:31:02.366
那在這個機率分布當中呢，你可以再算出說誰最高

00:31:02.400 --> 00:31:05.100
然後誰就是成為你目前的 choice

00:31:05.100 --> 00:31:09.600
同時你也可以算整個機率分布的信心程度

00:31:10.000 --> 00:31:12.333
如果這個機率分布超偏某個問題的話

00:31:12.333 --> 00:31:13.966
就代表你的信心程度很高

00:31:14.600 --> 00:31:16.400
如果是比較平均一點點

00:31:16.433 --> 00:31:18.900
就代表你的信心程度稍微低一點

00:31:19.733 --> 00:31:21.900
所以他們 API 也會回傳

00:31:22.800 --> 00:31:24.400
這些信心程度等等

00:31:24.566 --> 00:31:27.966
但這些都是透過原本的機率分布算出來的

00:31:28.033 --> 00:31:30.800
它最終的 output 就是一個機率分布

00:31:30.866 --> 00:31:34.266
然後你一個 API request 裡面包了很多不同的問題

00:31:34.300 --> 00:31:36.000
一次傳過去嘛，對不對？

00:31:36.500 --> 00:31:38.766
我猜他們在做的事情呢

00:31:38.766 --> 00:31:41.633
他們是一個個問題會獨立評估

00:31:41.866 --> 00:31:44.366
這個其實不是我猜啦，這個是官方他們直接有說

00:31:44.533 --> 00:31:47.200
他們說每個問題他們是獨立評估的

00:31:47.200 --> 00:31:48.866
但是平行進行評估的

00:31:49.100 --> 00:31:51.400
所以說你增加你的問題數量

00:31:51.433 --> 00:31:53.533
不會增加延遲的時間太多

00:31:53.966 --> 00:31:56.166
OK，好，那他只有講到這邊啦

00:31:56.166 --> 00:31:57.733
但是具體怎麼做呢？

00:31:57.800 --> 00:32:00.333
我覺得他應該暗示得蠻清楚的

00:32:00.333 --> 00:32:02.966
就是配合我們剛剛發現的另外一個線索

00:32:03.000 --> 00:32:06.500
就是你的 state 加任意一個問題加選項

00:32:06.500 --> 00:32:08.366
不能超過 32K token

00:32:08.400 --> 00:32:10.766
所以說這個 32K token 應該

00:32:10.766 --> 00:32:13.400
就是它的 context length，32K

00:32:13.800 --> 00:32:18.133
然後你問的所有問題會一個一個被分開拆出來

00:32:18.166 --> 00:32:22.166
然後再包成一個 batch 進行一次的推論

00:32:22.200 --> 00:32:25.233
一次的 forward pass 這樣子

00:32:25.233 --> 00:32:30.400
OK，就有點像是說，就一樣你今天用傳統的 LLM

00:32:30.433 --> 00:32:36.466
然後你可能你的 API 你 send 一個 request 給這個 NVIDIA 的機櫃

00:32:36.466 --> 00:32:39.333
然後還有另外一個使用者的 request

00:32:39.366 --> 00:32:42.166
然後這個 NVIDIA 機櫃會把你們兩個的 request

00:32:42.166 --> 00:32:44.700
跟很多其他人的 request 包在一起

00:32:44.733 --> 00:32:46.166
一次進行推論

00:32:46.200 --> 00:32:49.433
然後一直產出很多個 token，是一樣的道理

00:32:49.433 --> 00:32:51.133
只是他們這邊在做的

00:32:51.133 --> 00:32:54.366
就是你的每個問題會被分開拆出來這樣子

00:32:54.366 --> 00:32:56.900
所以我講了這麼多，我只是想幫你建立一個直覺

00:32:56.900 --> 00:32:59.900
就是你今天看到 Jev 回答一個問題

00:32:59.933 --> 00:33:03.933
其實它在做的運算其實是很接近

00:33:03.933 --> 00:33:07.800
就是一個 LLM 產生一個 token

00:33:07.800 --> 00:33:10.800
OK，就這樣而已，就它吐一個 token 出來

00:33:10.800 --> 00:33:12.500
就完成了它所有的任務

00:33:12.633 --> 00:33:15.500
從這邊你就可以了解到

00:33:15.500 --> 00:33:17.066
為什麼 Jev

00:33:17.066 --> 00:33:22.533
它可以有這麼大量的速度的提升跟成本的節省

00:33:22.566 --> 00:33:25.533
快 200 倍，省 400 倍的成本

00:33:25.800 --> 00:33:26.233
為什麼呢？

00:33:26.466 --> 00:33:27.800
因為它只吐一個 token 啊

00:33:29.166 --> 00:33:31.600
它只跑一次啊，就結束啦

00:33:32.033 --> 00:33:35.333
那一般的 LLM，如果給出一個 2000 字的回答

00:33:35.333 --> 00:33:37.033
它就是要跑 2000 次啊

00:33:37.233 --> 00:33:38.300
它就要跑 2000 個 token

00:33:38.333 --> 00:33:39.900
2000 個 forward pass 嘛，對不對？

00:33:40.333 --> 00:33:42.966
整個權重要算過 2000 遍

00:33:43.133 --> 00:33:46.033
那這個大方向的直覺，我覺得是不太可能會錯的啦

00:33:46.200 --> 00:33:49.133
OK，就很多也是他們官方已經間接承認的東西

00:33:49.533 --> 00:33:52.633
我覺得我這邊比較猜測我自己的想法的部分

00:33:53.000 --> 00:33:58.800
只是在於它 255 個 classifier head 的 implementation

00:33:58.833 --> 00:34:00.766
那些細節的部分啦

00:34:00.866 --> 00:34:02.900
但這個直覺是不會錯的

00:34:03.000 --> 00:34:04.733
你就是可以這樣子去思考 Jev

00:34:04.933 --> 00:34:08.633
那你現在完整理解了 Jev 的運作原理之後呢

00:34:08.666 --> 00:34:12.833
你再回來看一個 Jev 模型跟 LLM 模型的差別

00:34:12.833 --> 00:34:16.466
好，你就可以非常直覺地去理解到說為什麼

00:34:16.466 --> 00:34:19.100
這個 TypeSafe AI 會把它稱作

00:34:19.100 --> 00:34:21.300
會這樣子去 market 這個模型

00:34:21.333 --> 00:34:23.366
會把它稱作 System 1 模型

00:34:23.400 --> 00:34:25.666
然後會講出那些什麼完全不會

00:34:25.666 --> 00:34:28.433
hallucinate 之類的一些行銷用語嘛

00:34:28.433 --> 00:34:29.066
對不對？

00:34:29.100 --> 00:34:32.466
首先，它會叫做 System 1 模型呢

00:34:32.466 --> 00:34:34.766
當然就是一樣是來自於

00:34:34.800 --> 00:34:38.466
《Thinking, Fast and Slow》這本書

00:34:38.500 --> 00:34:44.766
他們講說人類的大腦有 System 1 跟 System 2 的這兩種思考系統

00:34:44.766 --> 00:34:46.466
System 1 是直覺腦

00:34:46.466 --> 00:34:49.333
就是你直接想也不想針對這個問題

00:34:49.366 --> 00:34:51.333
反射性地直接給出答案

00:34:51.766 --> 00:34:54.633
那 System 2 就是思考計畫腦

00:34:54.666 --> 00:34:55.666
就是針對

00:34:55.700 --> 00:35:00.433
這個問題你會花很多時間去認真地一步一步地思考

00:35:00.433 --> 00:35:03.433
去做計畫，去安排，然後再去回答

00:35:03.466 --> 00:35:05.966
一般的 LLM 是 System 2

00:35:05.966 --> 00:35:10.033
應該說現在絕大多數的 LLM 都是會思考的

00:35:10.033 --> 00:35:11.700
在回答問題之前

00:35:12.000 --> 00:35:14.933
好，那 Jev 它就是完全不會思考

00:35:14.966 --> 00:35:17.033
它反射性地針對這個問題

00:35:17.033 --> 00:35:20.666
直接給出一個答案的模型，所以說是 System 1

00:35:20.700 --> 00:35:23.266
那我知道有些人會說，欸不對啊

00:35:23.266 --> 00:35:25.833
這其實不久之前，大概兩年之前

00:35:25.833 --> 00:35:29.466
我們才在講說當時的 LLM 都是 System 1

00:35:29.500 --> 00:35:33.900
然後後來才慢慢因為 o1 的出現，模型開始會思考

00:35:33.933 --> 00:35:35.966
才開始變成 System 2 嘛，對不對？

00:35:35.966 --> 00:35:38.766
那不是原本的模型也是 System 1 嘛，對不對？

00:35:39.166 --> 00:35:40.300
是不是原本的模型

00:35:40.300 --> 00:35:42.500
其實也很接近 Jev 可以做到的事情？

00:35:42.900 --> 00:35:44.433
其實嚴格來說

00:35:44.433 --> 00:35:47.266
現在所有的大型語言模型都

00:35:47.300 --> 00:35:50.033
可以被迫做出 Jev 的行為

00:35:50.200 --> 00:35:54.433
就是你可以硬逼它變成是跟 Jev 類似的模型，OK

00:35:54.633 --> 00:35:58.000
然後也真的可以得到跟 Jev 一樣的 Speed Up，OK

00:35:58.233 --> 00:36:01.100
只是它的表現可能不一定像是原生的 Jev 這麼好

00:36:01.366 --> 00:36:02.666
那怎麼說呢？

00:36:02.866 --> 00:36:05.166
其實網路上在過去這幾天

00:36:05.166 --> 00:36:10.666
已經有大量的這些開源社群的人去想辦法做出

00:36:10.700 --> 00:36:13.966
一個開源版本的 Jev 模型

00:36:13.966 --> 00:36:18.566
使用的就是一些像是 Qwen 這種的

00:36:18.600 --> 00:36:21.200
這個要怎麼做呢？

00:36:21.200 --> 00:36:23.500
其實不用經過額外的訓練喔

00:36:23.766 --> 00:36:26.266
你只是要它有 Jev 的行為的話

00:36:26.266 --> 00:36:28.000
你不用額外再訓練它

00:36:28.400 --> 00:36:29.466
那這邊要怎麼做呢？

00:36:29.566 --> 00:36:31.700
其實比你想像中的更簡單喔

00:36:31.800 --> 00:36:35.466
假設你今天要用一個像是社群有人用的

00:36:35.466 --> 00:36:37.900
這個 Qwen3.5-4B 的模型

00:36:38.366 --> 00:36:40.200
你要把它變成 Jev，你要怎麼做？

00:36:40.400 --> 00:36:43.366
就是你一樣丟給它你的 state 跟你的 question

00:36:43.766 --> 00:36:50.066
就比如說你的 state 是這個客人說：「哇！你們餐廳的牛排實在是太好吃了！」

00:36:50.433 --> 00:36:51.966
那你的 question

00:36:51.966 --> 00:36:55.933
就是：「請問這則回覆是正面的還是負面的？」

00:36:57.200 --> 00:37:01.300
下面就有兩個選項，選項 A：正面，選項 B：負面

00:37:01.600 --> 00:37:06.666
你這邊就要把選項的代號要明確地標出來

00:37:06.700 --> 00:37:08.433
要標 A 跟 B

00:37:09.300 --> 00:37:13.133
之後你在 prompt 裡面就可以直接明確地跟它說

00:37:13.166 --> 00:37:15.866
針對目前的問題以及選項

00:37:15.866 --> 00:37:18.900
好，直接給我你會選哪一個選項

00:37:18.933 --> 00:37:19.033
OK

00:37:19.466 --> 00:37:21.766
所以說，你的整個 prompt 就是這樣

00:37:21.900 --> 00:37:23.400
我剛剛講的全部都是 prompt 的部分

00:37:23.766 --> 00:37:25.866
那接下來，Qwen 收到這個 prompt 之後

00:37:25.900 --> 00:37:28.466
它的第一步就是要開始產生 token 嘛，對不對？

00:37:28.500 --> 00:37:29.966
要產生出第一個 token

00:37:30.466 --> 00:37:32.166
好，那我們剛剛也有講到

00:37:32.200 --> 00:37:35.066
就是一般的 LLM 在產生一個 token 的時候

00:37:35.066 --> 00:37:37.400
它其實是在產生一個機率分布

00:37:37.433 --> 00:37:41.833
好，那更嚴格來說呢，它是產生所有可能的 token

00:37:41.866 --> 00:37:45.033
都會幫它打一個分數，叫做 logits

00:37:45.033 --> 00:37:49.533
logits 這個分數後續才會被轉換成機率分布

00:37:49.533 --> 00:37:52.700
透過一個叫做 softmax 的功能

00:37:52.733 --> 00:37:57.866
但反正它會為所有可能的 token 都打一個分數

00:37:58.133 --> 00:38:00.566
那理論上在所有 token 當中

00:38:00.566 --> 00:38:04.100
字母 A 的分數應該是最高的嘛，對不對？

00:38:04.500 --> 00:38:09.866
因為我們就是叫它直接給出你的選項啊

00:38:09.900 --> 00:38:14.033
所以說它理論上應該最有可能直接吐出 A 這樣子

00:38:14.466 --> 00:38:16.633
但它也有可能吐出其他的嘛，對不對？

00:38:17.033 --> 00:38:19.400
就你同樣的一個 prompt 丟給一個 LLM

00:38:19.433 --> 00:38:20.233
叫它去回答

00:38:20.666 --> 00:38:22.400
它有時候會直接就給你回答「A」

00:38:22.433 --> 00:38:23.766
沒錯，這是符合你的需求

00:38:23.933 --> 00:38:26.166
但有時候它會回答「答案是 A」

00:38:26.166 --> 00:38:27.866
那它第一個 token 呢

00:38:27.900 --> 00:38:30.333
就是它其實是「答」這個 token

00:38:30.366 --> 00:38:32.900
「答」這個字的機率是最高的，對不對？

00:38:32.933 --> 00:38:34.833
但是所以說就是它不一定 A

00:38:34.833 --> 00:38:36.800
這個 token 的分數是最高的

00:38:36.800 --> 00:38:40.233
但是你其他的 token 的分數你就完全不要看啊

00:38:40.266 --> 00:38:46.100
你就直接拿 token A 的這個分數跟 token B 的這個分數

00:38:46.100 --> 00:38:47.133
只看這兩個分數

00:38:47.166 --> 00:38:49.200
然後把它放到 softmax function

00:38:49.200 --> 00:38:50.366
當中去算一個機率

00:38:50.400 --> 00:38:53.766
就是硬是只算這兩個 token 的機率

00:38:53.766 --> 00:38:56.100
然後兩個要加起來 100%

00:38:56.533 --> 00:38:58.466
那它這邊 softmax 算完之後

00:38:58.500 --> 00:39:00.733
可能就是 token A 的機率是 95%

00:39:00.766 --> 00:39:02.933
然後 token B 的機率是 5%。好

00:39:02.933 --> 00:39:06.066
那這個時候你就是得到跟 Jev 一樣的輸出了嘛

00:39:06.100 --> 00:39:06.933
對不對？

00:39:06.966 --> 00:39:10.000
就是一個針對你目前問題的所有選項的

00:39:10.000 --> 00:39:11.166
一個機率分布

00:39:11.200 --> 00:39:12.233
所以簡單來說

00:39:12.233 --> 00:39:14.666
因為 LLM 本身就是在產生機率分布

00:39:14.666 --> 00:39:16.433
所以說你也不用特別訓練它

00:39:16.466 --> 00:39:18.700
你也不用改目前的 LLM 的架構

00:39:18.733 --> 00:39:22.833
你只要單純不去解讀它產生的 token

00:39:22.833 --> 00:39:26.100
而是直接讀你想要的 token 的機率分布

00:39:26.133 --> 00:39:29.266
你就可以讓它變成一個 Jev 的模型了，OK

00:39:29.266 --> 00:39:30.000
就是這麼簡單

00:39:30.466 --> 00:39:33.833
那網路上確實也是有人把 Qwen3.5-4B 的模型

00:39:33.833 --> 00:39:35.433
變成一個 Jev 的模型

00:39:35.433 --> 00:39:40.933
然後它表現跟實際 TypeSafe AI 的 Jev 模型究竟有多接近呢？

00:39:40.966 --> 00:39:45.766
其實真的在簡單跟中等的問題上面都非常的接近喔

00:39:46.133 --> 00:39:48.866
簡單的問題基本上是接近 100%

00:39:48.900 --> 00:39:50.800
完全表現是非常好的

00:39:51.366 --> 00:39:53.466
那唯一是在一些比較困難一點

00:39:53.466 --> 00:39:55.866
複雜一點的問題上，它會輸給 Jev

00:39:56.066 --> 00:39:59.600
然後在整個機率的校準上，機率的校準上

00:39:59.633 --> 00:40:03.066
calibration 上，它也會輸給 Jev 一點

00:40:03.400 --> 00:40:05.533
OK，就算是中等的問題

00:40:05.533 --> 00:40:08.433
它答對了沒錯，但它的機率分布

00:40:08.466 --> 00:40:10.300
沒有到像 Jev 一樣這麼準

00:40:10.333 --> 00:40:13.633
但速度跟成本，其實都可以贏過 Jev

00:40:13.800 --> 00:40:15.800
這速度可以比 Jev 快一點點

00:40:15.966 --> 00:40:18.933
嚴格來說，這樣直接比也沒有到非常公平

00:40:18.933 --> 00:40:20.100
因為這個 Qwen

00:40:20.133 --> 00:40:23.066
我們是本地直接跑，那 Jev 是 API

00:40:23.100 --> 00:40:25.066
還要算網路的來回速度

00:40:25.066 --> 00:40:26.566
但你就算扣了

00:40:26.600 --> 00:40:31.500
就是給 Qwen 的這個速度一些網路的 punishment

00:40:31.533 --> 00:40:35.133
還是就是跟 Jev 差不多快，甚至比 Jev 快一點點

00:40:35.133 --> 00:40:39.033
我在想這個 Jev 的模型應該是比 4B 再大一點這樣子

00:40:39.066 --> 00:40:42.466
然後同時成本當然也贏過 Jev 嘛，對不對？

00:40:42.500 --> 00:40:45.300
因為這個 Qwen 的模型你隨便一台筆電就可以跑了

00:40:45.333 --> 00:40:47.266
所以你成本基本上是零

00:40:47.266 --> 00:40:49.166
所以天下所有的 LLM 你都

00:40:49.166 --> 00:40:51.200
可以直接把它當作 Jev 在用

00:40:51.233 --> 00:40:55.200
然後它立刻就可以得到幾百倍的速度跟幾百倍的

00:40:55.200 --> 00:40:57.000
這個成本優化這樣子

00:40:57.000 --> 00:41:02.133
但是它能不能真的在這些問題選項上面給出

00:41:02.166 --> 00:41:05.466
真的很有校準過的機率分布

00:41:05.500 --> 00:41:07.833
真的準確率高的答案呢？

00:41:07.833 --> 00:41:10.500
這個就是 Jev 它特別強的地方了

00:41:10.566 --> 00:41:11.733
這個就是因為 Jev

00:41:11.733 --> 00:41:15.200
它整個模型原生就是為了這樣子的

00:41:15.200 --> 00:41:17.900
use case 去訓練出來的嘛

00:41:17.933 --> 00:41:21.066
就是我們剛剛講的這個 RLCD 的部分嘛，對不對？

00:41:21.500 --> 00:41:25.800
那當然你一個模型跑了 RLHF，跑了 RLVR

00:41:25.800 --> 00:41:28.266
然後再硬逼它去做這種選擇題

00:41:28.300 --> 00:41:31.533
當然不會比一個做了 RLCD 的模型更好嘛

00:41:31.566 --> 00:41:32.400
對不對？

00:41:32.433 --> 00:41:36.100
這邊其實就回扣到我們剛剛在技術討論那邊說

00:41:36.100 --> 00:41:41.333
這個 RLCD 的 recipe，以及他們訓練的資料

00:41:41.333 --> 00:41:44.133
才是 TypeSafe AI 這間公司的護城河

00:41:44.166 --> 00:41:47.600
才是他們最強的技術的秘密

00:41:47.633 --> 00:41:51.766
好，那模型的架構本身其實真的還好

00:41:52.000 --> 00:41:54.533
好，那我們現在再回去看一下它那個

00:41:54.533 --> 00:41:57.066
Marketing 裡面講的最狂的一句話嘛

00:41:57.066 --> 00:42:00.133
就是 Jev 這個模型是完全不會有幻覺的

00:42:00.166 --> 00:42:02.566
不會 Hallucinate 的一個模型

00:42:02.566 --> 00:42:06.933
好，那我覺得這句話呢，也是有點半炒作意味啦

00:42:06.966 --> 00:42:10.133
就是其實它嚴格來說不到非常精準

00:42:10.166 --> 00:42:13.200
應該說要看你怎麼定義 Hallucinate 這件事情

00:42:13.200 --> 00:42:16.233
因為 Jev 沒錯，你如果問題就給它五個選項

00:42:16.233 --> 00:42:20.300
那它只可能輸出這五個選項的其中一個

00:42:20.333 --> 00:42:23.466
嚴格來說它就只會輸出這五個選項的一個機率分布

00:42:23.500 --> 00:42:25.933
然後你後續再選出其中一個嘛，對不對？

00:42:25.933 --> 00:42:29.500
那它無論如何，它不可能會選出第六個選項

00:42:29.533 --> 00:42:31.266
因為你根本就沒有給它第六個選項

00:42:31.300 --> 00:42:35.366
然後它也不可能會把你的選項的裡面的字給寫錯之類的

00:42:35.366 --> 00:42:37.666
因為它根本就不用輸出那些字

00:42:37.700 --> 00:42:39.366
它只要輸出機率分布

00:42:39.366 --> 00:42:41.266
後續選項你怎麼定義

00:42:41.266 --> 00:42:44.500
然後你最後選出哪個是你自己在選的

00:42:44.500 --> 00:42:44.900
OK

00:42:44.933 --> 00:42:46.366
所以 Jev 不可能會

00:42:46.366 --> 00:42:49.166
就是嚴格來說它不可能會有 type error

00:42:49.200 --> 00:42:51.133
它不可能會有這種型態的錯誤

00:42:51.133 --> 00:42:54.033
叫做 type error，它不可能會有 type error

00:42:54.033 --> 00:42:58.200
那我相信這也是為什麼他們公司的名稱叫做 TypeSafe AI 嘛

00:42:58.233 --> 00:42:58.966
對不對？

00:42:58.966 --> 00:43:03.066
因為它不會有 type error，但是如果你對於 Hallucinate

00:43:03.100 --> 00:43:05.166
對於幻覺定義比較廣一點的話

00:43:05.200 --> 00:43:10.133
就是包含到很明顯給錯誤的答案，也叫做幻覺的話

00:43:10.133 --> 00:43:14.066
那 Jev 也會出錯，它百分之百也會出錯

00:43:14.100 --> 00:43:15.766
它可能也會針對一個問題

00:43:15.800 --> 00:43:19.533
然後很有信心地給出一個很錯的答案

00:43:19.533 --> 00:43:21.000
很糟糕的機率分布啊

00:43:21.233 --> 00:43:22.733
那個算不算 hallucinate？

00:43:23.033 --> 00:43:24.866
我覺得對於有些人來說那個也算

00:43:25.300 --> 00:43:28.300
但是就看你怎麼定義 hallucinate

00:43:28.500 --> 00:43:30.633
我們現在完全理解了 Jev 這個模型

00:43:30.666 --> 00:43:32.033
它到底是什麼樣子的一個模型

00:43:32.066 --> 00:43:33.200
它怎麼運作的

00:43:33.233 --> 00:43:37.066
我們接下來要來講一下實際的應用場景有哪一些

00:43:37.066 --> 00:43:38.766
以及我的一些實測心得

00:43:38.800 --> 00:43:42.400
那這邊你要先了解的一個觀念呢

00:43:42.433 --> 00:43:44.400
我相信你到這邊應該自己也知道了

00:43:44.400 --> 00:43:47.933
但是就是，Jev 它不會全面取代 LLM

00:43:47.933 --> 00:43:50.000
它只能把目前的 LLM

00:43:50.033 --> 00:43:52.633
就是目前的這些 AI agent

00:43:52.633 --> 00:43:57.433
工作中一些比較單純的判斷選擇問題快速地處理掉

00:43:57.466 --> 00:44:01.000
這個就是 Jev 它的應用場景，這就是它的價值

00:44:01.166 --> 00:44:02.633
OK，那像什麼東西呢？

00:44:02.766 --> 00:44:04.800
像是模型路由嘛，對不對？

00:44:04.933 --> 00:44:05.666
model routing

00:44:06.000 --> 00:44:08.166
好，就今天使用者問了這個問題

00:44:08.166 --> 00:44:09.900
你應該用比較弱的模型

00:44:09.933 --> 00:44:12.466
還是要比較強的模型才可以去解決

00:44:12.500 --> 00:44:13.033
OK

00:44:13.066 --> 00:44:18.066
然後還有像是很大量的這種要初期的資料的篩選，OK

00:44:18.333 --> 00:44:20.500
好，就是比如說我們剛剛講到

00:44:20.533 --> 00:44:23.833
最一開始有講到一個履歷的例子嘛，對不對？

00:44:24.433 --> 00:44:27.866
你今天假設大公司收到好幾千封履歷，好

00:44:27.866 --> 00:44:31.033
那你要從這個履歷當中先挑出適合的人選

00:44:31.066 --> 00:44:36.033
那當然你可以每一封都全部都叫 GPT-6 Astra 去看，好

00:44:36.033 --> 00:44:39.400
那你可能 token 就會燒蠻多的這樣子

00:44:39.433 --> 00:44:42.200
但是你如果是用 Jev，好

00:44:42.233 --> 00:44:47.100
先把五千封的履歷先挑出其中的兩百封就好了

00:44:47.133 --> 00:44:51.266
好，那快速地，Jev 可以很快速地做到這個挑選

00:44:51.266 --> 00:44:52.766
然後挑出兩百封

00:44:52.800 --> 00:44:55.833
那兩百封再交給 Astra 去一封一封看

00:44:55.833 --> 00:44:58.866
這樣是不是你的 token 就會省非常多

00:44:58.900 --> 00:45:00.700
然後整個過程也會快很多

00:45:00.700 --> 00:45:01.200
對不對？

00:45:01.233 --> 00:45:03.900
這個 GPT-6 Astra 在看履歷的時候呢

00:45:03.900 --> 00:45:07.266
可能就是真的根據你給的這個標準呢

00:45:07.300 --> 00:45:08.766
然後一條一條地看

00:45:08.800 --> 00:45:11.433
這個人的經歷是否有符合

00:45:11.433 --> 00:45:13.266
一條一條檢查之類的，然後

00:45:13.300 --> 00:45:16.266
每次檢查都還可能還要再燒一些 token

00:45:16.266 --> 00:45:18.000
去思考之類有的沒的。好

00:45:18.000 --> 00:45:20.966
但 Jev 它今天就是，它看一封履歷的時間

00:45:21.000 --> 00:45:23.933
就等同於 GPT-6 Astra 產出一個 token 的時間

00:45:23.933 --> 00:45:24.900
一個 token

00:45:24.933 --> 00:45:28.466
就它吃了你的徵才標準跟目前這個人的履歷之後

00:45:28.466 --> 00:45:30.566
就直接吐出一個機率分布啦

00:45:30.600 --> 00:45:31.700
就 1 到 5

00:45:31.700 --> 00:45:33.300
你可能是給它選項 1 到 5

00:45:33.333 --> 00:45:37.100
這個程度，5 是最符合，1 是最不符合

00:45:37.133 --> 00:45:39.300
然後它就直接吐出一個機率分布

00:45:39.333 --> 00:45:39.733
然後選

00:45:39.733 --> 00:45:41.166
然後你立刻從這個機率分布

00:45:41.200 --> 00:45:42.600
就直接算出這個人是 5

00:45:42.633 --> 00:45:43.333
這個人是 4

00:45:43.333 --> 00:45:44.066
這個人是 2

00:45:44.100 --> 00:45:44.866
這個人是 3

00:45:44.900 --> 00:45:45.866
這個人是 5

00:45:45.866 --> 00:45:46.066
好

00:45:46.100 --> 00:45:47.566
然後就很快，就超快

00:45:47.566 --> 00:45:48.900
就篩出 200 封了，然後

00:45:48.933 --> 00:45:50.000
當然這只是一個例子啊

00:45:50.033 --> 00:45:52.600
我們前面講到的那像什麼客服啊

00:45:52.600 --> 00:45:55.033
像什麼 email 的處理啊

00:45:55.033 --> 00:45:56.566
Jev 也全部都可以做

00:45:56.600 --> 00:45:57.266
你能想到

00:45:57.300 --> 00:46:01.400
你只要能夠把你的問題去 frame 成一個分類問題

00:46:01.433 --> 00:46:04.800
然後有明確的選項可以讓 Jev 去選的話

00:46:04.800 --> 00:46:06.266
Jev 都可以解決

00:46:06.300 --> 00:46:08.266
只不過 Jev 它模型

00:46:08.266 --> 00:46:09.600
它本身有一個限制

00:46:09.633 --> 00:46:12.433
就是它沒有視覺能力

00:46:12.466 --> 00:46:13.766
它是一個純文字模型

00:46:13.766 --> 00:46:17.933
所以說，今天假如你的問題是跟視覺有相關的話

00:46:17.966 --> 00:46:20.433
你就是還要再接其他的工具

00:46:20.433 --> 00:46:22.566
讓它可以理解這個圖片的內容

00:46:22.600 --> 00:46:24.966
比如說接一個 OCR 的工具等等的

00:46:25.200 --> 00:46:30.133
OK，好，那我看到網路上很多人都在 demo 的一個應用場景

00:46:30.133 --> 00:46:34.866
就是讓 Jev 去做 computer use，去使用電腦

00:46:34.900 --> 00:46:37.300
OK，好，那一開始你看一些這些 demo

00:46:37.333 --> 00:46:38.566
你真的會覺得，哇

00:46:38.566 --> 00:46:41.366
這好像真的是一個 Game Changer 喔

00:46:41.400 --> 00:46:45.200
因為 computer use 的問題呢，就是現在的做法啦

00:46:45.200 --> 00:46:49.100
就基本上你要叫 GPT-6 Astra 去操作一個網站

00:46:49.100 --> 00:46:53.433
它基本上就是它會看到這個網站的截圖

00:46:53.433 --> 00:46:53.633
OK

00:46:53.666 --> 00:46:57.933
那它就直接根據這個截圖去 reason 現在我這個步驟

00:46:57.933 --> 00:46:59.100
我應該要點什麼東西

00:46:59.133 --> 00:47:05.400
然後就直接產出它要點的座標跟它的動作

00:47:05.433 --> 00:47:06.766
可能是 click 還是 double click

00:47:06.766 --> 00:47:10.666
Whatever，然後再 call 一個操作的工具

00:47:10.666 --> 00:47:12.933
然後就完成這次的點擊

00:47:12.933 --> 00:47:17.566
每一個步驟它都要這樣做一個 reasoning 的過程

00:47:17.600 --> 00:47:20.066
有時候它還會思考一下嘛

00:47:20.066 --> 00:47:23.533
對不對？就看到這張圖片，還要思考個幾句

00:47:23.533 --> 00:47:27.433
想一下說，我現在應該要點哪一個按鈕啊？

00:47:27.466 --> 00:47:29.600
然後應該要怎麼點啊？

00:47:29.600 --> 00:47:31.966
然後什麼，反正就會產生很多 token

00:47:31.966 --> 00:47:33.633
然後會花很久的時間，OK

00:47:33.633 --> 00:47:36.600
那 Jev 如果它真的電腦可以用得很好

00:47:36.633 --> 00:47:37.300
很快的話

00:47:37.300 --> 00:47:39.066
基本上因為每個步驟其實

00:47:39.100 --> 00:47:42.200
你可以想像你都可以把它 frame 成一個分類問題嘛

00:47:42.233 --> 00:47:42.866
對不對？

00:47:42.866 --> 00:47:43.000
好

00:47:43.033 --> 00:47:46.733
就你今天的目標是要點選這間

00:47:46.733 --> 00:47:50.700
網路電商它的最新的鞋子的產品

00:47:50.733 --> 00:47:51.766
然後把它放到購物車

00:47:51.766 --> 00:47:52.933
那你有這個目標

00:47:52.966 --> 00:47:57.800
然後你現在的網頁的狀態是這樣

00:47:57.833 --> 00:47:59.400
你有這些按鈕

00:47:59.400 --> 00:48:02.833
然後這些按鈕現在目前是呈現這些狀態

00:48:02.866 --> 00:48:06.933
那你的選項就是有幾個層次

00:48:06.966 --> 00:48:10.633
第一層次是你要選你的動作是什麼

00:48:10.666 --> 00:48:12.600
就是按，你要按按鈕嗎？

00:48:12.633 --> 00:48:14.733
還是你要滑動？

00:48:14.733 --> 00:48:16.033
還是你要 blah blah whatever

00:48:16.066 --> 00:48:18.400
然後你選完了

00:48:18.400 --> 00:48:19.233
第一個動作之後

00:48:19.266 --> 00:48:20.700
你接下來第二個問題

00:48:20.733 --> 00:48:22.000
就你就它就問說

00:48:22.000 --> 00:48:23.166
你要按按鈕的話

00:48:23.166 --> 00:48:26.700
那網路上，你的網頁上有這些

00:48:26.733 --> 00:48:28.933
所有的按鈕可能加起來

00:48:28.933 --> 00:48:31.966
這個幾十個，不要超過 255 個就好了

00:48:32.000 --> 00:48:33.433
可能 100 多個之類的

00:48:33.466 --> 00:48:35.400
whatever，應該不會這麼多啦

00:48:35.433 --> 00:48:37.000
可能 50 個好了

00:48:37.000 --> 00:48:37.966
50 個按鈕

00:48:37.966 --> 00:48:39.600
請問你要選擇按哪一個？

00:48:39.600 --> 00:48:41.733
這也是一個選擇題啊，你就選了

00:48:41.733 --> 00:48:44.433
然後你就完成了這次的操作啊，不是嗎？

00:48:44.866 --> 00:48:49.400
那很明顯這個會比現在的 LLM 快非常多

00:48:49.433 --> 00:48:53.366
而且確實在進行 computer use 的過程當中

00:48:53.366 --> 00:48:58.133
你當然可能 high-level 的策略，然後要做什麼

00:48:58.133 --> 00:49:00.766
還是應該交給 LLM 去思考去制定

00:49:00.800 --> 00:49:01.566
沒錯

00:49:01.566 --> 00:49:04.233
但過程中會有超多這種小按鈕

00:49:04.266 --> 00:49:07.133
點來點去這種簡單很直覺的操作

00:49:07.433 --> 00:49:10.000
是不是理論上也都可以交給 Jev 處理？沒錯

00:49:10.400 --> 00:49:12.000
Jev 的能力是真的到的

00:49:12.033 --> 00:49:14.066
它真的是可以做到這件事情的

00:49:14.166 --> 00:49:19.700
然後確實網路上我們也看到蠻多的這些 demo 在使用 Jev 去操作電腦

00:49:19.733 --> 00:49:22.266
然後結果也真的都超級好的

00:49:22.266 --> 00:49:25.100
尤其有些有跟一般的 LLM 去進行比對的

00:49:25.133 --> 00:49:27.233
像是我有看到有一個 GitHub Repo

00:49:27.266 --> 00:49:30.933
他們是拿由 Jev 組成的 computer use 系統

00:49:30.933 --> 00:49:35.200
跟這個 Claude Opus 的 computer use 去進行比較

00:49:35.233 --> 00:49:37.833
然後結果真的是蠻扯的啦

00:49:37.833 --> 00:49:41.800
就是 Jev 跟 Opus 都一樣有完成目標

00:49:41.800 --> 00:49:46.233
但是 Jev 它的成本比 Opus 低了一百多倍

00:49:46.633 --> 00:49:51.200
然後這個 Latency，就是整體的這個速度呢

00:49:51.200 --> 00:49:53.466
也比 Opus 快蠻多的

00:49:53.500 --> 00:49:55.433
但是並沒有快一百多倍喔

00:49:55.466 --> 00:49:58.100
它只有快三倍左右，OK

00:49:58.433 --> 00:50:00.633
那聽到這邊你可能就覺得很奇怪

00:50:00.633 --> 00:50:03.600
就 Jev 它不是應該要比 Opus 快超級多倍嗎？

00:50:03.866 --> 00:50:07.266
好，就它等於是每一個步驟只有產生一個 token 啊

00:50:07.300 --> 00:50:09.266
好，甚至一兩個 token 之類的

00:50:09.300 --> 00:50:10.666
那應該快很多才對啊

00:50:10.666 --> 00:50:12.900
欸，但是沒有。為什麼？

00:50:12.900 --> 00:50:16.366
好，因為 Jev 它不能獨立地就操作電腦

00:50:16.400 --> 00:50:20.600
它要有其他的東西，其他的

00:50:20.600 --> 00:50:24.466
首先，Jev 沒有視覺能力

00:50:24.466 --> 00:50:28.733
所以它無法直接看網頁目前狀況的截圖

00:50:28.766 --> 00:50:31.966
它必須要讀網站的 DOM Tree

00:50:32.000 --> 00:50:35.166
看網站本身的原始 HTML

00:50:35.200 --> 00:50:39.200
看網站的 accessibility tags

00:50:39.233 --> 00:50:41.900
accessibility tags

00:50:41.900 --> 00:50:45.666
就是網頁中針對網頁各個按鈕

00:50:45.700 --> 00:50:47.866
它會有一個這個按鈕

00:50:47.866 --> 00:50:49.833
它是什麼東西的標示

00:50:49.866 --> 00:50:53.933
它這個標示會存在呢，其實是為了一些特殊的狀況

00:50:54.066 --> 00:50:56.333
就比如說你眼睛看不到

00:50:56.366 --> 00:50:59.900
對於盲人來說呢，你要使用一個網頁

00:50:59.900 --> 00:51:03.900
它可能會就是有一些朗讀的功能啊等等的

00:51:03.900 --> 00:51:05.633
那瀏覽器的朗讀功能呢

00:51:05.666 --> 00:51:07.900
其實就是在讀這些標示這樣子

00:51:08.333 --> 00:51:10.233
那 Jev 就是要靠著這些東西

00:51:10.266 --> 00:51:12.166
然後再加上一個 OCR 的模型

00:51:12.433 --> 00:51:13.500
這個 OCR 的模型

00:51:13.500 --> 00:51:15.966
就是 Optical Character Recognition 嘛

00:51:16.000 --> 00:51:16.633
對不對？

00:51:17.200 --> 00:51:19.200
這個就是我們常見的

00:51:19.233 --> 00:51:22.233
一個圖像的文字識別模型這樣子

00:51:22.700 --> 00:51:24.100
OK，就是它會從

00:51:24.133 --> 00:51:27.700
一個圖像裡面擷取出這圖像目前有哪些文字

00:51:27.700 --> 00:51:31.566
然後可能有些時候還會跟你講它在哪個地方

00:51:31.566 --> 00:51:33.500
然後哪個方位這樣子

00:51:33.500 --> 00:51:37.666
那反正 Jev 就只能靠著這些東西去操作電腦嘛

00:51:37.966 --> 00:51:40.800
那你可以想像這邊其實也會帶來一些限制

00:51:41.066 --> 00:51:44.200
就是包括很多網站的體驗呢

00:51:44.233 --> 00:51:48.733
其實你單純靠這些是沒有辦法真的完全正常操作的

00:51:48.766 --> 00:51:50.833
首先，很多的網站、很多頁面

00:51:50.833 --> 00:51:53.766
它的 accessibility tags 就沒有做得很好

00:51:53.966 --> 00:51:54.166
OK

00:51:54.400 --> 00:51:57.633
就是它本來就不是非常盲人 friendly 的

00:51:57.633 --> 00:51:59.500
就是有一些缺陷這樣子

00:51:59.866 --> 00:52:01.133
像是 Notion 啊

00:52:01.133 --> 00:52:03.666
它可能就沒有完全 full coverage

00:52:03.700 --> 00:52:06.500
那這個時候你可能就只能靠 OCR 了嘛

00:52:06.500 --> 00:52:07.033
對不對？

00:52:07.066 --> 00:52:09.600
因為你的 accessibility tags 沒有辦法

00:52:09.600 --> 00:52:12.166
讓你直接點到你想要點的按鈕

00:52:12.200 --> 00:52:14.600
但 OCR 也有它的缺陷

00:52:14.633 --> 00:52:16.900
就是它只能判斷文字嘛，對不對？

00:52:16.900 --> 00:52:20.166
就假設今天這個按鈕是一個圖示的話

00:52:20.200 --> 00:52:23.266
你是不是就完全沒有辦法點到了？

00:52:23.966 --> 00:52:26.166
Jev 就點不到這個按鈕了

00:52:26.433 --> 00:52:29.466
今天如果你的這個網站體驗又是

00:52:29.466 --> 00:52:32.100
一個比較互動程度比較高的

00:52:32.133 --> 00:52:37.100
比如說有很多 slider 啊，然後有些細膩的操作啊

00:52:37.100 --> 00:52:42.533
然後有一些比如說需要視覺推理的部分啊

00:52:42.533 --> 00:52:44.700
這種東西，這些所有的操作

00:52:44.733 --> 00:52:46.966
其實 Jev 都沒有辦法去做到

00:52:47.133 --> 00:52:49.566
然後你要知道，這不是一個模態的問題而已喔

00:52:49.700 --> 00:52:51.900
就是我相信下一代的 Jev

00:52:52.033 --> 00:52:53.766
絕對會有視覺能力，OK

00:52:53.966 --> 00:52:57.433
這個本身不是一個太困難的一件事情嘛，對不對？

00:52:57.533 --> 00:52:59.200
現在所有 LLM 都有視覺能力

00:52:59.233 --> 00:53:00.600
Jev 也可以有視覺能力

00:53:00.600 --> 00:53:03.633
因為 Jev 本身就是一個 LLM 的基底嘛，對不對？

00:53:03.633 --> 00:53:07.200
但是它有了視覺能力之後也不會解決這個問題

00:53:07.233 --> 00:53:11.133
它也不可能跟 Opus 跟這個 Astra 一樣

00:53:11.166 --> 00:53:15.166
這樣子去像人類一樣看著螢幕去使用電腦

00:53:15.166 --> 00:53:16.166
為什麼？

00:53:16.166 --> 00:53:19.733
因為網頁上能點的東西已經超過你的選項了嘛

00:53:19.766 --> 00:53:20.600
對不對？

00:53:21.200 --> 00:53:24.000
就是你的網頁上所有能點的東西

00:53:24.033 --> 00:53:28.600
就是可能你幾千個 pixel 乘幾千個 pixel

00:53:28.600 --> 00:53:30.000
幾百萬個耶

00:53:30.000 --> 00:53:32.533
你有幾百萬個可能可以點的東西耶

00:53:32.533 --> 00:53:33.900
那像是 LLM

00:53:33.933 --> 00:53:37.900
它就可以每次都輸出一個座標，OK，精準的座標

00:53:37.933 --> 00:53:39.266
任何網頁上

00:53:39.300 --> 00:53:40.533
它只要看得到的地方

00:53:40.533 --> 00:53:41.666
它都可以點得到

00:53:41.666 --> 00:53:42.966
然後看得到的東西

00:53:43.000 --> 00:53:43.966
它都可以點得到

00:53:43.966 --> 00:53:47.300
它完全不用管這個網頁它本身背後怎麼寫的

00:53:47.333 --> 00:53:51.966
但是 Jev，它因為只有 255 個選項可以選

00:53:51.966 --> 00:53:55.700
而且就算你未來下一代 Jev 選項更多

00:53:55.733 --> 00:53:57.433
變成這個兩倍啊

00:53:57.466 --> 00:53:59.400
四倍啊，無論如何

00:53:59.400 --> 00:54:03.566
不可能真的達到一個網頁所有能夠點的內容

00:54:03.600 --> 00:54:06.333
那就只有這些選項可以選

00:54:06.966 --> 00:54:08.033
就是只能想辦法

00:54:08.066 --> 00:54:09.700
把目前這個網頁所有

00:54:09.700 --> 00:54:12.833
可以點的東西想辦法呈現在這個選項當中

00:54:12.866 --> 00:54:15.433
那這就會是一個先天上的限制

00:54:15.466 --> 00:54:17.200
所以說先天上 Jev

00:54:17.200 --> 00:54:21.366
它就不可能能夠完成所有 computer use 的工作

00:54:21.366 --> 00:54:22.433
它只能解決

00:54:22.466 --> 00:54:26.033
就是網頁寫得好的、很 straightforward 的

00:54:26.033 --> 00:54:28.466
很單純的一些反覆的操作，OK

00:54:28.466 --> 00:54:29.766
它可以執行得非常好。好

00:54:29.800 --> 00:54:34.333
像是其實上禮拜我有測試用 Astra 去幫我訂餐廳

00:54:34.366 --> 00:54:36.100
然後你知道多扯嗎？

00:54:36.100 --> 00:54:37.300
原本 Astra

00:54:37.333 --> 00:54:40.933
可以很精準地選到我需要的人數跟時間

00:54:40.933 --> 00:54:42.933
那個我一點都不意外

00:54:43.166 --> 00:54:46.866
我意外的是，Astra 直接幫我把 CAPTCHA 做完耶

00:54:48.066 --> 00:54:50.333
那有夠扯的，就那個網站

00:54:50.333 --> 00:54:52.600
訂餐網站它有個 CAPTCHA

00:54:52.633 --> 00:54:56.600
是，CAPTCHA 就是那個網站拿來擋機器人的嘛

00:54:56.600 --> 00:54:56.833
對不對？

00:54:56.866 --> 00:54:59.133
就是你要驗證你不是一個機器人

00:54:59.133 --> 00:55:02.000
它有時候會給你一些小測驗嘛，對不對？

00:55:02.466 --> 00:55:05.233
有時候是最簡單的就是辨識花字啊

00:55:05.266 --> 00:55:07.100
但花字那個現在已經越來越少了

00:55:07.133 --> 00:55:09.733
因為現在對於現在的 AI 來說太簡單了

00:55:09.733 --> 00:55:12.233
所以這個網站的 CAPTCHA 是什麼，你知道嗎？

00:55:12.566 --> 00:55:14.033
它是三個角色

00:55:14.033 --> 00:55:15.466
卡通角色在那邊跳

00:55:15.466 --> 00:55:18.400
然後一直不斷地跳，動態地在那邊跳

00:55:18.433 --> 00:55:20.366
然後你要選出跳最高的那一個

00:55:20.366 --> 00:55:24.066
那這個對於一般的模型來說都超難的

00:55:24.100 --> 00:55:26.033
但是 Astra 竟然解決了

00:55:26.033 --> 00:55:27.466
你知道多扯嗎？

00:55:27.500 --> 00:55:28.033
就是 Astra

00:55:28.066 --> 00:55:30.766
它的解決方法就是它會截圖

00:55:30.766 --> 00:55:33.133
目前看這三個角色誰跳最高

00:55:33.166 --> 00:55:37.000
然後它就它一開始就直接截一張圖就直接選了

00:55:37.033 --> 00:55:39.000
它就發現這樣選

00:55:39.033 --> 00:55:40.233
它會選錯

00:55:40.233 --> 00:55:42.766
然後它就自己想一想，就發現說不行

00:55:42.800 --> 00:55:44.266
我應該要多截幾張圖

00:55:44.300 --> 00:55:46.666
我才可以得到一個動態的狀況

00:55:46.700 --> 00:55:49.766
因為剛好有可能這個角色原本會跳最高

00:55:49.800 --> 00:55:51.100
但它，我截圖的時候

00:55:51.100 --> 00:55:52.900
它剛好在最低點嘛，對不對？

00:55:52.933 --> 00:55:54.900
所以它就開始截很多張圖

00:55:54.900 --> 00:55:56.466
然後它的準確率就變超高

00:55:56.500 --> 00:55:59.333
然後就一下就把那個 CAPTCHA 解決了這樣子

00:55:59.333 --> 00:56:01.033
反正我覺得很酷啦

00:56:01.133 --> 00:56:02.500
但像這種問題呢

00:56:02.533 --> 00:56:05.600
Jev 就完全沒有辦法去解決，對不對？

00:56:06.133 --> 00:56:09.900
就你怎麼靠 OCR 去解決這樣子的 CAPTCHA？

00:56:09.933 --> 00:56:11.033
就不可能嘛

00:56:11.100 --> 00:56:13.700
所以我覺得 Jev 在 computer use

00:56:13.700 --> 00:56:15.966
這件事情上面絕對會有價值的

00:56:16.200 --> 00:56:19.600
但是它沒有辦法就直接取代掉現在的

00:56:19.600 --> 00:56:23.000
這個 GPT-6 Astra 的 computer use

00:56:23.400 --> 00:56:25.366
你今天一個使用者可能問

00:56:25.366 --> 00:56:27.833
GPT-6 Astra 的問題有無限多種

00:56:27.933 --> 00:56:30.200
它可能會操作的網站有無限多種

00:56:30.633 --> 00:56:34.733
你不可能預先想到哪些狀況你可以使用 Jev

00:56:35.833 --> 00:56:39.233
假設今天你就是很明確地有

00:56:39.266 --> 00:56:43.200
一個工作流是要操作特定的網站

00:56:43.233 --> 00:56:45.100
然後要做特定的操作的話

00:56:45.100 --> 00:56:47.866
你確實如果有這個固定的工作流

00:56:47.866 --> 00:56:51.000
你可以讓 Jev 去處理一部分的工作，OK

00:56:51.033 --> 00:56:53.400
很標準化的流程，很標準化的網站

00:56:53.400 --> 00:56:55.833
你就直接讓 Jev 去做，那就會很快

00:56:56.033 --> 00:56:58.033
好，那我自己也有簡單實測一下

00:56:58.033 --> 00:56:59.366
Jev 它的能力這樣子

00:57:00.400 --> 00:57:03.900
我其實有試很多不同 Category 的問題啦

00:57:03.900 --> 00:57:06.100
但是滿多都是假想的問題

00:57:06.400 --> 00:57:08.866
我覺得一個最直接最真實的問題

00:57:08.866 --> 00:57:10.333
我有叫它去用的是

00:57:10.366 --> 00:57:14.700
我叫 Jev 去幫我的真實信件歸類

00:57:14.700 --> 00:57:18.266
這個是我真實的信件，是來自我的信箱

00:57:18.266 --> 00:57:20.633
我真實收到的工作的信件

00:57:21.066 --> 00:57:22.466
我叫它去幫我分類

00:57:22.466 --> 00:57:24.333
然後這個其實也是我可能

00:57:24.333 --> 00:57:26.333
可以融入工作流的一個部分

00:57:26.366 --> 00:57:27.933
因為我工作流

00:57:27.966 --> 00:57:32.233
我現在有一個龍蝦在幫我處理管理專案嘛

00:57:32.266 --> 00:57:37.866
它會幫我讀信件，幫我理解我目前每個專案的進度

00:57:37.866 --> 00:57:41.033
我有時候常常問這個龍蝦的問題

00:57:41.066 --> 00:57:45.366
就是我現在有哪些信件是緊急要我回的？

00:57:45.400 --> 00:57:49.566
我覺得龍蝦目前回答這個問題都回答得非常好

00:57:49.566 --> 00:57:52.766
但它確實會需要花一點時間

00:57:52.800 --> 00:57:56.000
然後每一封去讀，再去判斷

00:57:56.033 --> 00:57:56.733
再去思考

00:57:56.733 --> 00:57:59.966
所以我這邊就直接叫 Jev

00:57:59.966 --> 00:58:03.733
去幫我針對我給它範例的信件

00:58:03.766 --> 00:58:05.766
去給出一些回答這樣子

00:58:05.766 --> 00:58:09.500
緊急程度是其中一個，但我也有問其他問題

00:58:09.533 --> 00:58:12.400
比如說直接幫我為這封信分類

00:58:12.433 --> 00:58:17.433
它是一個活動邀約，還是一個 scheduling 相關的

00:58:17.433 --> 00:58:20.133
還是一個 finance 相關的

00:58:20.166 --> 00:58:22.933
還是 follow-up，還是一個 FYI 等等

00:58:22.966 --> 00:58:26.900
然後目前的狀態等等，反正我有問它很多問題啦

00:58:26.900 --> 00:58:30.366
那我覺得直接跟大家講結論啦

00:58:30.366 --> 00:58:32.833
就是絕大多數的問題

00:58:32.866 --> 00:58:36.633
它回答都是完全正確的，然後機率分布

00:58:36.633 --> 00:58:38.333
我覺得也是非常接近的

00:58:38.366 --> 00:58:41.133
尤其是有一題我覺得非常令我驚豔的喔

00:58:41.166 --> 00:58:43.033
就是那一題呢

00:58:43.033 --> 00:58:46.900
那封信呢，是一個繳費，活動繳費的提醒，OK

00:58:46.933 --> 00:58:49.466
但是 tricky 的地方就是在於

00:58:49.466 --> 00:58:52.900
這個繳費期限已經過了，過了一天了，OK

00:58:52.933 --> 00:58:55.266
所以現在已經沒有辦法繳費了

00:58:55.300 --> 00:58:56.366
那針對這封信

00:58:56.366 --> 00:58:58.033
它的緊急程度是多高？

00:58:58.066 --> 00:59:00.900
那這邊確實是有一點討論空間沒錯嘛

00:59:00.900 --> 00:59:01.133
對不對？

00:59:01.133 --> 00:59:04.266
就有一些人可能會覺得

00:59:04.300 --> 00:59:05.800
那它就不緊急了

00:59:05.833 --> 00:59:09.033
應該說現在就完全不緊急了

00:59:09.166 --> 00:59:11.766
因為你不用管它，因為已經錯過繳費期限啦

00:59:11.833 --> 00:59:14.133
There's nothing you can do，對不對？

00:59:14.533 --> 00:59:17.200
有些人可能會這樣覺得，但是像我自己

00:59:17.233 --> 00:59:21.700
我個人覺得這個答案應該是非常緊急

00:59:21.733 --> 00:59:23.100
應該是最緊急的

00:59:23.100 --> 00:59:25.900
因為繳費期限還沒過太久

00:59:25.933 --> 00:59:30.133
還在 24 小時，只是超過 24 小時之內

00:59:31.266 --> 00:59:34.300
有可能有些活動單位，假設是重要活動的話

00:59:34.300 --> 00:59:35.966
他可能也是會通融一下

00:59:36.000 --> 00:59:38.433
然後就是讓我繳費嘛，對不對？

00:59:38.433 --> 00:59:41.966
所以說我自己個人還是會把它排成緊急啦

00:59:42.700 --> 00:59:45.933
像是 GPT-6 針對這一題呢

00:59:45.933 --> 00:59:49.800
它給出的答案就是「無法判斷」

00:59:50.066 --> 00:59:55.233
那 Jev 它針對這題給出的判斷就是「非常緊急」

00:59:55.500 --> 00:59:58.500
我覺得非常緊急就是比較好的一個答案

00:59:58.833 --> 01:00:00.600
Jev 甚至贏過了 GPT-6

01:00:00.600 --> 01:00:02.700
我覺得這個答案是非常好的

01:00:03.200 --> 01:00:09.433
雖然說它的整體的機率分布也沒有到非常有自信啦

01:00:09.466 --> 01:00:14.033
Jev 它選擇非常緊急的機率是 47%

01:00:14.066 --> 01:00:17.466
OK，所以它也不是超級自信覺得這是非常緊急的

01:00:17.700 --> 01:00:19.200
那這也是 good sign

01:00:19.233 --> 01:00:22.133
因為這題它本來就不應該有超級高的信心

01:00:22.333 --> 01:00:26.666
所以 overall 我覺得 Jev 給出的答案都是完全沒有問題的啦

01:00:27.000 --> 01:00:30.366
那當然我也沒有特別去 challenge

01:00:30.400 --> 01:00:32.700
它一些太刁鑽的問題啦

01:00:32.733 --> 01:00:36.433
因為我就真的是拿我的真實的 use case 去測試

01:00:37.300 --> 01:00:38.466
目前的結果是非常好的

01:00:38.666 --> 01:00:41.833
當然啦，我覺得這個本來就是預料中的結果

01:00:41.866 --> 01:00:43.433
這也沒什麼好意外的

01:00:43.433 --> 01:00:48.033
因為現在的 LLM 本來就是有很好的判斷能力

01:00:48.033 --> 01:00:52.266
Jev 對於這些一般的問題的判斷完全正確

01:00:52.300 --> 01:00:54.833
我覺得一點都不值得驚訝啦

01:00:54.833 --> 01:00:56.933
我覺得還蠻正常的啦

01:00:56.966 --> 01:01:01.000
主要還是說它的穩定性 overall 是真的很好的

01:01:01.033 --> 01:01:04.166
然後確實延遲跟成本也明顯

01:01:04.166 --> 01:01:08.366
明顯是有跟一般的 LLM 比起來很好的

01:01:08.400 --> 01:01:10.400
所以我目前測試到現在

01:01:10.433 --> 01:01:14.200
我是覺得 Jev 確實可以融入我的工作流當中

01:01:14.466 --> 01:01:17.133
只是具體來說怎麼操作

01:01:17.133 --> 01:01:21.500
我還要再花點時間去思考然後再去實驗

01:01:21.933 --> 01:01:25.933
但我已經可以看到它的融入工作流的潛能了

01:01:26.066 --> 01:01:27.600
最後我們來聊一下

01:01:27.633 --> 01:01:31.066
Jev 這個模型對於 AI 的意義究竟是什麼？

01:01:31.533 --> 01:01:35.400
因為我覺得有一些人可能稍微把

01:01:35.400 --> 01:01:38.866
這個 Jev 吹得有點太強大了

01:01:38.866 --> 01:01:43.266
講得好像是 Jev 會改變一切的這種感覺

01:01:43.300 --> 01:01:46.166
我自己在看 Jev 這個模型的時候

01:01:46.166 --> 01:01:49.200
當我真的開始完全理解它之後

01:01:49.233 --> 01:01:58.100
我覺得它不像是一個會大幅改變現在的 AI agent 典範的一個模型

01:01:58.133 --> 01:02:04.366
它比較像是在加速一個原本就有在發生的變化

01:02:04.366 --> 01:02:06.733
這個變化，這個趨勢呢

01:02:06.766 --> 01:02:11.333
就是所謂的 model routing，模型路由的趨勢

01:02:11.766 --> 01:02:14.533
它是在加速這個趨勢的進展而已

01:02:14.566 --> 01:02:17.733
並不是說把我們帶到了一條新的路上

01:02:18.266 --> 01:02:19.466
為什麼會這樣說呢？

01:02:19.866 --> 01:02:20.033
首先

01:02:20.033 --> 01:02:22.566
我們知道我們現在在使用 AI agent 的這個方式

01:02:22.566 --> 01:02:25.833
並不是成本效率上面最優化的方式嘛

01:02:25.866 --> 01:02:26.300
對不對？

01:02:26.300 --> 01:02:27.300
很明顯嘛

01:02:27.666 --> 01:02:31.500
就你今天訂閱那個 ChatGPT 200 美金的方案

01:02:31.500 --> 01:02:34.200
然後你叫 Astra 去做一件事情

01:02:34.766 --> 01:02:36.033
它從頭到尾

01:02:36.033 --> 01:02:39.833
從這個問題最一開始的思考，這個計畫

01:02:39.866 --> 01:02:43.233
然後到實際做這個 computer use 的每一個步驟

01:02:43.266 --> 01:02:45.166
全部都是它自己完成的嘛

01:02:45.200 --> 01:02:45.800
對不對？

01:02:45.800 --> 01:02:48.933
它並不會做到一半覺得這個問題比較簡單

01:02:48.966 --> 01:02:51.433
它就直接丟給那個 Luna 去解決

01:02:51.733 --> 01:02:54.500
它可能會有 multi-agent system 沒錯

01:02:54.533 --> 01:02:56.600
但是它就是 multiple Astra

01:02:56.600 --> 01:02:58.366
全部都是 Astra 這樣子

01:02:58.633 --> 01:03:00.933
但很明顯這邊有很多的成本跟

01:03:00.933 --> 01:03:02.733
這個效率的優化空間嘛

01:03:02.766 --> 01:03:03.566
對不對？

01:03:04.166 --> 01:03:07.600
很多簡單的事情真的不需要去交給 Astra 做

01:03:08.300 --> 01:03:14.300
未來呢，我覺得絕大多數人現在都有共識的一點

01:03:14.833 --> 01:03:21.133
未來我們會漸漸地走向一個更多 model routing 的混合系統

01:03:21.133 --> 01:03:23.666
有更多模型路由的系統

01:03:23.666 --> 01:03:27.633
同樣一個系統當中會有弱跟強的模型

01:03:27.666 --> 01:03:32.200
然後會動態地去決定目前這件事情要交給誰去處理

01:03:32.200 --> 01:03:33.833
那為什麼 model routing

01:03:33.866 --> 01:03:36.200
這樣的系統現在還沒有辦法普及呢？

01:03:36.333 --> 01:03:38.766
不是很多人都覺得這個是未來嗎？

01:03:38.866 --> 01:03:40.800
為什麼大家沒有一直往這邊走呢？

01:03:41.233 --> 01:03:43.933
我覺得目前有個蠻核心的卡點

01:03:43.966 --> 01:03:47.300
就是主要是因為模型的能力進步

01:03:47.300 --> 01:03:50.466
模型的能力變化實在是太過快速了

01:03:50.466 --> 01:03:53.933
導致整個工作流的變化也非常的快速

01:03:53.966 --> 01:03:56.933
我們現在的一個 LLM 的工作流呢

01:03:56.933 --> 01:03:58.633
可能年初是長這樣

01:03:58.666 --> 01:04:00.166
這個年中就變了

01:04:00.166 --> 01:04:04.533
你中間很多的步驟可能因為模型能力提升就改變了

01:04:04.566 --> 01:04:07.333
好，那你工作流沒有辦法定下來

01:04:07.333 --> 01:04:09.833
你就比較難有一個

01:04:09.833 --> 01:04:14.300
就是穩定地知道你有哪些事情要做

01:04:14.300 --> 01:04:18.166
那你就比較難就是穩定地去指派某一些不同的

01:04:18.200 --> 01:04:20.300
AI 模型去做這些事情嘛

01:04:20.333 --> 01:04:21.866
那當然對於有一些人

01:04:21.866 --> 01:04:24.333
他的工作流可能現在已經蠻標準了

01:04:24.366 --> 01:04:26.533
很確定了就是做這些事情

01:04:26.566 --> 01:04:30.700
然後就是要大量重複進行一些簡單的操作的時候

01:04:30.700 --> 01:04:34.433
他確實就是可以在他的 harness 當中

01:04:34.433 --> 01:04:38.166
把這個 model routing 做得蠻不錯的

01:04:38.200 --> 01:04:41.200
但是這樣子的人並不是大多數啦

01:04:41.233 --> 01:04:41.566
OK

01:04:41.566 --> 01:04:45.966
然後 OpenAI 也沒有覺得他們的這個產品

01:04:45.966 --> 01:04:48.666
可以成熟到直接把 model routing

01:04:48.700 --> 01:04:51.333
就是加到他們的這個 Agent 當中

01:04:51.333 --> 01:04:53.400
那他們其實之前有嘗試啦

01:04:53.600 --> 01:04:57.400
就是我有點忘了是 GPT-5 那一代還是哪一代

01:04:57.800 --> 01:04:59.466
但反正有一代模型呢

01:04:59.466 --> 01:05:03.000
就是你有一陣子你是不知道你在用哪個模型的

01:05:03.400 --> 01:05:04.133
大家還記得嗎？

01:05:04.166 --> 01:05:06.133
就你有時候，它根據你的問題

01:05:06.133 --> 01:05:08.933
它會給你一個比較爛的模型、比較笨的模型

01:05:09.233 --> 01:05:10.566
有時候又是比較好的模型

01:05:11.300 --> 01:05:15.533
那我記得那陣子就得到超多人的批評

01:05:15.533 --> 01:05:18.433
所以後來 OpenAI 就不幹這件事情了

01:05:18.466 --> 01:05:20.800
大家還是自己選模型這樣

01:05:20.800 --> 01:05:24.566
但你要知道，我覺得很多人會想要自己選模型

01:05:24.600 --> 01:05:27.133
並不是因為他們真的想要自己選模型

01:05:27.133 --> 01:05:32.033
而是因為 OpenAI 當時的 model router 真的太爛了

01:05:32.066 --> 01:05:36.633
然後，我覺得很多人可能他嘴上不願意承認啦

01:05:36.666 --> 01:05:39.533
但是如果今天一個 model router

01:05:39.533 --> 01:05:42.666
可以真的完美地幫他做模型選擇的話

01:05:42.700 --> 01:05:45.066
沒有人會想要自己選模型啦

01:05:45.066 --> 01:05:48.600
因為自己選模型就是額外一個思考的步驟

01:05:48.633 --> 01:05:51.866
然後額外的手動步驟嘛，對不對？

01:05:51.866 --> 01:05:53.766
那就還是麻煩啦

01:05:54.333 --> 01:05:55.900
OpenAI 也知道這一點

01:05:55.900 --> 01:05:58.433
他們其實未來所有東西都會合在一起

01:05:58.466 --> 01:06:02.300
未來那個 Chat 跟 Work 的這兩個 Tab 也會合在一起

01:06:02.333 --> 01:06:05.233
然後所有 Models 也全部合在一起

01:06:05.266 --> 01:06:08.966
就是一個統一的介面，任何問題

01:06:08.966 --> 01:06:12.400
任何的工作，你都直接丟給它

01:06:12.433 --> 01:06:13.866
然後它自己會判斷

01:06:13.866 --> 01:06:14.766
要不要用工具

01:06:15.066 --> 01:06:15.933
要用哪個模型

01:06:16.066 --> 01:06:16.866
要思考多久

01:06:17.266 --> 01:06:18.433
反正我講了這麼多

01:06:18.466 --> 01:06:20.433
我只想講說這個 model routing

01:06:20.466 --> 01:06:23.266
模型路由真的就是未來的趨勢啦

01:06:23.300 --> 01:06:26.533
只不過我們還在慢慢地一步一步朝那邊走這樣子

01:06:27.000 --> 01:06:29.100
那我覺得 Jev 的出現呢

01:06:29.100 --> 01:06:31.666
它就是會加速這個趨勢的普及

01:06:31.666 --> 01:06:32.933
OK，為什麼？

01:06:33.100 --> 01:06:38.133
因為首先 Jev 是一個很好的 off-the-shelf 的 model router，OK

01:06:38.133 --> 01:06:40.300
off-the-shelf 的意思就是

01:06:40.300 --> 01:06:42.866
你就直接拿它的 API 來用就好了

01:06:42.900 --> 01:06:44.733
你不用再額外去訓練它

01:06:44.733 --> 01:06:48.733
它自己本身就有很好的 model routing 的判斷能力

01:06:48.733 --> 01:06:50.733
這一點我自己也有測試過

01:06:50.733 --> 01:06:52.900
雖然我是用一些假想的問題

01:06:52.900 --> 01:06:54.566
但它都判斷得非常好

01:06:54.566 --> 01:06:57.566
就是哪些問題簡單，要丟給那個小模型

01:06:57.566 --> 01:06:59.333
哪些要丟給大模型等等的

01:06:59.366 --> 01:07:01.200
那這件事情本身呢

01:07:01.200 --> 01:07:06.866
就是可以降低大家自己實作 model routing 的門檻，對吧？

01:07:07.166 --> 01:07:11.266
至少 Router 本身，這是你不用再煩惱了

01:07:11.266 --> 01:07:14.500
你就丟給 Jev，去判斷就 OK 了

01:07:14.866 --> 01:07:19.566
你只要自己再把它那個問題跟選項調一下

01:07:19.600 --> 01:07:21.566
應該就沒問題了

01:07:21.733 --> 01:07:24.533
然後降低實作門檻的同時呢

01:07:24.533 --> 01:07:26.800
它又因為 Jev 爆紅了

01:07:26.800 --> 01:07:31.966
然後確實也就是真的能夠帶來遠遠超過現在

01:07:32.000 --> 01:07:36.133
LLM 的這個速度跟成本上面的優化

01:07:36.133 --> 01:07:40.866
所以說我相信很多人會開始正視 model routing

01:07:40.866 --> 01:07:42.566
正式想要在

01:07:42.566 --> 01:07:47.966
自己的架構中混合一些其他的模型這樣子

01:07:48.000 --> 01:07:50.800
當然，Jev 作為 model router 是一種可能性嘛

01:07:50.800 --> 01:07:51.433
對不對？

01:07:51.666 --> 01:07:56.433
但你直接使用 Jev 這也算是一個這個 model routing 嘛，對不對？

01:07:57.000 --> 01:07:59.700
就有一些工作交給原本的 LLM 做

01:07:59.733 --> 01:08:01.400
有一些是 Jev 直接處理

01:08:01.433 --> 01:08:03.233
這個也算是 model routing 啊

01:08:03.266 --> 01:08:05.300
這也是一個混合的模型架構嘛

01:08:05.300 --> 01:08:05.933
對不對？

01:08:05.966 --> 01:08:08.366
其實像我就是一個典型的例子嘛，對不對？

01:08:08.900 --> 01:08:12.533
現在我的龍蝦基本上就是使用 GPT-5.6

01:08:12.533 --> 01:08:16.800
其實我應該去換 Astra，但就是還沒找到時間

01:08:16.833 --> 01:08:18.566
然後目前用起來

01:08:18.600 --> 01:08:22.100
我的 use case 5.6 已經差不多了

01:08:22.133 --> 01:08:25.100
也沒有到非常有動力想要換

01:08:25.133 --> 01:08:29.966
反正我現在就是用 5.6，所有事情都是交給它處理

01:08:30.733 --> 01:08:32.900
Jev 的推出之後，我剛剛不是有跟大家講嗎？

01:08:32.966 --> 01:08:35.466
測試完了那個 Email 的分類之後

01:08:35.500 --> 01:08:38.966
我是真的覺得我可以把 Jev 融入我的工作流了

01:08:39.000 --> 01:08:42.666
那沒有 Jev 出來之前，其實嚴格來說

01:08:42.666 --> 01:08:46.233
我做不做得到這件事情？也是可以啊

01:08:46.366 --> 01:08:48.000
我拿一個 Luna

01:08:48.033 --> 01:08:52.200
或者是我拿一個甚至一個本地的開源模型

01:08:52.200 --> 01:08:54.000
一個 Qwen 之類的

01:08:54.033 --> 01:08:56.966
跑在我自己的 DGX Spark 上面

01:08:56.966 --> 01:08:59.400
甚至 Mac mini 都有可能

01:08:59.400 --> 01:09:00.566
就是超級小的

01:09:00.566 --> 01:09:02.100
其實也是可以啊，對不對？

01:09:02.633 --> 01:09:06.566
但有 Jev 出現呢，我就更想做這件事情啦

01:09:06.700 --> 01:09:09.000
所以我覺得接下來會發生的事情呢

01:09:09.000 --> 01:09:13.733
就是當然像我這些自己有在架一些工作流的人

01:09:13.733 --> 01:09:19.300
就會開始越來越多把 Jev 融入自己的工作流當中

01:09:19.300 --> 01:09:22.833
能夠節省一些成本跟時間是絕對的

01:09:22.866 --> 01:09:25.700
但也要看你的工作性質

01:09:25.866 --> 01:09:30.033
對於蠻多的工作來說，可能不會省到超級多

01:09:30.600 --> 01:09:34.000
然後有些工作會省到超爆多

01:09:34.500 --> 01:09:35.700
但就是不一樣

01:09:35.833 --> 01:09:37.266
像對我來說啦

01:09:37.266 --> 01:09:40.233
就是它幫我額外 Tag 一下這個

01:09:40.266 --> 01:09:42.533
Email 是哪一種類別啊

01:09:42.533 --> 01:09:44.000
什麼緊急程度啊

01:09:44.033 --> 01:09:47.033
其實真的對我來說 Impact 沒有到很大啦

01:09:47.166 --> 01:09:50.733
它不會省我多少的成本，然後同時可能

01:09:50.733 --> 01:09:51.900
就是在我問

01:09:51.933 --> 01:09:55.700
那個問題的時候幫我省下幾秒鐘的時間吧

01:09:55.700 --> 01:09:58.033
所以對我來說不是一個超級大的 game changer

01:09:58.033 --> 01:10:00.466
但對於那些比如說要 screen

01:10:00.500 --> 01:10:03.566
幾千封履歷的人來說絕對是有幫助的

01:10:03.566 --> 01:10:06.233
然後我覺得再下一步呢

01:10:06.266 --> 01:10:08.833
就是標準的 AI agent

01:10:08.866 --> 01:10:12.666
就會開始把 Jev 當作一個工具了

01:10:12.833 --> 01:10:14.766
可能在 model routing 之前

01:10:14.766 --> 01:10:16.500
它就是先自己做 routing

01:10:16.500 --> 01:10:18.233
然後把它當作一個工具吧

01:10:18.333 --> 01:10:19.800
我覺得比較可能的是這樣子

01:10:20.966 --> 01:10:25.000
換言之呢，比如說 Astra 在工作的過程中

01:10:25.000 --> 01:10:29.600
假設你叫 Astra 去做一個大量的 screening

01:10:29.633 --> 01:10:32.633
大量地去看大量的 email 之類的

01:10:32.633 --> 01:10:35.133
它可能就會 call 一下 Jev

01:10:35.133 --> 01:10:40.733
就等於說這個 Jev 融入了 AI agent 的 harness 當中的這種感覺

01:10:40.733 --> 01:10:43.733
我覺得下一步蠻可能會發生這樣子的事情啦

01:10:45.233 --> 01:10:48.300
反正無論如何，你可以想像的

01:10:48.333 --> 01:10:51.733
就是 model routing 一定是未來

01:10:51.733 --> 01:10:56.866
而且未來不只是你在 LLM 跟 Jev

01:10:56.866 --> 01:11:01.333
跟中等的 LLM 之間進行選擇

01:11:01.366 --> 01:11:05.433
還會有地端的 LLM 跟雲端的 LLM 的選擇

01:11:05.433 --> 01:11:07.133
會全部混在一起

01:11:07.166 --> 01:11:08.733
我覺得未來就是這樣

01:11:08.733 --> 01:11:13.800
對於我們這些科技宅來說，你想要的話

01:11:13.833 --> 01:11:18.400
你可以隨時把這些最新的 capability 融入到你的工作當中

01:11:18.400 --> 01:11:20.500
但是對於一般人來說

01:11:20.500 --> 01:11:24.500
我相信他們整個過程中他們都不會感覺到

01:11:24.533 --> 01:11:26.533
他們，像是 Jev 問世

01:11:26.566 --> 01:11:29.833
他們不會看到 Jev，也不會用到 Jev

01:11:29.833 --> 01:11:34.500
但是 Jev 會實質上慢慢地改變他們的

01:11:34.500 --> 01:11:37.566
AI agent 的速度跟成本

01:11:37.600 --> 01:11:40.466
這些是他們會慢慢體感到的

01:11:40.466 --> 01:11:43.300
他們不會知道過程中發生了什麼事情

01:11:43.333 --> 01:11:48.700
只有我們這些真的科技宅們才真的是知道這些內幕啊

01:11:48.866 --> 01:11:49.000
OK

01:11:49.666 --> 01:11:52.066
好，那麼這集科技浪就大概跟大家聊到這邊

01:11:52.466 --> 01:11:55.800
如果你覺得本集節目對於你了解

01:11:55.833 --> 01:11:58.266
Jev 來說是有點幫助的

01:11:58.266 --> 01:12:01.300
你覺得節目是有趣好聽的話呢

01:12:01.333 --> 01:12:03.466
歡迎給我們一個五星評分、留言

01:12:03.466 --> 01:12:06.933
然後把科技浪分享給你的親朋好友們

01:12:06.966 --> 01:12:08.866
我們就下週再見囉，拜拜！