WEBVTT
Kind: captions
Language: zh-TW

00:00:00.000 --> 00:00:04.109
每天都有一堆新的AI工具冒出來
是不是常常不知道該從哪裡開始

00:00:04.540 --> 00:00:06.616
別擔心這裡是AI懶人報

00:00:06.616 --> 00:00:13.222
每天幫你精選五個最多人討論的AI工具影片
每天十分鐘讓AI走進你的生活中

00:00:13.222 --> 00:00:17.017
讓你不知不覺成為效率大師
今天最有趣的是

00:00:17.017 --> 00:00:23.342
Sakana AI 不是靠單一超強模型翻盤
而是做了一個很會分工的AI經理人

00:00:23.560 --> 00:00:28.745
這件事如果跑順未來我們用AI寫程式
可能就不是自己下指令

00:00:28.745 --> 00:00:33.828
而是在管理一整隊模型
好那我們就從今天的重頭戲說起吧

00:00:34.040 --> 00:00:36.231
如果你這禮拜有在關注開發者社群

00:00:36.231 --> 00:00:43.095
你一定會看到一個叫做 Sakana AI 的日本新創公司
還有他們的新產品 Fugu Ultra

00:00:43.095 --> 00:00:47.889
在網路上引起了超級大的討論
Fugu Ultra 官方宣稱的資料非常驚人

00:00:47.889 --> 00:00:53.079
他們說 Fugu Ultra 在一系列的基準測試中
表現超越了 Fable 5 和 Mythos

00:00:53.183 --> 00:00:57.740
這些測試可不是普通的測試喔
像是 SWE Bench Pro

00:00:57.740 --> 00:01:04.025
它是目前軟體工程任務的黃金標準
Fugu Ultra 在上面拿到了 737 的分數

00:01:04.300 --> 00:01:10.914
你知道 Claude Opus 48 才 692 嗎
在另一個叫 LiveCodeBench 的測試裡

00:01:10.914 --> 00:01:15.900
Fugu Ultra 更猛直接衝到 932
把 Opus 48 遠遠甩在後面

00:01:16.100 --> 00:01:22.357
它不只在這些專業的程式碼測試上表現亮眼
連在研究生等級的科學推理終端機操作

00:01:22.357 --> 00:01:27.501
還有多代理任務上都表現得非常出色
但是這裡就有一個很關鍵的點

00:01:27.501 --> 00:01:33.139
你必須深入瞭解一下
因為 Fugu Ultra 跟你想像的完全不一樣

00:01:33.260 --> 00:01:37.454
它不是那種 Sakana AI 在東京的地下室
從零開始訓練出來

00:01:37.454 --> 00:01:42.100
然後就神奇地把 Anthropic 和 OpenAI 嚇跑的超大型基礎模型
完全不是

00:01:43.460 --> 00:01:47.850
Fugu Ultra 其實是一個多代理協調系統
但它特別的地方在於

00:01:47.850 --> 00:01:53.028
你只需要透過一個單一模型的 API 就可以呼叫它
這個區別非常重要

00:01:53.780 --> 00:01:59.454
當你呼叫 Fugu Ultra 的 API 時
你不是在跟一個單一的類神經網路對話

00:01:59.454 --> 00:02:04.437
你其實是在跟一個高度最佳化的指揮家互動
這個指揮家會接收你的指令

00:02:04.437 --> 00:02:06.643
把任務拆解成很多小的子任務

00:02:06.643 --> 00:02:14.280
然後把這些子任務分派給它背後預先串接好的
各種現有的頂尖模型像是 GPT-55Opus 48

00:02:14.280 --> 00:02:21.170
Gemini 31 Pro 等等
最後它會綜合評估驗證這些模型的結果

00:02:21.170 --> 00:02:25.979
然後才把最終的成果交給你
你可以把它想像成一個管絃樂團

00:02:26.300 --> 00:02:33.222
樂團指揮不需要比首席小提琴手更會拉小提琴
他只需要知道小提琴什麼時候該進場

