こんにちは。
レトリバでは、研究動向・業界動向の把握のため、研究グループの人間は積極的に国内学会に参加しています。今回は、自然言語処理国内最大級のカンファレンスである言語処理年次大会に参加しました。
言語処理年次大会の概要
言語処理年次大会は名の通り、自然言語処理学会が年に一度開催する学会です。主に国内の自然言語処理の研究者が一同に解する機会でもあります。レトリバは創業以来スポンサーしており、今年もゴールドスポンサーとして支援いたしました。本年は数年ぶりに沖縄で現地開催され、過去最大の参加者数、論文投稿数でした。また、運営委員の方々の多大な努力により、参加者間の交流も活発行われていました。運営委員の方々には感謝申し上げます。
本大会では、弊社から勝又が発表を行いました（発表内容）。こちらは、先月記事を公開していますので、概要はこちらをご覧ください。また、飯田も博士課程での研究発表である検索に関する研究の発表を行いました（発表内容）。
以下では、印象に残った発表についてを紹介します。
印象に残った発表
対訳コーパスへの擬似文法誤りの挿入による翻訳誤り訂正データの構築
文法誤り訂正（Grammatical Error Correction; GEC）は非母語話者が書いた、誤りを含んでいるかもしれない文を入力、その誤りを訂正した文を出力するタスクです。（この辺りの詳細な考察はこちらやこちらが参考になります。） しかし、この問題設定だと言語学習としてはちょっと難しさもあるかと思います。 例としてこちらの発表や先行研究でも使われている、「I am leaving in Tokyo.」という英文を考えてみます。 誤った英文ではありますが、この英文には直し方として「I am living in Tokyo.」や「I am leaving Tokyo.」などが考えられます。 仮に、英語学習者が、気持ちとしては「東京に住んでいる」という気持ちで「I am leaving in Tokyo.」を書いたのに、システムが「I am leaving Tokyo.」を出力したら、言語学習者は「in はなくて良い」というような誤解を生じるかもしれません。 このように、言語学習者の意図した内容をシステムに入力できないために、本来の意図とは異なる訂正をシステムが行ってしまう可能性があります。 そのため、従来の非母語話者の作成した文だけでなく、その意図を示す原言語文（想定としては母語（L1）だと思います）を入力として与えることで、より意図を汲んだ訂正を行うタスクを設定する研究は（少なくとも自分にとっては）需要がありそうです。（なおこの場面設定は、この研究を知って感じた私の個人的な解釈であり、論文で言明されたものではありません）
この発表ではより簡易な設定として翻訳誤り訂正（Translation Error Correction; TEC）に取り組んでいます。 彼らはTECのタスク定義として、入力に（英語）誤り文と、（日本語）翻訳文を用意して、訂正した英語を出力としています。 このようにすることで、入力の誤り文、翻訳文の有無で性能が変化するかどうかを検証し、そもそも別言語の情報が誤り訂正に役立つかどうかを調査しています。 また、先行研究の手法に対してさらに文法誤り訂正でよく使われる疑似誤りがTECでも有効かどうかの検証なども行っています。
個人的にこの問題設定は色々練ることができるものだと思っていて、かなり面白いような気がしています。 冒頭の非母語話者の意図云々は私の個人的な意見なので、もっとうまい問題設定がありそうな気がしますし、意図の表現として翻訳文ではなく、最近流行りのInstructにしてしまっても面白そうです。 今回は原言語として日本語の文が追加されることによる精度の変化に関する内容になりましたが、日本語だけでなくL1の文として任意のものを受け取っても精度が出るかなど、興味は尽きません。 問題設定、評価データの構築などやることも多く、是非とも今後発展していってほしい研究だと感じました。
執筆：勝又
日本語Tokenizerの違いは下流タスク性能に影響を与えるか？
こちらの発表はBERTの事前学習および下流タスクへのファインチューニングの際に用いるTokenizerによって性能がどのように変わるのかを評価したという内容でした。BERTなど大規模言語モデルを用いる際、形態素解析器にどれを用いたらいいのか、或いは用いなくてもいいのかという点は悩みの種になります。例えばHuggingface Transformersを用いる際に形態素解析器を用いずサブワード分割のみを用いるのであれば、sentencepieceのモデルを用意すればexamplesにあるスクリプトを用いることができます。一方で形態素解析器による分かち書きを行う場合にはtransformersのtokenizerにテキストを渡す前に自前で分かち書きを行うか、BertJapaneseTokenizerが対応しているモデルを使う必要があります。また、形態素解析器によって処理速度に差があり、もし処理に時間がかかる形態素解析器を用いた方が性能が大幅に良いとなると、性能と処理時間とのトレードオフがまた検討事項になります。
この発表ではMecab(IPAdic, Neologd)、Juman++、Sudachi、Vaprettoといった形態素解析器とByte Pair Encoding(BPE)、WordPiece、Unigramといったサブワード分割の組み合わせによる下流タスクの精度への影響を網羅的に評価していました。結果としては形態素解析器間に有意な差は無いが、形態素解析は行った方が良いという形でした。また、サブワード分割に関してはBPE或いはUnigramを用いた方が良いとのことでした。
形態素解析による前処理は必要*1ですが、個人的には処理の早いものでよさそうという指針が得られて良かったので印象に残った発表でした。
執筆：西鳥羽
専門性の高いオープンブック質疑応答システムの構築と専門家添削による誤答抑制
この発表は、近年盛んに研究されている、オープンQ&Aシステムを専門家向けかつ内部文書に対して適用した研究です。 オープンQ&Aシステムは基本的には多くの教師データが必要であり、専門家向けという点においては、その教師データ作成およびその量がボトルネックになります。これらのボトルネックへの対処方法の工夫がさまざまに見られる点が、個人的には本研究の興味深い点でした。
データに関する流れとしては、
- SQuADやNatural Questionといった既存の英語データを和訳することでモデルを作成します。
- 専門家に質問応答データを数百件ほど作成してもらいます。
- 質問と正答のリストのペアを約200件用いて、回答が正答リストに含まれているかどうかで教師データを作成しています。
なお、3. については、回答生成時に３フレーズ生成することで、データを増やしています。なお、実際にはこのプロセスは、質問と回答のログデータを見て専門家がアノテーションすることを期待しているということです。
システムの構成としては、通常のオープンQ&Aシステムで用いるRetriever・Readerに加えて、誤答を抑制するVerifierを用いています。VerifierはこちらのACLでの発表でも有効とされているようです。 結果、データを増やしていくほど、誤答数が下がっていきました。発表中にはユーザの印象も語られており、もある程度正解ではあるものの、微妙に条件が異なるためそのままでは使えないという程度まではできていたということでした。
感想ですが、和訳＋数百件の教師データでもオープンQ&Aシステムとして成立することに驚きました。ただし、質問種類をある程度絞っており、entity抽出系のシステムになっていたようです。 また、Q&Aシステムとなることで、複数の文書をenittyの観点からまとめらるため、単純な検索でのアノテーションコストに比べてを大幅に削減できるのではないかという感想を持ちました。クエリをログするシステムがあれば、アノテーション自体のprecisionは高くできそうです。
なお、個人的には検索のみの場合の精度面が気になりました。Fusion-in-Decoderの論文でも、Readerからのフィードバックを用いることがさらなる精度向上につながっているとされています。
オープンQ&Aシステムとして数百件頑張るのか、検索システムとしてアノテーションをつけていくのか、ChatGPT以後、生成が非常にうまくいく今日において、どちらで特定ドメインに対して教師を付与していくのか、そのデータ拡張方法をどうやっていくのかは、今後も注目していきたいと思いました。
執筆：飯田
終わりに
レトリバ研究グループでは自社製品の研究開発を行うだけではなく、学会イベントなどのスポンサー・大学との共同研究の遂行・研究成果の対外発表など、学術コミュニティへの貢献を積極的に行っています。∪・ω・∪また、レトリバは絶賛インターン募集です。ご興味ある方はこちらよりお問い合わせください。
*1:言語処理年次大会後にリリースされたSentencePieceでは形態素解析器には事前分割制約をオプションで指定する機能が搭載されたため、形態素解析器による分割を反映したサブワード分割をSentencePieceだけで行うことができるかもしれません。Sentencepiece の分割を MeCab っぽくする - Qiita
