LangGraphの ノード・エッジ・ルーティングを深堀り 2024/05/25 第35回勉強会

自己紹介 ● 名前: 西岡 賢一郎 ○ 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) ○ 自社および他社のプロダクト開発チーム・データサイエンスチームの立ち上げ経験

はじめに 本日の発表内容 ● LangGraphを構成する要素を一つ一つ深堀りする ● ノード・エッジ・ルーティングを中心にデモを使って紹介

LangGraphを何故学ぶのか ● 2024/05/10にLangChain v0.2がPrerelease ○ https://blog.langchain.dev/langchain-v02- leap-to-stability/ ● 記事の中でLangGraphについて言及 ○ 旧AgentExecutorは引き続き利用可能。 ○ LangGraphが推奨されるエージェント構築方 法に。 ○ AgentExecutorに相当するプレビルト LangGraphオブジェクトで、カスタマイズが 容易に。

LangGraphについて改めて復習 ● LangGraphは、LLMを使って状態を持つマルチアクターアプリケーションを 構築するためのライブラリ ● Pregel、Apache Beamにインスパイアされ、NetworkXライクなインター フェイス ● 主な用途は、LLMアプリケーションに循環と永続性を追加すること ● 単純なDAGはLangChain Expression Language(LCEL)で実現可能 ● 単純なアプリを構築するのは簡単だが、ハマりどころがたくさんある。。

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

Graph ● LangGraphにおけるワークフローの中心的な表現方法で、ノードとエッジで 構成される ● グラフはステートマシンとして機能し、共有状態を持つマルチアクターのア プリケーションを柔軟に構築可能 ● グラフの主要コンポーネント: ○ State (状態): グラフの実行中に共有されるデータを表現 ○ Node (ノード): 状態を処理する基本的な構成要素で、Python関数またはRunnableとして定義 ○ Edge (エッジ): ノード間の接続を表現し、実行の流れを制御 ● 汎用的なStateGraphと簡単に利用できるMessageGraph

Graphの種類の推移 ● Graph自体も大きく分けて3種類存在する ● StateGraph ○ nodeやedgeの追加ができる ○ CompileするとCompiledStateGraphに変換で きる ● CompiledStateGraph ○ Workflowを実行できる ○ Runnable Interfaceに対応 ○ get_graphでDrawableGraphに変換できる ● DrawableGraph ○ グラフを描画できる

LangGraphのState ● LangGraphにおける中心的な概念で、グラフの実行中に共有 されるデータを表現 ● 各ノードは状態を受け取り、処理後に更新された状態を返す (Returnを定義せずStateを更新しない場合もある) ● Stateは通常、TypedDictまたはPydantic BaseModelとして 定義されるが、ほぼ任意の型を使用可能 ● reducer は、ノードの出力を現在の状態に適用する方法を定 義 ○ 状態フィールドにreducer関数を注釈 (annotation) 付 けすることで、データフローを正確に制御可能 ● 共有状態の使用には、グローバル変数と同様の設計上のト レードオフがある ○ 予期しない副作用、変更の追跡の難しさ、テストの複 雑化、並行処理のバグなどのリスクがある ● ただし、LangGraphの共有状態には以下の利点がある ○ 型付きの状態により、各スーパーステップの前後で データフローを完全に検査可能 ○ ミュータブルな状態により、ユーザーや他のソフト ウェアがスーパーステップ間で状態を更新可能 ○ チェックポイント時に明確に定義されているため、 ワークフロー全体の実行を保存、再開、バージョン管 理が容易

Node ● グラフの基本的な構成要素で、状態を処理する役割を持つ ● 通常は、状態を入力として受け取り、処理を行い、更新された状態を返す Python関数またはRunnableとして定義 ● ノードは同期的にも非同期的にも実装可能 ● ノードの第1引数は状態 (state)、第2引数 (オプション) は設定 (config) を受 け取る ● add_node メソッドを使って、ノードをグラフに追加 ● 内部的には、関数はバッチ処理、非同期サポート、トレース、デバッグ機能 を備えたRunnableLambdaに変換される

Nodeの実行結果 (Return) ● 各ノードの処理結果を表現し、グラフの共有状態をどのように更新するかを指定 ● ノードの返り値は、状態の特定の属性を上書き (SET) するか、既存の属性に追加 (ADD) する操作を表す ● Reducer関数は、ノードの返り値を現在の状態に適用する方法を定義 ((Value, Value) -> Value) ● ノードが返り値を省略した場合、状態は変更されず、現在の状態がそのまま次の ノードに渡される ● すべてのノードが値を返す必要はない (外部システムの変更のみするノードなど) ● ノードの返り値は、グラフの状態の型と互換性がある必要がある ● 複数のノードが同じ状態属性を更新する場合、Reducer関数が更新の競合を解決

Edge ● ノード間の接続を表現し、実行の流れを制御する ● 現在の状態を受け取り、遷移先のノードを決定する値を返す ● デフォルトでは、エッジの出力値は次に実行するノードの名前 ● 条件付きエッジ (Conditional Edge) を使って、状態に応じて遷移先を動的に 決定可能 ○ add_conditional_edges メソッドを使って、条件付きエッジを追加 ○ 条件付きエッジは、現在の状態を入力とし、次のノードの名前または終了を示す特別な値を 返す関数として定義 ● 通常のエッジは、特定のノードから別のノードへの無条件の遷移を表現 ○ add_edge メソッドを使って、エッジを追加 ● 1つのノードが複数の出力エッジを持つ場合、宛先ノードは並列に実行され る (次のスーパーステップ)

デモ ● デモ内容 ○ 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