山田 育矢 (Ikuya Yamada) Studio Ousia / RIKEN AIP オープンドメイン質問応答技術の最新動向 NeurIPS EfficientQAコンペティションの上位システムから学ぶ

自己紹介 山田 育矢 (@ikuyamada) Studio Ousia 共同創業者チーフサイエンティスト 理化学研究所AIP 客員研究員（知識獲得チーム、言語情報アクセス技術チーム） ● 大学入学時に、学生ベンチャー企業を起業し売却（2000年〜2006年） ○ インターネットの基盤技術（Peer to Peer通信におけるNAT越え問題）の研究開発を推進 ○ 売却先企業は株式上場 ● Studio Ousiaを共同創業し、自然言語処理に取り組む（2007年〜） ○ 質問応答を中心とした自然言語処理の研究開発を推進 ● プログラミングが好き ○ 最近よく使うライブラリ：PyTorch、PyTorch-lightning、transformers、Wikipedia2Vec ● コンペティション・シェアードタスクにいろいろ出場 ○ 優勝したタスク：#Microposts @ WWW2015, W-NUT Task #1 @ ACL 2015, HCQA @ NAACL 2016, HCQA @ NIPS 2017, Semantic Web Challenge @ ISWC 2020 2

本講演の概要 ● オープンドメイン質問応答の最新動向を解説 ● NeurIPS EfficientQAコンペティションの上位エントリの アプローチを概観 3

オープンドメイン質問応答とは？ ● 任意のファクトイド型の質問に対して解答を与えるシステム ○ 理由や定義を問うようなノンファクトイド型の質問は一般に対象としない ● 知識ソース（Wikipedia等）を参照して解答を生成 ● BERT等の事前訓練モデルの台頭で実用的な性能で解けるようになった 4 質問応答システム 「吾輩は猫である」の 作者は誰？ 夏目漱石 知識ソース

NeurIPS EfficientQAコンペティション ● Google等に所属する研究者が開催したオープンドメイン質問応答の コンペティション ● Natural Questionsデータセットと同様の方法で収集された、新しい 質問応答データを使ってシステムを評価 ● システムの精度と計算効率の双方にフォーカス ● モデルやデータを全て含んだDockerイメージのサイズを制約 ● 4つのトラック ○ 無制限 ○ 6GB以内 ○ 500MB以内 ○ 25％以上の性能を出した最小のシステム 5

NeurIPS EfficientQAコンペティション ● Google等に所属する研究者が開催したオープンドメイン質問応答の コンペティション ● Natural Questionsデータセットと同様の方法で収集された、新しい 質問応答データを使ってシステムを評価 ● システムの精度と計算効率の双方にフォーカス ● モデルやデータを全て含んだDockerイメージのサイズを制約 ● 4つのトラック ○ 無制限 ○ 6GB以内 ○ 500MB以内 ○ 25％以上の性能を出した最小のシステム 6 本講演では無制限トラックと6GB制約トラックに ついて解説します

コンペティションの背景 ● 近年の質問応答システムでstate of the artスコアを出すには 大規模な計算資源が必要 ○ 例：Natural QuestionsデータセットでSOTAのFacebook AIのFusion-in-Decoderは 64枚のTesla V100 GPU 32GBで訓練されている ● 性能を上げるためには、大きいニューラルネットワークを大きい メモリを積んだ複数枚のGPUで分散訓練するのが有利 ● 研究予算の大きい大手企業が有利になりがち 7 システムの容量を制約して計算資源が少ないチームでも戦いやすくする

Natural Questionsデータセットの例 8 Googleで検索された質問とその解答で構成されるデータセット

Natural Questionsデータセットの例 Q: who is under the mask of darth vader A: Anakin Skywalker 9 Googleで検索された質問とその解答で構成されるデータセット

Natural Questionsデータセットの例 Q: who is under the mask of darth vader A: Anakin Skywalker Q: who has the most gold medals in the winter olympics of all time A: Norway 10 Googleで検索された質問とその解答で構成されるデータセット

Natural Questionsデータセットの例 Q: who is under the mask of darth vader A: Anakin Skywalker Q: who has the most gold medals in the winter olympics of all time A: Norway Q: how many episodes are there in dragon ball z A: 291 11 Googleで検索された質問とその解答で構成されるデータセット

