Author Archives: staka - Page 5

Arxiv論文の翻訳サイト

前回公開した機械翻訳モデルのアプリケーションとして、arXivに投稿された人工知能関連の論文のメタデータ(タイトル・アブストラクト)とCreative Commonsライセンス(CC 0, CC BY, CC BY SA)の本文を日本語に翻訳するサイトを作成した。

Fugu-MT: arxivの論文翻訳

トップページでは投稿日別に最新3日の要約を表示している。メタデータ・本文の翻訳は日付別の参照から確認できる。全文翻訳がある場合はそのリンクを貼っている。

アブストラクトを要約・翻訳して一覧化も行っている。

Fugu-MT: arxivの論文翻訳(概要)

スマホなどで最新の論文をざっくり確認したい場合は便利だと思う。arXivのメタデータはCC 0なので要約や翻訳が可能である。

技術的な話

サイトの構成

このサイトはarXivのAPIを用いて人工知能分野の最新論文を取得、Fugu Machine Transratorを用いて日本語に翻訳している。PDF本文を翻訳するエンジンはリンク先のgithubにあるものを若干カスタマイズして使っている。

静的なWEBサイトで構成するため[1]に、翻訳結果などは基本的にHTML化して保存している。PDF情報もBASE64で埋め込んでいて、HTMLファイルをダウンロードすればどの環境でも翻訳文の閲覧が可能である。

CSSやJSはCDN経由としているので、「wgetでダウンロード」「ブラウザでリンク先を名前を付けて保存」などCSSやJSをローカルに保存する動きをしない方がうまく動く[2]。

2週間程度動かしてみてArxivに投稿された論文をライセンス別に集計すると大体1/3くらいは全文翻訳可能なライセンスとなっていた。最近Openなライセンスの論文が増えている印象で非常にありがたい。

作成したサイトでは30ページを超える論文は翻訳対象外としている[1]。30ページを超える論文の和訳が欲しい・Arxiv以外のサイトで翻訳可能な論文の和訳が欲しいなどの場合はFugu Machine Transratorでこのサイトと同じようなことができる(若干不具合があるので、今月中には修正予定)。

arXivへのアクセスはかなりゆっくりやっていて、API Limitやrobots.txtで決められた待機時間より2倍以上長めのwaitを入れているので更新は遅めかもしれない[3]。

要約処理

アブストラクトの要約にはPEGASUS: Pre-training with Extracted Gap-sentences for Abstractive Summarization論文)を用いている。PEGASUSはAbstractive Text Summarizationタスクで優秀なモデル(CNN / Daily MailでPapers with Code 3位[4])として知られている。論文のアブストラクトをさらに要約するにはExtractiveな手法ではイマイチであり、Abstractiveな要約手法を採用した。結果、まずまず良い感じに要約できているように思う。

所感など

arXivの日本語翻訳を行っているサイトはいくつかあり、また、arXiv Vanity を使ってブラウザの翻訳機能経由で日本語翻訳を行うことを紹介しているものもあった。arXiv VanityはPDFではなくそのソースであるTeXをベースにHTML化しているようで品質が高い[5]。正直、実用的にはこのような方法で十分だと思うが、自作ニューラル機械翻訳モデルの性能評価の意味を込めてサイトを作成してみた。

結果、アブストラクトについては大手翻訳サイトと比べても十分に比較可能なレベルで翻訳ができているように思う[6]。論文本体はPDFのテキスト化、英語文のsentence tokenizeに課題を抱えているためそこまで高精度ではないが「流し読みに便利」程度のレベルにはなっている。

Abstractiveな要約いわゆる抽象型と呼ばれる要約手法はExtractiveな要約(抽出型要約)に比べて安定した性能を出しにくいことが多いが、今回は翻訳を通しても文の破綻が少なくまずまずの性能が出せている。(要約部分も翻訳部分も意訳に近い動きをしているため、内容が変わることも少なからずあるが・・・[7])

