亚洲精品无码AⅤ片青青在线观看_国产在线播放不卡一区二区三区_无码中文字幕视频一区二区三区_久久夜色精品亚洲av三区_国产综合欧美无毒不卡怡红院

LangChain 很火，有關它的前途命運也有很多爭議，但一個相對肯定的結(jié)論是：LangChain 已經(jīng)成為了 AI 應用開發(fā)的新手村。22 年 11 月初，Hacker News 上“如何入門 AI”的帖子回復中，LangChain 第一次被列進入門套裝：

看 Fast.ai 和 Andrej Karpathy 的 YouTube 頻道。在本地試試跑 Stable Diffusion。用 YOLO 標記你的圖片。用 LangChain，在 Hugging Face 學學如何使用 Transformer 的庫。然后去 Kaggle 吧。

LangChain 由前 Robust Intelligence 的機器學習工程師 Chase Harrison 在 22 年 10 月底推出，是一個封裝了大量 LLM 應用開發(fā)邏輯和工具集成的開源 Python 庫，有成為第一個被廣泛認可的 LLM 應用開發(fā)框架的勢頭。隨著 Harrison 為 LangChain 添加了很多實用的抽象，以及 23 年 1 月眾多 AI Hackathon 決賽項目使用 LangChain，它的 Github Star 迅速破萬，成為 LLM 應用開發(fā)者選擇中間件時想到的第一個名字。

(資料圖片)

從開發(fā)者視角看，LangChain 是個挺友好且優(yōu)美的庫：

?它非常模塊化，還通過 Chain、Agent、Memory 對 LLM 的抽象幫助開發(fā)者提高了構建較復雜邏輯應用的效率；而且每個模塊有很好的可組合性，有點像“為 LLM 提供了本 SOP”，能實現(xiàn) LLM 與其他工具的組合、Chain 與 Chain 的嵌套等邏輯；

?它一站式集成了所有工具，從各種非結(jié)構化數(shù)據(jù)的預處理、不同的 LLM、中間的向量和圖數(shù)據(jù)庫和最后的模型部署，貢獻者都幫 LangChain 跟各種工具完成了迅速、全面的集成。

作為成長期投資者看 LangChain，它本身還太早期，遠沒到成長邏輯。除此之外，我對它在商業(yè)層面未來發(fā)展的核心擔憂在于：

?我們不能直接套用舊時代的中間件視角，隨著 ChatGPT Plug-In 出現(xiàn)和 OpenAI 的更多邊界延伸，LangChain 的價值可能被取代，很快像機器學習歷史上的其他明星庫一樣隱入塵埃；

?LangChain 本身的壁壘也比較薄，是“其他開源庫身上的開源庫”，沒有太多技術壁壘，只是替大家省下來了碼的時間。如果要收費使用，很多開發(fā)者可能會選擇自己把 LangChain 這套東西碼出來；

?目前使用 LangChain 庫的以個人開發(fā)者和極客的 side project 為主，還不是正經(jīng)的企業(yè)級 LLM 集成工具，而稍微有點體量的公司都會選擇 fork LangChain 的源碼或者干脆自己再碼套框架。

從投資人的角度看，LangChain 的創(chuàng)始人 Harrison Chase 想做的不止是 LangChain 這個開源庫而已，我們比較期待他服務 AI 應用開發(fā)者的下一步動作。此外，我在本文使用了盡可能通俗易懂的方式呈現(xiàn)和分析 LangChain 的能力，所以沒有技術背景的讀者也可以放心閱讀本文，也歡迎 LangChain 開發(fā)者填寫反饋征集問卷。

以下為本文目錄，建議結(jié)合要點進行針對性閱讀。

01.構建 AI 應用遠不只是調(diào)用模型 API

一旦在 LLM 領域花了足夠多的時間，在興奮之余你會意識到當前模型本身的兩點局限：

1. 它只有“腦子”沒有“手臂”，無法在外部世界行動，不論是搜索網(wǎng)頁、調(diào)用 API 還是查找數(shù)據(jù)庫，這些能力都無法被 OpenAI 的 API 提供；

2. 甚至它的“腦子”也不完美，OpenAI 的訓練數(shù)據(jù)截止至 2021 年，并且沒有任何企業(yè)和個人的私有數(shù)據(jù)，這讓模型只能根據(jù)自己的“記憶”回答問題，并且經(jīng)常給出與事實相悖的答案。一個解決方法是在 Prompt 中將知識告訴模型，但是這往往受限于 token 數(shù)量，在 GPT-4 之前一般是 4000 個字的限制。

