智慧建議模型常見問題集
本文深入探討智慧建議服務使用的模型演算法類型，並提供常見模型問題的解答。
目錄
智慧建議演算法概觀
智慧建議模型元件使用幾個不同的演算法來建立排名清單。 清單 API 會根據所選用於模型的演算法類型來回應查詢並傳回結果。 下表提供有關智慧建議服務所用演算法類型的詳細資訊：
[!注意]
依照最佳做法，在最終選擇哪個演算法最適合您的業務使用案例和資料集 (這是資料類型與實際行為的組合) 之前，使用「測試」來比較幾種不同清單類型和/或資料類型的結果。
| 演算法類型 | 描述 |
|---|---|
| 矩陣分解 (MF) | 矩陣分解是一種協同過濾演算法，側重於根據特定使用者互動 (購買、使用方式、點擊率、檢視次數、下載等) 建立使用者對項目和項目對項目關聯。 此演算法類型根據特定使用者的歷史喜好設定對清單進行排名，也就是所謂基於個人「品味」的排名。 這在使用者與項目互動的基礎上，還會衍生出項目之間的相似性。 矩陣分解會產生對稱 (如果 ‘A’ 類似於 ‘B’，則 ‘B’ 也類似於 ‘A’) 和遞移 (如果 ‘A’ 類似於 ‘B’，且 ‘B’ 類似於 ‘C’，則 ‘A’ 類似於 ‘C’) 排名。 為取得最佳結果，當您使用含大量互動訊號和目錄中繼資料的資料集時，請使用矩陣分解演算法類型。 這項功能非常適合電影和電視、遊戲或串流媒體等娛樂領域，但在其他依賴客戶互動訊號的領域也有很好的表現，包括：零售業、食品雜貨業、旅遊行程、製造業及其他。 |
| 直接關聯相似性 (DAS) | 直接關聯相似性 (DAS) 演算法非常適合需求依高效用而定之局部/定向親和性領域，例如實用性比歷史偏好 (品味) 更重要的應用程式。 例如，依序執行 ‘A’、‘B’ 和 ‘C’ 動作的人，通常會接著執行 ‘D’ 動作。 DAS 為非對稱，且不具結合性。 我們的服務使用 DAS 演算法來支援後續最佳動作 API，這會根據不同的可重複群組建立內容建議。 後續最佳動作的一般使用場合常見於「購物籃交易完成」案例中的零售結帳體驗，例如「經常一起購買」(這會根據使用者購物車的內容提供互補項目)。 DAS 也可以重新組合群組，並建議不同子領域中的項目。 例如，在雜貨店購物者的購物車中有漢堡肉餅和麵包的情況下，可能會向他們推薦餐巾紙和盤子。 從「後續最佳動作」獲得好處的領域包括食品雜貨、銷售、疑難排解、會計及其他。 |
| 視覺外觀相似性 (VBS) | 視覺外觀相似性 (VBS) 是深度學習的視覺認知演算法，可針對指定的種子項目，傳回影像相似項目的視覺相似建議。 與矩陣分解一樣，VBS 演算法產生的建議是對稱的。 這種深度學習卷積神經網路採用「Argus」做為主幹，但會使用更深層的技術對租用戶的影像進行進一步訓練，以取得視圖不變量，為租戶的領域提供更具相關性的建議。 VBS 在時尚，設計和珠寶等領域非常強大，在這些領域中，視覺屬性是產品的主要賣點。 |
| 文字內容相似性 (TBS) | 文字內容相似性 (TBS) 演算法對根據所提供目錄中項目之標題與描述建立的語言模型進行重點訓練，為指定的種子項目傳回文字描述上相似的建議。 此演算法在標題和描述具有描述性的領域中效果特別好，可以產生獨特且直觀的建議。 此模型使用以 ‘TNLR’ Transformer 為基礎的語言模型做為主幹，但是模型也會對提供的資料集使用傳輸學習以及更深層的訓練技術，讓這個演算法可以提供語意明確的最新式建議。 TBS 使用自然語言處理 (NLP) 做為輸入，使得此演算法適用於許多不同的領域，包括：旅遊行程安排、釀酒廠、科學期刊研究資料庫、疑難排解及其他。 |
| 瀏覽清單 | 瀏覽清單可讓您使用依資訊 (例如總銷售額、點選次數總和、發行日期或不同計量組合) 排序的啟發式圖表來瀏覽目錄。 支援的清單為：「全新」、「發燒貨」、「熱門」。 圖表是快速讓終端使用者與產品進行互動，並查看最新和最佳產品類別目錄的絕佳起點。 透過變更輸入互動類型，可以進一步擴增瀏覽清單。 例如，以購買訊號為基礎的模型會傳回「最熱門的購買產品」，而將模型訊號變更為觀看次數時，則會傳回「最受關注的產品」。 |
常見問題
本節介紹一系列有關智慧建議模型及其運用場合的常見問題。
如何追蹤模型狀態？
智慧建議客戶可以追蹤他們在其帳戶中所建立每個模型的模型狀態。 設定模型之後，服務會定期建立狀態記錄檔，以回報所有演算法目前的狀態 (相對於您的模型層)。 若要深入了解如何存取這些記錄，請參閱模型狀態報表指南。
應該為我的業務使用哪種演算法和清單類型？
根據業務使用案例、體驗以及可用於模型的資料，選取要使用的清單類型和演算法。 請參閱清單名稱、AlgoTypes 資料表、微調，以取得可用清單名稱和 AlgoType 組合的完整清單。
一般而言，模型互動反映人們與之互動的內容。 例如，我們會將使用 MF 演算法的「人們也」清單類型描述為「執行此動作的客戶，也會執行此動作。」當動作是購買時，清單會變成「已購買這個的人，也已購買。」
項目中繼資料也可以用來建立各項目之間的相似性 (假設中繼資料在數量和品質上很充足)。 例如，有相似描述的項目可視為密切相關，正如有相似產品影像的項目可能密切相關一樣。 此中繼資料對於在沒有互動的情況下，為項目建立結果非常有用 (也稱為建立「冷門項目」模型)。
結合互動和中繼資料 (適用於項目和/或使用者) 的方法，可與智慧建議搭配用來自訂案例和體驗。 使用多個不同的模型 (並對每個帳戶各使用一個模型)，以測試並查看哪個方法最適合您使用案例。
將可用資料類型及使用案例對應至演算法類型
| 可用的資料類型 | 案例 | 演算法 |
|---|---|---|
|
互動 例如，檢視次數、購買項目、使用方式等。使用者做了什麼？ |
為您精選 個人化 人們也這樣做 後續最佳動作 |
矩陣分解 (MF) 定向關聯 (DAS) |
|
文字中繼資料 例如，標題、描述 |
類似描述 | 文字內容相似性 (TBS) |
|
視覺中繼資料 例如，多個視角的產品影像 |
類似外觀 注意： 並非所有領域都適合此案例。 您應該在影像是項目的良好表示方式的情況下使用。 |
視覺外觀相似性 (VBS) |
|
其他項目中繼資料 例如，形狀、類別、標記等。 |
與互動相同。 此服務也允許以不同的方式建立模型： - 以混合方式將項目中繼資料與互動結合 - 或是僅使用項目中繼資料 (透過 MF 或 DAS 演算法) 來建立 |
矩陣分解 (MF) 定向關聯 (DAS) |
|
使用者中繼資料 例如，人口統計資料 |
相關案例是以使用者個人化為主軸： - 為您精選 - 個人化 此服務允許以不同的方式建立模型： - 以混合方式將使用者中繼資料與互動結合 - 或是僅使用使用者中繼資料 (透過 MF 或 DAS 演算法) 來建立 |
矩陣分解 (MF) 定向關聯 (DAS) |
該如何決定是使用矩陣分解演算法還是直接關聯演算法？
建議對您的資料同時嘗試這兩個演算法，看看哪一個會根據您的業務需求傳回更合適的結果。
在下列情況中，嘗試矩陣分解 (MF) 演算法：
- 領域中項目之間的連接大部分具有交換性 (對稱，亦即如果 A=>B，則 B=>A) 和結合性 (亦即如果 A=>B 且 B=>C，則 A=>B)。
- 您的資料稀少，但仍然希望有足夠的建議提供給許多項目。
在下列情況中，嘗試直接關聯 (DAS) 演算法：
- 領域中項目之間的連接大部分具有方向性 (非對稱，亦即 A=>B 不代表 B=>A) 和直向性 (無結合性)。
- 「後續最佳動作」(項目的特定排序清單，下一個應該是什麼) 對您來說是一個重要的案例。
- 您想要將項目的一個子領域推薦給另一個子領域。
- 看起來較多的直接連接應該更多地反映在結果中。
如需詳細資訊，請參閱清單名稱、AlgoTypes 資料表、微調。
需要多少次互動才能確保良好的建議？
若要為一組重要產品的領域建立適當的模型，每個產品都應該包含至少五次互動或更多的案例，例如「人們也喜歡」或「精選」(個人化)。 您還必須包含多個產品的充足互動，才能產生「後續最佳動作」的結果，產品是依 InteractionGroupingId 組成群組 (順序相同的每個項目在 InteractionGroupingId 相同的互動資料實體中都有一列)
根據經驗法則，最好要讓互動的數量大約五倍於項目的數量。 例如，如果目錄中有 1000 個項目，則最好嘗試透過至少 5000 次互動來建立模型。
如有疑問，嘗試使用簡單的模型 (更少的資料行) 以及輸入資料集中盡可能多的互動 (更多資料列)，會有所幫助。 若要評估資料合約的品質，並查看有關模型效能的計量，請參閱智慧建議儀表板。
為什麼我的互動資料實體需要包含 InteractionGroupingId、UserId、ItemId 和 ItemVariantId？
InteractionGroupingId 表示系統連接的群組 (尤其是項目)，以便更準確地全面進行整體推斷。 例如，在零售案例中依 InteractionGroupingId 將交易組成群組，可協助系統了解購物車中哪些產品是「經常一起購買」，或已在「後續最佳動作」角色中完成的工作，以及「人們也喜歡」中的類似項目。
UserId 由系統用來在項目和與項目互動的使用者之間形成的關聯性上建立模型，這取決於模型的側重點，可以是建立個人化和非個人化模型案例。 在使用 UserId 的個人化方法中，系統會根據每個單獨使用者的歷史偏好，為使用者與項目之間的對應建立模型。 這會接著產生「根據您先前的歷程記錄，您可能會喜歡」模型，又稱為「推薦項目」
ItemId 是實際的項目參考。 您必須將每個項目與其互動相連接，並允許模式在模型中出現。 沒有互動的 ItemIds 不會出現在對其他產品的建議中，還可能會在當做模型 (例如「喜歡這個項目的人也喜歡」) 的種子使用時，受到不良建議的影響。
ItemVariantId 主要用於「相似外觀」案例和視覺外觀相似性 (VBS) 演算法，此演算法考慮的是影像中繼資料而不是互動。 依賴互動的模型和演算法不需要此欄位。
若要深入了解每個案例所需的資料實體，請參閱資料實體對應資料表。
可以使用類別、色彩、型號等項目中繼資料嗎？
項目中繼資料在許多方面都能有所幫助：
- 除了互動輸入外，還會為項目建立更準確的模型，因此互動為數不多甚至沒有互動的項目 (冷門項目) 仍然可以取得「人們也喜歡」建議。
- 您可以讓模型完全根據項目中繼資料 (例如內容標記)，並傳回「類似項目」類型的建議結果。
- 如何執行此動作：為中繼資料項目指定 TagId。 在互動資料實體中，針對每個互動資料列，將 InteractionGroupingId 設定為 TagId，同時將項目保留為 ItemId，並將使用者保留為 UserID。 若要深入了解 TagIds 的運作方式，請參閱中繼資料標記和貯體指南。
[!重要注意事項]
對以項目中繼資料為基礎的模型使用不同的帳戶，使得每個 IR 帳戶各有 1 個 IR 模型，而這些模型/帳戶有別於純粹以使用者互動為基礎的模型/帳戶。
- 含資訊參考文字描述的項目可以取得我們 NLP 深層模型所驅動的「類似描述」建議。
- 有影像的項目和變體可以取得我們視覺認知深度學習模型所驅動的「類似外觀」建議。
可以使用使用者中繼資料 (例如人口統計資料) 來個人化建議嗎？
智慧建議服務可讓客戶透過中繼資料標記程序加入使用者中繼資料。 使用者中繼資料可強有力地用來向所有使用者建議相關內容，包括
- 新客戶或非經常性客戶 (也稱為「冷淡使用者」)。
- 將使用者與包含中繼資料標記的一般屬性相連接。 若要深入了解提供建議的人口統計貯體並查看範例，請參閱中繼資料標記和貯體指南。
可以做使用者對使用者建議嗎？
目前不支援完整的使用者對使用者建議。 目前有部分資料集可以透過對資料合約進行一些變更來取得「使用者對使用者」建議：
- 對於每個原始互動輸入，建構一列以執行下列動作：
- 將 ItemID 寫入 InteractionGroupingId 資料行
- 將 UserID 寫入 ItemId 資料行
- 建立 API 要求：對資料合約執行先前的變更後，將會使用 UserId 來呼叫「人們也」清單類型，傳回類似使用者的清單。
可以從哪裡了解與智慧建議搭配使用的矩陣分解模型？
我們的 MF 模型：使用隨機圖的單類共同篩選。 我們開發了貝氏矩陣分解的內部版本 (已在這裡說明)，可以用來深入了解這裡所述的任何內嵌。