前回TODOに挙げていた事を無視してarXivの翻訳サイトを作ってしまったが、良い経験にはなった[8]。英語のNLPでできる事は非常に多いのでFuguMTを便利に使ってもらえたら嬉しい[9]。

一応、1400万対訳ペアでのモデリング、1400万対訳→1000万対訳ペアへのフィルタリング(高品質化)なんかもやってはいるので、ぼちぼち翻訳エンジンの強化も再始動したいと思う最近。NLP周りの英語での成果を使うためにはEN→JAだけでなくJA→ENも必要なのでそのモデルも作ろうかなーとも思っている[10]。

脚注

[1] VPSのスペックによるもの・・・。
[2] ブラウザがJSやCSSをダウンロードし、リンクを書き換えるとうまく動作しないことがある。
[3] APIのデータは日本時間午前8時頃に更新されるがアクセス過多になっていることが多い。アクセス過多の時のwaitもかなり長めにとっているので新規論文リストを取得&論文のメタデータを取得完了するのは日本時間11時頃になっていると思う。(大体、次の日には和訳できてる、くらいのイメージ)
[4] 2021/2/14現在。リンク先にはExtractiveな要約が入っていない、PwCのLeader boardに載っていない結果もある、などの理由で実際の順位は不明。とはいえ、SOTAと比べて大幅に性能が低いわけではない。(正解が正解か怪しい世界でROUGEという微妙な指標を用いてベンチマークした結果よりも、要約したいドメインでの目検証の方が重要・・・。本件でも実は様々な手法を試している。)
[5] Robots.txt的にTeXファイルの取得はDisallowな気もしつつ、どう実装しているかは謎。
[6] 論文ドメインでのfine tuning無しの素の結果なので結構優秀ではなかろうかと自画自賛。ただ、語彙の点で負けている感はある。ニューラル機械翻訳モデルのパラメータチューニング&(やや反則だが)論文ドメインでのfine tuningを行えば大手翻訳サイトの性能を越えられるんじゃないかと思わなくはない。(がAWS費用がつらい)
[7] 要約文が破綻していても翻訳側で救っている場合もあった。要約結果があまりに変な文だと翻訳側が壊れる(同じ単語を繰り返す)みたいな事も起きる。
[8] 現実のデータと格闘しないと分からないことは多い。
[9] 日本語版のpre trainedモデルがたくさん公開されるとかNLPは日本語版がSOTAみたいな時代が来ると嬉しいが、現実は厳しい気がしている。マルチリンガル方面は流行なので、それで解決される可能性も感じているが・・・。
[10] GPU買っちゃおうかなーとも。対訳データを1円/wordくらいで買ってくれるとこないかな、、、

フリーのニューラル機械翻訳モデルFuguMT

英文を日本語訳するニューラル機械翻訳モデルをCC BY-SA 4.0で公開した。以前の記事で紹介した手法を用い昨年11月に構築したモデルである

  • FuguMT ver.2020.11.1 (約440MB)のダウンロード
  • shasum: 0cf8a1fc540b4c7b4388b75b71858c0eb32e392a
  • ライセンス: CC BY-SA 4.0  (readmeにも書いた通り、作者(Satoshi Takahashi)は本モデルを使用して発生したあらゆる結果について一切の責任を負いません 。引用等を行う場合はこのBlogのURLを記載するか、リンクを貼ってください。)

性能はそこそこ(後述)。構築手法は本格的(Marian-NMT[1]を用いた Transformer + Sentence Piece[2])である。

研究用途での試用を前提としており、当然ながら動作や出力に関して一切の責任を負えない(重要なので2度目) [3] がCreative Commonsに従って利用可能なモデルは珍しいと思う。

周辺のコードを含めてgithubにuploadしたので、利用する場合はgithubのfugumtリポジトリを参照いただきたい。githubのコードは基本的にテストサイトと同様だがシンプルに使用可能な構成にしている[3]。

翻訳を行う場合は著作権に注意。最近はCC Zeroなど自由なライセンスで公開される論文等も増えてきているとはいえ、通常、著作物を自由に翻訳することはできない。

モデルの詳細

