新しいマルチエージェントコードの説明（OpenAIによる）

7,230 文字

おはようさん、皆さん。みんなから「最新のコードエージェントの状況はどうなん？」って聞かれたんやけど、ええタイミングやで。ほんの4日前にOpenAIがええ感じの新しい例を見せてくれたんや。OpenAIの表記に従うて、エージェントのクラスをここで定義しとるんやけど、見ていこか。
でもその前に、みんなの質問に答えるで。「ビジョン言語モデルもエージェントになれるんか？」って聞かれたんやけど、もちろんなれるで。ステレオカメラにアクセスして、環境内のオブジェクトを識別するアクティブビジョン言語モデルを作動させるだけや。ええ感じの制御サイクルができるし、今はほとんどの言語モデルがビジョン言語モデルやからな。
カメラみたいな特定のツールがあって、システムが訓練されとったら、全然問題ないで。事前訓練データに基づいて、このシステムがうまく動いて、ビジョン言語エージェントになるんや。もちろん、ビジョン言語アクションモデルもいけるで。アクティブセンサーアレイがあって、赤外線や紫外線、ライダー、レーダーがあって、小さなロボットを3次元で動かせるアクチュエーターがあれば、ビジョン言語アクションモデルがこれを学習して、事前訓練データや微調整データでどう制御するか分かるんや。
ロボット工学のAIでは、事前訓練データと微調整に応じて、エージェントがめっちゃうまく動くんや。「超人的なAIシステムは作れるんか？」って質問もよく聞くけど、もちろん作れるで。ビジョン言語モデルに赤外線センサーや紫外線センサーへのアクセスを追加するだけや。人間の目には赤外線スペクトルが見えへんし、紫外線センサーもないから、これで超人的なエージェントができるんや。
質問ありがとな。さて、OpenAIの最新の文献によると、エージェントの主な特徴は何やと思う？信じられへんかもしれんけど、4つのポイントがあるんや。まず、使うGPT-4 Omni Miniみたいな言語モデルを特定する。次に、システムプロンプトみたいな感じで、エージェントの行動を導く指示がある。それから、エージェントが外部機能にアクセスしたりアクションを実行したりするためのPython関数のリストであるツールがある。これでエージェントの完成や。名前、使用するモデル、AIシステムに期待することを伝える指示、エージェントがアクセスできるツール、これらがそろってるんや。
OpenAIのクックブックには、エージェントのオーケストレーション、マルチエージェントの設定、ルーチン、引き継ぎについて書かれとるで。これから見せるけど、リンクは説明欄に載せとくし、完全なPythonノートブックへのリンクも載せとくから、完全なコードをダウンロードできるで。
基本的な考え方を見ていこか。マルチエージェントシステムでは、各エージェントが特定の役割を持ち、特定のツールにアクセスできるんや。モデルシステム、スケーラブルシステム、会話システム、LLMシステムがあって、各エージェントが専門的なタスクを処理する。人間とマルチエージェントシステムの会話では、必要に応じてシステムが特定のエージェントを呼び出すから、エージェント間のシームレスな移行ができるんや。
前回の動画では7つのエージェントがチェーンになっとったの覚えとる？でも、ナレッジグラフと相互作用するマルチエージェントシステムにチェーントポロジーが本当に最適なんかって聞かれたら、答えは「ちゃう」やな。もっとええ構成があるんやけど、それは次の動画の内容にしとこか。
とにかく、要素を見ていこか。エージェントに初めて触れる人のために説明すると、まずルーチンがある。これは、特定のタスクを実行するための手順を指示として言語モデルに与える単純な一連のステップや。すぐに例を見せるで。
次にツールや。これは特定のアクションを実行するPython関数で、例えば払い戻しの実行やデータベース内の特定アイテムの検索なんかができるんや。
関数からスキーマへの変換もある。これは、Pythonの関数をJSONフォーマットに変換する簡単なユーティリティで、言語モデルが理解して実行できるスキーマに変換するんや。
ツール呼び出しの処理もあるで。これは単純なモデルで、会話中に特定の関数を呼び出せる。これらの関数はPythonの実装にマッピングされて、アクションを実行して結果を会話に戻すんや。
他にも3つの用語があるで。まず引き継ぎ。OpenAIのエージェントは会話を別のエージェントに転送できるんや。実際のカスタマーサポートみたいに、マルチエージェントシステムで別の部門に転送するような感じやな。
エージェントクラスもあるで。これは既に見せたけど、エージェントの指示、ツール、相互作用するLLMモデルを定義する構造を提供するんや。
最後に、マルチエージェントのオーケストレーションがあるで。これから見せるコードでは、1つの会話の中で複数のエージェントが相互作用できるんや。
ルーチンはめっちゃ簡単や。エージェントに指示を与えるシステムメッセージやねん。例えば、特定の会社のカスタマーサポートエージェントやったら、「ユーザーに質問して、修正を提案して、ユーザーが満足してへんかったら払い戻しを提案する」みたいな3つのポイントを指示するんや。これがルーチンや。
エージェントは作業員みたいなもんで、特定のタスクをこなすためにツールを使うんや。例えば、払い戻しエージェントは会社のデータベースで特定のアイテムを検索する関数と、顧客に払い戻しを処理する関数を使うんや。アイテムを検索する関数と払い戻しを実行する関数を定義して、エージェントがタスクを完了するためにこれらの関数を使うんや。
このコードでは、ユーザーが何か入力して、エージェントがルーチンに従って応答するっていう会話をシミュレートできるんや。run_full_turnっていう関数があって、これが一番シンプルなケースや。システムメッセージとユーザーメッセージがあって、ユーザー入力を取得してGPT-4やGPT Omni Miniなどのモデルを呼び出すのをシミュレートするだけや。メッセージが追加されて、メッセージが返されるんや。これが一番シンプルなケースで、エージェントがユーザーに質問して答えを準備するだけや。
でも、時にはツールが必要になるやろ？AIエージェントが答えるためにツールを使う必要がある場合があるんや。カスタマーサービスのシナリオやったら、エージェントがアイテムをデータベースで検索したり、払い戻しを処理したりする必要があるかもしれん。そやから、関数をスキーマにマッピングせなあかんのや。スキーマは言語モデルが理解できる特定のフォーマットで、モデルがそれらのツールを呼び出せるようにするんや。
function_to_schemaっていう簡単な関数があって、名前、パラメータ、タイプ、プロパティを持つんや。これでモデルはこの関数の呼び出し方が分かるんや。execute_refund関数やlook_up_item関数をスキーマに変換するんは簡単やで。
モデルが特定のツールを呼び出す必要がある時は、払い戻し関数を呼び出すリクエストを送るだけや。コードは使用するツールを調べて、必要なパラメータで呼び出すんや。顧客名やID、アイテムの数量なんかがあるかもしれんからな。
でも、ここから面白くなるで。状況が変わって、セールスエージェントや払い戻しエージェントなんかの別のエージェントが必要になったら、OpenAIのソリューションの美しさは、現在のエージェントが会話を別のエージェントに引き継げることや。例えば、注文した後にユーザーが別のアイテムの払い戻しを急に要求したら、セールスエージェントは会話を会社の払い戻しエージェントに渡せるんや。ユーザーはそのまま会社とやり取りを続けられるんや。
払い戻しエージェントを定義して、名前を付けて、このエージェントのタスクを明確に指示するんや。セールスエージェントはユーザーが注文するのを手伝うし、簡単な構造で引き継ぎをシミュレートできるんや。
この完全なシステムはループで動いて、ユーザーがエージェントとやり取りできるようにして、会話の流れに基づいてエージェント間を切り替えるんや。これが全てのコードや。もう馴染んでくれたと思うで。
これが一番シンプルな例で、何も起こらへんかったけど、用語に慣れるためやった。もうちょっと複雑な例を見てみよか。3つのエージェントがある場合を考えてみるで。
まず、トリアージエージェントがいるんや。これは会社の最前線にいるエージェントで、不満を持った顧客が電話してきた時に対応するんや。トリアージエージェントには名前と指示があって、「あなたはこの会社のカスタマーサービスボットです。まず自己紹介して、常に簡潔に、顧客を適切な部門に案内するための情報を集めてください。質問は自然で控えめにして、適切な部門に転送してください」みたいな感じや。
関数としては、セールスエージェントへの転送、問題解決・修理への転送、人間のオペレーターへのエスカレーションがあるんや。AIシステムが「怒った人間に対応できへん」って言うたら、人間のオペレーターにエスカレーションするんや。関数を定義して、エージェントとツールを持つ、これだけや。
セールスエージェントも同じように名前と指示があって、「あなたはセールスエージェントです。ユーザーに商品を売ってください。常に1文で答え、このルーチンに従ってください。ユーザーに問題がないか聞いて...」みたいな感じや。注文の実行、価格はUSドルで、注文の概要、商品名、価格、注文の確認（はい/いいえ）、注文成功、注文キャンセルなんかの機能がある。
全てうまくいったらトリアージに戻すし、ユーザーが担当外の話題を持ち出したら、人間へのエスカレーションも含めて別のエージェントに転送する。常に別のエージェントへのフォールバックソリューションがあるんや。
3つ目のエージェントは問題解決・修理やけど、信じられへんかもしれんけど、同じスキーマで、エージェント、名前、全ての指示、全ての関数、使えるツール全てが定義されとるんや。
入出力のスキーマがはっきり定義されとるから、何をすべきか分かるんや。でも、エージェントはどうやって相互作用するんやろ？会話の流れ、ツールや関数の呼び出し、引き継ぎ、動的なやりとりがあるんや。
メインループを見てみよか。メインループは何をしとるんやろ？ユーザー入力、エージェントの処理、エージェントの更新、会話の継続、これだけや。これがメインループのコードや。トリアージエージェントから始まって、最前線で顧客に対応するんや。ユーザーが何か言うて、エージェントとメッセージでrun_full_turnを実行する。エージェントが応答して、引き継ぎが起こったらカレントエージェントを更新する。問題がエスカレートしたり、人間や別のエージェントに引き継いだりする。全てのメッセージが美しいリストになっとるんや。
一番おもろしい関数はもちろんrun_full_turnやな。これを見てみよか。これはシステムとして、ユーザーとエージェントの間の1回の会話のターンの実行を処理するんや。メッセージを言語モデルに送って、全ての関数呼び出しを処理し、全てのツールを扱って、必要な時にエージェントの引き継ぎを処理することで、やりとりを管理するんや。
コードを見せるで。これはかなりシンプルなコードや。パート1とパート2があるから、ゆっくり見てな。会話の流れを説明するから、分かりやすくなると思うで。
人間のユーザーが会話を始めるんや。「購入したい商品について助けが必要や」って言うたとする。トリアージエージェントが最初のターンを処理するんや。トリアージエージェントが1番目で、run_full_turnを処理して、人間からの情報を得て、可能な関数呼び出しをするんや。問題解決・修理に転送するかもしれんし、コンテキストに応じて別の対応をするかもしれん。
エージェントの引き継ぎがあって、問題解決・修理への転送関数が問題解決・修理エージェントを返すんや。エージェントが更新されて、もうトリアージエージェントやなくて新しいエージェントになるんや。それからエージェントはrun_full_turnのwhile
ループでアクションの処理を続けるんや。エージェントが応答して、詳しい質問をしたり、修正を提案したり、払い戻しを提案したりするんや。アイテムの検索や払い戻しの実行なんかの関数呼び出しがあって、会話が続くんや。
これが美しいループ、美しい循環や。別の視点で見たいなら、これが実際にどう動くかを説明するで。ユーザー入力とメッセージ処理の状況があるんや。ユーザーメッセージが完全な会話履歴に追加されるんや。最初はゼロかもしれんけど、このユーザーが10分前に電話してきたかもしれんしな。
処理中に元のリストを変更せんようにするために、会話メッセージのコピーが作られるんや。エージェントが言語モデルと相互作用して、エージェントの指示がシステムメッセージとして使われて、コンテキストを設定するんや。これは既に見せたな。会話履歴が大規模言語モデルに提供されて、モデルが完全なコンテキストを持つようにするんや。
モデルは応答を生成するんやけど、これにはコンテンツと特定の関数呼び出しが含まれるかもしれん。関数呼び出しがあったら、一つずつ処理されるんや。各関数呼び出しはexecute_tool_callを使って実行されて、対応するPython関数を呼び出すんや。これらの関数は既に定義したって言うたな。
エージェントの引き継ぎがあったら、実行された関数がエージェントインスタンスを返すんや。引き継ぎが起こって、現在のエージェントが新しいエージェントに更新されて、それが返されるんや。転送を示すメッセージが会話の記録に追加されるんや。
それからループが続くんや。モデルが関数呼び出しを行う限り、ループは続くんや。もう関数呼び出しがなくなったら、ターンが終わって応答が返されるんや。
どう見たいかは自由やけど、これはかなり簡単なスキーマで、OpenAIが実装した美しい新しいアイデアやな。
緑の初心者さんのために、run_full_turn関数の説明をもう一度するで。これが中心的な要素やからな。エージェントと、これまでにやり取りされたメッセージのリストである会話のメッセージがあるんや。loicっていう関数があって、変数を初期化して、メインループがあるんや。これは既に見せたな。
ツールをスキーマに変換して、モデルの応答を取得するんや。client.chat.completions.createっていうのがあって、新しい関数呼び出しをチェックして、それらの関数呼び出しを処理するんや。エージェントの引き継ぎがあれば処理して、システムの応答があるんや。
詳細を見たいなら問題ないで。ここに詳細1と2があるから、4K以外の画面でも読めるはずや。詳細2ではモデルの応答を取得して関数呼び出しをチェックするんや。詳細3は最後にエージェントの引き継ぎと返却やな。
これが大体全部や。4日前の新しいスキーマや。ええ感じやろ？
そこでストロベリーに聞いてみたんや。「OpenAIが示したこの新しいマルチエージェントオーケストレーションのメリットは何で、要約してくれへん？」って。
ストロベリーが返してきた答えはこうや。メリットはモジュール性、動的な引き継ぎ、ツールの統合、コンテキストの保持、そして拡張性やって。既存のシステムに大きな変更を加えんでも、新しいエージェントや新しいツールを追加できるんや。これはええな。
ストロベリーによる要約はこうや。run_full_turn関数が重要で、ここに注目すべきやって。これが、ユーザーと異なるエージェント間のやり取りをオーケストレーションするのに重要なんや。メッセージの受け渡しを管理するんやけど、気をつけてな。これはグラフニューラルネットワークのメッセージパッシングとは違うで。これは本当に単純なケースで、ただの会話履歴やねん。
それからモデルの相互作用、全ての関数呼び出し、使用する全てのツール、全てのエージェントの引き継ぎがあるんや。これを適用したら、柔軟で拡張性のある洗練された会話システムが構築できるんや。これはめっちゃええシステムやな。
完全なコードを提供すると言うたな。OpenAIのGitHubにあるOpenAI Cookbookの例、orchestrating-agentsってPythonノートブックに行くだけや。見てのとおり、4日前のもので、今は全てのエラーが修正されて、うまく動いとるんや。完全なPythonノートブックをダウンロードできて、全てが細かい詳細まで含まれとるんや。本当に美しい例や。
これで新しいルーチンと引き継ぎの概念の紹介ができたと思うで。助けになったらええな。追加で、調整エージェントのないスウォームの実装のサンプルリポジトリも提供されとるんやけど、この考えはスキップしよか。次の動画か近々の動画で、エージェント間の専門的な通信プロトコルを見ていくつもりやからな。これは、エージェント間の特定の構成に自動的に適応するんや。
一番簡単なケースではエージェントのチェーンがあるんやけど、異なる構成と異なる空間を調べて、そこで必要な異なる通信プロトコルを見ていくつもりや。でも、これは次の動画のいずれかで取り上げるから、そん時まで待っててな。
チャンネル登録したいなら大歓迎や。次の動画で会えるのを楽しみにしとるで。