GENZITSU / UsefulMaterials

34 stars 0 forks source link

weekly useful materials - 01/11 - #84

Open GENZITSU opened 2 years ago

GENZITSU commented 2 years ago

StackOverflowからのコピペをやめろ。今すぐにだ。

ネット上のコードをコピペすると、目には見えない制御文字が入ってることがあるので危険と言う旨が書かれている。

対策としては以下が推奨されている。

  • インタプリタ、Unicode対応コンパイラ等は、文字列リテラルやコメントに、終端の無い文字順序制御文字が含まれていた場合に警告やエラーを出さなければなりません(MUST)。
  • 終端の無い文字順序制御文字は、言語要件で明示的に禁止されるべき(SHOULD)です。
  • コードエディタ等では、制御文字を視覚的に強調表示すべき(SHOULD)です。

vscode使いであれば、Gremlins tracker for Visual Studio Codeと言う拡張機能や、設定で以下を行うなどの対策が取れるとのこと

editor.unicodeHighlight.invisibleCharacter を true(default) にすることで有効化されます。 初期設定だと表示されすぎて煩わしいという場合には editor.unicodeHighlight.allowedCharactors から設定できるようです。

スクリーンショット 2021-12-29 22 18 36

コメント

こわい

出典

元記事

GENZITSU commented 2 years ago

HITLに沿ったアノテーション 戦略

アノテーションの戦略ってのがあるんか。
ランダム:10%
モデルの予測スコアが50%くらいのもの:80%
外れ値:10%
みたいな方針が大事らしい。参考になるわ考えている顔

コメント

参考になる。

出典

元記事

GENZITSU commented 2 years ago

特定の属性を持ったキャラクターのプロフィールを生成する

T5を利用した、キャラクター属性の入力に対してプロフィール文を生成するAIの作成記録が紹介されている。

以下は気になったテク

属性語の自動抽出

相対出現比率 = (単語の総出現回数)/(単語の出現する作品数) という謎の数値を設定し、出現作品数が5以上でかつ、総出現回数が10以上、相対出現比率は10以下の名詞に限定するとなんとなく属性語っぽいのが取れるだろうという職人技的な決定方法で、属性語を抽出しました。

属性語の例は以下です。 高校生 凪 画家 学業 仕事 日数 留年 人

属性語は全部教えるとヒントが多すぎるのでランダムに6割除去して学習させました。 また、一つの作品にしか出ていないものは固有表現【人名】に置換しました。(人名じゃない可能性もあります。後これは結果的にはやらなくても良かった気がします)

生成例

属性語: 野山 親 女子 プロ 眠り 森 荊 道 女王 生成プロフィール文: 野山で親に捨てられた女子大生。プロポーズされた【人名】を「眠りの森」に連れて行くが、その正体は荊の道の女王であった。 正解プロフィール文: 野山野家長女。イッキ達の親のような存在。女子プロで活躍。元「眠りの森」で「荊の道」の女王。

属性語の拡張 下図のように、属性語のトピックモデルを作成しておき、入力の属性語から混合トピックモデルを推定し、単語分布から拡張語をサンプリングする。

スクリーンショット 2022-01-04 22 24 57

これを用いたときの生成例

スクリーンショット 2022-01-04 22 26 12

コメント

トピックモデルを利用した属性語の拡張というアプローチが面白い。

出典

元記事

コード

GENZITSU commented 2 years ago

Pytorchのtensorが占有しているGPUのメモリを開放する方法

pytorchではgpuに転送した変数をdelしてもメモリが確保されているので、delした後にtorch.cuda.empty_cache()を叩く必要がある。

コメント

メモ

出典

元記事

GENZITSU commented 2 years ago

Jupyter でPandas DataFrame 内部に画像をURLから参照して表示させる

表題の処理を以下のようなコードで実現することができるとのこと。 df.to_html & escape=False & 画像用のformatterが大事。

import pandas as pd
from IPython.display import HTML

