大模型上下文協(xié)議與Spring開發(fā)集成篇——mcp-spring-webmvc原理
“腦子”的問題目前已經(jīng)有了成熟的解決方案來繞開 token 數(shù)量的限制。通常的方法借鑒了 Map Reduce 的思想，涉及到給文檔切片、使用 Embedding 引擎、向量數(shù)據(jù)庫和語義搜索（我們?cè)?02 中詳細(xì)介紹了這個(gè)過程）。
關(guān)于“手臂”的探索也早就有很多，OpenAI 的 WebGPT 給模型注入了使用網(wǎng)頁信息的能力，Adept 訓(xùn)練的 ACT-1 則能自己去網(wǎng)站和使用 Excel、Salesforce 等軟件，PaLM 的 SayCan 和 PaLM-E 嘗試讓 LLM 和機(jī)器人結(jié)合，Meta 的 Toolformer 探索讓 LLM 自行調(diào)用 API，普林斯頓的 Shunyu Yao 做出的 ReAct 工作通過結(jié)合思維鏈 prompting 和這種“手臂”的理念讓 LLM 能夠搜索和使用維基百科的信息……
有了這些工作，在開源模型或者 API 之上，開發(fā)者們終于可以做有相對(duì)復(fù)雜步驟和業(yè)務(wù)邏輯的 AI 應(yīng)用。而 LangChain 是一個(gè)開源的 Python 庫（后續(xù)又推出了 Typescript 版本），封裝好了大量的相關(guān)邏輯和代碼實(shí)現(xiàn)，開發(fā)者們可以直接調(diào)用，大大加速了構(gòu)建一個(gè)應(yīng)用的速度。
如果沒有 LangChain，這些探索可能首先將被局限在 Adept、Cohere 等有充足產(chǎn)研資源的公司身上，或僅僅停留在論文層面。然后隨著時(shí)間推移，開發(fā)者需要悶頭碼個(gè)幾周來復(fù)現(xiàn)這些邏輯。但是有了 LangChain，做一個(gè)基于公司內(nèi)部文檔的問答機(jī)器人通常只需要兩天，而直接 fork 別人基于 LangChain 的代碼構(gòu)建個(gè)人的 Notion 問答機(jī)器人則只需要幾個(gè)小時(shí)。
我自己知道的第一個(gè)使用 Map Reduce 思想的應(yīng)用是 Pete Hunt 的 summarize.tech，一個(gè)基于 GPT-3 的 YouTube 視頻總結(jié)器。Pete 在去年 9 月興沖沖地在 Twitter 上表示自己找到了讓 GPT-3 調(diào)用成本下降 80% 的方法 —— 不是一股腦將 YouTube 視頻的文稿做總結(jié)，而是先將它分成很多的文本塊（chunk），對(duì)每個(gè)塊分別總結(jié)，最后給用戶交付的是“摘要的摘要”，過程中消耗的 token 數(shù)能節(jié)省很多。
事實(shí)上，這不光能讓成本降低，還可以解決單個(gè) Prompt 中 token 數(shù)量限制的問題。隨著 12 月 OpenAI 新的 Embedding 引擎推出和 ChatGPT 讓更多 AI 應(yīng)用開發(fā)者入場(chǎng)，這種做法目前已經(jīng)成為解決 Context 問題的絕對(duì)主流做法。
下面我們以一個(gè) 300 頁的書的問答機(jī)器人為例，給讀者展示下 LangChain 如何封裝這個(gè)過程（這個(gè)例子來自 YouTube 博主 Data Independent 的 LangChain 101 系列視頻，如果你想迅速上手 LangChain，強(qiáng)烈推薦觀看）：
1. 哪怕是 GPT 的 32k token 限制，300 頁的書也絕對(duì)超過了，因此我們需要引入上文這種 Map Reduce 的做法；
2. LangChain 提供了許多 PDF loader 來幫助上傳 PDF，然后也提供許多類型的 splitter 讓你可以將長(zhǎng)文本切成數(shù)百個(gè)文本塊，并盡量避免這么切可能導(dǎo)致的語義缺失；
3. 有了文本塊之后，你可以調(diào)用 OpenAI 的 Embedding 引擎將它們分別變成 Embeddings，即一些大的向量；
4. 你可以在本地存儲(chǔ)這些向量或者使用 Pinecone 這樣的云向量數(shù)據(jù)庫存儲(chǔ)它們；
5. 調(diào)用 LangChain 的 QA Chain 就可以進(jìn)行問答了，這背后發(fā)生的是 —— 輸入的問題也被 Embedding 引擎變成向量，然后使用 Pincone 的向量搜索引擎找到語義最接近的一些 Embedding，將它們?cè)倨唇釉谝黄鹱鳛榇鸢阜祷亍?/p>
LangChain 在過程中提供了完整的集成，從 OpenAI 的 LLM 本身、Embedding 引擎到 Pinecone 數(shù)據(jù)庫，并且將整體的交互邏輯進(jìn)行了封裝。如果你想用別人基于 LangChain 的代碼 fork 這個(gè) PDF 問答機(jī)器人，基本只需要換一下 OpenAI API key、Pincone API key 和用的這份 PDF。
LangChain 身上有許多標(biāo)簽：開源的 Python 和 Typescript 庫、第一個(gè)被廣泛采用的 LLM 開發(fā)框架、Model as a Service 設(shè)想的中間件、AI 應(yīng)用層的基礎(chǔ)設(shè)施……?感興趣上手使用 LangChain 的讀者可以參考下圖觀遠(yuǎn)數(shù)據(jù)的這個(gè)講解視頻，或是去 LangChain 的文檔中心和 Github 逛逛。
Source：《微軟 365 Copilot 是如何實(shí)現(xiàn)的？揭秘 LLM 如何生成指令》- Bilibili
我在這一部分將不再羅列 LangChain 本身的一系列功能，而是詳細(xì)講講我認(rèn)為 LangChain 最重要的 3 個(gè)身份 —— 讓 LLM 擁有上下文和行動(dòng)能力的第一選擇、所有 LLM Ops 工具的粘合劑/螺栓、一個(gè)快速崛起的開源社區(qū)。
目前基于 LangChain 開發(fā)的第一用例是建立使用私有數(shù)據(jù)的問答機(jī)器人，而大多數(shù)開發(fā)者想到要導(dǎo)入私有數(shù)據(jù)，第一選擇就是基于 LangChain 來做。可以說 LangChain 是目前將上下文信息注入 LLM 的重要基礎(chǔ)設(shè)施。Harrison 在去年 11 月為 LangChain 總結(jié)的 4 大價(jià)值主張支柱也都圍繞這一點(diǎn)，體現(xiàn)出了很優(yōu)美的模塊化和可組合性特點(diǎn)：
LLM 和 Prompts
如果是一個(gè)簡(jiǎn)單的應(yīng)用，比如寫詩機(jī)器人，或者有 token 數(shù)量限制的總結(jié)器，開發(fā)者完全可以只依賴 Prompt。此外，這也是更復(fù)雜的 Chain 和 Agent 的基礎(chǔ)。LangChain 在這一層讓切換底層使用的 LLM、管理 Prompt、優(yōu)化 Prompt 變得非常容易。
此處最基礎(chǔ)的能力是 Prompt Template。一個(gè) Prompt 通常由 Instructions、Context、Input Data（比如輸入的問題）和 Output Indicator（通常是對(duì)輸出數(shù)據(jù)格式的約定）。使用 LangChain 的 Prompt Template 很好地定義各個(gè)部分，同時(shí)將 Input Data 留作動(dòng)態(tài)輸入項(xiàng)。
圍繞 Prompt，LangChain 還有很多非常有意思的小功能，比如 0.0.9 版本上的兩個(gè)能力：Dyanamic Prompts 可以檢查 Prompt 的長(zhǎng)度，然后調(diào)整 few-shots 給出的示例數(shù)量，另一個(gè) Example Generation 可以檢查 Prompt 里 token 數(shù)量還有剩余的話就再多生成些示例。
Chain
當(dāng)一個(gè)應(yīng)用稍微復(fù)雜點(diǎn)，單純依賴 Prompting 已經(jīng)不夠了，這時(shí)候需要將 LLM 與其他信息源或者 LLM 給連接起來，比如調(diào)用搜索 API 或者是外部的數(shù)據(jù)庫等。LangChain 在這一層提供了與大量常用工具的集成（比如上文的 Pincone）、常見的端到端的 Chain。
今天 LangChain 封裝的各種 Chain 已經(jīng)非常強(qiáng)勁，一開始 300 頁 PDF 的案例中用到的是它的 QA Chain，我再舉一些足夠簡(jiǎn)單、易于理解的 Chain 作為例子：
它的第一個(gè) Chain 可以讓完全沒有技術(shù)背景的讀者也對(duì) Chain 有個(gè)概念 —— 這個(gè) Chain 叫做 Self Ask with Search，實(shí)現(xiàn)了 OpenAI API 和 SerpApi（Google 搜索 API）的聯(lián)動(dòng)，讓 LLM 一步步問出了美國(guó)網(wǎng)球公開賽冠軍的故鄉(xiāng)。
還有一個(gè)很直觀的 Chain 是 API chain，可以讓 LLM 查詢 API 并以自然語言回答問題，比如下面這個(gè)示例中 LLM 使用了 Open-Mateo（一個(gè)開源的天氣查詢 API）來獲取舊金山當(dāng)天的降雨量：
Agent
Agent 封裝的邏輯和賦予 LLM 的“使命”比 Chain 要更復(fù)雜。在 Chain 里，數(shù)據(jù)的來源和流動(dòng)方式相對(duì)固定。而在Agent 里，LLM 可以自己決定采用什么樣的行動(dòng)、使用哪些工具，這些工具可以是搜索引擎、各類數(shù)據(jù)庫、任意的輸入或輸出的字符串，甚至是另一個(gè) LLM、Chain 和 Agent。
Harrison 將 Agent 的概念引入 LangChain 是受到前文提到的 ReAct 和 AI21 Labs 的 MRKL（Modular Resaoning, Knowledge, and Language 模塊化推理、知識(shí)和語言）系統(tǒng)的啟發(fā)。作為 Agent 的 LLM 深度體現(xiàn)了思維鏈的能力，充當(dāng)了交通指揮員或者路由者的角色。
重新回歸 OpenAI 的 Anrej Karpathy 在 Twitter 上經(jīng)常說 LLM 會(huì)成為編排資源的認(rèn)知引擎，LangChain 的 Agent 走得其實(shí)就是這個(gè)方向。所以 Agent 究竟能干什么呢？下面是我最喜歡的一個(gè)例子。
眾所周知，ChatGPT 能聽懂你的幾乎所有問題，但是老胡編亂造。另外有一個(gè)叫 Wolfram Alpha 的科學(xué)搜索引擎，擁有天文地理的各類知識(shí)和事實(shí)，只要能聽懂你提問就絕不會(huì)出錯(cuò)，可惜之前只能用官方給的語法搜索，非常難用。所以它的創(chuàng)始人 Wolfram 老師一直在鼓吹 ChatGPT 與 Wolfram Alpha 結(jié)合的威力。
23 年 1 月 11 日，LangChain 貢獻(xiàn)者 Nicolas 完成了 ChatGPT 和 Wolfram Alpha 的集成。Agent 可以像下圖一樣運(yùn)行，自行決定是否需要工具和 Wolfram Alpha，在回答“從芝加哥到東京的距離”時(shí)選擇了調(diào)用它，在回答“Wolfram 是否比 GPT-3 好”時(shí)選擇不調(diào)用它，自行回答。
Memory
LangChain 在上述的 3 層都做得很好，但是在 Memory 上一直相對(duì)薄弱，Harrison 自己不懂，一直由非全職的貢獻(xiàn)者 Sam Whitmore 貢獻(xiàn)相關(guān)代碼，他也承認(rèn) LangChain 在這塊兒有些技術(shù)債。
對(duì)于不了解 Memory 是什么的讀者，你在 ChatGPT 每個(gè)聊天 session 都會(huì)出現(xiàn)在入口的左側(cè)，OpenAI 會(huì)貼心地為你生成小標(biāo)題，在每個(gè) session 的問答里 ChatGPT 都能記住這個(gè)對(duì)話的上文（不過也是因?yàn)槊看握?qǐng)求都會(huì)把之前的問答 token 都傳給 OpenAI），但是新的對(duì)話 session 中的 ChatGPT 一定不記得之前 session 中的信息。LangChain 中的 Chain 在前幾個(gè)月一直也都是這種無狀態(tài)的，但是通常開發(fā) App 時(shí)開發(fā)者希望 LLM 能記住之前的交互。
在前 ChatGPT 時(shí)代，LangChain 不久還是實(shí)現(xiàn)了 Memory 的概念，在不同的 Query 間傳遞上下文，實(shí)現(xiàn)的方法跟開始的總結(jié) 300 頁 PDF 類似：
? 總體而言的方法是記錄之前的對(duì)話內(nèi)容，將其放到 Prompt 的 Context 里；
? 記錄有很多的 tricks，比如直接傳遞上下文，或者對(duì)之前的對(duì)話內(nèi)容進(jìn)行總結(jié)，然后將總結(jié)放 Prompt 里。
微博博主寶玉 xp 畫過一個(gè)系統(tǒng)交互圖，如果不使用被封裝好的庫，自己手寫的話實(shí)際上這套邏輯也很復(fù)雜。
在 Scale AI 今年的 Hackthon 決賽上，Sam 又為 LangChain 做了 Entity Memory 的能力，可以為 LLM 和用戶聊天時(shí) Entity 提供長(zhǎng)期記憶上下文的能力：
在 ChatGPT 發(fā)布后，LangChain 又優(yōu)化了 Memory 模塊，允許返回 List[ChatMessage]，將邏輯單元拆分為了更小的組件，更符合模塊化的思想。
模塊化和可組合性是 LangChain 的關(guān)鍵理念，但它還有一個(gè)理念和我們介紹過的 Universal API 公司很像。
其實(shí)站在投資者的視角看，LangChain 的壁壘比較薄。有人問過 Harrison：為什么開發(fā)者要用 LangChain 而不是直接使用 OpenAI 或者 Hugging Face 上的模型？LangChain 作為一個(gè)開源庫仍然主要依賴于其他的開源庫，它的長(zhǎng)期目標(biāo)是什么？Harrison 的回答是：
Hugging Face、OpenAI、Cohere 可以提供底座模型和 API，但是在產(chǎn)品中集成和使用它們?nèi)匀恍枰罅康墓ぷ鳎L(zhǎng)期目標(biāo)是幫助人們更容易地構(gòu)建 LLM 支持的應(yīng)用。
從這個(gè)視角看，LangChain 更像“膠水”和“螺栓”。它的價(jià)值在于：
1. 全過程一站式的集成，從非結(jié)構(gòu)化數(shù)據(jù)的預(yù)處理到不同模型結(jié)果的評(píng)估，開發(fā)者所需要的工具和庫 LangChain 基本都有現(xiàn)成的集成。
2. LangChain 作為 Universal Layer 在 LLM 身上包了一層，讓用戶可以更自由地在多個(gè) LLM、Embedding 引擎等之間切換，以避免單點(diǎn)風(fēng)險(xiǎn)和降低成本。
這里的邏輯和 Universal API 很像 —— 每個(gè) LLM 提供者的 API 數(shù)據(jù)結(jié)構(gòu)不同，但是 LangChain 包了一層后做了遍 Data Normalization。從想象力的角度看，LangChain 有一定的編排價(jià)值，如果 Model as a Service 和多模型是未來，那么 LangChain 的價(jià)值會(huì)比想象中厚一些。
舉兩個(gè)例子：
去年 OpenAI 的 API 還很貴的時(shí)候，一些數(shù)據(jù)加載器將文本塊變成向量的方式是調(diào)用 OpenAI 的 Davinci Embedding，Harrison 覺得 LangChain 可以做到先用 Hugging Face 或者 Cohere 上便宜的模型做一道，然后再傳給 Davinci Embedding，這樣可以降低不少成本。
還有今年以來，ChatGPT 有時(shí)候會(huì)崩，這也引發(fā)了應(yīng)用開發(fā)者們的擔(dān)憂。Will Brenton 覺得出于這種理由用 LangChain 就很值得，可以用幾行代碼實(shí)現(xiàn)在多個(gè) LLM 之間切換的邏輯，一個(gè) LLM 如果服務(wù)掛掉了就自動(dòng)試下一個(gè)。
使用 LangChain 對(duì)比多個(gè)模型的輸出
LangChain 是目前 LLM 領(lǐng)域最熱門的開源項(xiàng)目之一，從下面可以看出今年以來的曲線和絕對(duì) Star 數(shù)跟最熱門的開源模型 LLama 相比也不遑多讓，發(fā)布不到 5 個(gè)月已經(jīng)擁有了超過 1 萬個(gè) Github Star。
人多力量大，我們?cè)谏衔慕榻B的集成大多數(shù)也都是社區(qū)貢獻(xiàn)的，目前 LangChain 的全職團(tuán)隊(duì)只有 2-3 個(gè)人：
? 發(fā)起人是 Harrison Chase，他 17 年從哈佛大學(xué)畢業(yè)，分別在 Kensho（一家金融自動(dòng)化公司，做金融分析決策與 NLP 的結(jié)合）和 Robust Intelligence（AI 模型部署的安全公司）做機(jī)器學(xué)習(xí)工程師，在 2022 年 9 月 的 Homebrew AI Club 聚會(huì)上聽到 Sam Whitmore 構(gòu)建 AI 應(yīng)用的過程和痛點(diǎn)后，他開始做 LangChain；
? 第一位全職加入 Harrison 的 LangChain 創(chuàng)業(yè)之旅的人似乎是 Ankush Gola，他從普林斯頓畢業(yè)后分別在 Facebook、Robust Intelligence 和 Unfold 做軟件開發(fā)，可以彌補(bǔ) Harrison 在軟件工程方面經(jīng)驗(yàn)的缺失。Harrison 搞不定 LangChain 的異步支持問題，Ankush 加入后迅速彌補(bǔ)了這一點(diǎn)，讓 LangChain 能夠使用 asyncio 庫。
開源是擴(kuò)大影響力和話語權(quán)的最好手段，LangChain 在 ChatGPT API 和 GPT-4 問世的當(dāng)天都迅速發(fā)布了集成，基于 LangChain 構(gòu)建的應(yīng)用想轉(zhuǎn)用 GPT-4 只需要換下 API key 和模型名字就行了，顯然 LangChain 是 OpenAI 的重點(diǎn)合作對(duì)象之一。
除了 OpenAI 的這些更新，Zapier 推出的 Natural Language Actions API 也是跟 LangChain 進(jìn)行了深度合作，Zapier NLA 對(duì)其 2 萬多個(gè)工具的操作實(shí)現(xiàn)了“自然語音 → API call → LLM-friendly 輸出”，也是基于 LangChain 做的。然后在推出當(dāng)天，LangChain 也官宣了跟 Zapier NLA 的集成，用戶可以先在 Zapier 支持的 App 上設(shè)置好一個(gè) NLA API endpoint，然后就可以在 LangChain 中調(diào)用和組合使用 Zapier。
從這兩個(gè)案例看，LangChain 是大模型能力“B2B2C”的一個(gè)重要中間站。
此外，除了給 LangChain 項(xiàng)目直接做貢獻(xiàn)，還有不少人已經(jīng)在圍繞 LangChain 做生態(tài)項(xiàng)目，下面是我最喜歡的 2 個(gè)：
LangChain 本身是一個(gè)沒有 UI 的庫，但社區(qū)成員 Rodrigo Nader 為它構(gòu)建了一個(gè)開源的 UI，叫做?LangFlow，讓用戶可以通過拖拽就能做出來應(yīng)用原型。
大多數(shù)用戶會(huì)使用 Streamlit 或者 Replit 來部署它們的應(yīng)用，但是已經(jīng)有社區(qū)成員開始為 LangChain 應(yīng)用打造更炫酷的部署方式，比如?Kookaburra，可以讓 LangChain 應(yīng)用非常方便地被部署為短信機(jī)器人。
從投資者視角，我對(duì) LangChain 的擔(dān)憂有兩點(diǎn)：
1. 它是一個(gè)很難被商業(yè)化的開源項(xiàng)目，因?yàn)樗且粋€(gè)“依賴其他開源庫的開源庫”，我所訪談的 LangChain 開發(fā)者也都認(rèn)為自己不會(huì)為它付費(fèi)，如果要構(gòu)建一個(gè)基于 LLM 應(yīng)用的公司，他們會(huì)選擇自己 fork LangChain 再寫一套框架，還能順手把成本和延時(shí)問題做更多優(yōu)化；
2. 和第一點(diǎn)相輔相成的是，目前使用 LangChain 的主流人群是 Hacker 和獨(dú)立開發(fā)者們，而不是 B 輪以后的 Mid-Market 或者大型企業(yè)公司。當(dāng)然，這是目前 AI 應(yīng)用生態(tài)的現(xiàn)狀，獨(dú)立開發(fā)者在數(shù)量上占據(jù)主導(dǎo)。而且當(dāng)前的 LangChain 實(shí)現(xiàn)一些復(fù)雜邏輯需要多個(gè) Chain 的嵌套，并且多次 call LLM API，對(duì)于大規(guī)模調(diào)用的產(chǎn)品可能也確實(shí)成本不經(jīng)濟(jì)也有不穩(wěn)定的情況。但是正因?yàn)榇耍琇angChain 更難進(jìn)行商業(yè)化，特別是在從數(shù)據(jù)準(zhǔn)備到模型部署的全環(huán)節(jié)已經(jīng)非常卷的情況下。
從演進(jìn)的視角看，我對(duì)于 LangChain 這個(gè)庫本身能不能具備服務(wù)中大型公司倒比較有信心 —— 兩個(gè)月前人們還不認(rèn)為 LangChain 是一個(gè)在生產(chǎn)環(huán)境中可靠的東西，一個(gè)月前 LangChain 才剛剛支持自托管模型，讓企業(yè) LLM 用戶可以在 LangChain 中調(diào)用共享遠(yuǎn)程 API，但是它在客戶自己的云賬戶或者本地硬件中運(yùn)行。給 LangChain 時(shí)間，貢獻(xiàn)者們會(huì)讓它高度可用。
市場(chǎng)上普遍對(duì) LangChain 有擔(dān)心，但是我認(rèn)為短期影響不大的兩點(diǎn)是：
1. LLM 本身的變化會(huì)讓 LangChain 庫中的許多部分過時(shí)。這一點(diǎn)我認(rèn)為恰恰是開源項(xiàng)目的優(yōu)勢(shì)，貢獻(xiàn)者可以迅速幫助它過渡到新版本；
比如 ChatGPT API 發(fā)布后，它有了新的交互，這也意味著需要新的抽象，原來的很多 Prompt 不管用了，適用于 GPT-3 的 Prompt Templates 在 ChatGPT 下效果不好，所以 LangChain 又新增了 PromptSelectors 功能。此外 ChatGPT 在遵循特定的輸出數(shù)據(jù)格式上表現(xiàn)得不好，有很多“無法解析 LLM 輸出”的報(bào)錯(cuò)，LangChain 很快上了一個(gè) chat-zero-shot-react-description Agent 來嚴(yán)格約束輸出的數(shù)據(jù)格式，還大受好評(píng)。使用 LangChain 可能幫助很多公司避免過多的 Prompt Engineering 開發(fā)資源浪費(fèi)。
2. 隨著模型支持的 token 數(shù)量變多，LangChain 的核心用例 —— 用分塊、Embedding、語義搜索、再拼回來 —— 可能會(huì)直接消失。這在短期內(nèi)不是個(gè)問題，因?yàn)槟呐?GPT-4 的 3.2 萬 token 也仍然不是很夠用。同時(shí)，這種 Map Reduce 的方式還能省錢。
在理性的質(zhì)疑中，我比較認(rèn)可的是 Notion AI 的 Linus 的觀點(diǎn)，他在 Twitter 上表示當(dāng)前所有類似 LangChain 的 Prompt Ops 工具都是為 side-project 級(jí)別的用戶服務(wù)的，很難正經(jīng)接受它們，主要有 3 點(diǎn)原因：
1. 這些工具都假設(shè)一個(gè)服務(wù)是對(duì) LLM 的調(diào)用，然后在此之上把業(yè)務(wù)邏輯耦合進(jìn)去。而不是反過來，在已有業(yè)務(wù)邏輯里插入對(duì) LLM 的調(diào)用，這讓現(xiàn)有的 SaaS 等公司很難使用這些工具；
2. 對(duì)于模型的輸出大家目前都沒有可量化的方式來評(píng)估，Humanloop 已經(jīng)有最好的模型評(píng)估 UI 了，但是也是為了人類反饋對(duì)齊而不是為了應(yīng)用開發(fā)者的性能優(yōu)化和迭代；
3. 這些工具都希望成為生產(chǎn)環(huán)境下工作負(fù)載的關(guān)鍵中間點(diǎn)，但是有延時(shí)和安全性上的很有問題，還不如給用戶交付模型配置和最終 prompt 然后讓用戶自己調(diào)用模型。
一些朋友在 Linus 的觀點(diǎn)下指出： LangChain 不是一個(gè) Prompt Ops 工具，它是一個(gè) LLM 增強(qiáng)工具，通過粘合一系列的模塊（這些模塊本身可能是 Prompt 增強(qiáng)工具）增加了 LLM 可以融入的業(yè)務(wù)邏輯復(fù)雜度。Linus 也認(rèn)同這一點(diǎn)。總體而言，我認(rèn)為這些批評(píng)為 LangChain 指明了方向，它也的確在 3 月?lián)碛辛烁嗪湍Ｐ驮u(píng)估以及性能可觀測(cè)性相關(guān)的集成。
拋開直接面向消費(fèi)者的應(yīng)用不看，LangChain 的核心競(jìng)爭(zhēng)對(duì)手是三類：
? GPT-Index 本身是基于 LangChain 構(gòu)建的，它的用例更集中于 Memory 和將數(shù)據(jù)導(dǎo)入 LLM，用例非常明晰，而 LangChain 的功能更抽象和龐大，用戶需要在其中挑選符合自己用例的進(jìn)行組合；
??Microsoft Semantic Kernel?的整體目標(biāo)和 LangChain 非常接近，Planner 類似我們上文提到的 Agent，但是它針對(duì)的受眾不是獨(dú)立應(yīng)用開發(fā)者，而是那些需要在兼顧原有開發(fā)工作的同時(shí)將 LLM 能力嵌入自家應(yīng)用的工程師們，因此采用了一個(gè)輕量級(jí) SDK 的形式交付，它是 LangChain非常強(qiáng)勁的潛在競(jìng)爭(zhēng)對(duì)手，但是 Microsoft 和 OpenAI 的親密關(guān)系可能讓它在未來無法像 LangChain 一樣靈活支持各類 LLM；
? Dust 和 Scale AI Spellbook 代表著 LLM 應(yīng)用開發(fā)的無代碼和低代碼思路，擁有非常好的 UI/UX，但是大多數(shù)開發(fā)者認(rèn)為自己并不是需要低代碼的工具，而是需要更多的功能和可實(shí)驗(yàn)性。
我們?cè)L談的所有 LangChain 用戶都只使用 LangChain，對(duì)于 GPT-Index 和 Dust 只探索到去它們的 Github 和官網(wǎng)逛逛的程度。有 Twitter 博主專門橫向測(cè)評(píng)了這三個(gè)工具，結(jié)論是：
如果你想構(gòu)建復(fù)雜邏輯并且自己托管后端的應(yīng)用，那就使用 LangChain。Dust 和 Everyprompt 是通過 UI 來定義 Prompt 和創(chuàng)建 LLM 工作圖，LangChain 作為一個(gè) Python 庫提供了更多的靈活性、可控度但更笨重。它的 game changer 是圍繞 Agent 的能力，一個(gè)可以跟外部工具（python interpreter、搜索引擎）交互從而回答問題的 LLM，這是其他工具所不具備的。
不看大廠的話，創(chuàng)業(yè)三杰 LangChain、GPT-Index、Dust 互相有很多羈絆，絕對(duì)不是火并競(jìng)爭(zhēng)的關(guān)系：Dust 比 LangChain 出現(xiàn)得更早，由前 OpenAI 的Stanislas 創(chuàng)建，它的理念和對(duì)可組合性的重視對(duì) Harrison 做 LangChain 有很大的啟發(fā)。而 GPT-Index 的創(chuàng)始人 Jerry Liu 是 Harrison 在 Robust Intelligence 時(shí)的同事，因此兩個(gè)人經(jīng)常交流產(chǎn)品想法，GPT-Index 和 LangChain 互相有非常多的集成。
甚至 GPT-Index 本身也是基于 LangChain 構(gòu)建的，能享受 LangChain 基建升級(jí)的許多好處。比如 LangChain 在 1 月底提供了 tracing 的能力，讓用戶能更好觀測(cè)和 debug 自己的 Chain 和 Agent，GPT-Index 作為基于 LangChain 的包也自動(dòng)獲得了這個(gè)功能。下圖是一個(gè) GPT-Index query 的 tracing 視圖：
LangChain 是一個(gè)開源項(xiàng)目，Harrison Chase 想構(gòu)建的似乎不止于 LangChain。上個(gè)月，The Information 報(bào)道 Benchmark 以數(shù)千萬美元估值投資了 LangChain 數(shù)百萬美元。Harrison 有可能在繼續(xù)擴(kuò)大 LangChain 影響力的同時(shí)做出更產(chǎn)品化的開發(fā)者工具。
從早期投資押注人的角度，Harrison 是一個(gè)很好的創(chuàng)業(yè)者和項(xiàng)目經(jīng)理，盡管還沒有直接交流過，但我比較喜歡他的幾個(gè)特質(zhì)：
在 22 年下半年，市場(chǎng)逐漸開始意識(shí)到 LLM 的下一步是“Action”，也就是在外部世界能夠采取行動(dòng)。標(biāo)志性的事件之一是 Cohere 在 9 月推出了基于 LLM 的 Discord 搜索機(jī)器人。
Harrison 這時(shí)候已經(jīng)花了不少時(shí)間思考下一步所需要的工具，并且留意到了 Dust 的嘗試，隨后就開始構(gòu)建 LangChain 這個(gè) Python 包，并且在 10 月就立馬推出。在此期間，碰到有人做應(yīng)用，Harrison 經(jīng)常會(huì)問問對(duì)方“什么工具會(huì)幫你提效”、“還缺什么工具”。
回過頭看，LangChain 能繼續(xù)火下去的前提是，目前 AI 應(yīng)用已經(jīng)從模型技術(shù)能力的 pk 到了產(chǎn)品能力的 pk，Harrison 自己的總結(jié)是“能有好的產(chǎn)品創(chuàng)意的人 > 能創(chuàng)建更好模型的人”，而 LangChain 就希望解鎖這些人的創(chuàng)意和效率。
從后視鏡看，LangChain 的 Chain 和 Agent 邏輯似乎是個(gè)無腦的選擇。但是 Harrison 當(dāng)時(shí)選擇構(gòu)建這一點(diǎn)是基于對(duì) Action 驅(qū)動(dòng)和對(duì) LLM 能力的判斷，受到了 ReAct 這篇論文不少影響。
他對(duì)于 token 數(shù)量限制的理解也很敏銳，將 Map Reduce 的實(shí)現(xiàn)提到了 LangChain 比較高的優(yōu)先級(jí)，后面隨著 1 月份各種 AI Hackthon（Hugging Face、Scale AI 等）的舉辦，對(duì)快速使用這個(gè)邏輯的需求激增，并且相關(guān)參賽隊(duì)伍都會(huì)提到自己使用了 LangChain，讓 LangChain 迅速變成了 AI 應(yīng)用開發(fā)者們的第一選擇。
LangChain 開發(fā)者舊金山 Meetup 的盛況
LangChain 上線各類新模型和新集成的速度非常快，Harrison 自己干活快，而且迅速讓 LangChain 的社區(qū)非常有凝聚力 ——?AI 和 LLM 本身是有趣且實(shí)用的，Harrison 推動(dòng)做了 LangChain Hub，旨在為用戶提供一個(gè)易于分享和發(fā)現(xiàn) Prompt Sequence、Chain 和 Agent，又加深了這一點(diǎn)。同時(shí)，Harrison 很善于跟社區(qū)成員交流獲得更多的反饋，在 LangChain Discord 社區(qū)頻繁互動(dòng)，并且建立了一個(gè)專用的 Slack 頻道幫助大家將 LangChain 用于生產(chǎn)環(huán)境。
有一個(gè)小的細(xì)節(jié)是：在 1 月中旬，有用戶反饋 LangChain 的 verbose（根據(jù)內(nèi)容來自的模型或組件來使用突出色號(hào)顯示）挺有用但可以更詳細(xì)，比如每個(gè)查詢到底用了多少 token，這樣在應(yīng)用可能被大規(guī)模使用時(shí)可以更好地追蹤成本。這是個(gè)很細(xì)節(jié)的功能，但是 Harrison 表達(dá)了重視并且在一周之后添加了對(duì) token 的計(jì)算和顯示，并且通過 GPT-Index 統(tǒng)計(jì) token 的具體使用情況。類似的例子我還觀察到了不少，只要是 Harrison 答應(yīng)用戶的需求，一定不久就會(huì)發(fā)布。
文章轉(zhuǎn)自微信公眾號(hào)@海外獨(dú)角獸
對(duì)比大模型API的內(nèi)容創(chuàng)意新穎性、情感共鳴力、商業(yè)轉(zhuǎn)化潛力
一鍵對(duì)比試用API 限時(shí)免費(fèi)
