規劃您的 QnA Maker 應用程式
若要規劃您的 QnA Maker 應用程式，您需要了解 QnA Maker 的運作方式，以及與其他 Azure 服務的互動方式。 您也應該確實理解知識庫的概念。
注意
QnA Maker 服務即將於 2025 年 3 月 31 日淘汰。 現在，Azure AI 語言提供較新版本的問題和解答功能。 如需瞭解語言服務內的問題解答功能，請參閱問題解答。 從 2022 年 10 月 1 日開始，您將無法建立新的 QnA Maker 資源。 如需將現有的 QnA Maker 知識庫移轉至問題解答的相關資訊，請參閱移轉指南。
Azure 資源
使用 QnA Maker 建立的每個 Azure 資源都有特定用途。 每個資源都有自己的用途、限制和定價層。 請務必了解這些資源的功能，讓您可以在規劃程序中使用該知識。
| 資源 | 目的 |
|---|---|
| QnA Maker 資源 | 撰寫和查詢預測 |
| 認知搜尋資源 | 資料儲存體和搜尋 |
| App Service 資源和 App Plan 服務資源 | 查詢預測端點 |
| Application Insights 資源 | 查詢預測遙測 |
資源規劃
每個資源的免費層 F0 都可以運作，並可同時提供撰寫和查詢預測體驗。 您可以使用這一層來學習撰寫和查詢預測。 當您移至生產或即時案例時，請重新評估您的資源選取項目。
知識庫大小和輸送量
當您建置實際的應用程式時，請針對知識庫的大小和預期的查詢預測要求規劃足夠的資源。
知識庫大小受控於下列各項：
- 認知搜尋資源定價層限制
- QnA Maker 限制
知識庫查詢預測要求是由 Web 應用程式方案和 Web 應用程式所控制。 請參閱建議的設定來規劃您的定價層。
資源共用
如果您已經部分使用這些資源，可以考慮共用資源。 查看可共用哪些資源，並了解資源共用為進階案例。
在相同 QnA Maker 資源中建立的所有知識庫都會共用相同的測試查詢預測端點。
了解資源選取項目的影響
適當的資源選取項目表示您的知識庫已成功回應查詢預測。
如果您的知識庫無法正常運作，通常是不當的資源管理問題。
不當的資源選取項目需要調查才能判斷需要變更的資源。
知識庫
知識庫會將其 QnA Maker 資源直接繫結。 其會保留用來回答查詢預測要求的問題和解答 (QnA) 配對。
語言考量因素
在 QnA Maker 資源上建立的第一個知識庫會設定資源的語言。 QnA Maker 資源只能有一種語言。
您可以依語言來建立 QnA Maker 資源的結構，也可以使用翻譯工具在將查詢傳送至查詢預測端點之前，將其他語言的查詢變更為知識庫的語言。
內嵌資料來源
您可以使用下列其中一種內嵌資料來源來建立知識庫：
- 公用 URL
- 私人 SharePoint URL
- 檔案
內嵌程序會將支援的內容類型轉換為 Markdown。 所有進一步的解答編輯都是使用 Markdown 完成。 建立知識庫之後，您可以在 QnA Maker 入口網站中編輯 QnA 配對，並提供 RTF 撰寫。
資料格式考量
QnA 配對的最終格式是 Markdown，因此請務必了解 Markdown 支援。
連結的影像必須可從公用 URL 取得，才能顯示在 QnA Maker 入口網站或用戶端應用程式的 [測試] 窗格中。 QnA Maker 不會提供內容 (包括影像) 的驗證。
Bot 個人化
使用閒聊將 Bot 個人化新增至您的知識庫。 這項個人化是透過特定交談語氣 (例如專業和友善) 提供的解答來展現。 此閒聊是以交談集的方式提供，您在其中可完全控制新增、編輯和移除。
如果您的 Bot 是連線到您的知識庫，建議使用 Bot 個人化。 即使您也連線到其他服務，也可以選擇在您的知識庫中使用閒聊，但您應檢閱 Bot 服務的互動方式，以了解這是否針對您用途的正確架構設計。
具有知識庫的交談流程
交談流程通常是以使用者打招呼做為開頭，例如 Hi 或 Hello。 您的知識庫可以回答一般解答 (例如 Hi, how can I help you)，也可以提供後續提示選項以繼續交談。
您應考慮使用迴圈來設計交談流程，讓使用者知道如何使用您的 Bot，且 Bot 在交談中不會遺棄使用者。 後續提示會提供 QnA 配對之間的連結，以允許交談流程。
使用共同作業者撰寫
共同作業者可能是共用知識庫應用程式完整開發堆疊的其他開發人員，或可能僅限於撰寫知識庫。
知識庫撰寫支援您在 Azure 入口網站中套用以限制共同作業者能力範圍的數個角色型存取權限。
與用戶端應用程式整合
用戶端應用程式的整合是透過將查詢傳送至預測執行階段端點來完成。 查詢會使用 SDK 或以 REST 為基礎的要求傳送至您 QnA Maker 的 Web 應用程式端點，以傳送至您的特定知識庫。
若要正確驗證用戶端要求，用戶端應用程式必須傳送正確的認證和知識庫識別碼。 如果您使用 Azure AI Bot Service，請在 Azure 入口網站 中將這些設定設定設定為 Bot 組態的一部分。
用戶端應用程式中的交談流程
用戶端應用程式 (例如 Azure Bot) 中的交談流程可能需要與知識庫互動之前和之後的功能。
您的用戶端應用程式是否藉由提供替代的方法來處理後續提示或包含閒聊來支援交談流程？ 若是如此，請及早設計這些服務，並確定用戶端應用程式查詢是由另一項服務或傳送至您的知識庫時正確處理。
在 QnA Maker 與 Language Understanding (LUIS) 之間分派
用戶端應用程式可能會提供數個功能，但只有其中一個是由知識庫回答。 其他功能仍需要了解交談式文字，並從其中擷取意義。
常見的用戶端應用程式架構是同時使用 QnA Maker 和 Language Understanding (LUIS)。 LUIS 會針對任何查詢 (包括其他服務) 提供文字分類和擷取。 QnA Maker 會從您的知識庫中提供解答。
在這種共用架構案例中，兩個服務之間的分派是由 Bot Framework 的分派工具來完成。
來自用戶端應用程式的主動式學習
QnA Maker 會使用主動式學習向解答建議替代問題，藉此來改善您的知識庫。 用戶端應用程式負責此主動式學習的一部分。 用戶端應用程式可以透過對話式提示來判斷知識庫是否傳回對使用者而言不實用的解答，並且可以判斷更好的解答。 用戶端應用程式必須將該資訊傳回知識庫來改善預測品質。
提供預設解答
如果您的知識庫找不到解答，則會傳回預設解答。 您可在 QnA Maker 入口網站或 API 中的 [設定] 頁面上設定此解答。
此預設解答不同於 Azure Bot 的預設解答。 在設定的過程中，您可以在 Azure 入口網站中設定 Azure Bot 的預設解答。 當分數閾值不相符時，就會傳回此值。
預測
預測是來自您知識庫的回應，其中包含解答以外的資訊。 若要取得查詢預測回應，請使用 GenerateAnswer API。
預測分數波動
分數可能會根據數個因素而變更：
- 回應包含
top屬性的 GenerateAnswer 所要求的解答數目 - 各種可用的替代問題
- 篩選中繼資料
- 傳送至
test或production知識庫的查詢
- 認知搜尋 - 排名第一。 將允許解答的數目設得夠高，讓認知搜尋傳回最佳解答，然後將最佳解答傳遞至 QnA Maker 排名工具。
- QnA Maker - 排名第二。 套用特徵化和機器學習服務來判斷最佳解答。
服務更新
套用最新的執行階段更新，以自動管理服務更新。
縮放比例、輸送量和復原能力
縮放比例、輸送量和復原能力取決於 Azure 資源、其定價層和任何周圍的結構，例如流量管理員。
Application Insights 中的 Analytics
您知識庫的所有查詢都會儲存在 Application Insights 中。 使用我們的最佳查詢來了解您的計量。
開發生命週期
知識庫的開發生命週期正在進行中：編輯、測試和發佈您的知識庫。
QnA Maker 配對的知識庫開發
您應根據用戶端應用程式的使用方式來設計及開發您的 QnA 配對。
每一個配對可以包含：
- 中繼資料 - 可在查詢時篩選，讓您使用資料來源、內容、格式和用途的其他相關資訊來標記 QnA 配對。
- 後續提示 - 可協助您判斷知識庫的路徑，讓使用者取得正確的解答。
- 替代問題 - 對於讓搜尋從不同形式的問題比對您的解答很重要。 主動式學習建議會變成替代問題。
DevOps 開發
在開發要插入 DevOps 管線的知識庫時，必須在批次測試期間隔離知識庫。
知識庫會與 QnA Maker 資源上的所有其他知識庫共用認知搜尋索引。 雖然知識庫是依資料分割隔離，但相較於已發佈的知識庫，共用索引可能會導致分數的差異。
若要在 test 和 production 知識庫上擁有相同的分數，請將 QnA Maker 資源隔離到單一知識庫。 在此結構中，資源只需要在進行隔離的批次測試時存留。