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