# NOTE: https://www.irasutoya.com/2021/01/onepiece.html から画像を参照
onepiece = {
    "モンキー・D・ルフィ" : "https://1.bp.blogspot.com/-uxIsaN0S5lQ/X-FcrvAAInI/AAAAAAABdD4/6uw_qNUh9dQrG0aUzIExybt84yTEmXOPwCNcBGAsYHQ/s200/onepiece01_luffy.png",
    "ロロノア・ゾロ" : "https://1.bp.blogspot.com/-rzRcgoXDqEg/YAOTCKoCpPI/AAAAAAABdOI/5Bl3_zhOxm07TUGzW8_83cXMOT9yy1VJwCNcBGAsYHQ/s200/onepiece02_zoro_bandana.png",
    "ナミ" : "https://1.bp.blogspot.com/-2ut_UQv3iss/X-Fcs_0oAII/AAAAAAABdD8/jrCZTd_xK-Y6CP1KwOtT_LpEpjp-1nvxgCNcBGAsYHQ/s200/onepiece03_nami.png",
    "そげキング(ウソップ)" : "https://1.bp.blogspot.com/-mZpzgXC1Sxk/YAOTCAKwWTI/AAAAAAABdOM/5B4hXli0KLU5N-BySHgjVbhZscKLSE-bQCNcBGAsYHQ/s200/onepiece04_usopp_sogeking.png",

}

df = pd.DataFrame({"Name": onepiece.keys(),
                   "Image": onepiece.values()})

def path_to_image_html(path):
    return f'<img src="{path}"/>'

pd.set_option('display.max_colwidth', None)
HTML(df.to_html(escape=False ,formatters=dict(Image=path_to_image_html)))

コメント

簡易的なレポーティングの運用をするときに使えそう。

出典

元記事

GENZITSU commented 2 years ago

米不動産テック大手Zillowの大失敗に見るAI経営の教訓…「予測モデルの過信」「目標設定のミス」は他人事ではありません

不動産価格予測AIをもとにしたホームフリッピング事業を展開していたZillowが、コロナ禍により価格予測AIの精度が狂ってい始めていたことに気づかずに、誤ったKPIを猛追してしまったことで、大失敗(570億円の評価減)してしまった事例の紹介。

記事中でためになった部分の抜粋

「ブラックスワン」事態が発生した場合、既存アルゴリズムの使用を停止するなど、瞬時に切り替えられる体制を作っていなければいけません。

予測モデルの精度が変化したときに瞬時に対応できる切り替え可能なモデルを作るだけではなく、業務オペレーションや意思決定がモデルの数字に100%依存しない形で回るよう「モデルになにかあったとしても大丈夫」という、バッファーを持たせることが大事

最近の事例だとテスラ社の自動運転のベータ版配信の一件があります。テスラ社がバージョン10.5を配信した約12時間後に、誤作動を起こすケースがあることをAIが認識。瞬時にバージョン10.5で運転しているユーザーの自動運転機能を遠隔でオフにしました。

うまく動作しないケースがあるという前提条件を知りながら、「AIそのものにオフスイッチを用意しておく」ことも、重要なバックアップの施策です。

コメント

機械学習に携わる人からすれば常識だろうといった感じだが、チームに関わる人全てがこういう認識とは限らないので、日々啓蒙してくことが大事かもしれぬ

出典

元記事

GENZITSU commented 2 years ago

パッチ分割をNumpyで効率的に実施する方法の紹介

ViTなどでよく用いられる画像のパッチ分割をnumpyのstride_tricksを利用して高速化する方法が紹介されている。

パッチ分割は以下のようにfor loopで書くことが可能だが当然遅い。

FISU2WLXIAYetR1

以下のようにstride_tricksを利用すると、高速にパッチの取得が可能になる。

FISr61OXsAY7msX

strideの値に何を指定するべきかは以下の図がわかりやすい。

そもそもnumpyの配列には以下のような属性がある。

stridesというのは配列の一個下or一個右の要素にアクセスする際に何byte分横に移動しなければいけないかを格納しているもので、
itemsizeは各要素が何byteであるかを保存している。 FISWjddWQAUQGGa

