我們如何在十個月內將 ARR 從 0 增長到 1000 萬美元以上？

作者 | Anshul Ramachandran
譯者 | 王強
策劃 | 褚杏娟 2022 年 11 月，我為 Latent Space 撰寫了第一篇客座博客文章，并且（樂觀地）希望它能成為三部分系列中的第一篇：如何選擇長期 AI 產品戰略（https://www.latent.space/p/what-building-copilot-for-x-really）；第二篇：如何讓你的 AI 產品有區分度（https://www.latent.space/p/ai-ux-moat）我們的企業產品在不到一年的時間內從零增長到了超過 1000 萬美元的 ARR，所以是時候發布第 3 篇了。也許令人驚訝的是，我們要做的事情不像 enterpriseready.io 等網站所說的那么簡單。早在 2022 年 11 月，我就為這三個主題寫好了論文，但當我寫第一篇文章時遇到了一個小問題。那時我們剛剛發布了 Codeium，因此雖然我可以談談第一個論點（強大的產品策略來自對經濟學和用例細節的深刻理解），但我們當時并不一定與其他 AI 代碼助手有所區別（每個工具都只是自動完成而已），而且我們肯定沒有在賺錢。兩年后，越來越明顯的是，出于質量和成本的原因，公司需要大大超越單純的模型 API 調用方法，而任務特定模型、托管開源模型、RAG 等主題都已開始流行。2023 年夏天到來了，我們已經對 IDE 內體驗做了 GA，其中包括代碼鏡頭和直接插入代碼等特性，這些功能在當時是非常新穎的。那時 GitHub Copilot 還要幾個月才會 GA 他們的功能。到那時，我有了足夠的信心認定我在第二篇論文中的論點是正確的——用戶體驗將是創造差異化護城河的關鍵，無論是在短期還是長期皆是如此。一年多之后，我認為這一論點比以往任何時候都更正確，人們真正意識到擁有非常直觀和強大的用戶體驗是多么重要，這種體驗在某種程度上隱藏了底層模型和推理的復雜性。看看 Perplexity 或 Glean，甚至在我們這個領域，看看 Zed 或 Cursor。他們的技術不錯，用戶體驗也很棒。不過，當時在寫我的第三篇論文時仍然存在一個小問題。個人版 Codeium 過去是免費的，現在仍然是免費的，我們剛剛推出了付費企業產品，所以我們還不一定能賺錢。所以我還不能寫關于如何用人工智能產品賺錢的文章。沒有證據的觀點就是猜測。好吧，正如前面提到的，我們的企業產品在不到一年的時間內就達到了八位數的 ARR。在 B2B 軟件世界中，這可算是很快了。所以在過了一年后，我希望在關于生成式人工智能產品的見解上取得三連勝。那么第三篇論文的論點是什么？如果你想在生成式人工智能領域持續賺錢，你必須是“企業基礎設施原住民”。
什么是企業基礎設施原住民？
成為企業基礎設施原住民意味著公司從一開始就有實力讓其產品用于最艱難的企業環境，例如財富 500 強、受監管的行業、百年老店。在舊金山和硅谷，我們經常被困在泡沫中。例如，如果我們要為企業開發代碼助手，考慮客戶時卻只想到了硅谷的公司，我們就會錯過真正的市場機會。美國前十大銀行雇用的軟件開發人員比 FAANG 全員都多，而這只是少數幾家銀行，而且只是美國而已。僅摩根大通一家就有超過 4 萬名技術人員。簡單的谷歌搜索結果顯示，Meta 的員工中有大約 3.2 萬名軟件工程師。而且現實情況是，這些非科技企業有很多約束，而這些約束不會出現在個人用戶或“數字原住民”硅谷科技公司身上。為了推出 MVP，盡快迭代產品，同時還能獲得用戶，企業自然會選擇消除這些約束，只關注硅谷用戶。“企業基礎設施原住民”公司的秘訣在于，他們不會屈服于這種屬性，不會在一開始就忽略這些約束。為什么？因為以后再引入這些約束要困難得多。這當然會更難，因為你可能會做出很多錯誤的設計決策。例如，你構建系統時可能選擇了一種難以容器化的方式，部署到一個自托管系統上（典型的 SaaS 到本地問題），而這正是許多大型受監管公司想要的。或者你忘了基于規則的訪問控制和其他安全考慮，因為你只是假設每個員工都可以看到所有數據。或者使用了不符合 HIPAA 合規性的系統，忘記添加審計系統，或者忽略了構建深度遙測的需求。但還有其他一些本質因素會導致企業在之后很難糾正錯誤。首先，你可能不會針對現實的完整狀態進行迭代，而且企業與消費者其實完全是兩碼事。例如，在我們的 AI 編程領域，如果你只為單個開發人員進行迭代，你將永遠不會意識到一個非常先進的，可以處理龐大、雜亂且通常過時的代碼庫的推理系統的重要性。這不是你的業余愛好者和硅谷開發人員客戶在構建從 0 到 1 的項目時所要做的事情。另一方面，你的團隊可能會發展得太快，以至于你沒有合適的專業知識來對這些約束做迭代。例如，為了滿足安全約束，客戶要在本地運行生成式 AI，所以我們需要本地 GPU，但這意味著我們的計算能力是有限的（大多數應用程序都不會讓人們為其購買一個機架的 H100）。這意味著我們需要實施很多非常重要的基礎設施優化技巧，以彌補我們無法在后臺“擴展算力”的劣勢。如果整個團隊此時更像是一個產品團隊，而不是一個在 GPU 基礎設施方面具有專業知識的垂直團隊，那么你就無法取得成功。如果你在早期由于忽略了許多約束而加快了步伐，那么當將來不可避免的企業轉型到來時，你會發現自己構建了錯誤的架構和團隊。這也能解釋為什么生成式 AI 流行之前成長起來的公司通常難以適應這種新模式——他們沒有一支將生成式 AI 視為自身 DNA 核心部分的員工隊伍。有些產品必須要有“企業基礎設施原住民”團隊才行，因為從定義上講，它們只適用于這類企業。例如，Harvey 對個人用戶來說就不合適。但絕大多數問題域都可以選擇是否在一開始就考慮這些約束。企業基礎設施原住民公司會有意選擇克服所有這些約束的障礙。我想明確一點——“企業基礎設施原住民”確實意味著需要付出更多努力來迭代產品。簡單來說就是約束更多了。話雖如此，如果這種本能從一開始就融入公司的 DNA，它就會成為一種做事方式。結果你在構建系統時，從一開始就會讓系統更容易在這些約束下進行迭代，你還會解決一個巨大而急迫的企業文化挑戰。同時，這并不意味著你必須等到某個特性適用于每家企業后才發布它。例如，我們有一些 SaaS 企業層可以更快地部署特性并獲得反饋。成為“企業基礎設施原住民”意味著，公司中至少有一些人應該積極思考如何讓該特性最終能適用于所有企業。我之所以稱之為企業基礎設施原住民，而不僅僅是企業原住民，是為了強調基礎設施這個部分，這并不奇怪。絕大多數額外的約束都表現為技術軟件基礎設施問題的形式，因此這凸顯了你要在技術棧中特別關注才能做好工作的那些部分，下面很快會具體展開。這就是為什么我一直認為 enterpriseready.io 等網站上的建議沒有切中要害。雖然你確實需要考慮變更管理、基于規則的訪問控制、SLA 和支持等問題，才能讓你的 SaaS 工具為企業做好準備，但這些指南給人的感覺是“如何修補已構建好的產品”，而不是“如何從一開始就構建正確的產品”。現實情況是，有時過早優化確實會帶來回報。我認為在生成式 AI 時代，采用“修補你的產品以備企業使用”的方法比傳統的 SaaS 產品更危險，因為引入的約束會更棘手，而且局勢變化如此之快，以至于你可能沒時間修補你的工具，因為總會有人一直在思考產品方向，并正確地抓住了市場機遇。來自 EnterpriseReady。發現什么明顯錯誤的地方了嗎？
為什么是“非科技”企業？
如果你看到了這里，你可能會糾結于一個核心問題——所有這些都是在談論向非科技原住民企業銷售產品，但 B2C 市場或更多數字原住民科技公司呢？為什么不考慮在這些市場中賺錢？這里的重點是要理解為什么在可預見的未來，生成式人工智能初創公司的收入將來自非科技企業。選擇企業而非個人市場的第一個論點是，企業一直有錢購買軟件。微軟顯然擁有龐大的 B2B 部門，谷歌和 Facebook 也從企業廣告商那里獲得了巨額收入。如果你今天正在用生成式人工智能構建產品，那么今天的價值主張就是完成更多工作或做更多創造性工作。企業愿意為這一價值主張投入巨額資金，說服幾家大企業就相當于說服成千上萬的個人。非科技企業優于科技企業的第一個理由是，所有大型科技公司都非常重視人工智能，并且擁有大量資金來嘗試自行開發。這里指的不僅僅是 FAANG 公司——開源 LLM 和易用的 LLM 相關框架的可用性使擁有開發 DNA 的公司更愿意自行開發而不是購買服務。所有大型科技公司都在嘗試自己抓住市場機會。想象一下我們試圖將 Codeium 賣給微軟，這可不是什么好事。大型科技公司對構建生成式 AI 產品的興趣也應該會讓任何從事 B2C 業務的人們感到害怕，因為大型科技公司已經擁有龐大的 B2C 基礎資源與巨大的分銷渠道。我們已經看到了這一點。Perplexity 正試圖在 B2C 搜索市場與谷歌競爭，他們還必須做一些備受質疑的事情，比如在后端使用谷歌。另一方面，Glean 正在進軍 B2B 搜索市場，并且在這個領域做得很好，而大型科技公司目前還沒有太多動作。大型科技公司的興趣也讓其他人更難爭奪科技原住民企業的業務機會，因為這些企業通常比非科技原住民公司受到的約束更少。大型科技公司的速度足夠快，可以解決那些較容易克服的約束，但初創公司可以利用他們的速度來解決非科技原住民企業可能遇到的更復雜的約束，從而脫穎而出。我們在 Codeium 經常看到這種情況。盡管幾乎每家大型科技公司都有代碼助手產品，但對于許多非科技原住民公司來說，我們到頭來并沒有與它們中的任何一家競爭，因為我們的產品以獨特的方式應對了這些公司所面臨的約束。我們將在下一節中詳細說明這些約束都有哪些，以及如何解決它們。我知道大家現在可能在想什么。但是 OpenAI 呢？他們憑借 ChatGPT 在 B2C 領域取得了巨大成功。我首先承認，考慮到 OpenAI 已經研究這項技術很長時間，這是一個很大的例外。如果你現在開始構建產品，你并不會有他們這樣的技術。實際上，隨著用戶開始嘗試其他模型（例如 Anthropic 的 Claude 3.5 Sonnet 似乎備受開發人員的歡迎），以及用戶嘗試 ChatGPT 以外的基于的產品（例如 Perplexity），人們現在想知道 OpenAI 是否真的能長期留住客戶。B2C 市場是無情的。
如何成為企業基礎設施原住民企業
好的，希望到現在為止我已經讓你理解了應該成為企業基礎設施原住民企業背后的邏輯。但在實踐中到底意味著什么？我們從一開始需要注意哪些事項？還好，我可以回來講講我們在 Codeium 積累的經驗。數據是許多企業基礎設施原住民考慮的根本原因之一。與現有的 SaaS 解決方案不同的是，在現有 SaaS 解決方案中，數據雖然可能很敏感，但可以通過系統來跟蹤它們，而 LLM 的大黑匣子屬性則增加了很多不確定性。無論是用于訓練的大量數據，還是對所生成數據的可追溯性缺乏透明度，都是這種不確定性的體現。
安全性
要使生成式 AI 工具發揮作用，你需要處理一些隱私數據。可以確認的是每家企業都有針對你的工具要處理的那些數據的，關于隱私和安全性的現行政策。例如，我們在 Codeium 處理代碼，如果公司使用 SCM 的自托管版本，那么他們已經證明他們的代碼默認策略是不將其發送到第三方服務器，即使第三方擁有所有認證，例如 SOC2 合規性，也不行。在基礎設施方面需要考慮的最重要的一點是你應該提供的部署選項集合。一般來說，你要么需要一個完全離線部署的自托管部署選項，要么至少需要一個混合版本，其中所有的持久隱私數據（或從隱私數據派生的信息）都保留在客戶的租戶內。你應該考慮將解決方案的服務端容器化，以便簡單地部署它（單節點系統使用 Docker compose，多節點系統使用 Kubernetes/Helm），并確保客戶端具有安全指向客戶服務器實例的功能。這些部署面臨許多挑戰，尤其是自托管部署。其中一些包括：確保你設置了自己的鏡像掃描，這樣就不會出現安全漏洞，像 Google Artifact Registry 這樣簡單的掃描程序都可以。客戶也會使用自己的掃描工具，而且有很多不同的掃描工具，所以要做好準備。建立持續更新和發布的系統（大多數客戶更喜歡“拉取鏡像”更新解決方案，而不是供應商提供的“推送鏡像”方法）。實際的更新頻率取決于你期望的產品發展速度——如果用戶體驗變化很大，也許最好每隔幾周發布一次，但如果用戶體驗相對穩定，而且更新主要是研究性開放式推理改進，那么每月或更短一些的發布時間應該沒問題。更快的發布周期的一個普遍好處是，如果發布版本中存在錯誤，那么在穩定版本中修復它們所需的時間會更少（如果問題嚴重，則需要單獨的補丁）。確保你的方案既能跑在超大規模集群，也能在本地 OEM 可以提供的機器上運行。我可以寫一整篇文章來討論誰能獲得哪些 GPU 和背后的，但你經常會看到各種差異，例如 Azure 和 GCP 上提供 1xA100 和 2xA100 實例，但 AWS 上只有 8xA100 實例可用。正確調整昂貴的 GPU 硬件規模以盡可能降低解決方案的 TCO，是創建更好的 ROI 故事的關鍵所在。一定要幫助客戶在他們的第一批 GPU 部署中跑通一個部署流程。另外，即使你認為自托管或混合部署過于復雜，你仍需要考慮為你的 SaaS 解決方案提供許多證明和認證。SOC2 Type 2 是基本要求，這要求在一段時間內設置控制措施并接受對這些控制措施的遵守情況的審核，因此需要數月的準備時間才能獲得此認證。ISO 27001 更進一步，歐洲公司經常詢問這一條（盡管由于 GDPR 的要求，即使有此認證，你可能仍需要考慮在位于歐盟的服務器托管你的解決方案）。最后，如果美國是潛在客戶（這里有很多利潤空間），你將需要考慮 Fedramp（針對民間機構）和 Impact Levels（針對國防部）認證。要獲得這些認證，你需要做很多事情，例如容器化你的應用程序，這是你在自托管部署中必須做的事情。如果你在構建 SaaS 應用程序時沒有考慮到這一點，做起來就會困難很多。最后一點比較明顯，如果你最后是在自己公司這邊處理客戶數據，就不要用這些數據來訓練。聽起來很簡單，但這仍是客戶最大的擔憂，因為這種風險依舊占據著媒體頭條。每一份合同都會要求寫明這一點（如果不寫明，則會在紅線中添加進去）。我們從未嘗試過以折扣換取使用客戶隱私數據訓練通用模型的權利，因為從未有任何跡象表明人們會接受這種做法。這種軟件并不昂貴，公司甚至不會考慮折扣和 IP 隱私之間的權衡，尤其是在判例法尚未建立的地區。有些人可能認為現實并不公平。雖然很多公司確實在使用大型科技公司的云服務，但潛在客戶對初創公司的安全性的信任度要低得多，因此他們可能對安全性的要求比對大型科技公司的要求更高。這就要求你誠實地說明你的解決方案在各種部署選項中都有哪些功能。你的自托管選項通常不會像 SaaS 托管選項那樣有著豐富的功能，因此，如果你用的是自托管版本，而不像大型科技公司對手可以使用 SaaS 版本，你是否會讓自己陷入困境？
合規性
只需搜索“生成式 AI 訴訟”，你就會明白我的意思。由于這些 LLM 是用大量數據訓練的，并且不可能將這些概率系統的輸出追溯到特定的訓練數據示例，因此這里存在大量之前沒遇到過的全新合規性問題。首先，許多模型都是使用它們可能不應該使用的數據來訓練的，例如受版權保護的圖像或非授權代碼。許多企業法律團隊擔心使用這樣的系統會導致他們在未來卷入訴訟（就判例法而言，這個領域非常落后）。因此，如果你是企業基礎設施原住民，你需要控制用于訓練模型的數據，無論你是在訓練自己的小型模型，還是在開源模型上執行其他任何針對任務的預訓練過程。可以考慮實施數據清理措施，這樣你就可以自信地向企業聲明，你不使用受版權保護的材料進行訓練。還可以多做一點，例如我們從訓練數據中刪除了所有非許可代碼，也刪除了所有與明確的非許可代碼具有相似編輯距離的那些代碼（以防其他人復制粘貼了那些非許可代碼卻沒被發現）。即使模型本質上是概率性的，主動充分展示你們的做法也會增加最終客戶的可信度，畢竟他們的法律團隊可能會在你提供任何價值之前就把你拒了。哦，關于這個話題，不要違反其他服務條款。OpenAI 的服務條款規定，你不能使用他們的模型的輸出作為訓練材料。所以不要這樣做，你會驚訝地發現有多少人忽略了這一點。你可以主動做很多工作，但有眼光的企業會發現這些模型是概率性的，并希望模型生成的數據能有某種保證。這里你就必須巧妙地構建一個歸因系統，可能基于編輯距離和相似度分數的一些啟發式方法。例如，我們構建了更高級的歸因過濾器，而不僅僅是其他工具采用的簡單字符串匹配方法。這往往還不夠。我們為所有被允許的代碼匹配構建了 歸因日志，為特定受監管行業構建了 審計日志，內置了為醫療保健公司提供 BAA 的支持，等等。所有這些很快就會變成基礎設施問題。你確實需要非常認真地對待這一點，因為作為一家初創公司，與安全性的主題類似，你需要有行業領先的賠償條款，或者至少與大型科技公司提供的條款相匹配，才能在風險角度上獲得客戶的認可。你要對解決方案的這一方面有真正的信心，否則這種條款會有很大的危險。這些工作流都不一定“令人興奮”，因為從最終用戶的角度來看，產品并沒什么變化，但它們依舊是必要的。
個性化
你認為一個通用系統經過大量公開數據的訓練就能為企業解決問題嗎？大多數企業認為他們的工作很特別，而事實是，即使他們的技術棧不是那么獨特，他們也確實有大量隱私數據，這些數據與想要生成更多隱私數據的人工智能系統高度相關。對我們來說，現有的私有代碼庫是創建高質量結果的最相關信息，同時它們能盡可能減少幻覺，因為它們包含現有的庫、語義、最佳實踐等知識。又要提到安全性了，你可能也習慣了。你無法在每次推理時都處理所有原始私有數據，因此你可能需要對數據做一些預處理，并且必須將這些信息保存在某個地方。這就是純 SaaS 解決方案的問題所在。即使你能做到，也要付出更多努力才能說服企業客戶允許初創公司擁有這種訪問和控制他們數據的權限，這就對你能做到的個性化程度帶來了很大約束。問題還不僅限于他們的 IP 與外部來源通信時的安全性考慮。基于角色的訪問控制（RBAC）對于 AI 應用程序是非常重要的，因為 AI 工具本身就能提供一種途徑，將只有某些員工才能訪問的數據廣泛泄露給其他員工。同樣，這種問題也是新出現的，因為生成式 AI 是第一批可以創建出和已有數據很像的新內容的技術之一。一個極端的例子是，事實證明，對于項目來說，一堆數據單獨存放時可能不是問題，但組合在一起時就會變成機密數據。個性化和人工智能技術具有整合信息的能力，但應謹慎對待。每當你計劃使用隱私數據時，都需要考慮許多因素，尤其是對于較老的企業更是如此。使用 AI 技術時更要注意，因為輸入數據的質量在很大程度上決定了生成數據的質量。現有數據的年限是多少？數據與當前手頭的任務有多相關？哪些數據源更重要？如何平衡來自多個數據源的信息？個性化是每家初創公司都應該利用的一個軸心，因為它增加了差異化價值，而大多數大型競爭對手推出這些價值的速度會更慢——這些系統具有很大挑戰性，這里的錯誤很容易導致他們陷入巨大的公關噩夢。不過我們應該知道有很多基礎設施可以做好這件事情。
分析和投資回報率報告
分析對于企業軟件工具來說不是什么新鮮事物，但鑒于市場對 AI 技術的期望過高，AI 非常需要分析技術。我們可能很快就會擺脫這種過高的期望，但這并不能改變這樣一個事實：大多數潛在客戶并不完全清楚他們對生成式人工智能的期望是什么，也不知道如何量化其價值。證明投資回報率可能是最難的問題。即使對于像代碼生成這樣具體的事情，其中生成式人工智能工具的輸出是可以驗證的（代碼必須編譯、運行并執行預期的任務），所謂“開發人員生產力”的含義也非常模糊。它指的是拉取請求周期時長嗎？也許吧，但那里有太多混雜變量，很難真正評估單個工具是否對這個值的任何變化負責。是接受的代碼量嗎？也許這是一個很好的價值代表，但很明顯，一半的代碼來自人工智能并不意味著開發人員的生產力提高了一倍。我可以想象，對于營銷文案等應用來說這更加困難，因為這些應用的輸出結果首先就不一定是可驗證的。我首先承認我在這里真的沒有答案。證明投資回報率是一個非常困難、難以捉摸的問題。話雖如此，生成式人工智能確實受益于這樣一個事實：大多數領導者確實相信這項技術會增加價值，并且當員工說他們使用此類工具感覺效率更高時，領導會信任他們。因此，作為供應商，你應該考慮如何讓你的企業客戶逐步實現更多價值。例如，一個好的開始是按團隊來統計使用率數據。這樣，管理員就可以了解哪些組別獲得了更多價值，從他們那里收集最佳實踐，哪些組獲得的價值較少，可能需要更多支持。
延遲
我們在 Codeium 博客中經常討論延遲。延遲約束對生成式人工智能應用非常重要，因為它們直接影響模型選擇等事項。例如，代碼生成的自動完成任務需要在數百毫秒內運行完畢，開發人員才能及時看到建議。但由于 LLM 的自回歸性質，這就意味著所有的大規模基礎模型都用不了了。不管是量化還是推測解碼之類的方法都沒法解決超大模型的延遲問題。模型推理并不是延遲的唯一來源。所有個性化工作也可能帶來延遲。推理之前的任何檢索都需要符合延遲預算。將數據發送到單獨的服務器？你要考慮網絡延遲，特別是在處理視頻等密集數據時。對模型輸出進行后處理工作，例如對照歸因過濾器來做檢查？那就意味著這些過濾器也得是低延遲的。不出所料，這些都是軟件基礎設施問題。你可以構建世界上最智能的系統，但如果它的運行速度不足以滿足負載和用戶的需求，它也就沒什么用了。
規模
這一點更本質一些，它涉及上述所有挑戰。當你意識到這些企業的用戶 / 員工規模、他們擁有的數據規模以及私有基礎設施的復雜性時，所有這些挑戰都變得更困難了。我們的客戶擁有數萬個存儲庫、數億行代碼和數萬名開發人員。這些數字將擴展你的系統的所有方面。你是否創建了一個自托管系統來索引代碼庫以實現個性化？但如果現在客戶有數萬個存儲庫怎么辦，它們真的都對個性化有所幫助嗎？客戶如何指定哪些是好代碼，壞代碼？你如何在這種規模下管理對這個索引的更新工作？如何在不影響延遲的情況下將其擴展到數萬名開發人員？你如何管理數千個用戶組和訪問控制任務？不幸的是，我沒有時間或空間來一個個回答這些問題，但如果你不想在以后感到驚訝和手忙腳亂，那么在設計和構建解決方案時，你應該問自己這些問題。
總 結
從許多方面來看，這篇文章解釋了 Codeium 迄今為止在 B2B 領域的成功，讓我們深入了解了如何思考和合理化這個領域。與此同時，我希望我的這個論點是錯的，這可能會出乎你的意料。我希望看到初創公司即使在 B2C 和技術原住民的 B2B 市場中也能成功與大型科技公司競爭。我希望看到各種形式的企業最終將人工智能視為自己更向技術原住民靠攏的原因。自私地說，我希望看到像 Codeium 這樣的 B2B 成功企業被視為擁有最佳人工智能產品的創新型人工智能公司，而不僅僅是“企業級解決方案”供應商。但如果你是一家新創業公司，今天想通過生成式人工智能獲得可持續收入，我希望這篇文章能對你有所幫助！作為一家企業基礎設施原住民公司，你要習慣這種不舒服的感覺。原文鏈接：https://www.latent.space/p/enterprise?utm_campaign=post&utm_medium=web會議推薦12 月 13 日至 14 日（周五至周六），AICon 全球人工智能開發與應用大會將在北京盛大開幕！本次大會匯聚 70+ 位 AI 及技術領域的頂尖專家，深入探討大模型與推理、AI Agent、多模態、具身智能等前沿話題。此外還有豐富的圓桌論壇、以及展區活動，帶你深入探索大模型的最新實踐與未來趨勢。年度最后一次 AI 盛宴，讓我們一起見證 AI 未來。今日薦文ChatGPT Canvas免費啦！集成Python仿真器，支持在線修Bug，生產力飆升Sora 剛正式登場就把OpenAI系統干廢了！Altman緊急暫停新用戶注冊阿里合伙人為“爹味發言”道歉：自罰三個月工資；美圖出售加密貨幣獲利5.7億；虧損11億、上市對賭失敗，公司啟動全員降薪 | AI周報OpenAI深夜炸場！一口氣放出o1模型全家桶，月費200美元的ChatGPT Pro被狂槽：Altman只想躺在上數錢谷歌最強世界模型“硬控”OpenAI 一分鐘：智能體交互、替你玩游戲！等等，智能體們早在游戲里 cosplay、交友了！你也「在看」嗎？??