Natural Questionsデータセットの例 Q: who is under the mask of darth vader A: Anakin Skywalker Q: who has the most gold medals in the winter olympics of all time A: Norway Q: how many episodes are there in dragon ball z A: 291 Q: who has the most followers in the world on instagram A: Instagram 12 Googleで検索された質問とその解答で構成されるデータセット

Natural Questionsデータセットの例 Q: who is under the mask of darth vader A: Anakin Skywalker Q: who has the most gold medals in the winter olympics of all time A: Norway Q: how many episodes are there in dragon ball z A: 291 Q: who has the most followers in the world on instagram A: Instagram Q: ok google who was the second president of the united states A: John Adams 13 Googleで検索された質問とその解答で構成されるデータセット

14 Studio Ousiaと東北大学の合同チームで出場

15 2位 6GB制約トラック

順位 名前 スコア 1 Microsoft Research 54.00 2 Facebook AI 53.89 3 Studio Ousia & Tohoku Univ. 52.78 4 Brno Univ. of Technology 50.33 5 Huawei Noah’s Ark Lab 48.06 6 Salesforce 46.83 16 3位 無制約トラック

17 無制約トラックの首位はMicrosoft Research、 他の全てのトラックはFacebook AIという結果に... 制約トラックでもFAIRは強かった...

宣伝：高精度な汎用質問応答エンジン「Soseki」 ● 独自に開発した大規模質問応答データで訓練したモデル ● 学習データの作成が不要（訓練済みモデルを提供） ● 回答となるデータ（FAQ、マニュアル、社内文書）があれば、 すぐにシステムをローンチできる ● NeurIPS EfficientQAで使用したモデルを拡張して使用 ● 主な用途： ○ サポートデスクの自動化・効率化 ○ 質問応答チャットボット ○ 社内検索エンジン ● 提供形態： ○ クラウドサービス ○ オンプレミス環境（システムインテグレータと連携して提供） 18 Soseki: 深層学習を用いた学習データ不要の高精度な質問応答エンジン https:/ /soseki.ai

EfficientQAで使った質問応答システムをオンラインで試せるよ！ 
 19 https://demo.soseki.ai デモ: Soseki as a Trivia Master

20 オープンドメイン質問応答の技術

Retriever-Readerアプローチ ● Retrieverが知識ソースから少量の候補パッセージを選択し、Readerが 候補パッセージを詳しく読んで解答 ● Retrieverは大量のパッセージから高速に候補パッセージを探す軽いモデル ● Readerはパッセージを詳しく読む重たいモデル ● EfficientQAでも無制限及び6GB制約トラックの全上位エントリが採用 21 Retriever Reader 我が輩は猫である を書いた作家は？ 夏目漱石 上位k件の該当性の 高いパッセージ 知識ソース (Wikipedia等) 近年のオープンドメイン質問応答システムはほとんど Retriever-Readerアプローチを採用

Retriever 22

Retrieverのベースライン: TF-IDF, BM25 ● WikipediaのパッセージをBM25でランキングした場合、上位20件の パッセージに解答の文字列が含まれている確率 (Karpukhin et al. 2020) 23 質問を検索クエリとして伝統的な（スパースな）検索（例：BM25）を使う Natural Questions 59.1% TriviaQA 66.9% Retrievalの段階で6割では性能的に厳しそう...

24 ニューラルネットを使ってRetrieverの性能を 改善したい...!

Dense Passage Retriever (DPR): 概要 25 ● 質問エンコーダとパッセージエンコーダの2つのBERTを 使って質問とパッセージをベクトル表現にする ○ BERTの[CLS]トークンの出力表現を用いる ● 質問とパッセージの”近さ”をそれぞれのベクトル表現の 内積で表現 質問 エンコーダ パッセージ エンコーダ 質問 パッセージ スコア 内積 BERTを用いたよく使われている単純なRetriever q: 質問 p: パッセージ E Q (･): 質問BERTエンコーダ E P (･): パッセージBERTエンコーダ Karpukhin et al. 2020 Dense Passage Retrieval for Open-Domain Question Answering. EMNLP.

