Tokenizer

トークナイザーについて。

何千年も言葉を使ってきたのに、どうして「こちらへきて、これをみてください」といったように頻繁に使われる言い回しが、一つの単語に縮約されないのだろう？　もっと短い「こきこ見なさい」という言葉になってもよさそうなものだ。
Metamagical Themas p.452

→ 津軽弁の「け」
→ Novelfo

GitHub - openai/tiktoken: tiktoken is a fast BPE tokeniser for use with OpenAI's models.tiktoken is a fast BPE tokeniser for use with OpenAI's models. - openai/tiktoken github.com

https://platform.openai.com/tokenizer

  • 企業詩生成の実装において、語句解析をやってるうちに、LLMのトークナイザーのことが気になってきた。
  • 新しいモデルほど、トークン種が増えて「ありがとうございます」が1トークンになってる
  • 「郡」のような出現率の低いマルチバイトUnicodeは2トークン扱いされてる
    • 郡は E9 83 A1 だが、どこで区切られているのか気になる
    • 恐らくただのバイト列を縮約するだけ
    • 「君 + 阝」のように部首で分割されると思いきや……
    • つまり、漢字の表意性はOpenAIのtokenizerにおいてはあまり汲んでもらえない
    • しいていうなら、同じ部首の漢字はテーブル上でも近傍にあるから、上位バイトが一致する = 同じトークンに前置される
    • 言語格差。というよりも、エンコード方式格差
    • もしかしたらハングルとかは、部首をペアにすることでエンコードするとかになってたりする？（調べる）
    • そういうエンコード方法にノーマライズすることによって、より漢字圏のトークナイズ精度を高めることができたりしないかな?
    • 漢字構成記述文字 (Unicodeのブロック) - Wikipedia

頻出文字列圧縮

「言ってることがありきたりすぎて情報量がない」を定式化できる気がする

「コーパス全体を0x0という1ビットに符号化する」といった過学習を起こさないためには、「モデル自体のサイズ + モデル下のビット長」を損失関数にすればいい。

いうなれば、冒頭のホフスタッターの問いは、「そうした縮約が登場しないのは、それだけトークン種が増え、人の脳内の語彙のルックアップテーブルが肥大化することで、縮約による圧縮効果を打ち消してしまうから」と答えることができる

けど、ある意味「作品タイトル」というのは「巨大な文字列を数トークンに圧縮する」ものといっていいのかも。ただし、タイトルは内容の伝達には使えず、その作品を通った人 = 作品タイトル → 本文の意味 のルックアップテーブルを脳内に構築できた人にとって、作品についての言及を数トークンで終えることができる という圧縮効果がある

  • Haffman符号化

→ Perplexity