開源軟體是新創公司通往2B市場的特效藥嗎?

最近在幫忙開發一個零代碼的RAG自動化平台, 被問到了使用開源軟體的問題, 我剛好也在Linux社群幫忙維持一個開源軟體，最近Redis變更授權方案也曾經引起很多開發朋友的關注，就跟大家簡單介紹下各種開源方案與商業模式的關係。不過我先聲明，如果你在台灣或大陸目標是2B，不是很建議採用開源社區的方式來增加使用者基礎，通常是面對全球市場，也考慮把2D列入, 而且對現金流的產生方式有把握才需要深入了解。

當然你也可以來詢問我實施經驗。

截至2023年,96%的軟體都包含某種開源元件,開源軟體佔現代軟體解決方案的70%到90%。然而,在享受開源帶來的便利的同時,我們也必須思考如何讓開源項目獲得可持續發展。我將跟大家分享不同的開源授權方案、其背後的資金來源,以及相應的商業模式。如果是條款細節建議您諮詢有經驗的律師。

一、開源授權方案比較

1. Copyleft型授權(如GPL)

- 特點:要求衍生作品也必須以相同的授權分發,確保修改版本仍然開放可得。
- 代表專案:Linux內核、GCC編譯器、WordPress等。
- 優點:保護了開源精神,防止專有化;有利於社群貢獻和協作。
- 缺點:對商業應用有較多限制;可能影響專案的吸引力和普及度。

2. 寬鬆型授權(如MIT、Apache)

- 特點:允許將軟體用於各種用途,包括商業應用;要求保留版權聲明和免責條款。
- 代表專案:Angular、TensorFlow、Kubernetes等。
- 優點:靈活性高,有利於專案的採用和推廣;對商業友好。
- 缺點:修改版本可能不會回饋社群;品牌recognition相對較弱。

3. 商業原始碼授權(如BSL)

- 特點:禁止將程式碼用於特定的生產環境,但允許用於非生產目的;原始碼公開。
- 代表專案:MariaDB、CockroachDB等。
- 優點:在開放與商業之間取得平衡;為商業化提供了更多空間。 
- 缺點:對社群貢獻的吸引力可能稍遜;許可證更新可能影響使用者。

4. 雙授權模式

- 特點:同時提供開源版(通常是Copyleft型)和商業版,滿足不同使用者的需求。
- 代表專案:MySQL、MongoDB等。
- 優點:靈活性高,可根據實際需要選擇適合的版本;有利於專案的推廣和商業化。
- 缺點:兩個版本的維護和同步可能有額外開銷;商業版定價可能面臨挑戰。

二、開源項目的資金來源

1. 基金會和非營利組織

- 知名基金會:Linux基金會、Apache軟體基金會、OpenJS基金會等。
- 籌資方式:會員費、贊助、捐款等。
- 資金用途:支持專案開發、社群建設、基礎設施維護等。

2. 企業贊助

- 常見形式:直接資助、提供開發資源、舉辦活動等。
- 動機:培養開發者生態、提升品牌形象、獲取人才等。
- 代表企業:Google、Microsoft、IBM、Intel等科技巨頭。

3. 雲端服務商

- 商業模式:提供托管服務,或在雲平台上整合開源軟體,收取服務費。
- 代表企業:Amazon Web Services、Google Cloud、Microsoft Azure等。
- 爭議:有時會將開源專案商業化而引發社群不滿,如AWS與Elasticsearch的案例。

4. 群募(crowdfunding)和捐款

- 平台:Patreon、Open Collective、GitHub Sponsors等。
- 適用專案:較小型、社群驅動的專案;或核心開發者需要獲得報酬的情況。
- 挑戰:籌資規模相對有限;可持續性有待觀察。

5. 開源軟體即服務(Open SaaS)

- 模式:在開源軟體的基礎上,提供托管服務並收取訂閱費。
- 代表公司:WordPress.com、GitLab等。
- 優勢:使用者無需自行部署和維護;為開源專案帶來持續收入。

三、商業模式比較 

1. 開源軟體+企業服務

- 模式:核心產品開源,通過提供諮詢、培訓、定制開發等服務獲利。
- 代表公司:Red Hat、Canonical等。
- 優勢:服務具有專業性和針對性;與客戶建立長期關係。
- 挑戰:服務業務的可擴展性相對受限;需要大量優秀的技術人才。

2. 開源軟體+商業許可

- 模式:提供額外的商業特性或企業級支持,通過售賣商業許可證盈利。
- 代表公司:Confluent、Cockroach Labs等。
- 優勢:產品本身即可帶來收入;相比服務,具有更好的可擴展性。
- 挑戰:需要持續開發有價值的商業特性;面臨社群反應和潛在的分叉風險。

3. 開放核心(Open Core)

- 模式:核心功能開源,高級特性或企業版採用商業授權。
- 代表公司:Elastic、Redis Labs等。
- 優勢:開源版吸引使用者和貢獻者,商業版提供差異化的價值。
- 挑戰:需要在開源和商業之間取得平衡;面臨競爭對手利用開源版的風險。

4. 雲端托管和服務

- 模式:在雲端提供開源軟體的託管實例,或圍繞開源專案提供管理服務。
- 代表公司:AWS、Google Cloud、Microsoft Azure等。
- 優勢:使用者可以快速上手,無需關心底層基礎設施;雲端市場前景廣闊。 
- 挑戰:競爭激烈,需要持續投入基礎設施和運維;可能面臨社群的licensewashing質疑。

5. 基於開源的SaaS

- 模式:在開源軟體之上構建SaaS產品,提供增值功能和服務。
- 代表公司:Automattic、Mattermost等。
- 優勢:顯著降低使用門檻;可以快速迭代和交付新功能;具有穩定的訂閱收入。
- 挑戰:需要投入大量資源構建和運營SaaS平台;競爭激烈,需要持續創新。

四、開源授權方案詳解

1. GNU通用公共許可證(GPL)

- 授權特點:Copyleft型,要求衍生作品也必須以相同的授權分發,確保修改版本仍然開放。
- 適用場景:適合希望保護開源理念、防止專有化的專案,如作業系統、編譯器等基礎設施。
- 申請方式:在專案中包含GPL許可證文本,並在每個原始碼檔案中添加版權聲明和許可證標示。
- 授權方:由自由軟體基金會(FSF)管理,無需向特定組織申請,但需要遵守GPL的條款。
- 採用實例:Linux內核、GCC編譯器、WordPress等知名開源專案廣泛採用GPL。

2. 阿帕奇許可證(Apache License)

- 授權特點:寬鬆型,允許自由使用、修改、分發,要求保留版權聲明和免責條款。
- 適用場景:適合鼓勵廣泛採用、與專有軟體結合的專案,如函式庫、框架等。
- 申請方式:在專案中包含Apache許可證文本,並在每個原始碼檔案中添加版權聲明和許可證標示。
- 授權方:由阿帕奇軟體基金會(ASF)管理,無需向特定組織申請,但需要遵守Apache許可證的條款。
- 採用實例:Apache HTTP伺服器、Hadoop、Spark等知名Apache專案,以及Angular、TensorFlow等廣泛使用的開源軟體。

3. 麻省理工學院許可證(MIT License)

- 授權特點:寬鬆型,允許自由使用、修改、分發,要求保留版權聲明和許可證文本。
- 適用場景:適合希望最大限度減少使用限制、鼓勵廣泛採用的專案,如工具、函式庫等。
- 申請方式:在專案中包含MIT許可證文本,並在每個原始碼檔案中添加版權聲明和許可證標示。
- 授權方:由麻省理工學院(MIT)提出,無需向特定組織申請,但需要遵守MIT許可證的條款。
- 採用實例:jQuery、Node.js、Rails等知名開源專案,以及眾多的開源函式庫和工具。

4. 商業原始碼許可證(BSL)

- 授權特點:平衡開放與商業,允許免費使用,但禁止在生產環境中部署修改後的版本。
- 適用場景:適合希望開放原始碼但保留商業授權彈性的專案,如資料庫、中間件等。
- 申請方式:在專案中包含BSL許可證文本,並在每個原始碼檔案中添加版權聲明和許可證標示。
- 授權方:由專案所有者自行管理,無需向特定組織申請,但需要遵守BSL的條款。
- 採用實例:MariaDB、CockroachDB、Sentry等開源專案採用BSL或類似的商業原始碼許可證。

五、使用開源方案的公司現況

1. 紅帽(Red Hat)

- 商業模式:提供基於開源軟體的企業級訂閱服務,包括支援、維護、培訓等。
- 代表產品:Red Hat Enterprise Linux、OpenShift、Ansible等。
- 發展現況:2019年被IBM以340億美元收購,繼續深耕開源生態系統,推動混合雲和自動化。

2. Confluent

- 商業模式:圍繞Apache Kafka項目提供商業訂閱和雲端服務。
- 代表產品:Confluent Platform、Confluent Cloud等。
- 發展現況:2021年IPO,市值超過150億美元,持續擴大在即時數據流處理領域的影響力。

3. Elastic

- 商業模式:提供Elasticsearch、Kibana等開源專案的商業訂閱和雲端服務。
- 代表產品:Elastic Stack、Elastic Cloud等。
- 發展現況:2018年IPO,市值超過100億美元,持續創新,拓展安全、可觀測性等新領域。

4. MongoDB

- 商業模式:提供基於開源文件型資料庫的商業訂閱和雲端服務。
- 代表產品:MongoDB Enterprise Advanced、MongoDB Atlas等。
- 發展現況:2017年IPO,市值超過300億美元,持續引領NoSQL資料庫的創新和應用。

5. Automattic

- 商業模式:在WordPress開源專案基礎上,提供託管服務和商業功能擴充。
- 代表產品:WordPress.com、WooCommerce、Jetpack等。
- 發展現況:2019年估值達30億美元,用戶遍及全球,持續推動開源網路出版和電子商務。

六、如何選擇和應用開源方案

1. 評估專案目標和需求

- 確定專案的功能、性能、可靠性等關鍵需求。
- 考慮專案的目標受眾和潛在的商業化路徑。
- 評估專案對開放性、社群貢獻、品牌推廣等方面的訴求。

2. 選擇匹配的開源許可證

- 對比各種開源許可證的特點和義務,選擇與專案目標相契合的許可證。
- 考慮許可證對商業化的影響,權衡開放性和控制力。
- 評估許可證在目標社群和使用者中的接受度和熟悉度。

3. 制定貢獻和治理策略

- 建立清晰的貢獻指南和流程,鼓勵社群參與。
- 設計合理的治理模型,平衡社群貢獻和專案掌控。
- 持續投入資源,培育和激勵健康、活躍的開源社群。

4. 建立商業模式和生態戰略

- 在開源的基礎上,發展差異化的商業產品和服務。
- 探索訂閱、支援、諮詢、定制開發等多元變現方式。
- 打造開放、協作的生態系統,實現與合作夥伴的共贏。

5. 遵循許可證義務和最佳實踐

- 嚴格遵守所選開源許可證的各項要求,如版權聲明、原始碼披露等。
- 建立許可證合規性審查和管理流程,降低法律風險。
- 積極回饋開源社群,貢獻程式碼、文檔、資金等資源。

開源軟體正在蓬勃發展,並衍生出多樣化的商業模式。紅帽、Confluent、Elastic等公司的成功實踐,展示了開源與商業的巧妙結合。對於開源專案而言,選擇合適的授權方案,制定匹配的商業戰略,並遵循許可證義務和社群最佳實踐,是實現可持續發展的關鍵。

軟體公司在後AI時代的估值方法與陷阱

 為什麼軟體公司賺錢總是很辛苦？SaaS總是在生死邊緣上掙扎?現在情況如何?

如果你是傳統企業想收購軟體團隊做AI, 你該注意什麼?我這裡分享一些觀點, 圖的部分因為是取材自我2022年應邀對中國及新加坡金融機構的公開付費講座。如果想了解更多內容或諮詢的話, 可以另外私訊, 我不便在這裡全部公開。不過這些圖表應該可以提供您一些參考。

這是投行的人告訴你的:

評估併購SaaS（軟體即服務）公司時，以下是幾個重要的財務數字和指標，您應該仔細審查：

1. 收入成長率：觀察公司的年收入成長率，了解其市場擴張和業務增長的速度。
2. 月循環收入 (MRR) 和年循環收入 (ARR)：這兩個指標顯示公司每月和每年的定期收入狀況，是衡量SaaS公司表現的核心指標。
3. 客戶獲取成本 (CAC)：這顯示公司獲得每個新客戶所需的成本。低CAC表明高效的市場策略和成本控制。
4. 客戶留存率和流失率：高客戶留存率表明客戶滿意度高，而低流失率則顯示客戶忠誠度和持續收入的穩定性。
5. 生命週期價值 (LTV)：這個指標衡量一個客戶在其整個生命週期中為公司帶來的總收入。LTV 與 CAC 的比率是衡量公司盈利能力和可持續性的重要指標。
6. 營運杠桿：評估公司的營運成本和收入增長之間的關系，了解公司擴大規模的能力。
7. 利潤率：觀察毛利潤率和淨利潤率，這些指標可以顯示公司的盈利效率和成本控制。
8. 現金流量：檢查自由現金流和經營現金流，了解公司的資金周轉和財務健康狀況。
9. 資本結構：分析公司的債務和股本結構，評估其財務風險和資本成本。
   

可是實際上的情形呢?

軟體相關的研發成本應該算進銷售成本裡頭。現在不是90年代,軟體公司不能只投資一次研發,然後把軟體燒成光碟賣。

現在是軟體即服務(SaaS)的時代,開發和維護軟體的成本可是持續的。

如果這個論點沒錯,那上市軟體公司的平均毛利率就會從72%掉到47%,其實差很大欸。

軟體公司的獲利計算可是很麻煩der。不同的會計規則會影響營收和成本的認列方式。2017年,美國業界從ASC 605改用ASC 606,一夜之間,有些公司變更賺,有些就虧了。這其實也有影響到台灣的SaaS公司。