00:02:33.222 --> 00:02:39.306
銅管什麼時候該加強音量還有誰走音了
順帶一提Sakana AI 的共同創辦人之一

00:02:39.306 --> 00:02:40.559
Llion Jones

00:02:40.559 --> 00:02:47.173
他可是當年那篇傳奇論文Attention Is All You Need的作者之一喔
Fugu 這個系統

00:02:47.173 --> 00:02:52.038
是他們基於兩篇非常有趣的論文打造出來的
第一篇論文提出了一個框架

00:02:52.038 --> 00:02:55.993
就是用一個比較小
效率高的 AI 來扮演經理人的角色

00:02:55.993 --> 00:03:03.586
然後它會給大型模型分配三個特定的角色思想家Thinker
製造者Maker和驗證者Verifier

00:03:03.960 --> 00:03:10.086
思想家負責分析問題和制定計畫
製造者負責寫程式或執行計算

00:03:10.086 --> 00:03:15.991
而驗證者則負責檢查工作成果
但第二篇論文才是真正厲害的地方

00:03:16.160 --> 00:03:21.697
這個系統會利用演化演算法和強化學習
自動去最佳化那個 AI 經理人

00:03:21.697 --> 00:03:25.576
給子代理們下達的提示詞prompt
也就是說

00:03:25.576 --> 00:03:31.493
不是人類工程師去寫這些協調系統的提示詞
而是這個 AI 透過不斷的試錯

00:03:31.493 --> 00:03:37.379
學習到如何最有效地跟其他 AI 溝通
它會保留那些有效的方法

00:03:37.379 --> 00:03:42.185
然後淘汰掉那些沒用的這整個過程
就跟自然選擇一樣

00:03:42.440 --> 00:03:48.873
說真的我想我們很多人都有過這種經驗對不對
你可能對自動化非常著迷花了三個小時

00:03:48.873 --> 00:03:53.436
在自己的環境裡搭了一個超複雜
超精密的多代理迴圈

00:03:53.880 --> 00:03:59.638
你給它設定了專門的子代理批評迴圈
還有記憶向量資料庫

00:04:00.060 --> 00:04:04.482
然後你按下確認鍵坐下來
看著終端機亮起來各種平行處理在跑

00:04:04.960 --> 00:04:06.093
結果四十五分鐘後

00:04:06.093 --> 00:04:13.843
它吐出來的只是一個你十分鐘就可以自己寫出來的基本 React 元件
你花在設計自動化流程的時間和金錢

00:04:13.843 --> 00:04:19.471
比手動完成這個任務還要多上好幾倍
而這也正是 Fugu Ultra 的兩面刃

00:04:19.620 --> 00:04:24.827
當你在真實世界情境中測試它時
那些基準測試的漂亮資料

00:04:24.827 --> 00:04:29.456
就開始出現裂痕了
沒錯它確實可以產生非常驚人的結果

00:04:29.640 --> 00:04:33.269
在一個盲棋測試中
模型必須在沒有看到棋盤的情況下

00:04:33.269 --> 00:04:35.320
只靠記憶來維護整個棋局狀態

00:04:35.320 --> 00:04:45.235
Fugu 連續跟其他頂尖模型還有一個 2100 ELO 等級的 Stockfish 引擎下了四盤棋
它始終保持完美的精準度

00:04:45.235 --> 00:04:50.785
而其他模型則開始混亂或出現幻覺
Fugu 最終每一盤都將死對方

00:04:51.260 --> 00:04:56.384
它還解決了 Rubiks cube 的 300 個謎題
其他模型都是零分

00:04:56.384 --> 00:05:01.624
但 Fugu 也是 300 題全對
但是在日常的軟體工程流程中

00:05:01.624 --> 00:05:06.991
這種協調的額外負擔代價非常大
不只是金錢上的還有時間上的

00:05:07.200 --> 00:05:12.826
在一個針對 38 個不同複雜程式碼任務
謎題和演算法設計的大規模對比測試中