githubに記載の通り FuguMT ver.2020.11.1 は様々なデータセットを組み合わせて作成している。使用したデータ量は約660万対訳ペア(日本語:690MB 英語:610MB、約1億words)である。 AWS p3.2xlarge 上で Marian-NMT + SentencePieceを用い約30時間の学習を行った。

公開するモデルは「model.npz」と「model_uncased.npz」の2つで、前者は英文をそのまま日本語訳するモデル、後者は英文を小文字に統一(sentence pieceの–normalization_rule_name = nmt_nfkc_cf)し日本語訳するモデルである。 fine tuningも可能。詳細な設定はzipファイル中の「model.npz.yml」「model.npz.progress.yml」を確認してほしい。fine tuning時にはreadmeを読みライセンスに従った取扱いをお願いしたい。

このモデルの性能はKFTT テストデータのBLEUで23程度である。技術文書、論文に対してはもう少し性能が高く、BLEUで30程度とオンラインで公開されている翻訳エンジンと同レベルの性能を出すことができる。BLEUは良い指標とはいいがたいため、 テストサイト で試してみると大体の性能が分かると思う。このBlogを書いている時点ではテストサイトの翻訳エンジン1はFuguMT ver.2020.11.1のmodel.npzを使用している[4]。

多くの場合 「model.npz」の方が良い結果を出力するが、翻訳が難しい文の場合「model_uncased.npz」の方が安定した結果を出力する。githubのfugumtライブラリでは複数の翻訳結果候補から良いと思われる出力を選ぶ機能を実装している。

FuguMT ver.2020.11.1 で利用したデータセット

FuguMT ver.2020.11.1 で使用したCreative Commonsライセンスのデータセットは下記の通り。CCで利用可能なデータセットには非常に助けられた。フリーなライセンスで公開された方々に感謝したい。FuguMTの構築には下記以外に独自に収集したデータも利用している[5]。

使い方

fugumtに記載の通り。githubのDockerfileをbuildし、モデルをダウンロード、marian-decoder経由で使う手順がテストを行いやすい。CPU 1コアで実行した場合1文の翻訳に2-3秒は必要である。

fugumtライブラリでは文章の文分割、訳抜け防止モードの実行、翻訳の適切さのスコアリング、複数の翻訳候補から良い翻訳文を選ぶ機能などを実装している。

pdf_server.pyを使うとpdfminerを用いてPDF文書をそのまま翻訳できる。pdf_server.pyはpickleを出力する。server.pyの機能でPDFと訳文を対比しながら内容を確認できる。 計算時間は1ページあたり1分程度である。

今後の予定

githubにも書いている通り、TatoebaとCCAlignedを用いたモデルは構築済みで性能評価中である。対訳ペア数は1400万に達しているものの、CCAlignedのデータに機械翻訳されたものが多数混在しており総合的な性能が向上するかは検証できていない。これを含め、今後下記のようなことをやりたいと思っている[7]。

  • 対訳ペアを1400万ペアに拡張したモデルの性能評価・公開
  • FastAPI等を利用したAPI化
    • bottleの実装を改善したい
  • 英語→日本語だけではなく日本語→英語のエンジン作成
    • 基本的にはデータを反転させれば作れる
  • Back Translation、BARTやmT5など事前学習モデルの活用、文脈を使った翻訳などモデルの高度化
    • Back Translationの活用はマシンパワーがあれば可能
    • BARTは試行したが性能が向上しなかった。とりあえず中断した検証を再開したい。
    • 1400万対訳ペアのうち7割程度は文脈を考慮可能[8]で文脈を考慮するモデルは構築したい(構築できる)。
  • 英語・日本語以外への対応
    • フランス語、ドイツ語、イタリア語、スペイン語、ロシア語、ポルトガル語は一定程度の対訳をコレクションしている。

その他

とりあえず夏休みの宿題で作ったものを形にして冬休み(+1週間)に公開できたのは良かった。 FuguMTは気軽に使えるがモデル性能はそこまで高くない。何らかのサービスで利用する場合は大手翻訳サイトのAPIと比較してみてほしい。