所以先把獲利擱一邊,來看看自由現金流量收益率(FCFY)。

對投資人或股東來說,FCF比常用的本益比更能反映公司的基本表現。

想找最佳基本指標的投資人,應該把FCF也納入他們的金融指標工具箱。

FCFY衡量的是:在公司營收流過各種成本後,年底時還能剩下多少錢在銀行戶頭裡。

過去20年裡,軟體公司的FCFY平均有3%,穩坐龍頭寶座。2009年12月9日到2016年3月這段期間,科技公司的FCFY平均接近5%。

當然,也有其他產業FCFY更高的時候。比方說,受到市場波動影響,能源產業現在就登頂了。但放眼二十年,科技業仍是市值的龍頭老大。

這個趨勢大概還會繼續下去。

我還是要說,沒有任何財務指標是完美的,它們都只能近似衡量企業的最終表現。FCFY和其他指標一樣,也有它的缺陷和細節。

就連創投參考的Pitchbook, 也都在告訴你EV/EBITDA的數值可以信任。

來看看貓膩在哪裡吧!

「Rule of 40」是一種財務分析方法，通常用於評估高成長技術公司的績效。這個規則結合了兩個關鍵指標：增長率和自由現金流利潤率（FCF margin）。該規則的目標是確保公司的總增長和利潤能夠保持平衡，以確保公司健康發展並具有吸引力。具體來說，根據這個規則，公司的年增長率（通常是收入增長率）和自由現金流利潤率之和應該至少達到40％。這意味著公司可以通過持續的增長來彌補其現金流損失，同時也可以實現盈利。這個規則通常用於評估高增長的科技公司，並且在投資者和分析師之間廣泛應用，作為評估公司投資價值的一個指標。

Rule of 40是我過去幾年最喜歡用來觀察矽谷公司表現的指標。

最近Conv equity將「Rule of 40」分析替換為「Rule of X」。Bessemer Ventures的 Byron Deeter和Sam Bondy在2023年底提出了這個指標，他們觀察到，統計資料顯示，增長與投資回報的相關性比自由現金流利潤率(FCF margin)更大。

Bessemer Ventures建議在「Rule of X」的下一年預期增長部分使用一個乘數。上市公司這個乘數主要在2到3之間，其中2.3是中位數。

再將「Rule of X」調整一下，加入SBC（ Stock-Based Compensation, 員工股票獎勵）百分比，得到了以下公式：

Rule of X（包括SBC）= 下一年預期增長 * 2.3 +（過去12個月自由現金流利潤率 - 過去12個月SBC百分比）

下表顯示了41只按照「Rule of X（含SBC）」排序的股票。

$AVGO、$CRWD、$MNDY、$ZS和$PANW等股票都在Rule of X（含SBC）方面表現出色。

我們的分析進一步將Rule of X與比較法、DCF法和價格變動進行交叉分析。

如果找到一支股票，Rule of X為深綠色、中綠色或淺綠色，並且估值為綠色，那該股票看起來很有吸引力。

如果價格變動也是綠色的，那就是額外的加分；但是考慮到最近市場的波動劇烈，因此，黃色的價格變動——意思是相對較小的變動——是與綠色的Rule of X和綠色的估值最符合的價格變動。

根據分析，$PANW和$FTNT看起來特別亮眼。

這裡同時分析了 eToro 上的 NDI-FutureTech 投資組合中的一些股票。使用了 "X rule" 的方法來評估這些股票的吸引力。

X  rule考慮了公司的增長率和自由現金流量率。如果一家公司的 X rule值高,通常意味著它有很好的增長前景和盈利能力。

在第一張圖表中,作者發現 $PDD、$DLO、$MELI 和 $AVGO 這些股票看起來特別有吸引力,因為它們的 X rule值高,但股價相對較低。

在第二張圖表中,作者發現 $DUOL、$GBLE、$HIMS、$MNDY、$APP、$PANW、$PLTR 和 $SNOW 這些股票也有類似的特點。

在第三張圖表中,作者發現 $OSCR、$GTLB 和 $TOST 這些股票的 X rule值高,主要是因為它們有很高的預期增長率,儘管它們目前還沒有盈利。

如果你發現一隻 X rule高但股價相對較低的股票,它可能是一個很好的投資機會。但在做出任何決定之前,還是要對公司進行深入的研究和分析。這只是一些見解和分析,不能作為投資建議。投資有風險,大家在做決定前還是要謹慎考慮。

「Next token Prediction」還能再走多遠?

近年來大語言模型(Large Language Models, LLMs)在自然語言處理領域取得了顯著的突破。而支撐這些 LLMs 的核心技術之一,就是下一個 token 預測(Next Token Prediction, NTP)。

NTP 技術由「資訊理論之父」Claude Shannon在其著作《通信的數學原理》（A Mathematical Theory of Communication）中首次提出。其核心思想是,通過給定一個詞序列的上下文,讓模型預測下一個最可能出現的詞。這種預測能力使得語言模型能夠生成連貫、邏輯性強的文本,在機器翻譯、文本摘要、自動寫作等場景中發揮重要作用。

 Shannon在這篇劃時代的論文中，首次系統地定義了「資訊」這個概念，並給出了資訊的數學表示方法。他引入了「bit」（比特）作為資訊量的基本單位，提出了著名的「香農熵（Shannon entropy）」公式來計算一個隨機變數所包含的平均資訊量。這個公式後來被廣泛應用於各個領域，成為現代資訊論的核心概念之一。

香農熵的定義如下：

對於一個離散隨機變量 X，其概率分佈為 P(X=x_i) = p_i，i=1,2,...,n，則 X 的香農熵為：

H(X) = -∑[i=1 to n] p_i log p_i

其中，log 通常以 2 為底，這樣熵的單位為比特（bit）。如果以自然常數 e 為底，則熵的單位為納特（nat）。

香農熵的一些重要性質：

非負性：H(X) ≥ 0，即香農熵總是非負的。

當 X 的分佈是均勻分佈時，香農熵達到最大值 log n。這意味著均勻分佈具有最大的不確定性。

當 X 的分佈是確定性分佈（即某個事件的概率為 1，其他事件的概率為 0）時，香農熵達到最小值 0。這意味著確定性分佈沒有不確定性。

香農熵滿足一些重要的不等式，如均值不等式、次加性不等式等，這些性質在信息論的推導中非常有用。

在信息論和編碼理論中，香農熵被用來衡量信息源的平均信息量，或者說，傳輸一個符號所需的平均比特數。

此外,Shannon還在論文中提出了兩大定理：

香農第一定理（Shannon's Source Coding Theorem）：給出了信源編碼的極限壓縮率,即信源熵。這意味著,當編碼長度趨於無窮時,每個編碼符號的平均長度不會小於信源的香農熵。

香農第二定理（Shannon's Channel Coding Theorem）：論證了存在一種編碼方式,使得通過帶噪信道進行通信時,傳輸誤碼率可以任意接近零,只要資訊傳輸速率低於信道容量。信道容量公式為：

C = B log2(1 + S/N)

其中,C是信道容量（單位：bit/s）,B是信道頻寬（單位：Hz）,S/N是信噪比。

這兩大定理奠定了現代編碼理論的基礎,指明了可靠通信的理論極限,對現代通信技術的發展產生了深遠影響。

雖然Shannon的原始論文並沒有直接提及「下一個token預測」（Next Token Prediction, NTP）這個概念，但他的資訊理論思想無疑為 NTP 技術的發展提供了理論基石。NTP 的核心思路可以看作是對香農理論的延伸和應用——通過最小化預測下一個 token 的不確定性（即香農熵），來訓練語言模型生成連貫、高質量的文本。

OpenAI 首席科學家 Ilya Sutskever 更堅信,NTP 是通往 AGI(Artificial General Intelligence,通用人工智慧)的關鍵。他認為,token 預測的質量反映了模型對語言背後隱藏的語義和知識的理解程度,這不僅僅是統計,更是對世界本質的壓縮和表達。如果讓一個足夠強大的語言模型去預測一個睿智、博學且能力非凡的人會有怎樣的行為舉止,它很可能可以通過人類資料進行推理和外推,模擬出超越現實的假想情況。

事實上,OpenAI 的研究員 Jack Rae 在斯坦福的研討會上做了題為《Compression for AGI》的報告,詳細論證了「壓縮即智慧」的觀點。他認為,壓縮能力體現了模型對資料的泛化和抽象能力,而泛化能力正是智慧的基石。

NTP 技術的基本原理可以概括如下:

1. NTP 是因果語言模型的核心任務,目標是準確預測給定文本序列中下一個令牌(token),如單詞或字元。Token 預測過程基於自迴歸機制,即模型一次預測一個令牌,並以由左至右的順序進行。

2. 大多數 NTP 模型基於 Transformer 架構,尤其是其僅解碼器(Decoder-Only)變體。Transformer 透過自注意力(Self-Attention)機制,讓模型在生成每個新 token 時,都能考慮到之前所有 token 的上下文資訊,從而生成更加準確和連貫的文本。

3. 在進行下一個 token 預測之前,文本首先需要被切分成模型可理解的最小單位,即 token。這些 token 隨後被轉換為嵌入向量(embedding vector),以數值形式表示。為了讓模型理解 token 的順序,每個 token 的嵌入向量會與位置嵌入向量相加,使模型能夠捕捉序列中的位置資訊。

4. 大型語言模型通過在大規模文本資料集上進行預訓練來學習下一個 token 預測。這個過程是自監督的(self-supervised),意味著模型通過預測文本序列中的下一個 token 來自我訓練,無需外部標註的訓練資料。透過這種方式,模型學會了理解和生成自然語言。

傳統的機器人控制方法,如波士頓動力公司採用的運動控制算法、強化學習和行為克隆等,通常需要對環境和任務進行專門的建模和規劃。這種方法雖然在特定環境下表現出色,但泛化能力有限,難以應對複雜多變的真實世界。

而基於自回歸生成的 NTP（Next Token Prediction）技術,為機器人控制開闢了一條新的路徑。通過將感官運動資料序列化為類似於自然語言的 tokens,並訓練類似 GPT 的自回歸語言模型來預測下一個 token,機器人可以直接從大量歷史互動資料中學習到連貫、鮮活的行為模式,而無需對環境進行顯式建模或路徑規劃。

這種範式轉變的優勢在於,自回歸生成模型具有強大的泛化能力。通過從海量多樣的感官運動資料中學習,模型可以掌握環境和任務的隱含規律,並在新的情景下自主地採取合適的行動。就像 GPT 模型可以根據上下文生成連貫的自然語言一樣,基於 NTP 的機器人控制器可以根據當前的感知狀態和歷史行為,自主產生連貫、適宜的運動控制指令,而無需為每個場景專門設計路徑。

以柏克萊團隊的工作為例,他們將多個來源的機器人感官運動資料（如手動設計的控制器輸出、強化學習模型的決策序列、人類運動捕捉資料等）匯總成一個龐大的「軌跡語料庫」,並在此基礎上訓練類似 GPT 的自回歸運動控制模型。他們將仿人機器人的感覺運動軌跡視作類似於自然語言中的單詞序列,將感覺輸入(如傳感器資料)和運動輸出(如馬達指令)的輸入軌跡進行 token 化,組成軌跡的「單詞」和「句子」。

接著,研究者們訓練了一個通用的 Transformer 模型來自迴歸地預測移位的輸入序列。與語言模型不同的是,機器人資料是高維的,包含多個感官模態和動作。研究者通過將輸入軌跡進行標記化,然後訓練 Transformer 模型來預測這些標記,處理了這種多模態性。模型能夠預測完整的輸入序列,包括感官和動作標記。

更有趣的是,當軌跡資料不完整(即感覺或運動資訊缺失)時,模型可以通過預測存在的資訊,並用可學習的遮罩標記(learnable mask tokens)替換缺失的標記來從中學習。這使得模型能夠從不完美或缺失的資料中學習,提高其泛化能力,在面對真實世界的不完整資料時仍能有效運作。

研究者們還發現,使用更多軌跡進行訓練可以減少位置追蹤誤差,展現了 scaling 定律在機器人控制中同樣有效。此外,實驗顯示,更大的上下文視窗和模型參數規模能產生更好的策略和更低的追蹤誤差。

實驗表明,訓練後的模型可以在各種場景下自主產生連貫、合理的運動軌跡,展現出了良好的泛化能力。機器人無需再依賴專門的路徑規劃,即可自如地在複雜環境中行動。

自回歸生成模型在機器人控制領域的應用,為打造更加智能、自主、泛化的機器人系統開闢了一條充滿潛力的新路徑。隨著 NTP 等技術的不斷發展和完善,我們有望在未來看到更多具備「類人般常識」的通用機器人助手,它們能夠像人一樣自然地感知、思考和行動,為人類的生產生活提供更加智能、貼心的服務。這無疑將是人工智能發展史上又一個激動人心的里程碑。

雖然這些結果令人振奮,但 NTP 技術在機器人控制中的應用仍存在一些疑慮和局限性。一些學者質疑論文中對「觀測」和「行動」概念的定義是否清晰一致,以及具體實現細節是否完備。也有人指出,即使對於簡單的行走任務,也需要大量(如數萬條)軌跡資料,而這些資料在現實中難以收集。

此外,NTP 技術本身也存在一些固有的局限性。例如,在長序列中,每個步驟的小錯誤可能會指數級累積,導致整體準確性大幅下降;模型可能學習到錯誤的規劃策略,在需要前瞻性規劃的任務中表現不佳;快速和慢速兩種思考過程難以同時模擬;一些 token 可能天生難以學習,需要對未來有全局理解。

當然,基於 NTP 的機器人控制方法仍處於探索階段,還面臨著一些挑戰和局限性。例如,如何在訓練過程中更好地引入物理約束和安全保障？如何進一步提高感官運動資料的採集和處理效率？如何賦予模型更強的因果推理和長期規劃能力？這些都是亟待研究者進一步探索的問題。

