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

エージェントフレームワークの考え方

記事の要約

この記事では、信頼性の高いAIエージェントを構築する上での課題を探り、ワークフローとエージェント、宣言型と命令型のアプローチを比較し、コンテキスト制御の重要性を強調します。

エージェントフレームワークの考え方
誤りを報告

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

訂正案内
本文へ

信頼性の高いエージェントシステムを構築するのは簡単ではありません。プロトタイプを作るのは比較的容易ですが、ビジネスクリティカルなアプリケーションを支える信頼性の高いエージェントを作るには多大な労力が必要です。LangChainチームがエージェント構築者を対象に行った調査では、「パフォーマンス品質」がエージェントを本番環境に導入する上での最大の制限要因であることが明らかになりました。では、なぜエージェントは時としてパフォーマンスが悪いのでしょうか。その原因はLLMのミスにあります。LLMがミスをする理由は主に二つです。(a) モデル自体が十分に優れていない、(b) モデルに間違った(または不完全な)コンテキストが渡されている。経験上、後者のケースが非常に頻繁に発生します。

コンテキストの欠如は、システムメッセージが短すぎる、ユーザー入力が曖昧、適切なツールにアクセスできない、ツールの説明が不十分、正しいコンテキストを渡していない、ツールの応答形式が悪いなど、さまざまな要因で起こります。したがって、信頼性の高いエージェントシステムを構築する上での核心的な難しさは、各ステップでLLMに適切なコンテキストを確実に与えることです。これには、LLMに入力する内容を正確に制御することと、関連するコンテンツを生成するための適切なステップを実行することの両方が含まれます。LLMに渡す内容の制御を難しくするフレームワークは、開発者の足を引っ張るだけです。

エージェントシステムはエージェントだけではありません。Anthropicの定義はより precise です。エージェントシステムにはワークフローとエージェントが含まれます。ワークフローとは、LLMとツールが事前定義されたコードパスを通じてオーケストレーションされるシステムです。一方、エージェントとは、LLMが自身のプロセスとツールの使用を動的に指示し、タスクの達成方法を制御するシステムです。Anthropicはこれらを総称して「エージェントシステム」と呼び、本番環境のエージェントシステムのほとんどがワークフローとエージェントの組み合わせであると指摘しています。OpenAIの定義はより曖昧で、「あなたの代わりにタスクを独立して達成するシステム」としていますが、これはむしろ思想的リーダーシップであり、実用的な定義ではありません。

実際には、何かがエージェントであるかどうかを二分するのではなく、システムの「エージェント性」の度合いに注目する方が有用です。Andrew Ngが述べたように、形容詞「エージェント的」を使うことで、システムをさまざまな程度のエージェント性で捉えることができます。ワークフローとエージェントは相互排他的ではなく、連続的なスペクトル上の異なる点です。ほとんどの本番システムはその中間に位置します。

エージェントシステムを構築する際には、二つの重要なトレードオフを考慮する必要があります。予測可能性とエージェント性、そして低い参入障壁と高い天井です。システムのエージェント性が高まるにつれて、予測可能性は低下します。ユーザーの信頼や規制上の理由から、システムの予測可能性が必要な場合もあります。信頼性は予測可能性と完全に一致するわけではありませんが、実際には密接に関連しています。アプリケーションに応じてスペクトル上の位置を決定する必要があります。LangGraphは、この曲線上の任意の位置にアプリケーションを構築できるため、理想的なポイントに移動するのに役立ちます。

フレームワークの参入障壁と天井も考慮すべきです。低い参入障壁のフレームワークは初心者に優しく、すぐに使い始められます。高い参入障壁のフレームワークは学習曲線が急で、効果的に使用するには専門知識が必要です。低い天井のフレームワークは能力が限定され、すぐに限界を迎えます。高い天井のフレームワークは、高度なユースケースに対応する広範な機能と柔軟性を提供します。ワークフローフレームワークは通常、天井は高いが参入障壁も高く、エージェントロジックの多くを自分で書く必要があります。一方、エージェントフレームワークは参入障壁が低い代わりに天井も低い傾向があります。

LangGraphはイベント駆動型のオーケストレーションフレームワークであり、宣言型と命令型の両方のAPIを提供し、低レベルのフレームワーク上に一連のエージェント抽象化を構築しています。主な使用方法は二つあります。宣言型のグラフベースの構文と、低レベルフレームワーク上に構築されたエージェント抽象化です。LangGraphは関数型APIと基盤となるイベント駆動型APIもサポートし、Python版とTypeScript版の両方が存在します。エージェントシステムはノードとエッジで表現できます。ノードは作業単位を表し、エッジは遷移を表します。ノードとエッジは通常のPythonまたはTypeScriptコードであるため、グラフの構造は宣言的に表現されますが、グラフ内のロジックは通常の命令型コードです。エッジは固定または条件付きにでき、パスは完全に動的にできます。

LangGraphには永続化層が組み込まれており、フォールトトレランス、短期記憶、長期記憶を可能にします。この永続化層により、「ヒューマン・イン・ザ・ループ」や「ヒューマン・オン・ザ・ループ」のパターン(中断、承認、再開、タイムトラベルなど)も可能になります。LangGraphはトークン、ノード更新、任意のイベントのストリーミングを組み込みでサポートします。LangGraphはLangSmithとシームレスに統合され、デバッグ、評価、可観測性を容易にします。

まとめると、エージェントフレームワークは多種多様であり、比較する際にはワークフローとエージェント、宣言型と非宣言型、エージェント抽象化、マルチエージェントなど、複数の軸を区別する必要があります。ほとんどのフレームワークは真のオーケストレーションフレームワークではなく、単にエージェント抽象化を提供しているに過ぎません。これらの軸を理解することで、適切なツールを選択するのに役立ちます。Anthropicが推奨するように、LLMアプリケーションを構築する際には最もシンプルなソリューションを探し、必要な場合にのみ複雑さを増すべきです。エージェントシステムを構築する必要がない場合もあります。エージェントシステムは通常、レイテンシとコストを犠牲にしてタスクパフォーマンスを向上させるため、そのトレードオフが妥当かどうかを検討する必要があります。明確に定義されたタスクにはワークフローが予測可能性と一貫性を提供し、柔軟性とモデル駆動型の意思決定が求められる大規模なシナリオではエージェントが適しています。

要点と分析を開く

記事インテリジェンス

エンジニア上級

要点

  • 信頼性の高いエージェントシステムを構築する難しさは、各ステップでLLMに適切なコンテキストを確実に与えることにあります。
  • エージェントシステムにはワークフローとエージェントの両方が含まれ、本番環境のシステムは通常その組み合わせです。
  • エージェントフレームワークは多くの場合、宣言型や命令型のオーケストレーションフレームワークではなく、単なるエージェント抽象化の集合であり、コンテキスト制御を曖昧にすることがあります。
  • LangGraphは宣言型と命令型の両方のAPIを備えたオーケストレーションフレームワークであり、エージェント抽象化が組み込まれています。

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