最近一段時(shí)間，AI 編程工具 Cursor 火遍全球，風(fēng)頭一時(shí)無(wú)兩。

Cursor 是一款基于 VS Code 的代碼編輯器，它為 AI 輔助編程添加了許多強(qiáng)大的功能，吸引了編程界和人工智能界的關(guān)注和興奮。

近日，知名播客節(jié)目主持人 Lex Fridman 與四位 Cursor 團(tuán)隊(duì)成員進(jìn)行了一場(chǎng)技術(shù)對(duì)談，揭示了這個(gè)團(tuán)隊(duì)在做的以及未來(lái)要做的探索。

視頻地址：https://youtu.be/oFfVt3S51T4?si=pCvBgWm5X-W8xt4n

以下是 Lex Fridman 與 Cursor 團(tuán)隊(duì)創(chuàng)始成員 Michael Truell、Sualeh Asif、Arvid Lunnemark 和 Aman Sanger 的對(duì)話，機(jī)器之心進(jìn)行了核心內(nèi)容的整理：

Cursor 的起源

Cursor 的起源故事是什么呢？

2020 年左右，OpenAI 發(fā)布了有關(guān)縮放損失的論文。那一刻，該領(lǐng)域似乎取得了明顯可預(yù)測(cè)的進(jìn)展，即使我們沒(méi)有更多的想法，但看起來(lái)如果你有更多的計(jì)算和更多的數(shù)據(jù)，你就可以讓這些模型變得更好。

順便說(shuō)一句，我們可能會(huì)就縮放損失這個(gè)話題討論三到四個(gè)小時(shí)。但總結(jié)一下，這是一系列論文中的一篇，這些論文提出了一系列觀點(diǎn)，認(rèn)為在機(jī)器學(xué)習(xí)領(lǐng)域，模型大小和數(shù)據(jù)大小越大越好。

它更大更好，但可以預(yù)見(jiàn)的是它會(huì)更好。這是另一個(gè)話題。

好的，這是另一個(gè)話題。

是的。那段時(shí)間，我們中的一些人進(jìn)行了很多概念性討論：它會(huì)是什么樣子？對(duì)于所有這些不同的知識(shí)工作者領(lǐng)域來(lái)說(shuō)，這項(xiàng)技術(shù)的發(fā)展將如何讓他們變得更好？有那么幾個(gè)時(shí)刻，那篇論文中預(yù)測(cè)的理論收益開(kāi)始變得非常具體，我們開(kāi)始覺(jué)得，如果你想在人工智能領(lǐng)域做有用的工作，你實(shí)際上可以直接去，而不必攻讀博士學(xué)位。感覺(jué)現(xiàn)在有一整套可以構(gòu)建的真正有用的系統(tǒng)。

下一個(gè)讓一切都變得順理成章的重要時(shí)刻實(shí)際上是提前獲得 GPT-IV 的使用權(quán)。所以，大約在 2022 年底，我們開(kāi)始修改這個(gè)模型，升級(jí)能力令人感覺(jué)非常強(qiáng)大。在此之前，我們一直在從事幾個(gè)不同的項(xiàng)目。由于 Copilot、由于 scaling odds、由于我們之前對(duì)這項(xiàng)技術(shù)的興趣，我們一直在修改程序員工具，但這些工具非常具體。因此，我們正在為必須在 Jupyter Notebook 中工作的金融專業(yè)人士構(gòu)建工具，或者嘗試使用這些模型進(jìn)行靜態(tài)分析。

然后 GPT-IV 的升級(jí)讓我們感覺(jué)，看，這確實(shí)使之前預(yù)測(cè)的理論收益具體化。感覺(jué)你可以在那個(gè)時(shí)間點(diǎn)立即構(gòu)建更多東西。而且如果我們保持一致，感覺(jué)這真的不僅僅是一個(gè)點(diǎn)解決方案。所有編程都將流經(jīng)這些模型，需要不同類(lèi)型的編程環(huán)境，不同類(lèi)型的編程。所以我們開(kāi)始構(gòu)建一種更大的愿景。

代碼差異

Cursor 有一個(gè)非常酷且引人注目的功能，那就是整個(gè) diff 接口情況。因此，模型用紅色和綠色表示我們將如何修改代碼，你可以在聊天窗口中應(yīng)用它，它會(huì)向你顯示 diff，你可以接受 diff。

我們可能會(huì)有四五種不同的 diff。我們針對(duì)自動(dòng)完成功能優(yōu)化了 diff，因此它具有與檢查較大代碼塊時(shí)不同的 diff 接口。然后，我們正在嘗試優(yōu)化另一個(gè) diff 功能，以適應(yīng)處理多個(gè)不同文件的情況。從高層次來(lái)看，區(qū)別在于你使用自動(dòng)完成功能時(shí)，讀取速度應(yīng)該非常非常快。實(shí)際上，在所有情況下讀取速度都應(yīng)該非常快，但在自動(dòng)完成功能中，你的眼睛會(huì)集中在一個(gè)區(qū)域，人類(lèi)不能看太多不同的地方。

