LangGraphのノード・エッジ・ルーティングを深堀り

機械学習の社会実装勉強会第25回 (https://machine-learning-workshop.connpass.com/event/319050/) の発表資料です。

Transcript

1. LangGraphの ノード・エッジ・ルーティングを深堀り 2024/05/25 第35回勉強会
2. 自己紹介 • 名前: 西岡 賢一郎 ◦ Twitter: @ken_nishi ◦ note: https://note.com/kenichiro ◦ YouTube: 【経営xデータサイエンスx開発】西岡 賢一郎のチャンネル (https://www.youtube.com/channel/UCpiskjqLv1AJg64jFCQIyBg) • 経歴 ◦ 東京大学で位置予測アルゴリズムを研究し博士 (学術) を取得 ◦ 東京大学の博士課程在学中にデータサイエンスをもとにしたサービスを提供する株式会社ト ライディアを設立 ◦ トライディアを別のIT会社に売却し、CTOとして3年半務め、2021年10月末にCTOを退職 ◦ CDPのスタートアップ (Sr. PdM)・株式会社データインフォームド (CEO)・株式会社ディース タッツ (CTO) ◦ 自社および他社のプロダクト開発チーム・データサイエンスチームの立ち上げ経験
3. はじめに 本日の発表内容 • LangGraphを構成する要素を一つ一つ深堀りする • ノード・エッジ・ルーティングを中心にデモを使って紹介
4. LangGraphを何故学ぶのか • 2024/05/10にLangChain v0.2がPrerelease ◦ https://blog.langchain.dev/langchain-v02- leap-to-stability/ • 記事の中でLangGraphについて言及 ◦ 旧AgentExecutorは引き続き利用可能。 ◦ LangGraphが推奨されるエージェント構築方 法に。 ◦ AgentExecutorに相当するプレビルト LangGraphオブジェクトで、カスタマイズが 容易に。
5. LangGraphについて改めて復習 • LangGraphは、LLMを使って状態を持つマルチアクターアプリケーションを 構築するためのライブラリ • Pregel、Apache Beamにインスパイアされ、NetworkXライクなインター フェイス • 主な用途は、LLMアプリケーションに循環と永続性を追加すること • 単純なDAGはLangChain Expression Language(LCEL)で実現可能 • 単純なアプリを構築するのは簡単だが、ハマりどころがたくさんある。。
6. LCEL • LangChain Expression Language (LCEL) とは ◦ 宣言的な方法でチェーンを簡単に構成でき る言語 ◦ 最もシンプルな「プロンプト + LLM」 チェーンから最も複雑なチェーンまで対応 ◦ コードを変更せずにプロトタイプを本番環 境に導入可能 • LCELの主な機能 ◦ ファーストクラスのストリーミングサポー ト ◦ 非同期サポート ◦ 最適化された並列実行 ◦ リトライとフォールバック ◦ 中間結果へのアクセス ◦ 入力と出力のスキーマ ◦ シームレスなLangSmithトレース ◦ シームレスなLangServerデプロイメント from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI model = ChatOpenAI() prompt = ChatPromptTemplate.from_template("tell me a joke about {topic}") # LCELを使ってチェーンを構成 chain = prompt | model
7. Graph • LangGraphにおけるワークフローの中心的な表現方法で、ノードとエッジで 構成される • グラフはステートマシンとして機能し、共有状態を持つマルチアクターのア プリケーションを柔軟に構築可能 • グラフの主要コンポーネント: ◦ State (状態): グラフの実行中に共有されるデータを表現 ◦ Node (ノード): 状態を処理する基本的な構成要素で、Python関数またはRunnableとして定義 ◦ Edge (エッジ): ノード間の接続を表現し、実行の流れを制御 • 汎用的なStateGraphと簡単に利用できるMessageGraph
8. Graphの種類の推移 • Graph自体も大きく分けて3種類存在する • StateGraph ◦ nodeやedgeの追加ができる ◦ CompileするとCompiledStateGraphに変換で きる • CompiledStateGraph ◦ Workflowを実行できる ◦ Runnable Interfaceに対応 ◦ get_graphでDrawableGraphに変換できる • DrawableGraph ◦ グラフを描画できる
9. LangGraphのState • LangGraphにおける中心的な概念で、グラフの実行中に共有 されるデータを表現 • 各ノードは状態を受け取り、処理後に更新された状態を返す (Returnを定義せずStateを更新しない場合もある) • Stateは通常、TypedDictまたはPydantic BaseModelとして 定義されるが、ほぼ任意の型を使用可能 • reducer は、ノードの出力を現在の状態に適用する方法を定 義 ◦ 状態フィールドにreducer関数を注釈 (annotation) 付 けすることで、データフローを正確に制御可能 • 共有状態の使用には、グローバル変数と同様の設計上のト レードオフがある ◦ 予期しない副作用、変更の追跡の難しさ、テストの複 雑化、並行処理のバグなどのリスクがある • ただし、LangGraphの共有状態には以下の利点がある ◦ 型付きの状態により、各スーパーステップの前後で データフローを完全に検査可能 ◦ ミュータブルな状態により、ユーザーや他のソフト ウェアがスーパーステップ間で状態を更新可能 ◦ チェックポイント時に明確に定義されているため、 ワークフロー全体の実行を保存、再開、バージョン管 理が容易
10. Node • グラフの基本的な構成要素で、状態を処理する役割を持つ • 通常は、状態を入力として受け取り、処理を行い、更新された状態を返す Python関数またはRunnableとして定義 • ノードは同期的にも非同期的にも実装可能 • ノードの第1引数は状態 (state)、第2引数 (オプション) は設定 (config) を受 け取る • add_node メソッドを使って、ノードをグラフに追加 • 内部的には、関数はバッチ処理、非同期サポート、トレース、デバッグ機能 を備えたRunnableLambdaに変換される
11. Nodeの実行結果 (Return) • 各ノードの処理結果を表現し、グラフの共有状態をどのように更新するかを指定 • ノードの返り値は、状態の特定の属性を上書き (SET) するか、既存の属性に追加 (ADD) する操作を表す • Reducer関数は、ノードの返り値を現在の状態に適用する方法を定義 ((Value, Value) -> Value) • ノードが返り値を省略した場合、状態は変更されず、現在の状態がそのまま次の ノードに渡される • すべてのノードが値を返す必要はない (外部システムの変更のみするノードなど) • ノードの返り値は、グラフの状態の型と互換性がある必要がある • 複数のノードが同じ状態属性を更新する場合、Reducer関数が更新の競合を解決
12. Edge • ノード間の接続を表現し、実行の流れを制御する • 現在の状態を受け取り、遷移先のノードを決定する値を返す • デフォルトでは、エッジの出力値は次に実行するノードの名前 • 条件付きエッジ (Conditional Edge) を使って、状態に応じて遷移先を動的に 決定可能 ◦ add_conditional_edges メソッドを使って、条件付きエッジを追加 ◦ 条件付きエッジは、現在の状態を入力とし、次のノードの名前または終了を示す特別な値を 返す関数として定義 • 通常のエッジは、特定のノードから別のノードへの無条件の遷移を表現 ◦ add_edge メソッドを使って、エッジを追加 • 1つのノードが複数の出力エッジを持つ場合、宛先ノードは並列に実行され る (次のスーパーステップ)
13. デモ • デモ内容 ◦ LCELとRunnable Interface ◦ StateGraph → CompiledStateGraph → DrawableGraphの変換 ◦ Stateの更新 ◦ Conditional Edgeを使ったRouting ◦ Multiple Edgeを使ったRouting ◦ Reducer関数によるStateの更新 • ソースコード ◦ https://github.com/knishioka/machine-learning-workshop/blob/main/langchain/Lang Graph%20Node%2C%20Edge%2C%20Routing.ipynb