ウェブセミナーでは、複数の会話ワークスペースを使用してプロジェクトのさまざまなトピックを処理する方法について説明しました（機能的な会話とオフトピックなど）。このデザインをどのように実装する必要がありますか？複数のワークスペースでワトソン会話を実装する方法
2つのワークスペースがある場合、1つは機能トピックで、もう1つはオフトピックです。どのように決定するのか、どのような作業領域にロジックを要求すればよいのでしょうか？
この決定ロジックは、サーバーバックエンドまたはワークスペースロジックに実装する必要がありますか？
ありがとうございました。
最初のインテントセットは、分類するもので作成します。それらの意図の1つは、 "Offtopic"で、オフトピックの質問をすべて保持する必要があります。
第2のワークスペースはオフトピックですが、関連トピックに分かれています。
電話をかけてOfftopicを取得したら、2番目のワークスペースを呼び出します。それはオフトピックの性質を返す必要があるので、あなたはそれに対して行動を起こすことができます。
トピックの内容に干渉しないように、主なインテントセットをテスト/調整する必要があります。例えば、会話がスポーツ用品の販売に関連する場合、スポーツに関連する話題は、捕まえるのが厄介かもしれない。
その時点で信頼性を考慮する必要があるかもしれません。
私に示唆されているもう1つのアプローチは、現在マスタールーティング用ワークスペースと多分複数のアプリケーションワークスペースを持つことです。最初のインスタンスでは、ユーザーの入力は、どのアプリケーションワークスペースにルーティングするかを決定する高レベルのインテントを持つマスターに送られます。アプリケーションのワークスペースには、より詳細なインテントがあります。
次に、すべての後続の入力を、選択したアプリケーションワークスペースとマスタールータの両方にパラレルで送信します。これまでに説明したシーケンシャル・アプローチと比較した場合の潜在的なメリットは、マスター・ワークスペースが、トピック外や低い信頼によって降伏させる必要はなく、制御に苦しむことができることです。これは、オフトピックを集中化することを可能にするだけでなく、初期ルーティングと同じインテントを使用して他のワークスペースへの動的ルーティングを得ることができることを意味します。
私は一緒に（マスターでマスターワークスペースに送信されますし、どちらのワークスペースが現在としてマークされているオーケストレーション層がこの
{
currentWs: xxxx,
contexts: {
ws_idn: {}, // basically an array of conversation contexts,
.... // keyed on workspace_id's
}
}
入力のようなコンテキストの配列としてセッションを管理することによって、これをやりましたそのワークスペースに関連するコンテキストオブジェクトを使用して）。それらのコンテキストを失うことなく、複数のチャットボックスアプリケーション間でシームレスに切り替えることができます。