これを転用することで、各patch間の上下移動に何byte分の移動が必要で、各patch内の上下移動に何byte分の移動が必要かを計算することで、パッチ分割を高速に行えるようになる。

FISh_zBXsAAeE4W

FIShzvIXEAAyNM5

ちなみにpatch内移動は元々のstridesと同じ値で良い。

FIShzvIXEAAyNM5

これを転用するとRGBのパッチ分割や、overlapを考えたパッチ分割などが可能になる。

FIStgufXEAQOXc9

ただし、この手法は分割する縦横の大きさが既知の場合でないと使えないのでそこは注意が必要。

コメント

このようなテクがあるのをしらなかった。

とは言えやってみると以下のような結果になったので、うーんってかんじ。 2~5倍程度早くなるものの元々結構早い...

スクリーンショット 2022-01-06 23 38 21

スクリーンショット 2022-01-06 23 40 11

出典

元ツイート

GENZITSU commented 2 years ago

Pythonでの開発・CI/CDの私的ベストプラクティス2022

表題の通り、一個一個触れると長くなるので省略するが、以下のようなことをしている。

スクリーンショット 2022-01-06 23 53 31

コメント

メモ

出典

元記事

GENZITSU commented 2 years ago

CNNによる画像分類:背景の影響を低減させる正則化

背景画像の影響を低減させるためのOrthogonal Sphere Regularizationという手法が紹介されている記事。

以下のようなLosで正則化をかけることができる模様。

スクリーンショット 2022-01-07 0 04 14

以下は実装

# from (https://qiita.com/tabintone/items/8f5593bf1083a55c4b72)

import torch.nn.functional as F
from torch import linalg as LA

class CrossEntropyOSLoss(nn.Module):
    def __init__(self, regularization_param):
        super().__init__()
        self.Cross_Entropy_Loss = nn.CrossEntropyLoss()
        self.alpha = regularization_param

    def forward(self, output, representation, target):

        # 通常のクロスエントロピー誤差
        CEL_value = self.Cross_Entropy_Loss(output, target)

        # Orthogonal Sphere Regularization
        normalized_representation = F.normalize(representation, p = 2, dim = 1)
        OS_value = torch.add(
            torch.matmul(torch.t(normalized_representation), normalized_representation), 
            torch.eye(normalized_representation.size()[1], device = device), 
            alpha = -1
        )
        OS_value = self.alpha*LA.norm(OS_value, ord = "fro")

        return CEL_value + OS_value

# 損失関数のインスタンスを生成
alpha = 0.01 # 正則化パラメータ
loss_func = CrossEntropyOSLoss(alpha)

結果を見ると確かに、注目領域が背景から中心に寄っているように見える。

スクリーンショット 2022-01-07 0 05 40

論文曰く、光源や姿勢などの重要な物理的な要素が特徴空間で複雑に絡み合っていると良くないので、それらをできるだけ独立にさせたい的なモチベから生まれたとのこと

CNN models trained using just the regular cross-entropy loss automatically encode different complex interactions between various physical factors like lighting and pose. However, the features learnt are not necessarily constrained or related to basic constraints from imageformation. They also end up being highly correlated especially in the deeper layers of the network. This results in feature redundancy with the final model being highly sensitive to pruning techniques. R

コメント

にわかには信じられないが、機会があれば使ってみたい。

出典

元記事

元論文

GENZITSU commented 2 years ago

prefix tunigをするときのtips

T5 で Prefix-Tuning するときはデコーダにも Prefix を付与するのが正しそう(元論文の BART でもそうなってるのでそれはそうという感じですが…).チュートリアルだと付与しない設定になってるけど,手元のコーパスではこれが有ると無いとでかなり性能に差が出る

fine-tuning に用いるコーパスの target (デコーダ) 側の文書の分布が T5 の事前学習で用いられた文書の分布と似ている場合は decoder 側の Prefix なくてもいいのかもしれない 知らんけど

コメント

メモ

出典

元記事

GENZITSU commented 2 years ago