從抽象層面看，我們使用 LLM 時在期待兩種能力（這是個沒那么科學嚴謹?shù)姆诸悾?/p>

1. 一種是使用它的生成能力，這是 GPT-3 和 ChatGPT 剛剛出現(xiàn)時最初被體驗的能力 —— 讓 ChatGPT 寫首詩，你可以接受它的上述不完美；

2. 進入到圍繞模型構建“真正有用”的應用時，我們更多在使用它通過思想和記憶進行推理的能力。而簡單直接地通過 API 調(diào)用模型無法將推理所需的一些事實和知識給到它，即這時候模型總是缺少“Context”（廣義的上下文）。

這就需要為模型注入 Context 并進行一定的 Prompt Engineering。正確的 Prompt 可以激發(fā)出 LLM 的能力，這在 GPT-3.5 以前的時代更為重要。將 Context 注入 LLM 實際上在 Prompt Engineering 的上游，把知識告訴 LLM，Prompt 只是中間橋梁。前 Stitch Fix 的 ML 總監(jiān) John McDonnell 畫的這幅圖很好地展示出了二者的關系：

“腦子”的問題目前已經(jīng)有了成熟的解決方案來繞開 token 數(shù)量的限制。通常的方法借鑒了 Map Reduce 的思想，涉及到給文檔切片、使用 Embedding 引擎、向量數(shù)據(jù)庫和語義搜索（我們在 02 中詳細介紹了這個過程）。

關于“手臂”的探索也早就有很多，OpenAI 的 WebGPT 給模型注入了使用網(wǎng)頁信息的能力，Adept 訓練的 ACT-1 則能自己去網(wǎng)站和使用 Excel、Salesforce 等軟件，PaLM 的 SayCan 和 PaLM-E 嘗試讓 LLM 和機器人結(jié)合，Meta 的 Toolformer 探索讓 LLM 自行調(diào)用 API，普林斯頓的 Shunyu Yao 做出的 ReAct 工作通過結(jié)合思維鏈 prompting 和這種“手臂”的理念讓 LLM 能夠搜索和使用維基百科的信息……

有了這些工作，在開源模型或者 API 之上，開發(fā)者們終于可以做有相對復雜步驟和業(yè)務邏輯的 AI 應用。而 LangChain 是一個開源的 Python 庫（后續(xù)又推出了 Typescript 版本），封裝好了大量的相關邏輯和代碼實現(xiàn)，開發(fā)者們可以直接調(diào)用，大大加速了構建一個應用的速度。

如果沒有 LangChain，這些探索可能首先將被局限在 Adept、Cohere 等有充足產(chǎn)研資源的公司身上，或僅僅停留在論文層面。然后隨著時間推移，開發(fā)者需要悶頭碼個幾周來復現(xiàn)這些邏輯。但是有了 LangChain，做一個基于公司內(nèi)部文檔的問答機器人通常只需要兩天，而直接 fork 別人基于 LangChain 的代碼構建個人的 Notion 問答機器人則只需要幾個小時。

02.案例：為一本 300 頁的書構建問答機器人

我自己知道的第一個使用 Map Reduce 思想的應用是 Pete Hunt 的 summarize.tech，一個基于 GPT-3 的 YouTube 視頻總結(jié)器。Pete 在去年 9 月興沖沖地在 Twitter 上表示自己找到了讓 GPT-3 調(diào)用成本下降 80% 的方法 ——不是一股腦將 YouTube 視頻的文稿做總結(jié)，而是先將它分成很多的文本塊（chunk），對每個塊分別總結(jié)，最后給用戶交付的是“摘要的摘要”，過程中消耗的 token 數(shù)能節(jié)省很多。

事實上，這不光能讓成本降低，還可以解決單個 Prompt 中 token 數(shù)量限制的問題。隨著 12 月 OpenAI 新的 Embedding 引擎推出和 ChatGPT 讓更多 AI 應用開發(fā)者入場，這種做法目前已經(jīng)成為解決 Context 問題的絕對主流做法。

下面我們以一個 300 頁的書的問答機器人為例，給讀者展示下 LangChain 如何封裝這個過程（這個例子來自 YouTube 博主 Data Independent 的 LangChain 101 系列視頻，如果你想迅速上手 LangChain，強烈推薦觀看）：

