如果你正在開發 RAG（Retrieval-Augmented Generation）應用，十之八九會遇到這個問題：到底該用 LangChain 還是 LlamaIndex？

老實說，我自己在去年也糾結了好一陣子。兩個框架都很強大，但解決問題的思路完全不同。今天我就把這幾個月的使用心得，加上 2026 年最新的基準測試數據，一次整理給你。

為什麼需要比較這兩個框架

先說結論：LangChain 是編排引擎，LlamaIndex 是資料引擎。聽起來很抽象，但理解這個根本差異，後面的選擇就會簡單很多。

根據 GitHub 的數據，LangChain 目前有超過 85,000 顆星，LlamaIndex 也突破了 30,000 顆星。兩者都有非常活躍的社群，所以不存在「某個框架快死了」的問題。

但如果你之前用過 LangChain Agent 開發入門的教學來入門，可能會覺得 LangChain 什麼都能做。確實可以，但「能做」跟「做得好」是兩回事。

LangChain 核心特點與架構

LangChain 的 DNA 是 Agent、Tools、Memory 和 State。它把 LLM 當成一個推理引擎：可以呼叫計算機、搜尋 Google、執行 Python 程式碼，然後根據結果決定下一步行動。

不過，LangChain 最常被詬病的就是「依賴地獄」。它是一個龐大的函式庫，版本更新時偶爾會出現破壞性變更。我曾經升級一個小版本，結果三個 chain 全部壞掉，花了一整天在修 breaking changes。

另一個問題是 Token 效率。由於 LangChain 的通用性設計，它在 RAG 場景下的 prompt 模板通常比較冗長，平均每次查詢消耗約 2,400 tokens。

LlamaIndex 的核心使命很明確：幫助 LLM 高效存取外部資料。它專精於文件攝取、索引建構和結構化檢索。

LlamaIndex 的問題是「過度抽象」。很多時候你覺得它像魔法一樣自動處理好了，但如果需要客製化檢索管線，不了解內部機制的話會很痛苦。我第一次試著改 retriever 的排序邏輯，翻了半天文件才搞清楚抽象層的結構。

光說不夠，來看數據。這是用相同模型（GPT-4.1-mini）、相同嵌入（BGE-small）、相同檢索器（Qdrant）跑 100 次查詢的結果：

指標	LangChain	LlamaIndex	差異
框架開銷	~10 ms	~6 ms	LlamaIndex 快 40%
Token 使用量	~2,400	~1,600	LlamaIndex 省 33%
檢索準確率	相當	略勝	LlamaIndex 在複雜文件上表現更好

值得一提的是，DSPy 的框架開銷最低（~3.53 ms），Haystack 的 Token 使用量最少（~1,570）。如果你的需求很單純，這兩個也值得考慮。

說了這麼多，我的建議很直接：

其實在生產環境中，越來越多團隊採用混合架構：用 LlamaIndex 作為知識層負責資料索引和檢索，用 LangChain 作為編排層負責工作流和 Agent 邏輯。

簡單來說：

如果你對向量資料庫的選擇也感興趣，可以看我之前寫的分析。RAG 的效能不只取決於框架，底層的向量搜尋引擎同樣關鍵。

最後提醒一句：框架只是工具，重要的是理解你的應用場景。不要因為某個框架「比較潮」就選它，而是根據你的資料類型、查詢模式和團隊技能來做決定。祝你的 RAG 之旅順利！