DPR: 訓練 ● ある質問に対して、解答文字列を含んだパッセージを正例、含んでいない パッセージを負例とする ● 難しい負例（hard negatives）の作成：質問をクエリとしてBM25を使って パッセージを検索し、上位のパッセージで解答文字列を含まないものを負例とする ● 質問とパッセージの内積を使ったクロスエントロピー損失を用いて訓練 ● その他の工夫： ○ 解答位置のアノテーションを含むデータセットにおいては、アノテーション されたパッセージを正例とする ○ 複数のデータセットを連結して訓練データを増やす 26 q: 質問 p+: 正例パッセージ p-: 負例パッセージ

DPR: in-batch negatives ● in-batch negatives: ある質問qと同じミニバッチに含まれる全ての他の質問に 対応する正例および負例パッセージをqの負例として扱うことで計算量を削減 ● マルチGPUではNCCL等を使ってパッセージ表現をGPU間で転送しながら訓練 ● 負例数を大きくすることが性能向上につながると報告されている 27 Qu et al. RocketQA: An Optimized Training Approach to Dense Passage Retrieval for Open-Domain Question Answering より引用

DPR: 推論 ● 知識ソースに含まれる全てのパッセージを予めベクトルに変換し、パッセージの ベクトルインデックスを作成する ○ インデックスはパッセージ数×ベクトルの次元数の行列 ● 質問のベクトルをクエリとした近傍探索として解く ○ 高速に動作する実装がある（Faiss, ScaNN等） ○ HNSW等の近似近傍探索を適用することで推論速度を高速化できる ● 問題：インデックスは全て物理メモリ上に載せる必要があるが、サイズが非常に大きい ○ DPRの英語Wikipedia全体のインデックスは60GB超 ○ HNSWインデックスは140GB超 28 DPRはHugging Faceのtransformersライブラリに
 実装されているので気軽に使えるよ！

DPR: 性能 ● 上位20件／100件のパッセージに正解の解答文字列が含まれているかで評価 ● BM25と比較して大幅な性能向上 ● 複数のデータセットを連結して訓練する（Multi）とさらに性能向上する場合がある 29

Generation-Augmented Retrieval (GAR): 概要 ● 質問のクエリ拡張を行うseq2seqモデルを用いて、質問を拡張してから スパースな検索（例：BM25）を適用する ● 質問を入力として、下記のテキストを生成するseq2seqモデルを学習 ○ 解答文字列 ○ 解答文字列を含む文 ○ 解答文字列を含むWikipediaページのタイトル ● 質問と生成した文字列を連結して検索クエリとして使う ● 事前訓練済みモデルにはBARTを使用 30 seq2seqモデルでクエリ拡張を行ってスパースな検索における性能を改善 普通の検索エンジン実装がそのまま使えるのはメリットが大きそう Mao et al. 2020 Generation-Augmented Retrieval for Open-domain Question Answering. ArXiv 2020.

GAR: 生成事例 31

GAR: 評価 ● GARによって作成されたクエリを用いるとBM25の性能が飛躍的に向上 ● GAR (sparse) とDPR (dense) の組み合わせ（GAR+DPR）で性能がさらに 向上 32

GAR: Ablation Study ● 解答文字列、解答文字列を含む文、 解答を含むWikipediaタイトルの全て のクエリ拡張が性能向上に寄与 33

Reader 34

抽出型Reader (DPR reader): 概要 ● Retrieverが出力した候補パッセージから、パッセージを 選択して、選択したパッセージから解答文字列を抽出 ● BERTなどの事前訓練済みモデルを使う ● 各パッセージは、質問と連結してモデルに入力される ● 下記の3つのヘッドを持つモデルを訓練 ○ トークンが解答の開始位置である確率（P start ）を出力するヘッド ○ トークンが解答の終了位置である確率（P end ）を出力するヘッド ○ パッセージが正例である確率（P selected ）を出力するヘッド ● P selected でパッセージを選択しP start , P end で解答スパンを検出 35 [CLS] P CLS P 1 P N P SEP P 1’ P M’ P SEP Tok 1 Tok N [SEP] Tok 1’ Tok M’ [SEP] Transformer ... ... 質問 パッセージ 開始位置＆終了位置 パッセージのスコア オープンドメイン質問応答で標準的に使われている抽出型 Reader P i : i番目のトークンの Transformerの出力ベクトル (全てのパッセージの [CLS]出力ベクトルを連結) Karpukhin et al. 2020 Dense Passage Retrieval for Open-Domain Question Answering. EMNLP.