我們嘗試了三四次才讓這個(gè)東西正常工作，第一次嘗試是使用藍(lán)色劃線。在它變成側(cè)面的方框之前，它曾經(jīng)以 Google Docs 樣式顯示要?jiǎng)h除的代碼，你會(huì)看到一條劃線，然后會(huì)看到新代碼。這容易讓人分心。然后我們嘗試了許多不同的方法，有刪除，有嘗試紅色突出顯示。

然后，在下一次迭代中，這有點(diǎn)搞笑，你會(huì)按住 Mac 上的選項(xiàng)按鈕。所以它會(huì)突出顯示一段代碼，向你顯示可能會(huì)有什么東西出現(xiàn)。所以在這個(gè)例子中，輸入和值都會(huì)變成藍(lán)色。藍(lán)色是為了突出顯示人工智能為你提供了建議。所以它不是直接向你顯示東西，而是暗示人工智能有一個(gè)建議，如果你真的想看到它，你會(huì)按住選項(xiàng)按鈕，然后你就會(huì)看到新的建議。如果你釋放選項(xiàng)按鈕，你就會(huì)看到你的原始代碼。

是的，這是用戶體驗(yàn)設(shè)計(jì)工程中非常迷人的領(lǐng)域。所以你基本上是在試圖引導(dǎo)人類(lèi)程序員完成他們需要閱讀的所有內(nèi)容，僅此而已，這是最佳的。

你需要智能模型來(lái)做這件事。目前，不同的算法就像普通算法一樣。沒(méi)有智能。算法的設(shè)計(jì)需要智能，但你并不關(guān)心它是這個(gè)還是那個(gè)，因?yàn)槟阆ＭＰ蛠?lái)做這件事。

一個(gè)問(wèn)題是，這些模型會(huì)變得更加智能。隨著模型變得更加智能，它們能夠提出的改變也會(huì)更大。因此，隨著改變?cè)絹?lái)越大，人類(lèi)必須做越來(lái)越多的驗(yàn)證工作。

人類(lèi)不想把所有的時(shí)間都花在審查代碼上。我認(rèn)為可以使用語(yǔ)言模型顯著改善審查體驗(yàn)，例如，某種技巧可能會(huì)將你指向真正重要的區(qū)域。我還認(rèn)為，如果代碼是使用這些語(yǔ)言模型生成的，而不是由其他人生成的。代碼審查體驗(yàn)是為審查者和生成代碼的人設(shè)計(jì)的。如果編寫(xiě)代碼的人是語(yǔ)言模型，那么你就不必太在意他們的體驗(yàn)，你可以圍繞審閱者設(shè)計(jì)整個(gè)過(guò)程，讓審閱者的工作盡可能有趣、輕松、高效。

機(jī)器學(xué)習(xí)細(xì)節(jié)

Cursor 的編輯器讓我有點(diǎn)感受到 AGI 的存在，能不能談?wù)勛屗\(yùn)行的機(jī)器學(xué)習(xí)細(xì)節(jié)？

Cursor 實(shí)際上是基于我們訓(xùn)練的定制模型和前沿模型組成的集成模型來(lái)運(yùn)行的。一些 Cursor 廣受好評(píng)的功能，比如 Tab 和 Apply，都是微調(diào)起的效果。

這些前沿模型非常擅長(zhǎng)生成修改代碼的意見(jiàn)與草稿，但在實(shí)際生成代碼改動(dòng)的細(xì)節(jié)時(shí)，往往會(huì)遇到困難，特別是，當(dāng)用這些模型（如 Sonnet、o1）處理大型文件時(shí)，常常會(huì)出現(xiàn)搞串行這樣的低級(jí)錯(cuò)誤。

為此，我們采取了一個(gè)策略：首先讓模型生成一個(gè)粗略的代碼塊，簡(jiǎn)單描述代碼需要如何修改；然后再訓(xùn)練另一個(gè)模型，將這些代碼修改應(yīng)用到實(shí)際文件中。

補(bǔ)充一下，Apply 功能是模型會(huì)查看你的代碼并給出新建議。根據(jù)新建議對(duì)代碼進(jìn)行修改，對(duì)人類(lèi)來(lái)說(shuō)看似很簡(jiǎn)單，但對(duì)模型而言其實(shí)并不那么容易，對(duì)嗎？

可能有很多人認(rèn)為 Apply 功能背后的算法是「確定性的」，也就是說(shuō)它有一套固定的規(guī)則或流程，但實(shí)際上并不是。

是的，其他 AI 編程工具也有 Apply 功能的「平替版」，但它們往往會(huì)崩潰。很多人以為可以通過(guò)確定性的匹配來(lái)實(shí)現(xiàn)這些功能，但實(shí)際情況是，至少有 40% 都會(huì)失敗。

