HuggingFace Tokenizers 0.10 : コンポーネント (python)

by

HuggingFace Tokenizers 0.10 : コンポーネント (python) (翻訳/解説)
翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 06/05/2021 (Python v0.10.2)

* 本ページは、HuggingFace Tokenizers の以下のドキュメントを翻訳した上で適宜、補足説明したものです：

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

★ 無料 Web セミナー開催中 ★ クラスキャット主催 人工知能 & ビジネス Web セミナー

人工知能とビジネスをテーマに WEB セミナーを定期的に開催しています。
スケジュールは弊社 公式 Web サイト でご確認頂けます。
  • お住まいの地域に関係なく Web ブラウザからご参加頂けます。事前登録 が必要ですのでご注意ください。
  • ウェビナー運用には弊社製品「ClassCat® Webinar」を利用しています。
クラスキャットは人工知能・テレワークに関する各種サービスを提供しております :

人工知能研究開発支援 人工知能研修サービス テレワーク & オンライン授業を支援
PoC(概念実証)を失敗させないための支援 (本支援はセミナーに参加しアンケートに回答した方を対象としています。)

◆ お問合せ : 本件に関するお問い合わせ先は下記までお願いいたします。

株式会社クラスキャット セールス・マーケティング本部 セールス・インフォメーション
E-Mail：sales-info@classcat.com  ;  WebSite: https://www.classcat.com/  ;  Facebook

 

HuggingFace Tokenizers : コンポーネント (python)

トークナイザーを構築するとき、その動作をカスタマイズするためにこのトークナイザーに様々なタイプのコンポーネントをアタッチできます。このページは殆どの提供されるコンポーネントをリストアップします。

 

Normalizers

Normalizer は入力文字列を特定のユースケースに適するものとしてそれを正規化するための前処理を担当します。正規化の幾つかの一般的な例は Unicode 正規化アルゴリズム (NFD, NFKD, NFC & NFKC)、小文字化 etc… です。トークナイザーの特異性は正規化中にアラインメントを追跡することです。これは生成されたトークンを入力テキストにマップし戻すことを可能にするために必須です。

正規化はオプションです。

名前 説明 例
NFD NFD unicode 正規化
NFKD NFKD unicode 正規化
NFC NFC unicode 正規化
NKFC NKFC unicode 正規化
Lowercase 総ての大文字を小文字に置き換える 入力: HELLO ὈΔΥΣΣΕΎΣ
出力: hello ὀδυσσεύς
Strip 入力の指定されたサイド (左、右 or 両者) の総ての空白文字を除去します 入力: ” hi “
出力: “hi”
StripAccents ユニコードの総てのアクセント記号を除去します (一貫性のために NFD とともに利用されます) 入力: é
出力: e
Replace カスタム文字列 or regexp を置き換えてそれを与えれた内容で変更します Replace(“a”, “e”) はこのように動作します :
入力: “banana” 出力: “benene”
BertNormalizer オリジナル BERT で使用された Normalizer の実装を提供します。設定可能なオプションは :

  • clean_text
  • handle_chinese_chars
  • strip_accents
  • lowercase
Sequence 複数の normalizer を構成します、これは提供された順序で実行されます Sequence([NFKC(), Lowercase()])

 

事前トークナイザー

PreTokenizer はルールのセットに従って入力を分割する処理をします。この前処理は基礎的なモデルが複数の「分割」に渡りトークンを構築しないことを確実にさせます。例えばトークン内に空白を持つことを望まない場合、これらの空白上で分割する PreTokenizer を持つことができます。

Sequence を使用して複数の PreTokenizer を容易に一緒に組み合わせることができます (下参照)。PreTokenizer はまた丁度 Normalizer が行なうように、文字列を変更することを許容されています。これは正規化の前に分割することが必要な幾つかの複雑なアルゴリズム (e.g. ByteLevel) を可能にするために必要です。

名前 説明 例
ByteLevel 総てのバイトを可視な文字のセットに再マッピングしながら空白上で分割します。このテクニックは OpenAI により GPT-2 で導入されて幾つかの多かれ少なかれ良い特性を持ちます :

  • それはバイト上にマップしますので、130,000+ ユニコード文字とは対照的に、これを使用するトークナイザーは初期アルファベットとして 256 文字 (バイトが持てる値の数) を必要とするだけです。
  • 前のポイントの結果は、これを使用して未知のトークンを持つ必要がまったくないことです、何故ならば 256 トークンで任意のものを表せるからです (Youhou!! 🎉🎉)
  • 非アスキー文字については、それは完全に可読ではなくなりますが、それでもそれは動作します！
