影片筆記:EP348 - 日本模型空降AI前段班?Sakana Fugu 評測超越 Mythos!?單一模型時代結束了?如何用多代理協調系統,讓 AI 效能翻倍成長?
YouTube 影片框會固定在左上方;點擊右側逐字稿時間戳可跳到對應時間。
一句話總結
影片探討了 AI 競爭焦點從「單一模型能力」轉向「系統架構與多代理協調」的趨勢,重點分析了 Sakana AI 的 Fugu Ultra 系統如何透過協調多個模型在基準測試中超越單一頂尖模型,但指出其在實際軟體工程任務中面臨高昂成本與延遲的問題,同時披露了 Anthropic 與 OpenAI 最新模型的洩漏資訊與能力升級。
核心重點
Sakana AI 的 Fugu Ultra 系統:
- 這是一個多代理協調系統,而非單一基礎模型。它透過「AI 經理人」機制,協調 GPT-55、Opus 48、Gemini 31 Pro 等現有模型進行分工(思想家、製造者、驗證者)。
- 在基準測試(如 SWE Bench Pro、盲棋、魔方)中表現優異,甚至超越單一頂尖模型。
- 但在實際軟體工程任務中,其時間與成本效率遠低於直接使用單一頂尖模型(如 Opus 48)。
Anthropic 的模型動態:
- Claude Sonnet 5:洩漏資訊顯示其採用新分詞器(Tokenizer),換取更高的推理與多模態能力,但可能增加 Token 消耗。
- Mythos 6:被限制的 Fable 5 架構可能已轉為訓練更強大的內部模型 Mythos 6,用於長週期推理與程式碼庫遷移,目前僅限內部使用。
OpenAI 的新功能與模型:
- 新模型(Kindle Alpha / GPT-46 或 GPT-56 Pro):展現了強大的自主生成完整 3D 環境能力,能生成單一 HTML 檔案的完整可遊玩第一人称 3D 室內房屋。
- GPT-BDI 1 語音模型:具備即時雙向互動與語音處理能力,支援自然打斷與即時調整回應。
未來趨勢:
- AI 競爭焦點正從「撰寫提示詞」轉向「系統架構設計」與「模型協調策略」。
- 開發者需學會如何分配任務以平衡成本與效率,工程師角色可能轉變為系統協調者。
詳細大綱
一、 Sakana AI 與 Fugu Ultra 系統解析
- 公司背景:日本新創公司 Sakana AI,共同創辦人包含 Attention Is All You Need 論文作者 Llion Jones。
- 核心概念:
- 非單一超強基礎模型,而是「多代理協調系統」。
- 透過單一 API 呼叫,內部由「AI 經理人」指揮。
- 架構類似管絃樂團指揮,負責拆解任務並分派給預先串接的頂尖模型(如 GPT-55、Opus 48、Gemini 31 Pro)。
- 技術原理:
- 基於兩篇論文:一篇提出小模型扮演經理人分配角色(思想家 Thinker、製造者 Maker、驗證者 Verifier);另一篇利用演化演算法與強化學習自動最佳化提示詞(Prompt)。
- AI 經理人透過試錯學習如何與其他 AI 溝通,保留有效方法,淘汰無效方法。
- 效能評估:
- 優勢:在基準測試中表現驚人。
- SWE Bench Pro:737 分(超越 Opus 48 的 692 分)。
- LiveCodeBench:932 分。
- 盲棋測試:連續擊敗頂尖模型與 Stockfish 引擎(2100 ELO)。
- Rubiks cube:解決 300 個謎題,其他模型零分。
- 劣勢(現實情境):
- 協調負擔大:時間與成本高昂。
- 對比 Opus 48:Fugu 完成任務時間多 4.5 倍,成本高 5 倍。
- 案例:即時交易臺開發,Fugu 耗費 22,000 Token($0.51),Opus 48 耗費 16,000 Token($0.31)。若僅需前端設計,GLM 52 或 Chinchilla 52 成本僅約 $0.03。
- 案例:複製遊戲 Crossy Road,Opus 48 耗費 $37,Fugu 耗費 $7.32 但成品有操作反向、攝影機問題及缺音效。
- 應用價值:
- 展示未來 IDE 與本地環境趨勢:工程師轉變為系統協調者。
- 地緣政治避險:分散單一美國模型 API 停用的風險,透過協調器繞過限制。
- 結論:目前對單打獨鬥創業者或資深開發者而言,手動協調(如 GPT-55 處理邏輯、GLM 52 生成介面、Opus 48 規劃架構)可能更具成本效益,但需持續關注其延遲優化。
二、 Anthropic 的模型發展與審查現狀
- Claude Sonnet 5 洩漏:
- 在合作夥伴系統中出現,預示即將推出。
- 預期具備 1-2 百萬 Token 脈絡長度(Context Window)。
- 顯著提升視覺能力與對介面設計稿、架構圖的理解。
- 新分詞器(Tokenizer)權衡:
- 可能比舊模型多消耗高達 30% 的 Token。
- 代價換取更強大的推理能力與多模態理解,提高一次成功率(Zero-shot success),減少高成本的修改迴圈。
- 演示:僅憑單一提示詞生成高度詳細的 Nintendo Switch 2 SVG 圖檔。
- Fable 5 與 Mythos 6:
- Fable 5 因審查問題停用公開 API 存取。
- 停用的運算資源轉用於訓練內部模型。
- 洩漏顯示新架構 Mythos 6 已訓練完成,能力超越 Fable 5,具備高層次長週期推理、多步驟規劃及大規模程式碼庫遷移能力。
- 目前僅限內部使用,用於生成合成資料或加速訓練。
三、 OpenAI 的新模型與語音升級
- 新模型洩漏(Kindle Alpha / GPT-56 Pro):
- 版本號爭議:來源稱 GPT-46 或 GPT-56 Pro。
- 能力展示:生成完整可遊玩的第一人稱 3D 室內房屋(連貫平面圖、詳細房間、流暢移動系統)。
- 技術亮點:單一 700KB HTML 檔案完成,耗時約 40 分鐘運算,無偷懶、無佔位符,展現目標導向的自主執行能力。
- GPT-BDI 1 語音模型:
- 知識截止日期更新至 2025 年 8 月。
- 即時雙向互動:支援自然打斷,模型能即時調整回應。
- 演示:即時聆聽並計算冗長故事中的食物數量,準確捕捉細節。
- 影響:推動本地代理作業系統從終端機打字轉向持續即時的語音對話。
四、 總結與未來趨勢
- 競爭核心轉移:從「寫出最好的提示詞」轉向「系統架構設計」。
- 關鍵能力:
- 決定任務分配給哪個模型。
- 管理代幣經濟(Token Economy)與成本。
- 選擇合適的模型組合(如便宜快速的 Chinchilla 52 用於簡單介面,複雜的 Fugu 協調器用於多步驟推理)。
- 防止自主代理在無監督下導致成本失控。
工具 / 模型 / 名詞整理
- 公司/組織:
- Sakana AI(日本新創公司)
- Anthropic
- OpenAI
- Apple Podcast
- FBIGThreads(社群平台)
- 模型/產品:
- Fugu Ultra:Sakana AI 推出的多代理協調系統。
- Fable 5:Anthropic 被限制的模型架構。
- Mythos / Mythos 6:Anthropic 內部訓練的新一代模型架構。
- Claude Sonnet 5:Anthropic 洩漏的中階主力模型。
- Opus 48:Anthropic 的高階架構規劃模型。
- GPT-55:Sakana 系統中調用的模型之一。
- GPT-46:OpenAI 新模型的洩漏名稱之一。
- GPT-56 Pro:OpenAI 新模型的洩漏名稱之二。
- Kindle Alpha:OpenAI 新模型的內部代號。
- GPT-BDI 1:OpenAI 推出的語音模型。
- GPT-4 Omni:提及的舊版語音助理模型。
- GLM 52:用於生成便宜前端介面的模型。
- Chinchilla 52:用於簡單介面的便宜快速模型。
- Gemini 31 Pro:Sakana 系統中調用的模型之一。
- 測試/基準:
- SWE Bench Pro:軟體工程任務黃金標準測試。
- LiveCodeBench:程式碼測試基準。
- Stockfish:國際象棋引擎(提及 2100 ELO 等級)。
- 其他專有名詞:
- Attention Is All You Need:傳奇論文。
- React 元件:前端開發框架元件。
- SVG 圖檔:向量圖形格式。
- Nintendo Switch 2:遊戲主機。
- Crossy Road:遊戲名稱。
- GDPR:歐盟數據保護法規。
- IDE:整合開發環境。
- Tokenizer:分詞器。
- Context Window:脈絡長度。
- Zero-shot success:一次成功率。
操作流程整理
Sakana Fugu 系統運作流程:
- 使用者透過單一 API 呼叫提交任務。
- 內部「AI 經理人」接收任務,並拆解為子任務。
- 經理人根據子任務性質,分派給預先串接的頂尖模型(如 GPT-55、Opus 48、Gemini 31 Pro)。
- 模型分工扮演不同角色:思想家(Thinker)、製造者(Maker)、驗證者(Verifier)。
- 經理人透過試錯學習如何與其他 AI 溝通,保留有效方法,淘汰無效方法。
Claude Sonnet 5 新分詞器應用流程:
- 使用新分詞器處理輸入,可能增加 Token 消耗(高達 30%)。
- 換取更高的推理能力與多模態理解。
- 提高一次成功率(Zero-shot success),減少高成本的修改迴圈。
- 演示:僅憑單一提示詞生成高度詳細的 Nintendo Switch 2 SVG 圖檔。
OpenAI 新模型 3D 生成流程:
- 輸入生成指令。
- 模型自主生成完整可遊玩的第一人稱 3D 室內房屋。
- 輸出單一 700KB HTML 檔案,包含連貫平面圖、詳細房間、流暢移動系統。
- 耗時約 40 分鐘運算,無偷懶、無佔位符。
GPT-BDI 1 語音互動流程:
- 知識截止日期更新至 2025 年 8 月。
- 進行即時雙向互動,支援自然打斷。
- 模型能即時調整回應。
- 演示:即時聆聽並計算冗長故事中的食物數量,準確捕捉細節。
值得注意的限制或風險
Sakana Fugu 的成本與效率問題:
- 在實際軟體工程任務中,時間與成本效率遠低於直接使用單一頂尖模型(如 Opus 48)。
- 協調負擔大:Fugu 完成任務時間多 4.5 倍,成本高 5 倍。
- 案例:即時交易臺開發,Fugu 耗費 22,000 Token($0.51),Opus 48 耗費 16,000 Token($0.31)。
- 案例:複製遊戲 Crossy Road,Opus 48 耗費 $37,Fugu 耗費 $7.32 但成品有操作反向、攝影機問題及缺音效。
Claude Sonnet 5 的 Token 消耗:
- 新分詞器可能比舊模型多消耗高達 30% 的 Token。
Mythos 6 的可用性:
- 目前僅限內部使用,用於生成合成資料或加速訓練,尚未公開。
OpenAI 新模型的技術挑戰:
- 生成完整 3D 環境需耗時約 40 分鐘運算,且為單一 700KB HTML 檔案,技術實現難度極高。
自主代理的成本失控風險:
- 若無監督,自主代理可能導致成本失控,需管理代幣經濟(Token Economy)與成本。
逐字稿辨識疑點
- Fugu Ultra 官方宣稱超越的模型:逐字稿提及超越 "Fable 5" 和 "Mythos",後續又提到超越 "Opus 48"。需查證 "Fable 5" 是否為 Anthropic 模型名稱之聽寫錯誤(通常為 Claude 系列),或是否為 Sakana 內部特定模型名稱。
- Opus 48:逐字稿多次提及 "Opus 48" 與 "Claude Opus 48"。需查證 Anthropic 是否已發布此版本號,或是否為聽寫錯誤(常見為 Opus 1 或特定內部版本)。
- GPT-55:逐字稿提及 "GPT-55Opus 48" 及單獨的 "GPT-55"。需查證 OpenAI 是否發布此版本,或是否為 "GPT-4o" 或 "GPT-5" 的聽寫錯誤。
- Gemini 31 Pro:逐字稿提及 "Gemini 31 Pro"。需查證 Google 是否發布此版本,或是否為 "Gemini 1.5 Pro" 或 "Gemini Ultra" 的聽寫錯誤。
- GLM 52:逐字稿提及 "GLM 52"。需查證是否為特定模型名稱,或是否為聽寫錯誤。
- Chinchilla 52:逐字稿提及 "Chinchilla 52"。需查證是否為特定模型名稱,或是否為聽寫錯誤(Chinchilla 通常指代論文或特定參數量模型)。
- GPT-46 / GPT-56 Pro:逐字稿提及 "GPT-46" 與 "GPT-56 Pro"。需查證 OpenAI 是否發布此版本號,或是否為 "GPT-4" 系列或 "GPT-5" 系列的聽寫錯誤。
- GPT-BDI 1:逐字稿提及此語音模型名稱。需查證 OpenAI 是否發布此名稱,或是否為 "GPT-4o" 語音功能的特定代號或聽寫錯誤。
- Sakana AI 共同創辦人 Llion Jones:逐字稿稱其為 "Attention Is All You Need" 作者之一。需查證 Llion Jones 是否確實為該論文作者(該論文主要作者為 Ashish Vaswani 等,需確認 Llion Jones 的具體貢獻或是否為聽寫錯誤)。
- Fugu Ultra 的 "Fugu":逐字稿中系統名稱為 "Fugu Ultra",但後文有時僅稱 "Fugu" 或 "Sakana Fugu"。需確認正式產品名稱是否包含 "Ultra"。
- 基準測試分數:SWE Bench Pro 737 分、LiveCodeBench 932 分等具體數值,需查證是否為官方發布數據或影片中的口誤。
- 成本數據:Fugu 開發交易臺成本 $0.51、Opus 48 成本 $0.31;Crossy Road 遊戲 Opus 48 成本 $37、Fugu 成本 $7.32 等具體金額,需查證是否為影片中的
逐字稿時間軸
右側可一路往下捲;左側影片框會固定。點擊時間戳會讓左側影片跳到對應秒數。
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懶人報就報到這我是湯懶懶 我們明天見掰啦