最近,蘇黎世聯邦理工學院和谷歌研究院的學者在論文"The Pitfalls of Next-token Prediction"中全面總結了 NTP 技術在大型語言模型中的問題和局限性。他們指出,目前的爭議很大程度上源於沒有區分推理階段的自迴歸和訓練階段的 teacher-forcing 兩種 token 預測方式。如果不加以區分,在模型預測錯誤時,對複合誤差的分析往往會將問題導向至推理過程,誤以為是模型執行方面的問題。

https://arxiv.org/pdf/2403.06963.pdf

論文還透過實驗指出了 NTP 技術目前存在的幾個主要問題:

1. 在自迴歸推理中,即使每步錯誤率很小,錯誤也可能在長序列中指數級累積,導致整體準確性顯著下降。

2. NTP 模型可能在需要前瞻性規劃的任務中表現不佳,難以有效學習如何制定和執行長期計畫。

3. Teacher-forcing 訓練可能無法學習到準確的下一個 token 預測器,因為模型可能會利用輸入中洩露的答案前綴來生成未來的詞,而非從問題本身推導出答案。

4. Teacher-forcing 訓練可能誘導模型使用「Clever Hans 作弊」策略。

5. Teacher-forcing 訓練可能導致早期答案詞難以學習,因為模型在訓練過程中失去了關於完整答案的監督。

6. 即使在簡單的路徑查找任務中,Transformer 和 Mamba 架構的模型也可能失敗,令人質疑 NTP 是否能泛化到更複雜或不同類型的任務。

NTP 技術雖然強大,但仍存在一些固有的局限性。在機器人控制領域,它能否真正走通還有待進一步的研究和驗證。未來,我們或許還需要探索其他潛在的技術路線,如多模態大模型、具身大模型、自然模態世界模型等,來實現通用人形機器人的智慧控制。這需要學界和業界的共同努力。

低稚量化對LLMa3效能的影響

這篇論文主要是在研究 Meta 最新推出的 LLAMA3 語言模型,在進行低位元量化之後,性能會受到什麼樣的影響。LLAMA3 模型經過大量的預訓練後表現非常優秀,但是在資源有限的情況下使用還是會遇到困難。低位元量化技術可以減少語言模型在推理時所需的記憶體和運算量,讓它能在性能較差的設備上運行。這項研究想要分析 LLAMA3 模型在量化後性能下降的問題。

研究中使用了兩種主要的技術方向來量化 LLAMA3 模型:訓練後量化和 LoRA 微調量化。實驗涵蓋了從 1 位元到 8 位元的不同量化程度,並使用了多樣化的資料集來評估性能,例如 WikiText2、C4、PTB、常識問答資料集和 MMLU 基準測試。

在訓練後量化方面,研究評估了 8 種不同的量化方法在 LLAMA3-8B 和 LLAMA3-70B 模型上的表現。

訓練後量化：

• Round-To-Nearest (RTN): 基礎的四捨五入量化方法。
• GPTQ: 利用錯誤補償的權重量化方法。
• AWQ: 透過壓制異常通道減輕權重量化難度。
• QuIP: 優化權重和Hessian矩陣的非相干性。
• DB-LLM: 雙重二值化和偏差感知蒸餾策略。
• BiLLM: 進行重要權重的殘差逼近和非重要權重的分組量化。
• SmoothQuant: 將量化困難從激活轉移到權重，以平滑激活異常值。

LoRA微調量化：

QLoRA 和 IR-QLoRA: 結合低秩微調技術和量化的方法，專門用於4位元量化。

評估資料

使用多個資料集來評估量化模型的性能：

• 訓練後量化: 使用WikiText2、C4、PTB進行基礎性能評估，以及PIQA、Winogrande、ARC-e、ARC-c 和 Hellaswag進行零樣本評估。
• LoRA微調量化: 使用MMLU資料集進行性能評估，同時也在上述零樣本資料集上進行測試。

實驗結果

訓練後量化

不同的量化方法在LLAMA3-8B和LLAMA3-70B模型上展現出不同的性能表現。在低至1到2位元設置中，如DB-LLM和BiLLM方法能夠較好地保持性能，而GPTQ和AWQ在極低位元下表現不佳。在零樣本任務上，大多數量化方法的性能同樣顯示下降，特別是在較低位元設定下。

LoRA微調量化

在MMLU資料集上，LoRA-FT方法未能彌補量化引起的性能下降。特別是在4位元設置中，與未進行LoRA-FT的模型相比，性能明顯下降。零樣本任務中的表現也顯示了類似的下降趨勢。

結果顯示,即使在極低位元的情況下,專門為超低位元設計的量化方法,如 PB-LLM、DB-LLM 和 BiLLM,仍然能在 LLAMA3-8B 模型上取得較高的準確率。而且,LLAMA3-70B 模型對各種量化方法都展現出相當的穩健性。 

在 LoRA 微調量化部分,研究使用了 QLoRA 和 IR-QLoRA 兩種方法對 LLAMA3-8B 模型進行 4 位元量化。但在 MMLU 資料集上,低秩微調不僅無法彌補量化造成的誤差,反而讓性能下降得更嚴重。這與之前在 LLAMA1 和 LLAMA2 上觀察到的現象大不相同。不過,4 位元 LoRA 微調量化後的 LLAMA3-8B 模型,性能還是明顯優於 LLAMA1-7B 和 LLAMA2-7B 的量化版本。

https://arxiv.org/pdf/2404.14047

我的個人看法

LLAMA3模型在低位元量化後仍然保持一定的性能，但與未量化的原始模型相比，性能的下降仍然明顯。這一結果強調了在資源受限的環境中部署LLAMA3時所面臨的挑戰，並指出了低位元量化技術在未來的改進與發展潛力。本研究的結果不僅加深了我們對於量化LLAMA3模型的行為的理解，同時也為量化技術的未來研究方向提供了寶貴的實證見解。

總的來說,研究發現雖然 LLAMA3 模型在量化後性能仍然很好,但量化確實會導致明顯的性能下降,在許多情況下甚至會造成更大幅度的性能下滑。這凸顯了在資源受限環境中部署 LLAMA3 的潛在挑戰,也顯示低位元量化技術還有很大的改進空間。這項研究的實證結果,對於未來大型語言模型量化技術的發展有重要的參考價值,特別是在縮小量化模型與原始模型之間的性能差距方面。如果能解決低位元量化導致的性能下降問題,我們可以期待未來的量化方法能讓大型語言模型以更低的計算成本發揮更強大的能力。

此外，這項研究亦顯示，針對如LLAMA3這樣的大型預訓練模型，即便是先進的量化技術也可能無法完全彌補由於位元數減少而造成的性能損失。因此，開發更有效的訓練後量化方法和微調技術，特別是那些能夠對特定應用進行優化的方法，將是推動未來研究的關鍵。

Llamafile: 專為大模型設計的推論框架(二)

隨著 ChatGPT、BERT 等大型語言模型在自然語言處理領域掀起巨大波瀾,AI 技術正以前所未有的速度走近大眾生活。然而,這些 LLM 的訓練和推論對計算資源提出了極高要求,動輒數十甚至數百 GB 的模型體積也給分發和部署帶來諸多不便。為了讓 LLM 真正為更多人所用,我們不僅需要更強大的硬體和演算法,還需要打造全新的工具鏈和基礎設施。

正是基於這一考慮,Mozilla 創新團隊於去年底發布了 llamafile 專案。透過巧妙結合 llama.cpp 和 Cosmopolitan Libc 兩大開源專案,llamafile 可將 LLM 權重檔案直接轉換為可執行檔,讓使用者無需編程即可在多種環境一鍵部署 AI 服務。自首發以來,在社群開發者的積極參與下,llamafile 迭代了多個重大版本,新增了一系列振奮人心的特性,有力推動了 LLM 技術的普及。本文將深入剖析 llamafile 的設計理念和關鍵實現,探討其在 LLM 工程化中的重要意義。

LLM 部署的技術挑戰

隨著 Transformer 等新架構的發明,LLM 的參數規模和計算開銷呈指數級增長。以 GPT-3 為例,其參數量高達 1750 億,訓練時使用了多達 10000 個 GPU,耗費了數百萬美元的算力成本。即便是在推論階段,為了獲得最佳的回應速度,仍然需要 TB 量級顯存的支援。這對絕大多數潛在使用者而言是難以企及的。

為了降低准入門檻,LLM 的開發者們開始探索各種優化技術,包括:

- 模型蒸餾:將大模型的知識提煉到小模型中,在保留核心能力的同時大幅減少參數量。 

- 量化感知訓練:透過低位元表示權重,在犧牲部分精度的前提下顯著降低儲存和頻寬佔用。

- 稀疏注意力:利用注意力矩陣的稀疏特性,避免計算無關 Token 之間的相關度,節省算力。

經過這些優化,LLM 的體積得以大幅壓縮,如今流行的開源模型如 LLaMA 和 GPT-J 的體積已降至百 GB 以下,資源佔用也在業餘愛好者可接受的範圍內。但與此同時,模型檔案格式也呈現出多樣化的趨勢。由於缺乏統一的標準,不同的模型在權重儲存方式上存在顯著差異。比如有的採用 NumPy 的 npz 格式,有的則使用 PyTorch 的 pt 格式,還有的會自訂一套序列化方案。這就導致了模型利用的碎片化問題,不利於推廣普及。

除了格式不一致,LLM的硬體適配也面臨諸多障礙。一方面,儘管上述優化在降低推論開銷上已經卓有成效,但對於複雜的任務而言,CPU 計算能力仍嫌不足,必須借助 GPU、TPU 等專用加速器。而這些異構設備在編程模型上存在顯著差異,且驅動配置繁瑣,應用程式很難做到一次編寫,隨處執行。另一方面,由於模型體積仍然較大,單機記憶體很難將其全部裝載,因此通常需要分散式推論,這進一步加劇了環境依賴。

由此可見,要真正普及 LLM 技術,我們需要在工具鏈和基礎設施層面做出改變。具體而言,期望有這樣一套方案,能夠:

1. 屏蔽 LLM 檔案格式的差異,提供統一的模型描述和轉換機制。

2. 封裝異構硬體差異,實現可移植、高效能的加速方案。  

3. 簡化分散式環境配置,做到開箱即用、按需擴縮。

llamafile 正是基於這些考量應運而生。透過在兩個成熟專案的基礎上提供薄薄一層"膠水",它巧妙地化解了上述矛盾,讓部署 LLM 變得無比簡單。

llama.cpp:為 LLM 注入 C 的效能

在介紹 llamafile 的核心設計之前,我們有必要先了解其重要組成部分:llama.cpp。

眾所周知,Python 以簡潔優雅著稱,是機器學習研究人員的首選語言。但在工程實踐中,Python 的執行效率一直飽受詬病。這在 LLM 推論場景下尤為突出,因為模型體積巨大,稍有不慎就會引入性能瓶頸。為了避免這一問題,llama.cpp 的作者選擇用 C/C++ 從頭實現 LLM 推論。

Agent使用第三方的大模型隨著使用頻率增加，成本也會上升，是否有更省錢的方法呢？有的，就是將這些大模型跑在CPU上。

一般來說，月租GPU伺服器至少也要花費9000左右，使用第三方服務的API可能很划算，但使用第三方服務始終存在資料外洩的風險。而且隨著用戶增加，按token計價的方式也一樣會讓花費快速增加。一些技術專家找到了一個省錢的方法，那就是讓大型模型在AMD的GPU，甚至在CPU上運行。如果在CPU上運行，我們只需要租一台核心夠用且內存較大的伺服器即可，每個月的價格瞬間就能降低千元甚至千元以下，有時候選擇折扣方案只要花費四千多塊台幣就能租一年。

想要在CPU上跑LLM，關鍵在於兩個要點：

1. 有效的CPU運算架構。

2. 充分利用大型模型的性能。

只要做到以上兩點再配合一台硬體配置還不錯的CPU伺服器，就可以得到一個性價比極高的本地大型模型服務。

有關第一點，Georgi Gerganov提出了用C/C++重新實現模型框架的想法。就是我們上次提到的llama.cpp。

使用C/C++的優點在於：

不需要額外的依賴，相比Python代碼需要的PyTorch等庫，C/C++直接編譯出可執行文件，避免了不同硬體的繁瑣準備工作:

1. 支持Apple Silicon芯片的ARM NEON加速，x86平台則以AVX2替代。

2. 具有F16和F32的混合精度。

3. 支持4-bit量化。

4. 不需要GPU，只需CPU即可運行。

由於這是純C/C++實現，不需要其他依賴，運行效率很高。除了MacBook Pro外，甚至還可以在Android上運行。

第二點，如何對100B大小的大型模型進行壓縮，以便於CPU機器運行呢？答案是通過「量化」。量化是指將連續取值的浮點型模型權重進行裁剪和取捨的技術，簡單來說就是壓縮，丟失部分精度，換取空間和性能。Georgi Gerganov提出了自己的量化方案ggml，ggml成為一種量化模型的文件格式。不過，由於大模型發展太快，ggml很快就跟不上，於是在去年年8月，推出了改進方案gguf，成為最新的量化模型文件格式。目前，HuggingFace也大力支持這個格式。當然，除了gguf方案外，還有其他量化方案，例如GPTQ等。總之，經過量化後的模型，可以提升性能，降低對硬體資源的要求。

有了llama.cpp和gguf，我們就可以在CPU上跑大模型了。

雖然llama.cpp可以直接運行，但運作起來總是不太方便。畢竟現在很少有人用C++來寫系統，所以最好能夠直接與我們的應用結合起來。

這裡有兩種方案：

1. 建立獨立服務，通過RPC或HTTP進行調用。

2. 將其編譯為業務系統開發語言所支持的模組，直接在代碼中調用。

第一種方案可以使用llama.cpp專案提供的輕量級HTTP服務，或者使用第三方的Docker容器來啟動服務。啟動後，就可以通過HTTP API來調用大型模型。

