Langchain 是一個專為開發由大型語言模型(LLMs)應該開發而誕生的框架。其核心精神是希望開發人員能夠很容易製作 LLMs 應用,並且外部資料源無縫整合,進而實現任務。目前有 Python 版本和 JavaScript 版本,不過以生態系來說,目前還是 Python 比較完整。
Langchain 是一個社群驅動的開源框架,允許開發人員貢獻並利用社區的集體知識和資源,目前在 GitHub 上已經累積六萬四千多個星星了。另一套類似的開源框架,Semantic Kernel,相較之下星星數只有一萬三千五個左右,可以見到 Langchain 的社群開發力量是很強大的。
在模組方面,LangChain 提供了標準且可擴展的接口以及外部整合,包括以下模組:
Model I/O:與語言模型的接口,使開發人員能夠利用語言模型的能力進行各種不同的任務。
Retrieval:通過此模組,開發人員可以從外部檢索必要的資料,以便在應用程式中使用。
Chains:協助構建 Chain,使開發人員可以更有效地組織和執行多個操作或查詢,以實現更複雜的功能。
Agents:讓鏈根據高級指令選擇使用哪些工具,通過此模組,開發人員可以更靈活地控制和管理應用程序中的不同部分和功能。舉例來說,你可以寫一個發 email 的 agent 讓你的 LLM 應用可以整合寄出 email 的功能。
Memory:提供了在鏈的運行之間保持應用狀態的能力,通過此模組,開發人員可以在不同的運行之間保留和管理應用程式的狀態,以確保持續性和一致性。尤其是對話 QA 時最常使用這一塊。
Callbacks:提供了 log 和流程中間步驟的能力,通過 callback ,開發人員可以更好地理解和監控應用程式的運行,並在需要時進行調整。
無可否認,Langchain 是語言模型和應用開發領域的革命性框架,為利用 LLM 創建強大、上下文感知的應用程序提供了有效的渠道。通過其模塊化和集成設計,以及簡化開發的一系列功能,然而 Langchain 還是有許多被人詬病的地方。
過度抽象和封裝: 在某些情況下,Langchain 的高度抽象和封裝可能會限制開發人員的彈性。例如,如果一個開發人員想要對模型的某個特定層或操作進行細粒度的控制,Langchain 的抽象層可能會讓這變得困難。開發人員可能會發現他們無法輕易地訪問或修改底層的代碼,這可能會阻礙他們進行特定的優化或調整。舉例來說,載入 CSV 是一個很簡單的功能,但是透過 Langchain 抽象後與封裝,使得 Python 原生 CSV 套件難以做更多操作。
依賴性和學習曲線: 雖然 Langchain 提供了許多方便的工具和模組,但它也引入了新的依賴性和學習曲線。開發人員可能需要花費額外的時間來學習如何使用 Langchain,以及如何配置和管理與之相關的各種模組和工具。對於那些偏好更自由或低層次工具的開發人員來說,這可能會感到有些限制。
API 與原生 SDK 的偏離:我們前幾天談了向量資料庫,幾乎都是使用向量資料庫官方原生的 SDK。Langchain 也有跟各大向量資料庫做整合,但是其 API 名稱往往與原生的 SDK 不一致,而且如第一點所述的,很多細粒度的操作都無法控制。
版本間的差異過於劇烈:因為 Langchain 還在相關早期開發的階段,很多方面的成熟度都很不足,也導致版本和版本之間的差異過大。常常會發生一更新版本,原本的程式碼就無法運作,也因此更需要好好管理 Python 套件的版本。
這些可能的爭議點突顯了在選擇使用高度集成和抽象框架、並且相當年輕的框架時,可能需要考慮的一些權衡。在選擇使用 Langchain 或任何其他類似框架時,開發人員需要考慮他們是否願意犧牲某些控制和彈性,以換取開發速度和便利性。
明天我們就開始來用 Langchain 和向量資料庫做整合吧!