我認(rèn)為整體趨勢(shì)是，模型會(huì)變得越來(lái)越智能。而 Apply 的另一個(gè)優(yōu)勢(shì)在于，它可以讓最智能的模型在生成代碼時(shí)，使用較少的 tokens，從而降低延遲和成本。

具體來(lái)說(shuō)，你可以給模型一個(gè)粗略的代碼草稿，然后模型負(fù)責(zé)具體實(shí)現(xiàn)，相比于讓模型從零開(kāi)始寫(xiě)完整的代碼，給一個(gè)大致草稿讓模型去完善要簡(jiǎn)單得多。我相信這一趨勢(shì)將繼續(xù)發(fā)展，隨著負(fù)責(zé)規(guī)劃的模型越來(lái)越智能，具體實(shí)現(xiàn)的細(xì)節(jié)可能交由相對(duì)簡(jiǎn)單的模型來(lái)處理。也許會(huì)有 o1 或更強(qiáng)大的模型來(lái)生成高層次的規(guī)劃，再由定制的模型遞歸地執(zhí)行。

如果你感興趣，我們可以聊聊如何讓它更快。

那你們是如何提升 Cursor 的處理速度的呢？

讓速度變快的一個(gè)要點(diǎn)是「投機(jī)編輯」（speculative edits），它是從投機(jī)解碼（speculative decoding）衍生出來(lái)的。你可以利用投機(jī)解碼的一個(gè)優(yōu)勢(shì)：大部分情況下，尤其是在語(yǔ)言模型生成時(shí)受內(nèi)存限制的情況下，一次處理多個(gè) tokens 比逐個(gè)生成 tokens 更快。因此，當(dāng)你查看每秒生成的 tokens 數(shù)量時(shí)，會(huì)發(fā)現(xiàn)處理 prompt tokens 的速度遠(yuǎn)快于逐個(gè)生成 tokens。

我們的方法與傳統(tǒng)的投機(jī)解碼不同。傳統(tǒng)方法是用一個(gè)很小的模型預(yù)測(cè)代碼，然后由更大的模型來(lái)驗(yàn)證。但是因?yàn)槲覀儗?duì)已有代碼的樣子、格式和邏輯足夠熟悉，所以可以直接把原始代碼片段輸入到模型中，讓模型去判斷哪些部分需要改動(dòng)。絕大多數(shù)情況下，模型會(huì)認(rèn)同：「這些代碼沒(méi)問(wèn)題，可以直接復(fù)制。」

因此，你可以并行處理所有代碼行，并對(duì)足夠多的代碼片段進(jìn)行同樣操作。最終，當(dāng)模型預(yù)測(cè)的文本與原始代碼出現(xiàn)不一致時(shí)，它會(huì)生成新的 tokens，我們則根據(jù)匹配程度判斷何時(shí)重新對(duì)代碼塊進(jìn)行推測(cè)。

GPT vs Claude

哪個(gè) LLM 更擅長(zhǎng)編碼？GPT 和 Claude 在編程方面誰(shuí)更勝一籌？

大模型編程能力排行榜

我認(rèn)為沒(méi)有哪個(gè)模型可以稱霸于所有模型，這意味著在我們認(rèn)為重要的所有類(lèi)別中，Pareto 模型都表現(xiàn)更好，這些類(lèi)別包括速度、編輯代碼的能力、處理大量代碼的能力、長(zhǎng)上下文、其他一些方面以及編碼能力。我現(xiàn)在認(rèn)為最好的模型是 Sonnet。o1 非常有趣，而且推理能力很強(qiáng)。因此，如果你給它一些非常難的編程面試風(fēng)格問(wèn)題或引導(dǎo)代碼問(wèn)題，它可以做得很好，但感覺(jué)它不像 Sonnet 那樣理解你的大致意圖。

如果你看看許多其他前沿模型，它們?cè)诨鶞?zhǔn)上的表現(xiàn)都非常好，但是當(dāng)你將它們推到更遠(yuǎn)的地方時(shí)，我認(rèn)為 Sonnet 是保持相同性能的最佳選擇。

正常的編程體驗(yàn)與基準(zhǔn)測(cè)試所代表的體驗(yàn)之間有什么區(qū)別？當(dāng)我們?cè)u(píng)估這些模型時(shí)，基準(zhǔn)測(cè)試的不足之處在哪里？

這是一個(gè)非常非常困難且至關(guān)重要的細(xì)節(jié)，它說(shuō)明了基準(zhǔn)測(cè)試與真實(shí)編碼之間的區(qū)別，真實(shí)編碼不是面試風(fēng)格的編碼。人類(lèi)有時(shí)會(huì)說(shuō)半生不熟的英語(yǔ)，有時(shí)你會(huì)說(shuō)：「按照我之前做的做。」有時(shí)你會(huì)說(shuō)：「添加這個(gè)東西，然后為我做另一件事，然后制作這個(gè) UI 元素。」然后很多事情都是依賴于上下文的。抽象地說(shuō)，面試問(wèn)題非常具體。它們很大程度上依賴于規(guī)范，而人類(lèi)的東西則不那么具體。