第二種方案，技術社群裡會有很多神人提供不同語言的模組，可以在llama.cpp專案的首頁找到這些專案。只需要找到適合你業務系統編程語言的模組，安裝到你的系統中，就可以像調用一個第三方庫一樣調用大型模型。另外，如果想要快速體驗，還可以通過ollama一鍵安裝和啟動大模型的功能。

量化後的模型對硬體的要求降低，但並不是說隨便一台舊電腦就能跑得動。比如我們有一個需要8G內存的大模型，我們可以試試6B的量化模型。如果有必要，可以升級到32G，這樣就可以增加量化的精度，獲得更好的結果。如果只有2G內存，建議用第三方接口調用。

模型經過量化後失去了一部分精度，會不會影響模型的準確性？

對於這個問題，應該根據自己的需求來選擇。會有不同參數量級的模型，是因為對於不同的應用場景所需要的資料精度是不同的。對於應用開發來說，要學會根據需要選擇適合的模型，適度降低成本。如果將所有LLM的處理都交給一個大模型去處理，代表模型要承受巨大的服務壓力，成本也會相應增加。因此，合理將不同的處理分配給不同的模型，在學習和調試的過程中，可以自己搭建一個本地的大模型服務，等調試完Agent之後，再將部分調用切換到付費的大模型上。如此一來，就可以降低成本。

具體而言,llama.cpp 提供了一個通用的推論引擎,可以載入 LLaMA、GPT-J、GPT-NeoX 等主流模型,並執行高效的文字生成。它採用自訂的權重格式,將模型劃分為若干個分片,每個分片包含其全部參數。這種組織方式可以充分利用局部性原理,在載入和訪問權重時盡可能減少快取缺失和頁面調度。

在演算法實現上,llama.cpp 對矩陣乘等關鍵路徑進行了極致優化,充分利用了 SIMD、Loop Unrolling 等現代 CPU 特性,再加上精心調教的多執行緒並行,使其在工業級伺服器上的推論效能可比肩商用解決方案。

為了方便地與現有應用整合,llama.cpp 還提供了一個相容 OpenAI API 的 HTTP 伺服器。使用者只需將請求發送至指定埠,即可獲得類似於 GPT-3 的對話體驗。這極大降低了二次開發的門檻。

然而,llama.cpp 仍存在一些不足之處:

1. 儘管提供了 Python binding,但在實際使用中仍不可避免地需要一些 C++ 知識,對非專業開發者不太友善。

2. 雖然權重格式經過優化,但轉換過程需要花費較長時間,且佔用大量磁碟空間。  

3. 雖然已經適配了 CUDA 後端,但配置過程較為繁瑣,且未考慮 AMD 平台。

llamafile 透過引入 Cosmopolitan Libc,巧妙地解決了這些問題。

Cosmopolitan Libc:賦予 C 跨平台的靈魂

談到跨平台,很多人首先想到 Java 的"一次編寫,到處執行"。然而,對於偏好 C/C++ 的系統級開發者而言,這一理念似乎遙不可及。一個主要原因是,不同作業系統在底層 API 的語義和呼叫規範上存在顯著差異。為了適配多種環境,開發者不得不編寫大量膠水程式碼,人工處理各種邊界情況,既繁瑣又容易出錯。這嚴重阻礙了 C/C++ 程式的可移植性。

Cosmopolitan Libc 試圖從根本上解決這一困境。它的核心理念是:透過提供一層統一的系統呼叫抽象,讓開發者只需面向 Cosmopolitan API 編程,生成的目標碼就可以不經修改地在 Linux、Windows、macOS 等各種環境直接執行。

實現這一點的關鍵是 Cosmopolitan 的連結器。傳統的連結器如 ld 只負責解析符號、分配位址,對目標平台並不作過多假設。而 Cosmopolitan 的連結器則內置了一個微型作業系統,可在裸機環境直接啟動。在入口函數執行之前,它會初始化 GDT、頁表等關鍵資料結構,並提供執行緒調度、虛擬記憶體、動態連結等現代作業系統的核心功能。這使得 Cosmopolitan 程式可以不依賴宿主機核心,直接控制硬體資源。

在 API 層面,Cosmopolitan 參考了 POSIX 規範,提供了檔案、網路、多執行緒等常用系統服務。為了適配不同 ISA,它還實現了通用的原子操作、鎖機制等並發原語。對於跨平台必須的元件如 libc、libm,Cosmopolitan 也提供了自己的實現。這些努力最終使得開發者只需遵循 Cosmopolitan 的編程規範,就能編寫可移植的系統級應用。

但光有可移植性還不夠,Cosmopolitan 還需為高效能計算提供支援,這主要體現在兩個方面:

1. 動態連結。LLM 推論通常需要呼叫 CUDA、BLAS 等第三方程式庫。為此,Cosmopolitan 實現了自己的動態連結器,可以載入宿主機的共享物件,並自動完成重定位。

2. GPU 加速。考慮到異構計算的廣泛應用,Cosmopolitan 透過封裝 CUDA driver API,使得 GPU 核心可以直接內聯到 Cosmopolitan 程式中,避免了 JIT 編譯帶來的額外開銷。

這兩個特性是 Cosmopolitan 區別於傳統 Libc 的關鍵所在,也是 llamafile 實現其設計目標的重要基石。

https://github.com/Mozilla-Ocho/llamafile

融合創新:llamafile 的架構設計

有了前面的鋪墊,我們就可以詳細解讀 llamafile 的核心設計思路了。

簡單來說,llamafile 直接利用 llama.cpp 作為 LLM 推論後端,透過 Cosmopolitan Libc 將其打包為可執行檔。這裡的關鍵是,llamafile 將模型權重硬編碼到可執行檔中,使得最終產物可脫離原始碼獨立執行,且不受環境約束。

具體實現上,llamafile 主要經過如下步驟:

1. 模型轉換。首先使用 llama.cpp 提供的工具,將各種常見格式的權重檔案轉換為 llama.cpp 定制格式。這個過程是一次性的,轉換結果可供重複使用。

2. 構建 blob。利用 Cosmopolitan 的連結器 objcopy,將轉換後的權重檔案以 blob 的形式內嵌到目標檔案中。

3. 連結可執行檔。將 llama.cpp 的核心程式碼、Cosmopolitan Libc、權重 blob 等目標檔案一起連結,生成最終的可執行檔。在這個過程中,連結器會進行符號解析和重定位,並生成元資料供啟動期使用。

4. 執行期載入。當可執行檔啟動時,首先由 Cosmopolitan 執行期完成初始化,並解析命令列參數。隨後,llamafile 利用 mmap 將嵌入的權重 blob 映射到記憶體,模擬 llama.cpp 的模型載入過程,繼而可以開始推論。

整個過程無需依賴 Python 直譯器,權重載入也省去了從檔案系統讀取的 I/O 開銷,再加上 Cosmopolitan 對資源的細粒度控制,使得 llamafile 的端到端效能接近原生應用。

為了進一步提高效能,llamafile 還在 Cosmopolitan 的基礎上實現了以下增強:

- 利用 GPU 加速矩陣運算,針對 NVIDIA 平台封裝了 cuBLAS API,AMD 平台則使用 ROCm。

- 針對 NUMA 架構進行 NUMA-aware 記憶體分配和執行緒調度優化。

- 引入 Cosmopolitan 對 JIT 編譯的支援,可在執行期產生高度優化的計算核心。

- 在模型並行方面,llamafile 支援多 GPU 橫向擴展,並利用 NCCL 實現高效通訊。

同時,llamafile 還致力於提供開箱即用的使用者體驗:

- 提供 llamafile-convert 工具簡化模型轉換,並與 Hugging Face 等社群生態深度整合。

- 持續完善 API server,提供易用的 RESTful 介面,同時相容各種應用框架。  

- 針對 CPU 後端實施 Lazy Tensor 優化,減少不必要的顯存佔用。

這些設計使得 llamafile 不僅在性能上拔得頭籌,也讓 LLM 開發和使用前所未有地便捷。

推動大語言模型民主化進程

自面世以來,llamafile 迅速俘獲了開源社群的芳心。憑藉卓越的性能和體驗,它已躍升為 Mozilla 最受歡迎的專案之一。在眾多貢獻者的推動下,llamafile 正以驚人的速度迭代演進,展現了開源力量的非凡魅力。

開源程式碼,技術創新,社群協作,這是 llamafile 專案的三大法寶,也是它不斷突破自我、續寫傳奇的力量源泉。  

自 v0.1 發布以來,llamafile 幾乎以每月一版的速度迭代。在 v0.8 中,它不僅支援了 Meta 最新發布的 LLaMA 3 等 SOTA 模型,還帶來了一系列性能優化:透過手寫組合語言實現的 BLAS 核心將 CPU 運算效率提高了一個數量級;針對 NVIDIA 和 AMD GPU 的異構調度策略也更加完善;為樹莓派等 ARM 平台提供了專門的低位元量化方案,即便在這些小型設備上也能實現即時對話。如此迅猛的進化速度,展現了開源力量的驚人魅力。

與此同時,llamafile 還在架構層面做出了前瞻性的嘗試。比如在 v0.7 中,它引入了混合執行引擎,可以根據模型規模和硬體條件動態調整執行策略。對於超大規模模型,它會自動採用流水線並行、張量融合等圖優化技術,最小化資料移動;對於中小規模模型,則會利用 Lazy Tensor 避免無謂的顯存分配,提高快取利用率。這為 LLM 推論提供了一套全局優化的範式。  

llamafile 也在積極擁抱社群生態。透過提供相容 OpenAI 的 API,它可以直接取代商業方案,為各種創新應用提供基礎支撐。在 LangChain、AutoGPT 等熱門專案中,我們已經可以看到 llamafile 的身影。Mozilla 還專門成立了 MIECO專案,為 llamafile 等開源技術搭建產學研用協同創新的平台,推動 AI 生態良性發展。

展望未來,隨著演算法優化的不斷突破,以及晶圓代工工藝的持續進步,LLM 推論已展現出阿米巴原生的趨勢特徵。從雲端到邊緣、從資料中心到終端,llamafile 這樣的"蘋果核"有望成為 AI 民主化的助推器,讓智慧應用遍地開花。  

作為這一變革的先行者,Mozilla 正在 llamafile 的基礎上謀劃更宏大的藍圖。相信在可見的未來,它必將釋放出比肩作業系統和瀏覽器的顛覆性力量,成為 AI 新紀元的基石。讓我們拭目以待,見證 llamafile "出圈"的那一天。

小結

llamafile 是 Mozilla 為推動 LLM 大眾化做出的重要努力。它巧妙結合了 llama.cpp 和 Cosmopolitan Libc 兩大開源專案,透過將模型權重內嵌到可執行檔,徹底解決了 LLM 分發和部署的難題。  

性能方面,得益於 Cosmopolitan 細粒度的系統呼叫抽象和 llamafile 在 GPU 加速、BLAS 優化等方面的卓越工作,其端到端回應速度可比肩商業方案,且可輕鬆橫向擴展。

體驗方面,llamafile 提供了豐富的工具鏈支援,簡化了模型轉換和自訂流程。其 API server 更是開箱即用,無需過多配置即可實現靈活呼叫。

llamafile 的成功離不開開源社群的積極參與。Mozilla 不僅以 MIECO 的形式搭建產學研用協同創新的平台,更以 llamafile 為起點規劃 AI 普惠的宏偉藍圖。  

站在 IT 發展的新起點,Mozilla 正以 llamafile 為引擎,驅動 AI 技術向更廣闊的應用場景滲透。我們有理由相信,這場由開源力量領跑的 AI 革命,必將像當年的個人電腦和網際網路一樣,以摧枯拉朽之勢重塑數位世界的格局。讓我們攜手共進,做 AI 新時代的見證者和開創者!

個人觀點

作為一個開源愛好者和AI研究者,我對 llamafile 這樣的創新專案感到由衷的敬佩和興奮。在我看來,它不僅是一個技術突破,更代表了開源精神和創新動力的完美結合。

llamafile最令人印象深刻的,是它在複雜的異構環境中實現了"一次編寫,隨處執行"的理想。這在以往的 AI 部署中幾乎是不可想像的。無論是格式轉換、運行時優化還是分散擴展,llamafile 提供的全流程自動化方案堪稱教科書般的典範。更難能可貴的是,這一切都建立在開源專案的基礎之上,展現了開源社群協作的驚人力量。

同時,llamafile 對 LLM 生態的推動作用也不容小覷。一方面,它大大降低了 LLM 的准入門檻,讓更多人可以參與到這場 AI 變革中來。透過與主流開源社群的緊密整合,llamafile 將釋放出更多創新活力。另一方面,llamafile 的成功也為商業公司敲響了警鐘。在开源力量面前,封閉平台和專有格式已經岌岌可危。唯有擁抱開放,合作共贏,才能在 AI 新時代佔得一席之地。

當然,llamafile 還有進一步完善的空間。比如在安全和隱私方面,目前的方案可能還不夠成熟;在支援更多的模型和硬體時,也需要投入大量的適配工作。但我相信,在開源社群的共同努力下,這些問題終將迎刃而解。Mozilla 樹立的"開源+創新"範式,也必將在更多領域綻放異彩。

展望未來,我對 AI 技術的民主化充滿期待。隨著 llamafile 這樣的基石工程不斷夯實,LLM 推論從雲端向終端滲透的趨勢已勢不可擋。在可見的未來,也許我們每個人都將擁有自己的"AI助手"。它們不再是大公司的專利,而是真正服務於每個人的智慧夥伴。這場變革不僅將提升生產力,改善生活品質,更將從根本上重塑人與科技的關係。而這一切,都將由開源力量來推動和實現。作為這個偉大時代的一分子,我們每一個人都應該努力探索開源的無限可能,用創新和協作為 AI 新紀元續寫傳奇。讓我們攜手並進,共創美好未來!

CRISPR-GPT: Google DeepMind領軍自動化基因編輯實驗設計的LLM Agent

當大家還在討論AI是否能進行複雜推論的時候，另一個有"破壞力創造"的進步卻在悄然發生。那就是AI與基因編輯技術的結合!!

