三萬字實錄對話矽谷頂尖研究員：General Agent是偽命題；Agent的互動設計是關鍵

原文出自 張無常, 2025年01月15日
https://mp.weixin.qq.com/s/7XcdAvI6rROyzrGgM_6K2Q

無常按：　

2025年被許多人視為Agent 之年，確實值得多關注。今天分享的這篇，應該是全網關於Agent話題最深入的討論了，大概沒有之一，從前沿研究、互動設計到產品落地，全文超過三萬字，一篇看明白。

核心觀點

超4000 字人工提煉，實在沒時間可以先讀核心觀點，但仍然非常建議閱讀全文。

關於Agent

• Agent本質上由三個部分組成：action space、decision making 和memory。
• • action space 是選擇什麼樣的工具來交互，如何設計interface，以及如何進行internal reasoning。
  • decision making可以透過planning來實現更複雜的決策。我們不只是直接產生單一動作，而是可以在腦中模擬多個可能的動作並評估它們。就像下棋一樣，我可以預測如果我這樣走，對手會怎麼應對這樣的互動過程。
• Agent最重要的兩個能力
• • 一是獲取資訊的能力，無論是透過web還是透過RAG
  • 二是自我驗證的能力，就是執行和測試。
• General agent是個偽命題
• • 因為很難真正產生價值。表面上看能幫你做很多事情，但首先系統穩定性是個問題。其次，如果要處理真正複雜的事務，光靠API是不夠的，需要中間的agent來管理工作流程。而且你要解決的問題越廣泛，就越難讓它真正好用。需要人機互動才能真正發揮作用。
  • 需求定義越明確，完成的成功率就越高；需求越abstract，就越需要interactive的步驟和手動介入。所以Replit對agent的思路是把它定位為協作夥伴，不是簡單地交付任務給它。
• Agent 像是把多個LLM 當成API 呼叫並組合成一個端對端的應用，但體驗前所未有：不穩定、需要持續迭代、需要使用者長時間等待。因此如何讓使用者能夠與Agent良好互動並獲得價值，需要複雜設計
• • 產品化和做research是完全不同的事。雖然在研究層面看起來不錯，但要做成用戶能用的產品，需要更多產品層面的思考。
  • agent與其他AI產品有很大的差別，首先是一個iterative(迭代)的過程，使用者需要耐心等待，而這個產品形態是前所未有的。
  • 與傳統軟體API相比，一個LLM相當於以前的一個API call ，而現在的agent更像是把這些API組合成一個end to end的軟體。但前所未有的是可能需要等待十分鐘才能得到回饋。
  • agent還有一個特點是不穩定，它無法達到90%甚至80%、70%的準確率，更不用說傳統軟體追求的99.9%的穩定性。
  • 面對這樣一個軟體，如何讓使用者能夠良好互動並獲得價值，需要複雜的設計。
• 怎麼定義multi agent system？為什麼我們需要它？
• • 本質上是個inference time scaling的邏輯。我們最終希望在inference時用更多compute來獲得更好效果，增加agent數量就是scaling up的一種方式。不過現在base agent還不夠強，要等它達到一定水準後，multi agent的scaling才會真正發揮作用。就像團隊合作，如果大家都很菜，人越多越亂；但如果都夠強，兩個人可能比一個人效率快兩倍，三個人可能再快1.5倍。
  • multi agent其實有兩種不同定義：第一種是多個agent做同一件事，第二種是不同agent負責不同任務。例如MetaGPT這個項目，它模擬了一個完整的公司架構，有CEO、PM、程式設計師、reviewer，每個角色都有不同的prompt。在我們的設定裡，使用者和agent都是第一公民，這是很重要的理念。但這更像是一個multi prompt（甚至有點像人格分裂的Agent），並不像一個multi agent。
• SWE Agent 與Agent Computer Interface（ACI）：如果把interface design和agent design結合在一起，也就是使用GPT-4也應該能達到比現在更好的效果
• • 軟體開發本質上是一個fundamentally interactive（根本上互動）的過程
  • 人類使用的Visual Studio Code、vim或Emacs這些都是Human Computer Interface（HCI），我們投入大量時間去打磨這些工具。但這些工具可能不適合agent 。傳統上都是固定environment讓agent變得更好，例如Atari遊戲。
  • SWE Agent 提出 Agent Computer Interface（ACI），採取相反思路：固定一個簡單的ReAct agent，專注於打磨environment 。最終會有一些co-design ，但核心是如何設計最適合agent的interface 。
  • 和AutoGPT和baby AGI這類系統的差異？AutoGPT和baby AGI這類系統試圖把agent本身做得非常複雜，使用各種prompting方法、planning、reflection等技巧。但它們的environment其實很簡單，想做一個通用的agent，但效果不是特別好。 SWE Agent的philosophy是，如果我們知道要做什麼task，就可以針對性地優化工具和environment，讓相對簡單的agent提升performance。
  • 和Devin的差異？ Devin是一個產品，SWE agent是研究計畫。 Devin是在標準environment下的複雜agent。SWE agent只是一個簡單的agent加上初步優化的interface 。
  • Agent的效果並不完全依賴模型的效果：如果把interface design和agent design結合在一起，即使用GPT-4也應該能達到更好的效果。
  • Language model很像當年的GPU ，最初只是個text generator，但大家用它做各種事情時發現了很多令人驚訝的能力。所以我覺得下一步應該把model和agent進行co-design，把agent的experience和數據反過來fine-tune model。

關於RAG

• RAG為什麼重要？ LLM-based 產品必須了解使用者的codebase（上下文）
• • 在現實工作中，無論你做什麼工作，都會面對一個巨大的codebase。所以第一，產品必須真正懂你的整個codebase ，因此retrieval特別重要，因為這些程式碼不會出現在Foundation模型的訓練資料中。第二，產品feature必須能融入使用者的工作流程。對於professional用戶來說，他們已經有了自己的工作方式，這就是為什麼程式碼補全這麼受歡迎，因為它對工作流程的改變最小，用起來也很簡單。最重要的就是要在一個巨大的codebase裡做一個好用的工具。
• RAG為什麼難？
• • 目前企業RAG系統準確率最多大概只有70%-80%，達不到過往軟體生產環境99.9%甚至更高的要求。RAG的困難是評估evaluation ，甚至連標註都很難。關鍵是要先思考準確率本身的意義，就是top K的問題，可能是第一個結果準確，也可能是前十個結果都準確，這其實很像Google search的問題。Google search就是全世界最大的Retrieval系統。
  • 指望文本embedding能在大量候選項中找出最佳匹配是非常難的，這不僅是embedding好壞的問題，而是對它的期望過高了。例如推薦系統，TikTok用用戶embedding去retrieve最接近的影片embedding，這種關聯是由使用者行為驗證的。 Google的ranking也是基於使用者點擊形成的系統。但常用的RAG方式是基於文字意義來建構embedding，不是一個閉環系統。
• 長上下文long context能取代RAG嗎？
• • 短期看不可能，因為long context太慢了。長期看呢？也很難，為什麼？首先你總是需要獲取用戶更多資訊的，但又不可能把所有資訊都輸入進去，所以需要RAG。再說了，就算你把所有資訊都輸入為上下文，那也必須有一個選擇最相關內容的過程，那這個選擇過程其實就是Retrival，就是RAG。

關於研究

• 研究就是要minimize human factor，但product本質上就是all about human 。
• Chain-of-Thought 和Tree-of-Thought
• • Chain-of-Thought這篇paper的核心思想是，如果我們把next token prediction看作是一個system one的快速過程，那麼對於system two這種慢思考來說，它其實是一個對system one的控制。
  • Tree of thought的本質是透過tree search這樣的控制機制來control system one ，而不是去取代它，而是去對系統施加控制
• 理解模型能力的2個維度：推進能力前沿push frontier、實現使用者價值help people
• • 現有模型的強大能力並沒有真正傳遞到使用者手中。假設目前AI能力是60分，但大多數使用者可能只享受到20-30分的能力，有些甚至是零分。從產品角度，Replic工作是讓更多人能享受這個60分的能力；從研究角度，則是要把這個60分提升到80分甚至100分。當上限提升後，一般使用者享受到的能力自然也會隨之提升。
  • 一個是push frontier ，一個是help people實現價值。就像造紙局和用紙局的關係。造紙的人關注如何提升能力，用紙的人關注如何讓更多人用。不過現在確實還是research phase，絕對是research phase。
• Life is more like text-based than video game

因為你要做的decision其實很多是open-ended的。比如說今天晚上要做什麼，action space是open-ended的，並沒有一個類似遊戲裡的上下左右這樣的鍵盤去給你指引。你可以買張機票去另一個城市，或是看電視，有無數種選擇。所以Language更接近這個事情的本質（姚順雨）　

嘉賓介紹

• 姚順雨：普林斯頓大學博士，清華大學獲學士。他在Agent 領域發表了一系列非常有影響力的論文：從有奠基意義的ReAct，Tree of Thoughts，到成為行業標準的基於GitHub 的代碼能力評估數據集 SWE-Bench，到首個開源AI 程序開發agent 計畫SWE-agent，是絕對的天才研究員！https://ysymyth.github.io/
• 李珎：Replit AI 團隊負責AI Coding agent，ex- startup 創辦人，ex- Googler。 Replit 成立於2016 年，是一個基於瀏覽器的IDE，允許使用者在多種程式語言中編寫、運行和分享程式碼。 2023 年$97.4M 的B 輪，投資人包括A16Z，Khosla Ventures、Coatue 等，估值$1.16B  https://www.linkedin.com/in/zhen-li-nexplain/
• 趙宇哲：Augment 擔任AI 研究員，曾在Google Brain（現為Google Deepmind）擔任Staff Research Engineer，主要研究方向是語言模型預訓練，指令訓練，神經檢索和檢索增強語言模型。 Augment 成立於2022 年，是一家為提供企業級全端式AI 程式設計助理的新創公司，由矽谷著名老牌創投Sutter Hill Ventures 孵化（Snowflake也誕生於此），並在最新一輪獲得由Index Ventures、 Lightspeed Venture Partners 和Google 前CEO Eric Sc​​hmidt 等領投的2.5 億美金融資，估值接近10億美金 https://www.linkedin.com/in/vincent-zhao-1b750b46　