1. 哪怕是 GPT 的 32k token 限制，300 頁的書也絕對超過了，因此我們需要引入上文這種 Map Reduce 的做法；

2. LangChain 提供了許多 PDF loader 來幫助上傳 PDF，然后也提供許多類型的 splitter 讓你可以將長文本切成數(shù)百個文本塊，并盡量避免這么切可能導致的語義缺失；

3. 有了文本塊之后，你可以調(diào)用 OpenAI 的 Embedding 引擎將它們分別變成 Embeddings，即一些大的向量；

4. 你可以在本地存儲這些向量或者使用 Pinecone 這樣的云向量數(shù)據(jù)庫存儲它們；

5. 調(diào)用 LangChain 的 QA Chain 就可以進行問答了，這背后發(fā)生的是 —— 輸入的問題也被 Embedding 引擎變成向量，然后使用 Pincone 的向量搜索引擎找到語義最接近的一些 Embedding，將它們再拼接在一起作為答案返回。

LangChain 在過程中提供了完整的集成，從 OpenAI 的 LLM 本身、Embedding 引擎到 Pinecone 數(shù)據(jù)庫，并且將整體的交互邏輯進行了封裝。如果你想用別人基于 LangChain 的代碼 fork 這個 PDF 問答機器人，基本只需要換一下 OpenAI API key、Pincone API key 和用的這份 PDF。

03.產(chǎn)品：拼接好 LLM 的大腦和四肢

LangChain 身上有許多標簽：開源的 Python 和 Typescript 庫、第一個被廣泛采用的 LLM 開發(fā)框架、Model as a Service 設想的中間件、AI 應用層的基礎設施......感興趣上手使用 LangChain 的讀者可以參考下圖觀遠數(shù)據(jù)的這個講解視頻，或是去 LangChain 的文檔中心和 Github 逛逛。

Source：《微軟 365 Copilot 是如何實現(xiàn)的？

揭秘 LLM 如何生成指令》- Bilibili

我在這一部分將不再羅列 LangChain 本身的一系列功能，而是詳細講講我認為 LangChain 最重要的 3 個身份 ——讓 LLM 擁有上下文和行動能力的第一選擇、所有 LLM Ops 工具的粘合劑/螺栓、一個快速崛起的開源社區(qū)。

讓 LLM 擁有上下文和行動能力

目前基于 LangChain 開發(fā)的第一用例是建立使用私有數(shù)據(jù)的問答機器人，而大多數(shù)開發(fā)者想到要導入私有數(shù)據(jù)，第一選擇就是基于 LangChain 來做。可以說 LangChain 是目前將上下文信息注入 LLM 的重要基礎設施。Harrison 在去年 11 月為 LangChain 總結(jié)的 4 大價值主張支柱也都圍繞這一點，體現(xiàn)出了很優(yōu)美的模塊化和可組合性特點：

LLM 和 Prompts

如果是一個簡單的應用，比如寫詩機器人，或者有 token 數(shù)量限制的總結(jié)器，開發(fā)者完全可以只依賴 Prompt。此外，這也是更復雜的 Chain 和 Agent 的基礎。LangChain 在這一層讓切換底層使用的 LLM、管理 Prompt、優(yōu)化 Prompt 變得非常容易。

此處最基礎的能力是 Prompt Template。一個 Prompt 通常由 Instructions、Context、Input Data（比如輸入的問題）和 Output Indicator（通常是對輸出數(shù)據(jù)格式的約定）。使用 LangChain 的 Prompt Template 很好地定義各個部分，同時將 Input Data 留作動態(tài)輸入項。

圍繞 Prompt，LangChain 還有很多非常有意思的小功能，比如 0.0.9 版本上的兩個能力：Dyanamic Prompts 可以檢查 Prompt 的長度，然后調(diào)整 few-shots 給出的示例數(shù)量，另一個Example Generation 可以檢查 Prompt 里 token 數(shù)量還有剩余的話就再多生成些示例。

Chain

當一個應用稍微復雜點，單純依賴 Prompting 已經(jīng)不夠了，這時候需要將 LLM 與其他信息源或者 LLM 給連接起來，比如調(diào)用搜索 API 或者是外部的數(shù)據(jù)庫等。LangChain 在這一層提供了與大量常用工具的集成（比如上文的 Pincone）、常見的端到端的 Chain。

今天 LangChain 封裝的各種 Chain 已經(jīng)非常強勁，一開始 300 頁 PDF 的案例中用到的是它的 QA Chain，我再舉一些足夠簡單、易于理解的 Chain 作為例子：

