--- title: Tokenizer description: " トークナイザーについて。 何千年も言葉を使ってきたのに、どうして「こちらへきて、これをみてください」といったように頻繁に使われる言い回しが、一つの単語に縮約されないのだろう？　もっと短い「こきこ見なさい」という言葉になってもよさそうなものだ。 Metamagical Themas p.452 " date: 2026-05-25T03:27:39.279Z updated: 2026-05-25T03:27:39.279Z url: https://baku89.com/Tokenizer --- # Tokenizer ![](https://wp.baku89.com/wp-content/uploads/2026/05/Tokenizer-1779681807341.png) トークナイザーについて。 > 何千年も言葉を使ってきたのに、どうして「こちらへきて、これをみてください」といったように頻繁に使われる言い回しが、一つの単語に縮約されないのだろう？　もっと短い「こきこ見なさい」という言葉になってもよさそうなものだ。\ > _[Metamagical Themas](/Metamagical_Themas) p.452_ → 津軽弁の「け」\ → [Novelfo](/Novelfo) [GitHub - openai/tiktoken: tiktoken is a fast BPE tokeniser for use with OpenAI's models.](https://github.com/openai/tiktoken) - [企業詩生成](/corporate-poetry-generator)の実装において、語句解析をやってるうちに、LLMのトークナイザーのことが気になってきた。 - 新しいモデルほど、トークン種が増えて「ありがとうございます」が1トークンになってる - 「郡」のような出現率の低いマルチバイトUnicodeは2トークン扱いされてる - 郡は `E9 83 A1` だが、どこで区切られているのか気になる - 恐らくただのバイト列を縮約するだけ - 「君 + 阝」のように部首で分割されると思いきや…… - つまり、漢字の表意性はOpenAIのtokenizerにおいてはあまり汲んでもらえない - しいていうなら、同じ部首の漢字はテーブル上でも近傍にあるから、上位バイトが一致する = 同じトークンに前置される - 言語格差。というよりも、エンコード方式格差 - もしかしたらハングルとかは、部首をペアにすることでエンコードするとかになってたりする？（調べる） - そういうエンコード方法にノーマライズすることによって、より漢字圏のトークナイズ精度を高めることができたりしないかな? - [漢字構成記述文字 (Unicodeのブロック) - Wikipedia](https://ja.wikipedia.org/wiki/%E6%BC%A2%E5%AD%97%E6%A7%8B%E6%88%90%E8%A8%98%E8%BF%B0%E6%96%87%E5%AD%97_\(Unicode%E3%81%AE%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF\)) ## 頻出文字列圧縮 「言ってることがありきたりすぎて情報量がない」を定式化できる気がする 「コーパス全体を`0x0`という1ビットに符号化する」といった過学習を起こさないためには、「モデル自体のサイズ + モデル下のビット長」を損失関数にすればいい。 いうなれば、冒頭のホフスタッターの問いは、「そうした縮約が登場しないのは、それだけトークン種が増え、人の脳内の語彙のルックアップテーブルが肥大化することで、縮約による圧縮効果を打ち消してしまうから」と答えることができる けど、ある意味「作品タイトル」というのは「巨大な文字列を数トークンに圧縮する」ものといっていいのかも。ただし、タイトルは内容の伝達には使えず、その作品を通った人 = 作品タイトル → 本文の意味 のルックアップテーブルを脳内に構築できた人にとって、作品についての言及を数トークンで終えることができる という圧縮効果がある - Haffman符号化 → [Perplexity](/Perplexity)