Data Augmentation in NLP

自然言語処理用Data Augmentationがそれぞれのメリ/デメとともに網羅されている記事。

スクリーンショット 2022-01-07 0 36 50

コメント

有名どころは全部カバーされているので、時折見返してみるといいことありそう。

出典

元記事

GENZITSU commented 2 years ago

使いやすいフリー素材サイト

ちょうどいいイラスト

スクリーンショット 2022-01-07 21 44 23

ソコスト

スクリーンショット 2022-01-07 21 45 45

シルエットデザイン

スクリーンショット 2022-01-07 21 46 28

コメント

メモ

出典

元ツイート

GENZITSU commented 2 years ago

The Illustrated Retrieval Transformer

GPT-3のわずか4%のモデルサイズでGPT-3と同等の性能を達成したという、DeepMindから2021年12月に発表されたRETROの仕組みをイラストを用いて解説しているブログ。

通常の大規模言語モデルは言語情報処理と世界に対する知識の両方を内包しているが、RETROはそこを分離するように作られている。こうすることでモデルは言語情報処理にだけ集中することが可能になり、モデルサイズ / 訓練時間 / 必要GPU数が大幅に改善される。

スクリーンショット 2022-01-08 23 34 07

RETROは以下のようなデータベースを事前に構築することで、推論フェーズに役立てる。

スクリーンショット 2022-01-08 23 39 26

CompletionにはNeighborに続く文章がそのまま入っている。

Neighbor, which is used to compute the key Completion, the continuation of the text in the original document.

このデータベースはweb上のテキストからランダムサンプリングしてきている模様。

The dataset consists of text documents from multiple sources and multiple languages totalling over 5 trillion tokens (detailed in Table 1). Sequences are sampled from subsets of the training data, with sampling weights given in the right-most column of Table 1. We tokenize the dataset using SentencePiece (Kudo and Richardson, 2018) with a vocabulary of 128,000 tokens

スクリーンショット 2022-01-09 10 39 26

RETROはまず、入力文章をBERT(パラメータは固定)に通し、各tokenのembeddingを平均化して、sentence embeddingを取得する。

スクリーンショット 2022-01-08 23 45 06

取得したsentence embeddingを用いて、データベースからサポート文をNearest neighborの要領で2つ選択し、 (実装にはscannを使っている)

スクリーンショット 2022-01-08 23 45 06

入力文章に加えて選択された2つの文を用いて最終的なoutputを得る。

スクリーンショット 2022-01-08 23 45 19

抽出方法は以下の通り

スクリーンショット 2022-01-08 23 48 54 スクリーンショット 2022-01-09 0 14 32 スクリーンショット 2022-01-09 0 15 06

ちなみにモデル & データベースの性能曲線は下図の真ん中のようになり、モデルサイズを固定してもdatabaseのサイズを上げることで性能の向上ができるようになる。(Databaseのサイズがかなりでかいように見えるが...)

With a 2 trillion token database, our Retrieval-Enhanced Transformer (Retro) obtains comparable performance to GPT-3 and Jurassic-1 on the Pile, despite using 25× fewer parameters.

スクリーンショット 2022-01-09 10 33 25

コメント

近年NLP系モデルのモデルサイズは増加の一途を辿っている(GPT-3に関しては185 billion params)が、モデルサイズを抑えながらも性能は向上させられることを示した研究として大きな意味を持ちそう。

とはいえ、結局データベースのサイズは大きめでないといけないので、そのようなデータを持っている企業じゃないとては出せなさそう...

出典

元記事

元論文

GENZITSU commented 2 years ago

model-viewer

web上で3mモデルを表示できるようなライブラリがgoogleから提供されたとのこと

コメント

メモ

出典

元記事

GENZITSU commented 2 years ago

SaaSスタートアップ企業を経営をしていて大失敗した10のことを振り返ってみる

