最先端の質問応答技術の研究開発と迅速な実用化ーStudio Ousiaでの取り組みー

Slide 1

Slide 1 text

山田育矢 (Ikuya Yamada) Studio Ousia 最先端の質問応答技術の研究開発と迅速な実用化ーStudio Ousiaでの取り組みー

Slide 2

Slide 2 text

自己紹介山田育矢 (@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

Slide 3

Slide 3 text

本日の講演の流れ質問応答の研究開発から製品化に至るまでの Studio Ousiaでの取り組みを紹介します ● オープンドメイン質問応答の研究開発 ● 質問応答の実用化：アンサーロボ ● スタートアップでの研究開発のおはなし 3

Slide 4

Slide 4 text

これまでの質問応答への取り組み (2017-2020) 4

Slide 5

Slide 5 text

早押しクイズコンペティション @ NIPS 2017 5 ● 開発した単語とエンティティのベクトル表現（Wikipedia2Vec）を使った質問応答システムを実装 ● クイズで使ったモデル構造と Wikipedia2Vecは、CoNLL 2019、 EMNLP 2020 (demo)でそれぞれ発表 NIPS2017で行われた早押しクイズのコンペティションに参加 (NIPS 2017 Human-Computer Question Answering Competition)

Slide 6

Slide 6 text

早押しクイズコンペティション @ NIPS 2017 6 ● 開発した単語とエンティティのベクトル表現（Wikipedia2Vec）を使った質問応答システムを実装 ● クイズで使ったモデル構造と Wikipedia2Vecは、CoNLL 2019、 EMNLP 2020 (demo)でそれぞれ発表クイズ文中の単語とエンティティを入力する（エンティティリンキングでエンティティを抽出） NIPS2017で行われた早押しクイズのコンペティションに参加 (NIPS 2017 Human-Computer Question Answering Competition) 回答するエンティティを候補から選ぶ（Wikipediaから回答エンティティを選ぶ超多クラス分類）

Slide 7

Slide 7 text

早押しクイズコンペティション @ NIPS 2017 7 NIPS 2017で行われたクイズ対戦で、全米クイズ王チームに勝利！ ● コンペティションに投稿されたシステムで最も良いスコアを獲得 ● 「ジェパディ！」の優勝者を含む全米クイズ王チーム6人と対戦し、 465 対 200 の大差で勝利！ https://www.itmedia.co.jp/news/articles/1802/28/news037.html

Slide 8

Slide 8 text

抽出型質問応答（SQuAD v1.1） ● 訓練済言語モデル（RoBERTa）をベースに、Wikipediaを用いた追加の事前訓練を行ってエンティティエンべディングを学習 ● 単語に加えてパッセージ中のエンティティを入力することで、タスクに有用な情報を増やして性能を改善 8 知識拡張型言語モデルLUKEで抽出型質問応答（SQuAD v1.1）でSOTAを獲得

Slide 9

Slide 9 text

抽出型質問応答（SQuAD v1.1） 9 SQuAD v1.1での評価結果リーダーボードで一位を獲得

Slide 10

Slide 10 text

オープンドメイン質問応答への取り組み (2020-) 10

Slide 11

Slide 11 text

オープンドメイン質問応答とは？ ● 知識ソース（Wikipedia等）を参照して解答を生成 ● BERT等の事前訓練モデルの台頭で実用的な性能で解けるようになった 11 質問応答システム「吾輩は猫である」の作者は誰？夏目漱石知識ソース

Slide 12

Slide 12 text

NeurIPS EﬃcientQAコンペティション ● Google等に所属する研究者が開催 ● システムの精度と計算効率の双方にフォーカス ● モデルやデータを全て含んだDockerイメージのサイズを制約 ● 4つのトラックのうち、無制限トラックと6GB以内トラックに参加 ○ 無制限 ○ 6GB以内 ○ 500MB以内 ○ 25％以上の性能を出した最小のシステム 12 NeurIPS 2020で行われたオープンドメイン質問応答のコンペティションに参加

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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 14 Googleで検索された質問とその解答で構成されるデータセット

Slide 15

Slide 15 text

15 東北大学との合同チームで出場

Slide 16

Slide 16 text

16 2位 6GB制約トラック

Slide 17

Slide 17 text

順位名前スコア 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 17 3位無制約トラック

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Retriever-readerアプローチ ● Retriever: 大量のパッセージから高速に候補パッセージを探す軽いモデル ● Reader: パッセージを詳しく読む重たいモデル 19 Retriever Reader 我が輩は猫であるを書いた作家は？夏目漱石上位k件の該当性の高いパッセージ知識ソース (Wikipedia等) Retrieverが知識ソースから少量の候補パッセージを選択し、 Readerが候補パッセージを詳しく読んで解答

Slide 20

Slide 20 text

20 ReaderではなくRetrieverに注力する理由： 1. Readerの訓練には解答文字列のデータが必要 ○ 実世界の問題ではアノテーションのコストが高く入手が困難なことが多い ○ ファクトイド型の質問しかうまく扱えない 2. “超”大規模言語モデル（ChatGPT等）との組み合わせの相性が良い（retrieval-augmented LM）ニューラルネットを用いたRetrieverに重点を置いて開発しています技術開発の方針

Slide 21

Slide 21 text

Retrieverに関連する主な研究テーマ ● 軽量化 ○ 推論の軽量化 ○ 訓練の軽量化 ● 精度向上 ○ 性能の良いモデルの開発 ○ 大きなモデルからの蒸留 21 ● ドメイン外への転移性能の向上 ○ プロンプト・チューニング ○ 転移に強いモデルの開発 ● 遠距離学習 ○ 訓練データのウェブからの獲得（日本語、多言語） ○ 擬似クエリ・パッセージ生成様々な手法を気軽に試してうまくいった方法を論文化しています

Slide 22

Slide 22 text

Retrieverに関連する主な研究テーマ ● 軽量化 ○ 推論の軽量化 ○ 訓練の軽量化 ● 精度向上 ○ 性能の良いモデルの開発 ○ 大きなモデルからの蒸留 22 ● ドメイン外への転移性能の向上 ○ プロンプト・チューニング ○ 転移に強いモデルの開発 ● 遠距離学習 ○ 訓練データのウェブからの獲得（日本語、多言語） ○ 擬似クエリ・パッセージ生成様々な手法を気軽に試してうまくいった方法を論文化しています本講演では、研究の取り組みの例として、推論の軽量化に関する研究を紹介します

Slide 23

Slide 23 text

23 ハッシングによる Dense Passage Retrieverの軽量化

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

DPR: 推論の仕組み ● 知識ソースに含まれる全てのパッセージを予めベクトルに変換し、パッセージのベクトルインデクスを作成するインデクス：[パッセージ数×ベクトルの次元] の巨大な行列 ● 質問のベクトルをクエリとした近傍探索として解く ○ 高速に動作する実装がある（Faiss, ScaNN等） ○ HNSW等の近似近傍探索を適用することで推論速度を高速化できる 25

Slide 26

Slide 26 text

DPR: メモリコストの問題 26 各パッセージベクトルのサイズ: 4 バイト * 768 次元 ≒ 3072 バイト (ﬂoat32) (BERT出力次元) 3072 バイト * 21,000,000 ≒ 65GB 英語Wikipediaパッセージ（21M）のインデクスに必要なサイズ：インデクスは基本的に物理メモリに置く必要がある

Slide 27

Slide 27 text

27 インデクスを小さくして普通のマシンでも動くようにしたい...

Slide 28

Slide 28 text

Binary Passage Retriever (BPR) ● 実数ベクトルからバイナリベクトルに変換を行うハッシュ関数をエンドツーエンドで学習 (learning-to-hash) ● 候補生成とリランキングの二つのステージでタスクを解く 28 ハッシングという技法を使ってDPRを拡張しパッセージを実数ではなくバイナリのベクトルとして表現する EﬃcientQAのシステムで使用した後にACL 2021で発表（ワシントン大学の浅井明里さんとHannaneh Hajishirzi先生との共同研究）

Slide 29

Slide 29 text

DPRとBPRの構造の違い 29 パッセージエンコーダ質問エンコーダパッセージ質問スコア内積 [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd DPR:

Slide 30

Slide 30 text

DPRとBPRの構造の違い 30 パッセージエンコーダ質問エンコーダパッセージ質問スコア内積 [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd パッセージエンコーダ質問エンコーダパッセージ質問リランキング内積 [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd ハッシュレイヤーハッシュレイヤー [1, -1, …, 1]∈{-1, 1}d [1, -1, …, 1]∈{-1,1}d ハミング距離候補生成 DPR: BPR:

Slide 31

Slide 31 text

DPRとBPRの構造の違い 31 パッセージエンコーダ質問エンコーダパッセージ質問スコア内積 [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd パッセージエンコーダ質問エンコーダパッセージ質問リランキング内積 [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd ハッシュレイヤーハッシュレイヤー [1, -1, …, 1]∈{-1, 1}d [1, -1, …, 1]∈{-1,1}d ハミング距離候補生成 DPR: BPR:

Slide 32

Slide 32 text

BPR: ハッシュレイヤー 32 パッセージエンコーダ質問エンコーダパッセージ質問リランキング内積 [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd ハッシュレイヤーハッシュレイヤー [1, -1, …, 1]∈{-1, 1}d [1, -1, …, 1]∈{-1,1}d ハミング距離候補生成エンコーダの上にハッシュレイヤーを追加エンコーダによって計算された実数ベクトルをバイナリベクトルに変換ハッシュレイヤーは符号関数を用いて実装

Slide 33

Slide 33 text

BPR: 符号関数をスケールされたtanh関数で近似 33 問題: 符号関数は不連続で誤差逆伝播と相性が悪い解決策: 訓練時に符号関数をスケールされた tanh関数で近似する (Cao et al. 2017) βを訓練ステップ毎に徐々に増やす green: sign(x) blue: tanh(βx) training step: 0 (β=1, γ=0.1)

Slide 34

Slide 34 text

BPR: 符号関数をスケールされたtanh関数で近似 34 問題: 符号関数は不連続で誤差逆伝播と相性が悪い解決策: 訓練時に符号関数をスケールされた tanh関数で近似する (Cao et al. 2017) βを訓練ステップ毎に徐々に増やす green: sign(x) blue: tanh(βx) training step: 240 (β=5, γ=0.1)

Slide 35

Slide 35 text

BPR: 符号関数をスケールされたtanh関数で近似 35 問題: 符号関数は不連続で誤差逆伝播と相性が悪い解決策: 訓練時に符号関数をスケールされた tanh関数で近似する (Cao et al. 2017) βを訓練ステップ毎に徐々に増やす green: sign(x) blue: tanh(βx) training step: 990 (β=10, γ=0.1)

Slide 36

Slide 36 text

BPR: 符号関数をスケールされたtanh関数で近似 36 問題: 符号関数は不連続で誤差逆伝播と相性が悪い解決策: 訓練時に符号関数をスケールされた tanh関数で近似する (Cao et al. 2017) βを訓練ステップ毎に徐々に増やす green: sign(x) blue: tanh(βx) training step: 8990 (β=30, γ=0.1)

Slide 37

Slide 37 text

BPR: 候補生成とリランキングの二段階アプローチ 37 パッセージエンコーダ質問エンコーダパッセージ質問リランキング内積 [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd ハッシュレイヤーハッシュレイヤー [1, -1, …, 1]∈{-1, 1}d [1, -1, …, 1]∈{-1,1}d ハミング距離候補生成候補生成: ● 少数のパッセージ候補を計算効率の高いハミング距離を使って取得する ○ 質問: バイナリベクトル ○ パッセージ: バイナリベクトル

Slide 38

Slide 38 text

BPR: 候補生成とリランキングの二段階アプローチ 38 パッセージエンコーダ質問エンコーダパッセージ質問リランキング内積 [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd ハッシュレイヤーハッシュレイヤー [1, -1, …, 1]∈{-1, 1}d [1, -1, …, 1]∈{-1,1}d ハミング距離候補生成候補生成: ● 少数のパッセージ候補を計算効率の高いハミング距離を使って取得する ○ 質問: バイナリベクトル ○ パッセージ: バイナリベクトルリランキング: ● パッセージ候補を表現力の高い内積を用いてリランキングする ○ 質問: 実数ベクトル ○ パッセージ: バイナリベクトル表現力が高い

Slide 39

Slide 39 text

BPR: マルチタスク訓練候補生成用のランキング損失関数: リランキング用の交差エントロピー損失関数: 最終的な損失関数: 39 二つの異なる損失関数を使ったマルチタスク訓練

Slide 40

Slide 40 text

BPR: DPRとの比較 40 ● 評価するパッセージ数kが20個以上での再現率でDPRと同様かDPR以上の性能 ● DPRの計算量を飛躍的に削減 → インデクスサイズ: 65GB -> 2GB → クエリ時間: 457ms -> 38ms Natural Questionsでの top-kでの再現率 TriviaQAでの top-kでの再現率質問応答においては通常は20個以上のパッセージを読み込むので、20個以下の性能は重要でない

Slide 41

Slide 41 text

BPR: エンドツーエンドの質問応答性能 41 モデル NQ TQA BPR+抽出型リーダ 41.6 56.8 DPR+抽出型リーダ 41.5 56.8 ● DPRと同様の性能を飛躍的に小さい計算効率で実現 Natural QuestionsとTriviaQAでの正解率（exact match）同じBERTをベースにした抽出型リーダを使用

Slide 42

Slide 42 text

EﬃcientQA 6GB制約トラック 42 モデルトラック順位リトリーバリーダ知識ソース自動評価手動評価 Facebook System 6GB 1位 DPR+GAR Fusion-in- Decoder Wikipediaテキスト、リスト 53.33% 65.18% Ousia-Tohoku Soseki 6GB 2位 BPR 抽出型 (ELECTRA) Wikipediaテキスト 50.17% 62.01% BPRと抽出型リーダを組み合わせてEﬃcientQAに投稿し 6GB制約トラックでFacebookAIについで二位 ● Facebook AIも独自のリトリーバの軽量化（post-hocな量子化、次元削減）を実施 ● Facebook AIとの性能差の要因 ○ リーダの性能差（生成型（Fusion-in-decoder） v.s. 抽出型） ○ 知識ソースの差（Wikipediaのリスト） ○ リトリーバの拡張（GAR）

Slide 43

Slide 43 text

EﬃcientQA 6GB制約トラック 43 モデルトラック順位リトリーバリーダ知識ソース自動評価手動評価 Facebook System 6GB 1位 DPR+GAR Fusion-in- Decoder Wikipediaテキスト、リスト 53.33% 65.18% Ousia-Tohoku Soseki 6GB 2位 BPR 抽出型 (ELECTRA) Wikipediaテキスト 50.17% 62.01% BPRと抽出型リーダを組み合わせてEﬃcientQAに投稿し 6GB制約トラックでFacebookAIについで二位 ● Facebook AIも独自のリトリーバの軽量化（post-hocな量子化、次元削減）を実施 ● Facebook AIとの性能差の要因 ○ リーダの性能差（生成型（Fusion-in-decoder） v.s. 抽出型） ○ 知識ソースの差（Wikipediaのリスト） ○ リトリーバの拡張（GAR）我々もFusion-in-Decoderを実装したものの、当時は性能を再現できず

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

BPR: ベクトル検索のオープンソース実装で採用 45 WeaviateがBPRを公式にサポート vespa.ai (Yahoo検索のOSS) が BPRを使った大規模検索を紹介

Slide 46

Slide 46 text

実用化：アンサーロボ 46

Slide 47

Slide 47 text

アンサーロボ 47 ● 独自に大規模な日本語／多言語での質問応答データセットを収集しリトリーバを訓練 ● zero-shotで企業の実データにおいて高い性能を発揮 ● クラウド（AWS）上でのSaaSとして展開 zero-shot型の企業向け質問応答システム https://answerrobot.ai

Slide 48

Slide 48 text

Slide 49

Slide 49 text

スタートアップでの研究開発 49

Slide 50

Slide 50 text

研究をする上で気をつけていること 50 ● 実世界での実用的なニーズを満たすテーマを選ぶ ○ 論文でのみ通用する問題設定を避ける ○ 実用化から遠い基礎的な内容を避ける

Slide 51

Slide 51 text

研究をする上で気をつけていること 51 ● 実世界での実用的なニーズを満たすテーマを選ぶ ○ 論文でのみ通用する問題設定を避ける ○ 実用化から遠い基礎的な内容を避ける ● 論文にも製品にもならない中途半端な状態に陥らないようにする ○ 研究の各段階で目的意識を明確にして無理に続けずに早期に撤退する ○ なるべくインパクトのある論文として対外的に発表できるように努力する

Slide 52

Slide 52 text

研究をする上で気をつけていること 52 ● 実世界での実用的なニーズを満たすテーマを選ぶ ○ 論文でのみ通用する問題設定を避ける ○ 実用化から遠い基礎的な内容を避ける ● 論文にも製品にもならない中途半端な状態に陥らないようにする ○ 研究の各段階で目的意識を明確にして無理に続けずに早期に撤退する ○ なるべくインパクトのある論文として対外的に発表できるように努力する ● 良い性能を出すことにこだわる ○ 性能は実用上のメリットと論文の説得力を両立する近道 ○ ベンチマークでの性能に関するインサイトはビジネスでも有用であることが多い

Slide 53

Slide 53 text

研究をする上で気をつけていること 53 ● 実世界での実用的なニーズを満たすテーマを選ぶ ○ 論文でのみ通用する問題設定を避ける ○ 実用化から遠い基礎的な内容を避ける ● 論文にも製品にもならない中途半端な状態に陥らないようにする ○ 研究の各段階で目的意識を明確にして無理に続けずに早期に撤退する ○ なるべくインパクトのある論文として対外的に発表できるように努力する ● 良い性能を出すことにこだわる ○ 性能は実用上のメリットと論文の説得力を両立する近道 ○ ベンチマークでの性能に関するインサイトはビジネスでも有用であることが多い ● 研究用のコードと割り切らない ○ 研究フェーズでなるべく綺麗なコードを書いておく ○ そのまま拡張していけば製品に使える状態になるように努力する

Slide 54

Slide 54 text

GPU計算資源の安価な確保開発用GPUマシンを組み立て ● パーツをeBayやAmazon等で安価に調達 ● 外排気型GPU 4枚構成のLambda Deep Learning DevBoxを Corsair Air 540 + pcpartpicker.comのパーツリストから自前で再現 ● RTX 3090 4枚構成のマシン（1500W以上の電力を消費）を PC電源を2台載せられるPCケース（Lian Li O11 Dynamic）を使って作成安価なGPUクラウドの活用 ● Vast.ai ● Lambda Cloud 54 自作GPUワークステーションとGPUクラウドを効果的に利用 Lian Li O11 Dynamic Corsair Air 540

Slide 55

Slide 55 text

55 [email protected] @ikuyamada 質問やコメント等は下記の連絡先までご連絡ください！ありがとうございました！