基準(zhǔn)測(cè)試中實(shí)際可以建模的內(nèi)容與實(shí)際編程之間存在偏差，有時(shí)很難概括，因?yàn)閷?shí)際編程非常混亂，有時(shí)無(wú)法很好地指定什么是正確的，什么不正確。但是由于公共基準(zhǔn)測(cè)試的問(wèn)題，這也變得更加困難。因?yàn)楣不鶞?zhǔn)測(cè)試有時(shí)是爬坡測(cè)試，也是因?yàn)閺哪Ｐ椭蝎@取公共基準(zhǔn)測(cè)試數(shù)據(jù)非常非常困難。

例如，最受歡迎的基準(zhǔn)之一 SWE-Bench 確實(shí)受到這些基礎(chǔ)模型的訓(xùn)練數(shù)據(jù)污染。因此，如果你要求這些基礎(chǔ)模型解決 SWE-Bench 問(wèn)題，但實(shí)際上沒(méi)有為它們提供代碼庫(kù)的上下文，它們就會(huì)產(chǎn)生幻覺(jué)的文件傳遞，產(chǎn)生幻覺(jué)的函數(shù)名稱。

這種情況下，它可以針對(duì)文字問(wèn)題或拉取請(qǐng)求本身進(jìn)行訓(xùn)練，也許實(shí)驗(yàn)室會(huì)開(kāi)始做得更好，或者他們已經(jīng)在凈化這些東西方面做得很好，但他們不會(huì)忽略存儲(chǔ)庫(kù)本身的實(shí)際訓(xùn)練數(shù)據(jù)。這些都是一些最流行的 Python 存儲(chǔ)庫(kù)。SimPy 就是一個(gè)例子。我不認(rèn)為他們會(huì)在 SimPy 和所有這些流行的 Python 存儲(chǔ)庫(kù)上設(shè)置他們的模型，以便在這些基準(zhǔn)測(cè)試中獲得真實(shí)的評(píng)估分?jǐn)?shù)。

鑒于基準(zhǔn)測(cè)試中的缺陷，使用這些模型構(gòu)建系統(tǒng)或構(gòu)建這些模型的地方實(shí)際上會(huì)使用一些有趣的「拐杖」來(lái)了解它們是否朝著正確的方向發(fā)展。在很多地方，人們實(shí)際上只是讓人類(lèi)來(lái)玩這些東西并對(duì)這些提供定性反饋。一些基礎(chǔ)模型公司都有人負(fù)責(zé)這項(xiàng)工作。在內(nèi)部，我們也對(duì)這些模型進(jìn)行定性評(píng)估，實(shí)際上除了我們擁有的私人電子郵件外，我們還非常依賴這些評(píng)估。

提示工程

一個(gè)好的提示詞能起什么作用？你曾寫(xiě)過(guò)一篇關(guān)于提示詞設(shè)計(jì)的博客。

這取決于你正在用哪個(gè)模型。每個(gè)模型對(duì)不同的提示反應(yīng)也不同，比如 GPT-4 就對(duì)提示詞非常敏感，但問(wèn)題是，當(dāng)空間有限時(shí)，你如何決定哪些信息應(yīng)該被放入提示詞中呢？

針對(duì)這個(gè)問(wèn)題，我們內(nèi)部有一個(gè)系統(tǒng)叫做 Preempt。它有點(diǎn)像你在制作一個(gè)網(wǎng)站：你希望在移動(dòng)端和桌面端都能正常顯示網(wǎng)站的頁(yè)面。但你需要考慮一些動(dòng)態(tài)的信息，畢竟網(wǎng)頁(yè)設(shè)計(jì)不像雜志排版是固定的。網(wǎng)站和提示詞的輸入都是動(dòng)態(tài)的，你需要確保格式始終適用，輸入量很大時(shí)，需要剪裁一些內(nèi)容。因此，我們從設(shè)計(jì)網(wǎng)站的思路中提取了靈感。

我們非常喜歡 React 以及聲明式的方式，比如你可以在 JavaScript 中使用 JSX，然后直接聲明：「這就是我想要的，我認(rèn)為這個(gè)部分比其他部分具有更高的優(yōu)先級(jí)或更高的 Z 軸順序。」

在網(wǎng)頁(yè)設(shè)計(jì)中，渲染工作由渲染引擎來(lái)完成，而在 Cursor 中，這個(gè)任務(wù)由 Preempt 渲染器負(fù)責(zé)，它將所有內(nèi)容布局到頁(yè)面上。你只需說(shuō)明你想要的效果，渲染器會(huì)自動(dòng)幫你實(shí)現(xiàn)。