表題の通り

  1. お客様の課題・ペインの解像度が荒いままスタートしてしまった
  2. プロダクトを作りはじめる前にモックアップをお客様に見せるべきだった
  3. MVPとMSPは違うことを知っておくべきだった
    • お客様がお金を払ってでも使いたいと思ってもらえるプロダクトの質に達しているか?はまた別の観点で持っておく必要があります。
  4. 採用で妥協してしまった
    • スキルとスタンス両方がある人の採用はとてもとても大変ですが、この苦しさから逃げてしまうと逃げた分だけ自分にしっぺ返しが来ます
  5. 採用にかける時間が短かった
  6. スキルと報酬のミスマッチがあった
  7. カルチャー作りに注力しなかった
    • カルチャー作りをし、それを言語化する。意外とサボってしまいがちですが、スタートアップは初期から考え始めることをおすすめします。もっと簡単に言えば、どんな人と働きたいか?どんな会社にしたいか?だけでもOKです。少しでも考えておくことであとから思考プロセスをショートカットできることも多かったなと振り返って思いました。
  8. PRをもっと積極的にすればよかった
  9. リードタイムをもっと考慮して売上計画を立てるべきだった
    • 大企業を狙うという戦略は良かったのですが、大企業はとにかくリードタイムが長かった。アポをしてから早くても3ヶ月、通常は6〜12ヶ月ほども検討や稟議でかかることがありました。どうしても予算確保などの動きは小回りが聞かず、自分たちがコントロールできない要因に振り回されることが多くこれが本当に辛かったです。
  10. 料金設定はもっと強気でいくべきだった
    • お客様の課題をしっかり解決していれば多少高くても払ってくれますし、逆に課題解決ができてなくディスカウントのことばかり話す場合はたいてい値段がいくらであってもチャーンする結果になります。
    • 企業向けでかつDXや働き方改革の文脈に乗ることも多かったので、半分SaaS半分コンサル的な動きが特に喜ばれました。コンサル的な動きをするとリソースは取られますが、ARRが上がることと、お客様にべったり伴走できるのでカスタマーサクセスにもなり、課題吸い上げも素早くでき、チャーンリスクも下げやすくなります。

逆にやってみて良かったこと

UXに超こだわったこと お客様にお客様を紹介してもらえた 初期は90%リファラル採用だったけどとても良かった

コメント

メモ

出典

元記事

GENZITSU commented 2 years ago

【書籍メモ】Eelastic leadership - 自己組織化チームの育て方

リーダーに求められる動き方はチームのフェーズによって変化させるべきという筆者の経験から、各フェーズごとにどのようなテクニックが必要かが述べられた「Eelastic leadership - 自己組織化チームの育て方」という本の書評。

チームのリーダーの役割は、優れた優秀な人材が育つのを助けることである。つまりチームメンバーの成長を促進することを指針とし、スキルを身に付けるために新しい事へと挑戦させなくてはいけません。 これは、リーダー自身が問題解決を行うことをやめなければならないということであり、チームの問題をリーダーがすべて解決しているようであれば、ボトルネックはリーダー自身であるとしています ただし、チームに新しいことを学ばせることが常に良いとは限らない。時にチャレンジは理にかなっていない、というのが著者が論じている内容です。

この本ではではチームのフェーズを3つに分割している。

スクリーンショット 2022-01-09 14 53 47

サバイバルモード

チームに学習する時間が十分にない状態であり、この状態をサバイバルモードと定義しています。リーダーの目標はチームが成長するように指導することです。これを達成するためには学ぶ時間を作る必要があります。 このフェーズでの戦略は、ゆとり時間を作るために、指揮統制型のリーダーシップを発揮し、一刻も早くサバイバルフェーズからチームが抜け出すことです。 チームは、火消しに追われている状態であり、現状に対処するための必要スキルを学ぶ時間が十分に持てません。この場合には、チームリーダーがチームに道筋を直接示し、一刻も早くこのフェーズから抜け出すことを目指します。

学習モード

十分なゆとり時間があり、その時間を使って学習や検証を行っている場合、チームは学習モードにいると言えます。ここでのリーダーの目標は、自分たちの問題を自力で解決できるように教え、挑戦させることによってチームを自己組織化チームへ育てることです。

