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

情報処理学会第255回自然言語処理研究会 での招待講演資料です。

1. 山田 育矢 (Ikuya Yamada) Studio Ousia 最先端の質問応答技術の研究開発と迅速な実用化 ーStudio Ousiaでの取り組みー
2. 自己紹介 山田 育矢 (@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
3. 本日の講演の流れ 質問応答の研究開発から製品化に至るまでの Studio Ousiaでの取り組みを紹介します • オープンドメイン質問応答の研究開発 • 質問応答の実用化：アンサーロボ • スタートアップでの研究開発のおはなし 3
4. これまでの質問応答への取り組み (2017-2020) 4
5. 早押しクイズコンペティション @ NIPS 2017 5 • 開発した単語とエンティティの ベクトル表現（Wikipedia2Vec）を 使った質問応答システムを実装 • クイズで使ったモデル構造と Wikipedia2Vecは、CoNLL 2019、 EMNLP 2020 (demo)でそれぞれ発表 NIPS2017で行われた早押しクイズのコンペティションに参加 (NIPS 2017 Human-Computer Question Answering Competition)
6. 早押しクイズコンペティション @ NIPS 2017 6 • 開発した単語とエンティティの ベクトル表現（Wikipedia2Vec）を 使った質問応答システムを実装 • クイズで使ったモデル構造と Wikipedia2Vecは、CoNLL 2019、 EMNLP 2020 (demo)でそれぞれ発表 クイズ文中の単語とエンティティを入力する （エンティティリンキングでエンティティを抽出） NIPS2017で行われた早押しクイズのコンペティションに参加 (NIPS 2017 Human-Computer Question Answering Competition) 回答するエンティティを候補から選ぶ （Wikipediaから回答エンティティを選ぶ超多クラス分類）
7. 早押しクイズコンペティション @ NIPS 2017 7 NIPS 2017で行われたクイズ対戦で、 全米クイズ王チームに勝利！ • コンペティションに投稿されたシステムで 最も良いスコアを獲得 • 「ジェパディ！」の優勝者を含む 全米クイズ王チーム6人と対戦し、 465 対 200 の大差で勝利！ https://www.itmedia.co.jp/news/articles/1802/28/news037.html
8. 抽出型質問応答（SQuAD v1.1） • 訓練済言語モデル（RoBERTa）をベースに、Wikipediaを用いた追加の 事前訓練を行ってエンティティエンべディングを学習 • 単語に加えてパッセージ中のエンティティを入力することで、タスクに 有用な情報を増やして性能を改善 8 知識拡張型言語モデルLUKEで抽出型質問応答（SQuAD v1.1）でSOTAを獲得
9. 抽出型質問応答（SQuAD v1.1） 9 SQuAD v1.1での評価結果 リーダーボードで一位を獲得
10. オープンドメイン質問応答への取り組み (2020-) 10
11. オープンドメイン質問応答とは？ • 知識ソース（Wikipedia等）を参照して解答を生成 • BERT等の事前訓練モデルの台頭で実用的な性能で解けるようになった 11 質問応答システム 「吾輩は猫である」の 作者は誰？ 夏目漱石 知識ソース
12. NeurIPS EfficientQAコンペティション • Google等に所属する研究者が開催 • システムの精度と計算効率の双方にフォーカス • モデルやデータを全て含んだDockerイメージのサイズを制約 • 4つのトラックのうち、無制限トラックと6GB以内トラックに参加 ◦ 無制限 ◦ 6GB以内 ◦ 500MB以内 ◦ 25％以上の性能を出した最小のシステム 12 NeurIPS 2020で行われたオープンドメイン質問応答のコンペティションに参加
13. コンペティションの背景 • 近年の質問応答システムでstate of the artスコアを出すには 大規模な計算資源が必要 ◦ 例：Natural Questionsデータセットで当時のSOTAだったFusion-in-Decoderは 64枚のTesla V100 GPU 32GBで訓練されている • 性能を上げるためには、大きいニューラルネットワークを大きい メモリを積んだ複数枚のGPUで分散訓練するのが有利 • 研究予算の大きい大手企業が有利になりがち 13 システムの容量を制約して計算資源が少ないチームでも戦いやすくする
14. 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で検索された質問とその解答で構成されるデータセット
15. 15 東北大学との合同チームで出場
16. 16 2位 6GB制約トラック
17. 順位 名前 スコア 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位 無制約トラック
18. 18 オープンドメイン質問応答の技術
19. Retriever-readerアプローチ • Retriever: 大量のパッセージから高速に候補パッセージを探す軽いモデル • Reader: パッセージを詳しく読む重たいモデル 19 Retriever Reader 我が輩は猫である を書いた作家は？ 夏目漱石 上位k件の該当性の 高いパッセージ 知識ソース (Wikipedia等) Retrieverが知識ソースから少量の候補パッセージを選択し、 Readerが候補パッセージを詳しく読んで解答
20. 20 ReaderではなくRetrieverに注力する理由： 1. Readerの訓練には解答文字列のデータが必要 ◦ 実世界の問題ではアノテーションのコストが高く入手が困難なことが多い ◦ ファクトイド型の質問しかうまく扱えない 2. “超”大規模言語モデル（ChatGPT等）との組み合わせの相性が良い （retrieval-augmented LM） ニューラルネットを用いたRetrieverに重点を置いて開発しています 技術開発の方針
21. Retrieverに関連する主な研究テーマ • 軽量化 ◦ 推論の軽量化 ◦ 訓練の軽量化 • 精度向上 ◦ 性能の良いモデルの開発 ◦ 大きなモデルからの蒸留 21 • ドメイン外への転移性能の向上 ◦ プロンプト・チューニング ◦ 転移に強いモデルの開発 • 遠距離学習 ◦ 訓練データのウェブからの獲得 （日本語、多言語） ◦ 擬似クエリ・パッセージ生成 様々な手法を気軽に試してうまくいった方法を論文化しています
22. Retrieverに関連する主な研究テーマ • 軽量化 ◦ 推論の軽量化 ◦ 訓練の軽量化 • 精度向上 ◦ 性能の良いモデルの開発 ◦ 大きなモデルからの蒸留 22 • ドメイン外への転移性能の向上 ◦ プロンプト・チューニング ◦ 転移に強いモデルの開発 • 遠距離学習 ◦ 訓練データのウェブからの獲得 （日本語、多言語） ◦ 擬似クエリ・パッセージ生成 様々な手法を気軽に試してうまくいった方法を論文化しています 本講演では、研究の取り組みの例として、推論の軽量化に関する研究を紹介します
23. 23 ハッシングによる Dense Passage Retrieverの軽量化
24. 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
25. DPR: 推論の仕組み • 知識ソースに含まれる全てのパッセージを予めベクトルに変換し、 パッセージのベクトルインデクスを作成する インデクス：[パッセージ数×ベクトルの次元] の巨大な行列 • 質問のベクトルをクエリとした近傍探索として解く ◦ 高速に動作する実装がある（Faiss, ScaNN等） ◦ HNSW等の近似近傍探索を適用することで推論速度を高速化できる 25
26. DPR: メモリコストの問題 26 各パッセージベクトルのサイズ: 4 バイト * 768 次元 ≒ 3072 バイト (float32) (BERT出力次元) 3072 バイト * 21,000,000 ≒ 65GB 英語Wikipediaパッセージ（21M）のインデクスに必要なサイズ： インデクスは基本的に物理メモリに置く必要がある
27. 27 インデクスを小さくして 普通のマシンでも動くようにしたい...
28. Binary Passage Retriever (BPR) • 実数ベクトルからバイナリベクトルに変換を行うハッシュ関数を エンドツーエンドで学習 (learning-to-hash) • 候補生成とリランキングの二つのステージでタスクを解く 28 ハッシングという技法を使ってDPRを拡張し パッセージを実数ではなくバイナリのベクトルとして表現する EfficientQAのシステムで使用した後にACL 2021で発表 （ワシントン大学の浅井明里さんとHannaneh Hajishirzi先生との共同研究）
29. DPRとBPRの構造の違い 29 パッセージ エンコーダ 質問 エンコーダ パッセージ 質問 スコア 内積 [1.1, -0.3, …, 0.1]∈ℝd [0.2, -0.7, …, 0.3]∈ℝd DPR:
30. 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:
31. 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:
32. 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 ハミング距離 候補生成 エンコーダの上にハッシュレイヤーを追加 エンコーダによって計算された実数ベクトルを バイナリベクトルに変換 ハッシュレイヤーは符号関数を用いて実装
33. BPR: 符号関数をスケールされたtanh関数で近似 33 問題: 符号関数は不連続で誤差逆伝播と 相性が悪い 解決策: 訓練時に符号関数をスケールされた tanh関数で近似する (Cao et al. 2017) βを訓練ステップ毎に徐々に増やす green: sign(x) blue: tanh(βx) training step: 0 (β=1, γ=0.1)
34. BPR: 符号関数をスケールされたtanh関数で近似 34 問題: 符号関数は不連続で誤差逆伝播と 相性が悪い 解決策: 訓練時に符号関数をスケールされた tanh関数で近似する (Cao et al. 2017) βを訓練ステップ毎に徐々に増やす green: sign(x) blue: tanh(βx) training step: 240 (β=5, γ=0.1)
35. BPR: 符号関数をスケールされたtanh関数で近似 35 問題: 符号関数は不連続で誤差逆伝播と 相性が悪い 解決策: 訓練時に符号関数をスケールされた tanh関数で近似する (Cao et al. 2017) βを訓練ステップ毎に徐々に増やす green: sign(x) blue: tanh(βx) training step: 990 (β=10, γ=0.1)
36. BPR: 符号関数をスケールされたtanh関数で近似 36 問題: 符号関数は不連続で誤差逆伝播と 相性が悪い 解決策: 訓練時に符号関数をスケールされた tanh関数で近似する (Cao et al. 2017) βを訓練ステップ毎に徐々に増やす green: sign(x) blue: tanh(βx) training step: 8990 (β=30, γ=0.1)
37. 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 ハミング距離 候補生成 候補生成: • 少数のパッセージ候補を計算効率の高い ハミング距離を使って取得する ◦ 質問: バイナリベクトル ◦ パッセージ: バイナリベクトル
38. 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 ハミング距離 候補生成 候補生成: • 少数のパッセージ候補を計算効率の高い ハミング距離を使って取得する ◦ 質問: バイナリベクトル ◦ パッセージ: バイナリベクトル リランキング: • パッセージ候補を表現力の高い内積を 用いてリランキングする ◦ 質問: 実数ベクトル ◦ パッセージ: バイナリベクトル 表現力が高い
39. BPR: マルチタスク訓練 候補生成用のランキング損失関数: リランキング用の交差エントロピー損失関数: 最終的な損失関数: 39 二つの異なる損失関数を使ったマルチタスク訓練
40. BPR: DPRとの比較 40 • 評価するパッセージ数kが20個以上での再現率でDPRと同様かDPR以上の性能 • DPRの計算量を飛躍的に削減 → インデクスサイズ: 65GB -> 2GB → クエリ時間: 457ms -> 38ms Natural Questionsでの top-kでの再現率 TriviaQAでの top-kでの再現率 質問応答においては通常は20個以上のパッセージを 読み込むので、20個以下の性能は重要でない
41. BPR: エンドツーエンドの質問応答性能 41 モデル NQ TQA BPR+抽出型リーダ 41.6 56.8 DPR+抽出型リーダ 41.5 56.8 • DPRと同様の性能を飛躍的に小さい計算効率で実現 Natural QuestionsとTriviaQAでの正解率（exact match） 同じBERTをベースにした 抽出型リーダを使用
42. EfficientQA 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と抽出型リーダを組み合わせてEfficientQAに投稿し 6GB制約トラックでFacebookAIについで二位 • Facebook AIも独自のリトリーバの軽量化（post-hocな量子化、次元削減）を実施 • Facebook AIとの性能差の要因 ◦ リーダの性能差（生成型（Fusion-in-decoder） v.s. 抽出型） ◦ 知識ソースの差（Wikipediaのリスト） ◦ リトリーバの拡張（GAR）
43. EfficientQA 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と抽出型リーダを組み合わせてEfficientQAに投稿し 6GB制約トラックでFacebookAIについで二位 • Facebook AIも独自のリトリーバの軽量化（post-hocな量子化、次元削減）を実施 • Facebook AIとの性能差の要因 ◦ リーダの性能差（生成型（Fusion-in-decoder） v.s. 抽出型） ◦ 知識ソースの差（Wikipediaのリスト） ◦ リトリーバの拡張（GAR） 我々もFusion-in-Decoderを実装したものの、当時は性能を再現できず
44. EfficientQA 6GB制約トラックでの6GBの容量の割合 • システムの動作に必要なリソースを6GB以内におさめる必要がある ◦ 知識ソース（Passage corpus） ◦ 検索インデックス ◦ モデルのパラメータ ◦ OS、コード、依存ライブラリ • 特に知識ソースとインデックスが容量が大きい ◦ DPRが使用している英語Wikipediaのテキストデータは約16GB ◦ DPRのパッセージインデックスは60GB超(!) 44 Min et al. 2020 NeurIPS 2020 EfficientQA Competition: Systems, Analyses and Lessons Learned. ArXiv. 6GB制約トラックにおける上位エントリのストレージの使い方
45. BPR: ベクトル検索のオープンソース実装で採用 45 WeaviateがBPRを公式にサポート vespa.ai (Yahoo検索のOSS) が BPRを使った大規模検索を紹介
46. 実用化：アンサーロボ 46
47. アンサーロボ 47 • 独自に大規模な日本語／多言語での質問応答データセットを収集し リトリーバを訓練 • zero-shotで企業の実データにおいて高い性能を発揮 • クラウド（AWS）上でのSaaSとして展開 zero-shot型の企業向け質問応答システム https://answerrobot.ai
48. 30分でAIボットを作成できるアンサーロボ 適切なFAQの抽出を高精度の訓練済AIで行うから すぐに・手間なく導入できる 既存FAQを そのまま 登録するだけ 辞書登録 学習データ登録 不要 シナリオ登録 不要 Copyright © Studio Ousia｜All Rights Reserved. 4
49. スタートアップでの研究開発 49
50. 研究をする上で気をつけていること 50 • 実世界での実用的なニーズを満たすテーマを選ぶ ◦ 論文でのみ通用する問題設定を避ける ◦ 実用化から遠い基礎的な内容を避ける
51. 研究をする上で気をつけていること 51 • 実世界での実用的なニーズを満たすテーマを選ぶ ◦ 論文でのみ通用する問題設定を避ける ◦ 実用化から遠い基礎的な内容を避ける • 論文にも製品にもならない中途半端な状態に陥らないようにする ◦ 研究の各段階で目的意識を明確にして無理に続けずに早期に撤退する ◦ なるべくインパクトのある論文として対外的に発表できるように努力する
52. 研究をする上で気をつけていること 52 • 実世界での実用的なニーズを満たすテーマを選ぶ ◦ 論文でのみ通用する問題設定を避ける ◦ 実用化から遠い基礎的な内容を避ける • 論文にも製品にもならない中途半端な状態に陥らないようにする ◦ 研究の各段階で目的意識を明確にして無理に続けずに早期に撤退する ◦ なるべくインパクトのある論文として対外的に発表できるように努力する • 良い性能を出すことにこだわる ◦ 性能は実用上のメリットと論文の説得力を両立する近道 ◦ ベンチマークでの性能に関するインサイトはビジネスでも有用であることが多い
53. 研究をする上で気をつけていること 53 • 実世界での実用的なニーズを満たすテーマを選ぶ ◦ 論文でのみ通用する問題設定を避ける ◦ 実用化から遠い基礎的な内容を避ける • 論文にも製品にもならない中途半端な状態に陥らないようにする ◦ 研究の各段階で目的意識を明確にして無理に続けずに早期に撤退する ◦ なるべくインパクトのある論文として対外的に発表できるように努力する • 良い性能を出すことにこだわる ◦ 性能は実用上のメリットと論文の説得力を両立する近道 ◦ ベンチマークでの性能に関するインサイトはビジネスでも有用であることが多い • 研究用のコードと割り切らない ◦ 研究フェーズでなるべく綺麗なコードを書いておく ◦ そのまま拡張していけば製品に使える状態になるように努力する
54. 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
55. 55 ikuya@ousia.jp @ikuyamada 質問やコメント等は下記の連絡先までご連絡ください！ ありがとうございました！