入力: “Hello my friend, how are you?”
出力: “Hello”, “Ġmy”, Ġfriend”, “,”, “Ġhow”, “Ġare”, “Ġyou”, “?”
Whitespace 単語境界上で分割する (次の正規表現を使用します: \w+|[^\w\s]+) 入力: “Hello there!”
出力: “Hello”, “there”, “!”
WhitespaceSplit 任意の空白文字上で分割する 入力: “Hello there!”
出力: “Hello”, “there!”
Punctuation 総ての句読点文字を分離します 入力: “Hello?”
出力: “Hello”, “?”
Metaspace 空白上で分割してそれらを特殊文字 “▁” (U+2581) で置き換えます 入力: “Hello there”
出力: “Hello”, “▁there”
CharDelimiterSplit 指定された文字上で分割します x による例:
入力: “Helloxthere”
出力: “Hello”, “there”
Digits 任意の他の文字から数字を分ける 入力: “Hello123there”
出力: `”Hello”, “123”, “there”`
Split 多目的な事前トークナイザーで、提供されたパターン上と提供された動作に従って分割します。パターンは必要であれば反対にできます。

  • pattern はカスタム文字列か regexp であるべきです。
  • behavior は次の一つであるべきです :
    • removed
    • isolated
    • merged_with_previous
    • merged_with_next
    • contiguous
  • invert はブーリアン・フラグであるべきです。
pattern = ” “, behavior = “isolated”, invert = False による例:
入力: “Hello, how are you?”
出力: `”Hello,”, ” “, “how”, ” “, “are”, ” “, “you?”
Sequence 指定された順序で実行される複数の PreTokenizer を組合せます Sequence([Punctuation(), WhitespaceSplit()])

 

モデル

モデルは実際にトークン化するために使用される中心的なアルゴリズムです、そして従って、それらはトークナイザーの唯一の必須ののコンポーネントです。

名前 説明
WordLevel これは「古典的な」トークン化アルゴリズムです。それはどのような創造 (= fancy) もなく単語を ID に単純にマップさせます。これは利用し理解するために実際に単純であるという優位点を持ちますが、良い被覆率 (= coverage) のためには非常に大規模な語彙を必要とします。
このモデルの利用は PreTokenizer の利用を必要とします。このモデルによりどのような選択も直接なされません、それは単純に入力トークンを ID にマップします。
BPE 最もポピュラーなサブワード・トークン化アルゴリズムの一つです。Byte-Pair-Encoding は文字から始めて、最も頻繁に一緒に見られるそれらをマージしながら新しいトークンを作成することにより動作します。そしてそれは語彙で見る最も頻度の高いペアから新しいトークンを構築するように反復的に動作します。
BPE は複数のサブワード・トークンを使用してそれが決して見ていない単語を構築することができるため、”unk” (unknown) トークンのより少ない機会とともに、より小さい語彙を必要とするだけです。
WordPiece これは BERT のようなモデルで Google により主として使用された、BPE に非常に類似したサブワード・トークン化アルゴリズムです。それは greedy アルゴリズムを使用します、これは最初に長い単語を構築しようとし、単語全体が語彙に存在しないとき複数のトークンに分割します。これは文字から始めて、できる限り大きいトークンを構築する、BPE とは異なります。
それは単語の一部である (i.e. 単語を開始しない) トークンを識別するために有名な ## prefix を使用します。
Unigram Unigram はまたサブワード・トークン化アルゴリズムで、指定されたセンテンスのための確率を最大化するようにサブワード・トークンの最善のセットを特定しようとすることで動作します。これは逐次的に適用されるルールのセットに基づく決定論的ではない方法で BPE とは異なります。代わりに Unigram は最も確率の高いものを選択しながら、トークン化の複数の方法を計算することができます。

 

PostProcessor

パイプライン全体の後、時にトークン化された文字列をモデルに供給する前に “[CLS] My horse is amazing [SEP]” のように幾つかの特殊なトークンを挿入することを望みます。PostProcessor は丁度それを行なうコンポーネントです。

名前 説明 例
TemplateProcessing 後処理を容易にテンプレート化し、特殊トークンを追加し、そして各シークエンス/特殊トークンのために type_id を指定させましょう。テンプレートは単一シークエンスとシークエンスのペアを表す 2 つの文字列、そして使用する特殊トークンのセットが与えられます。 これらの値を持つテンプレートを指定するときの例 :
single: “[CLS] $A [SEP]”
pair: “[CLS] $A [SEP] $B [SEP]”
特殊トークン:

  • “[CLS]”
  • “[SEP]”

入力: (“I like this”, “but not this”)
出力: “[CLS] I like this [SEP] but not this [SEP]”

 

デコーダ

デコーダはトークナイザーで使用された ID から、どのようにテキストの可読なピースに戻すかを知っています。幾つかの Normalizer と PreTokenizer は例えば戻されるべき特殊文字や識別子を使用します。

名前 説明
ByteLevel ByteLevel PreTokenizer を元に戻します。PreTokenizer は各バイトを表すために可視な Unicode 文字のセットを使用し、バイトレベルでエンコードしますので、このプロセスを反対にして可読なものを再度得るためにデコーダを必要とします。
Metaspace Metaspace PreTokenizer を元に戻します。この PreTokenizer は空白を識別するために特殊な識別子 ▁ を使用しますので、このデコーダはこれらをデコードするのに役立ちます。
WordPiece WordPiece モデルを元に戻します。このモデルはサブワードを続けるために特殊な識別子 ## を使用しますので、このデコーダはこれらをデコードするのに役立ちます。

 

以上