抽出型Reader (DPR reader): 性能 ● DPRとBERT-baseベースの抽出型Readerを組み合わせる ● 2020年前半頃まで（？）のstate of the art 36 DPR readerのBERT-baseをELECTRA-largeに差し替えると、Natural Questionsで50%前後までは出せるよ

生成型Reader (T5+SSM): 概要 37 知識ソースを使わずに大規模言語モデルから解答を生成 ● T5（言語生成可能な大規模訓練済み言語モデル）に質問を読ませて解答を生成 ○ モデルのパラメータ数を増やせば、多くの情報を覚え込ませられるので、知識ソースを 参照しなくても質問に解答できる ● Salient span masking: Wikipediaにある固有表現及び日付をマスクして、モデルが正しく 穴埋めするように追加で事前訓練を行う ● Closed book質問応答: 知識ソースを使わない（Retriever-Readerアプローチではない） Roberts et al. 2020 How Much Knowledge Can You Pack Into the Parameters of a Language Model? EMNLP.

生成型Reader (T5+SSM): 性能 38 ● DPR reader (Karpukhin et al. 2020) よりは 劣るが比較的良い性能で質問応答を解ける ● モデルのサイズを大きくすると性能が あがっていく ● Salient span masking (SSM) による事前訓練を 追加するとさらに性能が上がる

生成型Reader (Fusion-in-Decoder): 概要 39 パッセージを読み込んで解答を生成するencoder-decoder方式の生成型 Reader ● Retrieverが取得した候補パッセージを読み込むエンコーダと、解答文字列を生成する デコーダで構成される ● パッセージから解答を抽出するのではなく、パッセージを入力として解答を生成する ● エンコーダは質問と各パッセージを連結したテキストを入力として取り、パッセージの 表現を出力 ● デコーダは、エンコーダの出力した表現を連結したものを入力として取り、解答を生成 ● 事前訓練済みモデルとしてT5-base, T5-largeを採用

生成型Reader (Fusion-in-Decoder): 性能 40 ● DPRをretrieverとして用いて、Natural Questions、TriviaQAデータセットでSOTA ● 64枚のNVIDIA Tesla V100 32GBを用いて訓練 ● 「パッセージに含まれている情報」と「モデルのパラメータに含まれている情報」の 双方を参考にして解答を生成できる ○ 抽出型質問応答とclosed book質問応答の「良いとこ取り」ができる

生成型Readerは抽出型Readerより優れているか？ 41 ● モデルのパラメータを増やせば性能が上がることを仮定すると一概に生成型の方が 性能が良いとはいえない ● 抽出型と生成型は得意な質問が異なると考えると、アンサンブルすると有利 モデル タイプ ベースモデル パラメータ数 NQでの精度 TQAでの精度 DPR 抽出型 BERT-base 110M 41.5% 56.8% Fusion-in-Decoder 生成型 T5-base 220M 48.2% 65.0% DPR (ours) 抽出型 ELECTRA-large 335M 50%前後 65.6% Fusion-in-Decoder 生成型 T5-large 770M 51.4% 67.6%

EfficientQA上位エントリのアプローチ 42

EfficientQA上位エントリのアプローチ (無制約トラック, 6GB制約トラック) 43 ● 無制約トラックおよび6GB制約トラックの上位は全てRetriever-Readerアプローチを採用 ● 上位エントリについては自動評価と手動評価が行われた ○ 自動評価：Natural Questionsデータセットの解答文字列とのexact matchで評価 ○ 手動評価：解答を人手で評価（一致しないが解答として正しいものも含めた評価） モデル トラック 順位 Retriever Reader 知識ソース 自動評価 手動評価 Microsoft UnitedQA 無制約 1位 DPR FiD + 抽出型 (ELECTRA) Wikipediaテキスト 54.00% 65.80% Facebook Hybrid 無制約 2位 DPR+GAR FiD Wikipediaテキスト、リ スト、テーブル 53.89% 67.38% Facebook System 6GB 1位 DPR+GAR FiD Wikipediaテキスト、リ スト 53.33% 65.18% Ousia-Tohoku Soseki 6GB 2位 DPR 抽出型 (ELECTRA) Wikipediaテキスト 50.17% 62.01%

