\documentclass[japanese,tombow,other]{jnlp_3.3}
\usepackage{jnlpbbl_2.2}
\usepackage[dvipdfmx]{graphicx}
\usepackage{amsmath}
\usepackage{gentombow}
\settombowbleed{5mm}
%%%%\usepackage{hangcaption_jnlp}
%%%%\usepackage{udline}
%%%%\setulminsep{1.2ex}{0.2ex}
%%%%\let\underline=\ul
\usepackage{url}
\allowdisplaybreaks


\Volume{28}
\Number{1}
\Month{March}
\Year{2021}
%%%%\Issuetitle{「　　　　」特集号}


\setcounter{page}{264}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\jsubject{学会記事}
\jtitle{「You May Like This Hotel Because ...: \\Identifying Evidence for Explainable Recommendations」の研究を振り返って}
\jauthor{叶内　　晨\affiref{Author_1}}
\etitle{You May Like This Hotel Because ...: Identifying Evidence for Explainable Recommendations}
\eauthor{Shin Kanouchi\affiref{Author_1}} 

\headauthor{叶内}
\headtitle{Identifying Evidence for Explainable Recommendations}

\affilabel{Author_1}{株式会社リクルート Megagon Labs, Tokyo}{Megagon Labs, Tokyo}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
\maketitle


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{まえがき}

本解説記事では，著者らのAACL-IJCNLP2020に採択された論文``You May Like This Hotel Because ...: Identifying Evidence for Explainable Recommendations'' (Shin Kanouchi, Masato Neishi, Yuta Hayashibe, Hiroki Ouchi and Naoaki Okazaki)（以下，原論文）について，その着想に至る経緯，採択・公開までの流れに重点を置いて解説する．
著者は事業会社にてデータを活用した開発案件に従事後，現在，株式会社リクルートのMegagon Labsにて事業の実サービスにおける課題を意識した研究開発に取り組んでいる．
その実サービスの課題を意識した上での研究テーマ決定から論文執筆・採択までの過程の共有が，少しでも読者の助けになれば幸いである．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{研究のはじまり}

近年，機械学習モデルを利用した予測や推薦時に，なぜその候補が出力されたのか，という推薦根拠の説明性に注目が集まっている \cite{zhang2018explainable}．
例えば，協調フィルタリングを用いた推薦根拠の説明では，「この商品を買ったユーザはこちらの商品も購入しています」と説明する研究 \cite{sarwar2001item}があり，特徴量に基づいた根拠説明では，「\verb|[feature]|に興味があるあなたには，こちらの商品がオススメです」と，スロット付きのテンプレート文を使って推薦文を生成する研究がある \cite{zhang2014explicit}．また，\citeA{Zhao:2019:PRG}は深層学習を用いて，曲名・作者・ユーザタグを入力として，音楽の推薦時にその推薦根拠を生成している．

上記の関連研究は，著者が研究テーマを深掘る際に網羅的にサーベイをして知った内容であり，実際にはそのサーベイ以前から推薦根拠の説明性について，ユーザ目線と企業の開発目線でそれぞれ感じることがあった．
(1)ユーザ目線では，日常的に利用するサービスで検索結果や推薦結果のソート順に「オススメ順」を見つけるたびに，何がランキングに寄与したオススメ順なのだろうか，自分にカスタマイズされているのだろうか，もしも自分からインタラクティブに情報を提供できればもっと良いランキング結果にならないだろうか，という思いがあった．(2)企業の開発目線では，過去にデータを活用した開発案件で，精度よりも説明性を重視することが複数回あり，説明性の重要性を肌で感じていた．一方で，テキストデータをメインで用いる予測・推薦で説明をする必要があるタスクでは，既存の論文に似た研究がある場合でも，現場に導入するハードルは高いことが多く，研究開発として中長期スパンで取り組む価値を感じていた．
それらの背景から，「何か要求や条件を持っているユーザに対して，商品推薦時にテキストで推薦根拠を説明する」という研究に方向性を定めた．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{研究の具体化}

著者の所属研究所の意向も踏まえて，ドメインはホテル予約ドメインとし，数年後に実サービスへの導入を目標として，現実の課題と既存の使用可能な技術の両面を考慮してタスクの具体化を目指した．
まず，誰にどんな出力を与えれば新しい価値を提供できるかという点についての考察を，ユーザが宿をオンラインで予約する場合と，旅行代理店に足を運んでオフラインで予約する場合のギャップに着目しながら行った．

オンライン予約では，主にユーザが特定の条件（人数・地域・禁煙・大浴場ありなど）やキーワードで宿を絞り込んだ上で候補一覧を表示し，気になる候補の詳細ページを確認し，予約する．
一方で旅行代理店では，オペレータが各ユーザについての多様な情報を元に候補を絞り込んで宿を提示し，追加の条件などがある場合は対話を通して宿の候補を入れ替え，予約する．
オフラインの代理店でのみ得られる体験として，オペレータがユーザの曖昧な情報を具体化して候補を提示してくれることがある．
例えば「子連れに優しい宿が良い」などの抽象的な要求\footnote{抽象的な要求とは，具体的な商品や体験・サービスを指定しない要求のことを指す．}が提示された時，オペレータは宿の推薦と同時に「こちらの宿は，キッズスペースもあり子連れにオススメです」と推薦根拠も提示することが多い．
このような抽象的な要求に対する推薦根拠の提示は，推薦の説得力を増すだけでなく，ユーザのより具体的な要求を引き出すことを可能にする．
オンライン予約でもユーザの要求が具体的であればキーワードによる検索が可能だが，抽象的な要求は曖昧性が高く対処が難しい．
そこで原論文では「根拠を必要とするような抽象的な要求が与えられた場合に，推薦根拠付き推薦文を作成して宿を推薦する」ことを目標とした．
ただし，著者の研究所では既に，主観表現に対して検索を行う研究 \cite{Li:2019:vldb}に取り組んでいるため，原論文では検索候補は選定せず，曖昧な要求に対応する推薦根拠の提示に注力した．

タスク具体化の途中で，利用するデータも選定した．日本語で推薦根拠を説明するための利用可能な公開済みデータセットは存在しておらず，また精度を高めるためにも教師あり機械学習で解くことが現実的と考えられたため，自ら新しいデータを構築することにした．
著者は運良く実サービスのデータを持った企業に所属していたため，事業のデータである旅行情報サイトの宿に関するレビューデータを利用した．データの候補は他にもあったが，データサイズが大きい・データ公開が現実的である・多言語や他ドメインへの検証がしやすい，などの理由からレビューデータを採用した．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{アノテーションとデータセット構築}
\label{sec:annotation}

アノテーション方法を検討する上で，関連研究として，推薦説明タスク \cite{zhang2018explainable}以外にも，「感情表現-対象や原因」に着目した感情分析タスク\cite{chen2010emotion,gui2016event}や，SQuADなどの言語読解系のタスク \cite{rajpurkar2016squad}を意識しながらデータセット構築を進めた．
感情分析タスクと同様に，「感情表現」を抽出後にそれに対応した「対象や原因」をアノテーションすることを検討していたが，自分が対象としたい抽象的な要求（「ゆっくりしたい」「愛犬と泊まれる」「歴史ある旅館」など）が「感情表現」の枠に収まらず，どう網羅的に抽出するかが課題となった．

分析を進める中で，レビュータイトルとレビュー本文の対応関係が利用できる可能性を感じた．
なぜなら，レビュータイトルには，宿泊した宿に対する特に満足した点が一言で要約して記述されることが多く，
一方で対応するレビュー本文には，ユーザの実体験に基づく感想や宿のサービスの描写が記述され，中でもレビュータイトルをより具体的にした記述が散見された．
そこで，(1)タイトルと抽象的な要求の類似性を利用して，宿のレビューデータについてタイトルの一部を抽象的な要求とみなして収集し，(2)対応するレビュー本文からその要求に対応する根拠を含む文を抽出し，(3)さらにその根拠文を推薦文へ言い換えるという方針を立てた．

