YouTube 基於 LLM 的對話式推薦系統

TLDR： 本文提供了一個使用大模型來構建端到端大規模對話推薦系統的路線圖。具體的，其提出了用戶偏好理解、對話管理和可解釋推薦的新實現，並將其作爲 LLM 驅動的集成架構的一部分。爲提高個性化，本文描述了大模型如何使用可解釋的自然語言配置文件，並使用它們來調整會話級上下文。

論文：https://arxiv.org/abs/2305.07961

在傳統的推薦系統模式中，用戶只能被動的在推薦列表中消費物料，缺乏深入參與推薦機制的機會。由此當用戶面對推薦系統可能帶來的不佳體驗時，比如流行度偏差、低效的興趣試探、信息繭房等，常常感到束手無策。對話式推薦系統（CRS）對此帶來了創新轉變，它通過對話交流的方式向用戶做推薦，不再單一的依賴於用戶行爲，而是能隨着用戶提供的反饋語句逐漸優化所推薦的內容。在對話式推薦系統中，用戶對推薦系統擁有更強的影響力。論文中給出 YouTube 場景下的對話式推薦系統如下，圖片中左邊爲系統與用戶的對話頁面，右邊爲系統給出的推薦結果。淘寶的服務助手中也存在類似的對話推薦系統，但推薦內容會在對話中直接給出。

‍大規模語言模型集成了海量知識內容且具備強大的邏輯推理能力，能夠以自然語言的形式與用戶進行互動交流，與對話式推薦系統相當契合。在此背景下 Google 在 YouTube 場景中基於大語言模型 LaMDA 實現了對話式推薦系統 RecLLM，開啓了對話式推薦系統的新模式。

RecLLM

如下圖所示，RecLLM 的整體框架包含以下幾個部分：
（1）對話管理模塊，負責與用戶交流並適時向推薦系統發起請求；
（2）召回模塊，負責在大規模語料庫中檢索出適合的推薦候選集；
（3）排序模塊，對推薦候選集合評分並提供推薦理由；
（4）用戶畫像模塊，負責形成可解釋性的用戶興趣並參與推薦流程；
（5）用戶模擬器，模擬用戶以生成對話示例，在系統冷啓時作爲樣本對各個模塊中的 LLM 做微調。

對話管理

對話管理模塊的核心功能包括兩部分，其一是實現與用戶的互動交流，其二是適時向推薦系統發起請求，以刷新推薦列表。爲實現推薦職能，要求對話管理模塊能夠在與用戶的交流中，有效的將對話引導至推薦相關話題，但引導的過程不能太生硬，即要注意對話的自然流暢、掌握恰當的時機和交流方法來啓發用戶以抽取其興趣喜好。對話管理模塊通過 LLM 驅動，上述話題引導的功能需特定數據對模型做微調來強化。

輸入到大模型中的數據可分爲三個部分，如下圖所示。首先是 Dialogue，它涵蓋了會話的上下文信息；其次是 User Profile 用戶畫像，其生成邏輯在下文講解；最後是 Item Summary，爲當前推薦內容的概述。模型的輸出同樣分爲三個部分：首先是 Context tracking，對會話上下文的總結；其次是 Instruction，即由模型產生的指令，這兩個部分類似於思維鏈，爲後續步驟的正確推理做鋪墊。最終部分爲 Response，它包括兩種輸出形式：“Response:” 旨在與用戶進行交流，而 “Request:” 則用於向推薦系統發起請求。

召回

