LangChain 由 Harrison Chase 開發，是一個 Python 和 JavaScript 庫，用於與OpenAI的 GPT API（後來擴充套件到更多模型）介面以進行 AI 文字生成。
更具體地說，它是 2022 年 10 月發表的論文《ReAct：在語言模型中協同推理和行動》的實現，俗稱 ReAct 論文，該論文演示了一種允許模型“推理”的提示技術（透過一系列思想） ）和“行動”（透過能夠使用一組預定義工具中的工具，例如能夠搜尋網際網路）。這種組合被證明可以極大地提高輸出文字質量，並使大型語言模型能夠正確解決問題。
LangChain 流行的 ReAct 工作流程在InstructGPT /text-davinci-003 上特別有效，儘管成本高昂且對於小型專案來說並不容易使用。
在BuzzFeed的工作中，我的任務是為Tasty品牌建立一個基於 ChatGPT 的聊天機器人（後來在 Tasty iOS 應用程式中以[url=https://www.buzzfeed.com/buzzfeedpress/buzzfeeds-tasty-introduces-botatouille-the-first-of-its]Botatouille 的[/url]形式釋出），它可以與使用者聊天並提供相關食譜。源食譜被轉換為嵌入並儲存在向量儲存中：例如，如果使用者詢問“健康食品”，則查詢將轉換為嵌入，並執行近似最近鄰搜尋以查詢與嵌入相似的食譜查詢，然後將其作為新增的上下文提供給 ChatGPT，然後可以向使用者顯示。這種方法通常被稱為檢索增強生成。
LangChain 是迄今為止 RAG 首選的流行工具，所以我認為現在是學習它的最佳時機。我花了一些時間閱讀 LangChain 相當全面的文件，以更好地瞭解如何最好地利用它：
- 經過一週的研究，我一無所獲。執行 LangChain 演示示例確實有效，但任何調整它們以適應菜譜聊天機器人約束的嘗試都會破壞它們。
- 解決bug後，聊天對話的整體質量很差而且無趣，經過緊張的除錯也沒有找到解決方案。
- 最終，我遇到了一場生存危機：我是不是一個毫無價值的機器學習工程師，因為我無法弄清楚 LangChain，而其他許多機器學習工程師卻可以？
總而言之，我浪費了一個月的時間來學習和測試 LangChain，最大的收穫是流行的 AI 應用程式可能並不一定值得大肆宣傳。在看到一個Hacker News 的帖子，說有人用 100 行程式碼重新實現了 LangChain，我的生存危機就解決了，大部分評論都發洩了對 LangChain 的不滿
LangChain 的問題在於：
它讓簡單的事情變得相對複雜，而這種不必要的複雜性造成了部落主義，損害了整個新興的人工智慧生態系統。
如果你是一個只想學習如何與 ChatGPT 互動的新手，絕對不要從 LangChain 開始。
詳細點選標題
其他網友觀點：
1、對我來說，現在我主要是反框架的，我更喜歡可以從中挑選的積木式框架。以下是我想到的一些痛點：
- 上下文管理：我建立了一個小型的 LLM 上下文管理工具來處理聊天記錄、RAG 和其他資料。在我建立完整應用之前，它一直執行良好，而現在我卻無法針對每個例項進行調整（影響分數容易、順序等），也無法確定有限上下文中包含哪些內容，這讓我感到很痛苦。
- 鏈/迴圈：我建立了一個小型的鏈庫，這樣我就可以編寫自定義提示並迴圈使用。這很有用，但我發現許多鏈 "條目 "需要自定義函式來控制流程。這對其他人來說幾乎是不可能的
- 檔案匯入：我使用 pymupdf，因為它似乎可以對 PDF 進行較低階別的訪問，足以讓我從檔案中生成帶標題的標記符。線上提取圖片和表格似乎很困難，多欄頁面更是災難。我希望能有一個庫，可以將任何文件轉換為 markdown。
- 分塊：我自定義了一個 markdown 分塊功能，這樣我就可以按標題將文件分塊，並在分塊中包含標題/文件標題後設資料。但它仍然很混亂，每次使用 RAG 時我都會感覺到它的侷限性。
我還對一些更高層次的問題感興趣：
- 流暢地處理聊天/RAG/代理--這樣 LLM 就能在必要時快速響應，必要時使用 RAG，否則就使用助手/代理迴圈。
瞭解多輪 RAG/代理：
例如，如何處理一個 RAG 問題，然後再處理一個上下文較少的通用後續問題？第一條資訊會返回大量結果，而第二條資訊則不會返回任何結果（"好吧，第二部分是什麼意思？）您是否會在上下文中包含原始 RAG 資料，並隨著聊天的繼續不斷填充更多資料？我的 RAG 和助手聊天感覺像是一次性的，而不是流暢的對話。
2、我非常喜歡 LangChain 的總體抽象水平，但我最大的問題是文件中的承諾太多，而實際能實現的卻很少。
舉個例子：
你會認為你可以在他們的 OpenAI LLM 類中使用與 OpenAI 相容的 API，尤其是因為他們有很多合併的 PR 專門用來新增該功能。
只是有點。
他們不會對返回的欄位進行任何資料驗證，只會對返回的對映/欄位進行原始索引，因此，如果後端 API 有不同的令牌概念，你很可能會因為 KeyErrors 而導致他們的實現崩潰，你必須重寫類的內部例項變數才能讓它正常工作。
是哪些？
請盡情閱讀他們的程式碼以及他們使用的客戶端程式碼。
同樣，如果你的 LLM 對格式非常挑剔，你就會認為你可以像他們的文件聲稱的那樣，在列表中生成一個系統、人工智慧和使用者提示的列表，然後將其輸入 LCEL 模型鏈。但事實並非如此！ChatMessage 和 LCEL 模型鏈之間的相容邏輯是在 ChatMessage 的特定子類中實現的，儘管文件聲稱所有 ChatMessage 都與 LCEL 模型鏈相容。
如果 LangChain 能夠變得更加註重測試，並對其承諾進行更全面的整合測試，我認為該框架將會非常出色。從最初的笨拙到現在的成熟，LangChain 已經走過了很長一段路，但還有很多事情要做。
在純功能層面上，我目前最喜歡的是 https://lmql.ai/，但它沒有那麼流行，而且隨著時間的推移，主要貢獻者的提交頻率也在下降，所以我對它不抱太大希望。