00:05:12.826 --> 00:05:18.938
Fugu Ultra 在幾乎所有專案上都跟 Opus 48 打成平手
但是

00:05:18.938 --> 00:05:23.655
Fugu 完成任務所需的時間比 Opus 多了四倍半
成本更是高出五倍

00:05:24.260 --> 00:05:29.220
我們在講的是Fugu 總共花了 357 分鐘
而 Opus 只花了 80 分鐘

00:05:29.760 --> 00:05:34.881
一個 Opus 六秒就能搞定的任務
Fugu 可能要花好幾分鐘

00:05:34.881 --> 00:05:39.319
因為它必須把任務丟給它的思想家
製造者和驗證者迴圈一輪

00:05:39.520 --> 00:05:46.970
我們來看一個實際的例子打造一個完整的即時交易臺
包含前端和後端元件即時市場資料

00:05:46.970 --> 00:05:53.123
還有一個客製化的深色主題介面
Fugu Ultra 確實交付了一個最精美

00:05:53.123 --> 00:05:57.064
功能最豐富的介面
但它燒掉了 22000 個 token

00:05:57.064 --> 00:06:03.119
成本是 51 美分 Opus 48 也做得很好
用了 16000 個 token成本 31 美分

00:06:03.940 --> 00:06:07.349
但最關鍵的是
如果你只是想要一個超棒的前端設計

00:06:07.349 --> 00:06:13.083
GLM 52 或是 Chinchilla 52 只要大約 3 美分就能搞定

00:06:13.600 --> 00:06:16.485
在另一個複製遊戲 Crossy Road 的測試中

00:06:16.485 --> 00:06:23.151
Fugu Ultra 在效率上竟然打敗了 Opus 48
Opus 燒掉了將近一百萬個 token

00:06:23.151 --> 00:06:27.065
花了 79 分鐘
成本高達 37 美元才把遊戲做出來

00:06:27.065 --> 00:06:31.903
雖然成品非常精美
而 Fugu 只花了 22 分鐘成本 732 美元

00:06:33.040 --> 00:06:38.092
但是Fugu 做出來的版本操作是反向的
攝影機怪怪的而且還缺少音效

00:06:38.880 --> 00:06:44.939
所以Sakana Fugu 到底有什麼實際用途呢
如果它只是一個加強版的 API 包裝

00:06:44.939 --> 00:06:46.990
我們為什麼要關注它呢 首先

00:06:46.990 --> 00:06:55.136
它完美展示了我們未來的 IDE整合開發環境和本地環境會長什麼樣子
我們正在從寫程式的工程師

00:06:55.136 --> 00:07:01.442
轉變為管理系統的協調者 Fugu 證明瞭
如果你有一個很棒的路由和驗證系統

00:07:01.442 --> 00:07:05.583
你可以把現有模型的能力
推向遠超它們原生極限的境界

00:07:05.800 --> 00:07:08.104
第二點這對企業來說可能更重要

00:07:08.104 --> 00:07:11.561
Fugu 代表了一個巨大的地緣政治避險策略

00:07:11.860 --> 00:07:17.931
Sakana 明確地將 Fugu 定位為提供頂尖能力
同時沒有出口管制風險的產品

00:07:18.160 --> 00:07:24.043
假設你公司的客服系統全部綁死某個美國模型
一旦 API 因法規停掉

00:07:24.043 --> 00:07:29.008
整條客服流程就卡住
多代理系統至少能把任務改丟給其他模型

00:07:29.008 --> 00:07:33.448
這樣你就分散了風險
如果某個模型掛了或被限制

00:07:33.448 --> 00:07:38.315
協調器會自動繞過它
把任務分配給其他模型 當然諷刺的是

00:07:38.315 --> 00:07:47.766
Fugu 本身目前在某些歐洲地區也因為 GDPR 和法規限制而無法使用
所以這個避險策略還不夠完美