論文探討了四種不同的推薦召回策略，如上圖表格。首先是 “Generalized Dual Encoder Model”，即最常用的雙塔召回方法。由於 RecLLM 策略的設計理念是僅通過分析用戶的對話內容來抓取用戶的興趣點，而不依賴於任何點擊或其它行爲數據，因此無法使用行爲樣本訓練雙塔。RecLLM 將會話上下文等用戶信息輸入至 LLM，直接使用其隱藏層作爲用戶向量，而物料向量則依賴於其他業務場景中已有的物料表示。然而，未經訓練的方式無法確保用戶和物料向量處於同一語義空間內，這導致了較差的性能表現；第二種是“Direct LLM Search” 召回，通過 LLM 直接生成物料的 ID 或標題，進而在物料庫中進行匹配。這種方法的缺點是，對大模型做微調既耗時又勞力，並且無法應對物料庫的頻繁更新；第三種方法爲 “Concept Based Search”，這是對雙塔召回的改進。在這種方式中，LLM 輸出一組相關“概念”，並利用“Concept Activation Vectors” 將這些概念聚合並映射到物品表示空間中，從而確保用戶和物品在相同的語義空間內。儘管如此，概念生成和概念激活向量的使用可能會損失一定的準確性，進而影響推薦精度；最後一種是 “Search API Lookup” 召回策略，這裏大模型生成的是搜索查詢 query，隨後利用已經存在於業務中的搜索 API 來獲得推薦內容。

排序

召回生成的候選集中的每一物料都將逐一被 LLM 打分，並同時生成語言解釋，其流程如上圖。由於內容冗長，物料的 Item Metadata（例如視頻字幕、用戶評論等）和用戶對話上下文 Context 都需經過總結處理後再輸入到 LLM 中。隨後，該模型會輸出評分以及語言解釋，語言解釋除了向用戶展示外，也起到了思維鏈的作用。

用戶畫像

雖然用戶在會話過程可以明確表達自身喜好，但爲了提供更加個性化的體驗，創建用戶畫像仍然十分必要。例如，如果用戶指出他們不喜歡看偶像劇，那麼應該在用戶畫像中記錄該偏好，有助於避免未來用戶重複提及。文本形式的用戶畫像不僅解釋性強，而且還允許用戶自己手動進行編輯和調整。

用戶畫像由三個關鍵部分組成。首先，Memory Extraction 負責使用 LLM 識別並記錄用戶顯著的喜好表達，例如識別 “我不喜歡看偶像劇”，並將其加入到用戶畫像。其次，Triggering and Retrieval 負責匹配每輪的對話內容與用戶畫像之間的文本相似性，由此篩選出所需要使用的用戶畫像。最後，System Integration 解決是關於如何將代表長期興趣的用戶畫像與當前對話內容集成，即使它們相互矛盾，仍能夠融合到一起的問題。例如，一個用戶可能平時不喜歡偶像劇，但由於對某個熱點事件感興趣，可能暫時需要查找特定的偶像劇。同樣，RecLLM 將兩者統一輸入至 LLM，藉助於其強大的文本理解能力和推理能力來解決這一矛盾。

數據模擬和微調

用戶模擬器的任務是仿真用戶與對話式推薦系統（CRS） 的交互響應。爲了確保用戶模擬器的真實性，它與 CRS 互動所產生的對話分佈 Q 應和真實用戶與 CRS 的對話分佈 R 無差異。RecLLM 提出了衡量兩分佈差異性的三種不同策略。第一種方法依賴於人工判斷；第二種方法涉及創建分類器以確定樣本是否來自真實分佈；第三種方法則是構建對話的主題、情感和用戶意圖等細粒度分類器，精準的評估兩個分佈間的差異。

用戶模擬器通過 LLM 實現，爲了確保其真實性，RecLLM 提出了兩種控制策略。第一種爲全局對話控制，涉及通過類似用戶畫像聲明作爲輸入來引導 LLM，例如：“I am a twelve year old boy who enjoys painting and video games”。第二種則是單次對話控制，利用用戶在其他業務中的行爲序列（例如搜索引擎中的 Query 序列）實現對用戶對話軌跡的模擬。使用用戶模擬器便可生成微調 LLM 的樣本，例如額外輸入提示詞 “在第 j 輪對話中提出生成 x 物料推薦的需求”。召回和排序階段使用模擬的數據來微調即可。其中在召回階段中爲解決樣本選擇偏差問題需要額外負採樣。對於對話管理模塊，使用了 RLHF 算法來微調。

更多技術細節請閱讀原始論文。

作者：Socket
鏈接：https://zhuanlan.zhihu.com/p/677347530

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/6711iOrnXmyegXoO-cyMFw