正文

註：本期錄製時間為2024年5月。但認知擴散的速度並沒有太快，業界的許多認知，到半年後的今天，似乎都遠遠沒有趕上前沿研究半年前的認知。　

00:00:45 - 00:02:07　

今年除了OpenAI的Solar驚起千層浪以外，同樣引起AI從業者尤其工程師極大關注的，想必就是僅透過一段演示影片就連續獲得兩輪融資，估值在半年內躥升到20億美元的Cognition Labs的AI agent Devin。身為宣稱的世界上第一位AI軟體工程師，它將如何重塑軟體開發甚至工程師這個職業？ Devin是否能代表agent應用開發的方向？以及看到目前agent產品還有多少提升空間？　

這一期我們邀請到三位在各自領域都極具代表性的嘉賓，有來自去年剛晉升獨角獸的軟體開發雲平台Rapid的AI agent工程師，首個基於GitHub的程式碼能力評估資料集SWE- bench以及首個開源AI software agent專案Three Agent的作者，還有剛官宣估值達到10億美元的企業級AI程式輔助公司Ogman的AI研究員。　

在兩個多小時的對話裡，我們從工程師個體、企業級需求以及學界研究等不同角度，深入探討了最近出現的程式輔助產品、試圖替代工程師的agent、基礎大模型的邊界，以及生成式AI對個人職業和社會的深遠影響。本期內容遠遠超出了對技術和產品的探討，希望能對正在收聽的你們有所啟發。 enjoy。　

00:02:07 - 00:03:30　

Monica:　

大家好，歡迎來到Onboard，我是Monica。　

高寧:　

我是高寧。　

Monica:　

今天我們很難得在矽谷錄製這期線下的Onboard。這期節目的話題，我覺得集合了AI界最近最熱的幾個方向。一開始我們計劃討論AI for coding這個話題。在幾個月前，大家關注更多是像Microsoft的Copilot這種auto complete的形態。但追蹤這個領域的朋友應該也注意到，前幾週Cognition Labs發布了一個叫Devin的coding agent，我覺得這一下子讓大家對LLM或AI如何改變整個軟體開發模式有了新的想像空間。　

高寧:　

每個階段都非常有代表性的產品和技術。　

Monica:　

對，所以我們今天請到了在這個領域非常有發言權的幾位嘉賓。剛才我們也喝了點小酒，氣氛已經到位了。　

00:03:31 - 00:06:07　

高寧:　

請三位嘉賓做個簡單的自我介紹，同時分享今年發現的最有趣的產品。我們從順雨開始吧。　

姚順雨:　

大家好，我叫姚順雨，是Princeton第五年的PhD，馬上畢業了，現在在舊金山的Sierra實習。說到有趣的產品，我想推薦Sierra ，這是AI領域真正能落地的產品之一，主要做customer service business agent。我們已經有很多客戶了，最讓人興奮的是它真的work，而且能夠完全取代某些角色。　

Monica:　

Sierra確實是去年最受關注的典型大佬創業公司，是原來Salesforce的CEO創立的，主要為企業提供customer service chatbot服務。　

高寧:　

那除了Sierra之外，你今年發現最有趣的AI產品是什麼？　

姚順雨:　

我經常使用Perplexity ，主要用它來取代Google搜尋一些知識性的內容。　

Monica:　

不只是在國內，就算在國外，在AI圈之外的人對Perplexity都不太熟悉。我現在除了查找特定網站這類事實資訊用Google外，只要是帶問號的搜尋都會用Perplexity。　

李珎:　

我現在使用Perplexity的比例已經達到30%了。　

Monica:　

順雨，可以介紹一下是如何進入AI研究領域的嗎？　

姚順雨:　

我本科時就開始做科研，最初是做computer vision，後來覺得想要研究language，就轉向了這個方向。　

Monica:　

順雨很謙虛，他在agent相關的工作在整個領域都有很強的標誌性意義，一會兒我們會請他詳細介紹。　

00:06:07 - 00:06:44　

趙宇哲:　

大家好，我叫趙宇哲，我現在在一家做full stack AI for code的AI新創公司工作。之前我在Google Research的Google Brain團隊，主要做language research的工作。　

Monica:　

對，這家公司也是某大佬創業的，我們今天集齊了各個大佬創業公司。這家公司是某特別愛孵化的大佬基金孵化的公司。　

00:06:45 - 00:09:56　

高寧:　

可以說說你是怎麼進入AI這個領域的嗎？　

趙宇哲:　

我進入這個領域運氣特別好。我PhD期間做的是比較理論的研究，當時覺得這些理論研究缺乏實際意義和解釋性。畢業時我在vision和language兩個方向之間選擇，因為在PhD期間做過一些vision的小項目，但最終選擇了language方向，因為language與intelligence更接近，而vision更偏向perception（感知）。　

五年前我加入了Google，剛好是發明BERT的團隊。經歷了BERT前後NLP研究的翻天覆地變化，這對我來說是非常好的學習機會。最初我做了很多BERT的pre-training相關工作，後來參與了LaMDA專案。 LaMDA是生成式AI的開山鼻祖，在此之前沒人認為生成式語言模型可以用來做chatbot。之後我們做了第一批instruction tuning的工作，發表了相關論文。　

我個人比較感興趣的研究方向是retrieval ，我認為retrieval對language model來說是一個很重要的capability，這也是我現在在新公司正在做的事情。除此之外，我也參與了一些產品落地的工作。　

說到AI產品，我覺得影片生成很有意思，雖然我主要是看demo。日常使用最多的還是GPT，特別是用GPT-4來處理一些影像相關的任務。　

00:09:57 - 00:10:23　

高寧:　

好的，李珎。　

Monica:　

大家好。　

李珎:　

大家好，我叫李珎，目前在B輪創業公司工作。我們的產品不只是一個IDE，它最初是從一個multiplayer online IDE開始的，現在已經有兩千多萬用戶。　

00:10:23 - 00:11:33　

大部分人其實是在學習編程，或者說不太會寫代碼的，這些人需要一些沒那麼專業的programmer的幫助。我們的vision是"Next billion software creator"。　

趙宇哲:　

這個世界會寫程式的人只有三、四千萬，是人類人口的極小部分。　

李珎:　

對，我們常聽到"我有一個idea，但是缺少一個程式設計師"。　

趙宇哲:　

有idea的人是很多的。　

李珎:　

但我們的vision其實就是想讓所有人都成為software creator，你有一個idea就可以create software。這個vision在七年前就有了，所以第一步就是做一個雲端IDE，讓大家可以在手機上、在任何地方寫程式碼，然後有一些輔助設定環境的工具。現在加入了更多AI的部分，這讓我們離實現這個vision會更近很多。　

00:11:33 - 00:12:58　

這是我們公司，我是六個月前來到這裡的。我在北航本科畢業後直接去了Google，在那裡工作了五年。　

趙宇哲:　

在Google主要是做推薦系統？　

李珎:　

對，做Google News，我們叫Discover，其實也是news。那時候我一直在做AI，特別是推薦系統，這是上一波AI最賺錢的場景和產品。做了五年後，我覺得基本上已經捲到頭了，因為大家都往上加各種各樣的奇技淫巧。有很多feature engineering，然後在模型裡面加上一些奇怪的結構，像是attention、transformer這些。這些方式it worth，但已經有種捲到頭的感覺了。真正能帶來正向revenue的突破不多，所以我後來就出來了，去TikTok做了一年推薦，想看看他們在做什麼。　

00:12:58 - 00:15:42　

Monica:　

你不是已經覺得捲到頭了嗎？怎麼又去了一個更卷的地方？　

李珎:　

我當時覺得Google的工作方式可能不太適合我，想看看中國公司是怎麼樣的，因為我想創業。創業就會面臨一個問題：是在美國創業還是在中國創業？所以我想給自己一年時間去回答這個問題，就去了TikTok。待了一年拿到綠卡後我就出來創業了，因為我覺得自己做才能真正學到東西。　

我做了一個Biotech領域的Copilot，就是給biotech的人做copilot。從前年到去年九月，那時ChatGPT還沒出來。我們當時有個very big ambition，想做GPT的App Store。後來我發現AI在coding領域能產生更大的價值，就開始尋找這個方向的機會。　

Monica:　

所以你當時去的公司做了好幾年了，是在一個什麼階段？　

李珎:　

他們已經做了六、七年，有很好的產品市場契合度，有大量用戶非常喜歡這個產品，但需要開始獲利了。我加入的時候正好是公司開始引入AI的早期階段，他們剛從Google Research挖來了我的老闆，他之前在做PaLM和其他coding model。公司剛開始加入ghost writer等AI相關feature，是很早期的階段，然後後面又做了一系列的提升。　

00:15:44 - 00:16:59　

高寧:　

你今年發現的最有意思的AI產品是哪一個？　

李珎:　

因為我想要Empower更多人去build software，有一個產品特別有趣。是一家叫Buildspace的公司，是a16z投資的。它更像是一所學校，主要是幫助更多人學習怎麼做產品。他們今年做了一個新產品，是一個chatbot。你可以跟它說你的idea，它要嘛幫你產生程式碼，要嘛幫你接到能幫到你的人。比如說，如果你是YouTuber，你跟它說我想要為我的影片產生更好的封面，它就會幫你找到大概十個正在做YouTube影片封面生成的公司或個人。　

