LangChain 核心概念解析

什麼是 LangChain？

LangChain 是一個強大的框架，旨在幫助開發者構建由大型語言模型（LLMs）驅動的複雜應用程式。您可以將其視為「黏合劑」，它將 LLM 的強大能力與外部資料源、計算資源和記憶系統連接起來。LangChain 將複雜的 LLM 應用程式分解為六大核心組件。

🧠 模型 (Models)

LLM 核心，提供標準介面。

💬 提示詞 (Prompts)

管理和優化 LLM 的輸入。

🔗 鏈 (Chains)

將多個步驟組合在一起。

📂 索引 (Indexes)

結構化外部資料以便 LLM 互動。

🤖 代理 (Agents)

賦予 LLM 決策和使用工具的能力。

💭 記憶 (Memory)

讓 LLM 記住過去的對話。

LCEL (LangChain 表達式語言)

LCEL 是 LangChain **現代**的組合方式，也是目前的主流。它使用「管道 (Pipe)」運算子 (|) 來串聯所有組件，取代了舊版的 LLMChain 類別。這種方式更簡潔、更靈活，並且原生支援串流 (Streaming)、並行處理 (Parallelism) 和非同步 (Async)。

LCEL 基礎：管道 (`|`)

LCEL 的核心是 | 運算子，它將一個組件的輸出「輸送」到下一個組件的輸入。


# 一個基礎的 LCEL 鏈
# 流程: 提示詞 -> 模型 -> 輸出解析器
chain = (
    prompt_template   # 1. 接收輸入, 格式化提示詞
    | model           # 2. 將提示詞傳給 LLM
    | StrOutputParser() # 3. 將 LLM 的回應解析為純文字
)

處理多重輸入：`RunnableParallel`

當鏈的起點需要多個變數時（例如 RAG 需要 context 和 question），我們使用 RunnableParallel（或 RunnableMap）來並行處理這些輸入。


# 一個完整的 RAG 鏈
chain = (
    {
        "context": retriever,  # 檢索器並行抓取上下文
        "question": RunnablePassthrough() # 原始問題直接通過
    }
    | prompt_template # 將 context 和 question 填入模板
    | model
    | StrOutputParser()
)

索引 (Indexes) & RAG - 賦予 LLM 外部知識

這是 LangChain 最核心的應用，用於將 LLM 連接到您自己的私有資料（如 PDF、網頁、資料庫），使其能夠回答「訓練資料之外」的問題。

                    RAG (檢索增強生成) 的完整流程
                    1. 文件載入 (Loaders): 從 PDF, Web, Notion, Databases 等來源讀取原始文件。
2. 文字分割 (Splitters): 將大文件切割成小的文字區塊 (Chunks)。這是必要的，因為 LLM 有上下文窗口限制。
                            chunk_size: 決定每個區塊的大小。
chunk_overlap: 決定區塊間的重疊字數，以確保語義連貫。

                        
3. 嵌入 & 儲存 (Embeddings & Vector Stores):
                            嵌入模型 (Embedding Model): 將每個文字區塊轉換為數字向量 (Embeddings)，這個向量代表了文字的「語義」。
向量儲存庫 (Vector Store): 一個專門的資料庫 (如 Chroma, FAISS)，用於儲存這些向量並執行高效的「語義搜尋」。

                        
4. 檢索 (Retrievers): 這是 RAG 鏈中的橋樑。當使用者提問時，檢索器會：
                            使用「嵌入模型」將使用者的問題也轉換為向量。
在「向量儲存庫」中搜尋與問題向量「語義最相關」（距離最近）的文件區塊。
將這些區塊作為「上下文 (Context)」傳遞出去。

                        
5. 生成 (Generation): 最後，RAG 鏈會將「上下文」和「原始問題」一起傳遞給 LLM，並給予明確指令（例如：「請僅根據提供的上下文來回答問題」），生成最終答案。

                

