ジェネレーティブAIの分野は現在急速に進化しており、新しいフレームワークや技術が登場している。そのため、この記事で紹介する内容は最新のものである可能性があることを、読者は承知しておく必要がある。この記事では、LLMアプリケーションを構築するための2つの主要なフレームワーク、LangChainとLangGraphを詳しく見ていき、その長所と短所を分析することで、最適なツールを選択できるようにします。
LangChainとLangGraphファンデーションコンポーネント
両フレームワークの基本的な要素を理解することで、開発者は両フレームワークのコア機能の扱い方における重要な違いをより深く理解することができます。以下の説明は、それぞれのフレームワークのすべてのコンポーネントを列挙しているわけではありませんが、全体的な設計を明確に理解するためのものです。
ラングチェーン
LangChainは主に2つの方法で使うことができます:事前定義されたコマンドのシーケンシャルチェーン(Chain)とLangChain Agentです。Chainは予め定義された直線的なワークフローを使用し、Agentはコーディネータとして働き、よりダイナミックな(非直線的な)意思決定を行うことができます。
- チェーンLLM、エージェント、ツール、外部データソース、手続きコードへの呼び出しを含むことができるステップの組み合わせ。チェーンは、論理的な条件分岐に基づいて、1つのプロセスを複数のパスに分割することができる。
- エージェントまたはLLMLLM自体は自然言語による応答を生成することができますが、エージェントはLLMを推論、ツールの起動、失敗した場合のツールの起動を可能にする追加機能と組み合わせます。
- 工具エージェントが連鎖的に呼び出したり、トリガーして外部システムとやりとりするコード関数です。
- プロンプトシステムプロンプト(モデルがタスクを完了する方法と利用可能なツールを示す)、外部データソースから注入された情報(モデルにより多くのコンテキストを提供する)、およびユーザー入力タスクが含まれます。
ラングラフ
ラングラフ は、AIワークフローを構築するために異なるアプローチをとる。その名の通り、グラフとしてワークフローをオーケストレーションする。AIエージェント、手続き型コード、その他のツールの間で柔軟に対応できるため、線形チェーン、分岐チェーン、単純なエージェントシステムでは不十分な複雑なアプリケーションシナリオに適しています。LangGraphは、より複雑な条件ロジックやフィードバックループを扱えるように設計されており、LangChainよりも強力です。
- グラフLangGraphは循環グラフもサポートしており、特定のノードに何度もアクセスできるようなループやフィードバックの仕組みを作ることができる。
- ノードLLM クエリ、API 呼び出し、ツール実行などのワークフローのステップを示す。
- エッジと条件付きエッジエッジはノード間の接続に使われ、あるノードの出力が次のノードの入力として使われるように情報の流れを定義する。条件付きエッジは、特定の条件が満たされたときに、あるノードから別のノードに情報を流すことを可能にする。開発者はこれらの条件をカスタマイズできる。
- 州ステートは開発者定義の変数TypedDictオブジェクトで、グラフの現在の実行に必要なすべての関連情報を含んでいます。LangGraphは自動的に各ノードの状態を更新します。
- エージェントまたはLLMグラフ内のLLMは、入力に対するテキスト応答の生成のみを担当する。一方、エージェント機能は、グラフにエージェントの異なるコンポーネント(推論、ツールの選択、ツールの実行など)を表す複数のノードを含めることができます。エージェントは、グラフ内のどのパスを取るかを決定し、グラフの状態を更新し、テキスト生成だけでなく、より多くのタスクを実行できます。
つまり、LangChainは直線的でツールベースの呼び出しに適しており、LangGraphは複雑でマルチパス、フィードバック機構を持つAIワークフローに適している。
コア機能の処理方法におけるLangChainとLangGraphの違い
LangGraphとLangChainは、いくつかの機能が重複していますが、問題へのアプローチは異なります。LangChainは、(チェーンによる)直線的なワークフローや、さまざまなAIエージェントのパターンに重点を置いているのに対し、LangGraphは、AIエージェントを組み込むことができる、より柔軟で、きめ細かい、プロセスベースのワークフローを作成することに重点を置いています、ツール・コール、手続きコードなど
一般的に、LangChainはより抽象化されたカプセル化と事前定義されたコンフィギュレーションを提供するため、学習曲線が比較的低く、LangChainを単純な利用シナリオに適用するのが容易です。一方、LangGraphはワークフロー設計をより細かくカスタマイズできるため、抽象度が低く、効果的に使用するために開発者はより多くのことを学ぶ必要があります。
ツール・コール
ラングチェーン
LangChainでは、ツールの起動方法は、一連のステップがチェーン内で順次実行されるか、エージェント機能のみが使用されるか(チェーン内で明示的に定義されていない)に依存します。
- ツールは、チェーンの定義済みステップとして含まれます。これは、必ずしもエージェントによって動的に呼び出されるわけではなく、チェーンの設計時にどのツールを呼び出すかが決定されることを意味します。
- エージェントがチェーンで定義されていない場合、エージェントはより自律性を持ち、アクセスできるツールのリストに基づいて、どのツールをいつ呼び出すかを決定することができます。
チェーン・アプローチのプロセス例:
Agentメソッドの流れの一例です:
ラングラフ
LangGraphでは、ツールは通常グラフ上のノードとして表現される。グラフにAgentが含まれている場合、Agentは推論能力に基づいてどのツールを呼び出すかを決定します。エージェントがツールを選択すると、ワークフローは対応するツールノードにジャンプし、ツールの操作を実行する。AgentとTool Node間のエッジは、ツールを実行するか否かを決定するための追加の判断ロジックを追加するConditional Logicを含むことができる。このようにして、開発者はよりきめ細かい制御を行うことができます。グラフ内に Agent が存在しない場合、ツールは LangChain チェーンと同様の方法で呼び出されます。つまり、ツールは定義済みの Conditional Logic に基づいてワークフロー内で実行されます。
Agentのダイアグラムの流れの例が含まれています:
エージェントを含まないダイアグラムのフローの例:
歴史と記憶に関する対話
ラングチェーン
LangChainは、会話履歴とメモリを扱うための組み込みの抽象化レイヤーを提供します。異なる粒度レベルでのメモリ管理をサポートし、会話履歴の量を制御します。 トークン 主に以下のような方法で:
- フルセッションの会話履歴(Full session conversation history)
- 会話履歴の要約版
- カスタム定義メモリ(CDM)
さらに、開発者は長期記憶システムをカスタマイズして、対話の履歴を外部データベースに保存し、必要なときに関連する記憶を取り出すことができる。
ラングラフ
LangGraphでは、Stateはメモリを管理する役割を担っており、各時点で定義された変数を記録することで、状態情報を管理している:
- 歴史との対話
- マンデート実施のステップ
- 言語モデルの最後の出力
- その他の重要情報
各ノードがシステムの現在の状態にアクセスできるように、ノード間で状態を受け渡すことができます。しかし、LangGraph自身はセッションをまたいだ長期的な記憶を提供しません。 もし開発者が記憶を持続的に保存する必要がある場合、外部のデータベースに記憶や変数を保存するための特定のノードを導入し、その後の検索に利用することができます。
すぐに使えるRAG機能
ラングチェーン
LangChainは複雑な ラグ ワークフローを提供し、開発者のアプリケーションへのRAGの統合を促進する洗練されたツール群を提供します。例えば
- ドキュメントの読み込み
- テキスト解析
- エンベデッド・クリエーション
- ベクトルストレージ
- 検索能力(検索能力)
開発者はLangChainが提供するAPI(例えば langchain.document_loaders
そしてラングチェーン埋め込み
歌で応える ラングチェーン・ベクトルストア
)を使ってRAGワークフローを実装する。
ラングラフ
LangGraphでは、RAGは開発者が設計し、グラフ構造の一部として実装する必要があります。例えば、開発者はそれぞれ別のノードを作ることができます:
- 文書解析
- 埋め込み計算 (埋め込み計算)
- セマンティック検索(検索)
これらのノードは、ノーマルエッジまたは条件付きエッジによって互いに接続することができ、個々のノードの状態は、RAGパイプラインの異なるステップ間でデータを共有するために情報を渡すために使用することができる。
パラレリズム
ラングチェーン
LangChainでは、複数のチェーンやエージェントを並列実行することができます。 実行可能パラレル
クラスを使って基本的な並列処理を実装する。
しかし、より高度な並列計算や非同期ツール呼び出しが必要な場合、開発者は以下のようなPythonライブラリを使用する必要があります。 アシンシオ
) 自己実施。
ラングラフ
LangGraphは、ノード間に依存関係がない限り(例えば、あるLLMの出力を次のLLMの入力として使うことはできない)、ノードの並列実行を自然にサポートします。つまり、相互依存ノードでなければ、複数のエージェントを同時に実行することができます。
LangGraphもサポート:
- 利用する
実行可能パラレル
複数グラフの実行 - Pythonの
アシンシオ
ライブラリ並列呼び出しツール
再試行ロジックとエラー処理
ラングチェーン
LangChainのエラー処理は、開発者が明示的に定義する必要がある:
- チェーンにおけるリトライ・ロジックの導入(リトライ・ロジック)
- エージェントにおけるツールコールの失敗の処理
ラングラフ
LangGraphはエラー処理を別のノードにすることで、エラー処理ロジックをワークフローに直接埋め込むことができます。
- タスクが失敗した場合、別のエラー処理ノードにジャンプするか、現在のノードで再試行することができる。
- 失敗したノードは、ワークフロー全体が再実行されるのではなく、個別に再試行される。
- こうすることで、ダイアグラムは最初からやり直すことなく、障害発生時点から実行を継続することができる。
タスクに複数のステップやツールの呼び出しが含まれる場合、このエラー処理メカニズムは非常に重要になる。
LangChainとLangGraphのどちらを選ぶか?
開発者はできる:
- LangChainのみを使用
- LangGraphのみを使用
- LangChainとLangGraphの併用
LangGraphのグラフ構造化機能を、MicrosoftのAutoGenのような他のAgentフレームワークと組み合わせることも可能です。 オートジェン LangGraphのノードとしてのエージェント。
LangChainとLangGraphにはそれぞれ利点があり、適切なツールを選択することは混乱を招く。
いつLangChainを選ぶか?
開発者がAIワークフローを迅速に構築する必要がある場合、次のような状況でLangChainをご検討ください:
- 線形タスク文書検索、テキスト生成、要約などのための定義済みワークフロー。
- AIエージェントはダイナミックな意思決定を必要とするしかし、複雑なプロセスを細かく制御する必要はない。
ラングラフを選ぶとき?
アプリケーションのシナリオがノンリニア(直線的でない)ワークフローを必要とする場合、LangGraphを次のような状況でご検討ください:
- このタスクには、複数のコンポーネントの動的な相互作用が含まれる。
- 条件判断、複雑な分岐ロジック、エラー処理、並列実行が必要。
- 開発者は、LangChainが提供しない機能の一部を独自に実装することを望んでいる。
LangChainとLangGraphは、どのような場合に併用すべきですか?
LangChainの容易に利用できる抽象化機能(RAGコンポーネント、ダイアログ・メモリなど)とLangGraphの非線形オーケストレーション機能の両方を利用したい場合、両方の利用を検討することができる。
両者を組み合わせることで、それぞれの強みを最大限に活用し、より柔軟で強力なAIワークフローを構築することができる。