它的第一個 Chain 可以讓完全沒有技術背景的讀者也對 Chain 有個概念 —— 這個 Chain 叫做 Self Ask with Search，實現(xiàn)了 OpenAI API 和 SerpApi（Google 搜索 API）的聯(lián)動，讓 LLM 一步步問出了美國網(wǎng)球公開賽冠軍的故鄉(xiāng)。

還有一個很直觀的 Chain 是 API chain，可以讓 LLM 查詢 API 并以自然語言回答問題，比如下面這個示例中 LLM 使用了 Open-Mateo（一個開源的天氣查詢 API）來獲取舊金山當天的降雨量：

Agent

Agent 封裝的邏輯和賦予 LLM 的“使命”比 Chain 要更復雜。在 Chain 里，數(shù)據(jù)的來源和流動方式相對固定。而在Agent 里，LLM 可以自己決定采用什么樣的行動、使用哪些工具，這些工具可以是搜索引擎、各類數(shù)據(jù)庫、任意的輸入或輸出的字符串，甚至是另一個 LLM、Chain 和 Agent。

Harrison 將 Agent 的概念引入 LangChain 是受到前文提到的 ReAct 和 AI21 Labs 的 MRKL（Modular Resaoning, Knowledge, and Language 模塊化推理、知識和語言）系統(tǒng)的啟發(fā)。作為 Agent 的 LLM 深度體現(xiàn)了思維鏈的能力，充當了交通指揮員或者路由者的角色。

重新回歸 OpenAI 的 Anrej Karpathy 在 Twitter 上經(jīng)常說 LLM 會成為編排資源的認知引擎，LangChain 的 Agent 走得其實就是這個方向。所以 Agent 究竟能干什么呢？下面是我最喜歡的一個例子。

眾所周知，ChatGPT 能聽懂你的幾乎所有問題，但是老胡編亂造。另外有一個叫 Wolfram Alpha 的科學搜索引擎，擁有天文地理的各類知識和事實，只要能聽懂你提問就絕不會出錯，可惜之前只能用官方給的語法搜索，非常難用。所以它的創(chuàng)始人 Wolfram 老師一直在鼓吹 ChatGPT 與 Wolfram Alpha 結(jié)合的威力。

23 年 1 月 11 日，LangChain 貢獻者 Nicolas 完成了 ChatGPT 和 Wolfram Alpha 的集成。Agent 可以像下圖一樣運行，自行決定是否需要工具和 Wolfram Alpha，在回答“從芝加哥到東京的距離”時選擇了調(diào)用它，在回答“Wolfram 是否比 GPT-3 好”時選擇不調(diào)用它，自行回答。

Memory

LangChain 在上述的 3 層都做得很好，但是在 Memory 上一直相對薄弱，Harrison 自己不懂，一直由非全職的貢獻者 Sam Whitmore 貢獻相關代碼，他也承認 LangChain 在這塊兒有些技術債。

對于不了解 Memory 是什么的讀者，你在 ChatGPT 每個聊天 session 都會出現(xiàn)在入口的左側(cè)，OpenAI 會貼心地為你生成小標題，在每個 session 的問答里 ChatGPT 都能記住這個對話的上文（不過也是因為每次請求都會把之前的問答 token 都傳給 OpenAI），但是新的對話 session 中的 ChatGPT 一定不記得之前 session 中的信息。LangChain 中的 Chain 在前幾個月一直也都是這種無狀態(tài)的，但是通常開發(fā) App 時開發(fā)者希望 LLM 能記住之前的交互。

在前 ChatGPT 時代，LangChain 不久還是實現(xiàn)了 Memory 的概念，在不同的 Query 間傳遞上下文，實現(xiàn)的方法跟開始的總結(jié) 300 頁 PDF 類似：

?總體而言的方法是記錄之前的對話內(nèi)容，將其放到 Prompt 的 Context 里；

?記錄有很多的 tricks，比如直接傳遞上下文，或者對之前的對話內(nèi)容進行總結(jié)，然后將總結(jié)放 Prompt 里。

微博博主寶玉 xp 畫過一個系統(tǒng)交互圖，如果不使用被封裝好的庫，自己手寫的話實際上這套邏輯也很復雜。

在 Scale AI 今年的 Hackthon 決賽上，Sam 又為 LangChain 做了 Entity Memory 的能力，可以為 LLM 和用戶聊天時 Entity 提供長期記憶上下文的能力：