リーダーはコーチ型のリーダーシップを発揮します、チームに意思決定の仕方を教え、仮に学ぶべき教訓がある限りには、チームが誤った決定を下すことも許容します。

ゆとり時間を利用して、新しいスキルを獲得したり、技術的負債を取り除くことを経験のないメンバーと一緒に取組むのがよいでしょう。誤った決定により、火消しが必要になれば、場合によっては柔軟に「指揮統制型」のリーダーに切り替えます。

自己組織化モード

自身がノートPCの電源を切って数日間仕事を放置できる状態であれば、自己組織化フェーズであると言っています。すなわち、チームがリーダーの助けなしに自分たちの問題を解決できるしていける優れた状態であります。

このモードでは、リーダーはファシリテーターとなりその状態を維持することと、現状を処理するチームの能力に注意を払います。コーチがメンバーを立ち止まらせて何かを学ばせるのに対して、ファシリテーターは現状の環境や条件、目的や制約といったものが、チームに適した状態になっているか気を配ります。

ファシリテーターはチームの問題を解決しないが、代わりにチームが自立的に問題解決してくれると信頼します。

このようなフェーズ間の移動を把握するためには「チームの問題とその問題解決に必要な知識とスキル」、「ゆとり時間の量」を適切に把握する必要があるとのこと

コメント

メモ

出典

元記事

GENZITSU commented 2 years ago

facebookresearch / mae

facebook (meta社) からmasked autoencoderのpytorch実装及び、学習済みモデルが公開されている。

学習済みモデルの性能は下記

スクリーンショット 2022-01-09 15 53 26

コメント

メモ

出典

github

GENZITSU commented 2 years ago

john-rocky / CoreML-Models

iosのcore models用の各種学習済みモデルがまとめられているレポジトリ

スクリーンショット 2022-01-09 16 36 29

コメント

スマホにも簡単に機械学習モデルがデプロイできる自体になってきたな...

出典

github

GENZITSU commented 2 years ago

心霊写真もインスタ映え🧁 暗い画像を明るくする機械学習がすごい

GLADNetという露光補正用networkをを試している記事。

以下実行結果の例

スクリーンショット 2022-01-09 17 18 09

こっちはgithubからの転載で、機械学習モデルの前処理に使えるという触れ込み。

スクリーンショット 2022-01-09 17 18 25

コメント

論文自体は2018年のものなので、最近はもっと精度が上がっているかもしれない。

出典

元記事

GLADNetのgithub

GENZITSU commented 2 years ago

退職後にやるべきこと。やった方が良いことをまとめてみました。

FIgbiwUacAEC_vk

その他のtips

仕事辞めたらやるべきこと ①福祉課に行って家賃補助制度の申請をする ②ハロワに行って失業給付金の申請 ③半年間コースの職業訓練校を受験 1,2は順番を間違えると失業給付金しか貰えない。

コメント

いつかのためにメモ

出典

元ツイート①

元ツイート②

GENZITSU commented 2 years ago

NeurIPS2021 outstanding paperのMAUVEを解説

大規模現モデルが生成した文章がどれほど人間が書いた文章に近いかを定量化するMAUVEを解説している記事。

MAUVEでが機械が生成した文章には頻出するが人間が書いた文章にはあまり出てこないテキストと、人間が書いた文章には頻出するが機会が生成した文章には出現しにくいテキストの両方を考慮して、文章生成能力を評価する。

スクリーンショット 2022-01-09 18 26 39 スクリーンショット 2022-01-09 18 26 55

具体的には以下のように定量化を行う。

スクリーンショット 2022-01-09 18 42 28 スクリーンショット 2022-01-09 18 42 33 スクリーンショット 2022-01-09 18 42 39

以下の図では、これまで文章の生成能力の質の評価に用いられてきた代理指標とMAUVEの相関を確認している。

スクリーンショット 2022-01-09 18 45 00

また、文章生成を生成する時に使用するdecodeアルゴリズムの違いによるMAUVEの値も確認している。

