本文にスキップ
AI News HubLIVE
サイト内リライト3 分で読了

LangGraphを使ったグラフエンジニアリング:3年間の経験

記事の要約

この記事は、LangChainチームがLangGraphを使ってエージェントシステムを構築してきた3年間の経験をまとめたものです。グラフエンジニアリングは新しい概念ではなく、信頼性の高いエージェントを構築するための確立されたアプローチです。いつグラフを使うべきか、避けるべきか、そして「エージェントグラフは通常DAGではない」、「ループは単純なグラフである」、「動的遷移が重要である」という重要な教訓について説明しています。

LangGraphを使ったグラフエンジニアリング:3年間の経験
誤りを報告

訂正窓口はまだ利用できません。記事情報をコピーして保存できます。

訂正案内
本文へ

「グラフエンジニアリング」という用語は、最近XのAIコンテンツファクトリーから生まれました。プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリング、ループエンジニアリングなどの用語と並んでいます。これらはバズワードと見なされることもありますが、ビルダーが直面する実際の課題や設計上の決定を表しています。

LangChainでは、3年間にわたりグラフを使用してエージェントシステムを構築してきました。私たちのフレームワークLangGraphは現在、月間6500万回以上ダウンロードされ、スタートアップや大企業に広く使用されています。その成功の鍵は、決定論的なパスと自律的なステップのバランスにあります。

エージェントをグラフとしてモデル化する

グラフは、エージェントが従うワークフローを具体的に定義する方法を提供します。LangGraphでは、ノードが作業を実行します。ノードは、決定論的なコード、単一のLLM呼び出し、ツール呼び出し、または内部ループを持つ完全なエージェントにすることができます。エッジは次に何が起こるかを定義し、一部は決定論的で、その他はノードの結果、現在の状態、または外部信号に基づいて条件付きです。これは本質的に状態機械です。

グラフを使用すべき時

現実世界のエージェントワークフローには、予測可能な構造がよくあります。サポートエージェントは回答やエスカレーションの前に問題を分類し、コーディングエージェントは変更を提案する前にリポジトリを検査し、コンプライアンスワークフローは外部アクションを実行する前に承認を必要とします。グラフを使用すると、モデルが選択できるポイントや、システムが決定論的な動作を強制する場所など、これらの構造を直接エンコードできます。

例えば、3つのサブエージェント(コード用GitHub、内部ドキュメント用Notion、関連スレッド用Slack)を使用するナレッジベースエージェントを考えます。ワークフローは分類、検索、統合の3つの固定段階を持ちます。これにより、コードとモデルの推論が連携し、モデルは価値を付加する場所で推論し、コードは残りを処理するため、エージェントはより安価で高速、かつ予測可能になります。

グラフを使用すべきでない時

一部のタスクは本質的により自律的であり、それらを決定論的なパスに強制することは誤りです。例えば、汎用的なディープリサーチ:研究エージェントは計画、委任、検索、読み取り、統合を事前に固めるのが難しい方法で行う必要があります。初期のディープリサーチは事前定義されたLangGraphワークフローで構築されていましたが、その後より自律的なコアループに移行しました。GPT Researcherも同様の移行を行いました。

LangGraph構築からの教訓

まず、エージェントグラフは通常DAGではありません。本番エージェントにはループが必要です:失敗したツール呼び出しの再試行、不足情報のユーザーへの問い合わせ、検証後の回答修正、十分なコンテキストが得られるまでのツールの繰り返し呼び出し、再開前の人間の入力待ち。ループはエージェントシステムのコア部分です。

次に、ループは単純なグラフです。ループエンジニアリングはグラフの代替ではなく、むしろ単純なバージョンです。

第三に、動的遷移が重要です。すべてのエッジを事前に定義したいとは限りません。ノードが実行時に作成する作業量を決定することがあります。Map-reduceが古典的なケースです:入力を断片に分割し、各断片をワーカーに送信し、結果を結合します。ワーカーの数は入力に依存し、事前に知ることはできません。LangGraphはSend機能でこれを処理し、ノードが静的にすべての遷移を定義することなく、動的に1つ以上の下流ノードに作業をルーティングできます。

実際に新しくなったこと

エージェントシステムをグラフとして表現することは新しいことではありません——私たちは3年間そうしてきました。今変わったのは、ノードに何を入れられるかです。初期はノードは決定論的なコードか単一のLLM呼び出しでした。現在ではエージェント自体が十分に信頼できるため、ノードは完全なエージェント実行にすることができます。つまり、LLM呼び出しだけでなくエージェントをオーケストレーションしています。コーディングエージェントは良い例であり、それらをより大きなグラフ内のノードとして埋め込むことは、新しく実用的なパターンです。

例えば、Slackリクエストをレビュー可能なプルリクエストに変換するドキュメントエージェントを考えます。このグラフの各ノードは、決定論的から自律的までのスケール上の異なるポイントに位置します:固定ステップはコードとAPI呼び出しによって駆動され、モデルステップはツールなしの単一LLM呼び出しを使用し、エージェントステップはより自由度の高い作業を完了します。この決定論と自律性の混合により、ドキュメントエージェントは予測可能で強力かつ効率的になります。

より大きなアイデア

グラフエンジニアリングは新しいアイデアではなく、信頼性の高いエージェントを構築するための確立されたアプローチに最新の名前をつけたものです。これはループエンジニアリングやハーネスエンジニアリングと同じ考え方です:適切な場所に、適切なコンテキストでモデルの推論を配置することです。グラフエンジニアリングを試してみたいなら、LangGraphを試してみてください。

要点と分析を開く

記事インテリジェンス

エンジニア上級

要点

  • グラフエンジニアリングは、エージェントのワークフローをグラフで表現し、決定論と自律性のバランスを取る手法です。
  • LangGraphは3年前にリリースされ、現在月間6500万回以上ダウンロードされ、スタートアップや大企業に採用されています。
  • エージェントグラフは通常DAGではなく、ループを含みます。ループは本質的に単純なグラフです。
  • 動的遷移(例:Map-reduce)により、ノードが実行時に下流の経路を決定でき、柔軟性が高まります。

要点と分析は自動生成され、誤りを含む場合があります。原典をご確認ください。