我們發(fā)現(xiàn)這種方法非常有用，而且它的角色也在不斷演變：最初它是為了適應(yīng)較小的上下文窗口，而現(xiàn)在它在拆分進(jìn)入提示詞的數(shù)據(jù)和實(shí)際生成方面發(fā)揮了很大作用。因此，調(diào)試起來(lái)更加簡(jiǎn)單，因?yàn)槟憧梢孕薷奶崾驹~，并在舊的提示詞上進(jìn)行測(cè)試，直接查看你的修改是否真的提升了整個(gè)評(píng)估集的表現(xiàn)。

所以你們真的在用 JSX 來(lái)寫(xiě)提示詞嗎？

沒(méi)錯(cuò)！Preempt 看起來(lái)就像 React。它還有一些組件，比如文件組件，它會(huì)獲取光標(biāo)的位置。在代碼編輯器中，光標(biāo)在的那行代碼可能是最重要的一行，因?yàn)槟阏诓榭此Ｄ敲淳涂梢曰诖藶椴煌拇a行設(shè)置優(yōu)先級(jí)。光標(biāo)所在的那一行優(yōu)先級(jí)最高，離它越遠(yuǎn)的行，優(yōu)先級(jí)依次遞減。最終在渲染時(shí)，系統(tǒng)會(huì)計(jì)算出能顯示多少行代碼，并以光標(biāo)所在的行為中心進(jìn)行呈現(xiàn)。

這也太棒了！

你還可以實(shí)現(xiàn)更復(fù)雜的功能，比如當(dāng)整個(gè)代碼庫(kù)中有許多代碼塊時(shí)，可以通過(guò)檢索、嵌入和根據(jù)得分重新排序等方式，為這些組件設(shè)定優(yōu)先級(jí)。

那么，人類(lèi)在提問(wèn)時(shí)，是否也應(yīng)該嘗試使用類(lèi)似的方式？在提示中寫(xiě) JSX 會(huì)有好處嗎，還是說(shuō)想到哪里就問(wèn)什么這種方式更好？

我認(rèn)為我們的目標(biāo)是，你可以隨意提問(wèn)，而我們的任務(wù)是找到合適的方式檢索出與你想法相關(guān)的信息。

我之前和 Perplexity 的 CEO Aravind Srinivas 聊過(guò)這個(gè)問(wèn)題，他的觀點(diǎn)是提問(wèn)者越懶越好。這種思路是極好的，但我覺(jué)得對(duì)于程序員來(lái)說(shuō)，你應(yīng)該可以提更高的要求，對(duì)吧？

沒(méi)錯(cuò)。如果你說(shuō)「隨便你怎么問(wèn)」，人往往是懶惰的。這就產(chǎn)生了一種張力：一方面是人們可以隨意提問(wèn)，另一方面它也在鼓勵(lì)人們?cè)谔崾驹~中傳達(dá)更有深度的想法。

我的觀點(diǎn)是，即使 AI 已經(jīng)足夠智能，但你仍無(wú)法傳遞足夠明確但意圖來(lái)指引模型該做什么。有幾種方法可以解決這種意圖不明確定問(wèn)題。一種是讓模型問(wèn)你：「基于你的查詢，我不確定如何處理這些部分，你可以明確一下嗎？」另一種方法可能是，如果有五六種可能的生成方式，「鑒于目前查詢中的不確定性，不如我們把這些生成的結(jié)果都展示給你，然后讓你來(lái)選擇。」

對(duì)于模型來(lái)說(shuō)，讓它主動(dòng)發(fā)問(wèn)有多難呢？

我們最近為 Cursor 添加了一個(gè)加入文件的功能。當(dāng)你在編輯代碼或輸入內(nèi)容時(shí)，模型會(huì)嘗試預(yù)測(cè)你正在做什么，如果模型發(fā)現(xiàn)有不確定的地方，它會(huì)猜測(cè)你可能在編寫(xiě)某種 API。然后，模型會(huì)查看你的歷史記錄，推測(cè)哪些文件與當(dāng)前的編輯內(nèi)容相關(guān)。

這里有一個(gè)技術(shù)上的難題，就是如何在所有歷史記錄中找到相關(guān)的信息，判斷在當(dāng)前的提示詞下哪些文件最重要。雖然這個(gè)功能還處于試驗(yàn)階段，但相信我們會(huì)逐步完善它，但我們想展示出這個(gè)想法：「你是否想添加這個(gè)文件、那個(gè)文件，以便模型幫你編輯？」

比如你正在編寫(xiě)一個(gè) API，同時(shí)，你也需要編輯使用這個(gè) API 的客戶端和服務(wù)器代碼，那么 API 發(fā)生變化時(shí)，客戶端和服務(wù)器代碼也需要相應(yīng)更新。

Cursor 可以做的是，當(dāng)你在編寫(xiě)提示或代碼時(shí)，在按下「回車(chē)」之前，模型可以幫你找到這些可能需要一起修改的部分。這樣做的好處是，可以提前解決一些不確定性，確保所有相關(guān)的代碼都被正確更新，而不需要手動(dòng)去查找和同步這些改動(dòng)。

上下文