元々のモチベーションはSuperGLUEのような標準データセットの日本語版を作りたいというものだった。SuperGLUEは昨年末に「解決」されてしまい、xtremeといったマルチリンガルなベンチマークも流行っているのでやや時代遅れ感もある。。。が、勉強にはなった。

次に何をやるかは考え中。今後の予定にあることを地道にやっていくか、全然違うことをやるかも正直決めていない。

対訳ペアのデータの公開は今のところ考えていない。商業的価値のあるデータだと思いつつ、リーガルチェックや税金の問題など様々な課題があるので相当の金額でないと有償提供もしないと思う。

脚注

[1] Marian-NMT: https://github.com/marian-nmt/marian
[2] SentencePiece: https://github.com/google/sentencepiece
[3] 特に差別的な翻訳を行う可能性など十分な検証はできていない。
[4] 安定性は若干劣る。テストサイトはuwsgi+nginxで動作させる構成としている。もっとも、Marian-NMT自体が非常に良くできたソフトウェアなので、npzファイルさえあれば他はいらないかもしれないが・・・。
[5] これらデータを機械翻訳モデル構築に用いた場合、機械翻訳モデル(npzファイル)のライセンスがどうなるかは多くの議論がある。ここでは出所・ライセンスを明確にし、引用条件は配布サイトの表記に従っている。
[6] データはフィルタリングして使用。660万対訳ペアのうち300万対訳ペア程度は自力で収集したデータである。
[7] 趣味でやっているので時間が足りない。加えてAWS費用が重い。
[8] ただの文ではなく、ドキュメントとしてデータを保持している。

機械翻訳と訳抜けとConstituency parsing

