Token
読み: トークン
トークンとはAI課金と処理の単位
Tokenは大規模言語モデルがテキストを理解し生成するために用いる最小の処理単位である。文字や単語そのものとは異なり、AI特有のアルゴリズムによって分割される。API利用時の課金基準や、一度に処理できる情報量の上限を決定づける極めて実務的な指標である。
かんたんに言うと
食材を調理しやすい大きさに切り分ける際の一口サイズのブロック。ステーキ肉をそのまま飲み込めないように、AIもテキストを細かく刻まなければ消化できない。
文字数でも単語数でもないLLM独自の処理単位Token
Tokenは文字数でも単語数でもない。AIがテキストを処理する際の独自の分割単位である。
法務部門で契約書レビューのシステムを組む際、単純な文字数でAPIの予算を組むと痛い目を見る。人間にとっては1000文字の文章でも、AIの目には全く異なる数のブロックとして映っているからである。自然言語処理の根幹を成すこの概念を無視してシステム設計を進めると、本番稼働後に想定外の請求書を突きつけられることになる。コスト計算の土台として、まずはこの単位の性質を直感的に掴む必要がある。
日本語処理におけるByte-Pair Encodingの罠
OpenAIのtiktokenで計算してみれば一目瞭然である。英語なら1単語がほぼ1Tokenに収まることが多い。しかし日本語はひらがなや漢字の複雑な組み合わせにより、細かく分割される傾向がある。
「損害賠償」という4文字が複数Tokenを容赦なく消費する。経理部門の膨大な日本語の請求データを処理させると、英語圏の事例の数倍のコストが飛んでいく。Byte-Pair Encodingという仕組み上避けられない事象である。この言語によるエンコーディングの格差は、予算を握る事業部を説得する上で非常に悩ましい。
主要モデルの消費傾向と実運用
実際にAPIを叩いてみるとモデルごとに消費の癖がある。GPT-4oは賢いが、プロンプトの往復でみるみるTokenが溶ける。Claude 3.5 Sonnetは長文の読み込みに強いが、出力の長さには明確な上限がある。
Gemini 1.5 Proは100万Token以上の入力を受け付ける。人事部門で過去10年分の就業規則改定履歴を丸ごと投げ込むような荒業ができるのはGeminiくらいである。
ただ、全部読ませれば正解が出るわけではない。大量のテキストを処理できるからといって、思考の質まで担保されるわけではないのである。
詰め込みすぎが引き起こす記憶喪失
コンテキストウィンドウの上限までTokenを詰め込むと何が起きるか。
途中の情報を忘れるのである。
Lost in the Middleと呼ばれる現象である。法務のデューデリジェンスで数百ページの報告書を一度に処理させると、肝心な中盤のリスク条項を見落とす。これがハルシネーションの温床になる。処理速度も極端に落ちるため、ユーザーの待ち時間は増大する。精度と速度のトレードオフをどこで着地させるか、現場のエンジニアの判断が分かれるところである。
RAGによる入力制限の回避とAPI予算の最適化
だからこそ、全データをプロンプトに突っ込む力技は早々に捨てるべきである。ベクトルデータベースを使ったRAGを組む。ユーザーの質問に関連する社内規程だけを検索し、必要な数千TokenだけをLLMに渡す。
これならAPIの従量課金も抑えられる。モデルの選定も適材適所である。単純な経費精算データの分類なら軽量モデルで十分機能する。無駄なTokenを削ぎ落とし、いかにスリムな入力を維持するか。この泥臭いチューニングこそが、システムの寿命を決める。
当社の見解
自然言語処理は英語中心で発展してきた技術だ。日本語で使うと、英語では起きない問題に頻繁にぶつかる。このAI用語集1,500ページを日本語で生成・運用する中で経験したのは、トークン化の方式によって出力品質が大きく変わること。英語のベンチマークで高得点のモデルが、日本語では使い物にならないケースがある。日本語で使うなら、日本語で検証してから選ぶべきだ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。