00:07:47.980 --> 00:07:50.780
那到底 Sakana Fugu 的結論是什麼呢

00:07:50.960 --> 00:07:56.339
它在系統設計方面是一個令人驚嘆的工程成就
但對於你日常使用來說

00:07:56.339 --> 00:08:02.416
如果你是一個單打獨鬥的創業者
或者是一個想快速推進專案的資深開發者

00:08:02.416 --> 00:08:09.346
你可能還是手動協調自己的流程會比較好
例如用 GPT-55 來處理複雜的邏輯

00:08:09.346 --> 00:08:15.824
用 GLM 52 來生成便宜的前端介面
然後用 Opus 48 來做架構規劃

00:08:16.140 --> 00:08:21.228
你自己管理這些成本效益
但還是要持續關注 Sakana

00:08:21.228 --> 00:08:26.683
因為一旦他們優化了這種協調的延遲問題
那真的會改變整個遊戲規則

00:08:27.220 --> 00:08:33.075
好剛剛我們聊到 Sakana Fugu 證明瞭
你可以透過巧妙的系統設計

00:08:33.075 --> 00:08:36.361
把現有模型的能力發揮到極致 這個概念

00:08:36.361 --> 00:08:40.281
也完美地銜接到 Anthropic 那邊正在發生的事情

00:08:40.520 --> 00:08:47.050
雖然 Sakana 證明瞭你可以透過精巧的協調來硬幹出智慧
但那些正在開發基礎模型的實驗室

00:08:47.050 --> 00:08:53.767
可沒有閒著 但最近

00:08:53.767 --> 00:09:00.304
一個新的模型名稱Claude Sonnet 5出現在 Anthropic 合作夥伴的系統中
我們大概有一段時間沒有聊到 Sonnet 了

00:09:00.304 --> 00:09:04.608
這裡快速幫大家複習一下
在 Claude 的生態系統中

00:09:04.608 --> 00:09:10.265
Sonnet 是一個中階的主力模型
在複雜的代理流程中例如 Claude Code

00:09:10.265 --> 00:09:14.222
你通常會用 Opus 來做高階的架構規劃
然後再啟動 Sonnet 來作為執行工作者

00:09:14.222 --> 00:09:23.997
處理那些成本較低速度較快的任務 通常
當一個模型名稱洩漏到合作夥伴的系統中

00:09:23.997 --> 00:09:28.285
這代表它很快就要推出了
早期的測試顯示

00:09:28.285 --> 00:09:29.683
Sonnet 5 將會是一個巨大的升級

00:09:30.220 --> 00:09:36.803
我們預期它會有 1 到 2 百萬 token 的脈絡長度context window
顯著提升的視覺能力

00:09:36.803 --> 00:09:41.443
以及對介面設計稿和架構圖更強的理解能力
但是這裡有一個關鍵的點

00:09:41.443 --> 00:09:46.820
又回到我們對代幣經濟的執著了
有報導指出

00:09:46.820 --> 00:09:52.414
Anthropic 在 Sonnet 5 上使用了一種新的分詞器tokenizer
這種新的分詞器對於完全相同的提示詞

00:09:52.414 --> 00:09:57.582
可能會比舊模型多消耗高達 30 的 token
乍聽之下

00:09:57.582 --> 00:10:01.922
這對你的 API 預算來說好像很糟糕
但這個取捨是

00:10:01.922 --> 00:10:07.695
這種分詞器讓模型能夠以更強大的推理能力和多模態理解能力來處理資訊

00:10:08.420 --> 00:10:13.017
這是一個經典的工程學權衡你在輸入端燒掉更多的 token

00:10:13.017 --> 00:10:22.211
但你在輸出端獲得一次成功率zero-shot success的機率會大大提高
這就減少了需要無止盡高成本的修改迴圈

00:10:24.864 --> 00:10:27.524
我們看到一個洩漏的演示
Sonnet 5 僅僅從一個提示詞

00:10:27.524 --> 00:10:28.854
沒有參考圖片就生成了一個完美