在 ChatGPT 發(fā)布后，LangChain 又優(yōu)化了 Memory 模塊，允許返回 List[ChatMessage]，將邏輯單元拆分為了更小的組件，更符合模塊化的思想。

一站式粘合所有工具

模塊化和可組合性是 LangChain 的關鍵理念，但它還有一個理念和我們介紹過的 Universal API 公司很像。

其實站在投資者的視角看，LangChain 的壁壘比較薄。有人問過 Harrison：為什么開發(fā)者要用 LangChain 而不是直接使用 OpenAI 或者 Hugging Face 上的模型？LangChain 作為一個開源庫仍然主要依賴于其他的開源庫，它的長期目標是什么？Harrison 的回答是：

Hugging Face、OpenAI、Cohere 可以提供底座模型和 API，但是在產(chǎn)品中集成和使用它們?nèi)匀恍枰罅康墓ぷ?，長期目標是幫助人們更容易地構建 LLM 支持的應用。

從這個視角看，LangChain 更像“膠水”和“螺栓”。它的價值在于：

1. 全過程一站式的集成，從非結(jié)構化數(shù)據(jù)的預處理到不同模型結(jié)果的評估，開發(fā)者所需要的工具和庫 LangChain 基本都有現(xiàn)成的集成。

2. LangChain 作為 Universal Layer 在 LLM 身上包了一層，讓用戶可以更自由地在多個 LLM、Embedding 引擎等之間切換，以避免單點風險和降低成本。

這里的邏輯和 Universal API 很像 —— 每個 LLM 提供者的 API 數(shù)據(jù)結(jié)構不同，但是 LangChain 包了一層后做了遍 Data Normalization。從想象力的角度看，LangChain 有一定的編排價值，如果 Model as a Service 和多模型是未來，那么 LangChain 的價值會比想象中厚一些。

舉兩個例子：

去年 OpenAI 的 API 還很貴的時候，一些數(shù)據(jù)加載器將文本塊變成向量的方式是調(diào)用 OpenAI 的 Davinci Embedding，Harrison 覺得 LangChain 可以做到先用 Hugging Face 或者 Cohere 上便宜的模型做一道，然后再傳給 Davinci Embedding，這樣可以降低不少成本。

還有今年以來，ChatGPT 有時候會崩，這也引發(fā)了應用開發(fā)者們的擔憂。Will Brenton 覺得出于這種理由用 LangChain 就很值得，可以用幾行代碼實現(xiàn)在多個 LLM 之間切換的邏輯，一個 LLM 如果服務掛掉了就自動試下一個。

使用 LangChain 對比多個模型的輸出

快速崛起的開源社區(qū)

LangChain 是目前 LLM 領域最熱門的開源項目之一，從下面可以看出今年以來的曲線和絕對 Star 數(shù)跟最熱門的開源模型 LLama 相比也不遑多讓，發(fā)布不到 5 個月已經(jīng)擁有了超過 1 萬個 Github Star。

人多力量大，我們在上文介紹的集成大多數(shù)也都是社區(qū)貢獻的，目前 LangChain 的全職團隊只有 2-3 個人：

?發(fā)起人是 Harrison Chase，他 17 年從哈佛大學畢業(yè)，分別在 Kensho（一家金融自動化公司，做金融分析決策與 NLP 的結(jié)合）和 Robust Intelligence（AI 模型部署的安全公司）做機器學習工程師，在 2022 年 9 月 的 Homebrew AI Club 聚會上聽到 Sam Whitmore 構建 AI 應用的過程和痛點后，他開始做 LangChain；

?第一位全職加入 Harrison 的 LangChain 創(chuàng)業(yè)之旅的人似乎是 Ankush Gola，他從普林斯頓畢業(yè)后分別在 Facebook、Robust Intelligence 和 Unfold 做軟件開發(fā)，可以彌補 Harrison 在軟件工程方面經(jīng)驗的缺失。Harrison 搞不定 LangChain 的異步支持問題，Ankush 加入后迅速彌補了這一點，讓 LangChain 能夠使用 asyncio 庫。

開源是擴大影響力和話語權的最好手段，LangChain 在 ChatGPT API 和 GPT-4 問世的當天都迅速發(fā)布了集成，基于 LangChain 構建的應用想轉(zhuǎn)用 GPT-4 只需要換下 API key 和模型名字就行了，顯然 LangChain 是 OpenAI 的重點合作對象之一。