我曾經參與生物晶片公司的營運, 所以從實務上深入分析這個應用帶來的影響, 但是如果產業知識對您過於艱澀, 您可以直接看我的結論。

基因工程技術的引入徹底改變了生物醫學研究,使得對基因資訊進行精確修改成為可能。然而,創建一個高效的基因編輯系統需要對CRISPR技術和複雜的實驗系統有深入的理解。雖然大型語言模型(LLM)在各種任務中表現出了前景,但它們往往缺乏特定知識,難以準確解決生物學設計問題。

在由DeepMind領軍Stanford U.及Princeton U.實驗室的這項工作中,該報告介紹了CRISPR-GPT,這是一個融合了領域知識和外部工具的LLM agent,可以自動化和增強CRISPR基因編輯實驗的設計過程。CRISPR-GPT利用LLM的推理能力,幫助選擇CRISPR系統、設計向導RNA、推薦細胞遞送方法、起草實驗方案,並設計驗證實驗以確認編輯結果。該報告展示了CRISPR-GPT在協助非專家研究人員從頭開始進行基因編輯實驗方面的潛力,並在一個真實世界的案例中驗證了agent的有效性。此外,該報告探討了與自動化基因編輯設計相關的倫理和監管考量,強調需要負責任和透明地使用這些工具。該報告的工作旨在彌補初學生物研究人員與CRISPR基因組工程技術之間的差距,並展示LLM agent在促進複雜生物學發現任務中的潛力。

背景

基因編輯技術代表了一項開創性的科學進步,它使得精確改變生物體的遺傳物質成為可能。這一創新技術在生物學和醫學的各個領域都得到了廣泛應用,從糾正導致囊性纖維化、血友病和鐮刀型貧血等疾病的基因缺陷,到為對抗癌症、心血管疾病、神經退行性疾病和感染等複雜疾病提供新策略。最著名的基因編輯系統之一被稱為CRISPR-Cas9。它是從細菌用作免疫防禦的天然發生的基因組編輯系統改編而來。除了CRISPR-Cas9,最近的進展還促成了CRISPR啟動/干擾、CRISPR基礎上的Prime編輯和Base編輯技術的發展。CRISPR啟動/干擾,也稱CRISPRa/CRISPRi,能夠通過表觀遺傳調控來增強基因表達或沉默特定基因的活性。被認為是DNA的"搜索和替換"方法的Prime編輯可以在不引入雙鏈斷裂的情況下進行精確編輯。另一方面,Base編輯可以在目標位置直接、不可逆地將一種DNA鹼基轉換為另一種,進一步擴大了精確基因組修飾的工具箱。所有這些技術在醫學、農業及其他領域都有廣泛的應用潛力,提高了基因組編輯在尋求治療遺傳疾病和其他應用方面的能力。

設計基因編輯實驗需要深入理解一系列技術以及目標器官相關的生物學。CRISPR Cas基礎編輯的工作原理是與一個短的"向導"序列(導向RNA)的RNA相互作用,該序列與細胞DNA中的特定目標序列結合,類似於細菌從CRISPR陣列產生的RNA片段。當導入細胞時,導向RNA識別預定的DNA序列,Cas酶(通常是Cas9或其他)在目標位置切割DNA,模仿細菌中的過程。在設計這類實驗時,有許多考慮因素,包括選擇合適的基因編輯系統、開發最佳的導向序列和驗證方法。這通常需要大量的領域專業知識、對目標器官生物學的理解以及反復試驗。開發人工智能輔助計算工具來幫助基因編輯有巨大的前景,可以讓技術更容易獲得,加速科學和治療的發展。

大型語言模型(LLM)已經在語言技能方面展示了非凡的能力,並包含了大量的世界知識,近似於人工通用智能的某些方面。最近的研究還探索了用外部工具增強LLM,提高它們解決問題的能力和效率。LLM也展示了作為工具製造者和黑盒優化器的潛力。研究人員探索了用於各種應用領域的基於LLM的專門模型,以及用於解決科學和數學任務的模型。例如,ChemCrow使用工具增強LM來解決一系列與化學相關的任務,如對乙酰氨基酚的合成,而Coscientist也由GPT-4驅動並整合了自動實驗,在優化鈀催化的交叉偶聯反應方面取得了成功。

然而,一般用途的LLM並不知道如何設計生物學實驗。儘管運用大型語言模型(LLM)來輔助基因編輯實驗的設計前景誘人,但目前最先進的通用模型在這一專業領域存在明顯不足。這些模型雖然知識儲備豐富,卻缺乏精確、最新的特定領域知識,而這對於準確設計生物學實驗至關重要。

通用LLM的一個關鍵局限性是它們傾向於產生自信但不準確的回應,即當被要求回答專業生物學查詢時的 "幻覺"。例如,當被要求為靶向特定人類基因(如EMX1或EGFR)設計向導RNA(gRNA)序列時,像ChatGPT-3/ChatGPT-4這樣的通用LLM往往會用高置信度給出錯誤序列。然而,它們提供的gRNA序列通常與任何已知的基因組區域都不對應。這種差異可以通過將LLM生成的序列與NCBI的BLAST等數據庫中的參考序列進行比對來輕易發現,BLAST可以將序列與人類基因組和轉錄組比對。如果不經過適當的審核,這種虛構的設計序列不僅缺乏實用性,還可能誤導研究人員,導致資源和時間的浪費。

此外,通用LLM產生的回應通常缺乏實驗設計所需的基本細節,如具體材料、方案、非目標效應考量、gRNA效率和特異性。這些資訊上的差距可能讓研究人員,尤其是基因編輯領域的新手,無法為實驗的實際執行做好準備。

值得注意的是,生成的回應可能包含大量與基因編輯實驗設計無直接關係的資訊。這種無關的文字會導致混淆和誤導,使研究人員難以識別最相關和最實用的資訊。

所有這些局限性都凸顯了開發專門針對基因編輯實驗設計的新型LLM的必要性。這些模型需要整合深入、精確的領域知識和批判性評估並生成可行實驗解決方案的能力,從而克服通用LLM在設計CRISPR基因編輯實驗時面臨的當前障礙。

CRISPR-GPT概述

在基因工程快速發展的領域,CRISPR技術已成為精確基因編輯的關鍵工具。儘管它很有前景,但設計CRISPR實驗的複雜性——從向導RNA(gRNA)的選擇到預測非目標效應——對那些剛接觸該領域的人來說帶來了重大挑戰。為了彌合這一差距,該報告推出了CRISPR-GPT,這是一種新型解決方案,它將大型語言模型(LLM)的優勢與特定領域知識和計算工具相結合,專門用於CRISPR基因編輯任務。

CRISPR-GPT的核心是一個量身定制的LLM驅動的設計和規劃agent。這個agent的引擎不僅利用了基因編輯領域領先從業者的專家知識,還整合了對最新文獻的廣泛回顧以及一套計算工具包,包括向導RNA設計工具。

CRISPR-GPT Agent的創新之處在於通過簡化複雜的過程為一系列可管理的步驟,實現基因編輯實驗的自動化設計:

1. CRISPR系統的選擇:根據實驗需要量身定制CRISPR系統的選擇。
2. gRNA設計:根據Broad Institute的金標準guideRNA庫和CRISPRPick工具包,包括預先設計的gRNA庫,優化guideRNA序列的效率和特異性。
3. 遞送方法選擇:就將CRISPR組分導入目標細胞的最有效方法提供建議。 
4. 非目標效應預測:評估預期編輯的同時可能出現的意外改變。
5. 實驗方案的推薦:根據實驗目標量身定制分步過程。
6. 驗證方法推薦和引物設計:推薦驗證編輯的最佳方法,並幫助設計相關引物。

這種方法利用連續思考推理模型和狀態機,確保即使是基因編輯的新手也能反復完善他們的實驗設計,以達到滿足他們具體研究需求的方案。此外,CRISPR-GPT還提供:

• 一個自由問答模式,用於精確解答臨時查詢。
• 一個用於深入分析預設計gRNA的非目標預測模式。

當使用者在實驗設計過程中遇到其他問題時,這些功能可以為使用者提供幫助。

考慮到圍繞基因編輯(尤其是人類應用)的倫理和安全問題,該報告已經將保障措施整合到CRISPR-GPT中。這些措施包括限制其在人類受試者中的使用、確保遺傳資訊隱私的措施,以及對潛在意外後果的警示,反映了該報告致力於在與基因編輯技術相關的更廣泛的科學和倫理討論中負責任地使用這些工具。

方法和算法

大型語言模型 

CRISPR-GPT agent由以下4個核心模塊組成:LLM規劃器、工具提供者、任務執行器和LLM Agent,後者作為與使用者的介面,用於接收輸入和傳達輸出。

任務執行器以狀態機的形式運行,提供穩健的子目標分解和進度控制。該報告以狀態機的形式為CRISPR-GPT實現了22個任務,總結於表1。狀態機負責為當前任務提供充分的指示,並引導使用者通過多輪文字互動完成決策。通過這些狀態機,該報告為任務執行器手動分解每個任務為子目標。具體而言,每個狀態負責一個特定的子目標。轉移邏輯被很好地定義,因此任務執行器可以根據當前進度適當地轉移到另一個子目標。

該報告有4個預定義的元任務,支援4種基因編輯相關實驗的完整流程;見表1。此外,LLM規劃器可以根據使用者的元請求生成定制的任務清單。相應任務的狀態機被鏈接在一起,形成一個更大的狀態機以支援整個流程。

工具提供者將任務執行器與外部API連接起來。為了將語言模型與外部功能連接起來,系統需要(1)分析當前形勢並判斷是否適合調用外部工具;
(2)知道有哪些工具可用,並從中選擇最佳工具。

在CRISPR-GPT中,該報告沒有直接向LLM公開API的介面,而是將API的使用包裝在狀態中,並通過手寫的指示和回應公開更加使用者友好和LLM友好的文本介面。通俗地說,該報告是在教使用者(人類agent和LLM agent)如何使用這些工具。這些工具包括Google網路搜索、運行Primer3等程式,以及從外部向導RNA庫、研究論文和實驗方案中檢索資訊。

LLM規劃器根據使用者的請求自動生成任務清單。大型語言模型(如GPT-4、Gemini和Claude)可以作為LLM驅動的agent的推理核心,以解決現實世界的決策問題。該報告採用流行的ReAct提示技術,其中LLM被提示輸出連續思考推理路徑和從可能的行動集合中選出的最終行動。為了讓LLM執行任務分解,該報告提供一個表格,其中包含所有任務的描述和依賴關係作為LLM的提示。基於LLM的內部知識以及該報告手動編寫的任務描述和任務分解指示,LLM可以智能地分析使用者的請求,並將使用者的請求分解為一系列任務,同時考慮任務之間的依賴關係。分解後,相應的狀態機被鏈接在一起以完成所有任務。任務分解的提示格式可以在附錄B中找到。

為了提高魯棒性,該報告不允許LLM在自動執行過程中動態添加/刪除新任務(新狀態機)。然而,該報告相信這是邁向更智能的CRISPR-GPT版本的重要一步,並將其作為未來的工作。

LLM-Agent根據使用者的元請求自動與任務執行器互動。在解決自動化CRISPR基因編輯任務這一複雜挑戰時,該報告通過序貫決策的視角來構建問題。這一視角將使用者與自動化系統之間的互動框定為一系列步驟,每一步都需要精確的決策以朝著實驗設計和執行的最終目標前進。該報告系統的核心是LLM-agent,它充當使用者與狀態機之間的中介。這個狀態機源自初始任務分解步驟,有效地將基因編輯過程分解為一個結構化的動作和決策序列。在這個序列的每一步,狀態機都向LLM-agent呈現一個當前狀態。這個狀態封裝了手頭任務的描述,並指定了使用者需要提供的任何輸入以推進進程。

LLM-agent的角色是解釋當前狀態並代表使用者做出明智的決定。為了有效地做到這一點,agent可能會利用各種資訊,包括:

• 當前狀態固有的指示,
• 使用者提出的具體請求,
• 當前任務會話中過去互動的歷史,
• 已整合到系統中的外部計算工具的結果。

這些資訊被整合到LLM-agent的提示中,然後agent利用其能力來確定最合適的下一步行動。這些提示的格式和結構旨在優化決策過程。

使用者監督是該系統的一個關鍵組成部分。雖然LLM-agent自主運作,但使用者並沒有被排除在這個過程之外。相反,該報告鼓勵他們監控任務的進展並與agent互動。這種設置確保LLM-agent的任何錯誤或誤解都能被使用者及時發現和糾正,維持基因編輯實驗設計的準確性和完整性。這種自動化方法強調人類專業知識與人工智能之間的協同合作。通過利用LLM-agent處理和應對複雜資訊的能力,該報告為設計CRISPR基因編輯實驗提供了一種更高效、更使用者友好的體驗。序貫決策框架不僅簡化了任務執行過程,而且確保使用者的輸入仍然是實驗規劃和設計的基石。

人工評估

為了評估CRISPR-GPT agent在協助基因編輯和實驗設計方面的有效性,該報告組織了一個由12位CRISPR和基因編輯研究領域專家組成的多元化小組。這12位專家根據既定標準,對三種模式對實驗設計任務的回應進行了1(差)到5(優)的評分。為了提供一個比較視角,該報告使用類似的提示生成了ChatGPT 3.5和ChatGPT 4.0(模型版本gpt-4-0613)的輸出,並使用相同的標準進行評估。

生物學實驗和濕實驗驗證 

該報告通過人工-agent協作使用ChatGPTv4 API的CRISPR-GPT進行了生物學實驗,作為該報告方法的真實世界濕實驗驗證。具體而言,該報告讓獨立的科學家(他們不熟悉基因編輯實驗)使用CRISPR-GPT來協助他們在一個癌症研究項目中進行基因敲除(KO)實驗。詳細的方法如下。