EfficientQA上位エントリのアプローチ (無制約トラック, 6GB制約トラック) 44 モデル トラック 順位 Retriever Reader 知識ソース 自動評価 手動評価 Microsoft UnitedQA 無制約 1位 DPR FiD + 抽出型 (ELECTRA) Wikipediaテキスト 54.00% 65.80% Facebook Hybrid 無制約 2位 DPR+GAR FiD Wikipediaテキスト、リ スト、テーブル 53.89% 67.38% Facebook System 6GB 1位 DPR+GAR FiD Wikipediaテキスト、リ スト 53.33% 65.18% Ousia-Tohoku Soseki 6GB 2位 DPR 抽出型 (ELECTRA) Wikipediaテキスト 50.17% 62.01% Facebook AIはトラック毎に異なるチームで複数のシステムを投稿

EfficientQA上位エントリのアプローチ (無制約トラック, 6GB制約トラック) 45 モデル トラック 順位 Retriever Reader 知識ソース 自動評価 手動評価 Microsoft UnitedQA 無制約 1位 DPR FiD + 抽出型 (ELECTRA) Wikipediaテキスト 54.00% 65.80% Facebook Hybrid 無制約 2位 DPR+GAR FiD Wikipediaテキスト、リ スト、テーブル 53.89% 67.38% Facebook System 6GB 1位 DPR+GAR FiD Wikipediaテキスト、リ スト 53.33% 65.18% Ousia-Tohoku Soseki 6GB 2位 DPR 抽出型 (ELECTRA) Wikipediaテキスト 50.17% 62.01% Retrieverは、Microsoftと我々のシステムは DPRを使用。Facebookは双方の システムでDPRとGARをアンサンブルして性能を向上した

EfficientQA上位エントリのアプローチ (無制約トラック, 6GB制約トラック) 46 我々もFiDを実装したものの、論文のスコアを
 再現できずお蔵入りに... モデル トラック 順位 Retriever Reader 知識ソース 自動評価 手動評価 Microsoft UnitedQA 無制約 1位 DPR FiD + 抽出型 (ELECTRA) Wikipediaテキスト 54.00% 65.80% Facebook Hybrid 無制約 2位 DPR+GAR FiD Wikipediaテキスト、リ スト、テーブル 53.89% 67.38% Facebook System 6GB 1位 DPR+GAR FiD Wikipediaテキスト、リ スト 53.33% 65.18% Ousia-Tohoku Soseki 6GB 2位 DPR 抽出型 (ELECTRA) Wikipediaテキスト 50.17% 62.01% ReaderはFacebookはFusion-in-Decoder (FiD)、我々は抽出型モデルを使用。 Microsoftは双方をアンサンブルして性能を向上。

EfficientQA上位エントリのアプローチ (無制約トラック, 6GB制約トラック) 47 モデル トラック 順位 Retriever Reader 知識ソース 自動評価 手動評価 Microsoft UnitedQA 無制約 1位 DPR FiD + 抽出型 (ELECTRA) Wikipediaテキスト 54.00% 65.80% Facebook Hybrid 無制約 2位 DPR+GAR FiD Wikipediaテキスト、リ スト、テーブル 53.89% 67.38% Facebook System 6GB 1位 DPR+GAR FiD Wikipediaテキスト、リ スト 53.33% 65.18% Ousia-Tohoku Soseki 6GB 2位 DPR 抽出型 (ELECTRA) Wikipediaテキスト 50.17% 62.01% Facebookは、知識ソースとして、テキストに加えてリストやテーブルを 追加して性能を向上