除了 OpenAI 的這些更新，Zapier 推出的 Natural Language Actions API 也是跟 LangChain 進行了深度合作，Zapier NLA 對其 2 萬多個工具的操作實現(xiàn)了“自然語音 → API call → LLM-friendly 輸出”，也是基于 LangChain 做的。然后在推出當天，LangChain 也官宣了跟 Zapier NLA 的集成，用戶可以先在 Zapier 支持的 App 上設置好一個 NLA API endpoint，然后就可以在 LangChain 中調(diào)用和組合使用 Zapier。

從這兩個案例看，LangChain 是大模型能力“B2B2C”的一個重要中間站。

此外，除了給 LangChain 項目直接做貢獻，還有不少人已經(jīng)在圍繞 LangChain 做生態(tài)項目，下面是我最喜歡的 2 個：

LangChain 本身是一個沒有 UI 的庫，但社區(qū)成員 Rodrigo Nader 為它構建了一個開源的 UI，叫做LangFlow，讓用戶可以通過拖拽就能做出來應用原型。

大多數(shù)用戶會使用 Streamlit 或者 Replit 來部署它們的應用，但是已經(jīng)有社區(qū)成員開始為 LangChain 應用打造更炫酷的部署方式，比如Kookaburra，可以讓 LangChain 應用非常方便地被部署為短信機器人。

04.挑戰(zhàn)：對 Prompt Ops 的質(zhì)疑

從投資者視角，我對 LangChain 的擔憂有兩點：

1. 它是一個很難被商業(yè)化的開源項目，因為它是一個“依賴其他開源庫的開源庫”，我所訪談的 LangChain 開發(fā)者也都認為自己不會為它付費，如果要構建一個基于 LLM 應用的公司，他們會選擇自己 fork LangChain 再寫一套框架，還能順手把成本和延時問題做更多優(yōu)化；

2. 和第一點相輔相成的是，目前使用 LangChain 的主流人群是 Hacker 和獨立開發(fā)者們，而不是 B 輪以后的 Mid-Market 或者大型企業(yè)公司。當然，這是目前 AI 應用生態(tài)的現(xiàn)狀，獨立開發(fā)者在數(shù)量上占據(jù)主導。而且當前的 LangChain 實現(xiàn)一些復雜邏輯需要多個 Chain 的嵌套，并且多次 call LLM API，對于大規(guī)模調(diào)用的產(chǎn)品可能也確實成本不經(jīng)濟也有不穩(wěn)定的情況。但是正因為此，LangChain 更難進行商業(yè)化，特別是在從數(shù)據(jù)準備到模型部署的全環(huán)節(jié)已經(jīng)非常卷的情況下。

從演進的視角看，我對于 LangChain 這個庫本身能不能具備服務中大型公司倒比較有信心 —— 兩個月前人們還不認為 LangChain 是一個在生產(chǎn)環(huán)境中可靠的東西，一個月前 LangChain 才剛剛支持自托管模型，讓企業(yè) LLM 用戶可以在 LangChain 中調(diào)用共享遠程 API，但是它在客戶自己的云賬戶或者本地硬件中運行。給 LangChain 時間，貢獻者們會讓它高度可用。

市場上普遍對 LangChain 有擔心，但是我認為短期影響不大的兩點是：

1. LLM 本身的變化會讓 LangChain 庫中的許多部分過時。這一點我認為恰恰是開源項目的優(yōu)勢，貢獻者可以迅速幫助它過渡到新版本；

比如 ChatGPT API 發(fā)布后，它有了新的交互，這也意味著需要新的抽象，原來的很多 Prompt 不管用了，適用于 GPT-3 的 Prompt Templates 在 ChatGPT 下效果不好，所以 LangChain 又新增了 PromptSelectors 功能。此外 ChatGPT 在遵循特定的輸出數(shù)據(jù)格式上表現(xiàn)得不好，有很多“無法解析 LLM 輸出”的報錯，LangChain 很快上了一個 chat-zero-shot-react-description Agent 來嚴格約束輸出的數(shù)據(jù)格式，還大受好評。使用 LangChain 可能幫助很多公司避免過多的 Prompt Engineering 開發(fā)資源浪費。

2. 隨著模型支持的 token 數(shù)量變多，LangChain 的核心用例 —— 用分塊、Embedding、語義搜索、再拼回來 —— 可能會直接消失。這在短期內(nèi)不是個問題，因為哪怕 GPT-4 的 3.2 萬 token 也仍然不是很夠用。同時，這種 Map Reduce 的方式還能省錢。