00:16:59 - 00:17:45　

這個產品本質上是在把人和人connect起來，這是一件很好的事情，是幫助你去完成目標。你並不需要自己會做所有的事情，只要有人能幫你完成就好。他之前是做crypto的，現在在Web3上。　

觀眾:　

本質上這是一個非常有意思的公司。　

李珎:　

我非常喜歡這個founder，他是個特別優秀的創業家。他很喜歡sharing他的knowledge。我在他那裡學到的創業知識，可能比我自己做創業六個月學到的還多，而在他那裡只花了幾個星期的時間。　

00:17:46 - 00:20:24　

Monica:　

我覺得這個挺有趣的，讓我想到HeyGen。他們之前分享過早期的一個growth hack。這是一家華人新創公司，前段時間拿到了Benchmark的4,000萬美金投資。他們是幫你自動生成類似真人的avatar。最早他們把服務放到Fiverr這個freelancer平台上，那裡真人影片服務通常要收費幾十到一百美金一小時。他們就把AI生成的影片標價很低，好像就五美金左右。這個價格差太大了，一下子就打開市場了。我覺得以後有了這些AI技術和產品，真的可以幫你端到端完成工作，到時候在這些網站上，你可能都分不清哪些是AI、哪些是真人做的了。　

李珎:　

我是透過Buildspace來認識這些的。 Buildspace的slogan是six weeks to work on your dream。它會定期舉辦batch活動，六週時間讓你去實現自己的夢想。你可以做software、APP，甚至像我當時那樣畫漫畫，也可以寫歌。他們不教你怎麼寫程式碼，而是教你怎麼讓別人專注在你的產品，怎麼去launch 。我參加過兩次，後來透過Buildspace的founder Farza和Anthropic CEO的fire side chat認識了Anthropic，這就是我現在在這裡的原因。　

00:20:24 - 00:20:41　

趙宇哲:　

非常酷的。　

Monica:　

對，很棒。剛才李珎講到了Replit，這家成立五、六年的公司現在融資已經超過了兩億美金。　

高寧: 　

是個獨角獸了。　

00:20:41 - 00:21:37　

Monica:　

對，朱老師說得對。在這波AI浪潮中，Replit在美國一直處於聚光燈之下。我覺得他們算是前行者，從兩、三年前就開始加入很多AI功能，迭代也非常快。我專門去看了Replit的博客，他們分享了很多關於AI的思考。去年年中他們就發表了一篇博客，講AI will redefine every single app feature 。他們發布的這些AI功能讓我們發現，AI在IDE開發工具裡的應用遠遠不止Copilot那樣的功能。李珎，你可以跟大家介紹一下Replit的AI產品都有哪些？它背後的主線邏輯是怎麼樣的呢？　

00:21:38 - 00:22:02　

趙宇哲:　

我們的主線邏輯很簡單，我們想做兩件事。　

李珎:　

第一件事是Next billion software creator ，讓更多的人可以去create software。第二個是from idea to software ，就是把你的想法轉變成能夠幫你profit的軟體。　

00:22:02 - 00:22:32　

我們所有的產品都是圍繞著這個平台，這是一個雲端的程式碼平台，它支援multiplayer功能。　

趙宇哲:　

用戶可以在雲端編寫程式碼。　

李珎:　

這個multiplayer功能實際上為我們帶來了很多用戶，特別是教育領域的用戶。例如老師可以即時看到學生在寫什麼程式碼，在整個debug過程中，每一個步驟都能在multiplayer環境下被看到。　

00:22:32 - 00:23:56　

觀眾:　

是code completion，就是我們當時的ghost writer。　

李珎:　

當你寫程式的時候，它會出現一堆ghost writer，也就是ghost text 。你可以接受它給你的補全建議，這個其實跟GitHub Copilot和大量的補全產品非常像。這是一個很直覺的能夠幫助程式設計師寫程式碼的產品，也是現在大家覺得最有用的產品之一。　

同時我們會有一個AI chat，這是個很常見的產品。在我們的IDE裡，左邊是程式碼，右邊是chat。你可以用它做很多事情，例如幫你產生程式碼，然後直接一鍵貼到IDE裡面。或者當某個地方有紅線提示LSP錯誤或語法錯誤時，上面會有debug按鈕，點擊後它會在chat裡顯示錯誤原因，並告訴你如何修復。　

00:23:56 - 00:25:34　

我們的Software開發流程是這樣的：從寫入程式碼開始，然後debug運行，我們最大的優勢是把所有環境都放在了雲端。　

趙宇哲:　

雲端確實解決了很多問題。　

李珎:　

是的，程式設計師都知道配環境很麻煩。 Replit透過雲端環境和standardize的setup腳本解決了這個問題，這樣就不存在本地Python dependencies這樣的問題了。到最後一步deployment時，你完成軟體後希望它成為一個真的網站供人訪問。我們其實做了一件事，就是把整個軟體開發週期裡面要做的事情都整合在一個平台裡面，是一個all in one的platform了。　

現在市面上有很多公司分別在做code completion、deployment等單項功能。把這些整合在一起有好有壞：壞處是我們一個公司要做好幾家公司的事情，好處是可以把整體體驗優化得非常好。　

00:25:34 - 00:26:44　

我們發布了很多功能，包括ghost writer和chat。今年初我們做了一個很大的改動就是AI for All。之前AI功能只對付費用戶開放，現在我們把這個功能開放給了所有人。你現在上Replit，不需要有帳號就可以使用code completion和AI chat。這對我們來說其實是在花錢的事情，因為我們要付這些token給免費用戶。　

高寧:　

使用者現在不需要註冊就可以體驗這些AI功能了嗎？　

李珎:　

對，不需要註冊就可以用。這是我們的vision，因為我們想要讓更多人用AI去create software。這也是我加入後做的比較大的第一批工作之一。　

00:26:46 - 00:28:57　

這其實也引出了我們自己的一些工作。我們訓練了自己的code completion模型，包括上個月發布的code pair模型，因為我們要支援更多人使用AI。我們有幾百萬用戶需要服務，這對模型和後端系統提出了許多特殊要求。　

高寧:　

我理解就是需要一個更小的模型，用更低成本的方式來服務更大規模的用戶，對嗎？　

李珎:　

對，有兩個出發點。第一個就像你說的，模型必須要小，因為這樣才快，而且要便宜。第二個原因是我們要利用自己的數據來提升模型效能。　

Monica:　

我看到最近發布的1.5版本code模型是3B參數量。　

李珎:　

對，我們現在有3B參數量的code completion模型，已經放在Hugging Face上可以下載。另外，我們最近也發布了一個code repair模型，它不是做補全，而是幫你修復程式碼錯誤的。這個模型既可以讓agent用來修復程式碼中的bug，使用者也可以直接獲得修復建議。比起調用更大的模型，我們用更小更快的方式來提供建議，這樣就能更頻繁地服務用戶。　

00:28:57 - 00:30:43　

高寧:　

現在我們看到專門針對coding的模型非常多，非常卷。不管是大模型公司還是像magic這樣的startup，包括雲端廠商都在開發自己的coding model。我想請教大家，我們是否真的需要一個專門的coding model？它的能力是否真的可能超越現在的通用基礎模型？　

Monica:　

這涉及兩個問題：一是專門的coding模型在效果上能否超越最好的通用基礎模型，二是我們現在有這麼多專門的coding model，是純粹出於效率的考量，還是有其他因素在裡面？　

李珎:　

從Replit的角度來說，我們的目標是要Power next billion Creator。雖然我們只訓練了3B的模型，但評估顯示其性能比Code Llama 7B更好。因為我們的用戶主要是citizen developer ，所以我們更關注效率和成本。我們的主要考慮是如何降低為用戶提供免費服務的成本，同時充分利用我們自己的數據。　

00:30:43 - 00:31:01　

Monica:　

關於podcast討論的這個主題，如果大家使用公開抓取的coding數據，大概率這些數據的質量不如企業內部的代碼那麼高，因為很多開源代碼可能存在garbage in， garbage out的問題。　

00:31:01 - 00:31:46　

趙宇哲:　

我覺得這個問題很好，我們的promise是我們絕對不會在意這一點。這就是做enterprise業務的特色。我可以看到做enterprise和非enterprise業務有很大的區別。　

比如說data engine這個領域，為什麼要用Snowflake而不用Azure或GCP的服務？有一部分原因是trust。如果你是企業導向的企業，對這個特別在意。當然也不是所有企業都這樣，特別小的企業可能無所謂，但是到了一定規模，大家對這個問題特別清楚，會對security有顧慮，這讓體驗很不一樣。　

00:31:46 - 00:34:04　

Monica:　

我在想，在這個領域是否不存在所謂的資料飛輪效應？因為客戶資料都無法使用，所以各個model的數據似乎都沒有優勢。　

趙宇哲:　

我並不完全同意。公司可以取得一些有license的數據，而且GitHub本身的數據已經很豐富。目前標準做法是收集GitHub的各種版本進行deduplicate。但這裡有個關鍵問題是license，在GitHub上clone程式碼並不代表license允許你用來訓練。如果要認真做enterprise服務，這有legal風險。例如Microsoft為了獲得trust，會向GitHub用戶承諾處理所有legal問題。　

Monica:　

那這樣的話，如果GitHub也嚴格遵守license，是否代表他們在數據上也不會比別人有優勢？　

趙宇哲:　

是的。而且Copilot現在是用OpenAI的API，他們之間的關係並不透明。不過，GitHub確實提供了enterprise服務，如果企業需要fine tuning，他們可以提供fine tuning服務和私有化部署。　

Monica:　

所以最終企業的需求是希望model只benefit自己的數據？　

趙宇哲:　

對，這會是一個重要的service方向。　

00:34:04 - 00:35:29　

Monica:　

