6

ウェビナーでは、複数の会話ワークスペースを使用してプロジェクトのさまざまなトピックを処理することについて言及しました (機能的な会話とトピック外の会話など)。この設計をどのように実装する必要がありますか?

2 つのワークスペースがあるとします。1 つは機能的なトピックで、もう 1 つはトピック外です。どのワークスペースにリクエストを送信する必要があるかを決定する方法とロジックは?

そして、この決定ロジックは、サーバー バックエンドまたはワークスペース ロジックに実装する必要がありますか?

ありがとう。

4

2 に答える 2

0

私に提案され、現在実験中の別のアプローチは、マスタールーティングワークスペースと、場合によっては複数のアプリケーションワークスペースを持つことです。最初のインスタンスでは、ユーザーの入力は、ルーティング先のアプリケーション ワークスペースを決定する高レベルのインテントを持つマスターに送信されます。アプリケーション ワークスペースには、より詳細に分割するインテントがあります。

微妙な点は、その後のすべての入力を、選択したアプリ ワークスペースとマスター ルーターの両方に並行して送信することです。前述のシーケンシャル アプローチに対するこの潜在的な利点は、マスター ワークスペースが、トピックから外れたり、信頼度が低いために引き渡されるのではなく、制御に取り組むことができることです。これは、オフトピックを一元化できるようにするだけでなく、マスターで初期ルーティングと同じインテントを使用して、他のワークスペースへの動的ルーティングを取得できることを意味します。

オーケストレーション レイヤーにセッションをこのようなコンテキストの配列として管理させることでこれを行いました

{
   currentWs: xxxx,
   contexts:  {
      ws_idn: {}, // basically an array of conversation contexts,
      ....       // keyed on workspace_id's
   }  
}

入力は、マスター ワークスペースと、マスターによって現在としてマークされているワークスペースに (そのワークスペースに関連するコンテキスト オブジェクトと共に) 送信されます。コンテキストを失うことなく、複数のチャットボット アプリケーション間をシームレスに切り替えることができます。

于 2016-12-24T13:54:18.127 に答える
0

分類したいものを使用して、最初の一連のインテントを作成します。それらのインテントの 1 つは「トピック外」であり、トピック外の質問をすべて保持する必要があります。

2 番目のワークスペースはオフ トピックですが、関連するトピックに分割されています。

呼び出しを行って Offtopic を取得したら、2 番目のワークスペースを呼び出します。トピック外の性質を返す必要があるため、それに対してアクションを実行できます。

主なインテント セットをテスト/微調整して、トピックに干渉しないようにする必要があります。たとえば、会話がスポーツ用品の販売に関連している場合、スポーツに関連するオフ トピックは聞き取りにくい可能性があります。

その時点で、自信を考慮に入れる必要があるかもしれません。

于 2016-08-07T20:16:26.137 に答える