進階檢索技術 (Advanced Retrieval)

為了提高 RAG 的準確性，LangChain 提供了更進階的檢索策略：

上下文壓縮 (Contextual Compression)

在檢索到文件區塊後，先進行「壓縮」再傳給 LLM。這能過濾噪音、節省 Token。

- 過濾 (Filtering): 逐句檢查，只保留與問題相關的句子。
- 總結 (Summarization): 呼叫 LLM 將區塊總結成精簡摘要（成本較高）。

多查詢檢索 (Multi-Query Retrieval)

解決使用者問題模糊的問題。它會先呼叫 LLM，將一個模糊問題（例如：「LangChain 的優點？」）擴展為多個具體的子問題（例如：「LangChain 如何處理 RAG？」、「LangChain 的代理功能？」），然後分別檢索再合併結果，以擴大搜尋範圍。

代理 (Agents) - 賦予 LLM 行動能力

如果 RAG 是讓 LLM 擁有「知識」，那麼代理 (Agents) 就是讓 LLM 擁有「行動能力」和「決策大腦」。代理的核心是讓 LLM 自己決定下一步該做什麼。

ReAct 框架 (Reasoning + Acting)

代理的核心機制是 ReAct。LLM 不再只是單純回答，而是會進行「思考-行動-觀察」的循環：

思考 (Thought): LLM 分析當前任務，決定下一步該做什麼。（例如：「我需要知道現在的天氣」）
行動 (Action): LLM 決定呼叫一個「工具」(Tool)。（例如：呼叫 GoogleSearch 工具，查詢「台北天氣」）
觀察 (Observation): LLM 接收工具執行的結果。（例如：「台北市，28°C，晴」）
重複/回答: LLM 根據新的觀察結果，再次「思考」... 直到任務完成並給出最終答案。（例如：「台北現在 28°C，天氣晴朗。」）

工具集 (Tools)

工具是代理可以呼叫的任何外部功能。LangChain 提供了許多內建工具，您也可以輕鬆自訂：

搜尋 (Search): 例如 GoogleSearch, DuckDuckGo，用於獲取即時資訊。
計算 (Calculator): 用於執行精確的數學運算，避免 LLM 產生幻覺。
RAG 檢索器: 您可以將 RAG 流程打包成一個工具，讓代理自己決定何時需要查閱私有文件。
自訂工具 (Custom Tools): 透過 API 呼叫，連接到任何系統（例如：您的 CRM、ERP 或內部資料庫）。

記憶 (Memory) - 賦予 LLM 對話歷史

記憶模組讓 LLM 能夠記住對話的歷史，實現真正的「聊天機器人」而非「一問一答」。這在代理和 RAG 鏈中都至關重要。

緩衝記憶 (Buffer Memory)

機制: 一字不漏地儲存所有對話紀錄。

優點: 保真度最高，所有細節都在。

缺點: 當對話變長時，會很快超過 LLM 的 Token 上下文窗口限制 (Context Window)，導致成本高昂或 API 錯誤。

摘要記憶 (Summary Memory)

機制: 在背景呼叫 LLM 將長對話壓縮成一份摘要。

優點: 極度節省 Token，適合超長對話。

缺點: 成本更高（需要額外呼叫 LLM 進行摘要），且摘要過程可能遺失重要細節（資訊失真）。

低程式碼實作 (n8n + LangChain)

對於希望減少程式碼、專注於流程編排的開發者來說，n8n 提供了完美的低程式碼解決方案：

後端 (LangChain): 使用 Python 和 FastAPI（或 LangServe）將您複雜的 RAG 或代理邏輯打包成一個 API 端點。
前端/流程 (n8n): 使用 n8n 的視覺化節點（如 Webhook Trigger、HTTP Request、Slack）來呼叫這個 LangChain API，並編排整個自動化工作流程，無需編寫前端或流程控制程式碼。