我對這個領域還不是很了解，想請教一下，如果拿最強大的通用基礎模型，例如GPT-4這樣的模型，與專業的coding模型相比，它們的程式設計能力是怎樣的關係呢？　

趙宇哲:　

這是個很好的問題。當初不只有專門做coding的模型，還有專門做數學證明的模型。這種專門化模型出現有幾個原因：　

一方面是學術界的research需求，因為代碼這個language不是natural language，作為natural language研究的人原本不研究code。但當T5這些模型出現後，學術界就開始專門研究如何用這些模型去做code task ，包括數學和邏輯證明的模型。　

另一個重要原因是cost考慮，因為雖然code跟natural language有關係，但關聯度沒那麼高。如果只是想訓練一個專注於code的模型，可能專門訓練會更好。例如國內的DeepSeek就是一個非常優秀的程式碼模型。　

Monica:　

而且DeepSeek還是開源的。　

00:35:30 - 00:36:50　

趙宇哲:　

還是開源的。然後在程式碼訓練上，有一個很有趣的預訓練方法叫做filling the middle 。它不是傳統的從上到下、從左到右的訓練方式，而是專注於上下文中間的內容。這個任務特別適合做程式碼補全。 OpenAI的論文也提到了這一點，說明這種filling the middle的訓練方式是很重要的。  　

DeepSeek就採用了這種方法，而且他們也在程式碼訓練上做了一些創新，像是repo level的預訓練。你想啊，對於普通文本來說，不同文本之間是隨機組合的，因為它們本來就沒什麼關係。但是對程式碼來說就不一樣了，因為在同一個程式碼庫裡，不同的檔案之間是有關聯的。 DeepSeek就利用這種文件之間的關係來建構訓練數據，這樣就能得到很好的長文本訓練數據。　

00:36:51 - 00:37:10　

姚順雨:　

我們需要對這些內容進行排序嗎？　

趙宇哲:　

對，這是在做錯誤處理。在code上實作是很容易的。我覺得在natural language中雖然不是不可以，你可以用search來排序文本，但code就容易得多，因為code的結構比較清晰。　

李珎:　

結構比較清晰。　

趙宇哲:　

對，正是因為結構比較清晰，所以在code上可以更容易實現這些功能。　

00:37:10 - 00:37:36　

姚順雨:　

是不是tokenization也不太一樣？　

趙宇哲:　

理論上可以用相同的tokenization，但實際上確實會不一樣。即使用相同的訓練策略，distribution也會不一樣。不過之前的表現確實很好。　

GPT-4的程式碼能力非常強。對於general model來說，你需要專門分配很大的預算來訓練程式碼能力，因為程式碼相關的能力需要很大的模型capacity。　

00:37:36 - 00:38:33　

最近發布的Llama 3在程式碼方面表現很強。從能力上來說，專門的code model不一定比general model強，但它的模型體積一定更小。　

Monica:　

現在這些model的coding能力相比是怎麼樣的？　

趙宇哲:　

DeepSeek很強，然後Llama和GPT都很厲害。但這要看具體task，GPT不是專門做程式碼補全的模型。專門的程式碼補全模型在這方面確實厲害。但在human evaluation時，有一個特別的task，就是decode任務。　

高寧:　

刷題的那個。　

趙宇哲:　

對，就是很簡單的standalone任務，給你一個單獨的任務，要求實作某個演算法，GPT-4在這方面表現很強。　

00:38:33 - 00:40:00　

Monica:　

去年年初我們和Google PaLM的作者之一討論時就提到，大家發現加入coding資料的重要性已經成為業界共識。如果那些做Foundation model的公司目標是AGI，他們一定會花大錢，盡可能取得所有能拿到的最高品質coding資料。　

趙宇哲:　

完全同意這個AGI的觀點。有人認為如果是很強的程式設計師能寫程式碼就是AGI的體現，因為優秀的程式設計師可以實現很多功能。這就是Magic Dev Def公司的主張，這是很有邏輯的。這也解釋了為什麼大家都關心MMLU能力，還有人專門訓練模型做奧數，因為這些都與reasoning能力關係最緊密。　

李珎:　

如果我們認為目前的瓶頸是reasoning能力，那就應該給模型更多的reasoning資料。而現在大家能想到的最強的reasoning資料就是程式碼。　

00:40:00 - 00:40:56　

高寧:　

我知道有一家startup，他們專門為LLM公司提供訓練用的程式碼資料。這些LLM公司會提出具體需求，然後這家startup負責招募專業程式設計師來編寫高品質的程式碼數據，用於預訓練。這個模式有點像Scale AI。　

李珎:　

他們是透過購買這些數據來獲得收入的。　

趙宇哲:　

我看到很多程式碼的instruction資料集。　

高寧:　

是的，GitHub上的程式碼資料品質只能說是中庸水平，現在確實需要更專業、更高品質的程式碼資料集。　

Monica:　

這說明我們進入了數據升級階段，要產生高品質的數據，成本也不斷提高。　

00:40:56 - 00:43:29　

我想了解一下，你剛剛提到為了讓模型有更好的程式碼補全能力，有很多專門的訓練方式。這些訓練方式能用於Foundation model的訓練嗎？　

趙宇哲:　

是可以的。這種上下文預測的方式並不新，T5就是這麼做的。我之前做過一個叫dialogue predicting的工作，目標是透過已知對話的脈絡來預測中間的話語內容。這個task雖然有多種變體，但並不是很popular，主要是因為效率問題。在decoder-only model中，training時你只是讓它predict下一個token。這裡有個概念叫cost of masking，就是在predict token時會使用目前所有可見的token。如果做filling the middle training ，dependency關係就會改變，之前的計算就不能重複用了。　

姚順雨:　

例如你想用第一句和第三句來預測第二句，然後又要用第二句和第四句來預測第三句，這樣很多計算就沒辦法reuse。　

趙宇哲:　

對，雖然付出同樣的計算量，但效率會低很多。　

Monica:　

這讓我想到最近大家常討論的AI能否幫我們解決複雜的學術問題，例如數學定理證明。本質上不就是已知條件和結論，需要證明中間過程嗎？這technique能用在這方面嗎？　

趙宇哲:　

有這個可能性，但做reasoning時不一定要用filling the middle的方式。你可以用其他prompt方式，把結論直接放到prompt前面告訴模型這是目標。這樣也是可以work的。　

00:43:29 - 00:45:26　

Monica:　

姚順雨，你怎麼看？就前段時間Magic Dev一上來就融了上億美金，號稱要做最牛逼的coding模型，說這是通往AGI的捷徑。　

姚順雨:　

我認為coding資料對訓練Foundation Model非常重要，這個毫無疑問。但僅靠coding能否實現AGI這一點還有待商榷。natural language和programming language是有本質的區別。programming language更結構化，而natural language更noisy，有更多的pragmatic結構。對人來說，例如要創業，就需要同時掌握programming language和natural language 。我覺得高品質的coding資料eventually會很重要。　

Monica:　

你覺得eventually最強的Foundation Model的coding能力會強於專門的coding model嗎？　

姚順雨:　

我覺得是的，因為這不是一個fair comparison。 Foundation Model規模更大，在其他資料上訓練後整體推理能力會更強。但這要取決於具體application，像是Copilot這樣的應用就需要小模型。　

李珎:　

討論最強模型的話，最強的模型一定是把所有數據都用上的。不會出現一個僅僅因為用了更多coding資料就能超越最強模型的情況。　

00:45:27 - 00:46:42　

Monica:　

讓我們聊聊model之後的產品話題。 o1選擇了一條比較難的路徑，就是完全建構一個自己的IDE。我們看到很多像Copilot這樣的產品採用插件形式，我很好奇你們是怎麼思考這個產品形態的，以及不同產品形態對AI產品設計會有什麼影響？　

李珎:　

說實話，這個產品的邏輯我一開始也不太懂，我覺得很多人可能也不懂。雖然表面上看起來就是一個IDE，但我們選擇這種形式是有原因的。最大的好處是可以降低使用者的上手成本，使用者不需要去操心下載VS Code、安裝Replit插件、學習如何使用Azure部署等這些複雜的步驟。我們把這些功能都以按鈕的形式整合起來，讓使用者可以一鍵設定環境。這也是我們在2022年之前能夠吸引用戶的重要原因。　

00:46:42 - 00:49:45　

我在考慮加入時就在思考，如果AGI真的來臨，一個超強的AGI會需要什麼？它可能有很強的大腦，但如果要取代現有的軟體開發過程，它需要各種工具，就像手和腳一樣。它需要一個寫程式碼的地方，需要能測試、部署，然後驗證部署結果，看到自己建立的網站效果並進行回饋循環。最後也要把產品上線，接取支付功能，成為真正可以持續迭代的產品。　

這些工具現在都在本地，但最終會變成雲端API供AGI使用。實際上，我們（Replit）是在打造一個為AGI寫程式碼和製作產品的sandbox，只是現在的使用者還是人。即使OpenAI發展出超強的模型，它也需要像我們一樣建構雲端平台，讓AGI能夠編寫、運行、debug程式碼，處理編譯問題和LSP，處理各種錯誤和不同的程式語言。如果一家公司之前幾年的工作能輕易取代，那這個公司就沒有什麼價值。　

姚順雨:　

你提到未來AI可能會使用你們的工具，它是透過API存取還是使用UI介面？　

李珎:　

我們內部已經有了這些API ，包括取得30多種程式語言的編譯結果、LSP結果、部署執行測試等每一個步驟。就是透過function calling ，告訴AI這些工具可以用，它就能直接呼叫這些API。　

00:49:46 - 00:51:35　

Monica:　

