ベスト プラクティス

以下のベスト プラクティスは、堅牢なエージェント アプリの構築に役立ちます。

簡潔な目標

目標は、エージェントの目的の簡潔な説明にする必要があります。

品質の指示を行う

指示は以下のようにする必要があります。

  • エンドユーザーの問題を解決するための段階的なアプローチを反映する
  • 大まかな指示で簡潔な自然言語の文
  • 率直に、ツールの使用シナリオを指定する

エージェントごとに 1 つ以上のサンプル

サンプルはエージェントごとに 1 つ以上必要ですが、4 つ以上使用することをおすすめします。サンプルにはハッピーパスのシナリオを含む必要があります。

十分なサンプルがないと、エージェントで予期しない動作が発生する可能性があります。 エージェントが応答しない、または予期したとおりに動作しない場合は、欠落しているか、明確に定義されていないサンプルが原因である可能性があります。サンプルを改善するか、新しいサンプルを追加してみてください。

指示とサンプルの正確性

明確で説明的な指示を書くことも有用ですが、エージェントの動作の精度を決めるのはサンプルの質と量です。言い換えると、完全に正確な指示を与えるよりも、徹底的なサンプルを書くことに多くの時間をかけてください。

ツールスキーマの operationId フィールド

ツールのスキーマを定義する場合、operationId 値は重要です。エージェントの指示では、この値が参照されます。このフィールドの名前付けの推奨事項は次のとおりです。

  • 文字、数字、アンダースコアのみ。
  • スキーマに記述されているすべての operationId の中で一意にする必要があります。
  • 提供される機能を反映した意味のある名前でなければなりません。

ツールスキーマ検証

ツールスキーマは、検証する必要があります。Swagger Editor を使用して、openAPI 3.0 のスキーマ構文を確認できます。

空のツール結果を処理する

エージェントがレスポンスを通知するためにツールに依存している場合、空のツールの結果により、エージェントの予期しない動作が発生する可能性があります。場合によっては、エージェント LLM がツールの結果の代わりにレスポンスで情報をハルシネーションします。これを防ぐには、エージェント LLM が単独で応答しようとしないように、具体的な指示を追加します。

一部のユースケースでは、エージェントのレスポンスをツールの結果や提供データに焦点を合わせ、エージェント LLM の知識に基づいてのみレスポンスを軽減する必要があります。

ハルシネーションを軽減するための指示の例:

  • 「このツールを使用して、すべてのユーザーの質問に回答する必要があります」
  • 「ツールからデータが返されない場合は、ユーザーのクエリに対する答えがわからないと回答してください」
  • 「ツールからデータが返されない場合は回答をしないでください」

Gemini を使用してスキーマを生成する

Gemini では、スキーマを生成できます。たとえば、「Google カレンダー用にサンプルの openAPI 3.0 スキーマを作成できますか」を試してください。

集中型エージェント

非常に大規模で複雑なエージェントは作成しないでください。各エージェントでは、具体的で明確なタスクを達成する必要があります。複雑なエージェントがある場合は、小さなサブエージェントに分割することを検討してください。

ループと再帰を回避する

エージェント アプリをリンクする際にループや再帰を作成するような指示はしないでください。

サンプルにルーティング情報を提供する

エージェントが別のエージェントにルーティングする必要がある場合は、この情報をサンプルに提供する必要があります。この情報は、入力と出力サンプル セクションの出力情報を持つエンドサンプル フィールドから、サンプルへ提供されます。

たとえば、このフィールドの最後の文は、「以後のクエリをデフォルト エージェントに再ルーティングする」などです。

Dialogflow CX Messenger の JavaScript 関数を使用してカスタマイズする

Dialogflow CX Messenger を使用する場合、次の機能は、ユーザーのパーソナライズ情報をウェブ インターフェースからエージェントに送信するのに役立ちます。