不用 LangChain 的 RAG：無需 Python 框架建構生產級檢索管線

每當有人在 Reddit、Stack Overflow 或任何 AI Discord 上問「我該怎麼建構 RAG」時，LangChain 已經成為了預設推薦。這是有道理的：在 2023-2024 年間，它讓人們從零到一個可運作的原型比其他任何工具都快。你可以用五十行 Python 程式碼連接一個向量資料庫、一個嵌入模型和一個聊天補全端點。

但越來越多的生產團隊正在悄悄地將其移除。不是因為 LangChain 不好——它確實幫助引導了 RAG 生態系統。他們移除它是因為那些讓 LangChain 在原型階段表現出色的特性在生產規模下變成了負擔。

如果你正在評估如何在不使用 LangChain 的情況下建構 RAG 管線，或者在考慮是否應該遷移，這是一篇誠實的分析：到底有什麼問題、有哪些替代方案，以及什麼時候 LangChain 仍然是正確的選擇。

抽象稅

每個框架都有代價。你用控制權換取便利性。當抽象是穩定的、文件齊全的，並且能清晰地映射到你對底層系統的心智模型時，這種權衡是值得的。

LangChain 的抽象在生產環境中的這三個方面都表現不佳。

版本變動。 LangChain 的 API 介面在各版本之間變化劇烈。基於 langchain==0.0.x 建構的團隊發現他們的程式碼被 0.1.x 破壞，然後又被 langchain-core / langchain-community 的拆分再次破壞。在原型環境中，你固定一個版本就繼續前進。在有 CI/CD 管線、相依性稽核和安全審查的生產系統中，每次破壞性變更都要消耗工程時間。

除錯黑盒。 當 RAG 管線回傳一個不好的答案時，你需要檢查每個階段：查詢轉換、嵌入、檢索步驟、重排序和提示詞組裝。LangChain 將每一個都包裹在層層抽象中——鏈、可執行物件、回呼——這使得很難看到每個步驟實際發生了什麼。團隊報告說花在除錯框架上的時間比除錯管線邏輯的時間還多。

簡單管線的過度工程化。 大多數生產 RAG 系統遵循一個簡單直接的模式：嵌入查詢、搜尋向量儲存、將上下文組裝到提示詞中、呼叫模型。這大概是 100 行直接程式碼。LangChain 為本質上是線性資料流的東西引入了鏈、代理、輸出解析器、檢索器和記憶物件等概念。認知開銷是真實的，特別是在讓新工程師熟悉程式碼庫時。

供應商耦合。 LangChain 透過其整合層支援數十個 LLM 供應商、向量儲存和嵌入模型。但這個整合層意味著你依賴 LangChain 來維護每個供應商的包裝器。當供應商更新他們的 SDK 時，你要等 LangChain 跟上。當你想使用供應商特定的功能時，你要與抽象作鬥爭才能存取它。

這些都不意味著 LangChain 是一個糟糕的專案。它意味著這個框架是為廣度和入門速度最佳化的，而不是為生產中重要的營運關注點最佳化的：可除錯性、穩定性和透明性。

替代方案 1：直接 SDK 呼叫

團隊離開 LangChain 時最常走的路是最簡單的：完全放棄框架，直接呼叫供應商的 SDK。

使用直接呼叫建構的生產 RAG 管線通常是這樣的：

1. 嵌入查詢，使用你的嵌入供應商的 SDK（OpenAI、Cohere 或透過 sentence-transformers 使用本地模型）
2. 搜尋向量儲存，使用儲存的原生客戶端（Pinecone、Weaviate、Qdrant、pgvector）
3. 可選地重排序檢索到的分塊，使用交叉編碼器或重排序 API
4. 組裝提示詞，將檢索到的上下文插入你的提示詞模板
5. 呼叫 LLM，使用供應商的 SDK 和你組裝好的提示詞

每個步驟都是一個函式呼叫。每個函式呼叫回傳你可以獨立記錄、檢查和測試的資料。沒有框架狀態需要管理，沒有回呼系統需要設定，你和實際操作之間沒有鏈式抽象。

適用場景： 擁有強大 Python/TypeScript 工程能力的團隊，定義明確且不會頻繁改變形態的管線，以及在每個步驟都需要完全可觀測性的需求。當你想要除已有服務之外零外部相依性時，這是 LangChain 最佳的本地替代方案。

代價： 你要寫更多程式碼。你要建構自己的重試邏輯、自己的批次處理、自己的提示詞管理。對於單一管線來說這很簡單。對於多個團隊的十個管線，你最終會建構一個內部函式庫——實際上就是你自己的迷你框架。

替代方案 2：LlamaIndex