我在思考未來的開發環境選擇問題。現在我們需要在GitHub和Replit之間做選擇，但我認為未來決策可能會往更高層次發展。就像訂外賣，現在我們要在Uber eats和其他平台之間選擇，但未來可能我只需要表達我要訂外賣這個需求，由AI模型來決定使用哪個平台。同樣，開發者可能只需要表達我要寫程式碼，由AI來決定在哪個平台上實作。　

李珎:　

這要看用戶類型。如果是程式小白，確實需要很high level的抽象，像是幫我做個程序，唱會有票就傳簡訊給我。但對於專業程式設計師，就像F1賽車手一樣，他們會更具體地描述需求，例如要build一個iOS app，需要連接stripe，需要這個功能那個功能。　

高寧:　

當需求明確時，就需要specific的model和function 。 RAG技術更適合小白用戶，也就是citizen developer。而宇哲他們公司做的是插件形態的產品，專門服務企業裡的專業程式設計師。這與GitHub copilot等產品相比有其獨特的定位。　

00:51:35 - 00:54:09　

產品的一個不一樣的地方和這裡面的一些困難在哪裡？　

趙宇哲:　

我們公司的value proposition是希望我們的產品是真正懂你的codebase的。這個設計是針對已經有一個極大的codebase存在的場景。這和現在主流的那些benchmark很不一樣，因為那些比較像是面試題，甚至比面試題還要簡單的考試題。　

在現實工作中，無論你做什麼工作，都會面對一個巨大的codebase 。例如做財務的會面對整個公司的financial系統，做程式設計師的會面對整個公司的程式碼。有趣的是，全世界擁有最大codebase的其實不是tech公司，而是銀行。　

無常按：剛好和最近的一個思考不謀而合了。不存在從零到一的創作，今天人類幾乎所有創作都是有脈絡的。所以AI產品必須要了解使用者場景的上下文，必須RAG（也許還應該有其他方式）。　

我們面臨兩個主要挑戰：　

第一，產品必須真正懂你的整個codebase ，所以retrieval特別重要，因為這些程式碼不會出現在Foundation模型的訓練資料中。　

第二，產品feature必須能融入使用者的工作流程。對於professional用戶來說，他們已經有了自己的工作方式，這就是為什麼程式碼補全這麼受歡迎，因為它對工作流程的改變最小，用起來也很簡單。　

所以對我們公司來說，最重要的就是在一個巨大的codebase裡做一個好用的工具。　

00:54:09 - 00:55:26　

Monica:　

我很好奇，在你們這麼多AI feature中，哪個是最受歡迎的？　

李珎:　

最常用的顯然是code completion功能。不過最近成長最快的是deployment功能，它可以幫助使用者將產品網站或專案正式上線。這個功能成長非常快，而且能很好地monetize，因為用戶都願意為此付費。我們最近在deployment上也在加入很多AI feature。總的來說，對所有程式設計工作而言，最常用的是code completion和聊天功能。　

實際上，我們的AI功能遍佈整個平台的各個角落。這些功能背後都是同一套系統，它們之間可以互相分享context。　

00:55:26 - 00:57:09　

Monica:　

我很好奇，剛才宇哲提到要滿足企業級需求，能否跟大家解釋一下，如何建構一個更懂企業自身需求的solution ？是RAG吧？　

趙宇哲:　

對，就是RAG 。這是很多做企業級AI的公司都需要面對的問題。 RAG有很多種實現方法和變化，不同的任務需要不同的方案。　

RAG的核心功能是讓Foundation model能夠在私有資料的context下完成任務。在不進行fine tuning的情況下，唯一的方法就是把相關資訊放在模型的context裡。對於不同的task，你需要看不同的context，這點在context特別多的時候特別重要。企業相比個人通常會有更大的context，包括自己的codebase和各種資料。因為context量太大，你沒辦法把所有內容都放在language model的context裡，所以需要使用retrieval技術來挑選相關的內容。　

00:57:09 - 00:58:39　

那這邊關於retrieval的實現，需要考慮在什麼時候執行，以及執行的頻率。　

李珎:　

需要做多次執行。　

趙宇哲:　

在選擇retrieval的具體實作時，你可以使用關係型資料庫，也可以選擇向量資料庫，這些都是可選的方案。　

Monica:　

雖然大家經常談論retrieval這個概念，但實際上並沒有一個統一的最佳實踐。針對不同的場景，現在的解決方案都是不同的。　

趙宇哲:　

確實，有些新創公司想要做通用解決方案。我之前做retrieval研究時也在探索這個方向，希望發展一個通用的retrieval模型。但就目前來說，在自然語言問答這個任務上，市面上的模型確實做得都很好，但問題是並不是所有場景都是問答任務，所以這不是萬能的解決方案。　

高寧:　

在你現在做程式碼相關的企業場景中，特別是RAG這塊，你覺得最大的挑戰或是跟之前general場景最不一樣的地方在哪裡？　

趙宇哲:　

從技術角度來說其實沒有特別大的挑戰，但我覺得比較有趣的挑戰是evaluation。這個問題不僅存在於程式碼場景，對所有新創公司來說，價值評估和技術排名都是很困難的事情。　

00:58:39 - 00:59:34　

這適用於所有公司。RAG更難的地方在於它本身很難被value ，因為它不是終端的。例如我做程式碼品質評估時，直接看程式碼好不好就好。但是當涉及到應該retrieve哪個文件來改進程式碼時，這就多了一層複雜度，所以retrieve的evaluation本身就更難做。這也是為什麼學術性的evaluation很難做。　

李珎:　

對，甚至連標註都很難。給你一個包含一千個檔案的code base和一個問題，要你判斷哪兩個檔案最相關，這種標註是很難的。這不像其他數據標註任務，普通大學生就能完成，這個真的very hard。　

00:59:35 - 01:00:34　

姚順雨:　

對，你會用streaming來實現這個功能。　

Monica:　

我最近參加了Google Cloud的活動，看到很多企業用戶都在使用RAG技術。雖然每個企業都有自己的實現思路，但當討論到準確率時，發現一個問題：這些系統的準確率大多只有70%-80% ，這樣的準確率在生產環境中是很難部署的。我很好奇，提高準確率的難度究竟在哪裡？　

趙宇哲:　

這個問題的關鍵是要先思考準確率本身的意義，這實際上是一個evaluation的問題。　

李珎:　

就是top K的問題，可能是第一個結果準確，也可能是前十個結果都準確，其實很像Google search的問題。　

趙宇哲:　

對，Google search就是全世界最大的Retrieval系統。　

無常按：Google search就是全世界最大的Retrieval 系統。一個簡單到容易被忽略的事實。　

01:00:35 - 01:04:01　

Monica:　

如果企業需要達到90%、95%或99%的準確率才能在生產環境中使用，那麼我們與這個目標之間的差距在哪裡？而且我們要如何衡量這些準確率呢？　

趙宇哲:　

我覺得要反過來看這個問題。針對特定任務，gap不一定很大。現在Foundation model比傳統NLP solution強的地方在於通用性，但retrieval不是一個做什麼都行的通用工具。它的定義很模糊，在不同任務中表現差異很大。　

Monica:　

我最近參加了一個developer meetup，看到Voyage公司在做embedding model，這是RAG架構中的重要環節。他們針對法律、程式碼等不同場景開發專門的embedding model。　

李珎:　

你指望一個embedding能在大量候選項中找出最佳匹配是非常難的，這不僅是embedding好壞的問題，而是對它的期望過高了。例如推薦系統，TikTok用用戶embedding去retrieve最接近的影片embedding，這種關聯是由使用者行為驗證的。 Google的ranking也是基於使用者點擊形成的系統。但常用的RAG方式是基於文字意義來建構embedding，不是一個閉環系統。　

無常按：在推薦系統裡，TikTok用用戶embedding去retrieve最接近的影片embedding，這種關聯是由使用者行為驗證的。 Google的ranking也是基於用戶點擊形成的系統——這都是閉環的。但常用的RAG方式是基於文字意義來建構embedding，不是一個閉環系統。　

姚順雨:　

這是一個training task，是在arbitrary的任務上訓練的。　

高寧:　

那麼在現在還缺乏最佳實踐的情況下，給企業客戶的產品是否需要根據每個具體任務去交付，這會是一個非標準的過程？　

01:04:01 - 01:05:46　

趙宇哲:　

程式碼檢索有個很好的特點，比如說做法律領域的應用可能會有局限性，但在程式碼領域，不同企業使用的programming language是相同的。不同的task可能需要不同的retrieval，但如果這個task做得好，即使是不同人寫的Java程式碼，用不同的library和design pattern，基礎語言都是Java，所以這是可以transfer的。　

Monica:　

那麼不通用的部分是什麼呢？　

趙宇哲:　

不通用的是自然語言模型直接遷移使用的效果可能不太理想。比如說做程式碼檢索的retrieval用來處理其他程式碼問題，效果可能好也可能不好。對於不同客戶，我們會提供相同的服務，這也是很有趣的一點。這讓我想到enterprise AI在這一波LLM之前，投入了大量精力做AutoML，當時的目標就是要服務所有公司。　

01:05:46 - 01:07:04　

說到machine learning，最難的是training。 AutoML說可以自動幫你清理model，只要有資料就好了。但實際發現這個solution並沒有那麼general。　

不過code本身通用性很好，雖然對不同test你可能需要專門engineer一個solution，但這個solution是可以被zero-shot的。　

李珎:　

因為程式碼這件事兒，大家做法都一樣，都是在寫程式碼。大家大機率都用相同的language，都在相似的環境下面。這和Google之前想target的場景很不一樣。程式設計師的世界相對來說是比較同質的。　

姚順雨:　

對，就是在互相抄，大家都在Google上retro一下。　

Monica:　

但是對於一些大公司來說，因為他們有一些legacy的東西，情況會不太一樣。　

趙宇哲:　

這就是為什麼RAG的技術是一樣的，我們把不同的內容放在context裡面，就可以得到不同的結果。　

