LlamaIndex
為什麼重要
深度解析
LlamaIndex 最初名為 GPT Index，是 Jerry Liu 在 2022 年底進行的個人專案，起點是一項簡單觀察：大型語言模型的上下文視窗有限，因此若要將私有資料送進模型，不能一次全部塞入，而須在查詢時挑出正確的數千個 token。專案於 2023 年初改名為 LlamaIndex，也是向當時人氣迅速上升的 Meta Llama 模型致意；隨後它發展成一家公司，如今已形成成熟生態系，擁有 Python 與 TypeScript 版本、數百項社群整合（LlamaHub），以及託管雲端服務 LlamaCloud。框架範圍早已遠超索引這個起點，但其心智模型仍未改變：連接資料、建立索引，再透過檢索器、查詢引擎與代理，將資料交給 LLM。
核心抽象
LlamaIndex 中的一切，都建立在少數幾個概念上。資料連接器也稱為 reader，負責從 PDF、Notion、Slack、SQL 資料庫及 GitHub 等來源載入文件；LlamaHub 上有數百種可安裝套件。接著，節點解析器將文件切成區塊，預設使用 SentenceSplitter——它會盡量在句子與段落邊界處切分，而非生硬地按照字元數分割，這會直接影響檢索品質。索引再為搜尋整理這些區塊：VectorStoreIndex 將嵌入存入向量資料庫，用於語意搜尋；SummaryIndex 則直接走訪全部內容，適合「摘要整份文件」等任務，此外還有關鍵字、清單、樹狀及知識圖譜變體。最後，檢索器從索引取回相關節點，查詢引擎或聊天引擎則包裝完整迴圈——檢索、填入提示範本、呼叫模型，再回傳附有引用的答案。
從 GPT Index 到資料框架
最初的 GPT Index 是一個很薄的函式庫，全部工作就是將文件整理成可搜尋索引，以繞過上下文限制。2023 年，RAG 成為企業 AI 的主流模式，函式庫也順勢納入整條管線：資料匯入、切成區塊、嵌入、檢索、重排序與合成。這項焦點正是它與主要對手在理念上的差異。LangChain 想成為可串接任何 LLM 操作的通用框架，LlamaIndex 卻始終以資料為中心——它的抽象預設你手上有一批文件，並希望模型能以其內容進行推理。實務上，許多團隊會同時使用兩者，兩套生態系也逐漸匯合：LangChain 取得紮實的檢索工具，LlamaIndex 則發展出代理與編排能力。
它不只是一個 RAG 函式庫
一項常見誤解，是 LlamaIndex 等於 RAG，而 RAG 又等於向量搜尋。實際上，現代版本的大部分功能範圍都與 top-k 查找沒有太大關係。代理層讓模型可規劃多步任務並呼叫工具，Workflows 系統則是一層事件驅動的編排設施，將多步驟 LLM 程式建模成帶有型別事件的離散步驟；相較於一條巨型鏈，這種方式更容易除錯與重試。LlamaCloud 背後的文件解析引擎 LlamaParse，可將包含表格及多欄版面的混亂 PDF 轉換成乾淨 Markdown——這種資料匯入品質帶來的改善，通常比任何檢索技巧都更大。框架也大力支援Structured Output（結構化輸出），因此完全不必使用向量索引，也能建構將非結構化文件轉成型別化物件的擷取管線。
LlamaIndex 與 LangChain
每次架構討論都會出現這項比較；坦白說，兩套框架高度重疊，也都能完成工作。文件密集型工作負載通常更適合 LlamaIndex：其開箱即用的索引、檢索與評估工具更深入，預設設定已針對語料庫問答調校，查詢引擎抽象也隱藏大量 RAG 樣板程式碼。模型呼叫多、邏輯需要分支、非文件工具眾多的編排密集型工作，則通常更適合 LangChain，其 LangGraph 生態系尤其擅長複雜的代理工作流程。兩者都能串接相同的向量資料庫、嵌入供應商與可觀測性工具，也都支援 MCP 等工具存取標準。真正的成本是綁定：無論選擇哪一個，都等於採用其整套抽象；因此，預期日後會超出框架邊界的團隊，有時會盡量減少與框架的接觸面，自行掌控檢索邏輯。
正式環境中的考量
在一個下午內完成示範很容易；真正使其可靠，才是框架證明價值之處。資料匯入品質主宰結果，因此團隊會先投資於解析、元資料擷取——替每個區塊附上日期、作者與文件類型——以及評估框架，用來衡量檢索命中率與答案忠實度，接著才調整其他部分。LlamaCloud 為不想自行維運管線的團隊提供託管式解析、索引與檢索，代價是必須將文件交給第三方服務——在某些合規制度下，這一步完全不可行。框架不受模型限制，因此既能串接 OpenAI、Anthropic，也能串接在自有硬體上執行的本機模型；但這種彈性也代表，管線中每次呼叫的延遲與成本取捨，都須由你自行承擔。