細胞系和細胞培養。A375細胞系在添加了10%胎牛血清(FBS,Gemini Bio)、100 U/ml青霉素和100ug/ml鏈黴素(Gibco)的DMEM高糖、GlutaMAX(Gibco)中培養,溫度為37 ∘C,CO2濃度為5%。

crRNA克隆。通過Golden Gate組裝方法使用BbsI或Esp3I(NEB)將4個crRNA(TGFBR1/SNAI1/BAX/BCL2L1)克隆到表達Cas12a的骨架載體中。使用U6測序引物通過Sanger測序驗證構建: 5'-GACTATCATATGCTTACCGT-3'。

慢病毒包裝和轉導。通過使用PEI轉染試劑(Sigma-Aldrich)將組裝好的慢病毒載體與VSV-G包膜和Delta-Vpr包裝質粒共轉染到HEK-293T細胞中來產生慢病毒。轉染48小時後收集上清液。使用8µg/mL polybrene通過1000*g 45分鐘的離心感染,以低MOI轉導A375細胞。24小時後,用1µg/mL嘌呤霉素篩選細胞以建立穩定表達的細胞系。

gDNA提取、PCR和測序。7天後使用QuickExtract(Lucigen)從篩選的細胞中提取基因組DNA。然後根據製造商的說明,使用含有Illumina測序接頭的引物和Phusion Flash高保真PCR Master Mix(ThermoFisher Scientific)擴增目標位點。在Illumina MiSeq平臺上生成配對末端讀數(150 bp)。 

結果

CRISPR-GPT利用LLM的推理能力、領域知識、檢索技術和外部工具,為基因編輯實驗設計任務提供全面的解決方案。它支持廣泛的基因編輯場景,包括單基因敲除、無雙鏈斷裂的鹼基編輯、通過prime編輯進行插入/缺失/替換,以及用於基因激活或抑制的表觀遺傳編輯(CRISPRa和CRISPRi)。

CRISPR-GPT通過三個模塊協助研究人員進行基因編輯實驗設計

CRISPR-GPT agent通過三個不同的模塊幫助研究人員設計基因編輯實驗。"元模式"為一般基因編輯場景(稱為元任務)提供專家定義的流程,使使用者,特別是基因編輯領域的新手,能夠使用這些流程。"自動模式"根據使用者輸入自動生成定制的必要設計任務清單,幫助各個層次的使用者實現目標。"問答模式"作為一個高級GPT-4聊天機器人,在整個設計過程中解答使用者與CRISPR和基因編輯相關的查詢。

元模式 

"元模式"涉及使用4種CRISPR基礎基因編輯系統(元任務)規劃和實施22個獨特的基因編輯實驗設計任務。它利用預定義的流程來幫助使用者徹底完成一個元任務。在這種模式下,CRISPR-GPT agent引導使用者完成設計基因編輯實驗所需的每個任務。這包括選擇合適的CRISPR系統、推薦遞送方法、設計sgRNA、預測sgRNA非靶向效率、選擇實驗方案以及計劃驗證實驗。

對於每一個設計任務,CRISPR-GPT agent都與使用者互動,應用各種技術和外部工具來提供最佳解決方案。例如,在選擇CRISPR系統時,CRISPR-GPT不斷與使用者互動,提供指示並收集資訊,根據已發表的方案提出選項。對於遞送方法推薦等與上下文相關的任務,CRISPR-GPT不僅會推薦常用方法,還會根據使用者的要求通過網路搜索提供定制解決方案。對於sgRNA/pegRNA設計,來自現有設計和出版物的多物種資料庫使CRISPR-GPT能夠根據使用者資訊快速提出預設計的sgRNA。在sgRNA/pegRNA設計之後,使用者可以根據CRISPR-GPT提供的詳細指示和代碼評估設計的指引的潛在非靶向效應。完成設計任務後,CRISPR-GPT根據互動歷史提供選定的方案,包括CRISPR系統選擇和遞送方法。最後,對於驗證任務,CRISPR-GPT利用外部API(如Primer3)來幫助使用者設計用於驗證實驗的引物。

自動模式

"自動模式"也有助於規劃和執行13個獨特的基因編輯實驗設計任務。與"元模式"不同的是,它不依賴預定義的元任務和流程;相反,它使用LLM-規劃器將使用者的請求分解為一系列依賴任務。例如,如果使用者請求"設計sgRNA以敲除人類EGFR",CRISPR-GPT agent會從請求中識別關鍵字,並列出必要的設計任務,如"CRISPR/Cas系統選擇"和"用於敲除的sgRNA設計"。此外,它使用來自初始請求的資訊(例如,靶基因"EGFR"和物種"人類")來自動填充相關欄位並生成sgRNA設計,而不需要使用者重複輸入。同時,CRISPR-GPT闡明其選擇背後的理由,允許使用者跟蹤該過程並在必要時進行修正。  

問答模式

在"元模式"和"自動模式"的設計任務中,CRISPR-GPT agent通過"問答模式"即時回應或建議CRISPR和基因編輯相關的查詢。例如,在選擇CRISPR系統後,尋求有關所選系統(如Cas12a)更多資訊的使用者可以通過提問"Q: 什麼是Cas12a?"來快速獲得答案。CRISPR-GPT利用其知識庫以及來自該領域專家選定資料庫的文件檢索,迅速提供準確、相關的資訊。

CRISPR-GPT通過人工專家評估在基因編輯設計任務中優於通用LLM

為了評估CRISPR-GPT agent的性能,該報告邀請了12位CRISPR和基因編輯領域的專家,設計了一組任務來測試CRISPR-GPT在協助研究人員進行實驗設計方面的能力。結果從四個不同方面進行評估:準確性、推理、完整性和簡潔性。準確性反映CRISPR-GPT是否能提供關於CRISPR研究和方法學當前狀態的準確資訊。推理評估CRISPR-GPT是否能對建議的設計提供有見地的、有充分依據的解釋。完整性確保使用者收到CRISPR實驗設計所需的所有資訊。最後,簡潔性確保CRISPR-GPT向使用者提供與設計任務直接相關的資訊,不必要的資訊最少。所有評估者都被要求對三種模式下的任務集在這四個方面進行1(差)到5(優)的評分。使用等效的提示生成ChatGPT 3.5和ChatGPT 4.0的回應,並使用相同的標準進行評分。

該報告觀察到,在該報告設計的任務集中,CRISPR-GPT在所有三種模式下的準確性明顯高於通用LLM-agent,因為該報告在CRISPR和基因編輯領域採用了大量領域知識來確保CRISPR-GPT agent的魯棒性。而ChatGPT 3.5和ChatGPT 4.0等通用LLM agent產生的回應由於已知的問題(包括領域知識不足和幻覺)而包含更多細微的事實錯誤。同時,該報告發現CRISPR-GPT和通用LLM agent在不同的任務集上都表現出良好的推理能力。對於"自動模式"相關的任務,CRISPR-GPT表現出更好的推理能力,這可能是由於agent中編碼的更好的提示技術。正如該報告所預期的那樣,"完整性"是通用LLM-agent在執行基因編輯實驗設計任務時的主要問題。它們通常可以為設計提供一般性指導,但由於缺乏領域知識和外部工具,無法提供設計細節。相反,CRISPR-GPT在設計任務中表現出更好的"完整性"性能分數,使使用者能夠僅根據CRISPR-GPT提供的資訊執行基因編輯實驗。值得注意的是,ChatGPT 3.5和4.0在"問答"模式下的"完整性"性能分數優於CRISPR-GPT。這種結果是由於"完整性"和"簡潔性"之間有意的權衡。通用LLM-agent直接生成的答案通常包含大量無關資訊,以便向使用者提供更完整的回應。這通常會讓使用者感到困惑,難以抓住關鍵資訊。在這種情況下,該報告有意設計CRISPR-GPT在所有不同模式下向使用者提供簡潔準確的答案,因此CRISPR-GPT在"簡潔性"性能分數上表現一致更好。 

總的來說,通過專家的評估,該報告發現CRISPR-GPT在各個方面都表現出顯著優於通用LLM-agent的性能,用於基因編輯實驗設計任務。儘管如此,CRISPR-GPT在更複雜的基因編輯場景和罕見的生物案例中遇到了困難。未來可以通過更多最新的領域知識和更好的外部工具集來進一步擴展和改進它。

CRISPR-GPT通過真實世界的應用展示其功效

為了展示CRISPR-GPT在協助研究人員設計基因編輯實驗方面的能力,該報告通過與CRISPR-GPT的持續互動,在人類A375細胞系中進行了基因敲除實驗。

在這個實驗中,該報告的目標是在人類A375細胞系中分別敲除4個基因(TGFBR1、SNAI1、BAX、BCL2L1)。首先,該報告選擇"元模式"從頭設計基因敲除實驗。按照CRISPR-GPT中選擇CRISPR系統的指示,該報告選擇了AsCas12a,因為該報告希望進行多位點編輯並降低潛在的非靶向編輯率。對於在A375細胞中遞送CRISPR系統,該報告遵循CRISPR-GPT的建議,使用慢病毒轉導,以確保Cas酶和sgRNA的穩定表達。 

然後,基於這些資訊,該報告能夠獲得Cas12a質粒(之前已有)。在設計sgRNA時,該報告特別針對人類TGFBR1/SNAI1/BAX/BCL2L1基因,充分意識到CRISPR-GPT提出的人類基因編輯的倫理影響。CRISPR-GPT從已發表的文庫中為每個基因提供了4個sgRNA序列,所以該報告能夠訂購合成序列。

隨後,CRISPR-GPT提供了gRNA克隆的方案。然後提供了詳細的說明,使用必要的質粒和病毒包裝組分,通過磷酸鈣轉染HEK293T細胞來產生慢病毒。在此之後,該報告完全按照CRISPR-GPT生成的方案,通過轉導過程,包括細胞培養程式、添加慢病毒以及使用聚凝乙烯(polybrene)促進高效轉導。為了進行驗證,該報告在CRISPR-GPT中選擇了新一代測序(NGS)用於突變檢測和敲除驗證,並遵循CRISPR-GPT agent提供的方案。為了準備NGS,該報告根據方案使用DNeasy Blood & Tissue Kit從細胞中提取基因組DNA。對於PCR引物設計這一關鍵步驟,該報告向CRISPR-GPT提供了詳細的序列資訊,它自動返回了一組用Primer3設計的引物,專門用於擴增目標位點。在該報告實驗的最後階段,CRISPR-GPT建議該報告在PCR產物上連接Illumina接頭用於文庫構建,並強調有必要用NCBI BLAST檢查引物特異性。這最後的驗證步驟對於防止錯配和確保測序結果能準確反映預期的基因組編輯至關重要。

最後,該報告分析了NGS的資料,觀察到在所有4個靶基因上都有持續高比例的預期編輯結果。通過這一過程,CRISPR-GPT提供了:(1)CRISPR系統選擇(2)向導RNA設計(3)遞送系統推薦(4)質粒和病毒載體選擇以及克隆方案(5)組織培養、細胞轉導程式(6)細胞收集和基因編輯效率量化方法(7)測序引物設計和讀出驗證方案。因此,該報告的專業知識與CRISPR-GPT的計算指導之間的動態互動,對執行一個精確且在倫理上審慎的基因編輯實驗至關重要。

安全和倫理問題 

當使用AI工具來指導基因組編輯時,會出現安全和倫理問題,從非法改變人類基因組的風險到涉及使用者基因組資訊時的隱私問題。

減輕人類可遺傳編輯的風險

CRISPR-Cas9等技術已經使改變人類基因組成為可能,這帶來了一些倫理和安全風險。特別是,生殖細胞和胚胎基因組編輯帶來了許多倫理挑戰,包括是否允許使用這項技術來增強正常的人類特徵(如身高或智力)。基於對倫理和安全的考量,生殖細胞和胚胎基因組編輯目前在美國和許多其他國家是非法的。為了確保CRISPR-GPT遵循可遺傳基因組編輯暫緩令中給出的指引。

CRISPR-GPT採用一種機制,以確保在所有任務中,使用者無法繞過現有步驟詢問他們正在編輯哪個生物體。agent會檢查編輯目標是否屬於人類組織或器官。如果發現編輯目標是人類器官,將觸發以下解決方案:當使用者繼續設計人類基因編輯實驗時發出警告說明。提供這個國際暫緩令的連結並註明。要求使用者在繼續之前確認他們理解風險並已閱讀這個國際指南。

保護使用者基因組資料隱私

其他問題與使用者資料隱私有關,特別是當使用AI工具可能交換人類基因組序列資訊時。該報告遵循醫療保健中的資料隱私和HIPAA隱私規則。儘管基因組規模的序列從根本上與身份相關,但最長20 bp的DNA片段被認為是安全的,無法識別人類身份。CPISPR-GPT配備了以下功能,以避免向公共LLM模型提供任何可識別的私人人類/患者序列。具體而言,該報告的解決方案是:

• CRISPR-GPT永遠不會在伺服器上儲存任何可識別的長基因組序列,這可能會洩露患者的私人資訊。
• CRISPR-GPT實現了一個過濾器,在將提示發送到外部LLM之前,檢測提示中是否包含任何≥20bp的A/T/G/C/U序列。在檢測到這種序列存在後,agent會發出錯誤警告,要求使用者手動刪除輸入中的此類序列。通過這種方式,避免將此類敏感資訊洩露給公共LLM模型。

CRISPR-GPT agent展示了LLM在自動化和增強複雜生物學實驗設計過程方面的非凡潛力。通過無縫整合LLM與領域知識、外部工具和模組化任務執行系統,CRISPR-GPT使研究人員能夠以前所未有的輕鬆和效率來駕馭CRISPR基因編輯實驗的複雜領域。CRISPR-GPT的多模態功能包括元任務流程、互動提示和隨需問答支援。研究人員可以利用agent的專業知識來規劃和執行基因編輯實驗,從CRISPR系統選擇和向導RNA設計到自動起草詳細的方案和驗證策略。這種簡化的工作流程不僅加速了設計過程,而且降低了出錯和疏漏的風險,從而提高了研究成果的品質和可重複性。