關(guān)于上下文，當(dāng)我用 Python 編寫(xiě)代碼時(shí)，會(huì)導(dǎo)入一堆東西。如果想知道我想在上下文中包含哪些東西，自動(dòng)找出上下文有多難？

這很棘手。我認(rèn)為未來(lái)我們可以在自動(dòng)計(jì)算上下文方面做得更好。需要注意的一點(diǎn)是，包含自動(dòng)上下文是有代價(jià)的。

首先，為這些模型包含的上下文越多，它們的速度就越慢，請(qǐng)求的成本就越高，這意味著您可以減少模型調(diào)用，并在后臺(tái)執(zhí)行更少的花哨操作。此外，對(duì)于許多這些模型，如果提示中包含大量信息，它們會(huì)感到困惑。因此，包含的上下文的準(zhǔn)確性和相關(guān)性標(biāo)準(zhǔn)應(yīng)該相當(dāng)高。

我們已經(jīng)在產(chǎn)品的某些地方做了一些自動(dòng)上下文。這是我們希望做得更好的事情。我認(rèn)為有很多很酷的想法可以嘗試，包括學(xué)習(xí)更好的檢索系統(tǒng)，例如更好的嵌入模型、更好的重排序器。

還有一些很酷的學(xué)術(shù)理念，我們已經(jīng)在內(nèi)部嘗試過(guò)，你能否讓語(yǔ)言模型達(dá)到這樣一種境界，即模型本身就可以理解新的信息語(yǔ)料庫(kù)？最流行的版本是，你能否讓上下文窗口無(wú)限？那么，如果你讓上下文窗口無(wú)限，你能否讓模型真正關(guān)注無(wú)限上下文？然后，在你讓它關(guān)注無(wú)限上下文之后，讓它在某種程度上切實(shí)可行，你能否對(duì)無(wú)限上下文進(jìn)行緩存？你不必一直重新計(jì)算。但是，還有其他很酷的想法正在嘗試中，它們更類(lèi)似于在模型權(quán)重中實(shí)際學(xué)習(xí)這些信息的微調(diào)。如果你在權(quán)重級(jí)別上做更多的事情，而不是在上下文學(xué)習(xí)級(jí)別上做，那么你實(shí)際上可能會(huì)獲得一種定性的不同類(lèi)型的理解。

我們真的對(duì)更好的檢索系統(tǒng)和挑選與你正在做的事情最相關(guān)的代碼庫(kù)部分感到興奮。一個(gè)有趣的概念證明是使用 VS Code 直接在權(quán)重中學(xué)習(xí)這些知識(shí)。所以我們?cè)?VS Code 分支和 VS Code 中。代碼都是公開(kāi)的。因此，這些預(yù)訓(xùn)練模型已經(jīng)看到了所有代碼。他們可能還看到了有關(guān)它的問(wèn)題和答案。然后他們進(jìn)行了微調(diào)和 RLHF，以便能夠回答有關(guān)代碼的一般問(wèn)題。因此，當(dāng)你問(wèn)它關(guān)于 VS Code 的問(wèn)題時(shí)，有時(shí)它會(huì)產(chǎn)生幻覺(jué)，但有時(shí)它實(shí)際上可以很好地回答問(wèn)題。我認(rèn)為這只是…… 它碰巧沒(méi)問(wèn)題，但如果專門(mén)訓(xùn)練或后訓(xùn)練一個(gè)模型，使其真正構(gòu)建為理解這個(gè)代碼庫(kù)，會(huì)怎么樣？

這是一個(gè)開(kāi)放的研究問(wèn)題，我們對(duì)此非常感興趣。此外，還有一個(gè)不確定性，你是否希望模型成為端到端完成所有工作的東西，即在內(nèi)部進(jìn)行檢索，然后回答問(wèn)題、創(chuàng)建代碼，或者你是否想將檢索與前沿模型分開(kāi)，也許你會(huì)在幾個(gè)月內(nèi)得到一些真正強(qiáng)大的模型，這些模型比最好的開(kāi)源模型要好得多？然后，需要單獨(dú)訓(xùn)練一個(gè)非常好的開(kāi)源模型作為檢索器，作為將上下文輸入到這些更大模型的東西。

能否再多談?wù)動(dòng)?xùn)練模型后如何理解代碼庫(kù)？這是什么意思？這是一個(gè)合成數(shù)據(jù)方向嗎？

是的，有很多方法可以嘗試。當(dāng)然，想法是無(wú)窮無(wú)盡的。問(wèn)題只是去嘗試所有方法，然后根據(jù)經(jīng)驗(yàn)判斷哪種方法最有效。一個(gè)非常幼稚的想法是嘗試復(fù)制 VS Code 和這些前沿模型所做的事情。所以讓我們繼續(xù)進(jìn)行預(yù)訓(xùn)練。某種持續(xù)的預(yù)訓(xùn)練，包括一般代碼數(shù)據(jù)，但也加入了你關(guān)心的某些特定存儲(chǔ)庫(kù)的數(shù)據(jù)。然后在后訓(xùn)練中，讓我們從指令微調(diào)開(kāi)始。你有一個(gè)關(guān)于代碼的正常指令微調(diào)數(shù)據(jù)集。然后，你會(huì)在該存儲(chǔ)庫(kù)中提出很多關(guān)于代碼的問(wèn)題。

