深層学習を使った固有表現認識のサーベイ論文
IEEE Transactions on Knowledge and Data Engineering 2020の論文。
深層学習を使った固有表現認識のサーベイ論文。 ieeexplore.ieee.org
5章 今後の方向性
5.1 チャレンジ
データのアノテーションの課題
データのアノテーションには時間とコストがかかる。リソースの乏しい言語や特定のドメインによってはアノテーションを行うのに専門家が必要となるため、大きな課題となっている。
また、言語の曖昧さのためアノテーションの品質と一貫性の課題がある。 同じ単語でも違うラベル付けがされていることがある。 例えば、以下の文で考える。
Baltimore de feated the Yankees
上記の文章中の「Baltimore」は、MUC-7ではLocation、CoNLL03ではOrganizationとラベル付けされている。
他にもEmpire StateとEmpire State Buildingは、エンティティの境界が曖昧なためCoNLL03とACEのデータセットでは同じLocationとラベル付けされている。
informalなテキストへの対応
ニュース記事のような正式な文書ではまずまずの結果が報告されているが、ユーザが生成するテキストではF値は40%程度となっている。
informalなテキスト（ツイート、 コメント、ユーザフォーラムなど）の固有表現認識は文が短いこととノイズが多いことから現状は難しいと考えられている。
現時点（2021/6/26）だとF値60.45がSOTAとなっている。
5.2 将来の方向性
NERの細粒度と境界検出
細粒度NERではラベル数の大幅な増加により複数のラベルタイプをつける必要があり、複雑さの課題がある。 このことからB-I-E-SとOをdecodeタグとして使用することでエンティティの境界とラベルを同時に検出するようなNERのアプローチを考える必要がある。
NERとEntity linking(EL)の統合
既存研究ではNERとEntity linking(EL)は別々のタスクとして扱われている。 NERとEL、エンティティの境界検出、エンティティのリンク、エンティティタイプの分類をうまく組み合わせることで各タスクが他のタスクの部分的な出力から恩恵を受けることができ、エラーの伝播を軽減できるのではないか。
informalなテキストにおけるDeep learningベースのNER
informalなテキストでのNERのパフォーマンスはまだまだ低い結果となっている。 ユーザが生成するテキストの辞書を補助リソースとして活用していくことがパフォーマンスを上げることにつながる。 辞書をどのように取得するか、どのように組み込んでいくかが課題となる。
スケーラビリティ
データのサイズが大きくなった時のパラメータの指数関数的な増加を最適化するための仕組みが必要である。 例えば、ELMoは各単語を3 × 1024次元のベクトルで表現し、32GPUで5週間の学習、Google BERTは64個のCrowd TPUで学習が必要である。 エンドユーザがこういった強力なコンピューティングリソースにアクセスするのは難しい。 今後モデルの学習に必要な計算時間を削減するためにモデルの圧縮や枝刈り等の技術も必要になる。
転移学習
あるデータセットで学習したモデルは言語の特性やアノテーションの違い等により他のテキストへ転用した際にうまく動作しないことがある。NERに深層学習の転移学習を行う研究はいくつかあるが、まだ十分に検討されていない。
今後は以下のような研究課題に取り組む必要があると考える。
- あるドメイン領域から異なるドメイン領域への効率的に知識を転移すること
- NERタスクでのzero-shot学習, one-shot学習, few-shot学習の研究
- クロスドメインでのドメインミスマッチとラベルミスマッチへの対処
ツールの整備
データ処理、入力表現、context encoder、tag decoder、有効性の測定などを備えたツールは開発者をサポートすることができると考える。このようなツールができれば専門家に限らず一般の人にも有益であると考える。
タグの階層を使って異なるタグセットを活用する固有表現認識
ACL 2019の論文。
概要
異なるデータセットに出現するタグセットからタグの階層を人手で定義して、その階層構造をNERに利用する。
ベースラインモデルはneural NER(Lample et al.2016)
ベースライン1(M_Concat)：全ての学習データの連結→粒度が異なるタグも一緒になってしまう問題がある（例） City vs. Address
ベースライン2(M_Indep)：セパレートモデル→各タグで学習し、2つのモデルを作成。最終的な2つのモデルの出力を統合する必要がある。
ベースライン3(M_MTL)：マルチタスキング→テキスト表現を共有し、タスク毎に適用できる。こちらも最終的なモデルの結果を統合する必要がある。
提案手法
M_Hier：タグの階層性を用いることで上記のベースラインのモデルの課題を解決する。
提案手法では一番粒度の小さいFine-grainedタグのみを推測する。出力をタグセットに応じて変換する。例えば、Streetを推測した場合はタグセットに応じてLocationへ変換する
結果
医療用データセットI2B2'06とI2B2'14で学習。
F1-scoreで評価。結果としてM_Hierがどちらのデータセットでも良い結果となった。また、Physioでは一番良い精度となった。
ベースラインはいずれもコリジョンが起きたため、精度が落ちたと考えられる。
参考
HuggingFace Transformers Course（1章）
2017年に「[1706.03762] Attention Is All You Need」が出されて以降、Transformer(パーツはAttention)を使った手法が現在の自然言語処理の主流の手法となっている。 Transformerの実装ではHugging Faceのライブラリを使うことが多いのでこの機会に体形立てて学習しておくと良いだろう。 オンラインコースの参考になった部分について紹介していく。 各章の最後には章の内容に関するクイズがあるので理解を深めることができる。
1章 : Transformer models
1章はTransformerモデルの説明が書かれている。
NLP(Natural Language Processing)とは何かというところからNLPで解決したい各タスクに対してTransformersライブラリのpipelineを使ったコードとともに記載されている。
例えば、以下のようなタスクに対して適用できる。
- 特徴選択 : feature-extraction (get the vector representation of a text)
- マスク当て : fill-mask
- 固有表現抽出 : ner (named entity recognition)
- 質問応答 : question-answering
- 感情分析 : sentiment-analysis
- 文章要約 : summarization
- 文章生成 : text-generation
- 翻訳 : translation
- ゼロショット分類 : zero-shot-classification
Tranformerの歴史
Transformerの歴史の図
Transformerモデルは以下のような3つの種類に分けることができる。
- GPT-like(auto-regressive)
- BERT-like(auto-encoding)
- BART/T5-like(sequence-to-sequence)
GPT-likeのモデルはTransformerのDecoderを用いている。 文章生成のような生成タスクにおいてDecoderを使うと良い。
BERT-likeのモデルはTransformerのEncoderを用いている。 BERT-baseは12層のTransformerのEncoder部分(BertLayerモジュール)を使っている。 文章分類や固有表現抽出のようなインプットの理解が必要なタスクに使うと良い。
BART/T5-likeのモデルはTransformerのEncoder-Decoderの両方を用いている。 翻訳や文章要約のようなインプットを必要とする生成タスクではEncoder-Decoderの両方を用いる
以下の表がモデルと例、タスクを整理しておりわかりやすい。
EncoderとDecoder
Encoderは図の左の部分、Decoderは図の右の部分。
オリジナルのTransformerのアーキテクチャの図は以下。
ACMの会員ならオライリー本が読み放題
2021年6月2日
毎日発信の難しさ
早速、昨日は何もかけなかった。ブログで毎日何かしらのことを書こうと思うと難しい。 会社だと日報形式でその日やった仕事のことを書けるが、それ以外の日常生活で１日の中で何かやったのかと思うと何もやっていない。
ちょっとしたミスで時間をロスするのがもったいない
最近はちょっとしたミスで時間をロスすることが多い。 例えば、pythonのコードを実行するシェルスクリプトを書いて標準出力としてリダイレクトしたい場合 ファイルがないとなぜか怒られる→引数が3個だから多すぎる? pythonのコマンドラインって長さに制限がある?
結局は標準出力先の途中のディレクトリが存在していなかったり。。
他にはgit pushしようとしたけど、pushできない。
結局は本来とは違うディレクトリからpushしようとしていたり。。
結論としては単純ミスだけど、そこに至るまでの課程が悪いのかな、切り分け力が落ちているのかもしれない。