雖然在化學等其他科學領域存在LLM agent,但涉及活體材料的生物學實驗的複雜性需要一套不同的考量。與通常遵循明確方案的化學反應不同,生物學實驗需要複雜的程式,以考慮活體系統的動態特性。CRISPR-GPT通過提供針對具體實驗環境量身定制的詳細、分步指導來解決這一挑戰,確保研究人員能夠有效地駕馭使用活細胞和有機體的細微差別。

此外,CRISPR-GPT的自由風格提示和即時問答能力使其有別於許多現有的agent。研究人員可以提出非結構化的查詢,並獲得情境化的回應,促進與agent更自然、更直觀的互動。這一特性在面對實驗過程中可能出現的意外挑戰或不可預見的情況時非常有價值,使研究人員能夠尋求及時指導並根據需要調整他們的方法。

儘管CRISPR-GPT具有令人印象深刻的能力,但它並非沒有局限性。雖然agent可以設計單個組分,如向導RNA和引物,但它目前缺乏從自然語言輸入生成完整構建或載體的能力。這一局限性突顯了一個未來發展的領域。例如,基因編輯的模組化設計領域的最新進展,如FragMID,可以與CRISPR-GPT整合,實現LLM賦能研究人員探索和優化CRISPR設計和客製化策略的潛力,從而帶來更高效的基因編輯。

展望未來,CRISPR-GPT與自動化實驗室平臺和機器人技術的整合蘊藏著巨大的前景。通過連接計算設計和物理執行,研究人員可以利用agent的專業知識來編排端到端的自動化實驗,最大限度地減少人工干預,加速發現的步伐。

https://arxiv.org/pdf/2404.18021

個人見解

從第三方角度來看,這篇題為《CRISPR-GPT:一個自動化基因編輯實驗設計的大型語言模型Agent》的論文無疑代表了人工智能技術在生物醫學領域應用的一個重要里程碑。

本文的核心創新點在於巧妙地將大型語言模型(LLM)與領域知識和外部工具相結合,構建了一個名為CRISPR-GPT的智能agent,以協助研究人員設計和優化CRISPR基因編輯實驗。通過采用多種互動模式,如專家定義的元任務流程、自動任務分解、自由問答等,該系統將復雜的實驗設計過程分解為一系列易於管理的步驟,大大降低了技術門檻。

這一成果的意義首先體現在其對基因編輯技術的普及和應用的推動作用上。CRISPR作為一項革命性的生物技術,其在基礎研究和應用開發領域的前景不可限量。然而,設計一個成功的CRISPR實驗對於許多科研新手而言卻是一個巨大的挑戰。CRISPR-GPT的出現為他們提供了一個智能助手,引導他們以最優的方案和流程開展實驗,有望顯著提升這一領域的研究效率和產出。

同時,這項研究也為利用人工智能和大數據來驅動科學發現勾勒了一幅藍圖。通過無縫整合LLM的語言理解和推理能力,專家知識庫的權威解釋,以及各種任務專用的外部工具,CRISPR-GPT建立了一種全新的人機協作范式。這種范式不僅可以在基因編輯領域復制,也可以推廣到其他高度專業化、任務複雜的學科領域。可以想見,隨著這一模式的成熟和發展,我們有望看到越來越多的"AI科學家"在各個前沿領域崛起,成為人類專家強有力的助手和夥伴。

當然,本文也坦誠地指出了這一方案的局限性和有待完善之處。比如CRISPR-GPT目前還不能直接生成端到端的實驗流程,在處理一些複雜任務時也會遇到困難。這些問題為未來工作指明了努力的方向,比如進一步擴充其任務編排能力,引入更豐富的知識和工具,並在更多場景中予以測試和打磨。

此外,在充分肯定這一突破性成果的同時,我們也要理性看待其局限性和潛在風險。在技術層面,類似系統的有效性和可靠性還有待在更廣泛的實驗中得到嚴格驗證。在倫理層面,雖然CRISPR-GPT已經設置了一些基本的防護措施,但隨著應用場景的拓展,我們恐怕還需要更細緻入微、更具前瞻性的倫理規範框架。在實用層面,這類智能工具能否真正融入科研的日常工作流程,提高生產力的同時又不帶來過度依賴等問題,也是一個值得關注和研究的問題。

總的來說,CRISPR-GPT作為將LLM技術引入生物醫學研究的一次重要嘗試,其價值和意義不容小覷。它為攻克疾病、增進人類福祉提供了一個全新的思路和工具,展現了人工智能在賦能科學探索方面的巨大潛力。同時,它也為其他學科應用類似模式提供了有益的參考和借鑒。未來,隨著技術的不斷進步,倫理的持續審慎,以及跨領域協作的深入推進,相信這樣的智能輔助系統必將在更廣闊的疆域上大放異彩,開啟科學研究的智能化新紀元。我們有理由對這一前景充滿期待。

2024年企業購置AIGC應用的變化

生成式AI在2023年席捲消費市場,創下超過十億美元的驚人消費規模。而在2024年,企業市場的商機可望再翻倍成長。

去年,消費者花了無數時間與AI聊天機器人對話,或用擴散模型製作圖像和影片。但多數企業在生成式AI的應用似乎僅限於少數明顯的案例,並將「GPT包裝」產品作為新的銷售品項。一些懷疑論者質疑,生成式AI能否真正在企業市場擴大應用?我們會不會只能做那幾個老案例?新創公司能否賺到錢?這會不會只是炒作泡沫?

過去幾個月,a16z與幾十家財富500大企業和頂尖企業領袖對話,並調查了另外70位,希望了解他們如何使用、採購和編列生成式AI的預算。令人驚訝的是,企業在過去6個月內對生成式AI的態度和資源配置有了顯著的改變。雖然這些領導者對部署生成式AI仍有些保留,但他們也幾乎增加了3倍的預算,擴大基於開源模型的應用案例,並將更多工作負載從早期實驗轉移到生產環境。

這對創業者來說是巨大的機會。a16z相信,AI新創公司如果能夠

1)根據企業以AI為中心的戰略需求開發產品,同時預見和解決他們的痛點;

2)從服務導向轉變為打造可擴展的產品,就能搶佔這波新投資的商機,獲得大量的市場份額。

一如既往,要為企業開發和銷售任何產品,都需要深入了解客戶的預算、顧慮和技術藍圖。為了讓創業者掌握企業領導們部署生成式AI的決策方式,也讓AI高管了解其他同業如何應對相同的問題,a16z根據近期與這些領導人的交流,歸納出16個關於資源配置、模型和使用案例的重點考量。  

資源配置:預算大幅增加且不可逆轉

1. 生成式AI的預算正在飆升。  

2023年,a16z接觸的幾十家公司平均在基礎模型API、自行部署和微調模型上的支出為700萬美元。此外,幾乎每一家企業在生成式AI的早期實驗中都看到了前景,計劃在2024年將支出增加2到5倍,以支援更多工作負載投入生產。

2. 企業開始將AI投資重新分配到經常性軟體預算項目。

去年,企業在生成式AI上的支出不出所料大多來自「創新」預算和其他一次性的資金池。但在2024年,許多領導者正將這筆支出重新分配到更長期的軟體項目;不到四分之一的人表示今年的生成式AI支出會來自創新預算。a16z也開始看到一些企業將生成式AI預算用於節省人力成本,特別是在客戶服務領域,雖然規模還很小。如果這個趨勢持續下去,a16z認為這預示著未來企業在生成式AI上的支出將大幅增加。一家公司表示,每通電話由大語言模型(LLM)支援的客服系統可節省約6美元,總共可節省約90%的成本,因此計劃將生成式AI投資增加8倍。

以下是企業如何分配LLM支出的整體情況:

3. 衡量投資報酬率(ROI)仍是一門藝術和科學。

企業領導目前主要透過AI帶來的生產力提升來衡量ROI。雖然他們依賴淨推薦值(NPS)和客戶滿意度作為很好的代理指標,但也在尋找更具體的方法來量化回報,例如根據使用案例的不同,衡量營收增長、成本節約、效率提升和準確率改善等。短期內,企業領導仍在推廣這項技術,並找出最佳指標來量化回報,但未來2到3年,ROI將變得越來越重要。在領導者找出答案的同時,當員工表示他們正在更有效地利用時間時,許多人選擇相信這一點。

4. 實施和擴展生成式AI需要合適的技術人才,目前許多企業內部還不具備。

僅僅擁有模型提供商的API還不足以大規模構建和部署生成式AI解決方案。實施、維護和擴展必要的計算基礎設施需要高度專業化的人才。單是實施就占了2023年AI支出的最大領域之一,在某些情況下甚至是最大的。一位高管提到,「LLM可能只占構建使用案例成本的四分之一」,開發成本占了大部分預算。 

為了幫助企業在模型上快速啟動和運行,基礎模型提供商提供了並且仍在提供專業服務,通常與定制模型開發相關。a16z估計,這在2023年占了這些公司相當大一部分收入,除了性能之外,也是企業選擇特定模型提供商的主要原因之一。由於企業很難獲得合適的生成式AI人才,提供工具使企業更容易將生成式AI開發內部化的新創公司可能會看到更快的採用。

模型:企業正朝向多模型、開源的世界發展  

5. 多模型的未來。

就在6個多月前,絕大多數企業還在試驗1種(通常是OpenAI)或最多2種模型。而當a16z今天與企業領導交談時,他們都在測試,甚至在某些情況下已經在生產中使用多種模型,這讓他們能夠1)根據性能、規模和成本量身定制使用案例,2)避免供應商綁定,以及3)快速利用這個快速發展領域的進步成果。第三點對領導者來說尤為重要,因為模型排行榜是動態變化的,公司都渴望納入當前最先進的模型和開源模型,以獲得最佳效果。 

a16z認為我們可能會看到更多模型激增。在下表中,企業領導報告了許多正在測試的模型,這是未來將用於推動工作負載進入生產的模型的領先指標。在生產使用案例中,OpenAI仍然佔據主導地位,這在意料之中。

6. 開源正在蓬勃發展。 

這是過去6個月裡最令a16z驚訝的變化之一。a16z估計2023年的市場份額有80%到90%是封閉源代碼,其中大部分份額被OpenAI佔據。然而,46%的受訪者表示,他們在2024年更傾向或非常傾向於開源模型。在訪談中,近60%的AI領導者表示,他們有興趣增加開源使用,或者在微調後的開源模型性能與封閉源代碼模型大致相當時進行轉換。因此,在2024年及以後,企業預計會大幅轉向開源,一些企業明確以50/50的比例為目標,高於2023年80%封閉/20%開源的比例。

7. 雖然成本是開源吸引力的一個因素,但在關鍵選擇標準中,它的排名低於控制力和客制化。

控制力(專有資料的安全性和了解模型產生特定輸出的原因)和客制化(能夠針對特定使用案例進行有效微調)遠遠超過成本,成為採用開源的主要原因。a16z很驚訝成本並不是最重要的考量,但這反映出領導層目前堅信,生成式AI創造的超額價值可能遠遠超過其價格。正如一位高管解釋的那樣:「獲得準確的答案是值得花錢的」。

8. 對控制力的渴望源於敏感的使用案例和企業資料安全顧慮。

由於法規或資料安全顧慮,企業仍然不願與封閉源模型提供商共享其專有資料,而那些以IP為核心的企業在商業模式上尤其保守。雖然一些領導者通過自行託管開源模型來解決這一顧慮,但其他人則表示,他們優先考慮具有虛擬私有雲(VPC)整合的模型。

9. 企業通常透過微調而非從頭構建模型來客制化模型。

2023年,有很多關於構建BloombergGPT這樣的定制模型的討論。在2024年,企業仍然對定制模型感興趣,但隨著優質開源模型的興起,大多數企業選擇不從頭開始訓練自己的LLM,而是使用檢索增強生成(RAG)或微調開源模型以滿足其特定需求。  

10. 雲端仍然對模型採購決策有很大影響。  

2023年,出於安全原因,許多企業透過其現有的雲端服務提供商(CSP)購買模型,領導者更擔心封閉源模型會濫用其資料,而不是CSP,並希望避免冗長的採購流程。2024年仍然如此,這意味著CSP和首選模型之間的相關性相當高:Azure用戶通常偏好OpenAI,而Amazon用戶偏好Anthropic或Cohere。如下圖所示,在72%透過API訪問模型的企業中,超過一半使用了其CSP託管的模型。(請注意,超過四分之一的受訪者進行了自託管,可能是為了運行開源模型。)

11. 客戶仍然關注早期上市的功能。

雖然領導者將推理能力、可靠性和易用性(例如,在其CSP上)列為採用特定模型的首要原因,但領導者也傾向於具有其他差異化功能的模型。例如,多位領導者將之前20萬token的上下文視窗作為採用Anthropic的關鍵原因,而其他人則因為Cohere早期推出的易用微調服務而採用它。

12. 儘管如此,大多數企業認為模型性能正在趨同。 

雖然科技界的大部分人都專注於將模型性能與公開基準進行比較,但企業領導更關注將微調後的開源模型和微調後的封閉源模型與自己的內部基準集進行比較。有趣的是,儘管封閉源模型在外部基準測試中通常表現更好,但由於開源模型更容易針對特定使用案例進行微調,企業領導仍然給予它們相對較高的淨推薦值(NPS)(在某些情況下甚至更高)。一家公司發現,「在微調之後,Mistral和Llama的性能幾乎與OpenAI一樣好,但成本要低得多」。按照這些標準,模型性能的趨同速度甚至比a16z預期的還要快,這讓領導者有更多非常強大的模型可供選擇。

13. 優化靈活性。

大多數企業在設計應用程式時,使在模型之間切換只需要一個API更改。一些公司甚至在預先測試提示,使更改只需一個開關即可完成,而其他公司則建立了「模型花園」,可以根據需要將模型部署到不同的應用程式。企業採取這種方法,一方面是因為他們從雲端時代吸取了一些艱難的教訓,需要減少對提供商的依賴,另一方面是因為市場發展如此之快,致力於單一供應商似乎是不明智的。