00:10:28.854 --> 00:10:35.498
高度詳細的 Nintendo Switch 2 的 SVG 圖檔
它的設計品味和空間推理能力都非常驚人

00:10:36.040 --> 00:10:38.472
但 Anthropic 那邊正在醞釀的可不止 Sonnet 5

00:10:38.728 --> 00:10:47.773
這就牽扯到 AI 開發的審查現實有多麼嚴峻了
我們知道Anthropic 的 Fable 5 架構

00:10:47.773 --> 00:10:50.737
那個能夠執行超狂
長週期自主代理流程的模型

00:10:50.737 --> 00:10:55.314
目前因為審查問題而停用了
但一個模型被限制公開 API 存取

00:10:55.314 --> 00:11:00.359
不代表實驗室就會停止工作
事實上這反而釋放了大量的運算資源

00:11:00.359 --> 00:11:02.624
這些資源原本是用於推理的

00:11:02.624 --> 00:11:07.355
現在他們可以把這些資源全部轉移到訓練上
根據可靠的洩漏

00:11:07.355 --> 00:11:12.367
一個新版本的 Mythos 架構
很可能是 Mythos 6已經訓練完成了

00:11:12.520 --> 00:11:17.670
據說它的能力比已經被限制的 Fable 5 還要強大得多
我們在說的是

00:11:17.670 --> 00:11:23.505
它具備了更高層次的長週期推理能力
改進的多步驟規劃能力以及在處理大規模

00:11:23.505 --> 00:11:27.280
整個程式碼庫遷移任務時
擁有高度可靠的執行能力

00:11:27.620 --> 00:11:32.180
但關鍵是它已經被限制了
現在大模型公司的競爭

00:11:32.180 --> 00:11:36.319
已經不只是誰模型更強
那些在幕後開發的模型

00:11:36.319 --> 00:11:42.233
現在在自主執行方面已經強大到
它們在公開之前就觸發了法規門檻

00:11:42.440 --> 00:11:48.472
Anthropic 正在利用這些內部模型
來找出需要在系統中建立哪些防護措施

00:11:48.472 --> 00:11:54.854
以防止未來再次被限制 現在的問題是
他們是否會將 Mythos 6 公開釋出

00:11:54.854 --> 00:11:59.328
或者它將僅用於內部
生成合成資料並加速訓練接下來的模型

00:12:00.000 --> 00:12:04.470
當 Anthropic 正在努力應對這個複雜的審查迷宮時

00:12:04.470 --> 00:12:11.088
OpenAI 卻只是輕輕鬆鬆地準備推出他們自己的能力明顯往上跳一階的產品
有洩漏指出

00:12:11.088 --> 00:12:14.882
OpenAI 準備在本週推出一個新模型
有趣的是

00:12:14.882 --> 00:12:20.477
這些洩漏對於模型的命名方式意見分歧
有些來源稱它為 GPT-46

00:12:20.477 --> 00:12:26.974
而其他深入測試則稱它為一個功能非常強大的檢查點
叫做 GPT-56 Pro

00:12:27.180 --> 00:12:28.354
無論最終產品上的版本號是什麼

00:12:28.354 --> 00:12:31.373
我們從內部代號為Kindle Alpha的檢查點中看到的這些能力
都非常狂

00:12:33.973 --> 00:12:39.629
我們一直都在討論 AI 程式碼編寫的摩擦問題
像是模型會偷懶

00:12:39.629 --> 00:12:45.284
會給你請在此處插入其餘程式碼這樣的佔位符
以及它們在處理複雜

00:12:45.284 --> 00:12:52.010
有狀態的介面時會遇到困難 然而
一個關於 GPT-56 Pro 的洩漏測試顯示

00:12:52.010 --> 00:12:57.013
這個模型竟然能生成一個完整可遊玩的
第一人稱的 3D 室內房屋

00:12:57.460 --> 00:13:03.991
它建立了一個連貫的平面圖詳細的房間
以及一個流暢的第一人稱移動系統 而且