01:07:04 - 01:08:47　

Monica:　

我們一直在討論RAG，是應該靠更好的RAG還是更強的context window來解決問題？例如現在的Gemini有ten million的context window，可能還會更長，你覺得未來會怎麼發展？　

趙宇哲:　

如果說long context會取代RAG，長期maybe，但短期絕對不可能。我們測過，所有模型在處理long context時都很慢，不需要一百萬，只要十幾萬token就需要十秒幾十秒，特別慢對吧。不過，當我有這個model的時候，我可以把它轉成一個RAG solution 。雖然沒那麼容易，但非常good。　

姚順雨:　

大概率只有一小部分。　

趙宇哲:　

對，大概只有一小部分。而且如果這個model能讀一百萬token並且很強，那它大概率知道這一百萬token裡面哪些部分是有用的。所以這能被轉化成一個​​RAG solution，而且我有這個solution一定比你快。　

01:08:48 - 01:09:38　

李珎:　

而且我覺得長期來看，有些部分是沒有辦法被取代的。　

趙宇哲:　

比如說，你在寫程式的時候…　

李珎:　

對，比如說你需要參考document。以numpy為例，它有非常多版本的document，你總是需要找到正確版本的document來使用，不可能把所有numpy的document都feed進去。這本質上是一個混合了搜尋和retrieval的問題，資訊可能來自底層程式碼庫，也可能來自外部網站，但始終需要從外界獲取資訊。你不可能把全世界所有的document都輸入進去，必須有一個選擇的過程，這個選擇過程就是retrieval，就是RAG。　

無常按：長上下文能取代RAG嗎？短期看不可能，因為太慢了。長期看呢？也很難，為什麼？首先你總是需要獲取用戶更多資訊的，你不可能把所有資訊都輸入進去，所以需要RAG。再說了，就算你把所有資訊都當作上下文輸入進去，那也必須有一個選項的過程，這個選擇過程就是Retrival，就是RAG　

01:09:39 - 01:13:41　

Monica:　

剛才宇哲講到evaluation這個問題，這確實是我們聽到最多的難題之一。特別是在coding領域，這仍然是一個沒有共識的問題。正好順雨最近推出了SWE-bench，現在很多做coding的專案都在用。順雨，可以跟大家介紹一下SWE-bench以及你之前在coding和agent方面的工作嗎？　

姚順雨:　

SWE-bench的動機很簡單，就是現有的coding benchmark不太行。一個好的benchmark應該具備幾個特徵：第一，要realistic practical ，不能只是toy task；第二，需要challenging ，不能太簡單；第三，需要easy to evaluate ，要有好的評估方法。　

現在大多數NLP benchmark這三點都做得不夠好。例如很多都是toy task，或是一些簡單的問題。像human evaluation這種最常用的benchmark，現在模型已經能達到95%以上的表現。對於agent task來說，evaluation特別難，例如要評估一個web agent的輸出好壞就很難判斷。　

除了這些核心特徵外，一個好的benchmark還需要具備一些管理特質。例如要有scalable的資料收集方法，同時要確保資料不會被訓練集污染。我們發現GitHub的pull request和issue系統完美符合所有這些特徵。　

具體來說，task的input很簡單，就是一個真實的GitHub issue和完整的程式碼庫，可能有50萬行程式碼。 output就是一個能解決問題的pull request。 evaluation非常簡單，因為可以直接用專案裡的unit test。這個任務既實用又有挑戰性，目前最好的RAG方案的成功率也只有40%左右。而且資料收集很穩定，我們測試發現不同年份的success rate差不多，即使發生資料污染，我們隨時可以取得最新的資料來補充。　

01:13:41 - 01:14:25　

我們當時非常開心。然後開始去做SWE Agent想要去解決這個問題。　

Monica:　

讓我跟大家解釋一下什麼是SWE-A gent 。我們剛剛討論了很多關於coding的AI功能，前段時間一個叫Devin的產品發布了flash demo，這確實為大家打開了新的視野。它展示了agent如何解決更複雜的coding問題，而且不僅僅是幫助寫更好的程式碼，還能解決全鏈路的問題。我想詳細介紹一下思維agent是什麼，以及它背後的設計理念是怎麼樣的。　

01:14:26 - 01:18:11l　

姚順雨:　

對，Sweet Agent的想法其實很簡單。在SWE-bench專案中，我們發現用sequence to sequence的方式處理這類任務是不切實際的，因為輸入可能包含數十萬行程式碼和具體issue。即使使用RAG方案篩選出相關文件，仍然面臨許多挑戰，因為對人來說，軟體開發本質上就是一個fundamentally interactive（根本上互動）的過程。　

Sweet Agent是SWE-bench任務上的一個baseline agent。我們採用了基本的ReAct Agent (Reasoning and Action)思路，關鍵在於action space的設計。最初我們嘗試讓agent在bash terminal中運作，可以查看檔案、導航資料夾、編輯檔案和執行程式。但很快發現最大的問題是編輯操作缺乏回饋。執行程式時能得到execution result供agent判斷，但編輯檔案時沒有即時回饋，可能出現syntax error或authentication error卻不自知。　

這促使我們提出了Agent Computer Interface（ACI）的概念。人類使用的Visual Studio Code、vim或Emacs這些都是Human Computer Interface（HCI），我們投入大量時間去打磨這些工具。但這些工具可能不適合agent 。傳統上都是固定environment讓agent變得更好，例如Atari遊戲，而我們採取相反思路：固定一個簡單的ReAct agent，專注於打磨environment 。最後會有一些co-design，但核心是如何設計最適合agent的interface。　

01:18:12 - 01:18:45　

Monica:　

我們可以向大家描述一下，這個agent能實現什麼樣的體驗，它可以完成什麼樣的任務？　

姚順雨:　

我們現在上線了一個在線demo，你可以複製任何一個GitHub issue的鏈接，然後粘貼進去，點擊一個按鈕，它就會嘗試生成一個pull request來解決這個issue。　

Monica:　

如果大家有興趣的話，這個SWE-agent的示範影片在YouTube和B站上都能看到。　

01:18:45 - 01:19:49　

我覺得大家看了之後會覺得非常impressive。剛才順雨講到SWE-bench，很多RAG-based的solution準確率都在個位數。而最近Devin和sweet agent的準確率都超過了10%，有一個很大的提升。這個提升主要來源是什麼？是不是你們的Foundation model用的是GPT-4？　

姚順雨:　

對，我們sweet agent用的是GPT-4。我發現一個比較有趣的實驗結果，在RAG的setup下，現在Claude Opus已經略微超過GPT-4一點點，大約3.幾個百分點。　

趙宇哲:　

百分之24本身也是很強的。　

姚順雨:　

是的，但是在agent這個領域，GPT-4還是比其他model強很多，比Claude和其他的都要強很多。這可能是因為Claude針對長文本和RAG進行了最佳化，而GPT-4則是針對agent進行了最佳化。　

01:19:49 - 01:20:27　

Monica:　

這個three agent能在SWE-bench上比之前的RAG有這麼大的提升，主要是什麼原因？　

姚順雨:　

我覺得有好幾個原因。我覺得最根本的原因是它可以去execute程式碼，你可以寫unit test然後去運作。如果運行失敗了，你還可以繼續嘗試修改。這個iterative的feedback loop是非常重要的。如果我只給你一次機會寫pull request就立刻提交，都沒有機會去運行，那就很難確保程式碼是正確的。但是execution是一個關鍵。　

01:20:27 - 01:21:32　

Monica:　

這個跟前陣子大家討論的agent概念，像是AutoGPT這樣的框架是個概念嗎？還是有什麼不一樣的地方？　

姚順雨:　

我覺得不一樣的地方就是，AutoGPT和baby AGI這類系統試圖把agent本身做得非常複雜，使用各種prompting方法、planning、reflection等技巧。但它們的environment其實很簡單，想做一個通用的agent，但效果不是特別好。我的philosophy是說，如果我們知道要做什麼task，就可以針對性地優化工具和environment，讓相對簡單的agent提升performance。　

01:21:33 - 01:24:39　

高寧:　

你們與Devin之間的差異與準確率差異主要體現在哪些方面？　

姚順雨:　

Devin是一個產品，我們是研究項目，目標是解決SWE-bench。 Devin作為產品需要處理各種軟體環境下的任務。他們採用了一個非常general的環境，包括web browser、terminal、editor和整個AI框架。而我們因為專注於特定任務，可以將介面優化到最適合agent完成任務。雖然我們的API design對各種程式設計任務都有幫助，但我們的技術路線是優化interface。　

Monica:　

對於目前10-12%的準確率，你怎麼看？你期望達到什麼樣的目標？　

姚順雨:　

我覺得現在大家都還是baseline水準。我有朋友的創業公司可能達到20%左右。我估計GPT-4應該可以達到30% ，因為SWE agent只是一個簡單的agent加上初步優化的interface 。Devin是在標準environment下的複雜agent 。如果把interface design和agent design結合在一起，也就是使用GPT-4也應該可以達到更好的效果。　

Monica:　

Devin下面是用GPT-4嗎？　

高寧:　

GPT-4 Turbo發佈時官方發了推文at了Devin，應該是說明Devin提前獲得了GPT-4 Turbo的介面。　

01:24:39 - 01:26:50　

Monica:　

根據你剛才的說法，現在很多人在討論agent為什麼雷聲大雨點小，沒有很好的落地。很多人歸咎於Foundation model的reasoning能力不行，但根據SWE-bench的結果來看，在現有Foundation model能力下其實還有很大的提升空間。　

李珎:　

產品化和做research是完全不同的事。雖然在研究層面看起來不錯，但要做成用戶能用的產品，需要更多產品層面的思考。　