因此，你可以獲得基本事實(shí)數(shù)據(jù)，這可能很難，或者你可以使用合成數(shù)據(jù)執(zhí)行您暗示或建議的操作，即讓模型詢問(wèn)有關(guān)各個(gè)近期代碼片段的問(wèn)題。因此，你可以獲取代碼片段，然后提示模型或讓模型針對(duì)該代碼片段提出問(wèn)題，然后將其添加為指令微調(diào)數(shù)據(jù)點(diǎn)。然后從理論上講，這可能會(huì)解鎖模型回答有關(guān)該代碼庫(kù)的問(wèn)題的能力。

OpenAI o1

你們?cè)趺纯?OpenAI o1？這種能在測(cè)試時(shí)計(jì)算的系統(tǒng)將在編程中將扮演什么角色？

對(duì)于預(yù)訓(xùn)練模型模型，Scaling law 效果撥群，但我們現(xiàn)在已經(jīng)遇到了「數(shù)據(jù)壁壘」，因此，通過(guò)增加推理時(shí)使用的 flops 來(lái)提升模型性能，是一種有趣的方法。傳統(tǒng)上，我們必須訓(xùn)練更大的模型來(lái)使用更多的 flops，但現(xiàn)在我們或許可以在相同規(guī)模的模型上運(yùn)行更長(zhǎng)時(shí)間，來(lái)達(dá)到大型模型的質(zhì)量。

我覺(jué)得還有一點(diǎn)很有趣，有些問(wèn)題可能需要一個(gè)擁有 100 萬(wàn)億參數(shù)、訓(xùn)練了 100 萬(wàn)億 tokens 的超大模型才能解決，但這樣的問(wèn)題可能只占所有查詢數(shù)量的 1% 甚至 0.1%。那么，你會(huì)花費(fèi)大量的計(jì)算資源去訓(xùn)練一個(gè)如此昂貴的模型，卻只為極少的查詢提供服務(wù)嗎？這樣做感覺(jué)很浪費(fèi)。

所以更好的方法是，訓(xùn)練一個(gè)能夠處理 99.9% 查詢的模型，然后對(duì)于那些需要極高智能的問(wèn)題，在推理時(shí)運(yùn)行更長(zhǎng)時(shí)間，以獲得更好的答案。

如果你要構(gòu)建一個(gè)能和 o1 pk 的模型，你會(huì)怎么做？

待做事項(xiàng)之一肯定是要訓(xùn)練一個(gè)「過(guò)程獎(jiǎng)勵(lì)模型」（process reward model）。

或許我們可以深入討論一下「獎(jiǎng)勵(lì)模型」、「結(jié)果獎(jiǎng)勵(lì)模型」與「過(guò)程獎(jiǎng)勵(lì)模型」的區(qū)別。結(jié)果獎(jiǎng)勵(lì)模型是傳統(tǒng)用于語(yǔ)言建模的獎(jiǎng)勵(lì)模型，它只關(guān)注最終結(jié)果，比如一個(gè)數(shù)學(xué)問(wèn)題答對(duì)了，模型就能獲得對(duì)應(yīng)的獎(jiǎng)勵(lì)。

而過(guò)程獎(jiǎng)勵(lì)模型則試圖對(duì)「思維鏈」中的每一步進(jìn)行評(píng)分。OpenAI 在去年夏天發(fā)表了一篇論文，他們利用人工標(biāo)注員構(gòu)建了一個(gè)包含幾十萬(wàn)條「思維鏈」數(shù)據(jù)的大型數(shù)據(jù)集。目前來(lái)看，除了在樣本選擇中起作用外，過(guò)程獎(jiǎng)勵(lì)模型還有什么應(yīng)用，我還沒(méi)看到。

真正讓人覺(jué)得有趣、也讓大家期望能起作用的是結(jié)合過(guò)程獎(jiǎng)勵(lì)模型進(jìn)行「樹(shù)搜索」（tree search）。因?yàn)槿绻隳軐?duì)「思維鏈」的每一步都進(jìn)行評(píng)分，那么你就可以分支，并對(duì)這個(gè)思維鏈中的多條路徑進(jìn)行探索，再利用過(guò)程獎(jiǎng)勵(lì)模型來(lái)評(píng)估每個(gè)路徑。

OpenAI 曾提到他們正在隱藏模型的「思維鏈」，并表示這是一項(xiàng)艱難的決策。他們選擇讓模型總結(jié)思維鏈，而不是直接展示給用戶。同時(shí)，OpenAI 在后臺(tái)監(jiān)控這些思維鏈，以確保模型不會(huì)嘗試操控用戶，不管怎樣，你對(duì)隱藏思維鏈怎么看？