00:13:03.991 --> 00:13:13.528
它是在一個單一的 700KB 的 HTML 檔案中完成所有這些的
它大約花了 40 分鐘的運算時間來生成

00:13:13.528 --> 00:13:18.676
但它沒有偷懶沒有中途停止
它完美地執行了一個複雜有創意

00:13:18.676 --> 00:13:20.183
高度技術性的願景

00:13:20.660 --> 00:13:27.779
這正是你如果想要信任 AI 在你的程式碼庫中扮演自主代理時
所需要的這種不偷懶

00:13:27.779 --> 00:13:30.979
以目標為導向的執行能力 除此之外

00:13:30.979 --> 00:13:37.270
OpenAI 還將對他們的語音互動進行大規模升級
自從 GPT-4 Omni 推出以來

00:13:37.270 --> 00:13:42.749
語音助理領域一直在等待下一個大事件
現在GPT-BDI 1 語音模型登場了

00:13:42.940 --> 00:13:48.578
這是一個文字轉語音的升級
更是模型處理即時音訊方式的根本性轉變

00:13:49.000 --> 00:13:50.410
這個 BDI 模型

00:13:50.410 --> 00:13:55.422
它的知識截止日期是更新到 2025 年 8 月
可以跟你流暢地互動

00:13:56.020 --> 00:14:02.174
你不需要等它說完話你可以自然地打斷它
它會立即調整 在一個演示中

00:14:02.174 --> 00:14:07.839
使用者要求模型計算一個冗長
語速很快的故事中提到的食物數量

00:14:08.480 --> 00:14:13.880
模型即時聆聽處理音訊
並在中途準確地捕捉和計算了這些物品

00:14:13.880 --> 00:14:18.233
沒有漏掉任何一個
這感覺非常像人類的互動

00:14:18.680 --> 00:14:23.145
雖然這看起來可能只是一個有趣的消費者功能
但想想它對系統設計的影響

00:14:23.640 --> 00:14:30.373
我們正朝著一個這樣的世界邁進你與本地代理作業系統的互動
不再只是在終端機中打字

00:14:30.840 --> 00:14:37.614
它會是一個持續即時的語音對話
你邊口頭規劃系統AI 則在背景執行它們

00:14:37.820 --> 00:14:40.162
當你把所有這些事情放在一起看

00:14:40.162 --> 00:14:45.014
Sakana 的 Fugu 證明瞭協調系統可以媲美頂尖模型

00:14:45.014 --> 00:14:49.029
Anthropic 在暗中訓練著被限制的超級模型

00:14:49.029 --> 00:14:56.055
而 OpenAI 則推出了零樣本的 3D 環境和即時語音功能
這個發展趨勢就非常清楚了

00:14:56.220 --> 00:15:02.509
技術優勢不再是誰能寫出最好的提示詞
而是誰更懂得系統架構 白話說

00:15:02.509 --> 00:15:07.625
就是同一件事到底該丟給哪個模型做
要花多少錢做完誰來檢查

00:15:08.160 --> 00:15:14.521
誰知道什麼時候該用像 Chinchilla 52 這樣便宜又快的模型來做簡單的介面

00:15:14.521 --> 00:15:21.193
什麼時候該部署像 Fugu 這樣的協調器來處理複雜的多步驟推理任務
以及如何管理代幣經濟

00:15:21.193 --> 00:15:27.581
才不會讓你的自主代理在你睡覺的時候把你搞到破產
如果你覺得今天的內容讓你有點收穫

00:15:27.581 --> 00:15:32.737
那就幫我到 Apple Podcast 按讚追蹤
留個五星好評吧

00:15:33.080 --> 00:15:40.117
FBIGThreads 搜AI懶人報就找得到我了
你的支援是讓我持續最佳化內容的最大動力

00:15:40.840 --> 00:15:43.534
今天的AI懶人報就報到這我是湯懶懶
我們明天見掰啦