本文來自微信公眾號:海外獨角獸 (ID:unicornobserver),作者:Cage、程天一,編輯:penny,原文標題:《ChatGPT Plugin:被高估的“App Store時刻”,軟件和SaaS生態的重組開端》,頭圖來自:視覺中國
(相關資料圖)
“OpenAI 的 App Store 時刻”,這是 3 個月前 ChatGPT plugin 剛剛推出時市場的反應。過去 3 個月里,OpenAI 采取了一種相當保守的方式為這個生態放量,通過審核的 plugin 數量只有不到 300 個,至今使用 plugin 的用戶量級也只有數十萬量級。
一方面這是 OpenAI 有意為之的結果。用 OpenAI 總裁 Greg Brockman 的話來說,ChatGPT plugins 開放成本非常低 —— 基本上就是 API 的文檔,只不過是用來給語言模型讀。另一方面這也暴露出 OpenAI 并不是全能的,它對于如何培育一個安全、蓬勃發展又能快速上量的開放平臺和應用生態并沒有過多的經驗。Sam Altman 甚至承認 ChatGPT plugin 還沒有迎來 Product-Market-Fit。
盡管沒有想象中摧枯拉朽,plugin 仍然是 ChatGPT 這個產品的一個里程碑,讓 OpenAI 邁出了“開放”的又一步。我們在本文探討了圍繞 plugin 的炒作褪去后一些真正長期重要的問題:
究竟是哪些公司和開發者在積極接入 plugin?
plugin 如何同時確保安全、性能和整個系統的穩定性?
觀察一個開放平臺之上的應用生態的思考框架是什么?
plugin 帶來的新機會有哪些?
在這些問題之外,短期最值得期待的是在 plugin 標準互通的情況下,微軟能把這個生態玩出來什么花樣:
OpenAI 缺審核,缺產品經理,缺運營這個生態的專家,缺更好的、比聊天界面搭配小組件更廣泛的 UI。這些微軟都有 —— 大量可以投入的人員,廣泛可供 plugin 嵌入并發揮作用的一系列產品(消費者端的 Bing Chat 和 Windows 11 Copilot,企業端的 Microsoft 365 Copilot 和 Dynamis 365 Copilot 等)。
一、背景
OpenAI 在 23 年 3 月 23 日發布了 ChatGPT plugin。盡管官方強調這一舉動是為了更好研究 ChatGPT 在現實世界中的使用情況從而解決安全問題,外界對它在 OpenAI 生態打造、商業層面的潛力寄予了厚望,中英文社區一度認為這是 OpenAI 的“App Store 時刻”,并且直接“干掉了 LangChain 和 Fixie”。
4 月的開發者群體和 ChatGPT 用戶仍然延續著對這個生態的向往,除了官方合作伙伴外,大量的第三方 plugin 開始基于 OpenAI 定義的這套框架和標準被開發,用戶則瘋狂涌向 waitlist 并且在 Twitter 上成為 Code Interpreter 等明星 plugin 的自來水。
最密集的變化發生在 5 月,OpenAI 終于開始更大范圍放量,并且在 5 月下旬宣布向 Plus 訂閱用戶全量開放,提供 70 多個第三方 plugins。不過這種全量開放的策略仍然十分克制,Plus 用戶必須打開 Beta features 的開關,iOS app 也默認不顯示 Plugin,用戶得在舊會話中找到自己使用過的 Plugin。
在移動端使用 Plugin Source: Pietre Schiano
與此并行的是微軟在 Build 大會上宣布采用 OpenAI 的 plugin 標準,將允許開發者構建跨 OpenAI(ChatGPT)和微軟(Bing Chat、各產品線 Copilot)生態的 plugin,通過 ChatGPT plugin、Teams message extensions 和 Power Platform connectors 布局了個很全面的插件框架。鑒于 OpenAI 的研究屬性,微軟反而更有可能把 plugin 生態發揚光大。
在大規模放量之后,ChatGPT 在雙邊面臨的現實是plugin 仍然是一個相當早期的生態:
鑒于整個 plugin 的用戶數量還只有幾十萬量級,Plugin 的官方合作伙伴們可能短時間內無法獲得特別大的新增流量;ChatGPT 目前的 UI 本身也有很多限制;Airbnb 則覺得這種聊天框配合底部小組件的 UI 并不真的適合旅行產品,在其 plugin 上線前終止了這一項目;
個人開發者們如果有現成的 api 可用,可以在幾十分鐘內按照 OpenAI 的標準提交 api doc 等文件,但是滿足 UI 和數據隱私規范并通過審核往往要等待一段時間并且充滿不確定性;
用戶們則發現大多數 plugin 都比 Demo 顯示的要更加粗糙,很難在 ChatGPT 內部擁有統一的產品體驗;多數的討論集中在 Code Interpreter 和 Web Browsing,并且 Web Browsing 的探索過程也經常令人抓狂。
ChatGPT 的頻繁“試錯” Source: Reddit
我們覺得是時候將 OpenAI 當做一個地球物種 —— 它擁有世界頂級的 AI 研究員們,但是他們很難神奇地、天然地解決產品、雙邊生態構建的節奏等必然存在的挑戰 ——更加貼近現實地想象 plugin 的現狀、生態潛力和演進可能性,這也是本文探討的重點問題。
二、Plugin 的現有合作和未來影響
ChatGPT plugin 生態一度激發了大家對 ChatGPT 這個歷史上用戶增長曲線最陡峭產品的想象力。2 個月以來,plugin 也有不少功能的更新、新插件的引入和使用規模的放開。在這里總結下當下 plugin 擁有的一些能力,看看最近的更新是否符合預期。
截至 2023 年 5 月底,ChatGPT 插件商店中提供了 85 個插件,其按照能力大致可以分為 6 類:
1. 外部交互:這類插件提供了與外部的網頁和產品進行交互的能力。
其中 Browsing 是 OpenAI 官方推出的插件,思路與其在 21 年底的論文 WebGPT 一脈相承:使用語言模型去探索和理解外部網絡上的內容。在多個用戶訪談中提到,如果有明確目標的情況下,其瀏覽和總結能力比 New Bing 來得更好,但弊端是穩定性相對差些。
而外部工具中最好用的是 Zapier,Zapier 作為聚合器中的領先者,本身的能力是和外部 5000 余個應用的 api 去做交互,有了很完備的 api 交互邏輯。而由于 input context 的限制(容納不下數十上百個 api 的 prompt 說明文檔)和 OpenAI 在產品工程側重心的差異,短期之內 Plugin 生態的聚合能力是比較薄弱的一項。因此 Zapier 在中短期是受益于 ChatGPT 這個大腦的文本理解能力的。
2. 編程開發:提供開發環境,或編程開發的生產力工具。
受到最多關注的是 OpenAI 官方開發的 Code Interpreter。它提供了一個開發的沙盒環境,在環境中可以對用戶想要執行的代碼和分析的數據進行各類實驗。OpenAI 在 Python 安全方面做了很多工作,來確保在這個環境中執行的代碼實驗會被安全地隔離在環境中,不直接地對外部網絡環境造成改變和影響。由于這一特性,大家對 Code Interpreter 的使用就集中在 Python 另一個不需要部署上線的特長上——數據分析。Code Interpreter 能對數據做總結和加工,并根據指令產出言之有物的數據可視化,這一點隱隱有著超越傳統 BI 的希望,只是在可控性上還需繼續加強。
3. 個性化交互:為 ChatGPT 帶來記憶和個性化的能力。
之前在 Pinecone 的研究中提到過,Retrieval 插件被 Greg 認為是所有插件中最獨特的,因為它補足了 ChatGPT 原本沒有的從個性化記憶和專有數據中做 Retrieval Augmentation 的能力。插件的結構很簡單,從各類 vector DB 的 api 中取出與 prompt 語義接近的內容交給 ChatGPT 進行理解和學習。此外,DAN 也是這類中一個比較有趣的插件,其提供了為 ChatGPT 改變個性的能力。
4. 生活助手:衣食住行的信息整合。
這一品類是大公司涌入最多的,如 Expedia、Kayak 是旅行機酒預訂,OpenTable 是預約餐廳,Instacart 是購買生鮮的領先平臺。這類產品希望通過 ChatGPT 對自然語言的理解能力,抓住這個新平臺作為增量流量入口。一方面,ChatGPT 將這一功能全量的進度相對比較克制和保守,并沒有發揮比較明顯的引流作用;但另一方面,Chat 這一交互形式篩選下來的用戶質量是比傳統獲客渠道來得更高的。
5. 垂直領域:獲得專有數據的窗口。
有許多垂直領域高質量的數據并不是 ChatGPT 核心的技能點,因此垂直領域的插件能為其帶來更專業、專有的內容。例如 Vogue 有時尚領域的數據,Crypto Prices 有 web3 領域的公開數據,UN 有聯合國每年政策變化的相關文本。這些都是在垂直領域做理解和生成時重要的信息。
6. 辦公效率:生產力工具。
這類插件大多是辦公效率小工具的集合,例如 PDF 閱讀總結、待辦事項記錄、發郵件、文字轉語音是目前主要的插件能力。
以上介紹了當前 Plugin 的具體能力,會發現其在很多領域對不同垂直領域有所影響,有些可能會對大公司的現有產品形態造成一定沖擊,有些則是獨立開發者積累早期高質量用戶的好機會。接下來就分別對這些領域的影響進行梳理。
1. 搜索
案例:Google, Bing, Perplexity
? 使用頻次:★★★★★
? 短期影響:★★★★(short)
? 長期影響:★★★(short)
ChatGPT 集成了 browsing 功能在短期之內會對搜索引擎的能力有一定的沖擊。因為 LLM 很大程度上就是將互聯網上的公開信息學習了一遍,結合了 browsing 能力后,本身又繼承了一定的內容整合和推理能力,因此使用 ChatGPT 的用戶在短期會顯著減少使用搜索的頻率。
但谷歌的反應也是比較迅速的,已經在內部開放了集成 LLM 的搜索引擎。以谷歌的 infra 實力和對搜索引擎的深入理解,完全有可能在 Google 搜索引擎中做出比 New Bing 和 ChatGPT 更好的 AI 搜索引擎。但無論是哪個公司獲勝,大家對搜索的認知在長期一定會被 LLM 部分顛覆,傳統的索引排序式的 query 心智會漸漸被生成式的 prompt 心智侵蝕。
2. 聚合器
案例:Zapier
? 使用頻次:★★★
? 短期影響:★★★★ (long)
? 長期影響:★★★★(short)
LLM 時代的跨應用調度和交互需求會顯著增長,因此盡管目前聚合器的使用頻率相對低頻,我們還是給到了中等頻次的評價。
當前 ChatGPT 有了很強的工具使用能力,但缺少在 api 聚合方面的 know-how,因此 Plugin 的出現在中短期之內利好 Zapier 這類聚合器產品。Zapier 在此領域積累很深,現在如果大家想在 ChatGPT 上做一些復雜操作的時候:比如將文本總結之后發社交媒體,或是記錄在 Google Workspace 中,大家都會選擇用 ChatGPT + Zapier 的方式來實現。在很多 use case 中,ChatGPT 只需要接入聚合器,就能做到非常好的用戶體驗,它也不需要接入大量 api,相當于類似 SEO 的部分由聚合器完全提供了。
但長期上,這類產品面臨以下沖擊:一方面, api 的組織形式可能會發生變化,LLM 時代可能跨產品交互的頻次和。OpenAI 最近發布了函數調用能力,使 api 的可用性顯著提升,這些變化可能會弱化 Zapier 的護城河。另一方面,聚合器可能會成為操作系統機會中的一部分,微軟、谷歌和蘋果都可能基于自己的系統去建立相應的能力,競爭激烈。
3. 線上預訂平臺
案例:Expedia, Kayak
? 使用頻次:★★
? 短期影響:★★(long)
? 長期影響:★★★★★ (short)
這類平臺主要提供的能力是對平臺上信息的組織和履約能力。組織指的是更了解用戶,幫助其高效地預約到合適的機酒;履約指的是保障交易的安全性和流暢性,避免違約的風險。
隨著 ChatGPT Plugin 的推出,短期之內這類平臺可能會增加一個高質量獲客的渠道,但是長期是很可能受到比較大沖擊的。因為 Chat 帶來的語義理解能力提高,提供了一個更好的信息組織方式,用戶能高效地給出需求,找到合適的航班信息,平臺留下的主要壁壘是其交易的履約價值,這部分的價值比原來薄了很多。
4. O2O / 電商平臺
案例:Instacart
? 使用頻次:★★★
? 短期影響:★★★(long)
? 長期影響:★★★(long)
O2O / 電商類型的平臺與線上預訂平臺相比,多了線下的供應鏈組織能力。這一部分能力是不會受到 LLM 領域沖擊的,其中的 AI 算法也基本是優化方向的傳統 ML 算法,并不是 LLM 擅長處理和調度的任務類型。因此,這類平臺受到的影響相對較小,更多是多了一個高質量的獲客渠道。
5. 獨立開發者 & 創業者
案例:Giftwrap
? 短期影響:★★★★(long)
? 長期影響:★★★(long)
對于創業者來說,找到 PMF 和早期高質量用戶是一個有難度的事情,而加入 ChatGPT Plugin 是一條比較快速的捷徑。Chat 形式帶來的用戶,比傳統投放渠道獲得的用戶質量會高不少,因為都是經過門檻比較高的交互后留存的,轉化率會更高一些。而且接入的產品可以拿到用戶完整的對話 prompt,這對理解消費者的用戶畫像也是相當關鍵的。
三、Plugin 的開發方式和能力邊界
Plugin 開發門檻并不高
OpenAI 提供了一套 plugin 接入范式,供企業和個人開發者根據指南進行接入。低門檻的接入方式是經過 OpenAI 官方設計的。用 Greg 的話說,就是為一個語言模型寫 api 的文檔:
接入的開發門檻很低,只需要寫兩個核心組件:
1. api 接口,其中包含多個函數,負責定義不同場景下數據的輸入和輸出。以后文將展開的 Speak 產品為例,需要執行翻譯任務時將調用 Translate 接口,需要解釋具體表達時使用 Explain Pharse 接口。而具體接口的邏輯選擇就要用到第二個組件了;
2. Manifest 說明文件,通過自然語言 prompt 教會產品調用 api。這個文件的核心是一段自然語言介紹,幫助機器理解這個插件本身的能力。當用戶開啟某些插件時,ChatGPT 會理解 prompt 中需要的能力是否與插件 manifest 文件中的描述匹配,進而判斷何時調用 api ,以及使用哪個接口能最準確地實現目標。
例如 Speak 這款多語言翻譯和學習的產品插件中,其 Manifest 插件的文本內容被破解出來,大致內容如下:
? 當用戶問到一個其他語言中的內容時,call Speak 插件來響應用戶的語言學習意圖;
? 當用戶提供了一個明確的短語或句子需要翻譯時,調用 Translate 接口;
? 當用戶給了一個比較模糊的任務,比如“如何用西班牙語稱贊別人的穿著”時,調用 explainTask 接口;
? 當用戶給一個表達需要詳細的解釋,比如“putain 在法語中代表什么”時,調用 explainPhrase 接口。
這個文檔的寫作風格目前比較接近開發過程中的文檔和注釋。但未來當更多 api 接入之后,肯定會有文檔風格的差異,因為未來產品需要在其他同品類產品中脫穎而出,產品文檔會以接近 SEO 的思路體現出自己產品的差異化優勢,做文檔和 api 的優化。
Plugin 提供一套安全評估能力
隨著 Plugin 的開發和使用量增大,plugin 的安全問題會逐漸成為一個重要的因素。一方面,plugin 提供方是否有過度使用用戶的數據;另一方面,plugin 是否會為了流量提高自己活躍的優先級。
在 2017 年,Adobe 曾經因為在用戶的 Chrome extension 插件中加入了靜默安裝和訪問網站權限陷入了爭論。插件中包含了這樣的能力:能把用戶打開的每一個網頁轉成 PDF,因此要求用戶給插件開放讀取和修改網頁的能力,引起了諸多用戶的不滿。
安全和權限是產品可用性的一個重要組成部分,Adobe 和 Chrome 在那次爭議中都有一定的問題。Adobe 的產品很可能不會過度 track 用戶的訪問歷史,但還是應該基于用戶對這一功能的需求不那么激進地推進;Chrome 在權限管理時,當時沒有把讀取和修改網頁內容的權限分級拆分出來,導致用戶擔心插件會在生成時修改內容。
而 ChatGPT Plugin 的安全評估方式十分新穎:利用 LLM 的理解和角色扮演能力,讓其成為 plugin 的安全審查員。根據推特上研究 prompt injection 和 hacking 的用戶 rez0 破解得到的信息,給 AI 審核員的信息主要分為三個板塊:指令、事實和政策。
指令部分主要是對 AI 角色的定義:扮演一個在 OpenAI 工作的產品安全工程師,分析一個包含兩個文件的第三方 plugin 是否符合要求(包含了 6個基本的安全問題,如是否獲取個人信息,是否有參與不正當活動的能力等),并基于以上問題為插件的安全程度和適合年齡段進行打分。
而事實和政策部分,則為 AI 審查員的決策提供了依據,政策部分明確了政治、色情的明令禁止的內容;事實部分明確了風險等級劃分:
1. 低風險插件只使用公開數據,不涉及任何個人信息;
2. 中風險插件包含了個人或企業與第三方的交互;
3. 高風險插件使用了高風險數據(金融數據、醫療數據、其他用戶隱私敏感信息),或可能有欺詐行為的風險。
Plugin 未來會走向更復雜的系統
當下的 Plugin 還有諸多不成熟的方面:
1. 模型能同時調用的 plugin 數量很有限:
目前的 plugin 只支持開啟三個 plugin,ChatGPT 在 context window 中讀入這幾個的說明文件。由于 32k 的 input context 限制,5-10 個 plugin 的描述可能就是短時間內模型能讀入的上限了。
2. 目前接入 plugin 的 api 設計方式大多還比較傳統:
ChatGPT 收到 prompt 之后,將其根據 description 加工理解寫好給傳統 api 的輸入。這個優點是開發者可以很高效地把之前開發的 api 復用上,缺點是對開發者而言自由度不夠高。
因此未來的 api 形式會有變化,輸入數據不再是傳輸處理后的結構化數據,而是直接把 prompt 傳給開發者,開發者將對 prompt 的理解和使用寫進 api 中。
3. 當前給模型的描述文檔,尚需要不斷地根據競品情況和模型的理解情況進行調整:
例如,當一個垂直領域中加入一個新的競爭者時,如果競爭者有著更細粒度、更垂直的專注方向,大模型會將其專注方向的所有機會都交給競爭者。
針對以上提到的這些問題,需要一個更復雜的插件召回 plugin retrieval 系統來進行。這個系統可能包含有幾層:
? Plugin Store:提供了一個統一的文檔規定,來管理數以萬計的 plugin ,經過審核后允許 api 開發者進行注冊,更新和刪除。進入 Plugin Store 的時候,應加入關于這一 plugin 的具體標簽(就像 App Store 中的分類和信息),用于之后的召回和使用;
? Plugin Retriever:負責根據用戶需要的行為,召回推薦最相關的 5-10 個 api。召回過程中,Retriever 將 prompt 的信息與 plugin store 中的標簽和描述進行匹配,找到最相關的 plugin;
? Action Executor:負責調用 api 執行生成的動作代碼,調用 api,返回最終執行結果(這里還有一步潛在的排序,模型選擇 api 的過程類似于推薦系統中的精排)。
四、Plugin 的 App Store 野望
“App Store”不是新鮮事
由于過高的勢能,OpenAI 推出 plugin 被視作 iPhone 推出其 App Store 的時刻。我們認為客觀來看,擁有一個應用和插件生態并不代表一個開放平臺必然走向成功。從 SaaS 巨頭的歷史來看,到達了一定體量的公司都必然選擇建設 ISV 生態,通過“開放平臺 + ISV”避免定制化需求開發,并且通過抽成捕獲價值。能否將這樣一個平臺建設成功是通往千億美元級別平臺的重要試金石。
Snowflake 平臺 Take Rate 數據呈現
在美國的過去十年很少有下一個重量級生態在消費者側被建立 —— Meta 也沒做成微信小程序式的應用分發生態。但是一旦在消費者側做成 App Store 級的生態,意味著:
? 比 SaaS 平臺高 1-2 個數量級的生態價值;
? 比 SaaS 平臺高 2-3 個數量級的生態應用數量;
? 比 SaaS 平臺高一倍的 Take Rate。
一個冷知識是 Apple 的應用商店并不是第一個“App Store”,但這個概念的起源的確是 Steve Jobs:
Salesforce 的創始人 Benioff 2000 年左右對公司發展方向比較困惑,找 Jobs 聊了下,對方給出了 3 個建議:
1. 24 個月內增長 10 倍,不然沒戲;
2. 拿下一個大客戶,比如雅芳;
3. 必須建立一個 App Economy。
Benioff 立馬付諸行動,發現自己的產品形態上更像 Exchange 而不是 Store,最終在 2005 年推出了 AppExchange。Benioff 之前聽 Jobs 建議買了 App Store 商標和 appstore.com URL,在 2008 年送給了 Apple。
從一個框架和五個案例推演 Plugin 生態的勝負手
一個框架:
拋開“App Store”的視角,聚焦到開放平臺之上的插件生態建設,我們認為 Figma 給出了一個最好的框架,來用于分析一個生態的成功潛力:
? 安全性:包括用戶的數據隱私、權限管理以及 ISV 和平臺之間的權限和能力邊界;
? 穩定性:平臺的速度不應該被 plugin 拖慢,平臺的更新不應該影響現有的 plugin,平臺還應該提供在多個設備內統一的 plugin 安裝管理;
? 低門檻開發:平臺定義的框架和語言應該足夠在滿足其他前提下足夠低門檻以讓開發者很快上手貢獻一個強勁的plugin 生態;
? 性能:plugin 本身應該是足夠快和穩定的。
除了這套框架本身的普適性之外,我們還比較吃驚于 ChatGPT 和 Figma 的驚人相似性 —— 他們的 plugin 生態是完全云化、Web 端為主、基于強勁的開放平臺并且嵌入到主產品內的。同時,我們認為這套框架缺乏包含的部分是對于開發者的激勵以及在 plugin 數量膨脹后的分發機制。
五個案例
我們將這套框架用于評估 5 個被視作取得了巨大成功的開放平臺生態上,通過這種多案例研究的方法來得出一些對 ChatGPT plugin 的前景和坑的指導性判斷:
Apple App Store:最成功的 OS 應用商店
安全性:★★★★★
穩定性:★★★★★
低門檻開發:★★
性能:★★★★
激勵:★★★★
分發:★★
除了眾所周知的一些成功之處外,Apple 在激勵、分發、低門檻開發上的經驗教訓對于今天的 OpenAI 非常有參考意義:
Apple 成功在 OS 之上建立起了用戶的賬戶體系和自己端到端建設的全球支付網絡 —— Apple 在 2008 年推出 App Store 時只支持終生買斷制付費,在 2009 年引入了 In App Purchase,2010 年引入了 In App Marketplace,給了開發者完整的激勵能力。而 OpenAI 在賬戶體系及支付的建設還非常早期,不過跟 Stripe 的戰略合作可能是一個好兆頭;
App Store 在十幾年發展后表現出了明顯的分發問題,馬太效應問題明顯,大規模的 App 難以被分發和充分匹配。在經歷過個性化推薦的 Genius、LBS 分發的 Near Me 和激勵發現的 Explore 之后,Apple 最終沒有發現更智能的匹配邏輯,回歸到了保留至今天的 Curation 和 Editorial 風格。OpenAI 對于 plugin 的分發可能有新的破局之道,用更智能和非用戶主動選取的方式可以承載更大量級的匹配;
App 的開發門檻相當高,不過 Apple 從 2010 年 iPad 發布開始,會提前給開發者留出時間,讓他們根據新設備和 OS 的特性開發應用。這樣當用戶購買時,他們會現在有豐富的新應用可供選擇。ChatGPT 在 GPT-4 和 plugin 發布上已經是這種風格了,但是對于雙邊怎么放量顯然還缺少經驗。
Salesforce AppExchange:在平臺之上助力銷售
安全性:★★★★
穩定性:★★★★
低門檻開發:★★★
性能:★★★★
激勵:★★★★
分發:★★★
AppExchange 是一個被許多人忽視的成功,里面包含了很多基本功建設,非常值得觀察 OpenAI 后續能不能繼續圍繞這些方面優化用戶體驗:Salesforce 給開發者的前端框架從自己的 design system 演化為了 Lightning Web Components,后端則從基本的 SDK、api 和 Metadata 框架開始,發展出事件驅動的 Pub Sub api 架構,最后外部集成始于 VS Code 等 IDE 集成的優化,發展到 Salesforce Flow 完善的集成方案。
AppExchange 上起來的應用大部分在早期關注 SME 和 Mid-Market。如果要搞大客戶,應用可以自己錨定 3-5 個名字,然后找 Salesforce 的銷售渠道幫忙介紹,隨后開啟獨立的銷售流程。如果 OpenAI 未來需要打造草根崛起的 showcase,這會是個還不錯的范式。
Chrome Extensions:一度被忽視的生態
安全性:★★★★
穩定性:★★
低門檻開發:★★★★
性能:★★★
激勵:★★★
分發:★★
大部分的中國創業者和投資人相當沉迷于“移動互聯網”,反而一度忽視了 Chrome Extensions 上長出的機會,除了我們寫過的 Grammarly 和 Loom 外,第一個驗證了 Chrome 生態的巨大成功是 Honey。這個電商優惠券聚合插件以 40 億美元現金賣給了 PayPal。
Chrome 的生態可以引發對 OpenAI 的一點思考:不同于 App Store 在手機上的地位,Extension 一直僅僅被視作 Web 上的多個渠道之一,和官網、App、社交媒體賬號并行,直到 19 年之后才有越來越多的公司將它作為主要的獲客渠道。如果讓 ChatGPT plugin 的心智成為 KAYAK、Instacart、Expedia 的“獲客副陣地”,它可能會陷入類似的尷尬處境。不過根據開發者的反饋,雖然在發布時引入了大量合作伙伴,實際運行的 plugin 生態更偏向新的、獨立開發的、草根創業的 plugins。
Figma Community:社區帶來差異化
安全性:★★★★
穩定性:★★★★★
低門檻開發:★★★★★
性能:★★★★★
激勵:★★
分發:★★
Figma 通過技術手段很好地完成了安全性、穩定性和性能的平衡,同時揭示了“低門檻”對于雙邊的重要性:Adobe XD 和 Sketch 都擁有歷史更悠久的插件生態,但是用戶往往需要在社區之外發現并下載安裝,而開發者則需要通過類似 C 等語言編寫其插件,而 Figma 則提供了設計師更熟悉的 Typescript 等語言在框架內進行開發,并且打造了跟主產品無縫的體驗。
VSCode Extensions:生態超越內部優化
安全性:★★★
穩定性:★★★★★
低門檻開發:★★★★
性能:★★★★★
激勵:★
分發:★★
VSCode Extension Store 也是個好的案例,用出色的插件生態(各種 Python 插件/自動補全) 在開發體驗上超越了像 IDEA IntelliJ、Pycharm 那樣由經營者內部優化的產品。在 VSCode 的設計中,他們把 IDE 涉及得可擴展性極強,能夠讓開發者很輕松地為自己開發設計好用的插件,并把插件開放給社區一起使用和優化。
回顧 ChatGPT Plugin
五、Plugin 干掉 LangChain?
緊隨“App Store”論調之后的一類觀點是 ChatGPT plugin 抹殺掉了 LangChain、Fixie AI 甚至是 Adept 的價值主張,這是相當程度上高估了 plugin 的說法。
僅僅看 plugin 這一個戰略,它對 LangChain 目前的直接影響:
1. 商業化方面可能會受到一定擠壓,因為順著這個開源項目本身的話,LangChain 幾乎唯一的商業化方向是做 prebuilt hosted services;
2. LangChain 跟 OpenAI 完全不是競爭關系:
這個開源項目在 Plugin 推出 2 天后就持續了在 LangChain 抽象下的 Plugin 實現;
將 Chain 和 Agent 跟 LangChain VectorStore 和 QA 邏輯做了解耦,從而更好地支持未來類似 OpenAI Retrieval 類似的 LangChain 以外的 retriever。
從開發者反饋來看,也有相當多不同的聲音:
沒有之前費勁學習過 LangChain 抽象、希望實現模型間可組合性的獨立開發者構建 plugin 的方式基本是通過 Replicate 來方便地調用其他開源模型能力并通過 Replit 托管這個 plugin。
拋開 plugin,OpenAI 在 6 月最新推出的函數調用對于 LangChain 和 Fixie 的影響倒更大一些。
六、Plugin 的路線圖與連鎖反應
從增量的視角看,按照有短期到長期來排序,我們思考了 ChatGPT 能帶來的一些變化:
1. 微軟在 AI 的生態進一步增強
OpenAI 缺審核,缺產品經理,缺運營這個生態的專家,缺更好的、比聊天界面搭配小組件更廣泛的 UI。這些微軟都有 —— 大量可以投入的人員,廣泛可供 plugin 嵌入并發揮作用的一系列產品(消費者端的 Bing Chat 和 Windows 11 Copilot,企業端的 Microsoft 365 Copilot 和 Dynamis 365 Copilot 等)。
微軟共享 ChatGPT plugin 已有的上百個 plugin 將極大促進它自己生態的冷啟動,以讓客戶構造更多圍繞內部私有數據的 plugin。微軟圍繞這個敘事布局了完整的產品和服務:Azure AI 可以提供在企業私有數據和云上運行和測試 plugin 的能力,而 VSCode 及 Github 則可以被用于幫助企業更好地構建新 plugin。
2. 針對模型調用的調用優化和新的 api 生態
盡管真的像 SEO 或者 ASO(應用商店優化)一樣的廣告生態還非常遠,ChatGPT plugin 的一些玩法已經出現了針對模型進行優化的雛形 —— 激烈的競爭發生在“Description for Model”中,那些描述自己為“寵物電商”的 plugin 可以獲取精準匹配,這些流量不會被分配給擁有更粗粒度描述的 Shopify plugin,而更精細的“專為美國用戶打造的寵物電商”則可以搶走美國的相關流量,優化這個 Description 已經成為 plugin 開發者之間非常有趣的角逐。
除了在 JSON file 上下功夫,專門為 ChatGPT 優化自己的 api 是另一個路徑。OpenAI 在 6 月新推出的 Chat Completions api 的 Function call 功能可以幫助開發者實現“無代碼”的體驗,原來傳統的 api 有很大的為模型重構的空間。
3. 多模型之間的可組合性創造更多用例
類似我們在 05 末尾所展示的 plugin 例子,ChatGPT plugin 為 LLM 與 LLM 之間、LLM 與外部知識和 api 之間、LLM 與不同其他模型之間提供了一個用戶可以輕松使用的 UI。發揮類似的可組合性創意能夠創造出來許多在 LLM 與 Diffusion Model 不存在時難以出現的工作流和產品。
4. plugin 需求倒逼 ChatGPT 產品形態演進
這一點是顯而易見的 —— 如果 OpenAI 對于 ChatGPT 成為一個在消費者側經久不衰的偉大產品仍然抱有愿景,并且搭建了一支合適的團隊來實現這一點。目前來看,這非??赡艹蔀楝F實,因為 OpenAI 剛剛招募了來自 Facebook、Uber 和 Airtable 的產品老兵 Peter Deng 擔任 VP of Consumer Product。
5. 類 Chromebook 的硬件機會出現
外界對于 OpenAI 進軍硬件有非常高的預期。Google 圍繞著 Chrome 的策略算是硬件跟軟件生態配合得比較好的例子,Chrome Extension 在 Education 這個類別非常占據了統治級地位,誕生了 Grammarly 等公司,重要的原因是有 Chromebook 這個硬件讓 Extension 生態被分發到了大量的師生用戶。即使沒有帶來硬件交互上的爆炸性創新,能夠通過硬件建立一個獨特的用戶分發渠道也可以幫助到整個 ChatGPT plugin 生態。
6. 模型內外部數據促進 AI Agent 的出現和演進
從開放平臺的視角思考 plugin 的意義會得出比較有趣的結論,它是 OpenAI 對外開放的一個重要數據接口,讓第三方數據和用戶 Query 等數據能夠互動起來,而微軟與 Azure 似乎致力于促進更多的企業私有數據開始與模型互動,這會加速許多人已經拉滿了預期的 AI 助理的誕生。
本文來自微信公眾號:海外獨角獸 (ID:unicornobserver),作者:Cage、程天一,編輯:penny
標簽: