SIGIR 2019 に参加してきました

はじめに

2019年7月21日〜25日に開催された SIGIR 2019 に参加してきました。SIGIR は「Special Interest Group on Information Retrieval」 の略で、毎年開催されるカンファレンスは情報検索の分野において最も重要なカンファレンスといわれています。今年のカンファレンスでは、LTR(Learning to Rank、ランキング学習)、リコメンデーション、評価、クエリパフォーマンスなど、多様な研究テーマについての発表がありました。

会場は Cité des Sciences et de l’Industrie(シテ科学産業博物館)という欧州最大級の科学博物館で、チュートリアルを含めたカンファレンスの3日目の食事会は博物館の2階で行われました。

食事会の他に、初日に La grande galerie de l’Évolution という別の博物館でウェルカムレセプションもありました。

今年の SIGIR は初めて中国からの提出された論文数もアクセプトされた論文数もアメリカの論文数を超えました。

SIGIR 2019 は大きくチュートリアル、カンファレンス、そしてワークショップに分かれていました。以下、参加してきたセッションの中で関心を持ったものについて書きます。

チュートリアル

初日は Effective Online Evaluation for Web Search という一日のチュートリアルに参加しました。登壇者は Yandex社より5人、Facebook AI Research より1人いました。チュートリアルはWebサービスの更新に対する評価についてで、概要や資料などはここで見られます。豊富な内容でしたが、特に下記の項目が面白いと思いました。

A/B Testing

A/B テストとは、サービスの新しい機能や変更を試すときに、サービスの利用者をランダムに2つグループに分け、その新しい変更が適用されているサービスを片方のグループにだけ提供し、変更内容を評価する手法です。検索サービスの場合は、例えば 検索UI を変えるといったフロントエンドの変更や、検索結果の表示順を決めるランキングモデルを変えるといったバックエンドの変更などあります。A/B テストはユーザエクスペリエンス(UX)に影響を及ぼすため、基本的に事前に検討中の変更に対してオフラインで評価した上で、A/Bテストを行うか否か判断します。

全ユーザに対しても、ユーザ一人に対しても複数 A/B テストを同時に行うことが可能で、Yandex社ではまさにそうしているそうです。ただし、複数実験を同時に行うと、それぞれの変更が衝突し合い、想定外な結果になる危険性があるため、そうならないように注意する必要があります。ワークショップ時点で Yandex社では、実験を行わないユーザの割合は20%、1つ実験を行うユーザの割合は15%で、残り65%のユーザに対して2つ以上の実験が行われています。 ワークショップ資料の Part 3 の 13〜20ページに実験例、Yandex社のユーザに対する実験数のグラフなどが載っています。

評価手法の Directionality と Sensitivity

評価手法には sensitivity(感度)と directionality(指向性度)があります。sensitivity はある評価手法で統計学的に有意差の有無の測りやすさのことを指します。評価手法の sensitivity が高ければ高いほど、以下のことが見られます。

  • 評価値の小差を測れる
  • より sensitivity の低い手法に比べて、同じ差を測るのに必要なユーザ・データが少ない
  • 変更が適用された後すぐに評価値が変わる

一方、directionality は評価値の意味の明瞭さを指し、directionality が高い方が評価値の意味がはっきりしています。例えば、ユーザの投げたクエリ数をメトリックとして用いて、ある実験で全体的にクエリ数が上がったこと見られたとします。その場合は、検索結果の画面に表示される広告のクリック数も上がり、売り上げが上がる可能性がありますが、クエリの数が上がった理由はユーザの満足度が上がったからサービスをよりよく利用しているからか、求めている検索結果が見つからないからクエリを書き換える回数が上がったからかは不明です。後者の場合は長期的な売り上げに悪影響を与える危険性があります。評価値が上がっても、良いことかよくないことか不明だということは、directionality が低いという意味です。

上記例は directionality が低いですが、何か UX に変化があると、すぐにクエリを投げる回数が変わりますので sensitivity が高いです。それに対して、「ユーザの満足度」というメトリックを考えてみましょう。ユーザ満足度は非常に Directionality が高いですが、非常に測りにくく(測り得ないことが多く)、クエリ発行数とは異なり変わるのに時間がかかるため非常に sensitivity が低いです。ユーザの満足度を充分に測ることができたら理想的ですが、測れないので別の「ユーザのセッション数」を考えてみましょう。

セッション数は満足度より測りやすく、sensitivity が高いのに対し、directionality は低いです。クエリ発行数に関しては、セッションの定義次第ではありますが、クエリ数とは異なり、ユーザが求めている結果が見つからないことが多くなったら、満足度が下がり、利用回数もセッション数も下がるでしょう。しかし、セッション数の変化を測るには長い期間を見なくてはならないので、クエリ数より sensitivity が低くて、directionality が高いです。

評価手法は Web Service の目標と sensitivity と directionality を考えながら選択または開発すると良いとのことでした。既存の手法があれば、その directionality を保ちながら少しずつ sensitivity を上げていくことを目標にすれば、Web Service の改善を実現できます。

ワークショップ資料の 「Part 2 Development of online metrics」という部分に directionality と sensitivity の例、評価手法の開発や Yandex 評価手法開発に関する事例などが見られます。

Interleaving

A/B テストではユーザレベルのノイズを考慮できません。例えば、グループA に現在の本番環境を提供し、グループB に対して実験を行なって評価すると、グループAとグループBの差は見られますが、グループB のあるユーザがもしグループA に表示された結果を見たらどうするかはわかりませんので、個人レベルにおける比較は不可能です。実際はどんなクエリでもよくクリックを行うユーザもいれば、求める結果がない場合クエリを何度も書き換えるユーザもいます。このように、多様なユーザが存在するためユーザ間でノイズが生まれます。

そこで、interleaving という手法が開発されました。interleaving では、以下の図のように二つのランキングを混ぜ合わせて新しいランキングを作り、それをユーザに提供します。

interleaving にいくつか手法があり、手法によって混ぜ合わせ方や新しい検索結果の表示順が決まります。2つ以上のランキングモデルを比較したい場合は複数の interleaving を行うか、複数のモデルを比較できるように汎用化された interleaving、multileaving という手法を使います。

A/B テストではユーザが本番環境にデプロイ中のランキングモデルとは異なるモデルによるランキングしか見ません。しかし、interleaving ではデプロイ中のランキングからいくつか検索結果も見られますので、interleaving では、ユーザレベルのノイズをなくすのみならず、ある程度実験中の UX の悪化を避けることができます。

カンファレンス

7月22日〜23日に開催されたカンファレンスには、キーノート、カンファレンスセッション、そしてポスターセッションがありました。カンファレンスセッションでは、一人研究者が登壇し論文を発表したり、時間があれば質疑応答をします。それに対して、ポスターセッションでは、一つの部屋に短い論文についてのポスターが沢山貼られており、研究者が一人、または少人数に直接発表したり話し合ったりします。下記のまとめの見出しに書いてある [Session] か [Poster] で区別がつきます。

本記事では著者の情報を省略しますが、著者や論文などについてはここで確認できます。

Domain Adaptation for Enterprise Email Search [Session]

本セッションでは、データのドメイン適応(domain adaptation)という技法を用いて、グローバルなランキングモデルを異なるコーパスに有効になるように調整する方法とその詳細について発表されました。研究動機と抱えている課題は企業内メール検索にありますが、開発された技法はとても汎用性が高いです。以下、その課題と解決策となる技法をまとめます。

ウェブ検索のランキングモデルは基本的に豊富な user interaction data と汎用なコーパスに対して学習して構築されたものです。一方、企業内メール検索サービスはクラウド上で提供すると、全体のデータに対してランキングモデル(汎用モデル)は作れますが、各ユーザのコーパスが小さく、偏っていることが多いので、全ユーザに汎用モデルでランキングを提供すると最適な結果になりません。

例えば、半導体のメーカーが人気のある企業内メール検索のサービスを利用しているとします。そのメーカーのすべてのメールでできたコーパスは専門性が高く、メール検索サービスが処理する全てのメールでできたコーパスほど汎用でもなく、大きくもないです。従ってメール検索サービスの汎用ランキングモデルを半導体メーカーのメール検索に適用しようとすると、最適なランキングを得られなくてもおかしくないです。

一つの解決策として、ユーザ(企業・ターゲットドメイン)ごとにランキングモデルを構築することは可能ですが、企業内メール検索の場合はデータが不足していることが多く、モデルを構築しようとしたら過学習してしまう可能性が高いです。もう一つの解決策としては、ターゲットドメインのデータを使って汎用モデルのパラメータを調整しながら目標のドメインにフィットすることも可能ですが、これは非常に難しくて費用のかかるプロセスです。

そこで、本セッションで発表されたドメイン適応技法を使えば、汎用ランキングモデルを各ユーザに対して調整し、より性能の良いモデルを得られます。ドメイン適応とは、転移学習の一種で、あるドメインで学習されたモデルを異なるドメインにも効くように適応させることです。以下は企業内メールランキングモデルのアーキテクチャーの図です。

上記モデルは、上記図のソースデータセットに対して学習した深層学習モデル(予測モデル)をターゲットデータセットにも使えるようになることを目的としています。「埋め込み空間」とは、特徴量が存在する空間とは異なる空間で、データセットをこの埋め込み空間へのマッピングを行います。データ次第でマッピング方法を決めますが、例えばニューラルネットワークを使ったりできます。埋め込みベクトルはクエリと文書のペアを表します。「予測モデル」はクリックを予測するニューラルネットワークのモデルです。

「訂正モデル」は、ドメイン適応を行うために追加された部分で、GAN(Generative Adversarial Network)に基づいた手法(Discriminator-based techniques)と統計学に基づいた手法がありましたが、前者のみ簡単にまとめます。入力特徴量が「ソース」か「ターゲット」のデータだと予測するニューラルネットワークがあります。目的はこのニューラルネットワークが「ソース」か「ターゲット」か予測できなくなるように埋め込みベクトルを調整することです。例えば「ソース」か「ターゲット」を予測するための(正確に予測した方が小さくなる)損失関数があるとすれば、それを最大化することで調整できます。予測モデルと統計学的手法を使うことで、埋め込み空間で表現するソースドメインとターゲットドメインを区別できなくなるようにします。

実験結果として、GAN に基づいた手法も統計学に基づいた手法も4つのベースラインより性能が高かったそうです。以下のベースラインが使われていました。

  • ソースデータセットに対して学習したモデル (Train all model)
  • ターゲットドメインのみに対して学習したモデル (Domain model)
  • Train all model を学習後、ドメインのデータのみでより低い学習率で再学習(re-train)
  • Train all model に似ているが、各バッチに必ず指定した割合でターゲットドメインのデータを入れる

研究結果の詳細や数式などは元の論文を参照してください。

Revisiting Approximate Metric Optimization in the Age of Deep Neural Networks [Poster]

本ポスターセッションは、NDCG(Normalized Discounted Cumulative Gain) を近似してランキングモデルを構築する実験についてでした。NDCG はランキング学習で利用されている評価手法の一つで、以下の数式で計算できます。


上記式の Z は理想のランキングで計算されたDCGです。数式で使う j はランクを表し、ランクを計算するのに、あるクエリに対して文書j よりスコア・関連度(モデルによって出力された値)の高い文書を数える必要があります。下記式(元の論文の式(5))で表現できます。

上記式の関数fはランキングモデルの出力で s < t であれば I = 1 (そうでないときは 0 )です。この式は微分不能かつ非連続のため、直接勾配降下法を適用できません。直接 NDCG を目的関数として勾配降下法で利用できないため、LambdaMART や LambdaRank のように間接的に最適化しようとしたりしますが、ランクを計算する関数を Sigmoid で近似することで得られる ApproxNDCG (近似NDCG)は微分可能なので直接勾配降下法で最適化できるようになります。

Web30K と Yahoo! のテストセットに対して実験を行なった結果、LightGBM の LambdaMART 以外のランキングモデルより性能が良かったことが見られたそうです。

実験結果や論文の詳細などについては元の論文を参照してください。

その他の気になったセッション・ポスター

上記のセッション以外に、Investigating Passage-level Relevance and Its Role in Document-level Relevance JudgementHow Does Domain Expertise Affect Users’ Search Interaction and Outcome in Exploratory Search?、そして SIGIR 2019 の Best Paper Award を受賞したVariance Reduction in Gradient Exploration for Online Learning to Rankも興味深いと感じましたので、できれば後日追記したいと考えています。

ワークショップ

最終日に開催された Workshop on Fairness, Accountability, Confidentiality, Transparency, and Safety in Information Retrieval (FACTS-IR) というワークショップに参加しました。FACTS-IR は「公平性」「アカウンタビリティー」「機密性」「透明性」「安全性」という5つの観点から責任を持った情報検索システムの開発やデプロイについてでした。ワークショップの前半はカンファレンスセッションの同じように論文の発表がありましたが、後半は5〜6人のグループで FACTS に関する可能な研究テーマについてディスカッションをしました。私のグループは「透明性の高い情報検索システムの構築」に関する研究すべきテーマについてディスカッションをしました。以下、後半で話し合いをした内容を簡単にまとめます。

情報検索において「透明性」とは何でしょうか。例えば、映画のリコメンデーションシステムで言えば、「あなたは X を見たから Y をおすすめしています」とリコメンデーションの結果が説明されていることをある程度「透明性のあるリコメンデーションシステム」と言えるでしょう。もう一つの例として、ユーザA とユーザB が同じクエリを投げて、異なる結果・ランキングが返されたとき、または、あるはずの検索結果がないときに、その理由を説明できればそれもある程度、透明性のあるシステムと言えるでしょう。ただし、透明性のあるシステムを構築するには UX と機密性のバランスと、複雑なランキングモデルを使った場合どう説明すべきかということなど考慮しなければなりません。

UX とのバランスの例として、説明を追記するのに UI を変える必要があります。チュートリアルの部分に書いたように、UI の変化は UX の悪化をもたらす危険性があります。特にユーザのいらない・求めていない説明だらけになるような検索結果画面になったら、UX の悪化が発生するでしょう。

機密性とのバランスの例として、自分の名前を検索し、とても古くて関係なくなった結果が返されたら、その結果をランキングから削除するように申請ができます。削除された場合は誰のユーザであろうが、その文書は当たらなくなるはずです。別のユーザが過去にクエリを投げ、前にあった結果がなくなったことに気づいて、説明を求めたとします。「申請により削除された」と説明があった場合は、削除依頼した人の機密性を破ることになります。

深層学習などで得られた複雑なランキングモデルにそもそも説明がつかないときもあるでしょう。これは情報検索に限らず、機械学習の大きな問題でもあります。例えば、保険業界で非常に性能の高い深層学習のモデルでお客さんの保険プランの資格の有無を決める場合、「資格なし」と判断した場合は説明を求められるでしょう。説明ができなかったら、そのモデルはどんなに性能が高くても使えないことがあるでしょう。これと同じように、検索結果の説明が必要となれば、複雑なランキングモデルを使えなくなるか、説明できるように費用・リソースをかけなければならないかもしれません。

ディスカッションが終わると、グループで話し合った点を他のグループと共有しました。

終わりに

検索やリコメンデーション、ランキング学習についてのセッションのみならず、ワークショップで社会学的なテーマと情報科学・情報検索のテーマを混ぜ合わせた豊富なディスカッションにも参加できましたので私の初めての SIGIR は非常に勉強になりました。

以上

sigirReport

Comments

Popular posts from this blog

ランキング学習 〜情報検索への機械学習の応用〜

「機械学習の論文をスクラッチから実装しよう!」LambdaMART の数式をコードに落とす

Spark + AI Summit Europe 2018 に参加してきました