agent與其他AI產品有很大的差別，首先是一個iterative(迭代)的過程，使用者需要耐心等待，而這個產品形態是前所未有的。與傳統軟體API相比，一個LLM相當於以前的一個API call ，而現在的agent更像是把這些API組合成一個end to end的軟體。但前所未有的是需要等待十分鐘才能得到回饋。　

另外，agent還有一個特點是不穩定，它無法達到90%甚至80%、70%的準確率，更不用說傳統軟體追求的99.9%的穩定性。　

面對這樣一個軟體，如何讓使用者能夠良好互動並獲得價值，需要複雜的設計。　

01:26:50 - 01:29:13　

Monica:　

前面提到，姚順雨其實一直在agent這個領域做了很多工作，從最早可能從React開始。每個人對agent都有不同的理解，你能跟我們介紹一下你是什麼時候開始研究agent的，在這個過程中有哪些重要的研究？　

姚順雨:　

我覺得我比較幸運，2019年開始讀博士時，我的第一個專案就是在text adventure game做agent。當時這是個很小眾的方向，因為大多數人做agent都是做RL，基本上都是做video game或robots，很少人做基於language的environment agent。　

我覺得這個方向很有意思，因為它比較接近reasoning，比較接近intelligence。我認為life is more like a text-based more than a video game ，因為你要做的decision其實很多是open-ended的。比如說今天晚上要做什麼，action space是open-ended的，並沒有一個上下左右這樣的鍵盤去給你指引。你可以買張機票去另一個城市，或是看電視，有無數種選擇。　

我覺得language比較接近這個事情的本質。做完text game後，我發現text environment和傳統environment的本質差異在於它的action space是不需要預先定義的。這就需要reasoning，而reasoning本質上是思考的一部分。為什麼傳統的agent不如人，是因為人有一個神奇的action叫做思考，但傳統agent沒有。思考這個action很神奇，因為它沒有feedback ，你腦子裡想任何事情都無法獲得外在世界的回饋，所以這個事情是學不了的。　

01:29:13 - 01:30:57　

Large Language Model為我們提供了parsing機制，讓我們能夠將reasoning和thinking作為language agent的重要組成部分。透過trail soft的進一步思考，我意識到agent本質上包含兩個核心部分：action space和decision making。　

action space就是選擇什麼樣的工具來交互，如何設計interface，以及如何進行internal reasoning。　

傳統上，decision making主要是透過generate next token來產生動作。但我認為，decision making可以透過planning來實現更複雜的決策。我們不只是直接產生單一動作，而是可以在腦中模擬多個可能的動作並評估它們。就像下棋一樣，我可以預測如果我這樣走，對手會怎麼應對這樣的互動過程。　

基於這些思考，我們提出了新的conceptual framework：Cognitive architectures for language agents 。本質上，agent就是由action、decision和memory三個部分組成的。　

無常按：　

清晰到值得重複。本質上，agent由三個部分組成：action space、decision making 和memory 。　

action space 是選擇什麼樣的工具來交互，如何設計interface，以及如何進行internal reasoning。　

decision making可以透過planning來實現更複雜的決策。我們不只是直接產生單一動作，而是可以在腦中模擬多個可能的動作並評估它們。就像下棋一樣，我可以預測如果我這樣走，對手會怎麼應對這樣的互動過程。　

memory 是記憶。　

01:30:59 - 01:32:43　

Monica:　

所以你的工作就是從思考逐漸發展到taking actions的研究。我覺得現在大部分的agent工作其實都是在不直接改變Foundation model的情況下，主要透過prompt方式來實現的。　

李珎:　

會這麼理解？　

姚順雨:　

我覺得這個事情根本上有問題，因為它沒有形成閉環，是個open loop。我可以舉個例子，現在我們用H200就很像deep learning初期用GPU的方式。當年GPU不是為deep learning設計的，是為遊戲設計的。後來大家發現它可以訓練AlexNet這些神經網路。接下來發生的事情很有意思：GPU和deep learning method形成了co-evolve關係，GPU促進了更好的deep learning method，而transformer這樣的method又反過來影響GPU的設計變化。　

language model很像當年的GPU ，原本只是個text generator，但大家用它做各種事情時發現了很多令人驚訝的能力。所以我覺得下一步應該把model和agent進行co-design，把agent的experience和數據反過來fine-tune model。　

01:32:43 - 01:33:01　

我們有一個工作叫fineac，就是fine-tune React。　

Monica:　

你們是自己先做了React，然後再做fine-tuning的研究嗎？　

姚順雨:　

對，因為我一直在等別人去做這件事，但發現沒有人做，所以我們就自己做了。　

01:33:01 - 01:34:01　

Monica:　

前段時間在討論agent這個話題時，有些公司例如Adapt就專門開發了針對agent的模型，我們特別重視模型的reasoning能力。我想請教，是否會出現專門針對agent的語言模式？這是否是個偽命題？　

李珎:　

對，Adapt。　

姚順雨:　

我認為agent是個非常廣泛的概念，這取決於你想要做什麼樣的agent。如果是想做general purpose的digital agent，我覺得基礎模型會更有優勢。如果是做vertical domain的特定領域agent，那可能不需要專門的模型。　

高寧:　

聽起來你覺得這應該是個偽命題。　

Monica:　

對，結論應該是個偽命題。　

01:34:01 - 01:35:07　

李珎:　

這其實是我創業時的出發點，就是要有個general agent幫你處理各種事務。我們做了一個類似ztier的項目，讓LLM來接取各種API。我們接取了Google Calendar、Gmail、訂機票、訂外送這些服務。　

高寧:　

這樣就能幫助協調整個工作流程。　

李珎:　

但其實這種general agent是個偽命題，因為很難真正產生價值。表面上看能幫你做很多事情，但首先系統穩定性是個問題。其次，如果要處理真正複雜的事務，光靠API是不夠的，需要中間的agent來管理工作流程。而且你要解決的問題越廣泛，就越難讓它真正好用。　

姚順雨:　

對，它更多需要人機互動才能真正發揮作用。　

01:35:07 - 01:38:15　

李珎:　

對，coding agent的一個很好的特點是它能產生可以自我驗證的行動路徑，形成一個完整的閉環。當agent透過十步二十步的操作完成任務後，就會產生positive的訓練資料。　

姚順雨:　

行動路徑具體是怎麼定義的？　

李珎:　

這主要是基於OT flow，即使用者的edit記錄。 OT是一種用來解決多人編輯衝突的格式，例如Google Docs多人編輯時就需要解決這種衝突。它會記錄諸如用戶在第五行第三列添加內容這樣的具體操作。這是一個很底層的使用者操作記錄，比Google Docs的範圍更廣，還包含了運行shell、寫程式碼、debug等操作。　

姚順雨:　

這些數據真的非常exciting！　

趙宇哲:　

code也是可以爬的。　

李珎:　

對，這些數據的獨特價值在於可驗證性。我們能確認專案是否編譯成功、通過測試。這不僅是簡單的數據，而是一個達到成功狀態的完整軌跡。　

Monica:　

這有點像是Tesla在做的事情。　

李珎:　

目前我們還在探索如何最好地使用這些數據，包括legal和模型訓練的考量。由於記錄了每一個操作步驟，整體資料量是非常大的。　

01:38:16 - 01:40:52　

Monica:　

我聽說現在有一些agent是用GPT-4來產生action model？　

姚順雨:　

這是distillation。這個跟agent沒關係。　

李珎:　

我現在在Replit做agent，它更像是coding interpreter。我們提供預先建置的環境，沒有React Flow那些複雜的步驟，是更specific limited scope的。使用者只需提出需求，例如分析CSV文件，系統就能產生程式碼並運作。　

我們特別關注小白用戶，因為他們完全不懂程式設計，甚至不知道Python是什麼，所以更需要agent的幫助。我們有個功能叫bug bounty，使用者可以發布懸賞來解決bug。解決者可以是人類，也可以是SWE agent。　

這就是為什麼我們的CEO和SpaceX的CEO關係很好，因為用戶群是一體的。誰解決了bug就能獲得獎勵。　

Monica:　

順雨找到了賺錢的方式了。　

高寧:　

找到了應用場景了。　

01:40:53 - 01:42:04　

Monica:　

其實剛才順雨講到研究主題和產品的差異，就在這裡。在產品中，即使我說要有human loop，但我必須考慮參與loop的用戶是什麼樣的。例如像宇哲他們的客戶，預設都有一定的coding能力；但如果面向完全的小白用戶，這時候做human loop的互動設計就會很不一樣。　

姚順雨:　

我覺得本質上來說，除非做HCI research，研究就是要minimize human factor，但product本質上就是all about human。　

無常按：Product is all about human 好清醒的研究員！　

Monica:　

前兩天我跟open Devin（一個open source的Devin專案）的團隊交流過，也看了他們的架構。因為他們團隊都還在企業裡做產品，所以特別著重把human loop的互動融入架構中。這確實和research的思考方式很不一樣。　

01:42:04 - 01:44:20　

我們一直在討論Devin，我很好奇大家第一次看到Devin demo時的反應是什麼？什麼讓你們印象最深刻？根據目前有限的公開訊息，你們還想了解哪些內容？　

李珎:　

我的第一個反應是有人發布了和我正在做的exactly相同的東西。因為我們團隊正面對著百萬級用戶量，有很多infra問題要解決，所以沒辦法發布demo。　

不過我覺得Devin確實很impressive，特別是兩點：第一個是web browsing功能，它可以讓agent去瀏覽網頁獲取更多資訊。對agent來說最重要的兩個能力：一是獲取資訊的能力，無論是透過web或透過RAG；二是自我validate的能力，就是execute和test。　

姚順雨:　

web browsing確實非常難做。　

李珎:　

