適用於智慧型應用程式工作負載的意圖辨識和實體擷取選項
意圖辨識和實體擷取是自然語言理解的關鍵組成部分。
意圖辨識涉及識別使用者輸入背後的目標或目的。 例如，如果使用者說「我想預訂航班」，其意圖就是預訂航班。 意圖辨識可以幫助代理程式了解根據使用者的請求需要採取什麼動作。
實體擷取涉及從使用者輸入中識別和擷取特定的資訊。 實體可以是日期、名稱、地點或任何其他相關資料。 例如，在句子「預訂 9 月 15 日飛往紐約的航班」中，「紐約」和「9 月 15 日」是實體。
代理程式使用意圖來理解使用者的目標，並使用實體來識別完成工作所需的具體細節。 因此，意圖辨識和實體擷取使代理程式能夠對使用者查詢提供準確、有效的回應。
在設計智慧型應用程式工作負載時，您需要選擇最佳的意圖辨識和實體擷取選項，以確保您的智慧型應用程式工作負載提供積極的使用者體驗。
定義
| 詞彙 | 定義 |
|---|---|
| 自然語言理解 | 自然語言理解是 AI 中自然語言處理的一個子集，專注於機器閱讀理解。 |
| 中央情報局 | 對話語言理解是 Azure AI 的功能，支援建立自訂 NLU 模型。 |
| 法學碩士 | 大型語言模型是一種旨在理解和產生人類語言的 AI 模型。 |
| GPT | 產生預訓練變壓器是指使用變壓器架構來理解和產生類似人類的文字的一類大型語言模型。 |
| 動態鏈結 | 動態連結是一種自動觸發生成動作的方法。 動態連結可讓 AI 根據對話上下文確定需要呼叫哪些主題或外掛程式動作，而無需手動定義每個可能的主題或觸發字詞。 |
在智慧型應用程式工作負載中為意圖辨識和實體擷取選擇正確的選項涉及幾個關鍵考慮因素：
預建實體與自訂實體：評估 Microsoft Copilot Studio 提供的預建實體是否符合您的需求。 預建實體涵蓋日期、數字和名稱等常見資訊類型。 如果您的應用程式需要特定領域的知識，您可能需要建立自訂實體。
使用者輸入的複雜性：考慮使用者輸入的複雜性和多變性。 對於簡單的情境，預建實體可能就足夠了。 對於更複雜的互動，可能需要自訂實體和進階設定 (如規則運算式 (regex) )。
空格填寫：確定您的應用程式是否需要主動空格填寫，代理程式會主動尋找並填入使用者輸入中缺少的資訊。 空格填寫可以減少後續問題的需要，從而增強使用者體驗。
效能和可擴縮性：評估您選擇的方法的效能和可擴縮性。 自訂實體和複雜設定通常需要更多的處理能力，並且可能影響回應時間。
易於維護：考慮維護和更新實體的易於程度。 預建實體更易於管理，而自訂實體則需要隨著應用程式的發展而不斷進行調整。
在標準 NLU、Azure CLU 或動態連結之間進行選擇
在 Copilot Studio 中，可以透過使用標準 NLU 模型、將其與自訂 Azure CLU 模型結合或覆寫，或以動態鏈結 (基於 GPT 大型語言模型的模型) 完全取代 NLU 模型來實現主題或動作觸發。
| 標準NLU模型 | 自訂 Azure CLU 模型 | 動態鏈結 | |
|---|---|---|---|
| 優點 | 預設的、開箱即用的模型，經過預先訓練，具有許多預先定義的實體類型。 設定是透過新增觸發字詞和自訂實體 (具有值和同義詞的封閉清單或規則運算式) 來完成的。 |
支援更多語言，具有原生模型。 支援定制意圖觸發模型，以便更好地識別意圖或滿足特定的行業需求。 允許複雜實體擷取 (例如，同一類型)。 實體擷取也可以使用 Copilot Studio 標準 NLU。 |
使用 GPT 大型語言模型，並在更廣泛的資料上進行預訓練。 可以處理多個意圖和鏈主題和/或外掛程式。 自動產生缺失輸入的問題，並根據對話情境回答複雜的實體和問題。 透過描述主題、外掛程式動作、輸入和輸出來完成設定。 |
| 缺點 | 每個查詢進行單一意圖辨識。 無法延長。 您無法修改模型的行為或微調模型。 它按原樣提供。 在同一查詢中對同一類型的多個實體進行空格填寫需要對每個實體進行消歧義 (例如，出發城市和到達城市)。 |
每個查詢進行單一意圖辨識。 設定在 Azure 中完成，但需要額外付費。 有其自己的需要評估的服務限制。 必須小心保持 Azure CLU 意圖和 Copilot Studio 主題同步。 |
由於它是一種生成性 AI 功能，因此訊息的受權消耗率高於常規主題觸發。 |
觸發字詞和空缺填充
在開發智慧型應用程式工作負載時，使用本機功能來增強意圖辨識並簡化對話。 首先從現有的常見問題集資料庫和聊天記錄中識別主題觸發字詞，以確保預期的字詞相關且準確。 考慮如何使用實體；例如，您是否使用規則運算式來尋找訂單 ID、電子郵件的預建實體或具有同義詞的作業類型的封閉清單。 還要規劃如何使用範例字詞測試主題觸發程序來驗證和提高意圖辨識和實體擷取過程的準確性。 如需進一步了解，請參閱 部署和測試注意事項。
觸發字詞
觸發字詞會訓練代理程式的 NLU 模型。 它們透過定義觸發特定主題的特定字詞，來幫助代理程式識別並準確地回應使用者話語。 這些觸發字詞的正確設定可確保代理程式能夠正確識別使用者的意圖，並做出適當的回應。 當代理程式不確定要觸發哪個主題時，它可以建議最多三個潛在的主題候選 (多個主題匹配的系統主題)，或者如果沒有確定主題，則傳回預設回應。 此機制有助於維持對話的流暢性，並確保代理程式可以有效地處理各種使用者輸入。
實體擷取和空格填寫
實體擷取和空格填寫是開發有效代理程式的重要組成部分。 這些過程使代理程式能夠透過從使用者查詢中識別和擷取相關詳細資訊來有效地獲取和使用資訊。
實體擷取涉及解析使用者的輸入以識別特定的資訊。 例如，在查詢「我想訂購三件大號藍色 T 卹」中，代理程式的 NLU 模型應該擷取以下實體：
- 數量：3
- 顏色：藍色
- 尺寸：大號
- 商品種類：T 恤
空格填寫是利用這些擷取的實體來完成指定工作所需的資訊的過程。 在這個例子中，代理程式將主題識別為訂單，並使用擷取的實體填充所需的空格。 代理程式無需詢問更多問題即可理解使用者的請求，從而簡化了互動。
實體擷取和空格填寫使代理程式能夠更有效地處理複雜的查詢，提供準確且與上下文相關的回應，並增強使用者體驗。
深入了解：
將 Microsoft Copilot Studio 與 Azure CLU 整合
將 CLU 模型與 Copilot Studio 代理程式結合可以顯著增強代理程式的功能。 此整合涉及將 Azure CLU 意圖對應到 Copilot Studio 主題，使代理程式能夠更準確地理解和回應使用者意圖。 此外，Copilot Studio 預先建置實體可以與 Azure CLU 實體一起使用，為實體擷取提供強大的框架。
考慮這種整合時，重要的是評估您的智慧型應用程式工作負載是否需要 Azure CLU。 例如，Azure CLU 支援更多語言、行業特定詞典和複雜實體擷取，這對您的應用程式可能至關重要。 使用 Azure CLU 進行自訂實體擷取還可以實現靜默或「幸運」空格填寫，這使得代理程式可以處理諸如在單個字詞中識別來源城市和目的地城市而無需詢問後續問題等情境。
另一個重要面向是確保 Azure CLU 服務配額和限制與代理程式的使用情況一致。 例如，如果您預期每分鐘需要意圖辨識的呼叫少於 1,000 個，則可以使用 S 層設定 Azure CLU。 此設定可確保您的代理程式可以處理預期的工作量，而不會超出服務限制或產生意外成本。
深入了解：
主題結構的注意事項
有效地建立主題對於建立自然、無縫的對話非常重要。 主題是離散的對話路徑，組合起來後可讓使用者順利地與代理程式互動。 以下是設計主題結構的一些關鍵考慮因素：
觸發型主題：這些主題根據使用者話語啟動並作為入口點。 為這些主題定義明確的觸發字詞。 如果觸發字詞跨多個主題重疊，請考慮實施一個通用主題，該主題可以在提出澄清問題後重新導向到適當的主題。 透過實體擷取和空格填寫，如果已經提供了必要的資訊，則可以跳過這些澄清問題。
重新導向型主題：這些主題由重新導向動作、活動或事件觸發，並且可以被多個其他主題呼叫。 它們應該被設計為可重複使用和模組化，具有輸入和輸出變數，以便於無縫整合到各種對話路徑中。
雙觸發主題：某些主題可以透過意圖辨識或明確重新導向觸發。 這種靈活性使得對話更加動態、反應更快。
對話增強和後援：在使用者查詢未觸發任何符合主題的情況下建立後援主題。 這些主題可以提供通用的回應或建議相關主題以維持對話流暢。
設計方法：
關鍵情境的自訂主題：為關鍵情境開發一些自訂主題，並附帶相關的觸發字詞和重新導向。 使用父子主題結構來管理複雜的互動。 對於無法辨識的意圖，實現生成式答案和後援機制。
消除歧義主題：計畫對需要澄清問題的作業使用消歧義主題。 例如，使用者帳戶作業可能需要澄清作業類型 (例如，建立、解鎖、暫停) 和所涉及的系統 (例如，SAP、ServiceNow、Microsoft)。
避免重複：為了避免重複內容，為需要重複的對話路徑建立可重複使用的主題。 這些可重複使用的主題可以由父主題呼叫，一旦完成，對話可以恢復父主題的邏輯。
深入了解：
處理無法辨識的意圖
有效管理無法辨識的意圖可確保流暢的使用者體驗。 當代理程式不理解使用者話語並且缺乏足夠的信心來觸發現有主題時，就會出現無法辨識的意圖。 以下是處理這些情況的一些建議：
管理無法識別的意圖：首先，將無法識別的意圖引導至對話提升系統主題，該主題在公共網站和公司資源 (如 SharePoint 網站) 中搜尋答案。 如果未找到相關訊息，系統則可以使用 Azure OpenAI GPT-4 模型的自訂系統提示恢復到類似 ChatGPT 的體驗。 這種方法可以確保使用者即使在提出沒有計劃的查詢時也能收到有用的答案。
與外部系統的整合：考慮是否將與外部系統的整合作為後援策略的一部分。 例如，使用 HTTP 請求與 Azure OpenAI GPT-4 模型整合，以提供符合 ChatGPT 要求的類似體驗。
監控後援使用情況：定期檢查對話後援的百分比。 利用這些見解來豐富現有主題或建立新主題，確保代理程式不斷提高其理解和回應能力。
後援主題和生成式答案：當未找到匹配的主題時，將觸發後援系統主題。 如果啟用了生成式答案，則對話提升主題將首先在未知意圖事件上觸發，然後根據需要觸發後援主題。 這種分層方法有助於有效地管理無法識別的意圖。
使用對話增強和後援：使用生成式答案搜尋各種資料來源，或與其他系統 (如 Azure 語言認知服務) 整合。 該服務可以處理大量的問答對，並包含隨機問題的聊天模型。
核心情境和自訂主題：確保核心情境和主題定義明確，並透過自訂主題進行處理。 明確定義這些主題的結果，以保持結構化和高效的對話流程。
在地化和語言
建置代理程式時，請考慮智慧型應用程式工作負載必須支援的語言和市場。 在地化和語言支援是確保您的智慧型應用程式工作負載滿足不同使用者群需求的關鍵因素。 以下是一些建議的方法：
每種語言一個代理程式：這種方法涉及為每種語言建立一個單獨的代理程式。 它確保每個代理程式針對其特定語言進行充分最佳化；然而，維護多個代理程式可能會耗費大量資源。
一個代理程式支援多種語言 (設定翻譯)：透過這種方法，單一代理程式支援多種語言，並將翻譯作為代理程式設定的一部分提供。 這種方法要求每次更新代理程式或新增新內容時都更新翻譯。 它在資源效率和語言支援之間提供了平衡，但需要仔細管理翻譯更新。
一個代理程式多種語言 (即時翻譯)：此方法使用中繼代理程式在執行階段提供即時翻譯。 它允許快速部署更多語言並減少頻繁翻譯更新的需要。 但是，它引入了對中繼代理程式和即時翻譯層的依賴，例如 Azure Service Copilot 和 Azure Cognitive Services Translator。
主要考慮因素：
語言和市場：您的代理程式必須支援的語言和市場會影響您的在地化策略。
單一語言代理程式與多語言代理程式：決定是否開發支援多種語言的單一代理程式或為每種語言開發單獨的代理程式。 該決定取決於資源可用性、維護能力以及所涉及語言的複雜性等因素。
翻譯時間：考慮是否應該在設定階段設定翻譯，還是在執行階段即時提供翻譯。 設定翻譯提供穩定性和控制力，而即時翻譯提供靈活性和快速部署。
深入了解：