使用個人化工具的位置和方式
重要
從 2023 年 9 月 20 日起，您將無法建立新的個人化工具資源。 個人化工具服務將於 2026 年 10 月 1 日淘汰。
在您的應用程式需要選取正確的動作（內容）以顯示的情況下，使用個人化工具，讓體驗變得更好、取得更好的商務結果或提高生產力。
個人化工具會使用增強式學習來選取要向用戶顯示的動作（內容）。 選取範圍可能會因傳送至服務的數據數量、質量和分佈而有所不同。
個人化工具的使用案例範例
- 意圖釐清和釐清：藉由提供個人化的選項，協助使用者有更好的意圖體驗。
- 功能表和選項的預設建議 ：讓 Bot 以個人化方式建議最可能的項目作為第一個步驟，而不是呈現非個人功能表或替代方案清單。
- Bot 特性和語氣：對於可改變語氣、詳細資訊和撰寫樣式的 Bot，請考慮改變這些特性。
- 通知和警示內容：決定要用於警示的文字，以便吸引使用者更多。
- 通知和警示計時：已個人化瞭解何時將通知傳送給使用者以吸引他們。
使用個人化工具所需的期望
您可以在符合或實作下列指導方針的情況下套用個人化工具。
| 指導方針 | 說明 |
|---|---|
| 商務目標 | 您的應用程式有商務或可用性目標。 |
| Content | 您在應用程式中有一個位置，可決定要向用戶顯示的內容，以改善該目標。 |
| 內容數量 | 每個呼叫的動作少於50個。 |
| 彙總資料 | 最佳選擇可以和應該從集體用戶行為和總獎勵分數中學習。 |
| 道德使用 | 使用機器學習進行個人化時， 會遵循您所選擇的負責任使用指導方針 和選擇。 |
| 最佳單一選項 | 內容相關決策可以表示為從一組有限的選擇中排名最佳選項（動作）。 |
| 評分結果 | 您可以藉由測量用戶行為的某些層面，並以獎勵分數來表達應用程式的排名選擇，來判斷其運作程度。 |
| 相關時間 | 獎勵分數不會帶來太多混淆或外部因素。 實驗持續時間足夠低，在獎勵分數仍然相關時可計算。 |
| 足夠的內容功能 | 您可以將排名的內容表達為至少 5 項功能的清單，認為這項功能 有助於做出正確的選擇，且不包含使用者特定的可識別資訊。 |
| 足夠的動作功能 | 您有每個內容選擇、 動作的相關信息，作為至少 5 項功能 的清單，您認為這些功能可協助個人化工具做出正確的選擇。 |
| 每日資料 | 如果問題隨著時間而漂移（例如新聞或時尚偏好），就有足夠的事件能夠掌握最佳個人化。 個人化工具會適應真實世界中的連續變更，但如果沒有足夠的事件和數據來探索並解決新模式，則結果不會是最佳的。 您應該選擇經常發生的使用案例。 請考慮尋找每天至少發生 500 次的使用案例。 |
| 歷程記錄資料 | 您的應用程式可以保留足夠長的數據，以累積至少100,000個互動的歷程記錄。 這可讓個人化工具收集足夠的數據，以執行脫機評估和原則優化。 |
請勿使用個人化工具 ，其中個人化行為不是所有使用者都能探索到的行為。 例如，使用個人化工具從 20 個可能功能表項清單中建議第一個披薩訂單很有用，但在需要兒童保育協助時，從使用者的聯繫人清單撥打哪個聯繫人（例如“奶奶”）並不是在您的使用者群中個人化的。
如何在 Web 應用程式中使用個人化工具
將學習迴圈新增至 Web 應用程式包括：
- 決定要個人化的體驗、您擁有哪些動作和功能、要使用的內容功能，以及您將設定的獎勵。
- 在應用程式中新增個人化 SDK 的參考。
- 當您準備好個人化時，請呼叫排名 API。
- 儲存 eventId。 您稍後會使用 Reward API 傳送獎勵。
- 一旦您確定使用者已看到個人化頁面，請針對事件呼叫 Activate。
- 等候用戶選取已排名的內容。
- 呼叫 Reward API 以指定排名 API 的輸出效果。
如何搭配聊天機器人使用個人化工具
在此範例中，您將瞭解如何使用個人化來提出預設建議，而不是每次將一系列功能表或選項傳送給使用者。
- 取得此範例的程序 代碼 。
- 設定 Bot 解決方案。 請務必發佈 LUIS 應用程式。
- 管理 Bot 的排名和獎勵 API 呼叫。
- 新增程式代碼來管理 LUIS 意圖處理。 如果 None 傳回為最上層意圖，或最上層意圖的分數低於商業規則閾值，請將意圖清單傳送至個人化工具，以排名意圖。
- 將意圖清單向用戶顯示為可選取的連結，第一個意圖是排名 API 回應中排名最高的意圖。
- 擷取使用者的選取專案，並在 Reward API 呼叫中傳送此專案。
建議的 Bot 模式
- 每次需要釐清時進行個人化工具排名 API 呼叫，而不是針對每個使用者快取結果。 釐清意圖的結果可能會隨著一個人的時間而改變，而讓排名 API 探索變異數將加速整體學習。
- 選擇與許多使用者通用的互動，以便您有足夠的數據來個人化。 例如，簡介問題可能比交談圖表中只有少數使用者可以取得的較小釐清更適合。
- 使用排名 API 呼叫來啟用「第一個建議是正確的」交談，其中會詢問使用者「您要 X 嗎？」或「您的意思是 X 嗎？」，而使用者只能確認;與其提供選項給用戶，他們必須從功能表選擇。 例如，User：“我想要訂購咖啡”Bot：“您要雙濃縮咖啡嗎？ 如此一來，獎勵訊號也非常強烈，因為它與一個建議直接相關。
如何搭配建議解決方案使用個人化工具
許多公司使用推薦引擎、行銷和行銷活動工具、受眾區隔和叢集、共同作業篩選以及其他手法從大型目錄中對客戶建議產品。
Microsoft Recommender GitHub 存放庫提供了用來建置推薦系統的範例和最佳做法 (以 Jupyter 筆記本的形式提供)。 它提供準備資料、組建模型、評估、微調和操作推薦引擎的工作範例，適用於許多常見方法，包括 xDeepFM、SAR、ALS、RBM、DKN。
個性化工具可以與存在的推薦引擎一起使用。
- 推薦引擎採用大量項目 (例如 500,000 個) 並從數百或數千個選項中建議一個子集 (例如前 20 個)。
- 個人化工具會採用少量的動作，其中包含許多相關信息，並針對指定的豐富內容即時排名這些動作，而大部分的建議引擎只會使用一些使用者、產品及其互動的屬性。
- 個人化工具的設計目的是要一直自主探索使用者喜好設定，這會在內容快速變化的地方產生更好的結果，例如新聞、即時活動、即時社群內容、每日更新的內容或季節性內容。
常見用途是獲得推薦引擎的輸出 (例如，某個客戶的前 20 個產品) 並將其用作個人化工具的輸入動作。
將內容保護新增至您的應用程式
如果您的應用程式允許對使用者顯示的內容有較大差異，而某些內容可能不安全或不適合某些使用者，您應該事先規劃，以確保適當的保護措施已到位，以防止使用者看到不可接受的內容。 實作保護的最佳模式是：* 取得要排名的動作清單。 * 篩選出無法供物件使用的專案。 * 只排名這些可行的動作。 * 向使用者顯示排名最高的動作。
在某些架構中，上述順序可能很難實作。 在此情況下，有替代方法可在排名後實作保護，但必須進行佈建，讓落在保護外部的動作不會用來定型個人化工具模型。
- 取得要排名的動作清單，並停用學習。
- 排名動作。
- 檢查最上層動作是否可行。
- 如果最上層動作可行，請啟用此排名的學習，然後將它向用戶顯示。
- 如果最上層動作不可行，請勿啟用此排名的學習，並透過您自己的邏輯或替代方法決定要向用戶顯示的內容。 即使您使用排名第二位的選項，也不會啟用此排名的學習。