データセット構築のための全体のパイプラインを図\ref{img:pipeline}に示す．
処理は次の3段階である．

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% fig. 1
\begin{figure}[b]
\begin{center}
\includegraphics{28-1ia103f1.pdf}
\end{center}
\caption{根拠説明データセット構築のパイプライン}
\label{img:pipeline}
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{enumerate}
 \item \textbf{レビュータイトルから抽象的な要求を収集}
 「宿」を表す表現を含むなどのルールにより，抽象的な要求とみなせるタイトルを収集する．
 \item \textbf{根拠文判定（クラウドソーシングを利用しアノテーション）}
 収集した要求をタイトルにもつレビューについて，本文の各文がその要求に対する根拠を含むか判定する．
 \item \textbf{推薦文言い換え（クラウドソーシングを利用しアノテーション）}
 要求の根拠を含むと判定された文を，その要求をもつユーザに対する根拠付きの推薦文へと言い換える．
\end{enumerate}

アノテーション済みデータセットは公開済みである\footnote{\url{https://github.com/megagonlabs/ebe-dataset}}．詳細は原論文\cite{kanouchi2020evidence}を参照されたい．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{実験}
\label{sec:experiment}

\ref{sec:annotation}節でアノテーションしたデータセットを用いて，要求と各文が与えられた時に
(1)根拠文かどうかを二値分類するタスク，
(2)根拠文を推薦文に言い換えるタスク
の2つを実験した．
(1)の根拠文分類タスクの実験では，BERT \cite{devlin:2019:bert}を用いて，様々な種類の要求に対してその根拠文を分類できることを示した（F1スコア: 79.94）．また，テストデータで初めて出現した要求に対しても，精度はあまり低下しないことも示した．
(2)の推薦文言い換えタスクでは，エンコーダデコーダモデルを用いて実験した．LSTMベースのモデル \cite{luong2015effective}がスコア最大で，根拠文を入力とした場合にBLEUスコア56.09，ゴールドデータではない文（根拠かどうかわからない文）を入力した場合にBLEUスコア45.38で推薦文を生成できることを示した．
詳細は原論文を参照されたい．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{論文執筆・採択とデータ公開}

今回著者は，いわゆるトップカンファレンスに通すことよりも，1年以内に確実に研究内容を外部に公開することを優先した．
その理由としては，社内外に対して著者がこのタスクに取り組んでいることを共有することや，公開したデータを他の方が使って研究してくれるような土台作りが必要だと感じたことがある．実際の作業の流れは以下となった．

\begin{itemize}
  \item 2019年9月--12月: テーマ検討・アノテーション・実験
  \item 2020年1月: 言語処理学会第26回年次大会へ投稿 $\rightarrow$ 3月: 発表
  \item 2020年6月: AACL-IJCNLP 2020へ投稿（採択） $\rightarrow$ 12月: 発表
  \item 2020年7月: COLING 2020へ投稿（リジェクト）
  \item 2020年10月: データ公開
\end{itemize}

COVID-19の流行の影響で想定から修正が必要だったが，1月に年次大会で日本語版の論文を書き，3月に発表してフィードバックを頂き，その結果を踏まえて英語化した論文を仕上げて国際会議に投稿する，という当初の想定通りのスケジュールをこなした．COLINGは残念ながらリジェクトであったが，査読者のコメントをAACL-IJCNLPのCamera-ready版に反映することができ，大変ありがたく感じている．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{終わりに}

原論文について，その着想に至る経緯，採択・公開までの流れに重点を置いて解説した．
今後の展望として，まずは実サービスを見据えたシステム全体の評価とそれを踏まえた改善に取り組み，その後，実サービス上への統合を目指していきたい．




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\bibliographystyle{jnlpbbl_1.6}
\bibliography{23refs}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{biography}
\bioauthor{叶内　　晨}{
2015年 東京都立大学（旧，首都大学東京）卒業．2017年 東京都立大学大学院博士前期課程修了．
同年，株式会社リクルートテクノロジーズ入社．2019年4月 株式会社リクルートのMegagon Labsへ異動し，現在，リサーチサイエンティストとして研究開発に従事． 
}

\end{biography}




\end{document}