EfficientQA上位エントリのアプローチ (無制約トラック, 6GB制約トラック) 48 モデル トラック 順位 Retriever Reader 知識ソース 自動評価 手動評価 Microsoft UnitedQA 無制約 1位 DPR FiD + 抽出型 (ELECTRA) Wikipediaテキスト 54.00% 65.80% Facebook Hybrid 無制約 2位 DPR+GAR FiD Wikipediaテキスト、リ スト、テーブル 53.89% 67.38% Facebook System 6GB 1位 DPR+GAR FiD Wikipediaテキスト、リ スト 53.33% 65.18% Ousia-Tohoku Soseki 6GB 2位 DPR 抽出型 (ELECTRA) Wikipediaテキスト 50.17% 62.01% 自動評価では無制約トラックの順位が逆転し、 Facebookが1位に。 評価に使われる解答文字列はWikipediaから抜き出されているので、解答を パッセージから抽出する方が性能が高くなりやすいのかも...?

EfficientQA上位エントリの正解率改善 テクニック 49

性能改善: DPRのマルチステップ訓練 ● BM25よりも難しい負例を作成するため、下記の ステップを繰り返す ○ モデルを訓練（最初の訓練ではBM25で負例を作成する） ○ 訓練したモデルを質問をクエリとして検索し、解答文字列を 含まない上位パッセージを負例としてデータセットを作成 ● Facebook Hybridシステムが採用し、検証セットの exact match正解率で1.4%の性能向上 ● 2回から3回程度回すので十分 50 BM25よりも”難しい”負例を作るためにマルチステップでDPRを訓練する DPR 難しい負例

性能改善: 知識ソースにテーブルとリストを加える ● Wikipediaのテキストに加えて、テーブルとリストを加えることでDPRを拡張する ● テーブルは、下記の要領で行単位でテキストに変換する ○ テーブルの空行でない最初の行（ヘッダ）と各行のセルの値を改行で連結して テキストに変換 ○ 入力長に余裕がある場合はテーブルの他の行をランダムに選択して加える ● テーブルとリストを知識ソースに加えることで、上位20件／100件の候補 パッセージに解答文字列が含まれている確率が大幅に向上 51 テーブルとリストを加えて知識ソースを拡張する Oguz et al. 2020 Unified Open-Domain Question Answering with Structured and Unstructured Knowledge. ArXiv.

EfficientQA上位エントリの容量削減 テクニック（6GB制約トラック） 52

オープンドメイン質問応答システムを6GBにおさめる ● システムの動作に必要なリソースを6GB以内におさめる必要がある ○ 知識ソース（Passage corpus） ○ 検索インデックス ○ モデルのパラメータ ○ OS、コード、依存ライブラリ ● 特に知識ソースとインデックスが容量が大きい ○ DPRが使用している英語Wikipediaのテキストデータは約16GB ○ DPRのパッセージインデックスは60GB超(!) 53 Min et al. 2020 NeurIPS 2020 EfficientQA Competition: Systems, Analyses and Lessons Learned. ArXiv. 6GB制約トラックにおける上位エントリのストレージの使い方

DPRインデックスの容量削減 ● Facebook System: ○ DPRの出力に全結合層を追加し、768次元から256次元までベクトル表現の次元を削減 ○ インデックスに対してFaissの直積量子化（product quantization）を後処理で適用 ○ インデックスの容量を1.6GB程度まで削減 ● Ousia-Tohoku Soseki: ○ Learning to hashを適用し、パッセージのベクトル表現を訓練時にバイナリ化 ○ ベクトルの各次元が1bitで表現され、インデックスの容量を2GB程度まで削減 54 Izacard et al. 2020 A Memory Efficient Baseline for Open Domain Question Answering. ArXiv.

パッセージ等の容量削減 ● 解答が含まれていなさそうなパッセージを除外する ○ Facebook System: Wikipediaの記事タイトルとカテゴリを特徴とする 線形分類器を訓練 ○ Ousia-tohoku Soseki: ページビュー数が少ないWikipediaページを除外 （訓練無し） ■ ページビューを使うと性能低下無しで3割程度のパッセージを除外できる！ ● 圧縮する！ ○ Facebook System: lrzipでパッセージを圧縮 ○ Ousia-tohoku Soseki: ZPAQでモデル、パッセージ、インデックス、 /usr/local/libの全ファイルを圧縮 55

さいごに ● NeurIPS EfficientQAコンペティションの上位エントリを題材として、 オープンドメイン質問応答の技術を概観 ● 計算効率や多言語への対応、他ドメインへの適用などがこれからの課題 56 [email protected] @ikuyamada 質問やコメント等は下記の連絡先までご連絡ください！