使用案例:更多轉移到生產環境

14. 企業正在構建而非購買應用,至少目前如此。  

企業絕大多數專注於內部構建應用,並將缺乏經過實戰檢驗、佔據主導地位的企業AI應用作為驅動因素之一。畢竟,這類應用還沒有魔力象限(至少目前還沒有!)。基礎模型透過提供API,也使企業比以往任何時候都更容易構建自己的AI應用。企業現在正在構建自己版本的熟悉案例,如客戶支援和內部聊天機器人,同時也在嘗試更新穎的使用案例,如編寫消費品配方、縮小分子發現範圍和提供銷售建議。許多人已經寫過關於「GPT包裝器」(即新創公司為LLM的知名輸出建立一個熟悉的介面,如聊天機器人)的有限差異化;a16z認為這些公司將難以競爭的一個原因是,AI進一步降低了內部構建類似應用的門檻。

然而,當更多面向企業的AI應用程式進入市場時,這種情況是否會轉變,目前尚未定論。雖然一位領導者指出,儘管他們正在內部構建許多使用案例,但他們對「將會出現新工具」持樂觀態度,並希望「使用現有最好的工具」。其他人則認為,生成式AI越來越成為一種「戰略工具」,使企業能夠將某些功能內部化,而不是像傳統那樣依賴外部供應商。考慮到這些動態,a16z認為,在這個市場中,那些不僅僅局限於「LLM+UI」模式,而是從根本上重新思考企業基礎工作流程或幫助企業更好地利用其專有資料的應用程式,將有望獲得特別出色的表現。

15. 企業對內部使用案例感到興奮,但對外部案例仍持謹慎態度。 

這是因為企業對生成式AI仍存在2個主要顧慮:

1)幻覺和安全性的潛在問題;

2)部署生成式AI的公關問題,特別是在敏感的消費者領域(如醫療保健和金融服務)。

去年最受歡迎的使用案例要麼專注於內部生產力,要麼在到達客戶之前由人工審核,如編程輔助、客戶支援和行銷。如下圖所示,這些使用案例在2024年仍然主導企業應用,企業以更高的比例將完全內部的使用案例(如文本摘要和知識管理,例如內部聊天機器人)推向生產,而不是敏感的人工參與的使用案例(如合同審查)或面向客戶的使用案例(如外部聊天機器人或推薦演算法)。企業渴望避免加拿大航空客戶服務事件等生成式AI失誤造成的負面影響。由於大多數企業仍然非常關注這些問題,因此能夠幫助控制這些問題的新創公司可能會獲得大量採用。

總體機會:巨大且快速增長 

16. a16z認為,到2024年底,模型API和微調的總支出將增長到超過50億美元的執行率,企業支出將占這一機會的很大一部分。

根據a16z的計算,a16z估計模型API(包括微調)市場在2023年底的營收執行率約為15-20億美元,其中包括透過Azure在OpenAI模型上的支出。考慮到整體市場的預期增長和企業的具體表示,僅這一領域的支出到今年年底就將增長到至少50億美元的執行率,並且有巨大的上行潛力。正如a16z所討論的,企業已將生成式AI部署列為優先事項,增加預算並將其重新分配到標準軟體項目,針對不同模型優化使用案例,並計劃在2024年將更多工作負載推向生產,這意味著他們可能會推動這一增長的很大一部分。 

在過去6個月裡,企業從高層發出了尋找和部署生成式AI解決方案的指令。過去需要一年多才能達成的交易現在在2到3個月內就被推動完成,而且這些交易的規模比過去大得多。雖然這篇文章著重於基礎模型層面,但a16z也認為企業的這一機會延伸到堆疊的其他部分,從幫助微調的工具、模型服務、應用程式構建,到專門構建的原生AI應用程式。我們正處於企業生成式AI的拐點,a16z很高興能夠與服務這個充滿活力和不斷增長的市場的下一代公司合作。

https://a16z.com/generative-ai-enterprise-2024/

個人見解:

這份由a16z發布的報告以翔實的第一手調研和深入的分析,為我們勾勒出企業在生成式AI領域的最新發展和未來趨勢。報告揭示,儘管仍存在一些顧慮,但企業正以前所未有的速度擁抱生成式AI,大幅增加相關預算,並積極將之前的實驗項目推向生產環境。

這一轉變的背後,是企業領導者對生成式AI在提升生產力、優化流程、創造價值等方面潛力的日益認同。隨著技術的快速進步和開源模型的崛起,企業比以往任何時候都更容易利用這些先進的AI能力來重塑業務。生成式AI正在從曇花一現的炒作走向真正的產業變革。

不過,要真正實現這一願景,仍需克服不少障礙。企業普遍缺乏頂尖的AI人才,對資料安全和模型魔性輸出也有合理的顧慮。如何在控制風險的同時,將生成式AI深度整合到關鍵業務中,將是一大考驗。此外,儘管報告顯示當前企業更傾向自建應用,但我認為隨著第三方解決方案的日益成熟,未來市場格局可能出現變化。新創公司若能洞悉企業痛點,為其提供靈活、穩定、安全的生成式AI工具和平台,定能在這場變革中搶得先機。

a16z的這份報告清晰地展現了生成式AI在企業市場爆發式增長的趨勢,為創業者指明了巨大的創新與創業機會。但要真正抓住這波浪潮,恐怕不能簡單複製to C的模式,而需對企業的獨特需求有深刻理解,在魔性、隱私、安全等核心問題上狠下功夫,以降低企業的顧慮,贏得信任。相信在大家的共同努力下,生成式AI必將重塑更多行業,開創智能經濟的新時代。

醫療AI的一大步: Google Med-Gemini

人工智慧技術在醫療領域的應用一直備受矚目。近年來,隨著自然語言處理和電腦視覺的快速發展,智慧醫療系統的能力不斷提升,在輔助診斷、預測疾病風險、優化治療方案等方面展現出巨大潛力。作為這一領域的領軍企業之一,Google推出了Med-Gemini系列模型,為醫療AI技術的發展樹立了新的里程碑。

Med-Gemini模型建立在谷歌此前發佈的Gemini大型多模態模型之上。Gemini透過在海量文本、圖像、影音等跨模態資料上的預訓練,具備了驚人的語言理解和生成能力。在此基礎上,Med-Gemini針對醫療場景進行了進一步的調校和優化,旨在為醫療決策提供更專業、更精準的支援。

本文將從技術架構、基準測試和潛在應用等角度,深入剖析Med-Gemini系列模型的創新之處。透過客觀呈現其在多個任務上的出色表現,展望這一突破性進展對未來智慧醫療的深遠影響,並討論在實際部署過程中可能面臨的挑戰。

https://arxiv.org/pdf/2404.18416

研究方法

Med-Gemini系列模型的開發流程可分為三個主要階段:模型微調、多模態理解和長文本處理。

在模型微調階段,研究團隊採用了自訓練(self-training)和搜尋工具使用(tool use)相結合的策略,以提升模型在醫學推理任務上的表現。通過在大規模醫學問答資料如MedQA上微調,並引入外部搜尋結果作為額外線索,Med-Gemini顯著強化了處理複雜病例時的分析和决策能力。同時,研究人員設計了一種基於不確定性的搜尋機制,使模型能主動查閱資料以彌補知識盲區,進一步提高了輸出的可靠性。

對於多模態理解,團隊在Med-Gemini的基礎上融合了領域特定的編碼器,以適應醫學影像、病理切片等特殊資料型態。藉助龐大的跨模態醫療資料集,模型學會了從視覺信息中準確提取關鍵診斷線索,並與文本、語音等其他模態的資訊進行整合,形成更全面的臨床認知。

在長文本處理方面,Med-Gemini透過編碼器和注意力機制的優化,實現了對數萬字量級医疗记录的高效编码和理解。模型能夠在海量病歷資料中準確定位關鍵資訊,總結患者的病史、主訴、檢查和用藥情況等,並支援醫療人員進行縱向追蹤分析,及早發現疾病風險因子。

模型評估

為全面評估Med-Gemini的性能,研究團隊在14項權威醫療基準測試中對其進行了嚴格的考核,涵蓋醫學知識、臨床推理、基因組學、醫學影像等諸多領域。

在備受矚目的MedQA測驗中,Med-Gemini憑藉獨特的不確定性引導搜尋機制,以91.1%的準確率刷新了紀錄,比此前最好的Med-PaLM 2模型高出4.6個百分點。為進一步驗證結果的可靠性,研究人員邀請臨床專家對MedQA測試集進行了仔細核查,剔除了部分存在錯誤或歧義的試題,確保性能提升的確切性。

除MedQA外,Med-Gemini在新英格蘭醫學雜誌案例討論(NEJM CPC)、基因分析(GeneTuring)等複雜任務上亦有亮眼表現,充分展現了其在醫學推理方面的優勢。而在涉及影像、心電圖等多模態資料的測試中,Med-Gemini的表現同樣出類拔萃。例如在7項健康醫療類的視覺問答任務上,其平均優於GPT-4V模型44.5%。

長文本處理能力是Med-Gemini的另一大亮點。它在醫療記錄的關鍵資訊檢索(MIMIC-III)以及醫學教學影片問答(MedVidQA)等需分析海量文本的任務中均取得了最佳成績,憑藉情境學習能力超越了此前專門構建的系統,彰顯了該模型在實際應用場景下的潛力。

實驗結果

Med-Gemini在一系列基準測試中的優異表現,為其在真實醫療場景中的應用奠定了堅實基礎。為進一步評估其實用價值,研究團隊設計了醫學文本摘要、轉診信撰寫、醫學術語簡化等任務,並與人類專家的表現進行對比。

結果顯示,在自動生成病歷摘要方面,Med-Gemini的輸出在臨床可用性上達到甚至超越了人類醫生的水準。根據臨床醫生的評估,模型生成的摘要在準確性、覆蓋面、簡潔性等方面皆優於人工撰寫的樣本。這一發現意味著Med-Gemini有望顯著減輕醫護人員的文書負擔,為其騰出更多時間專注於患者溝通和臨床診療。

在轉診信的自動生成任務中,Med-Gemini的表現同樣出色。經盲評,83%的受試醫生認為模型撰寫的轉診信總體優於或等同於人類專家。這預示著該系統在未來有望作為智慧助手,協助醫生高效地完成常見的寫作任務,提升溝通效率。

Med-Gemini在多模態對話和長文本處理領域的潛力同樣引人注目。研究人員透過真實樣本展示了模型在皮膚病理和放射診斷中的應用前景。藉助多模態理解和醫學知識圖譜,該系統能夠引導患者提供症狀細節和相關檢查,並給出專業的初步判斷。雖尚不能完全取代醫生,但這一功能或可作為前置篩查和分診的有力輔助。

在生物醫學研究領域,Med-Gemini展現出從海量文獻中提煉關鍵資訊,加速基因型-表型關聯分析的能力。透過長文本處理技術,它成功地總結了大量關於FTO基因與肥胖症關係的研究發現,將具說服力的實驗證據以簡明扼要的方式呈現給使用者。這一案例表明,Med-Gemini有望成為生物醫學研究人員的得力助手,幫助他們及時掌握最新進展,聚焦關鍵科學問題。

綜合以上實驗結果,我們可以合理預期,Med-Gemini在未來智慧醫療體系中將扮演日益重要的角色。它不僅能夠為臨床診療提供更精準的决策支持,還可顯著提升醫患溝通和跨專科協作的效率。隨著技術的不斷成熟和完善,這一突破性的AI系統有望為醫療服務帶來全方位的變革。

結論

Med-Gemini系列模型在醫療AI領域的突破性進展,為智慧醫療系統的發展開啟了嶄新的篇章。藉助海量醫學知識和多模態數據的訓練,這一全新的AI架構展現出驚人的醫學理解和推理能力。它不僅在權威基準測試中取得了領先業界的成績,更在面向真實世界的任務中初步證明了其實用價值。

然而,醫療領域事關人命,對AI系統的安全性和可靠性有著極高的要求。儘管Med-Gemini在實驗環境下表現出色,其真正投入臨床應用仍需經過長期、嚴格的驗證。相關技術在落地過程中可能面臨資料品質參差、隱私保護、法律監管等諸多挑戰。這就要求技術團隊與醫療機構、政策制定者等多方通力合作,在確保患者利益的前提下穩妥推進。

Med-Gemini的發布彰顯了Google在智慧醫療領域的雄心和實力。作為該領域的技術領軍者,谷歌充分利用了自身在自然語言處理、知識圖譜等方面的優勢,構建了一個全方位的醫療AI平台。可以預見,隨著Med-Gemini的不斷迭代升級,它必將與其他先進醫療系統一道,為人類健康事業做出更多貢獻。

我們有理由相信,隨著人工智慧技術的日益成熟,智慧醫療將不再是遙不可及的願景,而是切實惠及大眾的現實。在這一進程中,以Med-Gemini為代表的尖端AI系統將扮演關鍵的推動者和賦能者角色。它們與人類醫護工作者優勢互補、協同作業,必將開創醫療服務的嶄新局面,讓更多患者以更低成本獲得更優質的健康照護。這無疑將是智慧科技造福人類的又一重大里程碑。

不過,任何新技術的發展和應用都不可能一蹴而就。在憧憬智慧醫療美好前景的同時,吾人亦需保持理性和警惕。AI系統畢竟是基於資料和機器學習算法構建的,其判斷並非絕對無誤,在複雜多變的臨床場景中可能面臨知識盲區和推理謬誤。因此,如何建立人機協同的長效機制,發揮各自所長、抑制彼此局限,是智慧醫療走向成熟亟需攻克的難題。

此外,AI技術在醫療領域的應用還可能引發一系列倫理難題。機器偏見、隱私保護、責任歸屬等問題若處理不當,則可能加劇健康照護的不平等,侵犯患者的合法權益,甚至動搖社會對醫療系統的信任根基。這就需要技術團隊自始至終將倫理考量融入系統設計之中,並與各界持份者保持坦誠溝通,在公眾監督下穩步推進。