對，特別是interactive web browsing，不只是fetch一個網頁，還要在網頁裡進行browsing，這點做得很impressive。另外，他們第一版還不能讓使用者修改程式碼，只能看著它產生。　

高寧:　

但中間是可以透過聊天方式去幹預的吧？　

李珎:　

對，你可以透過聊天來控制它，但沒有直接控制editor的權限。　

01:44:20 - 01:46:19　

這個我覺得挺surprise的。　

姚順雨:　

更像demo不像個產品。　

李珎:　

我覺得可能是他們的Design decision去限制scope。但我覺得正確的形式應該是都要具備，這對他們來說實現起來應該也不難。　

Monica:　

你覺得還有什麼想進一步了解的嗎？　

李珎:　

我很好奇他們準備怎麼把它當作產品落地，給誰用。　

姚順雨:　

是to C還是to B？　

李珎:　

對，這也是我們常常思考的問題。這個agent看起來能做所有事情，但你做research是一回事，做公司要賣產品又是另一回事。最重要的是找到product-market fit。是賣給coding小白還是其他人？價格定在這個區間合適嗎？這些包裝策略我都蠻好奇他們怎麼想的。　

高寧:　

因為你剛才提到如果不讓工程師過度參與編輯環節，聽起來是針對沒有程式設計能力的人。　

姚順雨:　

給產品經理。　

李珎:　

我覺得可能也是因為比較早期，所以先focus在這個方向也要make sense。　

01:46:19 - 01:48:13　

趙宇哲:　

我最喜歡的是Danny告訴我的這些事。我一直在關注這些工作，在離開工作之前我就很喜歡做prompting相關的工作，我們也很早就開始做這些了，效果很好。　

說實話，我對agent的工作一直是失望的。例如Langchain之前火過一陣子，大家都在談論agent可以做這做那，但後來並沒有特別顯著的進展。雖然Devin在這方面是比較成功的，但我仍然持懷疑態度，因為從一開始我就認為這只是個demo。後來Twitter上也有人說這確實就是demo。　

姚順雨:　

他是直接發布產品的。　

趙宇哲:　

對，但這本質上不是一個軟體問題。這個demo是在告訴你這件事是可能的。關於產品化，我認為如果它真的能在所有情況下都work的話，產品化可能也沒那麼難。 AI政策已經證明了我們無法阻止這個問題的發展。這個任務其實是automation後面一個level的任務，就是從issue到PR的過程。　

01:48:13 - 01:49:22　

首先要寫PR，現在有很多重要的tasks，像是如何做code review。這些review工作現在可以用model來輔助，它能夠suggest具體的code edits，這些功能已經可以投入service了。如果能把PR這塊做好，我甚至可以去負責整個project的架構，這就是architect要做的事。在企業環境中，當我要build一個function時，會面對大量的code base，需要開發新的feature。　

姚順雨:　

對，這些feature可以被有系統地decompose成一系列PR。　

趙宇哲:　

這確實是一個很關鍵的步驟，這也是我特別看重這個task的原因。關於agent是否是一個好的solution這個問題，我認為從長遠來看它一定會很好，是個非常有價值的research topic 。但對新創公司來說這是個很大的question mark 。如果公司像早期的OpenAI那樣不以盈利和產品為直接目標，那麼做這個方向很合適。但如果是以product為導向，research的risk就相當高了。　

01:49:22 - 01:51:36　

姚順雨:　

這很像當年adapt，一開始做了一個很fancy的demo，最初是作為research lab使用，後來轉向enterprise產品。我覺得dev也可能會往這個方向轉。　

趙宇哲:　

這確實是個很risky的轉向。　

Monica:　

那這個問題是僅限於model層面，還是有其他research需要解決？　

姚順雨:　

如果只是作為research benchmark去和GPT-4比較，能做到一個decent的水平。但要做成產品，很多low-level tasks可能就work不了，你可能需要工具支援。　

趙宇哲:　

對，從產品角度來說，假設我們現在有30%的成功率，提升到了50%。寫PR時50%是好的，但問題是透過unit test也不代表完全正確，unit test的coverage就是個問題。如果50%不好，誰來改它？如果它能自己改好就不會只有50%了。那程式設計師可能會想，我是不是自己寫一遍更快？　

姚順雨:　

但你覺得unit test真的能達到完美的evaluation嗎？　

趙宇哲:　

我們內部試過，效果沒那麼好。 GitHub上很多專案甚至都不寫unit test，品質也參差不齊。而且透過unit test不代表程式碼就對了，有時候程式碼錯一點點通不過測試，但實際程式碼品質也沒那麼差。　

01:51:36 - 01:52:22　

你的test品質可能沒那麼好，但PR相關的test會稍微好一點，因為它會涉及好幾個部分，而且有好幾個原有的test去cover。不過也不是所有PR的test都這麼好。　

姚順雨:　

我們當時做這個的時候，就選了比較高品質的test。　

趙宇哲:　

對，這就是很重要的部分。如果隨便選一個，那validation的效果就沒那麼好。我們試過這種情況。　

姚順雨:　

在理想情況下，假設你有一個非常高品質的evaluation，那麼即使是10%的隨機選擇其實也是可以work的，因為你可以試一百次，然後只要把unit test通過就行。　

01:52:22 - 01:53:46　

Monica:　

如果我們給AI一個test，想看它的完成準確率是多少。我們可以把範圍限定在junior engineer的任務上，畢竟你也不會給junior engineer太難的test。假設在這些junior的工作範圍內，它能達到80%、90%的完成機率。　

姚順雨:　

可以。　

趙宇哲:　

這個可以去設計，但就變成產品設計時要control你的user expectation 。你要考慮怎麼定義user，不要讓他們濫用這個功能。因為有些PR大有些PR小，簡單的PR讓AI做是很好的，但推產品時你需要把user定義得比較清楚，否則他們一開始就會覺得這個不行那個不行。　

Monica:　

這有點像我們招程式設計師一樣，你招不同level的人，佈置任務時也會考慮。例如給宇哲佈置任務和給一個剛畢業的佈置任務是不一樣的。我在想，當我們把agent也當成一個人來看的時候，我們assign task的方式是不是也應該不一樣。　

01:53:46 - 01:55:13　

李珎:　

對，這個事情正在發生，很多小的task，像是寫unit test、進行重構（rename）或是debug這些工作，都是可以交給junior engineer來做的。在軟體開發的各個步驟中，已經有許多新創公司專門針對這些任務開發產品，例如swift dev。　

我們發現需求定義越明確，完成的成功率就越高；需求越abstract，就越需要interactive的步驟和手動介入。所以我們對agent的思路是把它定位為協作夥伴，不是簡單地交付任務給它。它會在code base和repo中與你collaborate，當它在後台運行時遇到問題，會發送notification給你，讓你指導它如何proceed。　

01:55:13 - 01:56:06　

Monica:　

用戶不能太小白。這就像是甲方和乙方的關係，通常甲方什麼都不懂，這些東西是沒辦法的。　

李珎:　

這是不同level的問題。這樣的使用者不會問你技術層面的問題，而是會問需求上的問題。比如說你要做website，他會問你這個website要不要dark mode啊，你覺得這個好不好看，要不要改一改？ right，這些問題對於小白來說其實是make sense的，而且他需要問這些問題，這樣才能讓最終生成的東西符合你的期待。　

Monica:　

那其實這個agent就遠遠不止是一個coding的agent。　

趙宇哲:　

對，要求比較高，需要會跟人交流。　

Monica:　

這就像個乙方，我覺得這個真的很適合SWE-bench。　

01:56:07 - 01:56:46　

趙宇哲:　

如果這個agent真的很優秀，它就很適合當contractor來幫你完成工作。　

Monica:　

我們前面可能需要一個agent來evaluate，判斷這個問題是否能被現有的agent解決。如果目前agent無法處理，系統會將你分配到其他合適的agent 。它甚至可以幫你自動分配一些任務給人類操作員。　

李珎:　

我們可以想像這樣一個世界，你可以僱用很多不同的agent 。例如SWE-bench是一個可以僱用的agent，Devin是另一個選擇。你可以像查看LinkedIn履歷一樣，看到他們之前完成過什麼樣的任務，有什麼樣的工作記錄。　

姚順雨:　

最終還是要用賺錢多少來衡量，這是最基本的評判標準。　

01:56:46 - 01:58:00　

Monica:　

我注意到你們最近發表了一篇關於Olympia programming的論文，似乎是針對更複雜的數學問題。我很好奇能否介紹一下這個項目，以及它與SWE-bench有什麼關係？因為聽起來這兩個項目都在解決複雜的問題。　

姚順雨:　

這其實是coding這個問題的兩個不同frontier，是兩個完全不同方向的frontier。 SWE-bench本質上處理的內容沒有那麼複雜，它更關注的是long context和noisy context的處理。而Olympia problem則完全相反，它的問題和程式碼都很短，可能就十到二十行，但更注重grounded reasoning 、creative reasoning algorithm和organic reasoning 。所以一個是考驗你對長文本和複雜context的處理能力，另一個則是考驗你對CHV這個grounded的理解和augment。　

01:58:00 - 02:00:31　

Monica:　

你覺得解決數學問題和奧林匹克程式設計問題有什麼關係？　

姚順雨:　

我覺得奧林匹克程式設計問題更接近測試基礎模型的推理能力。比如說，有N個人站成一列，需要進行某些操作，問有多少種可能的方案。這類問題需要你在空間中進行想像，理解組合的意義，做world modeling和simulation 。傳統的軟體工程比較是pattern recognition ，例如搜尋stack workflow和複製程式碼，不太需要這種深度推理。　

李珎:　

軟體工程的問題只要投入足夠時間總是能解決，但奧林匹克程式設計有些問題即使投入再多時間也無法解決。　

詳全文 https://mp.weixin.qq.com/s/7XcdAvI6rROyzrGgM_6K2Q