Components
大模型應用開發的三種應用模式：
- 直接對話模式：處理使用者輸入並生成相應回答
- 知識處理模式：對文本文檔進行語義化處理、儲存和檢索
- 工具呼叫模式：基於上下文做出決策並呼叫相應工具
Eino將常用能力抽象為可複用的組件（Components）
組件抽象和幾種模式對應關係如下：
對話處理類組件：
- 模組化處理和大模型交互參數的組件抽象：
ChatTemplate - 直接和大模型交互的組件抽象：
ChatModel
文本語義處理類組件：
- 獲取和處理文本文檔的組件抽象：
Document.Loader、Document.Transformer - 文本文檔語義化處理的組件抽象：
Embedding - Embedding之後將資料索引進行儲存的組件抽象：
Indexer - 將語義相關文本文檔進行索引和召回的組件抽象：
Retriever
決策執行類組件：
大模型能夠做決策並呼叫工具的組件抽象：ToolsNode
自訂組件：
使用者自訂程式邏輯的組件抽象：Lambda
Eino的組件抽象秉持著以下設計原則：
- 模組化和標準化：將一系列功能相同的能力抽象成統一的模組，組件間職能明確、邊界清晰，支援靈活的組合。
- 可擴展性，介面的設計保持盡可能小的模組能力約束，讓組件的開發者能方便地實現自訂組件的開發。
- 可複用性，把最常用的能力和實作進行封裝，提供給開發者開箱即用的工具使用。
Chain & Graph 編排功能
編排：對Components原子能力進行組合、串聯。
- 不能讓業務邏輯融入到編排中。
- 大模型應用的核心是 「對提供原子能力的組件」 進行組合串聯，組件是編排的 「第一公民」。
- 抽象視角看編排：編排是在構建一張網路，資料則在這個網路中流動，網路的每個節點都對流動的資料有格式/內容的要求，一個能順暢流動的資料網路，關鍵就是 「上下游節點間的資料格式是否對齊？」。
- 業務場景的複雜度會反映在編排產物的複雜性上，只有橫向的治理能力才能讓複雜場景不失控。
- 大模型是會持續保持高速發展的，大模型應用也是，只有具備擴展能力的應用才擁有生命力。
Eino提供了基於Graph模型（edge+node）的，以組件為原子節點的，以上下游類型對齊為基礎的編排解決方案。
- 以組件為核心，規範了業務功能的封裝方式。
- 業務邏輯複雜度封裝到組件內部，編排層擁有更全域的視角，讓邏輯層次變得清晰。
- 提供了切面能力，callback機制支援了基於節點的統一治理能力（什麼是切面能力）
- 提供了call option的機制，擴展性是快速迭代中的系統最基本的訴求
- 提供了「類型對齊」的開發方式的強化，降低開發者心智負擔，把golang的類型安全特性發揮出來
- 提供了「流的自動轉換」能力，讓「流」在編排系統的複雜性來源榜中除名（Eino流式編程）
Graph缺點：基於 「點」 「邊」 模型的 Graph 在使用時，要求開發者要使用 graph.AddXXXNode() 和 graph.AddEdge() 兩個介面來建立一個資料通道，強大但是略顯複雜。
Eino 封裝了介面更易於使用的 Chain。Chain 是對 Graph 的封裝，除了 「環」 之外，Chain 暴露了幾乎所有 Graph 的能力。