MAUVEはgreedy < ancestral < nucleusという理想的な挙動を示していた。

スクリーンショット 2022-01-09 18 47 00

また、人間のアノテーターとの相関も確認。

スクリーンショット 2022-01-09 18 51 05

MAUVEはpypi上にも実装されており、簡単に扱うことが可能

from mauve import compute_mauve 
p_text = ["人間が生成したテキストのリスト'", ...] 
q_text = ["機械生成のテキストのリスト", ...]
result = compute_mauve(p_text=p_text, q_text=q_text) 

コメント

今まで色々な指標が提案されていることを知らかった。GPT-2でembeddingを使っていることを考えると計算量とかちょっと気になる。

出典

元記事

github

GENZITSU commented 2 years ago

DATA SCIENCE: LEAVE GEOPANDAS AND CREATE BEAUTIFUL MAP WITH PYGMT

pygmtというライブラリをつかうと綺麗なマップが生成できるようになるらしい。

スクリーンショット 2022-01-10 22 52 56

コメント

メモ

出典

元記事

GENZITSU commented 2 years ago

speech_analysis_synthesis_PyWORLD.ipynb

「google colab上で音声を録音」して分析合成する例

コメント

メモ

出典

元記事

GENZITSU commented 2 years ago

HRNet / DEKR

This is an official implementation of our CVPR 2021 paper "Bottom-Up Human Pose Estimation Via Disentangled Keypoint Regression"

ということで最新のpose estimationのコードがMITライセンスで公開されている。

こちらのツイートによると、推論速度は数百ミリ秒だが、イラスト系にも使えるらしい。

コメント

メモ

出典

github

GENZITSU commented 2 years ago

BERTでの語彙追加\~add_tokenに気をつけろ!~

BERTでは独自の語彙を追加することで性能が上がることがあるが、普通にadd_tokenをするとtokenize速度が爆裂に遅くなるという罠がある。 (ブログ中では4.4msが320msになっていた)

原因はtokenize関数内で呼ばれている、tokens_trieという関数が、辞書登録された単語かどうかを逐一for文で判定するからである。

def tokenize(self, text: TextInput, **kwargs) -> List[str]:
    ...
    no_split_token = set(self.unique_no_split_tokens)
    tokens = self.tokens_trie.split(text)
    # ["This is something", "<special_token_1>", "  else"]
    for i, token in enumerate(tokens):
        ....
    # ["This is something", "<special_token_1>", "else"]
    tokenized_text = []
    for token in tokens:
        # Need to skip eventual empty (fully stripped) tokens
        if not token:
            continue
        if token in no_split_token:
            tokenized_text.append(token)
        else:
            tokenized_text.extend(self._tokenize(token))
    # ["This", " is", " somet

対応方法

どのようにすれば、速度低下が防げるでしょうか。少し調べてみると、vocab.txtに書き込むという方法があるようです。

以下が実装例

# from https://tech.retrieva.jp/entry/2021/12/27/110000

In [-]: jtk_f = BertJapaneseTokenizer.from_pretrained("cl-tohoku/bert-base-japanese")

In [-]: jtk_f.save_pretrained("./tmp_tk/")
Out[-]:
('./tmp_tk/tokenizer_config.json',
 './tmp_tk/special_tokens_map.json',
 './tmp_tk/vocab.txt',
 './tmp_tk/added_tokens.json')

In [-]: with open("./tmp_tk/vocab.txt", "a") as f:
    ...:     print("航空宇宙産業", file=f)
    ..:

In [-]: jtk_f = BertJapaneseTokenizer("./tmp_tk/vocab.txt", word_tokenizer_type="mecab")

In [-]: print(jtk_f.tokenize(jp_text))
['航空', '宇宙', '産業', '(', 'A', '##ero', '##sp', '##ace', 'Ind', '##ust', '##ry', ')', 'と', 'は', '、', '航空機', 'や', ...]

コメント

こういう挙動があるの知らんかった。てか、学習済みbertに対して後から語彙を追加するみたいなことができたの知らんかった。

出典

元記事