在理性的質(zhì)疑中，我比較認可的是 Notion AI 的 Linus 的觀點，他在 Twitter 上表示當前所有類似 LangChain 的 Prompt Ops 工具都是為 side-project 級別的用戶服務的，很難正經(jīng)接受它們，主要有 3 點原因：

1. 這些工具都假設一個服務是對 LLM 的調(diào)用，然后在此之上把業(yè)務邏輯耦合進去。而不是反過來，在已有業(yè)務邏輯里插入對 LLM 的調(diào)用，這讓現(xiàn)有的 SaaS 等公司很難使用這些工具；

2. 對于模型的輸出大家目前都沒有可量化的方式來評估，Humanloop 已經(jīng)有最好的模型評估 UI 了，但是也是為了人類反饋對齊而不是為了應用開發(fā)者的性能優(yōu)化和迭代；

3. 這些工具都希望成為生產(chǎn)環(huán)境下工作負載的關鍵中間點，但是有延時和安全性上的很有問題，還不如給用戶交付模型配置和最終 prompt 然后讓用戶自己調(diào)用模型。

一些朋友在 Linus 的觀點下指出：LangChain 不是一個 Prompt Ops 工具，它是一個 LLM 增強工具，通過粘合一系列的模塊（這些模塊本身可能是 Prompt 增強工具）增加了 LLM 可以融入的業(yè)務邏輯復雜度。Linus 也認同這一點?？傮w而言，我認為這些批評為 LangChain 指明了方向，它也的確在 3 月?lián)碛辛烁嗪湍Ｐ驮u估以及性能可觀測性相關的集成。

05.競爭：以和為貴、各展神通的時代

拋開直接面向消費者的應用不看，LangChain 的核心競爭對手是三類：

?GPT-Index本身是基于 LangChain 構建的，它的用例更集中于 Memory 和將數(shù)據(jù)導入 LLM，用例非常明晰，而 LangChain 的功能更抽象和龐大，用戶需要在其中挑選符合自己用例的進行組合；

?Microsoft Semantic Kernel的整體目標和 LangChain 非常接近，Planner 類似我們上文提到的 Agent，但是它針對的受眾不是獨立應用開發(fā)者，而是那些需要在兼顧原有開發(fā)工作的同時將 LLM 能力嵌入自家應用的工程師們，因此采用了一個輕量級 SDK 的形式交付，它是 LangChain非常強勁的潛在競爭對手，但是 Microsoft 和 OpenAI 的親密關系可能讓它在未來無法像 LangChain 一樣靈活支持各類 LLM；

?Dust 和 Scale AI Spellbook代表著 LLM 應用開發(fā)的無代碼和低代碼思路，擁有非常好的 UI/UX，但是大多數(shù)開發(fā)者認為自己并不是需要低代碼的工具，而是需要更多的功能和可實驗性。

我們訪談的所有 LangChain 用戶都只使用 LangChain，對于 GPT-Index 和 Dust 只探索到去它們的 Github 和官網(wǎng)逛逛的程度。有 Twitter 博主專門橫向測評了這三個工具，結(jié)論是：

如果你想構建復雜邏輯并且自己托管后端的應用，那就使用 LangChain。Dust 和 Everyprompt 是通過 UI 來定義 Prompt 和創(chuàng)建 LLM 工作圖，LangChain 作為一個 Python 庫提供了更多的靈活性、可控度但更笨重。它的 game changer 是圍繞 Agent 的能力，一個可以跟外部工具（python interpreter、搜索引擎）交互從而回答問題的 LLM，這是其他工具所不具備的。

不看大廠的話，創(chuàng)業(yè)三杰 LangChain、GPT-Index、Dust 互相有很多羈絆，絕對不是火并競爭的關系：Dust 比 LangChain 出現(xiàn)得更早，由前 OpenAI 的Stanislas 創(chuàng)建，它的理念和對可組合性的重視對 Harrison 做 LangChain 有很大的啟發(fā)。而 GPT-Index 的創(chuàng)始人 Jerry Liu 是 Harrison 在 Robust Intelligence 時的同事，因此兩個人經(jīng)常交流產(chǎn)品想法，GPT-Index 和 LangChain 互相有非常多的集成。

甚至 GPT-Index 本身也是基于 LangChain 構建的，能享受 LangChain 基建升級的許多好處。比如 LangChain 在 1 月底提供了 tracing 的能力，讓用戶能更好觀測和 debug 自己的 Chain 和 Agent，GPT-Index 作為基于 LangChain 的包也自動獲得了這個功能。下圖是一個 GPT-Index query 的 tracing 視圖：

