- Composer 1.5 幾乎完全靠大量 RL 訓練,Cursor 團隊自評能力介於 Sonnet 4.5 與 Opus 4.5 之間
- 有些能力(grep、semantic search)只能透過 RL 內建進模型,光靠外部 prompt 做不到
- RL 訓練需要同時跑數百萬個 sandbox,這種規模的基礎設施買不到,只能自建
目錄
Cursor 團隊在一場訪談中談了他們幾天前釋出的 Composer 1.5 模型。這篇整理聚焦在其中最有工程參考價值的幾個決策:為什麼要自己訓練模型、RL 能帶來哪些外部工具做不到的能力,以及支撐 RL 訓練的基礎設施到底有多重。內容嚴格依據訪談本身,不做外部腦補。
Composer 1.5:介於 Sonnet 4.5 與 Opus 4.5 之間
Cursor 團隊對 Composer 1.5 的定位很直白:他們認為這是目前能用到的最好的模型之一,能力大約落在 Sonnet 4.5 與 Opus 4.5 之間。他們也誠實地說「還不是 Opus」——做出好模型本來就很難——但對接下來能持續做出更好的模型很有信心。
這個模型 幾乎完全是透過大量、大量的 RL(reinforcement learning)訓練 出來的。
比模型分數更值得注意的,是他們對「模型該有什麼手感」的看法。他們追求的不是那種「按下 enter 之後你就可以去睡覺」的模型,而是希望模型又快、用起來又很投入(engaging):你輸入 query,模型就用它能做到的最快速度把事情做完。速度在這裡不是事後優化,而是產品體驗的一部分。
為什麼要自己訓練模型,而不是搭上前沿模型的浪潮
問到「自研模型 vs. 直接用前沿模型」的取捨,Cursor 團隊的核心論點是:當產品和模型越來越深度整合時,你在乎的功能必須直接做進模型本身。
原因是——有些能力如果沒有被訓練進模型裡,模型就是用不好那個東西。你沒辦法只靠外面包一層 prompt 把它補回來。
RL 才能學會的能力:從 grep 到 semantic search
團隊舉了兩個具體例子來說明「必須做進模型」是什麼意思。
grep:以前有些模型連 grep 都用不好。要讓模型變得非常擅長 grep,做法就是用 RL 去針對這件事做訓練。
semantic search:Composer 系列模型的一個經典特點,是非常擅長用 semantic search。面對一個非常大的 code base,這些模型能在 一到三次查詢 內就找到該去的地方,而不是動用幾十次 grep。
他們認為這類能力只能透過 RL 學會。往前看,他們特別想讓模型擅長的一件事,是大量遞迴的 sub agent——目標是在幾乎所有 query 上,都能在兩到三分鐘內把問題解掉。而要做到這種程度,基本上就必須訓練自己的模型。
撐起 RL 的基礎設施:數百萬個 sandbox
被問到 RL 的技術細節時,團隊表示演算法層面不方便多談,但基礎設施(跑程式碼與環境)這塊反而更有意思。
RL 是一項新技術,正因為新,隨著你把規模拉大,基礎設施會變得相當複雜。實際做 RL 時,你是在同時跑數百萬個 sandbox。
這裡有個關鍵的產業觀察:做到某個規模之後,你根本沒辦法向任何人「買」這套基礎設施。過去十年建立的軟體公司,多半是這樣運作的——遇到很難的事,就外包給供應商,AWS 幫你打點底層,你在上面專心寫好軟體,關注點漂亮地分離。
但當你一年要吃掉 上億等級的 CPU compute,這種分工就行不通了。你必須自己想清楚:要怎麼把同時運行的數十萬、甚至數百萬個 sandbox 編排起來,餵給 RL 訓練。這已經不是「租雲端」能解決的問題,而是必須自建的系統。
模型路由:讓使用者不必去想要用哪個模型
既然同時存在前沿模型、Composer 1.5 等多個選項,使用者該怎麼選?團隊的其中一個目標,是讓使用者根本不必去想模型這件事:
你面前只有一個輸入框,按下 enter,剩下的不用管。
背後的邏輯是依難度自動路由:
- 偏簡單的 query → 走非常快的模型
- 真的很困難的 query → 走很聰明的模型
graph LR
A[使用者在輸入框按 enter] --> B{query 難度判斷}
B -->|偏簡單| C[快速模型<br/>低延遲]
B -->|很困難| D[聰明模型<br/>高能力]
C --> E[回傳結果]
D --> E
這樣一來,簡單的問題得到極快的回應,困難的問題交給最強的模型處理,而使用者完全不必為了選模型而分心。
小結
這場訪談沒有談營收數字,也沒有談編輯器架構,而是聚焦在一件事:Cursor 為什麼要走上自研模型這條路。可以歸納成三點:
- 能力要內建:grep、semantic search 這類能力得靠 RL 訓練進模型,不是外部 prompt 能補的。
- RL 是自建工程:數百萬 sandbox、上億等級 CPU compute 的規模,讓「外包給供應商」的舊模式失效。
- 速度即產品:模型要快、要讓人願意一直用,並用路由讓使用者不必操心選哪個模型。
參考資料
AI 只根據這篇文章內容回答。點下方任一問題,或直接開右下對話框。
相關標籤
相關文章
RAG 五階段:從流水線到會思考的檢索,以及我站上那個 Naive RAG
RAG 這兩年從『線性流水線』演化到『循環推理』,可以用五階段梳理:Naive、Advanced、Modular、Graph、Agentic。分水嶺是控制權從管線移交給 Agent,範式從 System 1 進到 System 2。回頭看 engineer-news 這個站的實作,其實還卡在 Naive RAG 邊界——這篇順便把它的下一步應該補什麼寫清楚。
想蓋一個能用的 RAG:InfiniFlow 2024 年度總結給我的 5 個 infra 功課
上一篇拉高看 RAG 五階段全景,這篇拉近看實際想蓋一個 RAG 要面對的 5 個 infra 功課:文件入口解析、Chunking 上下文化、三路混合搜尋、Tensor Reranker、GraphRAG 語意鴻溝。每個功課都對照 engineer-news 現況,收尾給出對個人站的優先順序清單。
Harness Engineering(二):OpenAI 百萬行實驗與五個工程答案
OpenAI 三名工程師用 Codex 五個月產出百萬行程式碼、零手寫——這場實驗真正的價值不在數字,而在它證明了『Harness 設計』是可以工程化的。拆解五個具體實踐:讓 App 對 Agent 可見、倉庫即事實來源、架構約束機械化、合併哲學重寫、後台熵管理。