重複メッセージを避けるミニエージェントとしてトピックを設計する

Note

この記事では 、標準ハーネスにおける会話トリガーを持つトピックの特徴と挙動について説明します。 Access標準エージェントおよびエージェントフローで標準機能にアクセスする方法を学びましょう。

この記事では、重複メッセージを避けるためのデザインのベストプラクティスに焦点を当てています。 重複メッセージは文脈のギャップから生じるため、デザインは文脈の流れを理解することから始まります。 標準ハーネスのコンテキスト分布の図を参照し、オーケストレーション層が各コンポーネントとコンテキストをどのように共有しているかを理解してください。

標準ハーネスでは、プランナーはツールやエージェントと同じ方法でトピックを呼び出します。 各トピックの説明を読み取り、そのトピックの使用タイミングを判断し、そのトピックのアクティブなコンテキストとユーザーからの入力を生成し、トピックが終了するとそのトピックの出力を読みます。 明確な記述、明確に定義された入力、明確な出力を持つトピックは、計画内のミニエージェントのように振る舞います。オーケストレーション層はトピックに必要なものを集め、トピックはロジックを実行し、生成したものを返し、オーケストレーション層は回答をフォーマットし、ユーザーに伝達します。

ユーザーにとって、ミニエージェントは会話のように感じられます。 ユーザーはトピックが必要な入力を集める中で自然に話し、フォローアップの質問をし、エージェントから豊かな回答を得ることができます。

Tip

標準ハーネスでは、決定論的論理をトピック内に保持し、ユーザーコミュニケーションはオーケストレーション層に任せます。 トピックが実行する前に入力として必要な値を収集し、実行後に出力として返す。

トピックに名前を付けて説明し、オーケストレーションレイヤーがそこにルーティングできるようにします

オーケストレーション層はトピック名と記述を使ってリクエストをトピックにルーティングします。 オーケストレーションレイヤー用に両方書いてください。 テーマに明確で具体的な名前をつけ、その役割を説明しましょう。

説明文は2つのパートに分けて書いてください。 まず、いつその話題を使うべきかを説明してください。 次に、トピックの出力に基づいて何をすべきかを簡単に説明し、オーケストレーションレイヤーがリクエストのルーティングや結果の処理方法をトピック実行後にどうすべきかを説明してください。 そのトピックの内部画面や手順は説明しないでください。

例えば、アカウント残高リクエストに回答し、 answered 出力でレポートを返すトピックには以下の説明を用いてください。

This topic handles account balance requests. 
If its answered output is true, the user has already received their response and it should not be answered again.

トピックを実行する前に入力を収集する

トピックに必要な値ごとに入力を与えます。 オーケストレーション層は、その能動的なコンテキストから、そしてトピックを実行する前に会話形式でユーザーからこれらの値を収集できます。 入力は変数に入力され、そのトピックのロジックがその変数を使用します。

入力名、説明、エンティティ、検証設定を使って、オーケストレーションレイヤーが入力を正確に入力するのを助けます:

  • 入力名は オーケストレーション層に何が収集されているかを伝え、オーケストレーション層がユーザーに値を尋ねる必要がある場合の質問を形成するために使われます。 メカニズムではなく、価値で名前を付けましょう。 例えば、入力をOData filterではなくThe user's request about...に名前を付けることで、オーケストレーションレイヤーがユーザーにクエリを書くように頼まないようにします。

  • 入力の記述は オーケストレーション層へのプロンプトであり、ユーザー向けのラベルではありません。 トピックが値を受け取る前に、オーケストレーションレイヤーに解釈、制約、変換方法を伝えるために使います。 オーケストレーション層は、会話からの入力、以前の出力、またはユーザープロファイルデータからの入力を埋めることができます。 セットの中から選び、制約を適用し、スキーマ情報に基づいてクエリを書くことができます。

    入力記述はオーケストレーション層に特定の形式で値を構築するよう指示することさえ可能です。 例えば、リストをフィルタリングするトピックは、ユーザーのリクエストからフィルターを構築する方法をオーケストレーション層に伝える説明を受けた入力を受け取ることができます。これには利用可能なフィールド、クエリ構文、いくつかの例が含まれます。

  • エンティティは 入力の許容型と範囲を設定するため、有効な値だけがトピックのロジックに到達します。

  • 高度な検証や条件付き論理、Power Fxは決定論的なチェックとして機能します。 条件が満たされていない場合、入力欄に値が入力されるのを防いだり、トピックが動作するのを防いだりできます。

決定論的入力チェックはコードと同じくらい信頼性が高いため、計画の他の部分が生成される際にもビジネスルールやコンプライアンス制約は尊重されます。

論理とガードレールはトピックの中に留めておきましょう

トピックの決定論的な処理は、そのトピック内に収めてください。つまり、実行するステップ、行う計算、適用するルールはすべてトピック内に含めます。 メーカーはコントロールを行使し、毎回同じように動く重要なビジネスロジックを適用します。まるで道具のように。

結果を出力として返し、ユーザーにメッセージを返すのではなく

トピックが終了したら、出力として返すと、オーケストレーションレイヤーがそれを使って応答を決定できます。 トピックが直接ユーザーにメッセージを送るよりも、この方法の方が好みです。 オーケストレーション層が応答している間にユーザーに書き込みを行うトピックは、重複メッセージの一般的な発生源です。オーケストレーション層はトピックがすでに応答したことを知りません。

Important

出力が返っていないトピックは警告サインです。 もしトピックがユーザーに応答したり、値を収集したり、カードを表示しても何も返さない場合、オーケストレーションレイヤーは何が起こったかを把握できず、同じリクエストに再度応答することがあります。 この挙動はトピックからの重複メッセージの最も一般的な原因です。