我對(duì) OpenAI 的一個(gè)猜測(cè)，純屬臆測(cè)，可能是他們不想讓人們從他們的模型中提煉出 o1 的能力。如果你能看到隱藏的思維鏈，復(fù)制這項(xiàng)技術(shù)可能會(huì)變得更容易，因?yàn)槟隳軌蚩吹侥Ｐ蜑榈玫阶罱K結(jié)果所采取的每一步，這可是非常重要的數(shù)據(jù)。

那你也可以基于這些來(lái)訓(xùn)練模型嗎？

之前也有類(lèi)似的情況，雖然這只是猜測(cè)：過(guò)去，這些 API 可以很方便地獲取生成 tokens 及提示 tokens 的對(duì)數(shù)概率。但后來(lái)，這個(gè)功能被移除了。依然是猜測(cè)，背后的原因可能是，如果你能獲取這些對(duì)數(shù)概率，就如同看到隱藏的思維鏈一樣，這會(huì)讓你更容易從這些 API 和大型模型中提煉出其能力，并將其轉(zhuǎn)移到你自己的模型中。

另外，補(bǔ)充一點(diǎn)我們之前關(guān)于整合 o1 模型的討論：我們現(xiàn)在還在摸索如何使用這個(gè)模型。所以我們把 o1 整合到 Cursor 中，是因?yàn)槲覀円荒玫竭@個(gè)模型就非常想試試，我想很多程序員也會(huì)很感興趣。

o1 并不屬于 Cursor 默認(rèn)體驗(yàn)的一部分，我們至今還沒(méi)有找到一種每天、甚至每小時(shí)都能在編輯器中使用 o1 的方法。因此，我覺(jué)得如何使用 o1 的最佳方式還沒(méi)有定論。我們也還沒(méi)有看到明確展示其實(shí)際用例的例子。有一些明顯的方向，它可以讓你更容易地在后臺(tái)運(yùn)行一些任務(wù)，或讓模型在循環(huán)中運(yùn)行，賦予它們 agent 的能力。但我們還在探索中。

需要澄清的是，我們確實(shí)有一些想法，只是在公開(kāi)之前，我們需要確保能做出真正有用的東西。

但 o1 也有一些明顯的限制。暫且不談它的能力問(wèn)題，它并不支持流式輸出。這意味著，當(dāng)你需要監(jiān)督輸出時(shí)，使用起來(lái)會(huì)非常不方便，你只能等待整段文本一次性顯示。此外，這感覺(jué)像是測(cè)試時(shí)計(jì)算和搜索的初級(jí)階段，o1 更像是一個(gè) v0 版本，還有很多需要改進(jìn)的地方。我猜想，在增加預(yù)訓(xùn)練數(shù)據(jù)量、擴(kuò)展模型規(guī)模以及探索預(yù)訓(xùn)練技巧的同時(shí)，還會(huì)有另一條路徑來(lái)不斷優(yōu)化搜索功能。

最近有傳言說(shuō)，GitHub Copilot 可能會(huì)以某種方式整合 o1，有一些評(píng)論說(shuō)：「這是否意味著 Cursor 完了？」你們?cè)趺纯茨兀?/span>

是時(shí)候關(guān)停 Cursor 了。

沒(méi)錯(cuò)  Cursor 是該倒閉了。

所以你們真的覺(jué)得是時(shí)候把 Cursor 關(guān)了嗎？

我認(rèn)為這個(gè)領(lǐng)域與過(guò)去 2010 年左右的軟件領(lǐng)域有些不同，因?yàn)檫@里的上限真的非常高。我認(rèn)為再等 3-4 年，那時(shí)最好的 AI 編程產(chǎn)品可能比現(xiàn)在的要實(shí)用得多。

當(dāng)然，你可以談?wù)撟o(hù)城河、品牌、優(yōu)勢(shì)等等，但如果你在產(chǎn)品創(chuàng)新上止步不前，就會(huì)被甩在后面。這對(duì)初創(chuàng)公司和想進(jìn)入這個(gè)市場(chǎng)的人來(lái)說(shuō)都是好消息，因?yàn)橹灰隳艽蛟斐龈玫漠a(chǎn)品，就有機(jī)會(huì)超越那些擁有大量用戶的競(jìng)爭(zhēng)者。因此，我認(rèn)為接下來(lái)的幾年關(guān)鍵在于打造最好的產(chǎn)品和系統(tǒng)，不僅包括模型引擎的改進(jìn)，還包括優(yōu)化編輯體驗(yàn)。

沒(méi)錯(cuò)，我認(rèn)為 Cursor 相比其他產(chǎn)品的額外價(jià)值不僅僅在于能快速整合 o1 這樣的新模型。更重要的是，Cursor 的定制模型在各個(gè)方面提供了深入支持，這些模型可能在你不知情的情況下默默發(fā)揮作用，每個(gè)功能都為用戶體驗(yàn)進(jìn)行了精心設(shè)計(jì)。