劃重點
01Cursor團隊在構(gòu)建人機協(xié)同體系，旨在改善程序員生活，提高編程效率。
02團隊成員認為，未來的編程將更加關(guān)注“你想要創(chuàng)造什么”，而非過度依賴AI。
03為此，他們正在研究如何將AI與人類智慧相結(jié)合，提高編程者的控制力和效率。
04同時，團隊也在探索合成數(shù)據(jù)分類法，以更好地訓練AI模型。
05除此之外，他們還計劃在未來幾年內(nèi)實現(xiàn)AGI，讓編程更加有趣。
以上內(nèi)容由騰訊混元大模型生成，僅供參考
智東西（公眾號：zhidxcom）
編譯 | 尹明順 吳浪娜
編輯 |漠影
智東西10月10日消息，當?shù)貢r間10月7日，知名播客主持人Lex Fridman和Cursor團隊4名創(chuàng)始成員Michael Truell、Sualeh Asif、Arvid Lunnemark和Aman Sanger進行了一場長達兩個半小時的對話。
Cursor是一個基于VS Code的代碼編輯器，它為AI輔助編程添加了許多強大的功能，它引起了編程和AI社區(qū)的關(guān)注和興奮，風頭正盛。那么Cursor作為一個初創(chuàng)團隊，如何能夠與科技巨頭微軟的Github Copilot一戰(zhàn)呢？
在播客中，幾人深度討論了Cursor團隊目前的發(fā)展以及未來的探索方向，還廣泛談?wù)摿司幊痰奈磥恚约叭祟惻cAI在設(shè)計和構(gòu)建復(fù)雜而強大的系統(tǒng)方面達成合作的各種可能。
團隊成員在博客中詳細分享了Cursor如何理解你的代碼庫并以此為依據(jù)預(yù)測你下一步要做什么，然后以驚人的速度生成代碼，從而有效提升了編程效率。
他們還介紹了Cursor更多功能，不僅擅長自動補全代碼，它還引入了影子工作區(qū)輔助編寫代碼，并能通過簡單的描述來命令A(yù)I編寫更復(fù)雜的代碼，完成更多的任務(wù)。
此外，團隊成員還對AI編程的技術(shù)要領(lǐng)進行了深入分析，并對人與AI編程之間的倫理問題展開探討，提到了希望將OpenAI o1模型集成的愿景。
值得一提的是，團隊成員認為，快速就是有趣（Fast is Fun）。吸引人們在電腦上創(chuàng)造新內(nèi)容的原因之一就是驚人的迭代速度，而在其他領(lǐng)域，你可能會受到資源或能力的限制，但在編程的世界，只要有你和計算機，你就能非�？焖俚貥�(gòu)建出非�？岬臇|西。
創(chuàng)始團隊中，Aman Sanger擔任Cursor的CEO，是一位工程師和企業(yè)家，此前他曾在Instagram和Facebook擔任領(lǐng)導(dǎo)職位。Arvid Lunnemark是公司的CTO，是一位工程師，曾在Spotify和Google工作。Michael Truell擔任設(shè)計主管，Sualeh Asif擔任公司COO。
▲播客現(xiàn)場介紹Cursor團隊成員（來源：YouTube）
以下是對該播客內(nèi)容的完整編譯（為提高可讀性，智東西調(diào)整了部分問答的順序，并在不違背原意的前提下進行了一定的增刪修改）。
一、類似增強版文字處理器，代碼編輯器可處理更多任務(wù)
Lex：代碼編輯器有什么用？
Michael：代碼編輯器主要是構(gòu)建軟件的地方，長期以來，而在今天或很長一段時間里，代碼編輯器是指對正式編程語言進行文本編輯的地方。對于非程序員來說，可以將代碼編輯器理解為程序員專用的增強版文字處理器。之所以說它是增強版，是因為代碼有很多結(jié)構(gòu)。因此，這個“文字處理器”即代碼編輯器，實際上可以為你做很多事情，而這些是傳統(tǒng)的文字處理器在文本編輯方面做不到的。
這包括給代碼中不同的元素提供視覺區(qū)分，以便快速瀏覽；可以在代碼庫中導(dǎo)航，直接跳轉(zhuǎn)到用戶正在使用的內(nèi)容的定義，就像在互聯(lián)網(wǎng)上使用超鏈接；還有進行錯誤檢查以捕獲基本錯誤等。傳統(tǒng)上，這就是代碼編輯器的定義。我認為在未來十年內(nèi)，隨著構(gòu)建軟件的方式有所變化，代碼編輯器的定義也將發(fā)生很大變化。
Lex：我認為代碼編輯器也應(yīng)該很有趣。
Arvid：是的，這非常重要。這實際上是我們決定構(gòu)建什么的一個被低估的方面。我們構(gòu)建的很多東西，通過試用它們，再進行實驗，然后因為它們不有趣而把它們?nèi)拥�。所以，有趣的很大一部分在于很多時候要快。快速就是有趣。
Michael：基本上，我認為吸引很多人在電腦上構(gòu)建東西的原因之一是這種驚人的迭代速度，而在其他領(lǐng)域，你可能會受到資源或能力的限制……甚至將一大群人聚在一起編程也是一件令人驚奇的事情，只有你和計算機，你才能可以非�？焖俚貥�(gòu)建出非�？岬臇|西。
二、從Copilot的粉絲到開發(fā)Cursor，Cursor起源的兩個重要時刻
Lex：對于不知道的人來說，Cursor是一個超級酷的新編輯器，它是VS Code的一個分支。聽聽你們對自己編輯器之旅的講述會很有趣。我想你們所有人都是VS Code和Copilot的忠實粉絲。你們是如何接觸到VS Code的，以及這如何引導(dǎo)你們走向Cursor？
Aman：我們最初都是純Vim用戶。沒有Neovim，只有純Vim和終端。至少對我自己來說，當Copilot出來的時候，大約是2021年，我真的很想試試它。所以我進入了VS Code，這是唯一可以使用Copilot的代碼編輯器，盡管我真的很喜歡使用Vim，但VS Code和Copilot的體驗足以說服我發(fā)生轉(zhuǎn)變。所以，這基本上成了默認設(shè)置，直到我們開始開發(fā)Cursor。
Lex：也許應(yīng)該解釋一下Copilot的功能。它是一個非常不錯的自動補全工具。當你開始寫東西時，它會建議一到三行代碼來完成它，這是一種有趣的體驗。你知道當你有親密的朋友時，你的朋友會幫你補全你的話一樣。當它做得很好時，會有一種親密的感覺�？赡�“親密”這個詞不太準確，但有一種很酷的感覺，就像“哇，它懂我”。然而當它不懂你時，就會有一種不愉快的感覺。所以會有這種摩擦。但我想說，對于很多人來說，那種“它懂我”的感覺壓倒了“它不懂我”的感覺。
Arvid：我認為GitHub Copilot被低估的一點是，即使它出錯了也有點煩人，但并沒有那么糟糕，因為你只需再輸入一個字符，也許它就能理解你了，或者你再輸入一個字符，它就能理解你了。所以即使它錯了，也不會那么糟糕。
Sualeh：你可以進行迭代和修復(fù)。我的意思是，對我來說，Copilot的另一個被低估的部分是，它是第一個真正的AI產(chǎn)品，第一個面向消費者的語言模型產(chǎn)品。
Lex：所以Copilot有點像語言模型的第一個殺手級應(yīng)用。
Michael：是的，它的beta版在2021年發(fā)布。
Lex：那么Cursor的起源故事是什么樣的？
Michael：大約在2020年，OpenAI發(fā)布了scaling laws論文，這是一個關(guān)鍵時刻，這個領(lǐng)域似乎取得了清晰可預(yù)測的進展，即使我們沒有任何新想法，看起來只要有更多的計算能力和更多的數(shù)據(jù)，就可以讓這些模型變得更好。
Lex：順便說一下，我們可能需要花三到四個小時來討論scaling laws這個話題。但簡而言之，這是一系列論文中的一篇，這些論文提出了一系列觀點，認為在機器學習領(lǐng)域，模型的大小和數(shù)據(jù)的大小，越大越好。
Michael：所以在那段時間，我們中的一些人有很多關(guān)于這會是什么樣子的概念性討論。對于所有這些不同知識領(lǐng)域的工作者來說，這項技術(shù)的發(fā)展將如何讓他們變得更好？然后我認為有幾個時刻，那篇論文中預(yù)測的理論進展開始變得非常具體，開始覺得你可以在AI領(lǐng)域做實際上有用的工作，而不需要去攻讀博士。感覺現(xiàn)在可以構(gòu)建一整套真正有用的系統(tǒng)。我認為第一個時刻是玩轉(zhuǎn)Copilot的早期測試版，那種感覺很棒，很神奇。
我認為第二個重要時刻是提前獲得了GPT-4的早期訪問權(quán)限。大約在2022年底，我們開始修改這個模型，能力的升級感覺非常巨大。在此之前，我們一直在研究一些不同的項目。因為Copilot，因為scaling laws，因為我們之前對這項技術(shù)的興趣，我們一直在修改程序員使用的工具，但這些都是非常具體的工具。所以我們正在為必須在Jupyter Notebook上工作的金融專業(yè)人士構(gòu)建工具，或者嘗試使用這些模型進行靜態(tài)分析。
而GPT-4的升級讓我們感覺這確實證實了我們之前預(yù)測的理論進展。感覺就像在那個時間點你可以立即構(gòu)建很多東西。而且，如果我們保持一致，這真的感覺不僅僅是一個點解決方案，這將涉及整個編程領(lǐng)域，所有編程都將通過這些模型進行，而且感覺這需要一種不同類型的編程環(huán)境，一種不同的編程方式，所以我們開始構(gòu)建那種更大的愿景。
Sualeh：有一件事我印象非常深刻，我的室友是IMO金牌得主，美國有一個叫Putnam的比賽，這有點像是大學生的IMO，也是一個數(shù)學競賽，它非常精彩。我記得Shengtong和Aman在2022年6月左右打賭，賭能否在2024年6月或7月的IMO中獲得金牌。
Lex：IMO是國際數(shù)學奧林匹克競賽。
Sualeh：Arvid和我也參加了，盡管我在某種程度上相信進步，但我認為想拿下IMO金牌，Aman是在異想天開。但老實說我完全錯了，但這可能是團隊中最有先見之明的賭注。
Aman：我清楚地記得我和Michael有一次對話，在那之前我還沒有非常深入和批判性地思考過scaling laws，他提出了一個問題，為什么scaling laws就是你需要的一切，或者為什么scaling laws不會帶來巨大的進步？我想我經(jīng)歷了悲傷的五個階段，最后終于接受了。
我想從那以后我一直對進步充滿希望和樂觀。我想要補充的一點是，這也取決于你將在哪些領(lǐng)域看到進步。數(shù)學是一個偉大的領(lǐng)域，尤其是形式化定理證明，因為你可以得到一個很好的信號來實際驗證事物是否正確。所以這意味著像強化學習這樣的東西可以工作得非常好，我認為你可能會擁有在數(shù)學上非常超人的系統(tǒng)，但從技術(shù)上講仍然沒有AGI。
三、Cursor預(yù)測你的下一步，或?qū)⒏淖儤?gòu)建軟件的方式
Lex：好的，那么我們談?wù)凜ursor。
Michael：對我們來說，決定做一個編輯器似乎是顯而易見的，至少對于我們想要做的事情和實現(xiàn)的目標來說是這樣的，因為當我們開始開發(fā)編輯器時，想法是這些模型會變得更好，它們的能力會提高，這將徹底改變你構(gòu)建軟件的方式，這不僅會讓你獲得巨大的生產(chǎn)力提升，而且會帶來根本性的改變，構(gòu)建軟件的方式也會發(fā)生很大的變化。所以，如果你是現(xiàn)有編程環(huán)境的一個插件，那么你對代碼編輯器的控制會非常有限，我們不想被這些限制所束縛。我們希望能夠構(gòu)建最有用的東西。
Lex：Cursor與Copilot在某種程度上是競爭對手，你們?nèi)绾稳�？靠速度和功能質(zhì)量嗎？
Aman：是的，我想這是一個相當有趣，也許非常獨特的領(lǐng)域，如果你看看以前的技術(shù)浪潮，也許只有一種主要的事情發(fā)生，它解鎖了一波新的公司，但每年，每一個模型能力的跳躍，你就解鎖了一波新的功能，尤其是編程中可能實現(xiàn)的事情。
所以我認為在AI編程中，即使只是領(lǐng)先幾個月，更不用說一年了，也會讓你的產(chǎn)品變得有用得多。我認為一年后的Cursor將需要讓今天的Cursor看起來過時。我認為微軟已經(jīng)做了很多很棒的事情，但我認為他們不像一個初創(chuàng)公司那樣有很大的空間真正繼續(xù)創(chuàng)新和推動這方面的發(fā)展。
Sualeh：我不知道我是否從功能的角度來考慮它，還是從程序員的能力的角度來考慮它。隨著新的o1模型發(fā)布，我相信會有更多不同類型的模型，比如更長上下文的，也許更快，所有這些瘋狂的想法你都可以去嘗試，希望其中10%的瘋狂想法能夠變成某種很酷且有用的東西，我們希望人們能更快地擁有它。換句話說，一個被低估的事實是，我們正在為自己創(chuàng)造它。
當我們開始構(gòu)建Cursor時，你真的會感到沮喪，你可以看到模型變得更好，但Copilot的體驗沒有改變。就像，這些家伙天花板越來越高，為什么他們不創(chuàng)造新東西？他們應(yīng)該創(chuàng)造新東西。那些Alpha功能在哪里？但沒有那些功能。如果做了新東西，我確信它是一門好生意。我敢肯定這是一項偉大的事業(yè)，我是那種真的想嘗試和使用新東西的人，但很長一段時間都沒有做出新東西。
Lex：當你比較Cursor和Copilot時，Copilot很快就開始因為某種原因而給人一種過時了的感覺。
Arvid：是的，我認為對我們有幫助的一件事是，我們把所有事情都做成了，我們在開發(fā)用戶體驗和與模型交互的方式的同時，也在開發(fā)如何讓模型給出更好的答案。所以你如何構(gòu)建提示，或者你如何找到上下文，對于Cursor Tab來說，你如何訓練模型？所以我認為這有助于我們讓同一批人來負責整個體驗。
Sualeh：是的，就像制作UI的人和訓練模型的人坐在一起，相距18英尺遠，甚至經(jīng)常是同一個人。你可以創(chuàng)造出一些如果不交談、不實驗就不可能實現(xiàn)的東西。
Lex：你們用Cursor來寫Cursor？
Arvid：當然。
Lex：我們聊聊無所不能的Tab，堪稱加強版自動補全的功能。Tab是怎么工作的？它是什么？
Michael：概括來說，我認為Cursor目前在兩個方面表現(xiàn)不錯。當然，它還有其他功能，但這兩項功能對程序員來說非常有幫助。一是它就像在你身后觀察，是一個速度很快、可以搶在你前面輸入并預(yù)測你下一步要做什么的同事。這也是一個好的自動補全功能的初衷，預(yù)測你下一步要做什么，但我們可以更進一步，不僅預(yù)測Cursor后面的字符，還能預(yù)測你要進行的下一個整體更改、下一個差異、接下來要跳轉(zhuǎn)的位置。
第二個是，能幫助你有時領(lǐng)先于AI，告訴它該做什么，實現(xiàn)從指令到代碼的轉(zhuǎn)換。為了做好這兩件事，我們在提高編輯體驗上下了很多功夫，讓它們既符合人體工程學，又足夠智能和快速。
四、加強版自動補全功能Cursor Tab，消除編輯器中的低熵操作
Sualeh：我們真正想要實現(xiàn)的是，讓模型能夠為我們編輯代碼。這是我們的愿望，在擁有能夠編輯代碼的優(yōu)質(zhì)模型之前，我們進行了多次嘗試。有了優(yōu)質(zhì)模型后，為了讓使用體驗更加流暢，我們付出了很多努力來加快推理速度，并已經(jīng)開始整合。
Michael剛才也提到了這種跳轉(zhuǎn)到不同位置的能力，我認為這種跳轉(zhuǎn)源于一種感覺，即一旦你接受了編輯，下一步要去哪里應(yīng)該非常明顯。比如，我做了這個更改，模型應(yīng)該直接知道下一步要跳轉(zhuǎn)到第18行。如果你是WIM用戶，你可能會按18JJ之類的快捷鍵，但為什么我要這么做呢？模型應(yīng)該直接知道。
所以，你只需要按Tab鍵，它就會跳到第18行，然后顯示下一個編輯，你再按Tab鍵，你只需一直按Tab鍵，就能一直這樣操作下去。所以內(nèi)部競爭就變成了，我們能讓人按多少次Tab鍵？一旦你有了這個想法，更抽象地說，要考慮的是如何使編輯達到零熵狀態(tài)。
也就是說，一旦你表達了意圖并且編輯，沒有新的信息片段來完成你的想法，但你仍然需要輸入一些字符來讓計算機理解你真正的想法，那么模型或許應(yīng)該“讀懂”你的心思，所有零熵位都應(yīng)該只是被Tab鍵消除，這就是比較抽象的說法。
Aman：一個有趣的現(xiàn)象是，如果你看不同領(lǐng)域的language model loss，我相信每字節(jié)的比特數(shù)，這是一種對代碼字符標準化損失的衡量，比語言低，這意味著代碼中有很多token是非常可預(yù)測的，很多字符也是非�？深A(yù)測的。而且，當你不僅僅是試圖自動補全代碼，而是預(yù)測用戶在編輯現(xiàn)有代碼時的下一步操作時，這種可預(yù)測性會被進一步放大。因此，Cursor Tab的目標是消除編輯器中所有低熵操作。一旦意圖得到有效確定，就讓我們直接跳轉(zhuǎn)到未來的某個時間點，向前跳過。
Lex：那么，Tab在近期內(nèi)應(yīng)該能夠做什么？
Aman：我可以講講讓這些功能發(fā)揮作用的一些細節(jié)。它們的延遲極低，所以你需要在這個任務(wù)上訓練小型模型。特別是，它們非常需要預(yù)填充token。這意味著它們有非常長的提示，能看到很多代碼，但實際上生成的token并不多。因此，使用MOE模型是最合適的。這是我們?nèi)〉玫囊豁椡黄�，極大地提高了模型在長上下文中的性能。另一個突破是我們構(gòu)建的投機解碼的變體，稱為投機編輯。我認為，這兩點是使其質(zhì)量高、速度快的重要因素。
Lex：那么緩存起作用了嗎？
Aman：緩存起到了巨大的作用。因為你要處理這么多輸入token，如果你在給定行中輸入的每個按鍵都要針對所有傳入的token重新運行模型，那么一是會大大降低延遲，二是會讓GPU負載過高。因此，你需要設(shè)計用于模型的實際提示，使其具有緩存意識。然后，你需要跨請求重用KV緩存，以減少計算量。
Sualeh：希望能跳轉(zhuǎn)到不同的文件。所以，如果你在一個文件中進行了編輯，可能需要轉(zhuǎn)到另一個文件來完成你的想法，它也應(yīng)該轉(zhuǎn)到第二個文件。
Arvid：完整的泛化是下一步行動預(yù)測。有時你需要在終端中運行命令，它應(yīng)該能夠根據(jù)你編寫的代碼來建議命令，或者有時它會給出建議，但你很難判斷它是否正確，因為你需要更多信息來學習。你需要知道類型才能驗證其是否正確。所以它或許應(yīng)該先帶你到某個定義的地方，然后再帶你回來，這樣你就有了接受下一個補全所需的所有必要知識。
Michael：編程是一門奇特的學科，有時你接下來五分鐘要做什么，實際上是可以根據(jù)你最近所做的事情預(yù)測出來的。那么，我們能否創(chuàng)造一個世界，讓這接下來的五分鐘要么在你放手的情況下自動完成，要么在你看到下一步要做什么并確認無誤后，通過輕觸Tab鍵就能快速實現(xiàn)。
五、增加顯示框提示代碼差異，圍繞審查者體驗做設(shè)計
Lex：Cursor有一個非常酷且引人注目的功能，那就是整個diff界面情況。所以，模型用紅色和綠色顯示我們將如何修改代碼，然后可以在聊天窗口中應(yīng)用它，它會向你顯示diff，你可以接受diff。那么，你能講講這方面的發(fā)展方向嗎？
Sualeh：我們可能會有四五種不同的diff。我們?yōu)樽詣友a全功能優(yōu)化了diff，因此它具有與審查大塊代碼時不同的diff接口。然后，我們正在嘗試優(yōu)化另一個diff功能，以適應(yīng)處理多個不同文件的情況。從高層次來看，差異在于，當你進行自動補全時，讀取速度應(yīng)該非�？�。實際上，在所有情況下它的讀取速度都應(yīng)該非�？欤谧詣友a全功能中，你的注意力會集中在一個區(qū)域，人類無法同時關(guān)注太多不同的地方。
在界面方面，我們有當前框，如果你試圖在某個地方刪除代碼并嘗試添加其他代碼，它會嘗試在側(cè)面顯示一個框。
我們嘗試了三四種不同的方法來實現(xiàn)這個功能。最初的方法是在旁邊顯示一個帶有藍色刪除線的框。它過去會以Google Docs的風格顯示要刪除的代碼，你會看到一條線穿過，然后看到新代碼，這非常分散注意力。然后我們嘗試了很多不同的方法……有刪除、紅色高亮等。
之后的迭代版本有點有趣，你會按住Mac上的option鍵。所以它會高亮顯示一段代碼，以顯示AI有建議給你。在這個例子中，輸入和值都會變成藍色，藍色是用來高亮顯示AI對你有一個建議。它不會直接顯示建議的內(nèi)容，而只是提示你AI有一個建議。如果你真的想看到它，就按住option鍵，然后你會看到新的建議，松開option鍵后，你又會看到原始代碼。
Arvid：我個人非常期待在這個領(lǐng)域做出很多改進。我們經(jīng)常把它稱為驗證問題，這些差異對于小范圍修改來說很好用。但如果是大范圍修改，或者涉及多個文件等情況，審查這些差異就有點費力了。所以這里有幾個不同的想法。一個想法是，差異中的某些部分很重要，包含了很多信息。而有些部分的信息熵很低，就是重復(fù)的內(nèi)容。
所以，或許可以高亮顯示重要的部分，而將不那么重要的部分灰度顯示�；蛘撸憧梢杂幸粋�模型，它查看差異并發(fā)現(xiàn)，“哦，這里可能有個漏洞。”我會用紅色波浪線標記出來，并提示你，“你應(yīng)該重點審查這部分差異。”我覺得這類想法很令人興奮。
而且，你希望用一個智能模型來完成這項工作。目前的算法只是普通算法，沒有智能性。算法的設(shè)計需要智能，但你并不關(guān)心它是關(guān)于這個還是那個，你只希望模型能做到這一點。
Sualeh：所以我認為一個普遍的問題是，隨著這些模型變得越來越智能，它們能夠提出的更改也會越來越大。而隨著更改越來越大，人類需要做的驗證工作也越來越多。這變得越來越……你需要幫助他們。我可不想把所有的時間都花在代碼審查上。
Aman：GitHub試圖通過代碼審查來解決這個問題。當你進行代碼審查時，你正在審查多個文件中的多個差異。但就像Arvid之前說的，我認為你可以做得比代碼審查更好。代碼審查有點糟糕。你花了很多時間去理解那些通常對你來說很陌生的代碼，而且它甚至并不能真正捕捉到很多漏洞。
我認為，使用語言模型可以顯著改善審查體驗，例如，使用Arvid之前描述的那種技巧，即可能指向?qū)嶋H重要的區(qū)域。我還認為，如果代碼是由這些語言模型生成的，而不是由其他人生成的……代碼審查體驗是同時為審查者和代碼編寫者設(shè)計的。
在代碼編寫者是語言模型的情況下，你就不必那么關(guān)心他們的體驗了，你可以完全圍繞審查者來設(shè)計整個體驗，讓審查者的工作盡可能有趣、輕松、高效。我覺得，如果只是天真地試圖讓這些東西看起來像代碼審查，那就會出現(xiàn)問題。我認為你可以更有創(chuàng)造力，并推動可能性的邊界。
Arvid：還有一個想法是，我認為順序很重要。通常，當你審查一個拉取請求（PullRequest）時，你會看到一個文件列表，并且從上到下依次審查，但實際上，你可能需要先理解這個部分，因為這部分在邏輯上是先發(fā)生的，然后你再理解下一部分，而你不希望自己弄清楚這一點，你希望有一個模型來引導(dǎo)你。
我認為，并不是所有的編程都會變成自然語言。如果我正在和Sualeh結(jié)對編程，Sualeh在電腦前和鍵盤上，有時如果我來主導(dǎo)，我會對Sualeh說，嘿，實現(xiàn)這個功能，這樣就行了。但有時，向Sualeh解釋我想讓他做什么太麻煩了，所以我會接過鍵盤，給他展示一下。
我寫一部分示例，然后他就明白了，這是最容易的溝通方式。所以我認為，對AI來說也是這樣。有時，與AI溝通的最簡單方式就是展示一個示例，然后它就會在其他地方執(zhí)行這個操作。
或者，有時如果你在做網(wǎng)站，例如，向AI展示你想要什么最容易的方式不是告訴它要做什么，而是拖動或繪制東西，也許最終我們會實現(xiàn)腦機接口之類的，你就可以讓它理解你在想什么。所以我認為自然語言會有一席之地。但我肯定地認為，它不會是大多數(shù)人大部分時間編程的方式。
▲播客現(xiàn)場（來源：YouTube）
六、Apply定制模型創(chuàng)建差異，更少的token使用更智能的模型
Lex：我在使用這個編輯器時，真的感受到了通用AI（AGI）的存在。感覺它背后有很多機器學習在起作用。能告訴我一些讓它正常工作的機器學習內(nèi)容嗎？
Aman：Cursor真正發(fā)揮作用的地方在于，我們通過這組自定義模型與前沿模型一起訓練，這些模型在推理密集型任務(wù)中表現(xiàn)非常出色。Cursor Tab就是一個很好的例子，你可以將這個模型專門化，使其甚至比前沿模型還要好。另一個領(lǐng)域是Apply，令人驚訝的是它需要定制模型，但這是必要的，而且在應(yīng)用方面效果很好。
這些前沿模型在草擬代碼計劃和生成變化的粗略草圖方面相當出色，但實際上，為訓練模型創(chuàng)建差異對于前沿模型來說是非常困難的。如果你嘗試用Sonnet、o1或任何其他前沿模型來做這件事，它會在一些愚蠢的事情上出錯，比如計算行數(shù)，尤其是在非常大的文件中。為了解決這個問題，我們讓模型勾勒出這個粗略的代碼塊，表明將發(fā)生哪些變化，然后我們訓練一個模型，將該變化應(yīng)用到文件中。
Lex：我們應(yīng)該說，Apply模型會查看你的代碼，并給你一個非常好的新操作建議。而看似對人類來說微不足道的將兩者結(jié)合起來的步驟，并不容易。
Sualeh：與普遍認知相反，這不是一個確定性算法。
Aman：是的，你會發(fā)現(xiàn)其他地方有Apply的淺拷貝，但大多數(shù)情況下它都會失效，因為你覺得可以嘗試進行一些確定性匹配，但它至少會有40%的時間失敗了，這會導(dǎo)致產(chǎn)品體驗非常糟糕。我認為，隨著模型變得越來越智能，這種趨勢將繼續(xù)下去。所以，Apply還能讓你做另一件事，那就是你可以用更少的token來使用最智能的模型。這在生成所有這些token的延遲和成本方面都很昂貴。
所以，你可以給出一個非常粗略的草圖，然后讓你的模型去實現(xiàn)它，因為實現(xiàn)這個非常粗略的代碼是一個更容易的任務(wù)。我認為這種趨勢將繼續(xù)下去，你可以使用越來越智能的模型來進行計劃，然后也許可以由不那么智能的模型來處理實現(xiàn)細節(jié)。也許你可以使用o1，也許它會有更強大的模型，給出更高級別的計劃，該計劃由sauna遞歸應(yīng)用，然后是apply模型。
Sualeh：也許應(yīng)該談?wù)勅绾巫屗兛臁?/p>
Aman：讓它變快的一個主要組成部分是投機編輯。投機編輯是投機解碼的一種變體，也許簡要描述一下投機解碼會很有幫助。在投機解碼中，你可以利用這樣一個事實，大多數(shù)情況下，我會加上一個限定，那就是當你在語言模型生成中受到內(nèi)存限制時，如果你一次處理多個token，這比一次生成一個token要快。
所以我們做的是，不是使用投機解碼通常所做的，即使用一個小模型來預(yù)測這些草稿token，然后你的大模型會進去驗證，在代碼編輯中，我們對現(xiàn)有代碼的外觀有非常強的先驗，并且該先驗實際上是完全相同的代碼。所以，你可以做的是，將原始代碼的部分反饋回模型，然后模型大多數(shù)情況下都會同意，“好吧，我只是要把這段代碼原樣輸出。”
所以，你可以并行處理所有這些行，只要使用足夠多塊即可。然后最終你會達到一個分歧點，模型現(xiàn)在將預(yù)測與原始代碼不同的文本。它會生成這些token，然后，在足夠多的token與原始代碼匹配后，我們會重新開始以代碼塊為單位進行預(yù)測。
這實際上看起來就像是正常編輯代碼的一個更快版本。所以它看起來就像是模型重寫所有代碼的一個更快版本。因此，我們可以使用與diff相同的接口，但它的流式傳輸速度會快得多。
七、GPT和Claude在編程上哪個更勝一籌？
Lex：哪個大語言模型更擅長編程？GPT和Claude，在編程方面，哪個更勝一籌？
Aman：我認為沒有哪個模型能在所有我們認為重要的類別中都優(yōu)于其他模型，這些類別包括速度、編輯代碼的能力、處理大量代碼的能力、長文本上下文，以及其他幾個因素和編程能力。我現(xiàn)在會說總體上最好的是Sonnet。我認為這是大家的共識。
o1也非常有趣，它非常擅長推理。所以，如果你給它一些很難的編程面試風格的問題或者領(lǐng)導(dǎo)代碼問題，它能做得很好，但它似乎不如Sonnet那樣能理解你的大致意圖。如果你看看其他很多前沿模型，我有一個疑慮，那就是感覺它們不一定好……我不是說它們在基準測試上訓練，但它們在基準測試中的表現(xiàn)確實非常好，相對于所有中間的東西。
所以如果你嘗試所有這些基準測試和它們評估的分布中的東西，它們會做得很好。但是，當你把它們稍微推離這個范圍時，Sonnet是我認為在保持相同能力方面做得最好的。你在基準測試中擁有的能力與嘗試指示它執(zhí)行任何與編程相關(guān)的事情時擁有的能力相同。
Sualeh：順便說一下，這是一個非常困難且至關(guān)重要的細節(jié)，基準測試與真正的編程之間的區(qū)別在于，真正的編程并不是面試風格的編程。人類有時會說半吊子的英語，有時你會說，“哦，按照我之前做的那樣做。”有時你會說，“添加這個東西，然后為我做這個其他事情，然后制作這個UI元素。”但很多事情都是依賴于上下的。你真的想要理解人類，然后按照人類的意愿去做，而不是……也許抽象地說，面試問題是非常明確具體的。它們在很大程度上依賴于明確說明，而人類的東西則不那么明確。
Aman：關(guān)于Claude，我聽到過一個有趣的觀點，我認為AWS有不同的芯片，我懷疑它們與Nvidia GPU的數(shù)值略有不同，有人推測Claude性能下降可能與在AWS Bedrock上使用的量化版本與Anthropics GPU上運行的版本不同有關(guān)。
八、Preempt系統(tǒng)可自動實現(xiàn)預(yù)想效果
Lex：在這一切中，一個好的提示（Prompt）扮演著什么角色？
Arvid：我認為這取決于你使用的是哪個模型，它們都有細微的差別，對不同的提示反應(yīng)也不同。但我認為，最初的GPT-4和去年的某些模型，它們對提示相當敏感，而且它們的上下文窗口也很校所以我們有很多與代碼庫相關(guān)的信息，這些信息可能在提示中會很有用。
你有文檔、你添加的文件、你有對話歷史，然后問題就來了，你如何決定實際上要把什么放進提示里，特別是當你的空間有限時？對于今天的模型，即使你有長上下文，填滿整個上下文窗口就意味著它會變慢。這意味著有時模型實際上會感到困惑，而且有些模型比其他模型更容易困惑。
我們內(nèi)部有一個系統(tǒng)叫做Preempt，它在這方面對我們有一些幫助。我認為它是為我們有8000個token上下文窗口的時代建立的，它有點類似于當你在制作一個網(wǎng)站時。你希望它在手機上能正常工作，你希望它在桌面上也能正常工作，而你有這些動態(tài)信息，但你沒有固定的布局。
例如，如果你設(shè)計一本印刷雜志，你知道你可以把東西放在哪里，但是當你有一個網(wǎng)站或者一個提示時，你有這些輸入，然后你需要格式化它們，以便它們能總是正常工作，即使輸入非常大，你可能必須削減一些內(nèi)容。所以我們的想法是，好吧，讓我們從中獲得一些啟發(fā)。
設(shè)計網(wǎng)站的最佳方式是什么？我們非常喜歡的是React以及它的聲明式方法，你在JavaScript中使用JSX，然后直接聲明：這就是我想要的，我認為這個部分比其他部分具有更高的優(yōu)先級或更高的Z軸順序。在網(wǎng)頁設(shè)計中，你有一個渲染引擎，就像Chrome一樣，在Cursor中它是一個preempt渲染器，它會將所有內(nèi)容都放在頁面上。你只需說明你想要的效果，渲染器會自動幫你實現(xiàn)。我們發(fā)現(xiàn)這鐘方法非常有幫助，而且它的作用隨著時間的推移已經(jīng)發(fā)生了變化。
最初它是為了適應(yīng)較小的上下文窗口，而現(xiàn)在它在拆分進入提示詞的數(shù)據(jù)和實際生成方面發(fā)揮了很大作用。因此，它更容易調(diào)試，因為你可以修改提示詞，然后在舊的提示上進行測試，直接查看你的修改是否真的提升了整個評估集的表現(xiàn)。
Lex：所以你們是真的用JSX來提示嗎？
Arvid：是的。我們有一個文件組件，它接收光標。通常在你的文件中有一行光標所在的位置，那可能是最重要的一行，因為那是你正在查看的一行。然后你可以給出優(yōu)先級。而且，如果你有很多來自整個代碼庫的代碼塊，你可以使用檢索和嵌入等重新排序分數(shù)來為這些組件添加優(yōu)先級。
Lex：那么當人類提問時，也應(yīng)該嘗試使用那樣的東西嗎？這是否意味著問題會變得松散和混亂，還是這樣的系統(tǒng)應(yīng)該鼓勵人們更清晰地表達？
Arvid：我認為我們的目標是，你應(yīng)該只做對你來說最自然的事情，然后我們的工作就是弄清楚如何實際檢索到相對重要的事情，以便你的思考是有意義的。
Lex：模型選擇回應(yīng)與一般回應(yīng)有多難？這很難，如何處理不確定性。我是否選擇詢問更多信息以減少歧義？
Sualeh：我們最近為Cursor添加了一個加入文件的功能。當你在編輯代碼或輸入內(nèi)容時，模型會嘗試預(yù)測你正在做什么，如果模型發(fā)現(xiàn)有不確定的地方，它會猜測你可能在編寫某種API。然后，模型會查看你的歷史記錄，推測哪些文件與當前的編輯內(nèi)容相關(guān)。
這里有一個技術(shù)上的難題，就是如何在所有歷史記錄中找到相關(guān)的信息，判斷在當前的提示詞下哪些文件最重要。雖然這個功能還處于試驗階段，但相信我們會逐步完善它，但我們想展示出這個想法：你是否想添加這個文件、那個文件，以便模型幫你編輯？
也許你在編寫一個API，你也應(yīng)該需要編輯使用這個API的客戶端和服務(wù)器代碼，那么API發(fā)生變化時，客戶端和服務(wù)器代碼也需要相應(yīng)更新。
Cursor可以做的是，當你在編寫提示或代碼時，在你按下回車之前，模型可以幫你找到這些可能需要一起修改的部分。這樣做的好處是，可以提前解決一些不確定性，確保所有相關(guān)的代碼都被正確更新，而不需要手動去查找和同步這些改動。
九、我們正在接近AGI時代，但AI Agent還不實用
Lex：你們怎么看Agent？Agent有多有用？
Arvid：我覺得Agent就像是人類，你能感覺到你正在接近AGI，因為你能看到一個演示，它表現(xiàn)得就像一個真人，這真的很酷。我認為Agent在很多事情上還不是特別有用，但我們已經(jīng)越來越接近它們真正變得有用的階段了。
所以我覺得有些類型的任務(wù)，有Agent的話會更好。例如，如果我們有一個bug，有時你不能在聊天輸入框中使用Command+C和Command+V，這是一個非常明確的任務(wù)，我只需要用兩句話來說：“這個不能用，請修復(fù)它。”然后我會很樂意有一個Agent，它會自動去處理，修復(fù)這個bug，然后我回來檢查修復(fù)情況。
它會找到正確的文件，嘗試重現(xiàn)bug，修復(fù)它，然后驗證它是否正確。這可能是一個需要很長時間的過程。所以我覺得我會很喜歡這樣。而且我覺得在編程中，經(jīng)常有人認為Agent會取代所有的編程工作。我不認為我們這么認為，因為很多編程工作，很多價值在于迭代，或者說你其實不想一開始就明確指定什么，因為你真的不知道你想要什么，直到你看到了初始版本，然后你想在此基礎(chǔ)上進行迭代，然后提供更多的信息。
所以在很多編程工作中，我認為你實際上想要的是一個即時的系統(tǒng)，它能立即給你一個初始版本，然后你可以非�？焖俚剡M行迭代。
Lex：比如最近推出的ReplicaAgent，它可以設(shè)置開發(fā)環(huán)境，解決軟件包問題，配置一切，包括配置數(shù)據(jù)庫和部署應(yīng)用。這也是你夢想中的一部分嗎？
Arvid：我覺得是的，對于某些類型的編程工作，這真的很酷。
Lex：這在Cursor的范圍內(nèi)嗎？
Arvid：是的，我們目前并沒有積極地在做這件事，但可以肯定的是我們想讓程序員的生活更輕松、更有趣，有些事情真的很乏味，你需要經(jīng)過一系列步驟，你想把這些事情交給Agent去做。然后有些事情，你可以讓一個Agent在后臺工作，同時你也在工作。比如說，你有一個同時涉及后端和前端的PR（Pull Request），你在前端工作，然后你可以讓一個后臺Agent去處理后端部分，當你開始處理后端部分的PR時，你就已經(jīng)有了一些初始代碼可以迭代了。所以這也會很酷。
十、影子工作區(qū)，在后臺運行代碼
Arvid：首先，我們要明確的是，我們希望在后臺進行大量的操作，并且我們正在嘗試很多內(nèi)容。目前，除了緩存預(yù)熱或找出命令鍵提示所需的正確上下文之外，我們并沒有太多其他后臺操作。但我們的想法是，如果能真的在后臺進行計算，那么就可以幫助你預(yù)測更長時間范圍內(nèi)的操作，而不僅僅是預(yù)測你接下來要寫的幾行代碼。
而是預(yù)測在接下來的10分鐘里，你可能會做什么。通過在后臺進行計算，我們可以花更多的計算資源來做這件事。所以我們實施的影子工作區(qū)（Shadow Workspace）的概念，并在內(nèi)部進行實驗，是為了真正利用后臺計算的優(yōu)勢，我們需要給模型提供某種反饋信號，不然可以通過讓模型思考更長時間來獲得更高的性能，比如o1就是一個很好的例子。
但另一種提高性能的方法是讓模型進行迭代并獲得反潰對于程序員來說，一個非常重要的反饋來源是語言服務(wù)器。它存在于大多數(shù)不同的語言中，并且每種語言都有一個單獨的語言服務(wù)器。它可以告訴你“你在這里使用了錯誤的類型”，并給出錯誤提示，或者它還可以跳轉(zhuǎn)到定義，并理解你的代碼結(jié)構(gòu)。TypeScript語言服務(wù)器是由TypeScript團隊開發(fā)的，Rust語言服務(wù)器是由Rust團隊開發(fā)的，它們都通過語言服務(wù)器協(xié)議與VS Code進行交互。這樣，VS Code就不需要內(nèi)置所有不同的語言，而是可以使用現(xiàn)有的編譯器基礎(chǔ)結(jié)構(gòu)。
這是為了代碼檢查、跳轉(zhuǎn)到定義以及查看你正在使用的正確類型。當你在處理一個大型項目時，類型檢查和引用查找功能都是必不可少的。如果沒有這些功能，就很難在大型項目中編寫代碼。
Lex：在Cursor中是如何使用語言服務(wù)器協(xié)議進行通信的嗎？
Arvid：在Cursor中，我們使用語言服務(wù)器協(xié)議向程序員展示信息，就像在VS Code中一樣，但我們的想法是，我們還想將這些信息展示給智能模型，并且我們想在不影響用戶的情況下做到這一點，也就是說，我們想在后臺進行這些操作。
影子工作區(qū)的想法是，我們可以創(chuàng)建一個隱藏的Cursor窗口這樣你就可以在它里面設(shè)置這個標志，然后把它隱藏起來。雖然你看不到它，但它確實存在。在這個窗口中，AIAgent可以隨意修改代碼，只要它們不保存修改，因為這仍然是同一個文件夾。然后，它們可以從linters（代碼檢查工具）中獲得反饋，跳轉(zhuǎn)到定義，并對代碼進行迭代。
這是我們最終想要實現(xiàn)的目標，也是我們博客文章主要討論的內(nèi)容，因為實現(xiàn)這一點有點棘手。我們希望它在用戶的機器上運行，以便完全模擬用戶的環(huán)境。在Linux上，我們可以做一些很酷的事情，比如鏡像文件系統(tǒng)，并讓AI在文件級別上進行操作，但實際上，這些操作是存儲在內(nèi)存中的。我們可以創(chuàng)建一個類似于內(nèi)核的擴展來實現(xiàn)這一點。而在Mac和Windows上，這有點難，但這是一個有趣的技術(shù)問題，所以我們在進行這項研究。
Aman：一個可能有些粗糙但很有趣的想法是，對保存操作進行鎖定。這樣，你可以讓語言模型在保存到磁盤時鎖定，然后你就不必在保存到磁盤的文件的真實版本上操作，而是在操作影子工作區(qū)中的那些未保存的內(nèi)容。你仍然可以獲得錯誤提示，并可以在其中編寫代碼。然后，當你嘗試運行代碼時，會出現(xiàn)一個小警告，提示有鎖存在，這時你可以從語言服務(wù)器或影子工作區(qū)中釋放鎖，以便并發(fā)地執(zhí)行其他操作。
十一、模型查詢bug仍有困難，Open o1也不例外
Lex：允許模型修改文件是一個令人興奮的未來，雖然這聽起來也有些嚇人。設(shè)想AI agent可以自動執(zhí)行一系列任務(wù)，用戶第二天只需對結(jié)果進行審查，AI就好像你的同事一樣。
Aman：我認為，模型在可運行性方面會有不同情況。執(zhí)行一些簡單任務(wù)時，用戶可以在幾分鐘內(nèi)順利完成，在本地機器上運行也是合理的。而執(zhí)行一些需要更長時間以及更大變動的任務(wù)時，則需要在遠程的沙盒環(huán)境中完成。如何精準將用戶環(huán)境重現(xiàn)在遠程沙盒中，并能確保代碼運行結(jié)果的一致性是極具挑戰(zhàn)的。
Sualeh：我很好奇，你們（用戶）想要什么樣的編碼agent？幫助你們找到漏洞？還是實現(xiàn)一些新的功能？
Lex：編碼方面，我認為應(yīng)該去關(guān)注查找各種級別的bug，尤其是邏輯錯誤，以及實現(xiàn)方向上的錯誤。
Aman：這些模型在簡單地提示下并不善于尋找和發(fā)現(xiàn)錯誤。它們的校準非常差，即便是最聰明的模型o1也是如此。
Lex：您能解釋一下嗎？
Aman：我認為這些模型都能夠很好地反映預(yù)訓練數(shù)據(jù)的分布，隨著損失函數(shù)的降低，模型的泛化能力也在增強。但現(xiàn)在損失函數(shù)的降低已足夠多，以至于模型能夠?qū)崿F(xiàn)全面的泛化。我們主要在前沿領(lǐng)域使用模型，用它們進行代碼生成并對問題進行回答。在預(yù)訓練階段，GitHub上的大量代碼，數(shù)量高達數(shù)萬億個token，Stack Overflow和GitHub Issues等平臺上也有大量問題和答案，都為任務(wù)提供了豐富的數(shù)據(jù)。
但當你嘗試推動其中一些在網(wǎng)絡(luò)上并不常見的事情時，比如根據(jù)已有的編輯來預(yù)測下一個編輯的Cursor Tab目標，模型的脆弱性就會顯現(xiàn)出來。
另一個很好的例子是bug檢測，因為實際上并沒有太多真實的檢測bug并提出修復(fù)建議的例子，所以模型在這方面會遇到很大的困難。
但我認為，這同樣是一個模型遷移的問題，我們需要將其他模型遷移到Cursor Tab上，在將非常擅長代碼的通用模型遷移到bug檢測任務(wù)時，效果應(yīng)該也不錯，只是需要我們稍做引導(dǎo)。
Sualeh：很明顯，我認為模型非常了解代碼。當它們在預(yù)訓練過程中，或許已經(jīng)能夠粗略地察覺到代碼的問題所在。這是因為有些人已經(jīng)對這些錯誤進行了嚴格的校準。
但當用模型編程的時候，比如編寫數(shù)據(jù)庫，這是很龐大的數(shù)據(jù)信息，即便設(shè)置了很多嚴格的校準程序，可能錯誤也還是很難被修正。
十二、危險代碼標注存爭議，開發(fā)團隊并不看好賞金制度
Lex：人類也很難判斷代碼的重要性。如果某行代碼可能造成嚴重后果，應(yīng)該添加“這行代碼是危險的”這一注釋。
Arvid：全部大寫，重復(fù)十次
Lex：是的，即使是同一個人也可能會忘記單個代碼的危險性。
Arvid：我認為在一定程度上這也適用于今天的AI模型，如果你真的在每一行中都標注dangerous，dangerment，dangerous的話，模型也會更加關(guān)注這些，并且更有可能在該區(qū)域發(fā)現(xiàn)錯誤。
Lex：明確標注代碼的潛在危害程度是一種良好的實踐。
Arvid：但這種做法存在爭議，例如Sualeh就不太喜歡。
Sualeh：雖然從美學角度來看我不喜歡這種做法，但它確實對模型和容易遺忘代碼危險性的人們很有幫助，可以避免一些小的錯誤導(dǎo)致嚴重的情況，例如服務(wù)器宕機。
Aman：即使是普通的文檔字符中，人們在修改代碼時也經(jīng)常會忽略，因此需要明確指出潛在風險。
Lex：人們在修改代碼時往往只考慮如何改進功能，而忽略了潛在的風險。
Arvid：如果能夠?qū)λ写a進行形式化驗證，就可以確保不會引入bug。
Aman：這個設(shè)想中的未來具體會是什么樣子？
Arvid：我認為人們可能不再需要編寫測試了，模型會根據(jù)代碼自動生成規(guī)范，用戶只需審查規(guī)范。同時，智能推理模型會計算出代碼是否符合規(guī)范。這種方式適用于大多數(shù)函數(shù)。
Michael：規(guī)范的生真的容易嗎？為軟件明確人類的意圖是具有難度的，畢竟有些想法很難指定，也很難證明它是否真的能夠符合你的想法去執(zhí)行。
Arvid：您認為規(guī)范很難生成？
Michael：對于難以用規(guī)范語言描述的需求，形式驗證并不可靠。
Arvid：即使有大量的規(guī)范文檔也難以達成？
Michael：規(guī)范可以取代單元測試。
Arvid：但規(guī)范語言可以不斷發(fā)展，以涵蓋更多需求。
Lex：這一設(shè)想是否適用于整個代碼庫，而不僅僅是單個函數(shù)？
Arvid：的確，對整個代碼庫進行形式化驗證更難，但這是值得追求的目標，并且從理論上是可行的。例如，最近有一些研究可以對硬件進行形式化驗證，包括C代碼、GCC編譯器和Verilog硬件描述語言。大型代碼庫也類似于多層系統(tǒng)，如果可以分解并分別驗證每個部分，那么形式化驗證整個代碼庫應(yīng)該是可能的。不過，規(guī)范問題確實是個挑戰(zhàn)。
Aman：如何處理副作用和外部依賴？例如調(diào)用Stripe API？
Sualeh：Stripe為其API編寫了一個規(guī)范。
Aman：是否所有外部依賴都可以提供規(guī)范？例如，如果程序中使用了語言模型作為原語，如何將其納入形式化驗證？
Arvid：這也是可能的。
Aman：如何證明語言模型效果？
Arvid：可以證明語言模型的對齊性，或者證明它能夠給出正確的答案。
Sualeh：這是最終的夢想。
Lex：如果這能夠?qū)崿F(xiàn)，將有助于確保代碼的正確性和AI的安全性。
Lex：既然模型在bug查找方面存在困難，那么未來的希望在哪里？
Sualeh：希望模型首先能夠幫助發(fā)現(xiàn)一些簡單的bug，例如off-by-one錯誤或注釋與代碼不一致的情況。最終，模型應(yīng)該能夠發(fā)現(xiàn)更復(fù)雜的bug。
Michael：強大的bug查找模型對于實現(xiàn)AI編程至關(guān)重要。如果AI能夠自動生成代碼，那么也需要能夠驗證代碼的正確性。這不僅是為了幫助人類程序員，也是為了驗證AI生成的代碼。
Arvid：是的，但實際上是怎么做到的呢？有一個流行的想法是這樣的，引入bug比找到bug更容易，因此可以訓練一個模型并引入一些錯誤代碼，然后就可以訓練一個反向錯誤的模型，并用其中的合成數(shù)據(jù)去尋找錯誤。這是一個不錯的例子。
Michael：還可以利用大型模型和代碼之外的信息來輔助查找bug，例如通過代碼執(zhí)行軌跡和調(diào)試器信息。bug查找工具可能會有兩種不同的產(chǎn)品形態(tài)，其一是在后臺運行的快速模型，用于發(fā)現(xiàn)常見的bug。其二是用于解決特定bug的高計算量模型，用戶可以支付一定的費用去使用。
Lex：是否考慮過用資金將這些整合起來？如果模型能夠找到bug或生成高質(zhì)量的代碼，我愿意付費。前幾天，我用Cursor模型生成了三個完美的函數(shù)，主要用于與YouTube API交互，為我提供多語言字幕更新功能。
API文檔不是很好，而且有代碼交叉現(xiàn)象，我用谷歌搜索得不到確切信息，只有一些令人困惑的內(nèi)容，而Cursor生成得則非常完美。我想，真希望能有一個“打賞”按鈕，寫著“5美元”既可以支持公司發(fā)展，也可以向模型發(fā)送積極反饋信號比如“Good Job”。在bug查找中，也可以引入類似的賞金機制。你們有考慮嗎？
Arvid：公司內(nèi)部對此存在爭議。我認為在某種程度上，這取決于你對人性的信仰程度。我認為，如果你不花任何錢就找到一個bug那非常棒。如果沒發(fā)現(xiàn)錯誤，你就不用花錢，而如果你花錢并找到了一個bug，并且你要點擊的“接受”，那么它會顯示在括號中，比如1美元。
這會存在一種擔憂，比如，我們在計算中投入了很多，也許人們會復(fù)制粘貼代碼，或者付費機制會影響用戶的體驗。我認為，可以考慮把付費機制與產(chǎn)品進行分離，如果用戶每月支付一定的費用，就可以免費獲得所有的功能。
Lex：可以添加一個“打賞”功能，而不是強制收費。
Arvid：即使是打賞也涉及到金錢，可能會影響用戶體驗。
Aman：用戶在分享模型時，人們就已經(jīng)在表達對模型的認可了。
Michael：如果能夠開發(fā)出一種技術(shù)手段來驗證bug是否已被修復(fù)，那么就可以不必依賴那些依賴于榮譽系統(tǒng)的賞金機制了。
十三、AWS基礎(chǔ)設(shè)施非常可靠，出現(xiàn)問題的概率微乎其微
Lex：終端和代碼之間有多少交互？在終端中運行代碼可以獲得多少信息？是否可以實現(xiàn)一個循環(huán)，讓模型運行代碼并建議如何對代碼進行更改？目前代碼及其實際運行是完全分離的嗎？目前，據(jù)我所知是可以在終端中使用“Ctrl+K”來輔助進行代碼編寫。
Aman：可以在Check命令和Ctrl+K中使用終端上下文信息。但目前還沒有實現(xiàn)循環(huán)功能，不過這很有意義。關(guān)鍵問題在于，這個循環(huán)是在前臺進行還是像之前那樣在后臺進行。
Lex:后臺運行的確很酷，因為它可以支持不同的方式運行代碼。此外，還需要考慮數(shù)據(jù)庫方面的問題，例如如何防止模型修改數(shù)據(jù)庫。
Sualeh:有一個不錯的解決方案。即正在開發(fā)一個新的API，我認為PlanetScale和Turbopuffer數(shù)據(jù)庫都會支持這種功能。當你正在開發(fā)一個功能并對數(shù)據(jù)庫進行測試時，實際上你并不想針對廣泛的數(shù)據(jù)庫進行測試，你可以向數(shù)據(jù)庫添加一個分支，而不是去修改主數(shù)據(jù)庫。
這種技術(shù)的實現(xiàn)方式是為數(shù)據(jù)庫的預(yù)寫日志添加分支。數(shù)據(jù)庫公司需要不斷開發(fā)新功能，而分支功能可能成為未來的一個趨勢，AI agent也可以利用數(shù)據(jù)庫分支進行測試。
Lex：在此可以對基礎(chǔ)設(shè)施相關(guān)信息提出一些問題，Cursor團隊目前是主要使用AWS（亞馬遜云科技）嗎？在使用AWS的過程中，都遇到了什么挑戰(zhàn)？
Arvid：AWS非常出色，無論在何時使用它的產(chǎn)品總是能夠正常工作，雖然完成其設(shè)置過程可能超級麻煩。實話說，AWS確實值得信賴，如果出現(xiàn)問題，那很可能是你自己的問題。
十四、擴展問題是公司發(fā)展難關(guān)，隱私保護也亟待突破
Lex:Cursor作為一家初創(chuàng)公司，在發(fā)展中遇到了哪些挑戰(zhàn)？
Michael：隨著請求量級的不斷提升，緩存和數(shù)據(jù)庫等通用組件都會遇到瓶頸。例如，我們現(xiàn)在已經(jīng)遇到遇到了數(shù)據(jù)表溢出等問題。此外，我們構(gòu)建的一些定制系統(tǒng)，例如用于代碼語義索引和問答的檢索系統(tǒng)回答有關(guān)代碼庫的一些問題，我也一直認為這是比較棘手的擴展問題之一。
Sualeh：我的超級高級工程師朋友們說，在擴展過程中很難預(yù)測系統(tǒng)會在哪里崩潰。您可以提前嘗試預(yù)測，但是在添加這些額外的內(nèi)容時，總會發(fā)生一些奇怪的事情。具體而言，Cursor將所有的代碼進行分塊，然后發(fā)送代碼進行嵌入，然后將嵌入代碼儲存在數(shù)據(jù)庫中，但實際上，并不儲存任何代碼。此后就是我們要確保不引入客戶端bug，因為我們對這些bug非常嚴格，服務(wù)器上存儲了許多細節(jié)，一切都是加密的。
因此，技術(shù)挑戰(zhàn)之一就是如何確保本地代碼庫狀態(tài)與服務(wù)器端狀態(tài)保持一致。技術(shù)層面上來說，我們的做法是將對服務(wù)器端的哈希值進行下載，并對比本地的哈希值，計算差額，來確定缺少的文件是什么。但這會增加網(wǎng)絡(luò)開銷。如果您使用了Cursor，沒有人希望有人一直對WiFi施加操作。
而且，這也會對數(shù)據(jù)庫造成巨大開銷。它將讀取數(shù)十TB的數(shù)據(jù)庫，每秒鐘接近20TB或者更大的數(shù)據(jù)庫。這太瘋狂。為此，我們采用了Merkle樹結(jié)構(gòu)，只需要協(xié)調(diào)單個哈希，即項目的根節(jié)點，去查看哈希值不匹配的子項，并以此類推，可以極大地降低開銷。
但隨著使用人數(shù)的增多，代碼庫也變得格外龐大。最初，我們對暗代碼庫進行了重新排列，但如今其規(guī)模已經(jīng)遠不如一些擁有龐大文件的公司的規(guī)模了。建構(gòu)一個東西很簡單，但擴展到更多人、更多公司，這是個難題。我們也在努力解決這些問題。
Aman：的確，索引系統(tǒng)有很多需要琢磨的東西。實際上嵌入代碼才是瓶頸。為了避免重復(fù)嵌入同樣的代碼塊，我們采用了一種緩存機制，即將代碼塊的哈希值與對應(yīng)的向量緩存起來，這會使得一些公司，在使用Cursor時，代碼嵌入的速度會大大提升，用戶不需要儲存代碼數(shù)據(jù)，只存儲向量數(shù)即可。
Lex：目前，您認為代碼庫索引帶來的最大收益是什么？短期來看，代碼庫有什么用呢？
Arvid：最明顯的一點是，當你想找出大型代碼庫中特定的一些東西時，你可以通過模糊性的提問來進行搜索。比如“我想找到執(zhí)行X功能的地方。”但是你并不知道在文本搜索中要輸出什么語言。你只需要請求聊天，按照enter命令來詢問代碼庫進行聊天。很多時候，模型通常都能夠給你提供正確位置。
Lex：為什么Cursor不考慮在本地進行代碼嵌入等操作？
Arvid：我們也考慮過這種方案，但實現(xiàn)起來很困難。一些用戶使用的是最新的MacBook Pro，但超過80%的用戶用的是Windows機器，其中許多機器功能并不是非常強大，實際上，本地模型實際僅適用于最新的計算機，并且構(gòu)建過程也會出現(xiàn)很大的開銷。因此，即使我們向這樣做，但也還是很難做得到。
Aman：是的，龐大的數(shù)據(jù)庫只會消耗大量的內(nèi)存與CPU。此外，正如Arvid所說的那樣，本地模型建設(shè)存在著巨大阻力，其中似乎都在朝著MOE架構(gòu)發(fā)展，雖然MOE模型對內(nèi)存帶寬的要求更高，并且有利于本地運行，但整體模型的規(guī)模也會變得更大，需要更多臺機器才能運行。我認為，對于編碼生成而言，用戶希望能夠用到最好、最聰明、最有能力的模型，但在本地實現(xiàn)卻很困難。
Arvid：實際上我很喜歡本地模式的替代方案。我認為，它仍然處于研究階段，可以把它想象成，為語言模型推理進行同態(tài)加密。用戶可以在本地加密輸入的數(shù)據(jù)，然后發(fā)送給服務(wù)器進行推理。服務(wù)器可以可以對加密數(shù)據(jù)進行處理，但無法讀取數(shù)據(jù)的具體內(nèi)容，此后服務(wù)器會把答案發(fā)回給用戶并進行加密處理，用戶只能通過解密查看返還的內(nèi)容。目前同態(tài)加密的成本依然很大，如果能夠降低成本，我相信這會非常值得期待。
世界上有越來越多的信息和數(shù)據(jù)將流經(jīng)兩個中心化的參與者，但這會有些令人擔憂，比如傳統(tǒng)黑客的入侵，這是非�？膳碌摹Ｓ脩艨赡軙缓诳捅O(jiān)控。人們努力防止不良入侵者使用AI模型，繼而引入一些監(jiān)控機制，但這些監(jiān)控機制又可能被濫用，比如用戶的數(shù)據(jù)可能會被監(jiān)控。所以我們希望，我們可以解決同態(tài)加密問題。
Lex：我想說，這是所有軟件都面臨的挑戰(zhàn)。就像云可以提供很多便利的功能，人們就越來越依賴它，但是它也存在缺點，這就是為什么需要依靠強大的安全措施來抵御一些攻擊。但是也又一些具有影響力的公司控制著這些數(shù)據(jù)，這就是我們存在著的現(xiàn)實生活。
Sualeh：是的，我非常擔心。例如Anthropic公司有這種負責任的擴展政策，其中我們是低級別的，當我們進入高級別時，任何模型都會出于合理的安全原因，都會希望對監(jiān)控有所提示。我認為這是合理的，但也存在一些弊端，如果所有信息都被見監(jiān)控，那會非常可怕。
Aman：您認為它（AI模型監(jiān)控）與云服務(wù)供應(yīng)商有何不同？
Arvid：我認為很多數(shù)據(jù)一開始并不會流向云供應(yīng)商，而通常你會把更多的數(shù)據(jù)提供給AI。一開始用戶并不會把自己的數(shù)據(jù)都放在網(wǎng)絡(luò)上，給那些公司或者模型。但現(xiàn)在AI模型的監(jiān)控更加集中，云服務(wù)中的用戶都可以使用加密密鑰，而AWS對此卻無能為力，但在這里只有中心化AI模型提供商才能夠看到確切的文本內(nèi)容。
十五、關(guān)于上下文訓練中關(guān)于上下文和模型訓練的探討
Lex：在使用Cursor時遇到的一個問題，當我在Python中寫代碼的時候，會導(dǎo)入一些內(nèi)容，模型怎么知道我想在上下文中提到哪些內(nèi)容，弄清楚這一點有多困難？
Michael：我認為我們將來可以在自動計算上下文方面做的更好。需要注意的是，包含自動上下文需要權(quán)衡取舍。因此，你為這些模型包含的上下文愈多，其速度就越慢，這些請求的成本的就越高，這意味著，你可以調(diào)用的模型就會越來越少。此外，對于這類模型來說，如果提示中包含了太多信息，它們會覺得困惑。因此，在上下文中呈現(xiàn)出的信息準確性和相關(guān)性的標準要十分高，我們也希望能夠做得更好。
我們在內(nèi)部也嘗試過一些改進措施，但目前該領(lǐng)域還存在一些問題。讓語言模型真正達到理解新信息語料庫？上下文窗口能否無限擴展？模型能夠真正做到關(guān)注無限的上下文嗎？能夠?qū)@些上下文進行緩存而不必重復(fù)計算嗎？還有很多想法都在嘗試中，這些想法類似于在模型權(quán)重學習過程中進行微調(diào)。同時作為一家公司，我們很高興可以擁有更好的檢索系統(tǒng)，也希望可以做的更好。
Aman：一個有趣證明是VSCode（跨平臺源代碼編輯器）。
我們處于一個分叉節(jié)點。VS Code的代碼是開源的，大型語言模型在預(yù)訓練過程中已經(jīng)見過這些代碼，并且經(jīng)過微調(diào)和RLHF（人類反饋）訓練，能夠回答與代碼相關(guān)的問題。因此，當用戶詢問關(guān)于VS Code的問題時，模型有時能夠給出正確的答案，盡管有時也會出現(xiàn)誤差。如果能夠訓練一個專門的模型并成立一個理解這些問題的代碼庫，這會很有研究價值。
另外，我們對于一個開放性的研究問題充滿興趣，同時也存在著不確定性，即用戶是希望模型在前端執(zhí)行完所有任務(wù)，還是將檢索與代碼生成進行分離？未來的幾個月，可能會出現(xiàn)一些真正有能力的模型，此后用戶可以單獨訓練一個非常優(yōu)秀的開源模型并將其作為檢索器，在上下文中為這些更大的模型提供信息。
Lex：如何針對特定代碼庫進行模型訓練？
Aman：有很多方法可以嘗試，需要通過嘗試確定效果。一件非常幼稚的事情，是嘗試復(fù)制VS Code和一些前沿模型做過的事情。所以我們應(yīng)該繼續(xù)進行預(yù)訓練。某種持續(xù)的預(yù)訓練，在繼續(xù)預(yù)訓練階段加入特定代碼庫的數(shù)據(jù)，并在指令微調(diào)階段加入關(guān)于該代碼庫的問題。我們從指令微調(diào)開始，建立一個關(guān)于代碼的常規(guī)指令微調(diào)數(shù)據(jù)集，繼而拋出更多關(guān)于該存儲庫中的代碼問題。
你可以獲取更多難以獲得的真實據(jù)，或者可以使用合成數(shù)據(jù)來執(zhí)行一些操作，讓模型對代碼各種新構(gòu)成部分提出問題。因此，獲取代碼片段，并讓模型對此提出問題，再將其添加到指令中對數(shù)據(jù)點進行微調(diào)，從理論上講，這一過程可能會解鎖模型理解該代碼庫問題的能力。
▲播客現(xiàn)場（來源：YouTube）
十六、與OpenAI o1競爭靠什么？
Lex：想問一些關(guān)于OpenAI o1的問題，您認為測試計算系統(tǒng)在編程中的作用是什么？
Aman：我認為測試時間計算非常有趣。因此，隨著數(shù)據(jù)量和模型大小的擴張，預(yù)訓練制度將使損失函數(shù)和下游任務(wù)中的表現(xiàn)越來越好。但是，我們正在面臨一些數(shù)據(jù)壁壘。這意味著，繼續(xù)擴大數(shù)據(jù)規(guī)模變得更加困難。
因此，擴大測試時間計算是一種有趣的方法，如果現(xiàn)在增加我們使用推理時間的flop計算數(shù)量，使用Infer Time時，這些模型總是會有更多的flop，但現(xiàn)在，我們也許可以使用相同大小的模型并運行更長時間，并獲得與更大模型規(guī)模相當?shù)幕貓蟆?/p>
某些查詢可能需要100萬億參數(shù)規(guī)模的模型才能處理，但這類查詢可能只占所有查詢的0.1%。在這種情況下，也許有些浪費精力。而訓練一個能夠處理99.9%查詢的模型，然后可以采用一種方法為那些真正想要更高智能查詢的人延長推理時間。
Lex：如何判斷哪些問題需要更高水平的智能？是否能夠動態(tài)地在GPT-4與o1使用之間進行切換？
Aman：確實這是一個問題，也沒有人真正很好地解決它。團隊在Cursor Tab功能中實現(xiàn)了簡單的模型路由，但在GPT-4和o1之間的切換還比較困難。另外，需要什么級別的AI來確定對于司機模型是否太難，可能需要o1模型，但這很難說得清楚。
此外，還需要考慮如何判斷某個問題對GPT-4來說是否過難，這可能需要o1級別的模型才能判斷。
測試時間計算需要一個完整的訓練策略才能正常執(zhí)行。此外，在大型實驗室之外，可能只有OpenAI，但沒人知道它是如何工作的，有一些非常有趣的論文顯示了它們可能提供了怎樣的暗示。因此測試時計算可以歸類為后訓練階段，但未來用于訓練支持測試時計算的模型的算力可能會超過預(yù)訓練階段。
Lex：如果要構(gòu)建一個與o1競爭的模型，應(yīng)該怎么做？
Aman：也許我們可以訓練一個流程獎勵模型。其中有結(jié)果獎勵模型和過程獎勵模型的區(qū)分，結(jié)果獎勵模型是人們接受語言建模訓練的傳統(tǒng)獎勵模型，它更重視最終結(jié)果。過程獎勵模型則需要對思維鏈進行層層劃分。OpenAI去年發(fā)表了一篇關(guān)于過程獎勵模型的論文，他們使用人工標注的數(shù)據(jù)集訓練了一個過程獎勵模型。
目前，過程獎勵模型主要用于從多個模型輸出中選擇最佳答案，但還看不出什么特別優(yōu)秀的地方。眾多的學術(shù)成果中，人們要做的是從語言模型中抽取一些輸出數(shù)據(jù)，然后使用過程獎勵模型對這些進行賦分，繼而選出最佳答案。未來，人們就是使用流程獎勵模型及其樹狀結(jié)構(gòu)，探索思維鏈的多個分支，繼而評估分支的質(zhì)量。
Lex：當分支質(zhì)量與結(jié)果質(zhì)量密切相關(guān)時，就能夠幫助模型選擇用哪個分支更好？
Aman：是的，我認為也許人們討論開源模型訓練流程獎勵模型時，采用的是更自動化的方式。但目前我并未看到任何東西能夠創(chuàng)造性地使用流程獎勵模型來進行樹狀結(jié)構(gòu)搜索和編碼。
Lex：有一個AI安全問題，它更像是哲學問題。OpenAI曾說，他們向用戶隱藏了思維鏈，這是個艱難的決定，他們會在后臺對思維鏈進行監(jiān)控，以此確保模型不會試圖對用戶產(chǎn)生干擾，這確實令人震撼。但你們對于隱藏思維鏈這件事有何看法呢？
Michael：我推測，OpenAI可能是為了防止別人從他們的模型中竊取他們的技術(shù)。如果你能夠詳細看到思維鏈的每個步驟，那這個技術(shù)就更容易被獲齲
Lex：所以你也可以用這個來訓練嗎？
Michael：可能大語言模型供應(yīng)商之間會存在這樣的情況，其中一切API曾經(jīng)提供了他們的所有記錄概率的訪問權(quán)限，但后來又取消了。其中的原因可能就在于，那些訪問了記錄概率的人，可以竊取到模型的技術(shù)信息。
同時我們也集成o1到Cursor之中，對于o1我們也有濃厚的興趣，并且我覺得很多程序員也都對此充滿期待。但無論如何，o1都不是Cursor默認體驗的一部分，目前我們還沒有找到將其集成到編輯器中的有效方式。所以我認為，如何和使用這個模型（o1），還是個未知數(shù)。
Sualeh：我們有一些美好想法，但需要找在發(fā)布之前獲得一些適用的場景。
Aman：o1模型還存在很多限制，比如不支持流式輸出，這意味著用戶無法對輸出過程進行監(jiān)督，只能等待文本的出現(xiàn)。另外，它技術(shù)發(fā)展還處于早期階段，有很多需要改進的地方，未來會在增加預(yù)訓練數(shù)據(jù)量，擴大模型體量的同時，讓搜索工作也變得越來越好。
Lex：GitHub Copilot似乎正在以某種方式集成o1模型，有人認為這意味著Cursor要完了？
Michael：我認為這個領(lǐng)域與2010年代的軟件領(lǐng)域有所不同，此處天花板真的非常非常高，所以我認為，三到四年內(nèi)最好的產(chǎn)品很快就會比今天最好的產(chǎn)品更優(yōu)秀。我認為即便擁有一個很好的品牌，但不去創(chuàng)新未來還是會失敗。接下來幾年我認為，關(guān)鍵在于建構(gòu)最好的產(chǎn)品與系統(tǒng)，這需要歸結(jié)于建模引擎與編輯體驗。
Aman：是的，我認為Cursor的優(yōu)勢在于其不僅僅是快速集成新模型就像o1那樣，同時它也是深度定制的模型，并且很重視用戶體驗。
十七、詳刨三類合成數(shù)據(jù)分類法
Lex：您能解釋一下，合成數(shù)據(jù)分類法是什么嗎？
Aman：合成數(shù)據(jù)是可以從AI中獲得的一些數(shù)據(jù)，我認為合成數(shù)據(jù)主要有三種。第一類是蒸餾，包括語言模型、輸出token或token的概率分布，可以用來訓練能力較弱的模型。這種方法無法生成比原始模型更強大的模型，但可以將昂貴的高延遲模型的能力提取到較小或執(zhí)行特定任務(wù)的模型中。
第二類是合成數(shù)據(jù)利用了某些問題中一個方向比另一個方向更容易的特點。例如，在bug檢測問題中，引入bug比檢測bug更容易。我們需要做的是，在一個未經(jīng)充分訓練的模型中引入一些bug，然后用這些合成數(shù)據(jù)訓練一個擅長檢測bug的模型。
最后一類，是使用語言模型生成可以輕松驗證的文本。比如，想對系統(tǒng)進行驗證，檢測語言是否能夠達到莎士比亞的水平，你可以讓猴子或者打字機去打字，最終就能夠獲得充分的訓練數(shù)據(jù)來培養(yǎng)一個莎士比亞級別的語言模型。
對于具體的引導(dǎo)代碼的代碼，可以通過測試結(jié)果來判斷這個測試代碼是否合格，我們也可以使用模型生成、通過測試的代碼來對模型進行訓練。但我認為這種方法很難產(chǎn)生實際效用，在開放式任務(wù)或者復(fù)雜任務(wù)中，很難找到完美的驗證器。
十八、人類反饋聯(lián)動AI反饋，共同提升模型訓練效果
Lex：人類反饋的強化學習（RLHF）和AI反饋的強化學習（RLAIF）相比而言如何？對AI模型性能提升都有什么作用？
Aman：RLHF是根據(jù)人類反饋信息來進行訓練的，我認為，如果能夠為專注的任務(wù)提供充分的人類反饋那么效果會非常不錯。
RLAIF則比較有趣，它根據(jù)約束條件執(zhí)行工作，比如使用語言模型來驗證解決方案比生成一個解決方案要容易，它更容易奏效，因為RLAIF可以實現(xiàn)一種遞歸循環(huán)。
我們可以將二者進行結(jié)合，在兩者之間選擇一個平衡點，比如在模型生成的正確代碼中，加入少量的人工反饋，大概50-100個示例，就能夠讓模型的先驗內(nèi)容與我們的構(gòu)想實現(xiàn)一致。
這看起來與普通的RLHF不同，普通的RLHF通常需要大量的示例對獎勵模型進行訓練。
十九、AI會在實現(xiàn)AGI前獲菲爾茨獎？
Lex：根據(jù)你的直覺，生成與驗證或者生成與排序哪個更容易呢？
Aman：根據(jù)直覺而言…可能是這樣的…既定情況下驗證更容易，而非找到證明。
Sualeh：AI獲得菲爾茲獎的可能性有多大？
Sualeh和Arvid：AI更容易獲得菲爾茨獎。
Aman：雖然AI已經(jīng)解決了許多難題，但現(xiàn)在還不確定定理證明領(lǐng)域中AI效用如何。其次，對于我們距離解決這些非常非常難的開放性問題還有多遠，我的直覺也不那么準確了。
Lex：你認為AI會先獲得菲爾茲獎嗎？而不是物理學或其他的什么。
Sualeh：我認為百分之一百是會獲得菲爾茨獎的。我覺得，一些奧數(shù)難題，比如伯奇和斯溫納頓-戴德（Birch and Swinnerton-Dyer conjecture）猜想對于AI而言還是非常難的，現(xiàn)在還并不知道如何去解決這些問題。
Aman：AI可能會在實現(xiàn)AGI之前就獲得菲爾茨獎。
Sualeh：如果能獲得，我會非常開心的，我覺得，可能在2028或者2030年就會實現(xiàn)吧。
二十、談縮放規(guī)律的未來，“模型越大越好”觀念已失效
Lex：談到縮放規(guī)律（scaling laws）的話題，大家可以就此談一下自己看法，對于現(xiàn)狀以及未來的發(fā)展有何看法？
Aman：最初OpenAI關(guān)于縮放規(guī)律的論文存在一些錯誤。他們提到了關(guān)于優(yōu)化學習效率的問題。后來，Chinchilla的論文提到了一個更準確的版本。自那時起，人們開始不再專注于計算優(yōu)化，而是更加關(guān)注在有限的推理預(yù)算下獲得更優(yōu)異的效果。
Aman：我認為，這些縮放規(guī)律曲線的維度遠比我們最初僅用于計算參數(shù)數(shù)量和數(shù)據(jù)的維度要豐富得多。比如，推理計算就是一個顯而易見的維度。我認為，上下文長度是另一個明顯的維度。假設(shè)我們關(guān)注推理計算和上下文窗口這兩個方面，也許我們想要訓練的是某種狀態(tài)空間模型（SSM）。
它們在處理超長上下文時，成本要低得多，速度也要快得多。即使訓練時的擴展屬性可能需要10倍的計算量，也就是說，需要花費10倍的計算資源來訓練模型，以達到相同的能力水平，但這也是值得的。因為我們最關(guān)心的是超長上下文窗口下的推理成本預(yù)算。因此，人們未來將會這些維度上進行探索。
Lex：你覺得大家是否還在相信“越大越好”這一理念？
Aman：對于原始性能和原始AI來說，更大的模型肯定更好。我認為，人們還是會更看好蒸餾技術(shù)。如果我們投入大量、大量的資金進行訓練，以獲得最具性價比的模型，那么我們可以調(diào)整多少個參數(shù)呢？
這一點確實值得關(guān)注。因為僅僅在推理時間上盡可能多地投入計算，這種天真的做法，人們已經(jīng)在Llama模型上嘗試過了。或者，僅僅是對7B（70億參數(shù)）模型進行過度訓練，使用的token數(shù)量也遠遠超過了最優(yōu)需求。
但是，如果你真的在意這件事，也許我們可以像Gamma所做的那樣，不僅僅是在token上進行訓練，而是實實在在地通過最小化與Gemma 27B分布的KL散度來進行訓練，這就涉及到了知識蒸餾。實際上是在所有這些token上，花費計算資源來訓練這個擁有270億參數(shù)的模型，然后將其中的內(nèi)容蒸餾到一個更小的模型中。
Lex：蒸餾只給你一個更快的模型，越小意味著越快？
Aman：我認為，蒸餾在理論上是從你正在訓練的數(shù)據(jù)中提取更多的信號。這可能是另一種方法，不是完全克服數(shù)據(jù)墻，而是部分地幫助我們克服數(shù)據(jù)墻�？梢杂柧毜臄�(shù)據(jù)有限，讓我們用所有這些token來訓練這個非常大的模型，然后我們將它蒸餾成這個較小的模型。相比于我們自己去訓練模型，蒸餾能夠讓模型獲得更多的信號。
Lex：如果給你們10萬億美元的預(yù)算，你們會如何做？
Aman：我認為有很多關(guān)于訓練這些大型模型的秘密和細節(jié)，只有大型實驗室才知道。即使我努力去做，也會浪費很多錢。
Lex：假設(shè)獲得所有信息，包括訓練參數(shù)以及方式方法，未來五年中你會如何投資才能使你們所說的原始AI實現(xiàn)最大化？
Sualeh：我覺得，答案很簡單。你只需盡可能地購買足夠多的計算機，此后每一天所要做的就是購買GPU，研究人員就可以根據(jù)目標來選擇去訓練大模型還是小模型了。
Aman：這涉及到一個問題，我們是真的受到計算和金錢的限制，還是受到其他什么制約？
Sualeh：更多是受限于自身觀念吧，但也存在其他一些限制因素。
Lex：你們會選擇進行大量的實驗還是選擇使用這些計算資源來訓練一個巨大的模型？
Arvid：可能會選擇通過實驗，我覺得現(xiàn)在我們?nèi)允芟抻谖覀兡壳八钟械挠^念。
Aman：我認為是這樣的，因為即便擁有了世界上所有的計算能力和可收集的數(shù)據(jù)，最終還是會受到限制，而且限制的不僅僅是想法，是受制于更卓越的工程技術(shù)。即便擁有世界上所有的資金，真正能在這里有所作為的人并不多。
研究工作中包含大量純粹的、極其艱難的工程技術(shù)工作。舉個例子來說，如果你看看原始的Transformer論文，將文獻中嵌入的許多非常有趣的概念融合在一起，而且還需要編碼，這些過程，都需要杰出的工程師來完成，就像GNOME Azure。
進一步說，讓下一代模型進行并行化工作，這需要龐大的工程量，我認為要讓所有這些事情都奏效，需要投入大量的工程技術(shù)工作。比如，能夠?qū)⒐こ掏度氤杀窘档?0倍，讓那些擁有美好想法的人真地實現(xiàn)那些結(jié)構(gòu)，提升40%到50%的GPU的利用率，那研究工作的效率可能會大幅提升。
Sualeh：如果能夠看到一個清晰的改進路線，那么結(jié)果就會唾手可得。我認為，可能OpenAI和其他一些實驗室的做法是對的，它們抓住了這些成果。比如，GPT-4.25�，F(xiàn)有方法是有效的，那就不需要考慮創(chuàng)新，只有當現(xiàn)在遇到瓶頸時，才需要創(chuàng)新。我認為，如果擁有10萬億美元的預(yù)算，也許實際上會先去擴大規(guī)模，然后再對自身的觀念進行更新。
只要現(xiàn)有的方法有效，就沒有必要嘗試新的想法。只有當現(xiàn)有方法遇到瓶頸時，才需要新的想法。如果擁有10萬億美元的預(yù)算，那么可以先嘗試擴大規(guī)模，然后重新評估想法。
Aman：我們都相信，去實現(xiàn)AGI需要全新的觀念。我們也相信，可以在更小的規(guī)模內(nèi)去測試一些新的觀念，而且我們有信心這會奏效。對于當前的實驗室而言，將有限的研究和開發(fā)人才投注到開發(fā)其他的新想法之中是十分困難的，畢竟現(xiàn)存方案在未來較長時間都有效。
二十一、談編程未來，仍需程序員領(lǐng)航
Lex：你們現(xiàn)在處于編程世界的中心。你們認為編程，編程的本質(zhì)在未來幾個月，在未來幾年，甚至十年會發(fā)生什么變化？
Michael：我認為，我們對未來充滿期待，因為程序員在很長一段時間內(nèi)都坐在“歷史的駕駛座”上。我們曾談到過這個問題，這需要程序員有著高效、代理能力與控制能力，他們可以修改任何你想修改的東西，并且對你構(gòu)建的內(nèi)容進行快速迭代優(yōu)化。
此處，與“同計算機對話形的編程”有差別，與計算機對話，就好比你在Slack上與工程部門或工程師進行交談一樣，輸入需求到一個獨立的文本框，AI就會自動為你完成這些工作。但這也有些問題，首先會有延遲性，其次這也意味著放棄了一些控制力。
從根本上說，工程實際的執(zhí)行情況，是根據(jù)你構(gòu)建的細微決策來進行的，其中人的關(guān)鍵作用是不能被AI取代的，要讓人類坐在“駕駛位”來掌舵。
而未來編程的情況，很可能是程序員可以控制代碼庫的抽象級別，可以通過觀察偽代碼的形式對代碼庫進行編輯。而且程序員也可對編程軟件的邏輯進行修改，保留其控制權(quán)，這樣可以大幅度提升生產(chǎn)力。
但這只是一個模糊的想法，還需要很多細節(jié)需要解決，最終能否實現(xiàn)還有待觀察。但是人本身的控制力、效率以及以人為中心觀念是非常重要的。我們認為，對于一些像Arvid之前提到一樣，某些編程，可以把它交給聊天機器人。但大多數(shù)編程任務(wù)仍需要人深度參與。
Lex：編程的基本技能是否會發(fā)生根本性的變化？
Michael：實際上，我認為現(xiàn)在是開發(fā)軟件非常令人興奮的時刻。不管什么時候，很多代碼依然還是需要查閱很多難以理解的信息。但今天的編程比過去有趣多了，人們開始享受編程�，F(xiàn)在的編程讓人具備快速構(gòu)建事物的能力，人們的控制力也被極大提升了。
對于那些編程人員來說，這也是個充滿意義的時期，人們的創(chuàng)意和趣味會被放大，如果你是程序員，那今天應(yīng)該更加注意這部分的特殊性。
Arvid：我也同意，最近我們正對代碼庫進行一次比較大的遷移，將Node.js中的Async Local Storage替換為 Context對象。即使可以借助AI，這個工作也依然需要我與另一個工程師耗費大概五天的時間。不過未來，我們可能只需要給AI展示幾個例子，然后這個遷移任務(wù)，就可以在10分鐘內(nèi)完成。程序員可以借助AI更快的工作，而不需要在事先就考慮太多，而且任何事情，其實都可以先去嘗試新方法，嘗試的成本并不高。
Aman：我覺得在編程中有兩種方式，其一是努力思考，仔細尋找解決問題的最佳方法然后用有限時間來驗證。其二是直接執(zhí)行代碼，看是如何執(zhí)行的并就此進行更新。我也更認同后一個方案。
Lex：那對于現(xiàn)在想要學習編程的人而言，你們有什么建議呢？應(yīng)該學習什么？比如Java亦或者PHP？
Aman：我認為，每個人都有學習編程的自身原因。但我覺得，實際上那些真的熱愛編程的人，會是最好的程序員。在我們團隊內(nèi)部，很多人在工作后依然會用Cursor編寫自己的編程，有的人甚至會熬到凌晨三點去做這件事。當他們難過的時候，還會說“我需要寫點代碼。”來寬慰自己。
這種對編碼的熱愛，驅(qū)使他們成為了最好的程序員，我也認為這些人將會認真投入到那些他們研究的事物之中。我認為，未來的編程者們需要會更多地關(guān)注“你想要創(chuàng)造什么”。
Sualeh：程序員可以通過更豐富的方式表達自己的意圖。
結(jié)語：共建人機協(xié)同體系，改善程序員生活
Lex最后運用Cursor團隊的宣言為本次談話做出總結(jié)，在《工程天才》中他們說“我們是一個應(yīng)用研究實驗室，構(gòu)建不可思議的生產(chǎn)性人機協(xié)同系統(tǒng)。”
宣言中寫道：“首先，我們正在培養(yǎng)未來的工程師，即人類AI程序員這比任何一個工程師的效率都高出一個數(shù)量級。這種混合型工程師可以輕松地控制代碼庫，并且無需進行低熵鍵盤操作。即使在最復(fù)雜的系統(tǒng)中，他們也會以判斷的速度迭代。通過結(jié)合AI和人類智慧，他們將比最好的純AI系統(tǒng)更聰明、更工程化。我們是一群研究人員和工程師。我們構(gòu)建軟件和模型，在有效性和可能性基礎(chǔ)上進行發(fā)明。我們的工作已經(jīng)改善了成千上萬程序員的生活。”
Lex稱，在這個談話中，至少讓編程更有趣了。
來源：YouTube