以下のテスト済み出力は、文脈やコミュニケーションの信頼できるパターンとして強く推奨されます。 トピックがユーザーに直接回答する場合でも、すべての情報をオーケストレーション層に返して回答する場合でも適用されます。

アウトプット Description 使用方法
answered このトピック内でユーザーがすでに満足のいく回答を受け取っている場合は、その通りです。 回答や結果が表示されたらトピックでtrueに設定してください。 以下の例のトップレベル命令を参照すると、オーケストレーションレイヤーがその部分のリクエストを応答済みとして扱い、繰り返し処理しないことが保証されています。
choiceReceived ユーザーがすでにこのトピック内で選択しているなら、それは正しいことです。 ユーザーがカードボタンを選択するなどの選択をしたら、その設定をtrueに設定してください。 オーケストレーションレイヤーは質問を再問いません。
balanceValue トピックが取得し、すでにユーザーに提供した値。 トピックが取得した重要なデータに設定し、そのデータの出力に名前を付けます。 オーケストレーションレイヤーは再度取得するのではなく、コンテキストから再利用します。
messageSummary 文脈を踏まえるために、すでにユーザーに表示された内容の簡単な要約です。 メッセージに後で計画が必要とする情報が含まれている時に設定してください。 オーケストレーションレイヤーはユーザーに伝えられた内容を把握し、それを繰り返したり矛盾したりしません。

古いモデルでは出力だけで十分です。 新しいモデルでは、オーケストレーション層に応答前に出力を確認するよう指示するトップレベルの命令も必要です。

このサンプルの最上位命令は、検証済みの動作例です。 必要に応じて編集やカスタマイズをしてください。

どのトピックやエージェントが呼ばれるたびに、返信を決める前に必ず「応答済み」のブール出力を確認してください。 トピックやエージェントはユーザーと独自のコミュニケーションチャネルを持っています。 「回答済み」が真の場合は、少なくとも1つの出力変数を使ってリクエストに適切に応答されたと常に仮定し、出力の記述に基づいてどの変数かを確認してください。 答えた内容に対して気まずく返事をしないようにしましょう。 回答されていない出力だけを提供し、次のステップへ自然に会話を続けましょう。

チャネル という用語は 統合チャネルを指すものではありません。 これはオーケストレーション層に、ユーザーが他のコンポーネントを通じてすでに答えを見ているかもしれないことを知らせるプロンプトデバイスです。 エージェントのモデルによっては、エージェント自身の命令に同様の命令を配置する方が効果的になる場合があります。 繰り返し メッセージを避けるための堅牢なトップレベル命令のデザインで詳しく学びましょう。

トピックでオーケストレーション レイヤーが再現できないもの（たとえば、アダプティブ カード）を表示する必要がある場合は、トピックでそれを表示し、回答済み状態の出力を返します。

Tip

重複メッセージと応答状態出力については、 重複メッセージを避けるためのデザインベストプラクティスで詳しく学びましょう。 標準ハーネスのコンテキスト配布で、オーケストレーション層とトピック間でコンテキストがどのように移動するかを学びましょう。

トピックにまだユーザーの意見が必要なときに回答を集めましょう

例えば、ボタンで選択肢を集めるために質問をしたりカードを見せたりするトピックもあります。 この設計アプローチは妥当です。 ユーザーが方針を変えた際に未解決の質問やカードを解決してから回答する必要があることを覚えておいてください。

質問ノードを追加する前に、その値を入力として収集できるかどうかを検討してください。 質問ノードを保持する際は、質問が開いている間にユーザーが別の質問をする場合に対応します。 詳細は 「未解決の質問」または「別のリクエストが処理された後にカードが戻る」でご覧ください。

例:アダプティブカードの選択が再リクエストされるのを防ぐ

トピックでは、ユーザーにアダプティブカードでカテゴリーを選ぶよう求めます:

あなたの問題はどのカテゴリーですか?

[請求][技術][会計]

オーケストレーションレイヤーは会話履歴を通じて質問テキストを受け取りますが、カードが表示されたことやユーザーがボタンを選択したことは知りません。 ユーザーがボタンを選択すると、オーケストレーションレイヤーは同じ質問をプレーンテキストで再度尋ねることがあります。

この問題を回避するために、トピックがその動作を報告するように設計してください:

アウトプット タイプ 何に設定すればいいか
answered 真/偽 トピックがすでにユーザーに答えやプロンプトが表示されている場合は真実です。
choiceReceived 真/偽 ユーザーがすでに選択をしている場合は、そうです。
selectedCategory テキスト 選択が受け取られるたびに、この出力にはユーザーが選んだカテゴリが含まれています。

トピック説明に指示を追加し、オーケストレーションレイヤーが成功した実行の意味を理解できるようにします。 Return resultsのトップレベル命令を出力として利用し 、ユーザーにメッセージ を送るのではなく、新しいモデルでは再度問いただしる前にこれらの出力を確認します。

標準ハーネスのトピックに関するベストプラクティス

  • トピックには明確で具体的な名前と、いつ使うべきか(そして実行後に何をすべきか)を説明する説明を与えてください。
  • トピックに必要な値ごとに入力を追加し、入力記述をオーケストレーション層にプロンプトとして書きます。
  • 入力項目には、そこに入力される値に基づいて名前を付けます。これは、オーケストレーション層がユーザーに確認を求める必要がある場合、その名前が質問文になるためです。
  • 決定論的な論理や、エンティティ、検証、パワーFXなどのガードレールはトピック内に含めておきましょう。
  • トピック内で直接ユーザーにメッセージを送るのは避けてください。 メッセージノード、質問ノード、またはアダプティブカードは必要な場合にのみ使用してください。
  • 回答済み状態の出力を含む結果を出力として返します。
  • Last updated on