QnA Maker アプリの計画
QnA Maker アプリを計画するには QnA Maker がどのように動作し、他の Azure サービスと対話しているかを理解する必要があります。 また、ナレッジ ベースの概念をしっかりと把握しておく必要もあります。
Note
QnA Maker サービスは、2025 年 3 月 31 日に廃止される予定です。 Azure AI Language の一部として、質問応答機能の新しいバージョンが提供されました。 言語サービス内の質問応答機能については、質問応答に関する記事を参照してください。 QnA Maker の新しいリソースは、2022 年 10 月 1 日以降作成できません。 既存の QnA Maker のナレッジ ベースを質問応答に移行する方法については、移行ガイドを参照してください。
Azure リソース
QnA Maker で作成される各 Azure リソースには特定の目的があります。 各リソースには、独自の目的、制限、および価格レベルがあります。 これらのリソースの機能を理解し、その知識を計画プロセスに使用できるようにすることが重要です。
| リソース | 目的 |
|---|---|
| QnA Maker リソース | 作成とクエリ予測 |
| Cognitive Search リソース | データ ストレージと検索 |
| App Service のリソースと App Plan サービスのリソース | 予測エンドポイントに対するクエリの実行 |
| Application Insights リソース | クエリ予測テレメトリ |
リソースの計画
各リソースの Free レベルである F0 を利用できます。また、作成とクエリ予測の両方のエクスペリエンスが用意されています。 このレベルを使用して作成とクエリ予測を学習することができます。 運用またはライブのシナリオに移行するときは、リソースの選択を再評価してください。
ナレッジ ベースのサイズとスループット
実際のアプリを作成するときは、ナレッジ ベースのサイズと予想されるクエリ予測要求に十分なリソースを計画します。
ナレッジ ベースのサイズは、次によって制御されます。
- Cognitive Search リソースの価格レベルの制限
- QnA Maker の制限
ナレッジ ベースのクエリ予測要求は、Web アプリ プランと Web アプリによって制御されます。 価格レベルを計画する場合は、「推奨設定」を参照してください。
リソースの共有
これらのリソースの一部を既に使用している場合は、リソースの共有を検討してください。 リソースの共有は高度なシナリオであることを理解した上で、共有できるリソースを確認してください。
同じ QnA Maker リソースで作成されたすべてのナレッジ ベースは、同じテスト クエリ予測エンドポイントを共有します。
リソース選択の影響の概要
適切なリソースの選択とは、ナレッジ ベースがクエリ予測に正常に回答することを意味します。
ナレッジ ベースが正常に機能していない場合、問題は、通常は不適切なリソース管理です。
リソースの選択が不適切な場合は、変更する必要があるリソースを特定するために調査が必要です。
ナレッジ ベース
ナレッジ ベースは、その QnA Maker リソースに直接関連付けられます。 これには、クエリ予測要求に回答するために使用される質問と回答 (QnA) のペアが保持されます。
言語に関する注意点
QnA Maker リソースに作成された 1 つ目のナレッジ ベースによって、リソースの言語が設定されます。 1 つの QnA Maker リソースには 1 つの言語のみを使用できます。
クエリをクエリ予測エンドポイントに送信する前に、QnA Maker リソースを言語ごとに構築するか、Translator を使用してクエリを別の言語からナレッジ ベースの言語に変更することができます。
データ ソースを取り込む
取り込まれた次のデータ ソースのいずれかを使用して、ナレッジ ベースを作成することができます。
- パブリック URL
- SharePoint のプライベート URL
- ファイル
インジェスト プロセスでは、サポートされているコンテンツの種類がマークダウンに変換されます。 回答のそれ以上の編集はすべて、マークダウンを使用して行われます。 ナレッジ ベースを作成した後は、リッチ テキスト作成を使用して、QnA Maker ポータルで QnA ペアを編集できます。
データ形式に関する考慮事項
QnA ペアの最終的な形式はマークダウンであるため、マークダウンのサポートを理解することが重要です。
リンクされた画像は、QnA Maker ポータルのテスト ペインまたはクライアント アプリケーションに表示されるパブリック URL から入手できる必要があります。 QnA Maker には、画像を含むコンテンツの認証機能はありません。
ボットのパーソナリティ
おしゃべりを使用して、ナレッジ ベースにボットのパーソナリティを追加します。 このパーソナリティは、Professional や Friendly などの特定の口調で提供される回答を返します。 このおしゃべりは会話のセットとして提供され、追加、編集、および削除を完全に制御できます。
ボットがナレッジ ベースに接続している場合は、ボットのパーソナリティが推奨されます。 他のサービスにも接続している場合でも、ナレッジ ベースでおしゃべりを使用することを選択できますが、ボット サービスがどのように相互作用するかを確認して、それが使用に適したアーキテクチャ設計であるかどうかを確認する必要があります。
ナレッジ ベースとの会話フロー
会話フローは、通常は Hi や Hello などのユーザーからのあいさつで始まります。 ナレッジ ベースは、Hi, how can I help you などの一般的な回答で答えることができ、会話を続けるためのフォローアップ プロンプトを選択することもできます。
会話フローは、ユーザーがボットの使用方法を認識し、会話中にボットによって中断されないように、ループを念頭に置いて設計する必要があります。 フォローアップ プロンプトは、会話フローを可能にする QnA ペア間のリンクを提供します。
コラボレーターとの作成
コラボレーターは、ナレッジ ベース アプリケーションの完全な開発スタックを共有する他の開発者であることも、ナレッジ ベースの作成のみに制限されていることもあります。
ナレッジ ベースの作成では、コラボレーターの機能の範囲を制限するために、Azure portal で適用するいくつかのロールベースのアクセス許可をサポートしています。
クライアント アプリケーションとの統合
クライアント アプリケーションとの統合は、予測ランタイム エンドポイントにクエリを送信することで実現します。 クエリは、QnA Maker の Web アプリ エンドポイントへの SDK または REST ベースの要求と共に、特定のナレッジ ベースに送信されます。
クライアント要求を正しく認証するためには、クライアント アプリケーションが正しい資格情報とナレッジ ベース ID を送信する必要があります。 Azure AI Bot Service を使用する場合は、Azure portal でボット構成の一部としてこれらの設定を構成します。
クライアント アプリケーションでの会話フロー
Azure ボットなどのクライアント アプリケーションでの会話フローでは、ナレッジ ベースとの対話の前後に機能が必要になる場合があります。
お使いのクライアント アプリケーションは、フォローアップ プロンプトを処理する別の手段を提供するか、おしゃべりを含めることで、会話フローをサポートしていますか。 その場合は、これらを早期に設計し、別のサービスによって、またはナレッジ ベースに送信されたときに、クライアント アプリケーション クエリが正しく処理されるようにします。
QnA Maker と Language Understanding (LUIS) 間のディスパッチ
クライアント アプリケーションは複数の機能を提供する場合があり、ナレッジ ベースによって回答されるのはそのうちの 1 つのみです。 その他の機能でも、会話テキストを理解し、意味を引き出す必要があります。
一般的なクライアント アプリケーションのアーキテクチャでは、QnA Maker と Language Understanding (LUIS) の両方を一緒に使用します。 LUIS には、他のサービスを含め、あらゆるクエリに対するテキストの分類と抽出の機能があります。 QnA Maker では、ナレッジ ベースから回答が提供されます。
このような共有アーキテクチャのシナリオでは、2 つのサービス間のディスパッチは、Bot Framework の Dispatch ツールによって実現されます。
クライアント アプリケーションからのアクティブ ラーニング
QnA Maker では、アクティブ ラーニングを使用して、回答に関する代わりの質問を提案することで、ナレッジ ベースを向上させます。 このアクティブ ラーニングの一部は、クライアント アプリケーションで行う必要があります。 クライアント アプリケーションでは、会話型のプロンプトを通じて、ナレッジ ベースからユーザーにとって役に立たない回答が返されたことを判断し、より適切な回答を判断することができます。 クライアント アプリケーションは、予測品質を向上させるために、ナレッジ ベースにその情報を返信する必要があります。
既定の回答の提供
ナレッジ ベースは、回答が見つからない場合は既定の回答を返します。 この回答は、QnA Maker ポータルの [設定] ページ、または API で構成できます。
この既定の回答は、Azure ボットの既定の回答とは異なります。 構成設定の一環として、Azure portal で Azure ボットの既定の回答を構成します。 これは、スコアのしきい値が満たされない場合に返されます。
予測
予測は、ナレッジ ベースからの応答であり、回答だけでなく、さらに多くの情報が含まれています。 クエリ予測応答を取得するには、GenerateAnswer API を使用します。
予測スコアの変動
スコアは、次のいくつかの要因に基づいて変化することがあります。
topプロパティを含む GenerateAnswer への応答として要求された回答の数- 利用できるさまざまな代わりの質問
- メタデータのフィルター処理
testまたはproductionのナレッジ ベースに送信されるクエリ
2 フェーズの回答の順位があります。
- Cognitive Search - 1 位。 許可される回答の数を十分に高く設定して、最適な回答が Cognitive Search から返され、QnA Maker ランカーに渡されるようにします。
- QnA Maker - 2 位。 特徴量化と機械学習を適用して、最適な回答を決定します。
サービスの更新情報
サービス更新プログラムを自動的に管理するには、最新のランタイム更新プログラムを適用します。
スケーリング、スループット、および回復性
スケーリング、スループット、および回復性は、Azure リソース、その価格レベル、およびトラフィック マネージャーなどの周囲のアーキテクチャによって決まります。
Application Insights による分析
ナレッジ ベースに対するすべてのクエリは Application Insights に格納されます。 上位のクエリを使用して、メトリックを理解します。
開発ライフサイクル
ナレッジ ベースの開発ライフサイクルは、ナレッジ ベースの編集、テスト、および発行です。
QnA Maker ペアのナレッジ ベースの開発
QnA ペアは、クライアント アプリケーションの使用状況に基づいて設計および開発する必要があります。
各ペアには次のものを含めることができます。
- メタデータ - クエリ時に絞り込んで、データのソース、コンテンツ、形式、および目的に関する追加情報を使用して QnA ペアにタグを付けることができます。
- フォローアップ プロンプト - ユーザーが正しい回答を受け取るように、ナレッジ ベースからのパスを決定するために役立ちます。
- 代替の質問 - さまざまな形式の質問からの回答と検索を一致させるために重要です。 アクティブ ラーニングの提案は代わりの質問に変わります。
DevOps 開発
DevOps パイプラインに挿入するナレッジ ベースを開発するには、バッチ テスト中にナレッジ ベースを分離する必要があります。
ナレッジ ベースは、QnA Maker リソースの他のすべてのナレッジ ベースと Cognitive Search インデックスを共有します。 ナレッジ ベースはパーティションによって分離されますが、インデックスを共有すると、発行されたナレッジ ベースと比較したときにスコアの差が生じる可能性があります。
test と production のナレッジ ベースを同じスコアにするためには、QnA Maker リソースを 1 つのナレッジ ベースに分離します。 このアーキテクチャでは、リソースは分離されたバッチ テストの長さまで有効である必要があります。