["G", "o", "o", "g", "l", "e"]これにより2つの複合的な問題が発生します。
結果として、難解な哲学を語り、プログラムを書けるAIが、簡単なスペリングアウト(文字の書き出し)では推測に頼らざるを得ず、「poop(うんち)には"r"が正確に1つ含まれている」といった、もっともらしいが誤った答えを生成してしまうのです 。
直感的な解決策は、トークン化をやめて、文字(Character)やバイト(Byte)単位で直接テキストを処理させることです。実際に、生のバイト列を直接扱うByT5のようなモデルも存在します。しかし、これが広く採用されていないのは、計算コストが劇的に増大するからです。
純粋な文字レベル処理に移行すると、AIが処理するテキストのシーケンス長が推定で3倍から5倍に膨れ上がります。これは計算負荷の増大に直結し、モデルが文脈や長期的な依存関係を学習するのを著しく困難にします。サブワードによるトークン化は、現代のLLMを実用可能にした、まさに「効率性とのトレードオフ」の産物なのです 。
多くの研究者は、「完璧なトークナイザー」はおそらく存在しないという見解で一致しています。トークナイザーは「非一意なエンコーディングを日常的に生成」し、アーキテクチャに深く根差した「表現のミスマッチ」を引き起こします。これは単にパッチを当てて修正できるバグではないのです 。文字レベルの正確さと、意味的な流暢さの間のトレードオフは、Transformer アーキテクチャにとって根本的なものだと言えるでしょう。
GoogleのAIがスペルを間違えるという現象は、LLMのより深い構造的限界を浮き彫りにしています。
自社名すら正しく綴れないAI。これは非常に恥ずかしい失態に見えますが、AI業界がパニックに陥らないのは、LLMの巨大な価値が別のところにあるからです。
文章の流暢な生成、要約、推論、翻訳、コード作成といった高度な能力は、LLMが意味レベルでテキストを扱えるからこそ実現されています。このレベルにおいては、トークンによる抽象化は「バグ」ではなく、むしろ**効率的な処理を可能にする「機能」**なのです 。文字レベルの正確さは、これらのアーキテクチャが最適化するために設計された対象ではありません。
実務的な回避策は、スペルや文字数カウントのクエリを、LLMに処理させるのではなく、従来型のルールベースのソフトウェアに迂回させることです。すでに一部のAI Overviewの実装では、そのようなクエリを検出して回避しようと試みていますが、2026年5月に大きく報道された失敗例は、その検出自体がまだ不完全であることを示しています 。ある研究によると、GoogleのAI Overviewsは、スペルを逆順にするクエリの52%で誤った回答をし、3音節以上の単語だと正答率はわずか10%でした
。
Googleは現在、この具体的な文字カウント問題の修正に取り組んでいます 。しかし、この「トークン化」のトレードオフを理解する者にとって、本当の教訓は「Googleがバグのある製品をリリースした」ことではありません。
それは、現在のAI革命を支えるアーキテクチャが、根本的な盲点を抱えており、LLMを価値あるものにしている中核機能を犠牲にすることなく、その盲点を解消する方法を、誰もまだ見つけられていないという現実なのです。
Comments
0 comments