一萬年太久,只爭朝夕 | Foundation model的進展仍不夠快
編者按:如今根基模型(Foundation Models)的應用和相關創新正在快速湧現,但仍有很大的提升空間,目前還無法充分發揮根基模型的潛能、將其高效快速地應用於企業級AI應用中。
根基模型的加速應用和落地,帶動了基礎設施和工具領域的創新。本期IDP Inspiration,我們為大家帶來的是創投機構Madrona對於根基模型的發展研判,和大家一同從投資人的視角探尋根基模型發展帶來的AI Infra新機遇。
以下是譯文,Enjoy!
作者 | Jon Turow, Palak Goel & Tim Porter
編譯 | 嶽揚
人工智慧領域目前的活動速度簡直令人驚訝。 基於根基模型(Foundation model),生成性AI應用程式和應用於資料的複雜推理的更大範疇的應用程式正在快速增多。 這些應用程式從實際的(加速程式碼開發[1]和測試[2]、法律合同[3]和奧斯卡提名電影的生產[4])到有趣的(多模態生成說唱對決)再到引人深思的(在美國醫學執照考試中或接近透過水平)。而根基模型的能力、模型準確性和基礎設施的演變速度至少與之一樣快。
如果所有這些感覺都不同,那是因為它們確實不同。以前雲端計算的出現提供了以前不可能的計算能力,使得包括 變換器(Transformer)模型在內的電腦科學的新領域成為可能。該模型[7]可以讓人們使用雲端計算來構建更大的模型,這些模型更好地推廣,並且能夠完成新任務,例如 文字和影像生成、彙總和分類。這些更大的模型已經顯示出複雜推理、知識推理和超出分佈穩健性的能力[8],而更小的、更專業化的模型都不具備這些能力。這些大型模型被稱為根基模型(Foundation Models),因為開發人員可以在它們的基礎上構建應用程式。
然而,儘管創新活動和步伐在飛速發展,未來仍然顯然不夠快,根基模型和生成式人工智慧尚未達到目標。
構建者們面臨一個不太令人滿意的選擇: 打天下(機遇根基模型構建應用)容易守天下(形成護城河)難,或者相反。 在前一種情況下,根基模型允許開發者在一個週末(或幾分鐘)內建立應用程式,而此前需要幾個月。但是,開發人員受到那些專有模型的現成功能的限制,其他開發人員也可以使用,這意味著開發人員必須富有創造力,找到差異化的來源。在第二種選擇中,開發人員可以擴充套件開源模型體系結構的功能,以構建一些新穎且易於形成護城河的東西。但這需要極高的技術深度,僅有極少數的團隊具備這種能力。能力集中在少數人手中與一個行業蓬勃發展所需要的恰好相反—— 我們需要更多的力量分散到更多的人手中,而不是更加集中。
但是,如果我們將大規模根基模型視為一種新的應用程式平臺,提取出更廣泛的技術棧,就會發現那些挑戰是創業者的機會。我們去年晚些時候寫了一篇文章,描述了這個棧,並預測工具層的出現。該棧發展如此之快(工具層也已經快速形成!),現在值得再次審視。
縱觀當今根基模型棧的狀態,我們發現了三個創業機會:
1)開發新穎的應用程式:技術較先進的團隊面臨著廣闊的前景。有很多創新可以做,特別是在 資訊檢索,混合模態和訓練/推理效率方面。這個領域的團隊可以推動科學的界限,建立以前不可能的應用程式。
2)尋找差異化:具有出色想法但僅有早期技術能力的團隊現在可以訪問工具,使得可以使用更豐富的記憶/上下文,更豐富的外部資料來源和API,以及評估和縫合多個模型的能力來構建更豐富的應用程式。這為創始人提供了更廣泛的途徑構建新穎且易防禦的產品,即使他們已經使用了廣泛可用的技術。
3)開發工具:喜歡基礎設施的團隊現在有一個高效率的機會,可以在 編排Orchestraction(開發人員框架,資料來源和動作,評估) 和 根基模型操作(部署,訓練和推理的基礎設施和最佳化工具) 方面構建工具。更加強大和靈活的工具將加強現有開發者的能力,並使根基模型棧能夠被更多的新開發者使用。
1 根基模型Foundation Models
開發根基模型的人面臨一個不吸引人的權衡——即基於模型構建新的應用程式的難易和對模型保護的難易之間的權衡,該權衡源於核心基礎模型的建立和開源方式。 開發者今天必須在 iPhone/Android,Windows/Linux 風格的戰爭中選擇一方,在每一方都有痛苦的妥協。
一方面,我們看到來自 OpenAI、co:here 和 AI21 等高度複雜、快速演變的 專有模型 (我們也可以把谷歌加入到這個名單中,因為他們在這些模型上花費的時間比任何人都長[9],而且計劃將模型外部化[10])。另一方面是 開源架構,如 Stable Diffusion[11]、Eleuther、GLM130B、OPT、BLOOM、Alexa Teacher Model 等,都在 Huggingface[12] 上組織成社群中心。
1.1 專有模型
專有模型是由擁有雄厚資金和技實力的提供商所擁有的,這意味著他們可以提供行業領先的模型效能。它們的現成模型也意味著開發人員可以輕鬆上手。Azure的新OpenAI服務使得入門變得比以往更容易,我們預計這將加速開發人員的實驗速度。
這些人也在考慮成本——OpenAI 在2022年末將價格降低了60%,Azure 也相應的調整了價格。但是這裡的成本仍然很高,限制了商業模式的可持續性發展。按席位許可證(per-seat licenses )和基於使用定價(consumption-based pricing)等模式在早期很普遍,這些可以持續。但是廣告支援的業務模型可能不會產生足夠的收入來覆蓋這一水平的成本。
1.2 開源模型
開源模型的效能不如專有模型,但是在過去一年中有了顯著改善。更重要的是, 技術複雜度高的建設者可以擁有擴充套件這些體系結構的靈活性,並建立尚不可能用專有模型實現的差異化功能(這是我們喜歡 Runway 的原因之一,Runway 是一個下一代內容生成套件,提供實時影片編輯、協作等。為了支援所有這些功能,Runway 繼續對多模態系統和生成模型的科學做出深入貢獻,以加速 Runway 的客戶的特徵開發)。
專有根基模型和開源根基模型之間的緊張關係已經像iPhone/Android 的戰爭一樣。 專有模型的優勢是效能和易於上手。開源模型的優勢是靈活性和成本效率。 可以肯定的是每個陣營都會加大投資以解決其弱點(使 OSS 模型更容易上手,並使其有可能更深入地擴充套件OpenAI模型),同時也要充分利用它們的優勢。
2 Tooling / Orchestration
強大、靈活的工具能夠使現有開發者的能力變得更加強大,使更多的新開發者能夠使用根基模型技術棧。
我們在2022年10月寫道[13]:“根基模型並不是’just work’僅執行即可,因為它們只是廣泛的軟體棧中一個組成部分。如今,從根基模型中得到較好的推理效果,需要應用開發者採取很多輔助措施“。
我們確實看到開發人員在軟體棧的這一層次上有密切關注。很多最酷的、回報較高的工作將在未來幾個月內發生在軟體棧之上,特別是在開發者框架、資料來源、最佳化措施以及評估方面。
2.1 開發者框架
過去的經驗告訴我們,框架(dbt,Ruby)對於將大型應用程式的各個部分連線起來是很有用的。根基模型開發框架讓開發者很容易地將諸如 跨多個呼叫的Context、提示工程和根基模型的選擇(或多個模型的順序) 結合起來。研究人員已經開始量化[14]這些使用根基模型構建的應用有多麼強大。LangChain[15]、Dust.tt[16]、Fixie.ai[17]、GPT Index[18]和Cognosis[19]是這部分軟體棧中最吸引開發者的專案。不好描述上手其中一些框架是多麼容易。但是演示起來真的很容易,所以我們現在就給大家演示一下。下面是LangChain開發者指南中的四行入門程式碼:
這樣的開發者框架使入門使用根基模型變得十分簡單,甚至幾乎成為一種樂趣。敏銳的開發者可能會注意到,透過上面的程式碼,如果開發者想要更換已啟動的 應用程式底層LLM/FM,幾乎不費吹灰之力。從長遠來看,使開發變得更容易往往會帶來更多的開發者,並加速新應用程式的出現。在工具層面的創新速度已經非常快,這為工具的開發者和使用工具建立新應用程式的開發者創造了很多機會!
2.2 資料來源和最佳化措施
如今根基模型只會推理它們接受訓練的那些事實。但這對於需要根據變化極快的現實資料做出決策的應用開發者和終端使用者來說,是個很大的限制,比如 天氣、金融市場、旅遊市場、供應庫存等等。因此,當我們想進行“hot” information retrieval時,這將是一件大事。在這種情況下,我們不需要訓練或編輯模型,而是讓模型呼叫外部資料來源並實時推理這些資料。Google Research和Deepmind在這個方向上發表了一些不錯的研究論文[20],OpenAI也是如此。所以,“hot” information retrieval時代即將到來,特別是目前在這個領域的研究成果轉商業應用的速度非常快。
上述提到的開發者框架預見到了根基模型科學的演變,並開始支援一些外部資料來源。按照類似的思路,開發者框架也將支援一些”下游“領域的概念(比如呼叫外部API,如Salesforce、Zapier、Google Calendar,甚至AWS Lambda serverless計算函式)。透過這些外部資料和最佳化措施的整合,很多新型根基模型應用將變得可能,而這在以前是很難或不可能的,特別是對於在專有模型之上構建應用的早期團隊。
2.3 評估
我們在2022年10月[13]寫道:“我們必須小心謹慎對待根基模型,因為我們永遠不知道它們會說些什麼或做些什麼。這些模型的提供者,以及建立在它們之上的應用開發者,必須接受承擔這些風險的責任。”可以預見開發人員在這方面很快就會變得更加成熟。Academic benchmarks(學術評估基準)是評估模型效能的重要步驟。但是,即使是像HELM這樣最複雜的評估基準也是不完美的,因為它們 不是面向所有使用者群或所有特定使用案例而設計的。
好的測試集來自於終端使用者。生成的建議中有多少被接受?chatbot有多少次對話的 "轉折"?使用者在一張特定的圖片上停留了多長時間,或者他們分享了多少次?這些型別的輸入總體上描述了一種模式,然後開發者可以用它來定製或解釋一個模型的行為,以達到較好的效果。HoneyHive[21]和HumanLoop[22]是兩個典型的公司,它們幫助開發者迭代根基模型架構,修改提prompts,過濾和新增新的訓練集,甚至提煉模型以提高指定用例的推理效能。
3 Tooling / FMOps
計算是根基模型公司的主要成本驅動因素,制約了他們可以選擇的商業模式。新一代的部署最佳化、訓練工具和基礎設施,正在幫助開發者解鎖新的商業模式。
根基模型對訓練和推理有巨大的計算要求,需要大量的專業硬體,這導致應用開發者面臨高成本和運營限制 (吞吐量和併發量) 。大公司有實力來維持,微軟在2020年建設了世界前5名的超算基礎設施用於支援OpenAI發展。但是,即使是巨頭公司也面臨著供應鏈和經濟上的限制。因此,訓練、部署和推理最佳化是投資的關鍵領域,在這裡我們看到了大量的創新點和機會。
3.1 訓練
現在開源根基模型的修改和再訓練比以往要容易。 大根基模型(foundation models)訓練費用超過1000萬美元,而Chinchilla[23]和Beyond Neural Scaling Laws[24]等論文表明,根基模型可以用50萬美元甚至更少的費用訓練,這意味著更多的公司可以自己建立根基模型。如今,AI從業者可以獲取很多大規模的資料集,如LAION[25](影像)、PILE[26](多樣化的語言文字)和Common Crawl[27](網路抓取資料)。他們可以使用Snorkel[28]、fastdup[29]和xethub[30]等工具來策劃、組織和獲取這些大型資料集。他們也可以訪問HuggingFace獲取更新和最強大的開源模型架構。他們還可以使用來自Cerebras[31]、MosaicML[32]等訓練基礎設施來大規模地訓練這些模型。這些資源對於利用更新的模型架構、修改重構這些架構的程式碼,然後在公共和專有資料的基礎上訓練私人模型是非常強大的。
3.2 部署和推理
持續的推理成本沒有像訓練成本那樣急劇下降。大部分的計算成本將最終用於推理,而不是訓練。推理成本最終對開發者造成了更大的限制,因為它也限制了公司可以選擇的商業模式。 Apache TVM[33]等部署框架以及蒸餾和量化[34]等技術都可以幫助降低成本,但這些都需要相當的技術深度才能使用。OctoML[35](TVM的開發者)提供可以降低成本和部署時間的管理服務,並能更好利用很多算力硬體。這使得更多開發者可以使用這些型別的最佳化,同時也讓開發者能夠更有效地工作。很多託管推理公司,如Modal Labs[36]、Banana[37]、Beam[38]和Saturn Cloud[39],也想要使推理比直接在AWS、Azure或GCP等超級伺服器上執行更具成本效益。
4 #HereWeGo
對於大規模foundation models(根基模型),我們才剛剛開始觸及表面。大型科技公司和資本雄厚的初創公司正在大力投資於更大、更好的模型、工具和基礎設施。 但好的創新需要無畏的技術和產品靈感。
圍繞根基模型相關的創新仍然會源源不斷,但是其速度和質量將會受到很多限制,直到軟體棧足夠完善能夠讓僅在某一方面有突出優勢的團隊也能作出巨大貢獻。 這些工作都需要由大科技公司及其創始人、學者、開發者、開源社群和投資者共同完成。同時,所有這些創新都需要考慮有沒有倫理道德負面影響,有沒有潛在的意外後果,並將必要的防護措施做到位,這至少與推進技術本身具有同等重要性。
要讓未來AI驅動的高質量應用源源不斷的出現,這需要我們所有人共同努力。我們期待看到企業家們提出什麼新的想法來幫助釋放根基模型的真正力量,並實現人人期望的廣泛創新和影響力。
本文經原作者授權,由Baihai IDP編譯。如需轉載譯文,請聯絡獲取授權。
原文連結:
關於原作者: 作者Jon Turow, Palak Goel & Tim Porter來自Madrona Venture Capital,在根基模型基礎設施進行了多次投資,並致力於幫助加速根基模型未來的到來。從事或者對根基模型領域的應用程式、根基模型構建及其工具感興趣的小夥伴,可與原作者(jonturow@madrona.com和palak@madrona.com)聯絡。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70018536/viewspace-2938229/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- CS 839: FOUNDATION MODELS
- 什麼是人工智慧領域的 Foundation Model?人工智慧
- Laravel ORM 對 Model::find 方法進行快取LaravelORM快取
- 只改變IDE是不夠的IDE
- Google仍不滿Vista桌面搜尋 稱微軟修改很不夠Go微軟
- 3.2.2的Model的快取邏輯快取
- 更要只爭朝夕,人工智慧的尷尬2019及破局2020 | 三大技術九大行業解析人工智慧行業
- 一個無競爭的快取快取
- 端側AI進化論:HUAWEI HiAI Foundation的奇妙旅程AI
- Spark只比Hadoop快19% ?SparkHadoop
- 單例--只寫一次就夠了單例
- 專案進展快,全靠 iView 帶 | 掘金技術徵文View
- nginx 只快取靜態檔案Nginx快取
- python 操作 mysql 只看這篇就夠了PythonMySql
- Webpack 4進階--從前的日色變得慢 ,一下午只夠打一次包Web
- Java 與 .NET 的平臺發展之爭Java
- 快取行競爭和偽共享快取
- iOS引用轉換:Foundation與Core Foundation對iOS
- 推薦文章:Java足夠快嗎?Java
- Laravel_Model_Cache(針對快速更新的數值屬性進行快取優化的外掛)Laravel快取優化
- 車聯網進入快車道,如何突破發展瓶頸?
- 谷歌與ChatGPT展開直接競爭谷歌ChatGPT
- 外包做的太久,分享下用的admin後臺模板
- 快取架構,一篇足夠?快取架構
- 分散式事務,只看這一篇就夠了分散式
- 工信部:我國人工智慧發展已經進入快車道人工智慧
- 券商線上業務發展提速,博睿宏遠為證券行業發展按下“快進鍵”行業
- Google微軟競爭向縱深發展Go微軟
- [譯] 一文帶你看完 2019 開年瀏覽器之爭的最新進展瀏覽器
- JavaEE 7的最新進展Java
- RxJava2 只看這一篇文章就夠了RxJava
- 夠快雲庫可用性測試記
- iOS - Foundation相關iOS
- 朝夕光年——今日頭條的“遊戲據點”遊戲
- 看了Observer,仍不懂,高手指點Server
- 關於郵件傳送,只看這一篇就夠了!!!
- Android Architecture Components 只看這一篇就夠了Android
- Android 單元測試只看這一篇就夠了Android