vLLM(一個廣受歡迎的開源 AI 推理引擎,是許多企業和研究機構用來部署 AI 模型的底層工具)推出了「Micro-Agent」功能,這是一種在伺服器端路由層(就是幫你分配請求的中介系統)加入多模型協作機制的技術。使用者只需呼叫一個統一的模型名稱,背後的系統會自動決定要不要把問題分給多個 AI 模型同時處理、交叉驗證、或逐步升級到更強的模型。整套機制提供五種協作策略,包括「先用便宜模型、不夠準才換更強的」、「多個模型同時答題再投票取優」、「讓不同模型相互辯駁來逼出最佳答案」等。根據官方測試數據,這套方法在多個頂級 AI 能力評估題組(benchmark,就是衡量 AI 各項能力的標準測驗)上的成績達到或超越了目前最強的商業 AI 模型,且完全不需要重新訓練模型或修改模型本身的權重(就是模型大腦裡存的知識)。
假設你在開發一個程式碼生成助手,需要解決困難的演算法競賽題。傳統做法是呼叫一個最強的 LLM(就是 ChatGPT、Claude 這類大型語言模型),但單次回答有一定機率出錯,無法自我修正。改用 vLLM Micro-Agent 的 ReMoM 模式(一種「多模型重複推理再合成」的策略),系統會同時讓多個 AI 模型各自獨立作答,等到有足夠數量的模型給出相同或相似答案後,再由另一個模型整合出最終解答。在 LiveCodeBench(一個測試 AI 寫程式能力的公開競賽題庫)上,這套方法得到 92.6 分,比目前單一最強商業模型 Fugu Ultra 的 92.0 分還高;在 GPQA-Diamond(測試研究生等級科學推理的超難題組)也拿到 96.0 分,同樣超越對手。差異在於:以前你得自己寫大量程式碼來實作多模型投票邏輯,現在只要把 API 端點換成 `vllm-sr/auto` 就能啟用整套機制,對外看起來和呼叫一個普通模型完全一樣,大幅降低了使用多模型協作的門檻。
Qwen 3.6 27B 是阿里巴巴開源的大型語言模型(就是像 ChatGPT 一樣能對話、能寫程式的 AI),這篇文章作者實測後認為它是目前「本地運行」(不需要連網、在自己電腦上跑 AI)的最佳選擇。所謂本地運行,就是把 AI 程式下載到自己電腦,所有資料完全不離開本機,不需透過任何雲端服務。作者在配備 128GB 記憶體的 MacBook Max M5 上測試,27B 版本以每秒 32 tokens(可理解為每秒輸出約 32 個字元)的速度回應,需佔用約 42GB RAM(電腦記憶體)。在基準測試(衡量 AI 能力的標準化考試)中拿到 37 分,相當於 2025 年中期頂尖 AI 的水準,是作者認為首個真正實用的本地通用智能模型。
我想要保護公司機密程式碼不上傳任何雲端,但又需要 AI 輔助開發。使用傳統雲端 API(如 ChatGPT、Claude)每次請求都會把程式碼送到對方伺服器,有資料外洩疑慮。改用 Qwen 3.6 27B 在本機運行:安裝 llama.cpp(一套在本地電腦執行 AI 模型的工具)後,下載 27B 8-bit 量化版本(約 27GB,量化是把模型壓縮以節省空間的技術),加上 `-ngl 999 -fa on` 等參數啟動,就能在自己的 MacBook 上以每秒 32 個 token 的速度獲得 AI 回覆,全程不需連網。作者測試中要求 AI 生成一個六邊形踩地雷遊戲,模型一次就給出可執行的完整程式碼;而較舊的開源模型(如 Gemma 4 31B)在相同任務表現明顯遜色,基準分數只有 29 分,差距明顯。核心優勢:程式碼與資料完全留在本機,且模型下載後不受服務商隨時下架或漲價影響,可長期穩定使用。
中國新創公司無界動力推出了一款名為 MWA™ 的「隱空間世界模型」(世界模型是一種 AI,能理解並預測物理世界中發生的事情,讓機器人更好地判斷「做了這個動作之後會發生什麼」)。這個模型的特別之處在於,它在「隱空間」(把畫面資訊壓縮成抽象數字特徵的空間,省去大量冗餘計算)而非原始畫面像素中進行推演,大幅提升效率。更核心的突破是「雙向物理因果鏈」:傳統 AI 只會「往前預測」(做了這個動作之後環境會怎樣變化),MWA™ 同時具備「往後推因」的能力(發生了這個結果、是什麼原因造成的),並讓兩者互相驗證,使機器人的因果推理更準確可靠。這個模型還不需要人工逐一標記動作訓練資料,可直接利用網路上大量無標籤影片學習物理規律,大幅降低訓練門檻。在知名具身 AI 基準測試(機器人操作任務排行榜)RoboCasa GR1 TableTop 中,MWA™ 以 75.2% 的平均任務成功率奪得全球第一,超越了英偉達(Nvidia)的 GR00T-N1.6 等主流模型,相比第二名領先 2.4 個百分點。
假設一臺機器人手臂要在嘈雜的工廠環境中完成精密插接任務——例如把 USB 接頭精準插進主機板的連接埠。這種任務不僅需要毫米級精準度,還會受到感測器雜訊幹擾。以往的做法是:工程師要為每一個子動作(伸手、對準、插入)分別標記大量訓練資料,且機器人只能一步一步推理、稍有偏差就容易失敗。使用 MWA™ 的方式,AI 預先從網路影片中自動學會「插接類物件的物理規律」,執行時能一次性規劃出完整的多步動作序列,再透過「逆向動力學」(從結果反推哪裡出錯)在雜訊環境下快速校正偏差。官方實驗數據顯示,在相同雜訊條件下,精密插接任務的成功率最高提升了 5 倍。目前無界動力已簽署近 1 億美元的全球訂單,其中包含遠景科技逾 5 億元人民幣的海外大單,是中國具身操作領域首個億元級海外訂單。
美國軍方首次大規模使用 AI(人工智慧,就是能自動分析大量資料、協助做決定的電腦程式)來挑選打擊目標。他們把 Anthropic(一家 AI 公司)開發的 Claude 模型(可以理解指令、分析資料的語言 AI)嵌入到 Palantir 公司的 Maven 智能系統中,第一天就建議了約 1,000 個攻擊目標。然而,2026 年 2 月底,美軍根據 AI 系統的建議,對伊朗米納布市一棟建築發射導彈,造成約 120 名兒童死亡,因為那棟建築早在多年前就已改建為小學。事後調查揭露,早在 2019 年,情報分析師就已發現並記錄這棟建築變成學校的資訊,但這份記錄放在一個「情報資料庫」裡,而這個資料庫從來沒有和軍方用來選目標的「官方目標資料庫」相連接,導致 AI 在推薦目標時完全看不到這條關鍵備註。
想像一個具體的過程:伊朗某棟建築在舊軍事資料庫中被標記為「軍事設施」。2019 年,一名情報分析師實地確認後,在另一個獨立的情報系統中寫下備註:「此地點已改為小學」。但這兩個系統之間沒有橋接,就像兩本互不相通的筆記本。2026 年,AI 系統讀取官方目標資料庫,看到「軍事設施」這個舊標籤,再加上七年前拍的衛星照片(當時建築外觀尚未完全改變),於是把這棟建築列入推薦打擊清單。人類指揮官看了 AI 推薦清單後批准,導彈發射,120 名孩子罹難。事後調查建議:未來應自動交叉比對 Google Maps 等公開地圖服務,一旦官方記錄與公開資訊出現落差,就立即標記出來讓人工審查,而非全部交給 AI 直接進入打擊清單。
Elon Musk 宣佈旗下 AI 公司 xAI 開發的新語言模型 Grok 4.5,已進入私人測試階段(private beta,就是邀請特定人員試用、尚未對外公開的封閉測試期),目前在 SpaceX(Musk 的太空公司)和 Tesla(電動車公司)內部率先試用。Grok 4.5 建立在一個規模達 1.5 兆參數(參數可以理解成模型「知識量」的衡量單位,數字越大通常代表模型越強)的第九代基礎模型上,並在訓練過程中額外加入了來自 Cursor(一款 AI 程式碼編輯器)的資料,讓模型在程式相關任務上有更好的表現。早期評測結果顯示,Grok 4.5 的能力已接近甚至超越 Claude Opus(Anthropic 公司目前最頂尖的旗艦 AI 模型),對整個 AI 市場競爭格局有重要意義。此外,模型目前仍透過強化學習(一種讓 AI 透過「做對得獎、做錯受罰」的機制持續自我改進的訓練方式)繼續提升,意味著正式發布前性能還有望進一步提高。
假設我是一名軟體工程師,平常使用 Claude Opus 幫我審查程式碼、找出邏輯漏洞,每個月為此支付高額 API 費用(API 就是讓開發者把 AI 功能接進自己軟體的介面)。若 Grok 4.5 正式上線後公開提供 API,且價格更具競爭力,我就能拿相同的程式碼審查任務分別測試兩個模型——以「找出 10 個函式中的邊界條件錯誤」為具體目標,比較準確率與成本。以往市場上能達到 Opus 等級的選擇極少,Grok 4.5 若真的達標,等於讓頂尖 AI 模型的選擇從幾乎唯一,變成有真正競爭的市場,開發者議價空間大幅提升。
Open Memory Protocol(OMP,開放記憶協定)是一個開源標準,目標是讓不同的 AI 助理工具(如 Claude、ChatGPT、Cursor 等程式編輯器的 AI 功能)能夠共用同一份關於你的記憶。目前的問題是:每個 AI 工具各自記憶用戶的偏好與對話內容,彼此完全隔離——你在 Claude 告訴它你喜歡簡潔的回答,換到 ChatGPT 就要重新說一遍。OMP 透過一個可以自己架設的記憶伺服器(Memory Server,就像一個專屬的個人資料庫)加上統一的 API(應用程式介面,讓不同軟體互相溝通的橋樑),讓所有支援 OMP 的 AI 工具都能讀取和寫入同一份記憶。專案目前已有 TypeScript 和 Python 的 SDK(軟體開發工具包,幫助工程師快速接入的程式庫),以及支援 Claude 的 MCP(模型情境協定,讓 AI 連接外部工具的標準)插件,版本為 v0.2 的規格草案。
假設我是一名工程師,慣用 TypeScript、討厭過多的程式碼註解,過去在 ChatGPT 花了幾週讓它瞭解我的風格。現在我想換到 Claude 處理一個新專案。以往的做法是在 Claude 重新自我介紹一遍偏好,浪費時間。使用 OMP 後:我先用一行指令 `npx omp-server` 在本機啟動記憶伺服器,再把 OMP 的 MCP 插件設定到 Claude Desktop,同時安裝 OMP Bridge 瀏覽器擴充套件。之後每次我在 ChatGPT 的對話內容都會每 2 分鐘自動同步到 OMP 伺服器。當我打開 Claude 開始新對話,瀏覽器擴充套件會彈出提示「要繼續你在 ChatGPT 的討論嗎?」,點下去 Claude 就會收到一份自動摘要的交接說明,立刻知道我的偏好和上下文。相較於舊做法每換一個工具就要重頭解釋,OMP 讓記憶跟著人走而不是鎖在工具裡。
htmx(一個流行的網頁前端開源工具)的作者 Carson Gross,寫了一篇親身實戰文章,分享他如何與 AI(具體來說是 Claude,就是 Anthropic 公司推出的對話式 AI 助理)合作,一起診斷並修復自己開源專案中的程式漏洞(bug)。他不是叫 AI「幫我修好」就收工,而是自己先理解問題架構、再用 AI 輔助產出解法、最後主動評估哪個方案最符合原本的程式碼風格。文章的結論是:真正有效的人機協作,關鍵在於「人要懂系統,AI 來加速」,而不是把思考全部外包給 AI。他也特別提到,AI 自動生成的測試案例(用來驗證程式是否正常運作的自動化測試腳本)品質意外地高,覆蓋了很多開發者自己可能沒想到的邊界情境。
Carson 的開源語言工具 hyperscript 出現一個 bug:使用者在升級版本後,原本寫的 `fetch 'url' as JSON`(意思是「去抓網路資料,並把結果當 JSON 格式來解析」)突然壞掉了。他先自己追蹤問題,找出是重構時誤把 `as` 這個關鍵字的語法判斷範圍放大了,導致程式把它誤判成「型別轉換運算式」而不是「命令修飾語」。確認根因後,他把問題和程式碼架構一起丟給 Claude 討論,AI 提出了三個修法方向:第一個方案修得太窄、不夠通用;第二個引入了不必要的複雜邏輯;他最終引導 AI 利用程式中已有的 `follows`(讓語法規則有先後順序依賴)機制,做出最乾淨的第三個方案。整個流程和「靠自己查 Stack Overflow 再手刻修復」相比,速度快很多,且測試覆蓋更全面——但前提是他自己必須先看懂問題,而不是直接把 AI 的第一個答案無腦貼上。
MIT Technology Review 報導一項重要研究:當企業把 AI 代理(agent,就是能自動執行任務流程的 AI 程式,例如幫你起草文件、回覆郵件的自動化助手)取人名、稱為「數位同事」或「數位員工」時,反而會讓旁邊的真人員工表現變差。波士頓大學商學院教授 Emma Wiles 的研究發現,當 AI 工具被標示為「員工」而非「聊天機器人」時,員工偵測 AI 犯錯的能力下降了 18%;同時,員工更傾向於把 AI 的可疑輸出直接往上呈報給主管,而不是自己仔細審查(上呈比例上升 44%)。這意味著人類對 AI 的監督與把關能力明顯降低,出了事責任也更難追究。研究調查了 1,261 位經理,發現近三分之一的公司已把 AI 代理定位成員工角色。麻省理工學院經濟學家、2024 年諾貝爾獎得主 Daron Acemoglu 也強調:AI 代理應優化為「強化人類判斷力」的工具,而非讓人誤以為可以完全信賴的同事。
假設你在法務部門,每天要審查 AI 幫你起草的合約。若公司把 AI 命名為「Alex」並宣傳它是你的「數位同事」,根據這項研究,你對 Alex 所犯錯誤的警覺度會下降,更可能直接把有疑問的地方向主管反映,而不是自己花時間逐字核查。但如果公司只說「這是一個 AI 起草輔助工具」,你反而會保持更高的批判性、更認真地逐項核對條文。結果是:同樣的 AI、同樣的合約,僅因為叫法不同,真人員工的審查品質就差了近兩成,出錯的合約也更容易被放行。這個發現直接提醒開發 AI 系統的工程師和企業主管:如何「介紹 AI 身份」本身就是影響工作品質的關鍵決策,而不只是無足輕重的行銷文案。
MIT 科技評論針對 300 位技術專家進行調查,評估企業在部署 AI 代理人(AI agent,就是能自主規劃並執行多步驟任務的 AI 系統,不需要人工一步步下指令)時的信心程度,調查範圍涵蓋 101 項實際工作任務。報告指出,2026 年被 Gartner(全球知名科技研究機構)定義為企業 AI 的「轉折年」,越來越多企業主管希望 AI 代理人能帶來可量化的財務成效,因此對「哪些任務適合交給 AI 自動處理」的判斷格外重要。調查發現,對於結構明確、有清楚衡量標準的任務——例如自動生成報告、監控資料品質、偵測異常——技術領導者的信心最高;一旦任務需要大量跨系統推理、或企業內部資料整合不完整,信心就明顯下降。報告也強調,「人工監督」是成功部署的關鍵,AI agent 必須在企業既有的資安與身份驗證框架內運作,才能讓相關團隊放心使用。
假設我是一家電商公司的資料工程師,每天需要監控數百萬筆訂單資料,確保資料完整性沒有異常(例如重複筆數、欄位遺漏、某時段訂單數驟降可能代表系統故障)。舊做法是工程師每天手動跑查詢腳本,發現問題才通報,反應時間慢且容易遺漏。導入 AI agent 之後,系統自動即時監控資料流、偵測異常、並自動生成摘要報告推送給主管,不需要人工盯盤。根據本次調查,這類「資料品質監控與異常偵測」任務在 101 項任務中信心排名最高,因為有明確的量化標準(異常比率、誤報率)可以驗證 AI 效果是否達標。相比之下,若要讓 AI agent 做跨部門業務決策,因為缺乏完整的企業情境資料,目前大多數企業的部署信心仍偏低。
Base44 是一個「Vibe Coding」平臺(就是讓你用白話文描述想要什麼 APP,AI 自動幫你把程式碼寫出來,完全不用自己動手寫程式的工具),屬於 Wix(以色列大型網站建立公司)旗下,目前年收入已達一億美元。他們最近推出了自家研發的 AI 模型 Base1,這個模型用平臺上數千萬筆真實用戶互動記錄來訓練,讓 AI「專門學會」Base44 使用者怎麼描述需求、怎麼建構 APP。自己養模型的用意,是要降低呼叫 OpenAI、Anthropic 等第三方 AI 的成本與延遲(延遲就是 AI 回應所需的時間),同時讓輸出結果更符合平臺用戶的習慣。更長遠的目標是讓 Base1 最終在速度和費用上超越 Claude Opus(Anthropic 目前旗艦等級的 AI 模型)。這也反映了一波 AI 新創趨勢:與其完全依賴大廠的 API(應用程式介面,就是向外部服務「借用」AI 能力的管道),不如垂直整合自建模型,打造別人難以複製的競爭壁壘。
假設一位創業者想做一個線上預約管理系統,他在 Base44 上用中文打出「我需要一個可以讓客戶自己選時間預約的網頁,後臺能看到所有預約紀錄」。過去,Base44 的後臺會把這段描述送到 Anthropic 或 OpenAI 的 API,由那些通用型大模型來生成程式碼——每次請求都要花費 API 費用,而且那些模型是為了「做所有事情」而訓練的,未必最擅長 Base44 的 APP 建構場景。換成 Base1 之後,模型是用幾千萬筆「Base44 用戶實際怎麼提需求、怎麼迭代修改 APP」的對話訓練出來的,對這類任務有更精準的預測,不只生成速度更快,生成的程式碼結構也更貼近平臺用戶的習慣,出錯率更低。對使用者而言,直接感受是「產出更順、卡頓變少」;對 Base44 而言,每次生成的運算成本大幅降低,不用再按量付錢給大廠。
Google 旗下的 AI 聊天工具 Gemini(就是 Google 版本的 ChatGPT,可以對話、生圖、幫你處理各種任務)原本有一項「個人化 AI 圖像生成」功能,需要付費訂閱 Plus、Pro 或 Ultra 方案才能使用。從 2026 年 6 月 29 日起,這項功能正式開放給美國所有符合條件的免費用戶。這個功能的核心是「個人智慧」(Personal Intelligence)技術——它會連結你的 Gmail、Google Photos(Google 相簿)、YouTube 和 Google 搜尋等帳戶資料,讓 Gemini 自動理解你的喜好與興趣,進而生成「專屬於你個人」的圖像。與一般 AI 生圖工具相比,你不需要在指令裡詳細描述自己的偏好,Gemini 會從你的帳戶資料自行推斷。這項功能採「選擇加入」(opt-in)制度,用戶可以自行決定要讓 Gemini 讀取哪些 Google 應用的資料,也可以隨時關閉。
我想生成一張「我與我的興趣愛好」主題插圖,但懶得自己列出所有喜好。以前沒有個人化功能時,我必須在提示詞(prompt,就是給 AI 的文字指令)裡一一描述:「畫一個喜歡登山、聽爵士樂、養貓的人」。現在,我在 Gemini 設定裡開啟個人智慧、授權它讀取 Google Photos 相簿和 YouTube 觀看記錄,只需輸入「為我和我最愛的東西製作插圖」,Gemini 就會自動從相簿和 YouTube 訂閱記錄推斷我的興趣,生成一張對我個人而言有意義的圖像——不需要手動描述,而且結果更貼近「我自己」。如果之後不想讓 Gemini 繼續讀取這些資料,可以隨時在工具選單切換按鈕關閉。
Anthropic(開發 Claude 這款 AI 對話助理的美國公司)與加州州長 Newsom 達成合作協議,讓加州所有州政府機構及地方政府可以用半價使用 Claude。加州的公務員可以透過 Claude 來起草文件、分析資料,提升行政效率。這項合作的背景很有趣:聯邦政府(美國國防部)拒絕了 Anthropic 提出的安全條款(要求 AI 不能在沒有人類監督的情況下用於監控或自主武器),並改為選擇競爭對手 OpenAI(開發 ChatGPT 的公司),甚至將 Anthropic 列為「供應鏈風險」。然而加州不理會聯邦的顧慮,獨立與 Anthropic 簽約,展現出州政府與聯邦政府在 AI 採購上的明顯分歧。
假設加州衛生局的公務員需要起草一份關於空氣品質法規修訂的政策文件。以前,他們得從零開始寫草稿,查閱大量法規文件、整理數據並撰寫摘要,可能耗費數天工時。現在透過這項協議,公務員可以直接用 Claude(一種 AI 文字助理,功能類似 ChatGPT,但由 Anthropic 開發)輸入需求與相關資料,讓 AI 快速產出草稿、摘要關鍵條文、比對前後版本差異,公務員只需審閱、修改即可。相較於完全手動撰寫,整個流程可大幅縮短時間,且透過政府採購協議以半價取得,比一般企業使用 Claude 便宜許多。
Arena 是一個由加州大學柏克萊分校研究人員創辦的 AI 模型評估平臺(就是讓使用者比較不同 AI 的好壞、幫它們打分排名的工具),以「Chatbot Arena」排行榜廣為人知。它的做法是讓使用者輸入問題,同時丟給兩個不同的 AI 模型,再讓使用者選出哪個答得比較好,累積超過 1,000 萬次這類評測後,形成一張公開的 AI 模型排名榜,幾乎所有主流 AI 公司都非常在意自家模型在這份榜單上的名次。Arena 於 2025 年 9 月推出付費商業服務「AI Evaluations」,專門幫 AI 模型開發商和企業做深度性能分析;短短 8 個月,年化收益(把目前月收入換算成一年總金額的估算方式)就從 3,000 萬美元成長至 1 億美元,目前融資總額達 2.5 億美元。平臺近期也新增了 Agent Mode(讓 AI 自動執行多步驟複雜任務的模式)評估能力,評測範圍從文字、程式碼進一步擴展到更複雜的 AI 工作流程。
假設你是一家公司的 AI 負責人,想決定要把公司的客服機器人換成哪個 AI 模型——是 GPT-4o、Claude Sonnet,還是 Gemini Pro?以往你可能要自己設計一批測試題、叫工程師一個個跑測試、再花時間整理比較結果,既費時又耗人力。現在你可以直接查 Arena 的 Chatbot Arena 公開榜單,幾秒內就看到這三個模型在「客服問答」類別的勝率排名。若需要更深入的客製分析——例如模型處理繁體中文客訴的表現,或在 Agent Mode 下自動填表的準確率——則可付費訂閱 Arena 的商業評估服務,取得針對你使用情境量身製作的報告,省去從頭自建評測流程的工程成本。
TIDAL(一個主打高音質的音樂串流平臺,類似 Spotify 或 Apple Music)宣佈從 2026 年 7 月 15 日起,全面禁止 AI(人工智慧)生成的音樂賺取版稅或銷售收入。凡是 100% 由 AI 自動生成、沒有任何人工創作參與的歌曲,都無法在平臺上獲得金錢回報,同時會被貼上「AI」標籤讓聽眾一眼識別。若 AI 音樂還試圖模仿真實歌手的聲音或風格,TIDAL 更會用自動化工具直接將其下架,完全不給上架機會。這項措施背後有一個驚人數字作為背景:另一家歐洲音樂平臺 Deezer 曾統計,每天新上傳到平臺的音樂中,高達 44% 是 AI 生成的,這已嚴重稀釋真人音樂創作者的曝光機會與版稅收益。Spotify、Apple Music、Qobuz 等競爭對手也已陸續制定類似的 AI 音樂管理規範,整個串流音樂產業正在集體對純 AI 生成內容亮紅燈。
假設你是一位使用 Suno 或 Udio(這類 AI 作曲工具,只需輸入文字描述,就能自動生成一整首有歌詞、有旋律的歌)的創作者,你產出 100 首背景音樂並上傳到 TIDAL,原本期待靠串流點播累積版稅收入。7 月 15 日之後,這 100 首歌不僅一毛版稅都賺不到,每首旁邊還會掛著「AI」標籤,讓聽眾知道這不是真人創作。若其中幾首聽起來像某位真實歌手(例如模仿 Taylor Swift 的唱腔或 Drake 的說唱節奏),更會被平臺的自動偵測工具找出來直接刪除。反過來說,若你是真人音樂製作人,製作過程中用了 AI 輔助混音、自動補音或生成伴奏,只要最終作品不是「100% 純 AI 生成」,就不在限制範圍內,仍可正常上架並領版稅——政策精準針對的是完全無人參與的 AI 作品。
Proception 是一家美國機器人新創公司,專攻讓機器手做到像人手一樣靈活的問題——這被公認為機器人領域最難解的工程挑戰之一。他們的特別之處在於訓練資料(就是用來讓 AI 學習的範例資料)的收集方式:讓真人戴上佈滿感測器的手套,同時搭配 VR(虛擬實境,就是戴上頭盔看到虛擬畫面)頭盔執行各種手部動作,藉此記錄下手指每一個細微的觸覺與力道資訊。這些資料會用來訓練控制機器手的 AI 模型(就是讓機器手「學會」怎麼握東西的程式)。傳統做法是讓人遙控真實機器手來收集資料,但遙控器無法傳遞觸覺回饋;Proception 的手套方案不需要機器人在現場,資料品質更豐富也更容易擴大規模。公司由前特斯拉 Optimus(人形機器人)技術負責人創立,剛完成 1,100 萬美元種子輪融資,投資方包含 Y Combinator(知名新創加速器,孵化過 Airbnb、Stripe 等公司)及 First Round Capital。
假設要訓練一隻機器手「撿起一顆雞蛋但不捏破它」——這需要機器手精確感知施加的力道,傳統做法是讓工程師遙控機器手操作幾千次,但遙控器無法傳遞真實觸感,工程師根本感覺不到「再用力一點點就會碎」的那個臨界點,導致收集到的資料品質不足。Proception 的做法是:讓真人戴上感測手套直接去撿雞蛋幾千次,手套會記錄下每根手指每個時刻的壓力、彎曲角度和觸覺細節,這些完整的人類手部資料再用來訓練 AI 模型。好處有三:不需要架設機器人設備就能大量收集資料、資料裡有完整的觸覺資訊(傳統方法缺這塊)、擴展成本低(多找幾個人戴手套即可)。這就好比「讓人先示範給 AI 看,而且是帶著感官資訊的完整示範」,比過去只能看動作、感受不到力道的方法進步很多。
Amazon(亞馬遜)的工程師正在將 Anthropic 開發的 Claude AI 模型「蒸餾」成更小、更便宜的版本,供公司內部使用。模型蒸餾(Model Distillation)是一種 AI 技術——簡單說就是讓小模型去學習大模型的行為,讓小模型能以更低的算力跑出與大模型相近的效果。Amazon 之所以這麼做,是因為明年起與 Anthropic 的計費方式將從「按算力小時計費」改為「按處理的 Token 數量計費」(Token 是 AI 處理文字時的基本單位,大約 4 個英文字母算 1 個 Token)。新計費制度可能讓費用大幅增加,因此 Amazon 決定提前透過蒸餾技術把大型模型「壓縮」成小版本,降低未來的支出。報導也指出,Amazon 同時在評估改用 OpenAI 等其他 AI 供應商的可行性。
假設 Amazon 內部有數千個工程團隊,每天都在呼叫 Anthropic 的 Claude 模型處理程式碼審查或文件摘要等例行任務。在「按算力小時計費」的舊方案下,費用相對固定可預測。但一旦換成「按 Token 數量計費」,每次 AI 處理文字都額外付錢,規模一大費用可能暴增。Amazon 工程師的應對方式是:先讓大型 Claude 模型處理大量問題並記錄答案,再用這些問答資料訓練出一個小型「仿製模型」,讓小模型模仿大模型的回答風格與品質。日後內部例行任務就改跑這個成本更低的小模型,只有真正需要最高品質時才呼叫原版 Claude——如此一來,對外付費的 Token 用量大幅下降,整體開銷就能有效控制。
Meta(臉書母公司)正式限制旗下工程師使用 Anthropic 的 Claude Code(一種 AI 寫程式助手)以及 OpenAI 的 Codex(同類型工具),原因是擔心這些競爭對手 AI 的輸出內容會混入 Meta 自己的 AI 訓練資料。這種現象在業界稱為「蒸餾」(distillation,意思是一個 AI 偷偷學習另一個 AI 的答案,等同間接盜用對方的能力)。Meta 的新政策規定,工程師不得用這些外部 AI 工具來生成測試任務或進行程式碼分析,所有涉及這類工具的工作都必須由人工審查。目前 Meta 正在開發自家的程式碼助手 MetaCode,希望逐步取代對外部工具的依賴;該公司預計今年內部 AI 的使用費用將高達數十億美元。
假設 Meta 的工程師在開發某個功能時,把程式碼丟給 Claude Code 請它補全或解釋,再把 Claude 的回應直接存進程式碼庫或測試集。如果這份程式碼日後被用來訓練 Meta 自家的 AI 模型(如 Llama 系列),等於讓 Meta 的 AI 學到了 Claude 的「思路」——這就是蒸餾。Meta 擔心這樣做不但可能違反 Anthropic 的使用條款,更重要的是讓自家模型的能力建立在競爭對手的基礎上,削弱自身的獨立性。對比舊做法:以前工程師可以自由選用任何 AI 工具輔助工作,但現在只要輸出內容有可能進入訓練流程,就必須嚴格管控來源。Anthropic 也曾公開指控阿里巴巴以類似手法大規模蒸餾 Claude 的能力,顯示這個問題在整個 AI 產業都愈來愈受重視。
德勤(Deloitte,全球最大的諮詢公司之一)在一場內部員工大會上展示了一份預測圖表,指出傳統的「按小時計費」諮詢服務到 2035 年將萎縮成極小比例,被 AI agents(就是能自動執行各種專業工作的人工智慧程式)大規模取代。有德勤顧問直接說:「我們的模式已經完蛋了,基本上我們被機器人取代了。」麥肯錫(McKinsey)和波士頓顧問公司(BCG)等頂尖諮詢巨頭,都在緊急尋找替代收益模式,從按小時收費轉向按成果付費或固定價格。這場轉型被業界 AI 顧問平臺 Catalant 執行長形容為「生存層面的競爭」,而非只是策略調整。
假設你是一家企業想聘請諮詢公司做市場分析報告,過去的做法是聘用一組顧問、每小時幾百美元、花三個月整理資料與訪談,最後付出幾十萬美元。現在 AI agents 可以在幾小時內自動蒐集市場資料、分析競爭對手、產出結構化報告,成本可能只是傳統方式的幾分之一。這使得「靠人力小時數賺錢」的模式難以競爭,因此麥肯錫已將超過 30% 的業務轉為「按績效付費」——達到客戶設定的目標才收費,而不是靠顧問坐著計時。但新模式也有風險:若專案超期或成效難以量化,諮詢公司要自行承擔虧損、現金流不穩,客戶關係也可能因此緊張。
Lean 是一種專為「形式驗證」(就是讓電腦用數學方式確認程式碼百分之百正確、不含 bug)設計的程式語言。根據 Gwern 的分析,AI 模型(像 ChatGPT 或 GitHub Copilot 這類能自動寫程式的 AI)在不同程式語言上的能力提升,符合「擴展法則」(scaling law,意思是 AI 模型愈大、訓練資料愈多,能力就成比例提升)。研究發現,Lean 語言目前對 AI 來說比 Python、JavaScript 等主流語言更難掌握,初始表現較差,但它的「擴展斜率」(就是隨著 AI 規模擴大,能力進步的速度)比其他語言更好。這表示長期來看,AI 在 Lean 上的能力提升幅度將超越其他語言,可能讓 Lean 成為程式正確性的未來贏家,值得企業考慮大規模將現有程式庫改寫成 Lean。
假設一家金融公司有大量負責計算利率與風險的核心程式碼,目前以 Python 撰寫。現有 AI 工具(如 GitHub Copilot)幫忙修 Python bug 時偶爾會出錯,因為 Python 語法靈活、邏輯錯誤不容易自動偵測。若將這些程式碼改寫成 Lean——Lean 的設計要求每一行程式碼都要通過數學驗證才能成功編譯——並搭配未來能力更強的 AI(依擴展法則,AI 在 Lean 上的能力會加速提升),AI 就能自動找出並修正所有邏輯錯誤,且保證修正後的程式在數學上絕對正確。對比現在 Python + AI 偶爾仍會漏掉 bug,Lean + 未來 AI 的組合更適合「不能出一個 bug」的金融系統或航太軟體等高可靠性場景。
這篇文章是知名 AI 訪談者 Dwarkesh Patel 的深度分析,探討 AI 發展的「下一個範式」(也就是主流的技術路線會怎麼改變)。目前大多數 AI 實驗室正在押注一種叫做 RLVR(強化學習配合可驗證的獎勵,就是讓 AI 反覆嘗試、做對就給分的訓練方法)的技術路線,希望把它擴展到數百萬種任務,藉此達到人工通用智慧(AGI,就是能處理幾乎所有人類工作的 AI)。但作者指出,這個路線有一道難以跨越的牆:很多重要的現實任務——比如打贏官司、創業、做投資交易——根本無法在電腦裡建立一個能反覆練習的模擬環境,AI 就無法透過「不斷試錯、得分」來進步。真正的突破在於「持續學習」——讓 AI 在實際部署、與使用者協作的過程中,把新學到的東西持續更新進模型的「權重」(就是 AI 的長期記憶庫),而不只靠每次對話開始時臨時塞進去的短暫上下文記憶。
假設你是一位律師,每天用 AI 幫你草擬訴狀、分析判例。現在的 AI 每次對話開始都是一張白紙——上週跟你討論過的案件細節、你偏好的論述風格、你常引用的判例,下次開啟新對話就全忘了,你每次都要重新說明背景。Dwarkesh 提出的「持續學習」願景是:AI 整週陪你處理工作,持續累積對你工作方式的理解,到週末再把這週學到的東西正式更新進模型;下週一的 AI 就真的記得你上週所有討論、偏好與案件知識,不需要重新介紹。對比現在:你每次開新對話都得重貼上下文,AI 才能接上上次的進度;持續學習後的 AI 就像一位真正跟你磨合了幾個月的助理,越用越聰明、越用越瞭解你。
這篇文章將棒球統計分析的「魔球」(Moneyball,一種用數據而非直覺做資源分配決策的方法)概念,應用到實體AI(Physical AI,指控制機器人手臂、自動駕駛車等在現實世界行動的AI系統)的訓練資料管理上。核心問題在於:訓練這類AI需要大量真實的機器人操作資料,成本極高——有學者估計要達到頂尖水準,可能需要約十萬年的機器人累積運作時間。業界慣用「累計運作時數」來衡量資料量,但這個指標沒有反映資料的「新穎性」(novelty,就是這筆資料有沒有帶來模型從未見過的新情境)。作者 Animesh Garg 主張:真正重要的不是資料多,而是資料「值錢」——稀有罕見的例外情境比重複的日常操作更有訓練價值;資本配置應根據資料類型和新穎程度精確定價,才能讓訓練預算花在刀口上。
假設一家機器人公司在工廠部署了一批機械手臂,每天累積數千小時的操作日誌。照舊有做法,工程師會把所有資料拿來訓練下一代模型,認為「資料越多越好」。但根據文章引用的縮放法則(Scaling Law,描述資料量與模型效能之間關係的數學規律)研究,重複超過約 4 個訓練週期後同樣資料反而讓效能下降;機械手臂重複抓同一款螺絲釘幾百次的錄影,幾乎沒有額外幫助。相反地,某次機械手臂遇到從未見過的包裝形式、失敗並重新嘗試的那幾分鐘紀錄,訓練價值遠超幾百小時例行操作。按本文提出的「資料新穎性定價」框架,工程師應先用嵌入空間(embedding space,將資料轉成數字向量後的空間,距離越遠代表情境越不同)分析哪些片段覆蓋了新場景,優先納入這些片段並捨棄大量重複日常資料——同樣預算下能讓模型學到更多真正有用的技能。
Meta(臉書母公司)發表了一篇研究論文,指出現在 AI 訓練中一個常被忽略的隱患——「獎勵模型(reward model,就是在訓練過程中替 AI 回答打分數、引導 AI 學習方向的評判機制)」太過敏感,容易對品質差不多的回答給出差異懸殊的分數。當前許多大型語言模型(LLM,就是 ChatGPT、Claude 這類對話型 AI)都透過強化學習(Reinforcement Learning,一種讓 AI 靠不斷嘗試、根據分數反饋持續改進的訓練方式)來提升表現,而獎勵模型就是那個「裁判」。問題在於,若裁判打分不穩定,AI 就會學到「鑽空子」的技巧——表面上分數很高,但實際回答品質根本沒有進步,這個現象稱為「獎勵黑客(reward hacking)」。Meta 提出兩個評估指標(辨別能力與精確度),並引入「蒙地卡羅丟棄法(Monte Carlo dropout,一種量化 AI 不確定性的技術)」,將原本連續的分數歸類成更穩健的離散區間,讓訓練訊號更可靠、AI 學習方向更正確。
假設有人在訓練一個中文客服 AI,用獎勵模型來評估每條回應好不好。有兩句回答:「您好,請問有什麼可以幫您?」和「您好!請問需要什麼協助?」——意思幾乎完全相同,但過敏感的獎勵模型可能給前者 8.7 分、後者只有 5.2 分,分差根本不反映真實品質差異。AI 接到這個訊號,會拼命模仿前者的用詞,學到「講某些特定措辭分數高」,而不是真正學會如何解決客戶問題,最終訓練出來的模型雖然「看起來」分數漂亮,實際上卻沒有變好。套用 Meta 的方法後,這兩句回答會被歸入同一個「足夠好」的離散區間,AI 不再因細微措辭差異而偏移學習方向,最終訓練出的模型才真正更擅長處理客服情境。
這篇文章提出了一種全新的理論框架,用來設計和理解 AI Agent(AI 代理人,也就是能自主執行任務的 AI 程式)。傳統做法通常把「信念」(AI 知道什麼)、「目標」(AI 要做什麼)、「行動」(AI 實際執行的步驟)分開設計,像三個獨立模組各自運作。這個新框架主張:這三者其實應該來自同一個底層結構——一張由無數「信念節點」互相連結組成的網路(也就是「信念網路」)。AI 在面對問題時,不是查詢獨立的目標模組,而是透過在這張網路上維持「局部一致性」(讓互相矛盾的信念不能同時成立)來自然生出推理和行動。作者認為,這種設計更接近人類思考的運作方式,也可能讓 AI Agent 變得更有能力、更靈活。這個框架目前仍屬理論階段,尚未有大規模實作驗證,但在 AI 研究社群引發討論。
假設我要做一個能幫我安排會議的 AI 助理。用傳統模組化設計,系統會分別維護一個目標清單(「排定下午的會議」)、一個事實資料庫(「用戶三點有空」)、以及一個行動規劃器(「把會議加入行事曆」)——這三個部分要用程式碼明確地串接起來,一旦邏輯複雜(比如同時有多個衝突的目標)就很容易出錯。改用信念網路框架,「我需要排會議」、「三點有空」、「會議需要一小時」、「四點有另一個衝突」這些全都是同一張網路裡的「信念節點」,彼此有連線代表依賴或矛盾關係。當 AI 發現「四點有衝突」這個信念節點存在時,系統自動在網路上傳遞矛盾訊號,重新評估其他信念並推導出新的行動——比如改約三點半。不需要工程師手動設計每一條「若 A 則 B」的規則,推理和決策從信念的一致性中自然浮現。差異在於:舊方法靠工程師預先寫死邏輯,新框架讓 AI 靠信念間的相互關係自行推理,理論上更能應對沒預料到的狀況。
Google 推出的 Antigravity(一個讓 AI 幫你自動執行各種開發任務的智慧代理程式系統)現在可以透過一個叫做 GitLab Orbit 的插件,直接讀取並查詢 GitLab 上的所有開發資訊。GitLab 是工程師常用的程式碼託管平臺(類似 GitHub,用來存放程式碼、追蹤開發進度、管理整個軟體開發流程)。這個整合是透過 MCP(Model Context Protocol,一種讓 AI 代理程式能和外部工具溝通的標準協議)來實現的,開發者只需從 Antigravity MCP Store(類似 AI 代理程式的「插件商店」)安裝 GitLab Orbit,AI 就能自動讀取 GitLab 上的專案、流水線(自動化測試和部署流程)、合併請求(開發者提交修改的申請)、資安漏洞,以及原始碼等完整資訊。換句話說,AI 現在可以像真正的團隊成員一樣,直接在 GitLab 的工作環境裡瀏覽與回答問題,不再需要人類從 GitLab 複製資料貼給它看。
假設我是一個工程師,想請 AI 幫我檢查「我們 GitLab 上最近三個合併請求有沒有資安漏洞,哪個最嚴重?」。以前,我需要自己進 GitLab 找到每個合併請求的詳細內容和掃描報告,複製後貼給 AI,AI 才能分析。現在,使用 Google Antigravity 並安裝 GitLab Orbit 插件後,AI 代理程式可以直接透過 MCP 工具主動查詢 GitLab,自動拉取合併請求資料和資安掃描結果,直接輸出分析——例如「第 2 個合併請求有 SQL 注入(一種可讓駭客竊取資料庫資料的攻擊手法)漏洞,風險等級高」——全程不需要工程師手動搬運資料,省去大量來回切換工具的時間。
Okta(一家專門管理「誰可以登入什麼系統」的企業身份驗證公司)推出了針對 AI 代理(就是能自動執行任務的 AI 程式,例如自動審核申請、查詢資料、處理流程的機器人)的身份管理產品,名為「Okta for AI Agents Core」,現在正式開放給需要符合政府安全規範(FedRAMP,美國聯邦政府的雲端安全認證標準)和醫療隱私法(HIPAA,美國保護病患個資的法規)的企業使用。這個產品讓企業可以把 AI 代理當作正式的「身份帳號」來管理,就像管理員工帳號一樣,可以指定負責人、設定它只能存取哪些資料。過去 AI 代理常常用寫死的固定密碼來連接系統,既不安全也難以稽核追蹤;現在改為短期、限制範圍的臨時憑證(用完即丟的一次性通行證),大幅降低資安風險。對於醫院、政府機關這類對資安和隱私有嚴格要求的組織而言,這代表他們終於有了合規的方式在內部部署 AI 代理,不用再擔心違反法規。
假設一家醫院想用 AI 代理自動審核病患保險申請,這個代理需要存取病患資料庫和保險公司的 API(應用程式介面,讓兩個系統可以互相溝通的橋梁)。過去的做法是把密碼直接寫在程式碼裡,一旦密碼外洩或程式被入侵,攻擊者就能存取所有病患資料,且完全不符合 HIPAA 規定。使用 Okta for AI Agents,IT 部門可以在 Okta 系統中把這個 AI 代理登記為一個正式帳號,指定某位資安主管為負責人,設定它只能讀取保險相關欄位、不能碰其他病歷內容,每次執行任務只拿到一個幾分鐘後就自動失效的臨時憑證。萬一出現異常存取,稽核紀錄清楚指向這個代理帳號,負責主管立刻能追蹤——整套流程與管理員工帳號完全一致,讓合規審查員用同一套工具就能驗證 AI 代理的行為紀錄,大幅簡化法規遵循的工作量。
Workday(一家專門為企業提供人力資源與財務管理雲端軟體的公司)提出了一個關於企業 AI 部署的核心主張:AI 的「防護欄」(guardrails,即限制 AI 行為、防止錯誤或越權操作的機制)必須直接內建在推論引擎(inference engine,就是 AI 實際執行運算、產出回答的那一層核心)裡,而不是在外面貼一層事後審核。這個主張特別針對人資(HR)、薪資計算(payroll)和財務(finance)等高敏感度工作流程——在這些場景裡,「大致正確」的答案是完全無法接受的,因為哪怕一筆薪資計算出錯,就可能直接衝擊員工的生計或公司的法律責任。Workday 認為,要讓 AI 代理(AI agent,能自動規劃並執行一系列任務的 AI 程式,例如自動審核假單或處理費用報銷)真正被企業信任、接手高風險業務流程,平臺本身就必須在 AI 運作的核心層內建四項機制:政策執行(policy enforcement,讓 AI 在推論當下就遵守公司規定)、權限管理(permissions,限制 AI 只能存取被授權的資料)、操作審計(auditability,完整記錄 AI 做了什麼、依據什麼規則)、以及特定業務領域的專屬控管。換句話說,不是在 AI 外面貼一層安全貼紙,而是把安全機制編織進 AI 運作的最底層。
假設一家跨國公司正在用 AI 代理自動處理員工薪資調整——員工在系統提交加薪申請,AI 根據公司薪酬政策計算核准金額,並直接觸發薪資系統更新。若防護機制只放在外部(例如一個獨立的事後審核模組),問題是:AI 在推論過程中已根據某種理解產出建議,外部攔截只能說「這個結果不行」,卻無法知道 AI 在推論時走了哪條路、為何那樣判斷,更無法在事後向監管機關解釋。Workday 主張的做法是:在 AI 推論的當下同步套用規則,例如「此職級的薪資調整上限是 15%」「超過 10% 必須主管二次確認」,並且每一個判斷步驟都留下可查詢的完整紀錄——誰送出請求、AI 套用了哪條政策、最終輸出是什麼、有沒有被人工覆蓋。這樣一來,一旦有薪資糾紛或主管機關稽查,企業可以逐步重建 AI 的完整決策路徑,而不是面對一個解釋不清的黑盒子。
Noz 是一個內建在 SigNoz 監控平臺(一套讓工程師追蹤應用程式運作狀況的軟體)裡的 AI 助手(agent,就是能自動執行任務的 AI 程式)。工程師平常需要手動設定警報規則、建立數據儀錶板(就是把各種數字整合成一個視覺化畫面,方便一眼看出服務是否正常),現在只需要用自然語言說出需求,Noz 就會自動把這些設定完成。它能讀懂你自己系統的日誌(系統運作記錄)、效能數據,以及 SigNoz 的使用文件,回答關於服務狀態的問題,並且直接在介面上幫你完成操作。目前 Noz 處於測試版,免費提供 SigNoz 用戶使用,不需額外設定,登入即可使用。
假設我是一名後端工程師,負責監控公司的結帳服務。以前當我想在「結帳 API 回應超慢」時收到通知,我需要手動進入 SigNoz 的警報設定頁面,選擇指標(metrics,就是你想追蹤的數字,例如 p99 延遲——意思是 99% 的請求都在這個時間內完成)、設定臨界值、填寫通知對象等一連串步驟,可能要花 10 到 15 分鐘。現在有了 Noz,我只要在側邊欄輸入「當結帳服務的 p99 延遲超過 2 秒時發出告警」,Noz 就會自動建構好完整的警報規則。同樣地,如果我想了解「今天早上哪段時間結帳服務錯誤率最高?」,直接問 Noz 就能得到答案,不用自己進查詢介面逐一翻找。對比舊做法,工程師從「手動操作」轉為「口頭描述」,重複性的設定工作大幅縮短。
這篇文章討論一個看似弔詭的現象:冰島擁有大量便宜的再生能源(地熱和水力發電)、天然涼爽氣候可省下大筆散熱費用,理論上是建造 AI 資料中心(就是讓 AI 運算的大型機房)的夢幻地點,但歐洲幾乎沒有在那裡大規模建設。文章指出,問題不在技術或地質,而在歐洲自身——包括電力線路審批要花好幾年、地方居民的「不要蓋在我家附近」心態,以及政策資金流向法國等大國而非最有效率的地點。歐盟雖然推出科技主權計畫,目標在五到七年內將 AI 算力(AI 運算能力)擴充三倍,但實際執行仍被繁雜的行政程序所阻礙。這篇文章揭示了歐洲在推動 AI 基礎設施建設時面臨的深層結構性困境,規則文件堆積,實際工作卻外包給他人。
假設一家歐洲 AI 新創公司需要大規模訓練語言模型(就是像 ChatGPT 那樣的 AI),需要租用大量 GPU(專門用來跑 AI 計算的圖形處理器)算力。理論上冰島是最佳選擇:電力 100% 來自再生能源、氣候涼爽不需額外空調、業者宣稱 12 個月內即可完工客製化機房。目前 Verne、Nscale 等業者已在當地部署約 4,600 枚 Nvidia Blackwell Ultra GPU,另有 Giga-42 計畫打造 50 百萬瓦的地熱設施。然而若這家新創想大規模擴建,立刻面臨電力線路審批拖延數年、地方居民強烈反對等問題;最終大多數企業只能選擇法國、德國等國的傳統資料中心——電費更貴、碳排放更高,但行政障礙相對少。SoftBank 就把 75 億歐元投入了法國,而非條件更好的冰島。
這是一篇技術教學文章,帶著讀者從頭到尾追蹤「當你執行 AI 運算程式時,GPU(顯示卡)內部到底發生了什麼事」。CUDA 是 NVIDIA(輝達)顯示卡提供的程式設計介面,幾乎所有 AI 模型的訓練與推論(讓模型實際回答問題的過程)都靠它來驅動 GPU 的算力。文章從撰寫好的程式碼如何被「翻譯」(編譯)成 GPU 能懂的指令開始講起,接著說明 CPU(電腦的主處理器)如何透過層層機制通知 GPU 開始工作,最後解釋 GPU 內部上千個小核心如何分工合作、在等待資料的空檔偷偷切換任務來讓效率最大化。平時開發者直接呼叫 PyTorch(AI 開發常用的程式庫)就能跑模型,但底下其實是一層層複雜機制在支撐,這篇文章把它攤開來一步步解說。
假設你正在用 PyTorch 訓練一個影像辨識模型,每次呼叫 model.forward(x) 感覺瞬間就在 GPU 上跑完了。但這篇文章告訴你背後發生的事:CUDA 編譯器先把你的程式碼轉成 PTX(GPU 的「通用中間語言」),再翻譯成你的 RTX 4090 看得懂的 SASS 機器碼;接著 CPU 要透過 ioctl 系統呼叫(CPU 與驅動程式之間的溝通管道,一次啟動就會呼叫將近 900 次)把工作排入 GPU 的任務佇列;GPU 收到後把工作切成 4096 個執行塊,分配給 128 個流多處理器同步執行;每個「執行緒束」(warp,32 個 GPU 執行緒為一組)遇到等待記憶體的空檔,排程器會立刻切換到另一個 warp 繼續計算,不讓 GPU 閒置。瞭解這些底層機制後,若訓練速度比預期慢,你才有辦法判斷瓶頸是在記憶體頻寬不足、kernel 啟動次數過多、還是 warp 分歧(同一組執行緒跑不同路徑導致效率下降)等問題,進而對症下藥。
Google 正在測試一個名為「Collections(集合)」的新功能,要加進他們的 AI 筆記工具 NotebookLM(一個能讓你上傳文件、然後跟 AI 對話、自動整理重點的筆記平臺)。目前 NotebookLM 最多可以建立 100 本筆記本,但所有筆記本是一條長長的清單排在一起,找起來很不方便。Collections 功能的目標就是讓你能把多本筆記本歸在同一個「資料夾標題」底下,例如把「專案 A 的文獻」、「專案 A 的會議記錄」都丟進一個叫「專案 A」的集合裡。這個功能目前仍在早期測試階段,Google 尚未正式公告,也沒有給出具體上線時間,但 Google 內部團隊已承認「跨筆記本分組」是目前被用戶反映最久的缺失功能之一。
假設你是一名研究生,同時在追蹤五個不同研究方向,每個方向都有十幾本 NotebookLM 筆記本(分別存放論文、訪談逐字稿、實驗數據)。現在這五十幾本全部擠在同一條清單,每次要找特定筆記本都要滑老半天。有了 Collections,你可以建立「氣候變遷組」、「AI 倫理組」、「田野調查組」三個集合,把各自的筆記本都歸進去,主介面只顯示三個集合標題,點進去才看到細項——就像電腦桌面從一堆散落的文件變成有整理好的資料夾一樣。對比現況:沒有此功能時,只能靠筆記本命名前綴(如「A-001」「A-002」)土法煉鋼做區分,換到 Collections 後可以真正做到視覺分群與快速切換。
這篇文章探討「資料品質」的本質,指出資料品質並非資料本身固有的屬性,而是根據使用情境才能被定義——你拿這份資料做什麼,決定了它的品質高低。資料品質越高,代表這份資料在特定用途上能帶來更好的結果、創造更高價值。文章提出資料品質有多個排序層次,若從錯誤的層次去評估,結論可能完全不同。此外,光靠標準化定義衡量品質是不夠的,什麼叫做「正確」,往往得看業務脈絡才能真正判斷。
假設我要訓練一個 AI 模型(就是讓電腦從大量範例中自動學習規律的系統)來預測客戶是否會購買某產品。我的資料庫裡有每位客戶的「年齡」欄位,乍看之下格式正確、沒有空白,品質似乎沒問題。但若這個年齡欄位是客戶「建立帳號當時」填的,已經五年未更新,那它在「預測今日購買行為」這個用途上就是低品質資料——不是格式問題,而是業務脈絡決定了它不夠用。若只用舊方法檢查「有無空值、格式正確否」,這份資料會被當作高品質放進模型,最終導致預測結果偏差。這正是文章核心觀點:品質標準必須對應使用情境,不能只看表面格式合不合規。