論文紹介：Towards a Unified Conversational Recommendation System: Multi-task Learning via Contextualized Knowledge Distillation

Transcript

1. Towards a Unified Conversational Recommendation System: Multi-task Learning via Contextualized Knowledge Distillation M2, Ryutaro Asahara. Inaba Lab, Department of Informatics, The University of Electro-Communications.
2. The University of Electro-Communications 論文の情報 • タイトル • Towards a Unified Conversational Recommendation System: Multi-task Learning via Contextualized Knowledge Distillation • 著者 • Yeongseo Jung, Eunseo Jung, Lei Chen • 所属 • The Hong Kong University of Science and Technology • 学会 • EMNLP2023 Main Conference
3. The University of Electro-Communications 目次 • 前提知識 • 提案手法 • 概要 • 教師モデルの構築 • 生徒モデルの構築 • 知識蒸留 • Hard GateとSoft Gate • 損失関数 • スペシャルトークン • 実験と結果
4. The University of Electro-Communications 目次 • 前提知識 • 提案手法 • 概要 • 教師モデルの構築 • 生徒モデルの構築 • 知識蒸留 • Hard GateとSoft Gate • 損失関数 • スペシャルトークン • 実験と結果
5. The University of Electro-Communications Conversational Recommender Systemとは I • 従来の推薦システムはクリックや購入，評価など過去の履歴を 基に推薦 • しかし，履歴がないユーザには推薦が難しい （コールドスタート問題） • そこで，会話をしながら推薦を行う推薦対話システム (Conversational Recommender System)の研究が活発 • ユーザの好みを聞き出し，好みそうなアイテム（映画，観光地， 音楽など）を推薦
6. The University of Electro-Communications Conversational Recommender Systemとは II • 2つのモジュールで構成 • 推薦モジュール • 対話履歴からユーザの 好みそうなアイテムを予測 • ユーザ埋め込みを計算し， アイテム埋め込みと マッチング • 対話モジュール • 推薦モジュールの情報を 用いて応答を生成
7. The University of Electro-Communications 既存CRSの問題点 • 推薦と対話のモジュールが別れている • 多くの手法は損失関数などで 両モジュールを学習 • 推薦モジュールで得られたベクトル表現 を対話モジュールにも用いる モジュール間の不一致問題が存在 推薦モジュールの予測→「タイタニック」 対話モジュールの応答→「アベンジャーズ」
8. The University of Electro-Communications 既存CRSの問題点 II • 既存CRSは不一致問題によって推薦性能が低下している • 推薦モジュールと対話モジュールの推薦性能を評価 • R@k(Recall@k) • 推薦モジュールの予測性能 • 推薦モジュールの予測したマッチングスコアのtop-kのアイテムを評価 • ReR@k(Response Recall@k) • 対話モジュールの予測性能 • 生成した応答に含まれるアイテムを評価
9. The University of Electro-Communications Knowledge Distillation（知識蒸留） • 能力の高いモデル（教師モデル）の知識を別のモデル（生徒モ デル）に移すこと • 手法は様々だが，一般に最小二条誤差やKL距離， 交差エントロピーによって両モデル間の差異を最小化する • 例 • 各層𝑙について教師と生徒モデルの隠れ表現ℎ𝑇 𝑙 , ℎ𝑆 𝑙 を最小化 • 教師と生徒モデルの出力分布𝑃 𝑥 , 𝑃(𝑦)のKL距離を最小化
10. The University of Electro-Communications アプローチ • 推薦と対話モジュールをそれぞれ教師モデルとする • 2つのモデルを1つの生徒モデルに蒸留して統合
11. The University of Electro-Communications 既存CRSのタスクについて 対話モジュール 推薦モジュール ターミネーターが好きな らトランスフォーマーも おすすめですよ トランスフォーマー:0.89 ドラえもん:0.1 ワンピース:0.01 トランスフォーマー:5 ドラえもん:2 ワンピース:1 ターミネーターが好きっ てことはトランスフォー マーもハマるはず！ BLUEやDISTINCE, Perplexityなどで評価 RecallやNDCGなどで評価 正解データ • 先行研究ではCRSを推薦モジュールと対話モジュールで それぞれ評価 • 推薦モジュール • 対話履歴と推薦候補アイテムから，ユーザの候補アイテムへの好みのスコアを予測 • 対話モジュール • 対話履歴から適切な応答を生成 正解データ
12. The University of Electro-Communications 本研究におけるタスク • 本研究では2つのモジュールを1つのモデルに統合する • 先行研究と同じ評価はできない • システム発話が言及したアイテムを用いて評価する ConKD ターミネーターが好きな らトランスフォーマーも おすすめですよ ターミネーターが好きっ てことはトランスフォー マーもハマるはず！ BLUEやDISTINCE, Perplexityなどで評価 正解データ トランスフォーマー 言及されたアイテムを抽出 トランスフォーマー:5 ドラえもん:2 ワンピース:1 RecallやNDCGなどで評価
13. The University of Electro-Communications 目次 • 前提知識 • 提案手法 • 概要 • 教師モデルの構築 • 生徒モデルの構築 • 知識蒸留 • Hard GateとSoft Gate • 損失関数 • スペシャルトークン • 実験と結果
14. The University of Electro-Communications 概要 • Hard GateとSoft Gateというアプローチを提案 • 推薦モデルと対話モデルのどちらからどの程度の知識を蒸留す るのかを決定
15. The University of Electro-Communications 目次 • 前提知識 • 提案手法 • 概要 • 教師モデルの構築 • 生徒モデルの構築 • 知識蒸留 • Hard GateとSoft Gate • 損失関数 • スペシャルトークン • 実験と結果
16. The University of Electro-Communications 教師モデル（推薦モジュール） • 推薦モジュール側の 教師モデルを構築 • 先行研究[Zhang+ 2020]の モデル構造(R-GCN)を採用 • 知識グラフ(DBpedia， ConceptNet)からアイテム と単語の埋め込みを学習 𝜀𝑒 𝑟：ノードeに対して関係rでリンクしているノードの集合 he′ (l)：ノードeにリンクしているノードe’のl層目の表現 he (l)：ノードeのl層目の表現， he 0：ノードeの初期の埋め込み，Wr (l),𝑊 𝑒 ：学習可能な重み
17. The University of Electro-Communications ユーザ表現の獲得 • 学習済みのモデルを用いてユーザ埋め込みを得る • 対話履歴𝑥に現れたアイテム𝑛(𝑥)と単語𝑣(𝑥)を以下式で集約 • ユーザ埋め込みを𝑝𝑢 とする • ユーザ埋め込みとアイテム埋め込みのマッチングスコアを計算
18. The University of Electro-Communications 教師モデル(対話モジュール) • 対話履歴とユーザ発話から応答を生成するモデルを学習 • 学習済みのモデルを採用 • KGSF：既存CRSの対話モジュール • DialoGPT：対話データセットで学習されたPLM 𝑇：トークンの長さ
19. The University of Electro-Communications 目次 • 前提知識 • 提案手法 • 概要 • 教師モデルの構築 • 生徒モデルの構築 • 知識蒸留 • Hard GateとSoft Gate • 損失関数 • スペシャルトークン • 実験と結果
20. The University of Electro-Communications 生徒モデル • 対話履歴とユーザ発話から応答を生成するモデル • 学習済みのモデルを採用 • KGSF：既存CRSの対話モジュール • DialoGPT：対話データセットで学習されたPLM • 教師となる対話モデルと同じ
21. The University of Electro-Communications 目次 • 前提知識 • 提案手法 • 概要 • 教師モデルの構築 • 生徒モデルの構築 • 知識蒸留 • Hard GateとSoft Gate • 損失関数 • スペシャルトークン • 実験と結果
22. The University of Electro-Communications 知識蒸留 • 交差エントロピーによって損失を計算 • 各教師と生徒モデルの確率分布がどの程度離れているかを計算 • この損失を最小化することで教師モデルの知識を蒸留 𝑃𝜙 (𝑦𝑡,𝑘 |𝑦1:𝑡−1 , 𝑥)：教師モデル（対話）の出力分布 𝑃𝜓 (𝑦𝑡,𝑘 |𝑦1:𝑡−1 , 𝑥)：教師モデル（推薦）の出力分布 𝑃𝜃 (𝑦𝑡,𝑘 |𝑦1:𝑡−1 , 𝑥)：生徒モデルの出力分布
23. The University of Electro-Communications 目次 • 前提知識 • 提案手法 • 概要 • 教師モデルの構築 • 生徒モデルの構築 • 知識蒸留 • Hard GateとSoft Gate • 損失関数 • スペシャルトークン • 実験と結果
24. The University of Electro-Communications 教師モデルからどの程度学習するのか • 性質の異なる2つの教師モデルのどちらからどの程度の知識を 蒸留するのか • 2つのアプローチを提案 • Hard Gate • 対話のフェーズから推薦・対話モデルのどちらの知識を用いるかを 離散的に決定 • Soft Gate • どちらのモデルからどの程度学習するかを連続的な割合で決定
25. The University of Electro-Communications Hard Gate I • 生徒モデルは教師モデルの条件付き確率との差異を最小化する ように学習する • しかし，2つのモデルに対して常に知識を蒸留することは好ま しくない • 対話のフェーズごとに必要な知識が異なる • 雑談中には対話モジュールの知識が役に立つ • 推薦する際には推薦モジュールの知識が必要 どちらの知識を用いるのか決定するHard Gateを導入
26. The University of Electro-Communications Hard Gate II • 「推薦時は対話モデルにおけるアイテムの生成確率が 大きくなる」と仮定 • 例えば • 映画を推薦する際にはタイトルの生成確率が高くなる • 教師としての対話モデルにおいて，各アイテムの生成確率の総 和がしきい値以下の場合は対話モデルから蒸留 • しきい値を超えた場合は推薦モデルから蒸留 ℐ：アイテムの集合 𝜂：しきい値
27. The University of Electro-Communications Soft Gate • 「対話モデルの出力確率におけるアイテムの確率が高いほど， 推薦が期待される」と仮定 • つまり，アイテムの生成確率の総和が高いほど， 推薦モデルから多く学習 ℐ：アイテムの集合
28. The University of Electro-Communications 目次 • 前提知識 • 提案手法 • 概要 • 教師モデルの構築 • 生徒モデルの構築 • 知識蒸留 • Hard GateとSoft Gate • 損失関数 • スペシャルトークン • 実験と結果
29. The University of Electro-Communications 損失関数 • Hard Gate，Soft Gateのどちらも以下の式によって全体の損失を 計算 • タイムステップ𝑡ごとに， • Hard Gateならℒ𝐷𝐼𝐴𝐿 とℒ𝑅𝐸𝐶 のどちらかを用いる • Soft Gateならℒ𝐷𝐼𝐴𝐿 とℒ𝑅𝐸𝐶 を𝜆𝑡 で示される割合で用いる ℒ𝑁𝐿𝐿 ：正解データとの交差エントロピー損失
30. The University of Electro-Communications 目次 • 前提知識 • 提案手法 • 概要 • 教師モデルの構築 • 生徒モデルの構築 • 知識蒸留 • Hard GateとSoft Gate • 損失関数 • スペシャルトークン • 実験と結果
31. The University of Electro-Communications スペシャルトークン • CRSの対話では推薦をするか雑談ターンのいずれかに 大きく分類できる • 以下のスペシャルトークンをシステム発話の先頭に付与 • 応答が推薦アイテムを含む場合は[REC] • 含まない場合は[GEN] • 推論時は発話が推薦かそれ以外かを分類するモデルを用いる • 対話履歴と対象の発話を入力し対象発話が推薦か雑談かを分類
32. The University of Electro-Communications 目次 • 前提知識 • 提案手法 • 概要 • 教師モデルの構築 • 生徒モデルの構築 • 知識蒸留 • Hard GateとSoft Gate • 損失関数 • スペシャルトークン • 実験と結果
33. The University of Electro-Communications 実験 – データセット • REDIAL • CRSの評価に幅広く用いられるデータセット • 推薦アイテムのドメインは映画 • 対話数は10,006，映画の総数は6,924 • 語彙数は23,928 • 英語の通常語彙とアイテム名（映画名）を含む
34. The University of Electro-Communications 実験 – ベースライン • ReDial • 対話，推薦，感情分析モジュールで構成 • KBRD • 推薦アイテムの知識グラフを導入 • KGSF • 推薦アイテムと単語の知識グラフを導入 • RevCore • レビューデータを用いたCRS • DialoGPT • REDIALでFine-tuningしたDialoGPT • RecInDial • DialoGPTの語彙を拡張し，End-to-Endで推薦
35. The University of Electro-Communications 実験 – 評価指標 • 推薦タスクの評価 • 生成した応答にtop-kのアイテムが含まれているかで評価 • ReR@k，PrR@k，F1@k • RecRatio • 全対話中で推薦アイテムが含まれる発話の比率 • 対話タスクの評価 • 正解応答と生成応答間のPerplexityとDistinctで評価 • PPL(Perplexity)，DIST-1,2,3,4 • 人間による評価 • Fluency, Informativeness, Coherence
36. The University of Electro-Communications 評価結果 – 推薦タスク • Hard Gateではモデルが積極的に推薦している • RecRatioが他モデルに比べて高い
37. The University of Electro-Communications 評価結果 – 対話タスク • モデルのパラメータ数に関わらず提案手法ConKDが性能を向上 させている
38. The University of Electro-Communications 評価結果(推薦タスク) – 正解アイテムの拡大 • CRSでは正解アイテム以外にも好みが及んでいる可能性がある • 知識グラフで正解アイテムの2ホップ以内にある アイテムも正解として評価
39. The University of Electro-Communications Ablation Study – 推薦タスク • Ablation • D：対話モデルを蒸留に用いる • R：推薦モデルを蒸留に用いる • ST：スペシャルトークンを用いる • 𝜆𝑡 を用いずに常に0.5の割合で教師モデルから損失を計算
40. The University of Electro-Communications Ablation Study – 対話タスク • Ablation • D：対話モデルを蒸留に用いる • R：推薦モデルを蒸留に用いる • ST：スペシャルトークンを用いる • 𝜆𝑡 を用いずに常に0.5の割合で教師モデルから損失を計算
41. The University of Electro-Communications Case Study • *：ConKD(Hard) • **：ConKD(Soft)
42. The University of Electro-Communications まとめ • CRSにおいて推薦・対話モジュールを1つのモデルに 蒸留する手法ConKDを提案 • 推薦・対話タスクにおいていくつかの評価指標で高い性能を示 した
43. The University of Electro-Communications 不十分な点 • 既存手法にだいぶ負けている • 違うモダリティを持つモデルを蒸留することは望ましくないの ではないか • 教師モデル(対話)：言語モデル • 教師モデル(推薦)：グラフモデル • 生徒モデル：言語モデル
44. The University of Electro-Communications スライド付録 A • なぜ推薦モジュールの予測結果を直に応答生成結果に埋め込ま ないのか