為什麼都放棄了LangChain？

或許從誕生那天起，LangChain 就注定是個口碑兩極化的產品。

看好 LangChain 的人欣賞它豐富的工具和組建和易於整合等特點，不看好 LangChain 的人，認為它注定失敗 —— 在這個技術變化如此之快的年代，用 LangChain 來構建一切根本行不通。

誇張點的還有：

「在我的諮詢工作中，我花了70% 的精力來說服人們不要使用langchain 或llamaindex。這解決了他們90% 的問題。」

最近，一篇LangChain 吐槽文再次成為熱門焦點：

作者Fabian Both 是AI 測試工具Octomind 的深度學習工程師。 Octomind 團隊會使用具有多個 LLM 的 AI Agent 來自動建立和修復 Playwright 中的端對端測試。

這是一個持續一年多的故事，從選擇 LangChain 開始，隨後進入到了與 LangChain 頑強鬥爭的階段。在 2024 年，他們終於決定告別 LangChain。

讓我們看看他們經歷了什麼：

「LangChain 曾經是最佳選擇」

我們在生產中使用LangChain 超過12 個月，從2023 年初開始使用，然後在2024 年將其移除。

在 2023 年，LangChain 似乎是我們的最佳選擇。它擁有一系列令人印象深刻的組件和工具，而且人氣飆升。 LangChain 承諾「讓開發人員一個下午就能從一個想法變成可運行的程式碼」，但隨著我們的需求變得越來越複雜，問題也開始浮出水面。

LangChain 變成了阻力的根源，而不是生產力的根源。

隨著 LangChain 的不靈活性開始顯現，我們開始深入研究 LangChain 的內部結構，以改善系統的底層行為。但是，由於 LangChain 故意將許多細節做得非常抽象，我們無法輕鬆編寫所需的底層程式碼。

眾所周知，人工智慧和 LLM 是瞬息萬變的領域，每週都會有新的概念和想法出現。而 LangChain 這樣圍繞著多種新興技術創建的抽象概念，其框架設計很難經得起時間考驗。

LangChain 為什麼如此抽象

起初，當我們的簡單需求與 LangChain 的使用假設相吻合時，LangChain 還能幫上忙。但它的高階抽像很快就讓我們的程式碼變得更加難以理解，維護過程也令人沮喪。當團隊用在理解和調試 LangChain 的時間和用在構建功能上的時間一樣時，這可不是一個好兆頭。

LangChain 的抽象方法所存在的問題，可以透過「將一個英文單字翻譯成義大利文」這一微不足道的例子來說明。

下面是一個只使用 OpenAI 軟體包的 Python 範例：

這是一段簡單易懂的程式碼，只包含一個類別和一個函數呼叫。其餘部分都是標準的 Python 程式碼。

將其與 LangChain 的版本進行對比：

程式碼大致相同，但相似之處僅止於此。

我們現在有三個類別和四個函數呼叫。但令人擔憂的是，LangChain 引入了三個新的抽象概念：

• Prompt 模板： 為LLM 提供Prompt;

• 輸出解析器：處理來自LLM 的輸出；

• 輸出解析器：處理來自LLM 的輸出；

輸出解析器：處理來自LLM 的輸出；

的“LCEL 語法”覆蓋Python 的| 操作符。

LangChain 所做的只是增加了程式碼的複雜性，卻沒有帶來任何明顯的好處。

這種程式碼對於早期原型來說可能沒什麼問題。但對於生產使用，每個組件都必須得到合理的理解，這樣在實際使用條件下才不會意外崩潰。你必須遵守給定的資料結構，並圍繞這些抽象設計應用程式。

讓我們來看看 Python 中的另一個抽像比較，這次是從 API 中取得 JSON。

使用內建的 http 套件：

使用 requests 套件：

🎜🎜高下顯而易見。這就是好的抽象的感覺。 🎜🎜當然，這些都是微不足道的例子。但我想說的是，好的抽象可以簡化程式碼，減少理解程式碼所需的認知負荷。 🎜🎜LangChain 試圖透過隱藏細節，用更少的程式碼完成更多的工作，讓你的生活變得更輕鬆。但是，如果這是以犧牲簡單性和靈活性為代價的，那麼抽象就失去了價值。 🎜

LangChain 也習慣在其他抽象之上使用抽象，因此你往往必須從嵌套抽象的角度來思考如何正確使用 API。這不可避免地會導致理解龐大的堆疊追蹤和調試你沒有編寫的內部框架程式碼，而不是實現新功能。

LangChain 對開發團隊的影響

一般來說，應用程式大量使用 AI Agent 來執行不同類型的任務，如發現測試案例、產生 Playwright 測試和自動修復。

當我們想從單一 Sequential Agent 的架構轉向更複雜的架構時，LangChain 成為了限制因素。例如，產生 Sub-Agent 並讓它們與原始 Agent 互動。或多個專業 Agent 相互互動。

在另一個例子中，我們需要根據業務邏輯和 LLM 的輸出，動態改變 Agent 可以存取的工具的可用性。但 LangChain 並沒有提供從外部觀察 Agent 狀態的方法，這導致我們必須縮小實現範圍，以適應 LangChain Agent 的有限功能。

一旦我們刪除了它，我們就不再需要將我們的需求轉化為適合 LangChain 的解決方案。我們只需編寫程式碼即可。

那麼，如果不使用 LangChain，你該使用什麼框架呢？也許你根本不需要框架。

我們真的需要建立人工智慧應用程式的框架嗎？

LangChain 在早期為我們提供了 LLM 功能，讓我們可以專注於建立應用程式。但事後看來，如果沒有框架，我們的長期發展會更好。

LangChain 一長串的組件給人的印像是，建立一個由 LLM 驅動的應用程式非常複雜。但大多數應用程式所需的核心元件通常如下：

• 用於LLM 通訊的用戶端

• 用於函數呼叫的函數/ 工具 

• 用於資料庫 RA 的向量用於追蹤、評估等的可觀察性平台。

• Agent 領域正在快速發展，帶來了令人興奮的可能性和有趣的用例，但我們建議 —— 在 Agent 的使用模式得到鞏固之前，暫時保持簡單。人工智慧領域的許多開發工作都是由實驗和原型設計所驅動的。

以上是 Fabian Both 一年多來的切身體會，但 LangChain 並非全然沒有可取之處。

另一位開發者Tim Valishev 表示，他會再堅持使用LangChain 一段時間：

我真的很喜歡Langsmith：

箱即用的可視化日誌play立即從日誌中修復Prompt，並查看它在相同輸入下的表現 

• 可直接從日誌輕鬆建立測試資料集，並可選擇一鍵運行Prompt 中的簡單測試集（或在程式碼中進行端到端測試） 

• 測試分數歷史 

• Prompt 版本控制 

• 而且它對整個鏈的流動性傳輸提供了一些手動鏈的支援。
  何況，只靠 API 也是不行的，每家大模型廠商的 API 都不同，無法「無縫切換」。

你怎麼看？

原文連結：https://www.octomind.dev/blog/why-we-no-longer-use-langchain-for-building-our-ai-agents

以上是為什麼都放棄了LangChain？的詳細內容。更多資訊請關注PHP中文網其他相關文章！