06.未來：Harrison 超越 LangChain

LangChain 是一個開源項目，Harrison Chase 想構建的似乎不止于 LangChain。上個月，The Information 報道 Benchmark 以數(shù)千萬美元估值投資了 LangChain 數(shù)百萬美元。Harrison 有可能在繼續(xù)擴大 LangChain 影響力的同時做出更產(chǎn)品化的開發(fā)者工具。

從早期投資押注人的角度，Harrison 是一個很好的創(chuàng)業(yè)者和項目經(jīng)理，盡管還沒有直接交流過，但我比較喜歡他的幾個特質(zhì)：

敏銳地把握到了 LangChain 的機會

在 22 年下半年，市場逐漸開始意識到 LLM 的下一步是“Action”，也就是在外部世界能夠采取行動。標志性的事件之一是 Cohere 在 9 月推出了基于 LLM 的 Discord 搜索機器人。

Harrison 這時候已經(jīng)花了不少時間思考下一步所需要的工具，并且留意到了 Dust 的嘗試，隨后就開始構建 LangChain 這個 Python 包，并且在 10 月就立馬推出。在此期間，碰到有人做應用，Harrison 經(jīng)常會問問對方“什么工具會幫你提效”、“還缺什么工具”。

回過頭看，LangChain 能繼續(xù)火下去的前提是，目前 AI 應用已經(jīng)從模型技術能力的 pk 到了產(chǎn)品能力的 pk，Harrison 自己的總結(jié)是“能有好的產(chǎn)品創(chuàng)意的人 > 能創(chuàng)建更好模型的人”，而 LangChain 就希望解鎖這些人的創(chuàng)意和效率。

對 LLM 的進展、能力、痛點 有自己獨到的理解

從后視鏡看，LangChain 的 Chain 和 Agent 邏輯似乎是個無腦的選擇。但是 Harrison 當時選擇構建這一點是基于對 Action 驅(qū)動和對 LLM 能力的判斷，受到了 ReAct 這篇論文不少影響。

他對于 token 數(shù)量限制的理解也很敏銳，將 Map Reduce 的實現(xiàn)提到了 LangChain 比較高的優(yōu)先級，后面隨著 1 月份各種 AI Hackthon（Hugging Face、Scale AI 等）的舉辦，對快速使用這個邏輯的需求激增，并且相關參賽隊伍都會提到自己使用了 LangChain，讓 LangChain 迅速變成了 AI 應用開發(fā)者們的第一選擇。

LangChain 開發(fā)者舊金山 Meetup 的盛況

非常緊貼用戶需求并且展現(xiàn)出很強的執(zhí)行力

LangChain 上線各類新模型和新集成的速度非?？?，Harrison 自己干活快，而且迅速讓 LangChain 的社區(qū)非常有凝聚力 ——AI 和 LLM 本身是有趣且實用的，Harrison 推動做了 LangChain Hub，旨在為用戶提供一個易于分享和發(fā)現(xiàn) Prompt Sequence、Chain 和 Agent，又加深了這一點。同時，Harrison 很善于跟社區(qū)成員交流獲得更多的反饋，在 LangChain Discord 社區(qū)頻繁互動，并且建立了一個專用的 Slack 頻道幫助大家將 LangChain 用于生產(chǎn)環(huán)境。

有一個小的細節(jié)是：在 1 月中旬，有用戶反饋 LangChain 的 verbose（根據(jù)內(nèi)容來自的模型或組件來使用突出色號顯示）挺有用但可以更詳細，比如每個查詢到底用了多少 token，這樣在應用可能被大規(guī)模使用時可以更好地追蹤成本。這是個很細節(jié)的功能，但是 Harrison 表達了重視并且在一周之后添加了對 token 的計算和顯示，并且通過 GPT-Index 統(tǒng)計 token 的具體使用情況。類似的例子我還觀察到了不少，只要是 Harrison 答應用戶的需求，一定不久就會發(fā)布。

Reference

Blog@LangChainTwitter@Harrison Chase

https://www.youtube.com/watch?v=h0DHDp1FbmQ

https://www.youtube.com/watch?v=X51N9C-OhlE

https://www.youtube.com/watch?v=Zn-L6t1BliA

https://www.youtube.com/watch?v=lhby7Ql7hbk&t=8s