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

Posted by on 2021年1月14日 2 comments

英文を日本語訳するニューラル機械翻訳モデルを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

Posted by on 2020年10月18日 No comments

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

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

スコア表示

お試しサイトでは英語文と対応する翻訳文それぞれについてスコアが付与されている。スコアは翻訳文が良いかどうかを表す指標であり、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. 翻訳対象の英語文それぞれについて４つの和訳結果（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）

Posted by on 2020年8月25日 No comments

夏休みの宿題（？）として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） – 結果 –

Posted by on 2019年3月11日 No comments

前回からの続き。脳からの知識蒸留を目指し実験を行った。目的は効率的なハンドラベリングであり、今回の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 »

脳からの知識蒸留（Distilling the Knowledge from a Brain） – 準備-

Posted by on 2019年3月10日 No comments

知識の蒸留（Knowledge Distillation）とは？

Deep learningの世界では知識の蒸留（Knowledge Distillation）が行われている。蒸留というと非常にかっこよい響きなのだが、やっているのは「大きなモデル」を用いて「小さなモデル」を「効率的に学習・構築」することである。
バラの病気診断モデルは以前紹介したように次の手順で構築した。

  • データ（写真）を集めて、ラベル（病気の有無など）を人が設定する（ハンドラベリング）。
  • ハンドラベリングしたデータを用いて、教師あり学習を利用し、植物の葉が病気か否かを判別する多値分類モデルを構築する。

上記で構築したバラの病気診断モデルはInception V3をベースにしておりネットワークの規模が大きい（ネットワーク規模の情報）。すなわち、高精度だが低速度である。バラの病気診断モデルをスマホに展開したい場合、若干精度を落としてでもネットワーク規模が小さく高速なモデル（例えばMobileNet）を使いたくなる。普通はデータだけ再利用してモデルは学習しなおすというプロセスが必要となるが、蒸留を用いると効率的な構築が可能となる。ざっくりとした仕組みは次の通りである。

  1. 病気診断モデル(Inception V3 / 先生)に学習用画像データを入力し、その画像に対する「健康・黒星病・うどん粉病・その他カビ系の病気」の4カテゴリの確率を得る。
  2. 病気診断モデル(Inception V3 / 先生)が出した4カテゴリの確率情報も用いて病気診断モデル(MobileNet / 生徒)を学習する。

普通は健康か否かという0/1の情報で学習するが、高精度モデルが診断した確率にも有用な情報が含まれているので、それを利用しようというアイデアである。実際に蒸留は効果があり、モデル圧縮をする場合によく用いられている。詳細はIntelの記事が良くまとまっていて、kerasを用いた実装例も載っている。

脳からの知識の蒸留（Distilling the Knowledge from a Brain）

バラの病気診断サイトを作ったときに時間がかかったのは、病気か否かのラベリングである。一般的に人間によるラベリングは高コストであり、しかも、間違いが含まれている。ハンドラベリングをしたことがある人ならわかると思うが、現実のデータには判定に困る画像も多い。加えて判定基準は人によって異なっている。同症状の画像に異なるラベルが貼られていることは少なくない。
ハンドラベリングは教師である人間から、生徒であるDeep Learningな各モデルへの情報伝達に他ならない。ということは蒸留の仕組みも利用できるはずである。人間が下した0/1の判断だけではなく、それに付随する判断確率の情報を用いれば高速・高精度なモデルが構築できるに違いない。問題は判断確率の分布情報をどうやって得るかであるが、近年のテクノロジーによって解決できる。すなわち脳波を計れば良い[1]。

脳波の測定とラベリング

今回、脳波の測定はNeuroSkyのMindWave Mobile 2で行った。このデバイスを用いてハンドラベリング時の脳波をはかり、その値をラベルの確度の一つとして利用する。MindWave Mobile2は1.5万円くらいで購入でき、python+thinkgearを用いてデータの取得が可能である（serialではなくpyserialが必要なことに注意）。なお、本件はMacで実施したのでWindowsではやり方が異なる可能性がある。
ライブラリはpipから導入できる。

pip install thinkgear
pip install pyserial

ライブラリ導入後、pythonを用いて

device = '/dev/tty.MindWaveMobile-SerialPo'
tg = ThinkGearProtocol(device)
for pkt in tg.get_packets():
  for d in pkt:
    if isinstance(d, ThinkGearAttentionData):
      val = d.value
      now = datetime.datetime.now()
      print("{},{}".format(now, val))

と言う感じでデータが取得できる（上記の例では脳波というよりは集中度をとっている）
今回は下画像のようなラベリング用簡易WEBアプリに脳波取得ロジックを組み込み、ラベリング実施時の脳波（特に集中度）を計測・保存した。ハンドラベリング時には0/1な病気判定だけでなく、その病気の進行度も選べるようになっており、迷いが生じると脳波に現れる[2]。モデル構築の学習時に脳波情報を併用することで、Deep Learning部の収束が早くなれば、脳からの知識蒸留ができた[3]と言えるのではないか。

実験の結果は次ページで報告。

脚注

[1] 別に脳波である必要は無い。むしろ、脳波は計測が難しく、このような用途には適していない。
[2] 実際のところ現れたと言えば現れたが本当に脳波なのかはかなり疑問である。前述の通り、心拍とか血圧とか目線とか判断までの時間とか脳波よりも測りやすくて効果がありそうな指標は多数存在する。
[3] 本件が誇大広告であることは認識している。が、Deep Learning関係の研究論文から著しく外れた言葉使いはしていない（と思う）ので激しい突っ込みは勘弁してください。