LlamaIndex（前身為 GPT Index）佔據了一個中間地帶。它仍然是一個框架，但專門為檢索和索引設計，而不是通用的 LLM 編排。

哲學上的關鍵區別：LangChain 試圖抽象整個 LLM 應用堆疊（代理、工具、記憶、鏈）。LlamaIndex 專注於資料索引和檢索問題——如何為模型取得正確的上下文。

在實務上，這意味著 LlamaIndex 的抽象與 RAG 管線實際做的事情更緊密地對應。它的核心概念——節點、索引、查詢引擎和檢索器——直接對應檢索管線中的各個階段。你花更少的時間與框架作鬥爭，因為框架的心智模型與問題匹配。

LlamaIndex 在 API 變更方面也更為保守，儘管它也經歷了自己的重構（llama-index-core 的拆分與 LangChain 的模組化如出一轍）。

適用場景： 想要框架便利性——預建整合、合理的預設值、文件解析工具——但不想要 LangChain 龐大抽象表面的團隊。如果你的管線涉及複雜的文件處理（層次化分塊、多文件合成、從 PDF 中提取結構化資料），LlamaIndex 特別強大。

代價： 你仍然在框架中。你仍然依賴維護者來保持整合的更新。但表面積更小，所以相依性風險更低。

替代方案 3：視覺化管線建構器

第三類方案已經出現，面向那些想要在不使用 LangChain 且完全不編寫管線編排程式碼的情況下建構 RAG 管線的團隊：視覺化管線建構器和低程式碼平台。

Flowise、Langflow、Haystack Studio 等工具以及專用企業平台讓你透過在視覺化圖中連接節點來組裝檢索管線。每個節點代表一個步驟——嵌入、檢索、重排序、生成——平台處理執行、監控和部署。

其中一些工具在底層使用 LangChain 或 LlamaIndex，但將你與框架的複雜性隔離開來。其他工具則基於自己的執行引擎建構。

適用場景： 建構 RAG 管線的人是領域專家（資料分析師、產品經理、解決方案工程師）而非後端工程師的團隊。也適用於快速實驗——你可以在一個下午透過交換節點嘗試二十種不同的分塊策略。

代價： 你用程式碼層級的控制換取了易用性。超出平台支援範圍的客製化需要變通方法或外掛程式。當你無法看到或修改底層程式碼時，效能調校更困難。而且你在基礎設施之上增加了一個平台相依性。

什麼時候 LangChain 仍然是正確的選擇

寫一篇關於不用 LangChain 的 RAG 的文章而不承認 LangChain 真正閃光的地方，那是不誠實的。

學習和原型化。 如果你是 RAG 新手並想了解各個組成部分，LangChain 的教學和社群資源是無與倫比的。你用 LangChain 取得可運作原型的速度比任何其他方法都快。在生產中成為負擔的抽象在你學習時是資產——它們讓你專注於概念而不被實作細節淹沒。

快速實驗。 當你需要在一週內測試十幾種不同的檢索器策略、模型供應商和提示詞模式時，LangChain 的即插即用整合節省了真正的時間。當你在探索、尚未確定特定架構時，框架的廣度是一個優勢。

以代理為中心的架構。 如果你的系統確實需要代理行為——工具使用、多步推理、動態路由——LangChain 的代理抽象（特別是透過 LangGraph）是目前最成熟的。當你在建構自主代理時，直接 SDK 呼叫會很快變得複雜。

需求廣泛的小團隊。 一個三人新創團隊建構一個 AI 功能不需要客製的管線架構。LangChain 讓他們更快地進入市場，而其抽象的營運成本在他們達到一定規模之前不會顯現——而達到那個規模本身就是一個好問題。

決策框架

以下是一種簡單的思考方式，幫助你判斷哪種方法適合你的情況：

誠實的答案是，沒有普遍最佳的方法。不使用 Python 框架建構生產檢索管線的團隊往往會在核心管線上收斂於直接 SDK 呼叫，並保留一個框架用於實驗。需要快速行動且尚未擔心營運成熟度的團隊可以很好地使用 LangChain。

重要的是根據團隊的具體限制有意識地做出選擇——而不是因為「每個人都在用 LangChain」或因為「框架不好」。這兩種說法在任何真正的工程決策面前都站不住腳。

Ertas 的定位

Ertas 專為那些已經決定要掌控自己 AI 基礎設施的團隊設計。無論你是直接呼叫供應商 SDK、使用 LlamaIndex，還是從 LangChain 遷移，Ertas 處理底層的營運層：模型部署、資料管線管理和治理控制。

你按自己的方式建構 RAG 管線。Ertas 確保它可靠執行、保持合規，並在不需要重新架構的情況下擴展。不強加框架意見——只是不妨礙你的基礎設施。