本動画は、OpenAIが提供するAgentKitの包括的なデモンストレーションである。AgentKitは、AIエージェントの構築、デプロイ、評価を統合的に行うプラットフォームであり、従来数ヶ月を要していた複雑なエージェント開発を劇的に効率化する。ビジュアルワークフロービルダー、自動プロンプト最適化、組み込み評価システム、カスタマイズ可能なUI(ChatKit)などの機能を備え、営業支援、カスタマーサポート、データ分析など幅広いユースケースに対応する。実際の企業事例を交えながら、データベース連携、ウェブ検索、メール生成を組み合わせた実践的な営業アシスタントの構築プロセスを詳解し、評価駆動開発の重要性とベストプラクティスを示している。
AgentKitの紹介
それでは始めましょう。皆さん、こんにちは。OpenAIビルドアワーへようこそ。私はプラットフォームチームのプロダクトマーケティングマネージャーのタシャです。本日のスピーカーをご紹介できることを大変嬉しく思います。まず私が口火を切り、次にスタートアップ側の応用AIチームのサマー、そしてプラットフォームチームのプロダクト責任者であるヘンリーが登壇します。
それでは、念のため確認させていただきます。ビルドアワーの目的は、OpenAIのAPIとモデルを使って皆さんの会社、製品、ビジョンを拡大するために、ベストプラクティス、ツール、AI専門知識を提供することです。下記のリンク、openai.com/buildhoursでスケジュールをご確認いただけます。
本日のアジェンダです。まず、つい数週間前のDevdayでローンチしたAgentKitについて簡単に説明します。その後、サマースにAgentKitのデモをお願いします。ヘンリーは評価システムについて説明します。これは実際にエージェントを機能させ、大規模に信頼できるようにするために非常に重要です。時間があれば、いくつかの実例もご紹介します。そして最後には必ずQ&Aの時間を設けます。進行中、自由に質問を追加してください。
それでは、過去数ヶ月、あるいは1年間、エージェントを構築する際の状況を簡単に振り返ってみましょう。以前は非常に複雑でした。オーケストレーションは困難で、すべてコードで記述する必要がありました。バージョンを更新したい場合、時には破壊的な変更が導入されることもありました。
ツールを安全に接続したい場合は、カスタムコードを書かなければなりませんでした。そして評価を実行するには、あるシステムから手動でデータを抽出し、別の評価プラットフォームに移す必要があり、これらの別々のシステムを数珠つなぎにして、実際に大規模にエージェントを信頼できるようにしなければなりませんでした。プロンプトの最適化は遅く、手作業でした。
その上、エージェントを実現するためにUIを構築する必要があり、それにはさらに数週間から数ヶ月かかりました。つまり、大規模なアップグレードが切実に必要な状況でした。それが私たちが今行っていることです。AgentKitによって、エージェント構築方法に段階的な改善をもたらせたと期待しています。
現在、ワークフローはビジュアルワークフロービルダーで視覚的に構築できます。バージョン管理されているため、破壊的な変更は導入されません。コネクタレジストリと呼ばれる管理センターがあり、データとツールを安全に接続できます。そしてプラットフォームに組み込まれた評価システムがあり、サードパーティモデルのサポートも含まれています。
サマースが後ほどお見せしますが、自動プロンプト最適化ツールもあります。これにより、手動で試行錯誤するのではなく、自動的にプロンプトを完璧にすることが非常に簡単になります。そして最後に、カスタマイズ可能なUIであるChatKitがあります。
これらをまとめると、AgentKitの技術スタックはこのようになります。最下層にはエージェントビルダーがあり、そこでエージェントをデプロイするモデルを選択できます。ツールを接続し、プロンプトを記述、自動化、最適化します。エージェントが期待通りに動作するように、予期しないクエリを受け取った場合でも、ガードレールを追加します。
それをChatKitにデプロイします。ChatKitは自分でホストすることも、OpenAIでホストすることもできます。そして、実世界のデータと実際の人間からのデータによって、評価プラットフォームを通じてパフォーマンスを観察し最適化することで、実世界で大規模にエージェントを最適化します。
すでに多くのスタートアップやFortune 500企業、そしてその中間の企業がエージェントを使用して、幅広いユースケースを構築しています。よく見られる人気のあるユースケースには、チャットベースのカスタマーサポートチケットをトリアージして回答するカスタマーサポートエージェント、営業アシスタント(実は今日デモするものと似ています)、OpenAIで使用している内部生産性ツールのようなもので、チーム全体がよりスマートかつ迅速に働き、重複作業を減らすのに役立っています。
ナレッジアシスタントや、ドキュメント調査や一般的な調査のようなリサーチも行っています。右側のスクリーンショットは、エージェントビルダーにあるいくつかのテンプレートで、すでに私たちがサポートしている主要なユースケースの一部を示しています。
実世界の例:営業支援エージェント
それでは、実際の例でこれを具体化しましょう。企業が直面する一般的な課題は、収益の促進と増加です。営業チームが見込み客へのアウトバウンド、関係構築、顧客とのミーティングで忙しすぎるとしましょう。営業時間を節約し、収益を増やすために、go-to-marketアシスタントを構築したいと思います。それでは、サマースに、その方法をお見せしてもらいましょう。
ありがとうございます。OpenAIでよく受ける最大の質問の一つは、「OpenAI内でOpenAIをどのように使っているのか」というものです。これによって、私たちが実際にgo-to-marketアシスタンスをどのように構築しているかを少し覗いていただけると思います。本日は、データ分析、リード資格審査、アウトバウンドメール生成ができるエージェントなど、いくつかの異なるトピックを取り上げます。
それでは画面を共有します。実は、Atlasブラウザを使っています。ぜひダウンロードしてください。この数週間使ってみて素晴らしい経験をしました。何時間、いや何日分もの時間を節約できたと思いますし、大ファンです。
それでは始めましょう。エージェントビルダープラットフォームに入ると、最初に目にするのはスタートノードとエージェントノードです。エージェントは、構築するワークフロー内の原子粒子のようなものと考えることができます。その背後にはエージェントSDKがあり、これがエージェントビルダー全体を実際に動かしています。
これらのエージェントビルダーワークフローを構築する際、OpenAIプラットフォーム内に留まる必要はありません。このコードをコピーして、自分でホストすることができます。従来のチャットアプリケーションを超えて、Webhookを介してこれらをトリガーするようなこともできます。
この例では、構築を考えている3つのエージェントがあります。Databricksからデータを取得するデータ分析エージェント、インターネットを精査して追加の詳細を探すリード資格審査エージェント、そして私たちがローンチしている製品やマーケティングキャンペーンに関する情報でメールを資格審査したいアウトバウンドメール生成エージェントです。いいですか。
いいですね。賛成です。それでは、ここで最初のエージェントを構築しましょう。3つの異なるタイプのユースケースを念頭に置いているので、トリアージエージェントを使用する非常に伝統的なアーキテクチャパターンを使いたいと思います。
私たちの考え方は、エージェントは専門的なタスクを実行するのが得意だということです。この質問を適切なサブエージェントに分解できれば、より良い応答が得られる可能性があります。それでは、この最初のエージェントを質問分類器と呼びましょう。タイピングは難しいですね。
ここに用意したプロンプトをコピーします。これがどのように見えるか簡単に見てみましょう。ここで実際に行っているのは、質問を資格審査、データ、またはメールタイプの質問のいずれかとして分類または分類するようモデルに依頼することです。
実際のアイデアは、モデルが出力として選択したものに応じて、このクエリをルーティングできるということです。従来のテキスト出力ではなく、ここで実際に行いたいのは、認識でき、ワークフローの残りの部分で使用できるスキーマでモデルに出力を強制することです。
それでは、この変数をカテゴリと呼び、モデルが出力する変数として、タイプをenumとして選択しましょう。これは、モデルがここで提供するリストからのみ選択を出力することを意味します。プロンプトから、emailエージェント、dataエージェント、qualificationエージェントがありました。
ちょっと待ってください。プロンプトはどうやって書いたんですか。全部自分で書いたんですか。プロンプトの重要性とエージェントを操縦することは知っていますが、どうやって思いついたんですか。
プロンプトを書くのは、私たちができる最も面倒なことの一つだと思います。最初のプロンプトを作成する際に、実際に重要なことを捉えるために、車輪を回転させるのに多くの時間が費やされます。そして私自身がプロンプトを書く最も重要な方法の一つは、ChatGPTとGPT-4oを使ってプロンプトのv0を作成することだと思います。
エージェントビルダー自体の中で、実際にプロンプトを編集したり、ゼロからプロンプトを作成したりすることができます。それを将来、エージェントワークフローのためにスピンするための基礎として使用できます。今のところ、ここに貼り付けたものをそのままにしておきますが、このワークフローの残りの部分で、それを実際に使用するとどのように見えるかを見ていきます。
それでは、出力を取得したので、エージェントビルダーは実際にこれを非常にステートフルにすることができます。ここにセットステートアイコンがあります。申し訳ありませんが、繰り返しますが、ドラッグアンドドロップも難しい場合があります。
ここで行いたいのは、前のステージからの出力値を取得し、それを新しい変数に割り当てて、このワークフローの残りの部分がそれを参照できるようにすることです。これをもう一度カテゴリと呼びます。今のところデフォルト値は割り当てません。
同じ値を使用して、データ分析エージェントまたはワークフローの残りの部分に条件付きで分岐できます。メールやデータ資格審査ユースケースまたは顧客資格審査ユースケースを実行する前に実行したい追加のステップを処理するためです。
ここでこのエージェントをドラッグし、ステートカテゴリがdataに等しい場合という条件文を設定します。見てみましょう。どうやらスペルを間違えたようです。デバッグ中です。
ご覧のように、実際に何が間違っていたかを確認できる便利なヒントがあり、非常に迅速に戻ってデバッグできます。ここでは、dataエージェントかどうかを確認したいので、その別のエージェントにルーティングします。そうでない場合は、おそらく追加のロジックを使用して、資格審査したいインバウンドリードや書きたいメールのためにインターネットを精査します。
今のところデータ分析エージェントに固執して、エージェントビルダー内、そして主にエージェントSDK内で外部ソースに実際に接続することがどのようなものかを見ていきましょう。ここで実際に行いたいのは、Databricksの使用方法を指示し、MCPサーバーと連携して使用できるクエリを作成することです。
ここで行ったのは、モデルがこのMCPサーバーにアクセスし、適切と考える方法でDatabricksをクエリできるようにツールを追加したことです。クエリが本当に難しく、結合が必要な場合、DatabricksとGPT-4oはそれらを一緒に使用して、簡潔なクエリを作成できます。
今のところ自分のサーバーを構築したので、ここに追加します。まずURLを追加します。これをDatabricks MCPサーバーと呼びます。ここで実際に行うのは、認証パターンを選択することです。認証なしを選択することもできます。
しかし、保護されたリソースや認証されたプラットフォーム内にあるものの場合、パーソナルアクセストークンのようなものを使用して、最後のフェデレーションを実行したい場合があります。この場合、Databricksインスタンス内で作成したパーソナルアクセストークンを使用して、ここで作成します。ツールが表示されるまで少し待ちます。
フェッチツールが実際にここに送信されていることがわかります。これにより、MCPサーバーに実際に許可されている関数のサブセットを選択できます。これにより、モデルが実行できる潜在的なアクションの選択肢に圧倒されないようにします。そこにそのツールを追加します。おっと、戻ります。
ここで見逃したかもしれないことの一つは、実際にモデルを設定することです。これを本当にキビキビさせたいと思います。そこで、非推論モデルを選択できます。しかしこれについては、モデルがこれらのクエリを反復し、モデルの結果がエージェントにどのように認識されたかに反応することを本当に望んでいます。
ここで行うのは、配管が機能することを確認するための簡単なテストクエリです。トップ10のアカウントを表示してくださいと言いましょう。それで十分なはずです。モデルがこのワークフローの個々のステージを実際にステップスルーしていることがわかります。
最初に、この質問をデータの質問として分類し、その状態を保存してからルーティングしたことがわかります。そのエージェントに到達し、そのツールを使用することを決定したとき、実際にそのアクションを実行する同意を求めてきました。フロントエンドでそのロジックを設定して、モデルが実際にアクションを選択したいことをユーザーにどのように表示するかを処理できます。
MCPを使用すると、読み取りアクションと書き込みアクションの両方を実行できます。すぐに使えるMCPサーバーがいくつかあります。Gmailのようなものを考えてください。すぐに使える多くのものがあります。SharePointなど。
ここで、モデルが実際にそのクエリの構築方法について考えていることがわかります。ここに応答が表示されています。モデルに実際にこの結果をフォーマットするように依頼していませんでしたが、このエージェント自体を使って実際に非常に迅速に行うことができます。
結果を自然言語で表示したいと言うだけで、エージェントビルダー自体の生成ボタンをスピンするだけで、リアルタイムで見た結果に応じて、これらのインライン変更を提供できます。非常にクールです。
次に実際に行いたいのは、メールの生成やリードの資格審査のために役立つかもしれない調査を行うための別のエージェントを作成することです。これを情報収集エージェントと呼びましょう。ここで少し止まっているようです。少しリフレッシュする必要があるかもしれません。プラットフォームが少しバグっています。
この情報収集エージェントに来ました。ここで行いたいのは、実際に行って、私たちが望むリードのためにインターネットを検索する方法をモデルに伝えることです。特に、会社に対して公開されている可能性のある情報のサブセットを探しています。会社の正式名称、従業員数、会社の説明、おそらく年間収益、地理的位置などを考えてください。
ここで再び行いたいのは、構造化された出力を使用して、モデルがインターネットを検索したときに出力がどのように見えるべきかを定義することです。これにより、良好なマッピングが得られ、モデル自体がこれらのクエリを書くときに何を探すべきかを知ることができます。インターネット全体で検索する方法をモデルに指示できます。
ここで行いたいのは、入力したいスキーマの出力形式も変更することです。以前表示したフィールドを構造化された出力形式に入れたい場合があります。プロパティに説明を追加することもできますが、今のところは空白のままにしておきます。
これで、モデルがこの情報収集エージェントに到達すると、このエージェントに到達し、インターネットを検索し、探している形式で出力します。最初にクエリルーティングの状態を保存したので、メール経由またはリード生成とリード強化エージェントにルーティングする際に、これを再度参照できます。
ここでこれをemailと等しく設定し、それ以外の場合は他のエージェントにルーティングします。サブエージェントアーキテクチャは素晴らしいですね。一つの汎用エージェントを使用するよりも、より高品質の結果を少し速く得られるということです。これは実際に営業チームの生産性を向上させ、影響を与えるのに役立ちます。
ここで行うのは、このメールエージェントのプロンプトを貼り付けることです。しかし、メールエージェントのハイライトは、クエリやインターネットからの情報だけでなく、マーケティングキャンペーン用のメールの構築方法についての考え方にマッピングされるファイルをアップロードしたいということです。
この場合、キャンペーンに関する情報を含むPDFのようなものがあるかもしれません。メールの書き方に関する情報を含む他のPDFがあるかもしれません。これらはすべて、そのメールが実際にどのように見えるべきかを仕様化するためにモデルにとって非常に有用な情報です。
ここで行うのは、実際にこれらのファイルを検索するツールを追加することです。既に持っているかもしれないベクターストアをワークフローにアタッチして、すぐに使用できます。API経由でこれらを追加することもできます。しかし今のところ、持っているファイルをいくつかドラッグするだけです。
メールの書き方に関する標準操作手順のものが一つあります。このサンプル会社が持っている潜在的なプロモーションに関する別のドキュメントがあります。モデルがこのベクターストアに入って、このタイプの情報を検索し、実際にそのメールを生成できるようにしました。
リード強化エージェントについて。自分で書く代わりに、実際に割り当てたい様々なアカウントエグゼクティブへの市場の一般的なセグメンテーションがあると仮定しましょう。この場合、実際に行いたいのは、インターネットから収集された情報に応じて、その割り当てプロセスをどのように行うかの簡単な概略図を出力できることです。
プロンプトを書かずに、エージェントビルダーは開始点としてそのプロンプトの完全なバージョンを出力できます。非常にクールです。エージェントビルダーから離れて、これがエンドツーエンドで機能することを示す前に、お見せしたかったのは、エージェントビルダーがテキストと構造化された出力形式だけをサポートしているわけではないということです。非常にリッチなウィジェットもサポートしています。
これが実際にどのように見えるかというと、テキストやJSONを出力する代わりに、ウィジェットをアップロードできます。実際にウィジェットを作成して使用する様子を少しお見せしますが、実際にウィジェットファイル自体をアップロードできます。これをドラッグします。
このウィジェットがどのように見えるか簡単なプレビューが表示されます。テキストで出力するだけでなく、おそらくChatGPTで従来見られるようなマークダウン形式の結果よりも、よりリッチなものをレンダリングしたい場合があります。
自分のウェブサイトで自分でホストする場合、そのマルチモーダルコンポーネントも持てるようにしたいと思います。ここでこのコンポーネントを作成します。では、OpenAIへのメールを下書きしてくださいと言いましょう。
情報収集エージェントに行ったことがわかります。理由は、ウェブ検索ツールへのアクセスを与えたからです。それをやったかどうか確認しましょう。そのステップをスキップしたかもしれません。
申し訳ありません、言おうとしていたのは、実際に本番環境に移行する前に、ここでワークフローをライブでテストしてデバッグできるのが大好きだということです。その通りです。
そして本当に素晴らしいのは、このワークフローを通じて質問を実行すると、モデルが様々なクエリをどのように実行したか、そしてワークフローがどのようにオーケストレーションしたかの詳細なトレースを保存することです。これはワークフローを継続的に反復する際に非常に豊富な情報です。
ヘンリーがこれについて多く触れますが、実際にカーテンをめくってモデルがこれについてどのように考えているかを見て、グレーダーを割り当てる能力は、評価のプロセスを拡大することを本当に可能にすると思います。
ここではLumaフリートを検索しているようです。これを少し実行させて、最後に何が起こるか見てみましょう。少し時間がかかるかもしれません。後でそれに戻ります。エンドツーエンドで。
ここで構築したのは、基本的に3つの異なることを行えるエージェントです。最初は、Databricksに入ってクエリを実行し、何らかの情報の壁の後ろにあるかもしれない情報を取得し、エージェントワークフロー自体内にそれを取り込むことができるようにするものです。
そして、メールを資格審査して書くことができること、そして顧客から得られるかもしれないインバウンドを資格審査することもできます。これらすべては、ChatKitでホストするか、自分のコードベースに持ち出してそれらのチャットワークフローが実際にどのように見えるかを処理できるワークフロー内にあります。非常にクールです。
ツールとウィジェットの活用
疑問に思っていたことの一つは、左側のサイドバーからツールを引き出してノードとしてドラッグアンドドロップするのと、エージェントノード自体にそのツールを追加するのとの違いは何かということでした。
非常に良い質問です。情報収集エージェントに検索ツールを追加したとき、モデルが実際にそのツールを使用すべきかどうかを判断できるようにしました。時には、エージェントが実際にその情報を取得する前に、常にツールを実行したい場合があります。
そのため、これらのノードの一つを追加して、エージェントが実際にその情報を受け取る前に、モデルが実際にこのアクションを実行していることを確認できます。非常に理にかなっています。AgentKitは、決定論的な結果と、望むなら非決定論的な結果の良い組み合わせだと感じます。
その通りです。この素晴らしいワークフローを構築したので、次はそれをデプロイしたいと思います。最近のDev Dayでリリースした最も素晴らしいことの一つは、構築したこれらのワークフローに入ってホストできる能力だと思います。
構築したワークフローIDを使用して、これらのチャットインターフェースを実際に動かすことができます。これらは、推論モデルをサポートするだけでなく、複雑なエージェントアーキテクチャとユーザーに表示したいハンドオフをサポートするために、それ以外では多くのエンジニアリングを必要とするかもしれません。
本番環境でこれがどのように見えるかというと、構築している実際のチャットインターフェースに、ブランドガイドライン全体を一致させることができます。そして、私たちの実際の顧客が今日これをどのように使用しているかを見てみます。
しかし、実際にハイライトしたかったのは、カラースキーム、フォントファミリー、ユーザーが入って使用するかもしれないスタータープロンプトまで、これを完全にカスタマイズできるということです。
たとえば、光熱費請求書を見るワークフローがあるとします。MCPサーバーに接続して、請求履歴を取得し、過去の請求書を分析してから、非常にリッチなウィジェットをユーザーに表示したい場合があります。
そのプロセス全体とユーザーが見るもののカスタマイズは、ChatKitを通じて完全に設定可能です。質問で、私のエネルギー使用量はどうですか。従来のテキスト応答を表示するのではなく、出力を視覚化できる非常にリッチなグラフが表示されます。これは非常にクールです。
私たちのユースケースの例では、話を完結させるために、利用可能なウィジェットの一つは、おそらく間もなくお見せするメールウィジェットです。エージェントに実際にOpenAIへのメールを下書きしてもらいたい場合(まだ情報を調査中だと思いますが、公開情報が非常に多いため)、営業はそのボタンをクリックして、そのメールを顧客に送信できます。
その通りです。それらのウィジェットがどのようなものかをいくつか見てみましょう。ギャラリーをリリースしました。そこで私たちが本当にクールだと思うものをいくつか見ることができます。これらをクリックして、実際にこれらを構築するためのコードが何かを確認することもできます。
しかし、本当にクールだと思うのは、自然言語を通じてこれらを生成できることです。たとえば、特定のブランドガイドラインを含むメールコンポーネントまたはウィジェットをモックアップしたい場合、または私のブランドに本当にアピールするそのウィジェットのフォーマット方法があります。
自然言語を通じて完全にそれができます。これを使用すると、エージェントビルダーにエクスポートして、エージェントビルダーがChatKitでそのウィジェットを呼び出すときにそのUIを表示できます。素晴らしいです。
ヘンリーに移る前に、実際の例でこれがどのように見えるかを示したかったです。地球の画像または地球儀を表示するウェブサイトがあります。自然言語を介してこの地球儀を制御できるようにしたいと思います。今日はどこに行きましょうか、タシャ。
次のDev Day Exchangeはバンガロールだと思います。インドと言いましょう。インドに行きましょう。ここで見るべきは、別のエージェントビルダー駆動のワークフローです。
右側にウィジェットが表示されただけでなく、実際のウェブサイト自体にレンダリングされたJavaScriptを実際に制御できたことがわかります。このカスタマイズ性と、毎日使用するウェブサイトやブラウザへのポータビリティを持つことは、ChatKitで非常に魅力的だと思います。
今までで最も速いインドへの旅行でした。その通りです。構築側とChatKitへのデプロイ側をカバーしました。本当に最も重要な部分であり、多くのエージェント構築の中で最も難しい部分は評価の部分です。
これこそが、本番環境で大規模に実世界のシナリオでエージェントを信頼できることを知る方法です。起こってくるすべての輝かしく奇妙なエッジケースを含めて。それでは、英国にいる友人ヘンリーに、Evalデモを案内してもらいたいと思います。
評価システムの重要性
タシャとサマー、ありがとうございました。そして皆さん、こんにちは。私はヘンリーです。AgentKitに取り組んだプロダクトマネージャーの一人です。今日は、エージェントを構築し、ワークフローを取得し、ビジュアルビルダーでそれを定義した後、それをテストする方法について少しお話ししたいと思います。
まず、個々のノードをテストし、その特定のエージェントまたはその特定のノードが望むように動作することを確信する方法について話したいと思います。なぜなら、最終的にエージェントは最も弱いリンクと同じくらい優れているからです。
すべてのコンポーネントが調整され、望むように動作している必要があります。すべてのノードを快適な場所に配置したら、エンドツーエンドのパフォーマンスを評価したいと思います。
そのために、トレースを見ることができますが、トレースは解釈が難しいです。そこで、トレースを取得して大規模に評価できるトレースグレーディング体験も用意しました。それでは、画面を出してデモを少しお見せして、これをどのように行えるかをお話ししましょう。
ここに私が構築したエージェントが見えます。これは、私たちの金融サービス顧客の一つの実際の例に基づいています。これは会社名の入力を受け取ります。これが公開企業か非公開企業かを評価し、最終的にその会社のプロフェッショナル投資家の一人がレビューするためのレポートを書く前に、その会社に対する一連の分析を完了します。
前述したように、ここには多くのエージェントがあり、これらのエージェントのすべてがうまく機能し、望むように動作する必要があります。それがどのように動作するかについて、どのように自信を持ち、その動作について可視性と透明性をどのように得るのでしょうか。
このエージェントを定義し、これらのノードの一つを見ているとき、右下に評価ボタンがあることがわかります。その評価ボタンをクリックすると、プロンプト、ツール、割り当てられたモデルを持つそのエージェントノードを取得し、データセットで開きます。
このデータセットUIが表示され、簡単な評価を視覚的に構築できます。このEvalにいくつかのデータ行をアタッチします。会社名と、真実の収益と所得の数字も表示できます。
そのデータをこのデータセットにインポートしました。これにより、この評価を実行できます。ビジュアルビルダーから渡されたすべてのものが見えます。モデル、ウェブ検索のツール、割り当てたシステムプロンプトとユーザーメッセージがあります。そして、アップロードしたこのデータも追加で見ることができます。
これはわずか3行で、いくつかの会社名と、ウェブ検索ツールがそれらの会社に対して返すべき収益と所得の数字の真実の値です。今できることは、生成を実行することです。
これは明らかに、評価の最初の段階は生成を実行することであり、生成が完了したら評価段階を完了します。その生成が実行されている間に、列をアタッチする方法をお見せしたいと思います。
たとえば、サムズアップとサムズダウンの評価をアタッチできる評価用の新しい列を追加できます。そして、フリーテキストフィードバック用の列を追加しましょう。ここでフリーテキストの注釈をアタッチできます。
何かに満足しているかもしれませんし、そのデータについてより長い形式のフィードバックをアタッチしたいかもしれません。今、この出力が出てきていることがわかります。これをクリックすると、完了したこれらの生成をタブで切り替えることができます。
ここで、Amazon、Apple、そしてMetaの分析を完了するように求められたことがわかります。まだ実行中です。それをスクロールして、完了した生成を見ることができます。次にできることは、作成したこれらのフリーテキストラベルをアタッチするか、これらの注釈をアタッチすることです。
これは良いと言えます。これは悪いと言えるかもしれません。これは良いと言えるかもしれません。そしてフィードバックをアタッチできます。たとえば、これは長すぎると言えます。
これらの注釈を完了したら、グレーダーも追加できます。ここでグレーダーを追加しましょう。財務分析を評価する簡単なグレーダーを作成します。
この財務分析には、上昇と下降の議論が含まれ、競合他社を考慮し、買い、売り、または保持の評価で終わることが要求されます。それを保存して実行します。これで実際にグレーダーの評価を実行します。実際、ちょっと変更させてください。それをそのままにしておきましょう。
これで実行して、そのグレーダー評価を完了します。多くのデータがあるため、実行には少し時間がかかります。以前に作成したデータセットに移動します。
これらのグレーダーが完了したことがわかります。これらをクリックすると、理論的根拠が見えます。グレーダーが与えた結果の理由が見えます。たとえば、ここでは明示的な推奨事項がなく、競合他社の比較がないため、このグレーダーは失敗しています。
この時点で何ができるか、そしてここがどこにいるかを簡単にまとめてみましょう。完了した生成があります。すべての注釈とすべてのグレーダー出力があります。
この時点で何をしますか。エージェントをどのように改善しますか。一つの方法は、手動でプロンプトエンジニアリングを行い、そのデータのパターンを見つけてから、プロンプトを書き直すことです。それは明らかに時間がかかり、それらのパターンを見つけて解決しようとするのに多くの時間を費やす必要があります。
より良い解決策として私たちが見ているのは、自動プロンプト最適化です。ここにこの新しい最適化ボタンがあることがわかります。それをクリックすると、このデータセットに新しいプロンプトタブが開き、そこでプロンプトの書き直しを自動化します。これにより、毎回手動でプロンプトエンジニアリングを行う手間が省けます。
ここで行っているのは、それらの注釈、グレーダー出力、プロンプト自体を取得して、新しいプロンプトを提案するために使用することです。繰り返しますが、これは実行に1、2分かかります。以前に作成したものにタブで移動します。
ここに書き直されたプロンプトが表示されます。基本的な財務分析を完了しますが、私が完了した最初のかなり粗雑で大雑把なプロンプトよりもはるかに徹底的で完全です。
これが、エージェントビルダーからその単一ノードを取得し、その単一エージェントを堅牢に評価する方法の概要です。しかし、ここで構築しているのは単一のエージェントではありません。これはマルチエージェントシステムであり、すべてのノードを個別にテストしたいと思います。
しかし最終的に私たちが気にするのは、エンドツーエンドのパフォーマンスです。それについてどのように自信を持つのでしょうか。それをどのようにテストするのでしょうか。
サマーが言及したように、これらのエージェントはトレースを発行します。ここに、以前にこのエージェントを実行したときのトレースの例が見えます。これをクリックすると、すべてのスパンが表示されます。すべてのスパンをクリックして、このエージェントが実行されたときに何が起こったかを特定し始めることができます。
これをクリックしていくと、問題に気づき始めるかもしれません。たとえば、ここにウェブ検索ツールによって取得された多くのソースがあることがわかります。たとえば、CNBCやBarons。これらのサードパーティソースを引用したくないかもしれません。ファーストパーティの権威あるソースのみが必要かもしれません。
ウェブ検索ソースはファーストパーティのみであるべきだと言いましょう。GPT-4oとNanoでそれを実行して、素早くしましょう。そして、これらをさらにクリックしていくと、追加の問題を見つけるかもしれません。
たとえば、最終結果に買い、売り、保持の評価が含まれていないという別のパターンを特定するとします。最終結果には明確な買い、売りの評価が含まれている必要があると言います。
そして繰り返しますが、特定のトレースに対して実行できるこれらの要件を構築しています。この要件セットはグレーダーのルーブリックのように考えることができます。このグレーダールーブリックは、優れたエージェントを定義する一連の基準で構築されています。
その基準セットを構築し、いくつかのトレースでテストしたら、上部にあるこの「すべてをグレード」ボタンをクリックできます。
これにより、これをスコープしたトレースのセットがエクスポートされます。この例では、これら5つのトレースだけです。そして、右側で定義したグレーダーのセットを取得します。それを新しい評価で開きます。
これにより、非常に多数のトレースを大規模に評価できます。なぜなら、これらのトレースのすべてをクリックして問題を見つけようとすることは、あまりうまく機能しないからです。時間がかかります。うまくスケールしません。
しかし代わりに、これらのトレースグレーダーを非常に多数のトレースに対して実行できます。それにより、問題のあるスパンだけを特定し、掘り下げたいトレースだけを特定するのに役立ちます。
これが、この組み込み評価体験の概要でした。エージェントビルダーと緊密に統合されています。また、このプラットフォームで多数の顧客と協力してきた経験から、いくつかのベストプラクティスと学んだ教訓をフラッシュしたいと思います。
まず、シンプルに始めましょう。物事を複雑にしすぎないでください。しかし早く始めてください。プロジェクトの最初の段階で、いくつかの入力と定義したシンプルなグレーダーを用意してください。評価を土壇場まで残すのではなく、これを出荷する直前にテストをしなければならないというような、一部の人がすることを知っています。
早期に開始し、評価を組み込み、プロトタイプを厳密にテストし、プロトタイプの問題を見つけてから、評価に対してヒルクライムしながら改善を定量的に測定する評価駆動開発を行う方が、はるかに良い製品を構築する方法であり、より高いパフォーマンスをもたらす可能性があります。
第二に、人間のデータを使用すること。仮想の入力を考え出すだけで、LLMを使用して合成入力を生成するのは本当に難しいです。
実際のユーザーデータ、実際のエンドユーザーからの実際の入力を取得すれば、おそらくはるかに優れたパフォーマンスが得られます。なぜなら、それは現実世界の混乱の多くを捉えているからです。
そして最後に、生成に注釈を付け、LLMグレーダーを調整することに十分な時間を投資してください。これにより、あなたの専門知識が実際にシステムにエンコードされ、グレーダーが実際に製品に望むことを表現するようになります。
これが私たちの製品の高レベルの概要でした。これはすべてGAです。ぜひ試していただき、フィードバックをお聞かせください。それでは、タシャとサムに戻します。
実例と総括
素晴らしい。ありがとう、ヘンリー。評価だけで丸々1時間のセッションができそうですね。素晴らしかったです。実は、終わる前に1つ質問があります。評価用のデータセットのサイズはどのくらいがおすすめですか。チャットでこの質問がありました。
100、1000、10ですか。望む結果を得るために、適切なデータセットサイズをどのように知るのですか。
良い質問ですね。最善の方法は早期に開始することです。10から20の例でも大いに役立ちます。テストするデータセットを持つことは本当に役立ちます。10、20、数十行でも役立ちます。
そして、本番環境に近づくにつれて、明らかに多いほど良いです。しかし、それは単に何行かという質問としては考えないでください。なぜなら、ここで考慮しなければならない品質×量の乗数があるからです。
非常に代表的な50行の本当に高品質な入力があり、大量のユーザー問題を代表し、望む動作に本当に一致したグレーダーがあれば、驚異的なパフォーマンスを発揮できます。一方、LLMを使用して1000行の合成入力を生成しても、それほど役立ちません。したがって、品質は量よりもほぼ重要だと言えます。
それは非常に理にかなっています。それに加えて、よく受ける質問の一つは、特にこれらのツールをまだ本番環境に導入していない場合、評価を実行するための多様なデータセットをどのように作成するかということです。
go-to-marketアシスタントを構築する際、それらのワークフローを実際にサポートするエンジニアリングチームは、専門家が実際に何を尋ねているか、何に興味を持っているかを理解するために、go-to-marketチームのすぐ隣に座っています。
これにより、継続的に最適化するすべての反復で、人々が実際に対話している微妙なニュアンスと実際のクエリをキャプチャする、多様な質問の良いセットを構築できます。非常にクールです。
素晴らしい。それでは、いくつかの実例をカバーして、最後にQ&Aの時間を残したいと思います。最初の例は、RAMPが構築した調達エージェントの短いビデオです。
彼らは実際にChatKitを使用して、ソフトウェアを要求する人にこのUIを視覚化しました。バックエンドでエージェントビルダーを使用して、実際にエージェントフローをオーケストレートしました。そして評価を使用して、本番環境で大規模に機能することを確認しました。
これはまだプラットフォーム上でライブではありませんが、近い将来そうなることを願っています。これは彼らが実際に構築したプロトタイプの簡単な説明でした。
RAMPはAgentKitスタックにより、このプロトタイプを70%速く構築できました。これは非常に素晴らしいことだと思います。2四半期ではなく2つのエンジニアリングスプリントに相当します。
Ripplingについては、実際にこのプロジェクトに少し取り組んだと思います。彼らが何を構築したか、どうだったかを共有していただけますか。
はい、もちろんです。当初、エージェントSDKを通じてこれをどのように仕様化できるかを考えていました。難しい課題の一つは、専門家と論理的に健全なワークフローを構築する能力との間の整合性を得ることでした。それで、彼らの実際のgo-to-marketユースケースが何かを理解するために、彼らと本当に座って、そこから逆算することができました。
彼らのチームと話し合うのは楽しかったですし、エージェントビルダーのようなツールを使用するのは喜びでした。次のバージョンについて、本当に良いフィードバックをたくさん得ました。
それは素晴らしいですね。同様に、AI分野で多くの素晴らしい仕事をしているHubSpotは、ChatKitを使用してBreezeアシスタントを強化しました。進めてください。
彼らは最初に述べたように、数週間分のフロントエンド時間を節約しました。エージェントを最初から最後まで構築するのは、関連する複雑なステップのそれぞれのために非常に時間がかかります。したがって、これらの多数の複雑なステップの一つだけでも支援できれば、この場合UI面で、それは有用な支援です。
そして最後に、Carlyle and BainというEvalの素晴らしい顧客が2社います。彼らは評価データセットで25%の効率向上を見ることができました。これは素晴らしいことです。
AgentKitをローンチしたとき、これらは初期の顧客の一部です。AgentKitが現在、スタートアップ、Fortune 500、そしてその中間の企業の技術スタックを強化していることがわかります。
これらは異なるタイプのエージェントです。ワークアシスタントから調達エージェント、ポリシーエージェントまで、幅広いユースケースがあります。大手食料品小売業のAlbertsonsには、マーチャンダイジングインテリジェンスエージェントがあります。Bainにはコード近代化があります。
ここでのユースケースの幅広さを見るのは本当にクールです。それでは、チャットからのQ&Aに移りましょう。次のスライドに進みますか。
forループブロックをどのように追加できますか。マーク、それを取りますか。
良い質問です。forループはありませんが、エージェントビルダー内で利用可能なwhileループがあります。完了基準が満たされているかどうかに応じて、異なるエージェントワークフローを継続的に実行できます。
明らかに、エージェントSDKを使用すると、それをコードベースに持ち出して、独自にオーケストレートできます。私たちの解釈をv0として使用するかもしれません。しかし、forループの代わりに、whileループをサポートしています。
その終了基準が満たされるまで、ワークフロー全体で反復できるようにするためです。それが役立つことを願っています。他に何がありますか。
AgentKitとエージェントSDKはどのように比較されますか。AgentKitはこれまでのところ、まあ、少し戻ります。AgentKitは、私たちOpenAIがエージェントを構築する際に日常的に最も有用だと思うツールについて意見を述べてきた製品スイートです。
エージェントSDKはAgentKit全体を動かしており、AgentKit内でできることのほとんどは、エージェントSDK内でも、またはAPI経由で利用可能です。これまでのところ、そのパリティをもう少し近づけるために、これらの変更の多くをロールアウトし続けています。
しかし、将来的には、AgentKitには、クラウド上でこれらのワークフローをホストする能力を拡張できる機能も含まれると想像しています。
したがって、従来のChatKit実装を使用するのではなく、API経由でこれらのワークフローをトリガーすることもできます。これにより、基本的にクラウド上でエージェントSDKをホストできます。
非常にクールです。そして、私が言うとすれば、エージェントビルダーは、機能的にはエージェントSDKと同等ですが、それらのエージェントを実際にオーケストレートするためのキャンバスベースのビジュアル方式であるのに対し、エージェントSDKは、直接コードにジャンプするバージョンのようなものです。非常にクールです。
すぐに使えるMCPサーバーと独自のMCPサーバーの構築をどのように行いますか。
その通りです。いくつかのMCPサーバーがあります。リモートMCPサーバーをサポートしています。つまり、MCPサーバーはクラウドでホストされているか、公開されているインターネット上でホストされている必要があります。
独自のMCPサーバーを構築する際、認証に関する多くの考慮事項により、独自のMCPサーバーを構築する必要があります。とはいえ、Gmailやカレンダーなど、毎日使用する多くのプロバイダーは、すぐに使える接続があり、APIキーを貼り付けるだけで、サポートしているすべてのツールを使い始めることができます。
これらのいくつかは、書き込みのようなことを行う完全な機能がないと思います。たとえば、Gmail API経由でメールを書きたい場合、現在サポートされていないと思います。
そこで独自のMCPサーバーを立ち上げたい場合があります。MCPについて本当に気に入っているのは、認証を可能にし、そのフローが実際にどのように見えるかをブラックボックス化することです。
独自のパーソナルアクセストークンを持ち込みたい場合でも、OAuthのようなものを経由して、取得した最後のトークンをMCPサーバーに渡す場合でも、どちらも保護されたソースへの認証のための完全に素晴らしいオプションです。
他に質問はありますか。はい。分類器エージェントと異なるエージェントへの分岐ロジックをいつ推奨しますか。
これは素晴らしい質問だと思います。これは私たちがよく受ける質問です。なぜなら、モデルにより多くのツールと指示を追加すると、一般的にパフォーマンスが低下することがわかっているからです。
100のツールがある世界を想像してください。モデルがそれらの100のツールのどれを選択するかを許可することは、ますます困難になります。より現実的には、100のツールはないかもしれませんが、20はあるかもしれません。そして、エージェントの各ユースケースは、それらのツールをまったく異なる方法で使用する可能性があります。
エージェントについて考えるのが好きな方法の一つは、このエージェントのコアコンピテンシーは何かというロジックを階層化することです。このエージェントに使用してもらいたいツールのネットセットは何で、その特定の方法でのみ使用するのは何ですか。
これらのツールの呼び出し方法、それらのツールのコンテキストでの指示の解釈方法についてモデルを混乱させ始めた瞬間、別のエージェントに分岐したいと思います。
たとえば、3つの異なるGTMユースケースを探していたケースでは、ウィジェットを出力するメールエージェントを構築していますが、リード資格審査を行うのにも最適ではないかもしれません。
したがって、同じツールを使用している場合でも、出力を少し異なる構造にしたい場合、モデルに出力を少し異なる解釈をしてもらいたい場合、異なるエージェントに分岐するのが良いです。
わかりました。マルチモーダルユースケース、特に画像やファイルの分析にAgentKitを使用できますか。
その通りです。これはAgentKitの素晴らしいユースケースです。カバーしたプレビューセクション内でファイル入力をサポートしています。ファイルをアップロードして、プレイグラウンドで遊ぶこともできます。
本当に興味深いのは、この動作をChatKitにも伝播することです。または、ChatKitもこの動作をエージェントビルダーに伝播します。ChatKit内でファイルをアップロードすると、それもホストされているエージェントビルダーバックエンドに渡されます。非常にクールです。
ここで終わりです。興味があれば、いくつかのリソースを残しておきたいと思います。AgentKitドキュメントは、開始するのに非常に役立つ場所です。先週、私たちはクックブックもリリースしました。これは、今日示したものと非常に似たユースケースをさらに詳細に説明しています。
ChatKitを試して、どのようにカスタマイズできるかを確認したい場合は、Chat Studio。そして最後に、今後のビルドアワーと過去のビルドアワーについて詳しく知りたい場合は、GitHubのビルドアワーリフィル。
それで終わりだと思います。もしよければ、そうですね。今後のビルドアワーは2つあります。エージェントRFT。つまり、今日話したことに基づいて。
ツール呼び出しやカスタムグレーダーなどのモデルを実際にカスタマイズするにはどうすればよいですか。それは11月5日になります。今日のセッションに基づいて、次のセッションで構築することを本当に楽しみにしています。
そして12月3日には、エージェントメモリパターン。両方のセッションでお会いできることを願っています。このリンクで登録に関する詳細情報を入手できます。
それでは終わりです。この素晴らしいデモをまとめていただき、本当にありがとうございました。とても楽しかったです。視聴していただいた皆様、ありがとうございました。エージェントの構築を楽しんでいただければ幸いです。
コメント