Components
大規模言語モデル応用開発の3つの応用パターン：
- 直接対話モード：ユーザー入力を処理し、対応する回答を生成する
- 知識処理モード：テキスト文書を意味的に処理・保存・検索する
- ツール呼び出しモード：文脈に基づいて意思決定し、対応するツールを呼び出す
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() の2つのインターフェースでデータチャネルを作らなければならない。強力だがやや複雑である。
Einoはより使いやすいインターフェースの Chain をカプセル化した。Chain は Graph のラッパーであり、「環」（サイクル）以外では、Chain はほぼすべての Graph の能力を露出している。