翻訳エンジンのお試しサイト(https://devneko.jp/demo/)を更新した。主に下記の機能を追加している。

  • 最大3000文字までの長文対応
  • 訳抜け防止モードの高度化
  • 翻訳結果に対するスコア表示

長文対応は文字数制限を外してnltkのsent_tokenize[1]を使用しているだけである。翻訳結果に対するスコア表示、訳抜け防止モードは以下のように多少工夫した。

訳抜け防止モード

Deep Learningな機械翻訳では訳抜けという現象が発生する。これは訳すべき英文を省略してしまうという現象である。結果、流暢であるが情報が欠けた文章が出力される。Google翻訳やDeepL翻訳などメジャーな翻訳エンジンでも起きることがあり(当然ながら)個人開発の翻訳エンジンではよく発生する。

例えば、下記の英語文を翻訳する例を示す。

Natural language processing (NLP) is a subfield of linguistics, computer science, and artificial intelligence concerned with the interactions between computers and human language, in particular how to program computers to process and analyze large amounts of natural language data.

https://en.wikipedia.org/wiki/Natural_language_processing 11 October 2020, at 18:45 (UTC) の版、Wikipediaより引用

現在の私の翻訳エンジンは上記文章を「 自然言語処理(nlp)は、コンピュータと人間の言語間のインタラクションに関する言語学、コンピュータ科学、人工知能のサブフィールドである。 」と翻訳し、「in particular」以後の情報が抜けている[2]。

訳抜けには様々な理由が考えられるが長い文だと発生しやすい。そこで訳抜け防止モードではconstituency parsing[3]を行ったうえで意味が成立しそうなブロックに分割し翻訳エンジンを適用するフローを採用している。ブロック分割した結果はお試しサイトの一番下に表示される。本件では翻訳対象の文が

Natural language processing ( NLP ) is a subfield of linguistics, computer science, and artificial intelligence concerned with the interactions between computers and human language,

https://en.wikipedia.org/wiki/Natural_language_processing 11 October 2020, at 18:45 (UTC) の版、Wikipediaより引用

in particular how to program computers to process and analyze large amounts of natural language data.

https://en.wikipedia.org/wiki/Natural_language_processing 11 October 2020, at 18:45 (UTC) の版、Wikipediaより引用

に分割された。結果、訳抜け防止モードでは上記の英文を「自然言語処理(nlp)は、コンピュータと人間の言語間の相互作用に関する言語学、コンピュータ科学、人工知能のサブフィールドである。 特に、コンピュータが大量の自然言語データを処理および分析するためのプログラム方法。」と翻訳した。意味としては良くなっている一方で流暢さは損なわれている。 実装した訳抜け防止モードは文を分割して翻訳しているだけであり、現状の機械翻訳エンジンは文脈の考慮もできていない。訳抜け防止モードの翻訳品質は通常モードに比べて低くなる。

翻訳エンジンのお試しサイトでは通常の翻訳×2[4]と訳抜け防止モード×2の結果を文毎に比較し、最も良い結果(スコア算出方法は後述)を採用している。

スコア表示

お試しサイトでは英語文と対応する翻訳文それぞれについてスコアが付与されている。スコアは翻訳文が良いかどうかを表す指標であり、0.0 – 1.0で評価される。概ね0.7以上であればそれなりの訳文になっていることが多く、0.5以下の場合は何かしらの問題が起きていることが多い。特に0.3以下の場合はほぼ確実に訳抜けが発生している。

スコアは「①文の類似度」×「②単語/形態素数の類似度」で計算している。「①文の類似度」はUniversal Sentence Encoder[5] + cos類似度である。LaBSE[6]も試行したがこのタスクではメモリ・計算時間の増加[7]に比べて効果が薄かった。「② 単語/形態素数の類似度 」は英文の単語数と日本語文の形態素数の比率が対訳データの平均(0.85)に近いかを計算している。形態素解析はMeCabを用いた。

所感・その他

お試しサイトの処理フローは以下の通りで機械翻訳エンジンを使う際の対応は大体実施できた気がしている。

  1. 改行が連続した場合は別の文とみなし、処理ブロックを分ける。(途中改行が1つの場合、文は連続しているとみなす。arxivの論文やPPT資料でありがちな改行の入り方に対応している。)
  2. 処理ブロック内の文章をNLTKのsent_tokenizeで文に分割する。
  3. 文に分割されたデータそれぞれに対してconstituency parsingを行い、意味が成立すると思われる一定の長さで文を分割する。
  4. 上記、2.、3.で作成した文のリストを機械翻訳エンジンで和訳する。和訳はハイパーパラメータを変えた2つのエンジンで行う。
  5. 翻訳対象の英語文それぞれについて4つの和訳結果(3.の有無×4.の2つの結果)のスコア(USEのcos類似度×単語/形態素数の平均比)を計算し、一番良いものを採用する。

それなりに複雑な処理になっているがOSSのソフトフェア・モデルをフル活用しているためコードの記述量はそこまで多くない。上記処理もそのうちgithubとかで公開しようと思っている。

(今のところ情熱が残っているので)今後は翻訳エンジン自体の強化を行っていく予定である。

現時点で前回使ったデータに加えて約200万対訳ペアの作成が完了している。加えて50万対訳ペア程度は追加できそうなのでデータ量は1.5倍程度にはなる見込みである。ぼちぼち小文字統一をしなくても良さそうなデータ量になっていることもあり、条件を変えながら深層学習モデルを作って比較するような事もやっていきたい[8]。

文脈が計算可能なデータ(対訳ペアの元となったドキュメント情報が残っているデータ)もそれなりにあるので、文脈パラメータを入れた機械翻訳エンジンの作りたいなーとも思っている。

構築したモデルはCC BY SAくらいのライセンスで公開する予定で自然言語処理分野の英語データセットを和訳する利用方法を想定している。アノテーション構造を保持したい場合の支援機能[9]組み入れも予定しつつ、時間があまりないなーと思っている今日この頃。

脚注

[1] https://www.nltk.org/api/nltk.tokenize.html?highlight=sent_tokenize#nltk.tokenize.sent_tokenize
[2] メジャーな翻訳エンジンは正しく処理する。流石である。
[3] 今回はAllen NLPのhttps://demo.allennlp.org/constituency-parsingを用いた。
[4] 翻訳はハイパーパラメータを変えて2回実行している。複数候補を出して選ぶというのもよく見られる構成だが、本件では行っていない。
[5] https://tfhub.dev/google/universal-sentence-encoder/4 対訳データ作成でもお世話になったモデルである。
[6] https://tfhub.dev/google/LaBSE/1 BERT系のモデルであり、多言語対応のText Embedding用途では最新・最高性能に近いと思われる。
[7] 類似度の妥当性ではUSEに比べてLaBSEがやや良いが、計算時間が数十倍(50倍以上)でありメモリ使用量も増加する。お試しサイトで使っているVPSで動かすのは厳しかった。
[8] AWS課金が凄いことになりそう。。。本当はBack Translationもやりたい・・・。
[9] 英語文→日本語文でタグ構造を維持する程度の機能は入れたい。tokenizer(sentence piece)構築時点でタグを特殊記号扱いし、対訳ペアに正しくタグを扱っている文を追加して学習させる予定である。このあたりは翻訳エンジンそのものに手を入れないと実現しにくく、メジャーな翻訳エンジンで同様の事をやるのは簡単ではないと思っている。

翻訳エンジンの構築(Marian-NMT)

夏休みの宿題(?)としてMarian-NMTを使って翻訳エンジンを構築してみた。構築した翻訳エンジンは「英語→日本語翻訳(https://devneko.jp/demo/)」から試すことができる。訳すべき単語を飛ばすなど深層学習な機械翻訳特有のミスをすることも多いが、個人が試作したものとしては相応の性能な気がする。割と訳せていて正直驚いた。ただ、入力文の適切な分割など前処理的な事をほとんどやっていないので変な結果になることも多い。

データセットは「WEB クロール + Universal Sentence Encoderで収集したデータセット」+「Free(Creative Commonsライセンスなど)のデータセット」、使用した手法はTransformer + sentence pieceであり、バリバリのDeep Learningで現時点でも本格的である。ただし、環境制約(というか時間制約&予算制約(後述)からBack Translationは使えていない。)

上記エンジンでは300文字以内の英語文(複数文の場合性能は落ちる) [1] を日本語に翻訳することができる。訳抜けを防止するモードもあるが、カンマや記号で文を分けているだけなので訳抜け防止モードの性能はあまりよろしくない。

翻訳エンジンを作った理由

本当は日本語でGPT-2辺りのfine tuningを試そうと思っていて「Faster than training from scratch — Fine-tuning the English GPT-2 in any language with Hugging Face and fastai v2 (practical case with Portuguese)」という素晴らしい記事を読んでいた。その中に「For example, to obtain a Portuguese GPT-2, we could download from the Transformers library of Hugging Face the OpenAI GPT-2 pre-trained in English and the MarianMT translator」という記載があったものの、残念ながら「日本語→英語」のモデルは公開されているが「英語→日本語」 のモデルは公開されていなかった[2]。

自由に使える翻訳エンジンは役に立ちそう[3]なので自分で構築することにした。車輪の再発明ではあるが、色々と良い経験になったと思う。

翻訳エンジンの作り方

翻訳エンジンを作るにはデータセット、学習用ソフトウェア、学習環境が必要である。今回は下記を用いた。

  1. データセット: WEBをクローリングして収集[4]+Freeで公開されているものを追加 [5]
  2. 学習用のソフトウェア: Marian-NMT (transformer) + sentencepiece [6]
  3. 学習環境: AWS p3.2xlarge インスタンス [7]
Read more »

脳からの知識蒸留(Distilling the Knowledge from a Brain) – 結果 –

前回からの続き。脳からの知識蒸留を目指し実験を行った。目的は効率的なハンドラベリングであり、今回のPoCでは生体情報をDeep Learningの蒸留と同じ方法、ソフトターゲットの設定で活用できるか?を検証した。

解いた問題と前提

データセット

脳からの知識蒸留を目指すため、前回作成したツールを用いて約330枚のバラの写真に対するハンドラベリングを行った。ハンドラベリング時に取得したデータは次の通り。

  • 病気の区分(黒星病・うどん粉病・健康)
  • 病気の進行度(軽症・中程度・重症)
  • 脳波(集中度を利用)
  • 分類にかかった時間(集中度の平均化のために使用)

元データはバラの病気診断サイト用に収集したもので、黒星病・うどん粉病・健康が1/3ずつとなるよう調整し、ハンドラベリングを実施した(各クラスのデータ数は同じ)。進行度は軽症が半分、中程度以上が半分な感じだが、データセット内の進行度の割合は調整していない。

モデル・学習の概要

今回は3クラス(黒星病・うどん粉病・健康)分類問題を(Convolution層+Pooling層)×2+分類用の層×2なCNNで解くシンプルな問題設定・モデルとした。転移学習や事前学習は行っていない。
脳からの知識蒸留が有効かを確認するため、下記4つのデータで学習し結果を比較した。

  1. 病気区分のラベルのみを用いた学習(普通の学習)
  2. 病気区分のラベルと進行度を併用した学習。病気進行度が高いほど病気区分ラベルの確信度が高くなるようにした。
  3. 病気区分のラベルと脳波を併用した学習。集中度が低いほど病気区分ラベルの確信度が高くなるようにした。(難しく考えなくても分類できたと言う意図[1])
  4. 病気区分のラベルと進行度と脳波を併用した学習。2.と3.の掛け算。

データセットを学習用75%・評価用25%に分割し、2エポック後の評価用データに対する正解率を比較した。学習データ・評価データに含まれる写真は4条件すべてで同一である(4条件でデータ分割による有利不利は生じていない)。loss関数として1.ではcategorical_crossentropyを、2.-4.ではkullback_leibler_divergenceを用いた。これは、2.-4.の正解データが教師の出力(本件では人間の確信度に相当する分布)でありバイナリ値ではない為である。

結果とまとめ

結果は次の通りであった。驚くべきことに[2]、Distilling the Knowledge from a Brainには効果があった。

  1. 通常の学習:正解率 37%
  2. 進行度の併用:正解率 37%
  3. 脳波の併用:正解率 41%
  4. 進行度+脳波の併用:正解率 49%

結果の解釈は難しいが、正解ラベル以外の情報(特に脳波)にも意味がありそうな感じである。データ数が少なく、そもそもの正解率が低いので何ともいえない感もあるので、今後データ数を増やして再度実験を行ってみたいところ。以下、硬い感じのまとめ。
AIが流行るにつれてハンドラベリングの重要性も上がっている[3]。本PoCではハンドラベリング時に脳波を測定し、それをモデル学習時に使用することで学習の効率化が出来る事がわかった。今後のラベリング作業では脳波を測定することがスタンダードになるだろう[4]。分類時の脳波付きデータセットが広く公開されることを期待する[5]。そのようなデータセットのもと、Distilling the Knowledge from a Brainの活用や脳波予測タスクをマルチタスクの1つとして解く学習によって、他のタスクの精度が上がっていくと推測される[6]。
(硬いまとめはここまで。個人的な思い的な考察はその他に続く。)

脚注

[1] この仮定は相当怪しい。
[2] こんな雑な問題設定・解き方で差が出るとは思わなかったが、複数回実行しても結果がほぼ同じであった。同じモデルにtrainを繰り返していないか確認したり、1.-4.の学習順番を変えてみたりもしたが同じ結果だった。びっくり。観測者効果的なもので脳波が変わったのだろうか?それはそれでびっくりだが。
[3] これはたぶん本当。実務では大きな課題。
[4] 脳波計測がスタンダードにはならないだろうが、取りやすい生体データが併用される可能性は感じた。特に心拍とか視線とか。
[5] 欲しい人がいれば今回のデータを公開してもよいかなーと思いつつ、雑にやったところを綺麗にするのが面倒なので、お蔵入りになりそうな予感がしている。
[6] 個人的にマルチタスクへの適用に可能性を感じている(参考論文「One Model To Learn Them All」)が、良い感じのデータが無いので試せていない。暇があったらやるかも。
Read more »