6,006 文字
皆さん、こんにちは。私はJerryです。SAAのAIプロダクトリードを務めています。本日は同僚のDanielと一緒に来ました。彼はOniのAIリードエンジニアの1人です。この1年間、私たちは企業向けにエージェントやエージェント型ワークフローを多く構築してきました。本日は、この分野での私たちの知見をいくつか共有させていただきたいと思います。
まず、なぜこのミッションを始めることになったのか、その理由についてお話しします。SAAでの私たちのミッションは、知識へのアクセスを解決することです。知識へのアクセスとその解決は、メタな問題を解決することだと考えています。これが解決されれば、より多くの人々がより早く自分のミッションを達成できると信じています。実際、本日までに新たに5,500万ドルのベンチャーラウンドを発表しました。本日はそのことについても、大変嬉しく思いながら共有させていただきます。
では、サーナで何をしているのかについてお話しします。サーナの核となるのは、AIアシスタントプラットフォームです。非構造化データ、例えば会議メモからのデータや、プラットフォームで稼働している100以上の統合からのデータを集めています。また構造化データ、これは任意のデータベースや記録システムからのデータも扱っています。これらすべてのデータは、企業の検索機能や自然言語チャット、そして本日発表したばかりのシートを通じて、SAのユーザーインターフェースで利用可能です。シートでは、より複雑なワークフローやデータ抽出が可能になります。
ただし、本日のプレゼンテーションの残りの部分と私たちの知見は、SIIの構造化データとのチャット部分に焦点を当てます。構造化データフローを扱う私たちのエージェントは、2種類のワークフローを処理できます。データ分析と、より複雑なトランザクションワークフローです。これは重要です。なぜなら、このタイプのワークフローによって、ユーザーは統一されたプラットフォームを離れることなく、複数のソースからのデータとSAAで直接やり取りできるからです。
それでは、これまでに構築してきたものをライブデモでお見せしたいと思います。これが私たちのプラットフォームです。ここでチャットを使用でき、SIに手伝ってもらいたいプロンプトがあります。ここでは次のタスクを依頼しています。特定のユーザーが所有する、CRMアカウントの特定のステージにある機会をリストアップするように依頼しています。SAは実際にバックグラウンドでいくつかの処理を行う必要があります。単純な1つの処理ではありません。まず説明を取得し、検索を完了し、それをクエリシーケンスにまとめる必要があります。
他のことも依頼できます。例えば、Googleドキュメントに追加するなどです。サーナがバックグラウンドで実際に何を行ったのか、正確にお見せできます。最初のステップでは、Salesforceのスキーマを確認する必要があります。機会とは何を意味し、Salesforceの他のすべてとどのように結びついているのか、Salesforceのアカウントや人々とどのように結びついているのかなどです。
2番目のステップは、Fredaが何を意味するのかを理解することです。特定のユーザーを探しており、機会と結びつけられるように、そのユーザーの権利を理解する必要があります。最後に、Googleクエリの最終クエリで、すべてを一緒にコンパイルし、それが結果を得た方法です。
ここで、例えばGoogleドキュメントにこれをプッシュするように依頼しました。好きな変更を加えることができます。ここにデモがあるとして、この金額を変更してみましょう。そして、Sunで直接ドキュメントを簡単に作成できます。これが完了したら、Google Docsで表示をクリックでき、新しいシートで開かれます。
これがSAAで構造化データとやり取りする1つの方法です。このタイプのデータとやり取りする別の方法は、ここにあるタスクを通じてです。これは事前に作成されたユーザープロンプト、またはテンプレートとして考えることもできます。ここでは、同僚が行った会議を選択しています。これは実際にzoomで行われた会議です。そして、SAAに特定のことを抽出するように依頼しています。例えば、会議で予算について話し合われたか、特定の競合他社について話し合われたか、会議で言及されたニーズは何かなどです。そしてそれらの情報をSalesforceアカウントの関連フィールドに送信してほしいと依頼しています。
サーナは実際にいくつかの処理を行います。まず、会議から機会名をSalesforceアカウントと照合し、その後、残りのアクションを確認できるようにします。例えば、タイムラインが実際に10月30日だった場合、それを変更でき、機会の更新をクリックするだけで、これは自動的にSalesforceと同期されます。Salesforceに行って、実際のbnctフィールドまでスクロールすると、これが実際にここにも反映されているのが分かります。
では、SAAで何が構築可能かを少しお見せしましたので、これらをすべて実際にどのように構築できたのか、同僚のDanielに説明を譲りたいと思います。
ありがとうございます、Jerry。アーキテクチャの説明に入る前に、私たちが見てきた特定の問題について話し、分析を提供したいと思います。エージェントは時々、複雑なツール呼び出しフローの順序付けに失敗することがあります。例えば、先ほど見たSalesforceの分析では、これら3つの特定のツールが必要でした。
最初のものはスキーマの取得です。エージェントがSQLクエリに直接進もうとした場合、私たちのSalesforceインスタンスがどのように見えるか実際には分からず、間違ったSQLを出力するかもしれません。そこから回復できるかもしれませんが、これはリアルタイムのやり取りをするユーザーにとって良くありません。
そこで、分析を行い、このような問題に対してどのようなエージェント構成が成功するか、しないかを正確に把握したいと思いました。最初に見たのは、指示を提供する異なる戦略です。多くの方がGPD 40のようなモデルのチャットAPIに慣れているかもしれませんが、振り返ってみると、エージェントやアシスタントに指示を与えたい場所を考える場合、それはシステムメッセージの中かもしれません。
私たちのものはAIで、パーソナリティのガードレールを与えます。それはユーザーメッセージの中にもあり得ますし、ツールの中にもあり得ます。各リクエストにはツールが付属し、ツールには呼び出す可能性のあるスキーマがありますが、説明も付いています。これらのシーケンスの指示をどこに置くべきかを検討しています。
1つの戦略は、ユーザーメッセージでハウツーガイドを提供することです。例えば、「ツールを使用する場合は、ツールA、次にツールB、次にツールCを使用してください」というように要点を伝えます。戦略2は、ツールの説明で依存関係をリスト化することです。「ツールCはツールBに依存し、ツールBはツールAに依存する」というように記述し、そこからツールA、B、Cの順序で実行する必要があることを推論できます。これは同じ指示を伝える異なる方法です。
そこで、これらの戦略のどちらがより成功するかを判断するため、異なるエージェント構成のグリッドを作成しました。上部に2つの異なる指示戦略が見え、側面にはエージェントに与えたツールの数が異なるものが見えます。
私たちが発見したのは、ユーザーメッセージでこのハウツーガイドの指示を提供することが非常に重要だということです。15個のツールがあっても、エージェントは正しいものを選び出し、ワークフローを成功裏に完了できました。これは3ステップのワークフローの1つに対してのことだと明確にしておきましょう。
このアプローチは、特に1つの目的を持つ単純なエージェントの場合、システムメッセージでもうまく機能します。それは素晴らしい解決策だと思います。私たちはユーザーメッセージを使用することを好みます。なぜなら、それによって会話履歴の異なる点でこれらの指示を置くことができるからです。
右側のツールの説明アプローチはあまりうまく機能しませんでした。興味深いことに、これは言い回しの問題ではありません。ユーザーメッセージからツールの説明に同じプロンプトをそのままコピー＆ペーストしても、これらの複雑なワークフローの順序付けに失敗します。同じトークンに変換されているにもかかわらず、適用の仕方が少し異なるのです。
これは、LLMが干し草の山の中から針を見つけ出すのが得意だという人々の見方と非常に一致していると思います。15個のツールは問題ありませんが、これらの推論や順序付けのタスクには、もう少し指示が必要かもしれません。そのため、ハウツーガイドのアプローチは素晴らしい方法です。
より単純なワークフローについては、同じ分析を実行し、すべての面で成功することが分かりました。これは素晴らしいことです。エージェントが一度に1つのツールだけを使用する必要がある場合、2つのツールでは、おそらく指示について深く考える必要はなく、同じエージェントに多くのツールを組み込むことができるでしょう。
さて、その分析を終えて、サーナでの私たちのソリューションに戻りましょう。もちろん、複雑なワークフローと単純なワークフローの両方を扱いたいと考えています。そこで、ツールセットと呼ぶ内部インターフェースを作成しました。ツールセットには名前があり、ここで見ているのは、先ほどデモを行ったSalesforceエージェントのデータクエリワークフロー用のツールセットです。
名前は「explore Salesforce records」です。もちろん、このツールセットの一部として必要な3つのツールがあり、ツール間の使用指示もあります。コードベースから逐語的にコピーすると、「SQLを使用する場合（これはSalesforceのバージョンのSQL）、常にdescribe APIを参照してクエリするスキーマを理解し、関連する外部関係のIDを見つけるためにfind record IDツールを使用する」などとなります。
このように、順序付けの指示を伝えています。全体として、このツールセットは、特定のコンテキストで特定のワークフローを実行できるようにするパッケージです。しかし、もちろんこの講演のタイトルに戻ると、私たちは多才なエージェントについて、そしてこれらすべてのワークフロー、つまりGoogleドキュメントの作成、Snowflake、Salesforceのクエリなどを同じユーザーインターフェースから行うという問題をどのように解決するかについて話しています。
そのためには、ルーティングが必要になります。ツールセットを選び出すルーターLLMがあり、そのために各ツールセットには特別な選択基準もあります。これもコードベースから逐語的にコピーすると、「このツールセットは、SQLクエリを使用して任意のタイプのSalesforceレコードを検索またはリストアップすることを可能にします。書き込み操作は扱わず、selectのみを扱います。以下のいずれかが真である場合」となります。
このように、ユーザーのメッセージがこの特定のツールセットによって処理されるべき非常に具体的な条件を定めることができます。こうすることで、ユーザーが誤って多くのツールを目の前に突きつけられることがないようにし、かつエージェントのワークフローを望む場合は、それを完了するための最適なツールセットを確実に得られるようにします。
これらすべてを結びつけると、バックエンドがユーザーからの新しいメッセージを受け取ると、先ほど説明したツールセットルーターと、主要なクエリプランナーと検索エンジンを並行して開始します。検索エンジンは一種のデフォルトのツールセットで、これは実際にSonet AIの要となるものです。ベクトル検索、ウェブ検索、ナレッジグラフ検索を備えており、これらすべてを合わせて、会社の知識全体から構造化および非構造化データを引き出しています。ツールセットを選択すると、それは検索結果と共に再帰的エージェントに送られます。
この部分は非常に重要です。これにより、例えば会議を分析し、その非構造化データを取り出してSalesforceに入力するような要求が可能になります。検索結果を取得し、ツールセットを使用して構造化された場所に配置できる仕組みです。
最後に話したいのは、高い整合性を持つツールレスポンスについてです。これは私たちが非常に重視しているもう1つの点です。エージェントはAPIと直接やり取りすると考えることもできますが、サーナのようなシステムでは実際にはそうではありません。エージェントはまず検証者とやり取りし、おそらくユーザーともやり取りします。Jerryが要求を送信する前に修正できるのを見ましたし、ユーザーはキャンセルすることもできます。
そこには、エージェントに表示できると考える様々なシステムの相互作用があり、エージェントが今後インテリジェントな決定を下せるようになります。エージェントに送り返す可能性のあるツールレスポンスの例として、1.ツールの使用がスキーマ検証を通過した、2.ユーザーが名前フィールドを修正した、3.ユーザーが午後2時41分に送信した、4.APIが成功で応答した、などがあります。
このように、私たちのエージェントは常にユーザーとの間で何が起きているのか正確に把握でき、これらの高度なコラボレーションワークフローを可能にします。
このプレゼンテーションから得られる2つの重要な実践的なポイントは、まず第一に、ユーザーメッセージまたはシステムメッセージを通じてツールの順序付け指示を追加することです。これにより、より複雑なワークフローが可能になります。第二に、エージェントが何が起きているのかを理解し、効果的にコラボレーションできるよう、包括的なシステムとユーザーのフィードバックをツールレスポンスで提供することです。
これらは、サーナでの研究から得られた知見のほんの一部です。私たちは汎用エージェントの構築を続けることにワクワクしており、それを皆さんの会社の知識全体と組み合わせることで、大きな生産性の向上を実現し、より大きな問題を解決する手助けができると考えています。ありがとうございました。
コメント