8,976 文字
私はこれからエージェントの効果的な作り方についてお話しします。Claudeファミリーのモデルを開発したAnthropicが、効果的なモデルの構築方法に関する多くの情報を公開しました。私はそれを読み、実際にとても良い内容だと感じました。一緒に内容を見ていきましょう。また、私自身も多くのエージェントを構築してきた経験から、私の考えもお伝えしていきます。
このビデオは、最新のNVIDIAチップで生成AIスタートアップをパワーアップする最も簡単な方法を提供するVultureがスポンサーです。詳細は説明欄のリンクをご確認ください。
これは約1週間前に公開されたブログ記事「効果的なエージェントの構築」についてです。まず最初に、エージェントを構築するために複雑なフレームワークは必要ないと述べています。それは事実です。ChatGPTのカスタムGPTを見てください。それらは実質的にエージェントです。パーソナリティを選び、役割を選び、ツールを与え、メモリを与える。それが私の考えるエージェントの最も基本的な形態です。
私個人的にはCrew AIを使用しています。私は投資家としても関わっているので当然使用していますが、彼らが最高のエージェントフレームワークだと考えています。単一のエージェントを定義する以上の洗練された機能が必要な場合、エージェントフレームワークは非常に強力です。これらのエージェントフレームワークは日々進化しており、彼らが具体的に述べているのは、最も成功している実装は複雑なフレームワークや特殊なライブラリを使用せず、シンプルで組み合わせ可能なパターンを構築していたということです。
これらのエージェントフレームワークが成熟するにつれて、その中から1つを選択することになるでしょう。毎回ゼロから車輪を再発明したくはありませんし、毎回最適なパターンを見つけ出そうとしたくもありません。それがフレームワークの存在意義です。だからこそ、私たちはコードのためのフレームワークを永きにわたって持ってきたのです。
次に彼らはエージェントとは何かについて説明します。多くの人々がエージェントに対して異なる定義を持っています。私個人的には、エージェントは本質的にコアとなるLLM、つまりメモリ、ツール、そして他のエージェントと協力する能力を備えた知性だと考えています。
Anthropicは、一部の顧客はエージェントを、様々なツールを使用して複雑なタスクを遂行する、長期間にわたって独立して動作する完全に自律的なシステムとして定義していると述べています。また、他の顧客は事前定義されたワークフローに従うより規範的な実装を指す用語として使用しています。
Anthropicでは、これらの全ての変種をエージェントシステムとして分類していますが、ワークフローとエージェントの間に重要なアーキテクチャ上の区別を設けています。ワークフローは、LLMとツールが事前定義されたコードパスを通じて制御されるシステムです。一方、エージェントは、LLMが自身のプロセスとツールの使用を動的に指示し、タスクの達成方法を制御するシステムです。
最高のエージェントフレームワークは、ワークフローとエージェントの境界線を曖昧にします。エージェントシステムには、より構造化された部分が必要で、事前定義されたコードを使ってエージェントを支援したい部分があります。そして、エージェントに考えさせ、創造させ、他のエージェントと協力して最適な解決策を見つけ出させたい部分もあります。先ほど述べたように、最高のエージェントフレームワークは、この境界線を本当に曖昧にするか、単一のユースケースで両方を簡単に使用できるようにします。
次に、エージェントをいつ使用し、いつ使用しないかについて説明します。最初の文章に私は完全に同意します。LLMを使用してアプリケーションを構築する場合、可能な限り最もシンプルなソリューションを見つけ、必要な場合にのみ複雑さを増やすことを推奨します。これは非常に重要で、エージェントだけでなく、コードにも、人生の教訓としても当てはまります。システムを構築する際は、最もシンプルな実装から始め、必要な場合にのみ複雑さを追加するべきです。
エージェントシステムは、より良いタスクパフォーマンスのために、レイテンシーとコストをトレードオフすることが多く、このトレードオフがいつ意味を持つかを検討する必要があります。エージェントの使用がより洗練され複雑になればなるほど、より多くのトークンを使用し、より多くの時間がかかります。
このレイテンシーとコストの解決も、エージェントシステムで取り組むことができます。これが私がGroにも投資している理由です。彼らは非常に安価で信じられないほど高速な推論速度を持っています。そのため、それをエージェントシステムに組み込むと、機能のレイテンシーとコストの部分はそれほど重要ではなくなります。
彼らは重ねて言います。ワークフローは明確に定義されたタスクに対して予測可能性と一貫性を提供し、一方でエージェントは柔軟性とモデル駆動の意思決定が必要な場合により良い選択肢となります。
そして、フレームワークをいつどのように使用するかについて説明します。LangChainのLang Graph、BedrockのAIエージェントフレームワーク、Rivet、Vellumなどについて触れています。なぜCrewに言及しなかったのか不思議です。Crewは基本的に最大のフレームワークですが、まあいいでしょう。
また、フレームワークを使用する理由についても説明しています。それらは抽象化のレイヤーを提供し、多くの組み込みツールを備えており、基本的には事前定義されたゴールデンパスです。もちろんフレームワークを学ぶ必要はありますが、進めながら多くの付随的な問題について考える必要がないのです。
もちろん、エージェントフレームワークを使用することにはデメリットもあります。それらは多くの場合、基礎となるプロンプトとレスポンスを不明瞭にする余分な抽象化レイヤーを作成し、デバッグを困難にします。また、そうすることが非常に簡単なため、不必要な場合でも複雑さを追加する誘惑に駆られやすくなります。
それでは、かなりシンプルなものから始めて、エージェントシステムがどのように見えるかの例を見ていきましょう。Anthropicは特に、問題がこれほどシンプルな場合、彼らのコアモデル、つまりベースモデルには、追加のフレームワークを必要とせずに問題を解決するために必要な全ての機能が備わっていると述べています。
ここで見ているのは、まずプロンプトがあり、そしてLLMがあります。LLM（Claudeファミリーのモデル）は検索結果を取得する能力（検索）、ツールを使用する能力、そしてメモリを持っています。そして出力があります。必要なものを決定した後、出力を提供します。
これらのベースモデルは日々向上しており、実際にはモデルプロバイダーがより多くのエージェント機能を直接そのベースモデルに組み込んでいることを意味します。これは良いことです。
これについてはあまり触れませんでしたが、Anthropicからのリリースがありました。ちなみにAnthropicは最近完全に絶好調です。彼らはModel Context Protocolと呼ばれるものをリリースしました。これはLLMがサードパーティのツールと対話するためのフレームワークで、本質的にその方法を定義するものです。
ここでは、シンプルなクライアント実装で成長するサードパーティツールのエコシステムと統合できるようにすると説明しています。
次にワークフローを見てみましょう。これはプロンプトチェーニングのためのワークフローです。少し読んでみましょう。プロンプトチェーニングは、タスクを一連のステップに分解し、各LLM呼び出しが前のステップの出力を処理します。中間ステップにプログラムによるチェックを追加して、プロセスが正しく進行していることを確認できます。
これは良さそうですが、なぜ必要なのでしょうか？説明する最良の方法は、複雑で本当にモジュール化できる部分に分解できる状況がある場合です。モデルにこの複数ステップのタスクを一度で達成させようとすると、基本的には同じ品質は得られません。
ここでのトレードオフは、各ステップを個別に実行し、次のプロンプトに渡し、それを基に構築できるようにすることです。ここで述べているように、品質のためにレイテンシーをトレードオフしているのです。
ここで彼らが挙げている例を見てみましょう。マーケティングコピーを生成し、それを別の言語に翻訳する。これは明らかに2つの異なるステップです。まずマーケティングコピーを生成し、それを別のプロンプトに渡して、翻訳を別個に行わせます。そうすることで、これら2つのタスクを一度に行おうとすることを避けています。
もう1つのワークフローの例はルーティングです。ルーティングは信じられないほど強力です。タスクを達成するのを待っている非常に特殊化されたエージェントを持つことができ、それらは達成できることが大きく異なる可能性があります。
クールなのは、プロンプトを送信し、どのエージェントがそのタスクに最も適しているかをルーターに決定させることができることです。どのようなツールが必要か、どのような専門知識が必要か、どのようなモデルが必要か、もちろん異なるエージェントに異なるモデルを持たせることができるからです。
ここで述べているように、ルーティングは、明確に区別される異なるカテゴリーが存在し、それらを別々に処理する方が良い複雑なタスクに適しています。分類はLLMまたはより伝統的な分類モデルアルゴリズムのいずれかで正確に処理できます。
ここで彼らが挙げているルーティングの例の1つは、私にとって絶対に素晴らしいものです。そのため、まさにこれを行う会社に投資しました。ここで彼らが言っているのは、簡単な一般的な質問をCloud 3.5 Hauのような小さなモデルにルーティングし、難しい珍しい質問をCloud 3.5 Sonetのようなより能力の高いモデルにルーティングして、コストと速度を最適化するということです。
適切なタイミングで適切なモデルに適切なプロンプトを与えたい場合、ルーティングは良い方法です。私が言及している会社はNotNotDiamondです。彼らは基本的にあなたのプロンプトを取り、コスト、レイテンシー、品質に基づいて、数十の異なるモデルのうちどれが最も適切かを決定し、どれを使用すべきかを教えてくれます。
大きなコスト削減、大きなレイテンシーの改善、そして全体的な品質の改善も得られます。もちろん、モデルを使用してシンプルなバージョンのルーティングアルゴリズムを自分で作成することもできます。
もう1つのワークフローは並列化です。特定のステップで操作の順序が重要でない場合、複数のエージェントを並列で動作させてタスク完了のレイテンシーを減らすことができます。
これについて考えていませんでしたが、彼らは並列化の2つの異なるバリエーションを説明しています。まず、セクショニング – タスクを独立した副タスクに分割して並列で実行する、シンプルですが、そして投票 – 同じタスクを複数回実行して多様な出力を得る、本質的にはChain of Thought推論です。
これは思考モデルがどのように機能するかの非常に基本的な説明です。複数の異なるバリエーションを考え出し、どれが最適かを判断し、そこから続けます。繰り返しになりますが、これらは自分で作成できます。これらは理論的には非常にシンプルなパターンです。もちろん、実際に構築して製品化する際にはより複雑になりますが、理論的にはかなりシンプルです。
では、ワークフローとして並列化をいつ使用するのでしょうか。彼らは各タイプの並列化について2つの例を挙げています。
まずセクショニングについて、ガードレールを実装する場合、1つのモデルインスタンスがユーザークエリを処理し、もう1つが不適切なコンテンツやリクエストをスクリーニングします。これは、同じLLM呼び出しでガードレールとコアレスポンスの両方を処理するよりも良いパフォーマンスを発揮する傾向があります。
私が作成したLLMジェイルブレイキングゲームのビデオを思い出してください。基本的にゲームは、このクリプトウォレットがあり、LLMにウォレットからお金を送金するように説得できれば、ウォレット内の金額を獲得できるという非常に面白いものでした。ちなみに、このビデオは説明欄にリンクを貼っておきます。
彼らはそうしませんでした。全てを1つのモデルで処理していましたが、ビデオで示唆したように、もし別のモデルで全てをダブルチェックしていれば、つまり1つのモデルが暗号資産の送受信を処理し、別のモデルがガードレールとして機能して、暗号資産を送信していないことを確認していれば、はるかに強力だったでしょう。
次にセクショニングでは、LLMのパフォーマンスを評価するためのEV評価の自動化があります。各LLM呼び出しが、与えられたプロンプトに対するモデルのパフォーマンスの異なる側面を評価します。非常に単純明快です。1つのモデルがプロンプトを生成し、1つのモデルがそれを評価します。
投票については、脆弱性のためのコードレビューがあります。1つのモデルがコードを作成し、別のモデルがそのコードを評価する場合、はるかに良質なコードが得られます。
これは私たち全員が見てきたことです。モデルからの最初のコード生成は時々は良いものの、必ずしも素晴らしいとは限りません。しかし、コードを実行し、エラーを与え、そのエラーを修正させると、より早く良くなります。
また、一般的にモデルについて気づいたことは、生成することよりも評価することの方がはるかに優れているということです。これは絶対的なルールではありませんが、一般的に私が見てきた限り、モデルはあるものを生成するよりも評価する方がはるかに正確です。そしてもちろん、特定のコンテンツが適切かどうかを評価することもできます。
次に、もう1つのワークフローとしてオーケストレーター・ワーカーがあります。これは私がCrew AIでかなり使用してきたものです。もちろん、これらのパターンは全てCrew AIで利用可能です。また、他のエージェントフレームワークでも使用したいかもしれません。
オーケストレーターパターンで私が本当に気に入っているのは、LLMから結果を得て、オーケストレーターがその結果をどう扱うかを決定し、潜在的に別の反復のために戻したり、次のステップを完了するために別のエージェントに送ったりできることです。
彼らの定義では、オーケストレーター・ワーカーワークフローでは、中央のLLMが動的にタスクを分解し、ワーカーLLMに委譲し、その結果を統合します。これはおそらく私が最もよく使用するワークフローです。
このワークフローで具体的に何を構築したか説明しましょう。PDFをアップロードし、エージェントに真実の質問と回答を多数作成させ、それからレビューアーエージェントにそれらの質問と回答が全て正確であることを確認させました。
私が発見したのは、30の質問と回答を作成すると、そのうち2つが幻覚かもしれない、つまり存在しないか単に間違っているかもしれないということです。そこで別のエージェントにチェックさせ、評価させました。
そして、オーケストレーターエージェントが質問と回答を生成するエージェントに送り返して、さらに2つを生成させ、オーケストレーターに送り返しました。これは全てシームレスに行われ、本当にクールでした。
このワークフローをいつ使用するか、彼らが挙げている2つの例があります。複数のファイルに複雑な変更を加える必要のあるコーディング製品と、可能性のある関連情報について複数のソースから情報を収集・分析する必要のある検索タスクです。これは明らかに私が作成したものです。
次に、もう1つのワークフローとして評価者・オプティマイザーがあります。これも、AIワークフローの非常に一般的なパターンです。1つのLLMがレスポンスを呼び出し、もう1つが評価とフィードバックをループで提供します。
このダイアグラムで見られるように、プロンプトがあり、LLM呼び出しジェネレーターがソリューションを生成し、評価者がそれを評価して、受け入れて提供するか、拒否して別のものを生成するよう指示します。
これは、質問と回答で私が行ったことと全く同じですが、評価者・オプティマイザーを使用し、さらにオーケストレーターも使用したので、これら2つのパターンを組み合わせたものでした。
この評価者パターンが有用ないくつかの例を見てみましょう。明確な評価基準がある場合と、反復的な改良が測定可能な価値を提供する場合です。
最初の例は、翻訳者LLMが最初は捉えきれないかもしれないニュアンスがある文学的翻訳ですが、評価者LLMが有用な批評を提供できる場合です。
ちなみに、現在のAIにおける最も強力なアイデアの1つを、私はすでに述べましたが、もう一度言います。それは評価パターンです。プロンプトに対する最初の生成レスポンスは通常最高のものではないという考えです。
これは文字通り思考モデルが行うことです。多数の異なる出力を生成し、最良のものに投票し、それを反復します。これは本当に長い生成・評価・反復のサイクルなのです。
2つ目の例は、包括的な情報を収集するために複数回の検索と分析を必要とする複雑な検索タスクで、評価者がさらなる検索が必要かどうかを判断します。
次に、Anthropicはエージェントについてさらに説明を続けています。私はここからいくつかの重要な文章とアイデアを取り上げたいと思います。
まず、この一文を見てください。エージェントは、人間ユーザーからのコマンドまたは対話的な議論のいずれかで作業を開始します。
これは必ずしもそうではないかもしれません。技術的には、エージェントは常にユーザーから開始する必要があるでしょう。完全に自律的に設定したとしても、あなたがそうするように設定しているからです。しかし、彼らの説明方法は、あなたが「はい、これをやってください」と言うか、プログラムでそのエージェントを開始してそれを実行させるかのいずれかです。
また、ヒューマンインザループについても少し触れています。これはエージェントフレームワークのもう1つの強力なアイデアです。人間が出力をレビューしたり、決定を下したりすることが重要なのはどのポイントか、また、エージェントは適切なタイミングで人間をループに含めることができるかということです。
タスクが明確になると、エージェントは独立して計画し、動作します。潜在的に追加情報や判断のために人間に戻ることもあります。エージェントはチェックポイントやブロッカーに遭遇した時点で人間のフィードバックを待つことができます。タスクは通常、完了時に終了します。
では、エージェントをいつ使用するのでしょうか？エージェントは、ステップ数を予測することが難しいか不可能で、固定されたパスをハードコードできないオープンエンドな問題に適しています。LLMは潜在的に多くの戻りで動作し、その意思決定にある程度の信頼が必要です。
以下の例は、私たち自身のエージェント実装からのものです。タスクの説明に基づいて多くのファイルに編集を加えるSbenchタスクを解決するコーディングエージェント（ちなみに、Sbenchチームとのインタビューをまだ見ていない場合は、非常に興味深いので下にリンクを貼っておきます）、またはClaudeがタスクを達成するためにコンピュータを使用する、私たちのコンピュータ使用リファレンス実装などです。
これがコーディングエージェントの大まかなフローです。人間からのクエリ、基本的にはこれをやってほしいという要求があり、エージェントが人間が望むことを明確化し、洗練するインターフェース、つまりそれをより徹底的に定義します。
その後、全てのコンテキストをLLMに送信し、コーディング環境内で多くのことを行うことができます。これらは本質的に全てツールです。ファイルの検索、パスの返信、コードの作成、ステータス、テスト結果、そして結果を完了して人間に表示します。
ここで重要な部分があります。そして、私がすでに触れた何かですが、これらのビルディングブロックは規範的ではありません。開発者が異なるユースケースに合わせて形作り、組み合わせることができる一般的なパターンです。
他のLLM機能と同様に、成功の鍵はパフォーマンスを測定し、実装を反復することです。これはおそらくこの文書全体で最も重要なことです。
私が何よりも発見したのは、特に現在は全てが非常に初期段階であるため、単にテスト、テスト、テストを繰り返す必要があるということです。可能な場合は監視ツールを使用し、必要な場合はエージェントフレームワークを使用し、多くの異なることをテストしてください。
Crewを含む多くのエージェントフレームワークは、コア機能の一部としてベンチマークを含んでいます。そのため、確実に可能な限り全てをテストし、あなたに、そしてあなたが達成する必要のあるタスクに適したパターンを発見することができるでしょう。
この素晴らしいスターターガイドを書いてくれたEric SchlunsとBarry Zhangに感謝したいと思います。エージェントについてのより多くの教育的な資料を作りたいと思っています。コメント欄で、それを見たいかどうか教えてください。
このビデオが気に入ったら、いいねとチャンネル登録をご検討ください。次回お会いしましょう。
コメント