「9.11 > 9.9」から始めるLLMの計算間違い探索

• 
• 
• 
• 

TL;DR

• 強力な主流生成AIサービスでも、簡単な数値比較や計算問題を間違えることがある。
  – これはトークナイゼーションの一部解釈から理解できる部分もあるが、本質的な原因ではない。
• LLMはそもそも数値計算を理解していなく、数値計算をしているのではなく、過去の学習データからそれらしい回答を思い出そうとしているだけと考えられる。
• 正確な数値計算を行う場合、LLMに任せるのではなく、生成AIサービスにプログラムを書かせるのが良い。
  – プロンプトはシンプルに、「プログラムを実行して回答してください」と指示するだけで十分。
• 生成AIをより有効に活用するためには、 「生成AIは何が得意で何が苦手なのか」 を理解し、 「道具として適切に使いこなす」 という姿勢が重要。

問題探索

今回の実験では、複数の主流生成AIサービスを同時に比較できる「天秤AI byGMO」サービス_[1]を利用し、その上で提供されている以下の４つのLLMを対象に実験を行いました。（なお、天秤AIサービスはAPI経由での利用となるため、公式のチャットUIとは挙動が若干異なる場合があることをご注意ください）

• GPT-4o
• Claude 3.5 Sonnet
• Gemini 1.5 Pro
• Llama3 70b Instruct

LLMの生成結果にはランダム性があるため、以下全ての実験は5回程度繰り返して回しました。

9.11と9.9の比較

ではまずは、話題の「9.11」と「9.9」の大小を質問してみました。

結果は以下のように分かれました（図１）:

• Gemini 1.5 Pro: 基本的に毎回正解
• GPT-4o, Claude 3.5 Sonnet: たまに正解するが、基本的には「9.11」の方が大きいと誤答
• Llama3 70b Instruct: 安定して毎回誤答

この結果だけを見ると、Gemini 1.5 Proが一番優れていると思われるかもしれませんが、結論を出すのはまだ早いです。

質問を少し変えてみましょう：

たった小数点前の9を5に変わるだけで、全てのLLMが不正解となりました（図２）。

なぜLLMはこんなにも単純な問題で間違ってしまうのかを探るために、とりあえず言い分を聞いてみました。LLMは自身の思考プロセスを完全に説明できるわけではありませんが、彼らの「言い訳」から、その特性や限界を垣間見ることができるかもしれません。

ここでは、長文にならないよう「理由を簡潔に教えて」と指示します（図３）。

全てのモデルが、小数点以下の「11」が「9」より大きいと誤って認識していることがわかります。つまり、LLMが小数点以下の桁数を正しく認識できていない可能性が高いですね。

そこで、桁数を揃えてあげれば、正しく判断できるのではないかと自然に考え思い浮かびますね。そのため、次のような質問もしてみました：

想定通り、今度はすべてのモデルが安定して「5.90が大きい」と答えてくれました（図４）。有効桁数を揃えることの重要性がよくわかりますね。

「strawberry」の「r」の数

次に、最近もう一つ話題となった問題「strawberry」の「r」の数について見てみましょう。

前と似たような結果が出ています（図５）：

• Gemini 1.5 Pro: 基本的に毎回正解
• GPT-4o, Claude 3.5 Sonnet: たまに正解するが、基本的には「2」と誤答
• Llama3 70b Instruct: 安定して毎回「2」と誤答

この結果を見ると、やはりGemini 1.5 Proが一番良いと思ってしまいますよね。しかし、今回も結論を出すにはまだ早いです。

先ほどと同様に、「理由を簡潔に教えて」を追加して理由を聞いてみましょう（図６）。

結果、Gemini 1.5 Proも含めて、すべてのモデルが「berry」の「r」を1つだけと誤認識していることがわかります。Gemini 1.5 Proは、「aw」の後に存在しない「r」をカウントして、たまたま正解を出しているようですね。

長い数字の0数

実は、似たような問題として、1年前にChatGPTが長い数字の0の数を間違えることがすでに指摘されていました_[2]。

例として、このような質問をしてみます：

質問を複数回繰り返すと、Llama3 70b Instruct以外のモデルは時として正しい回答を返すこともありますが、、基本的には回答の一貫性がなく、誤答が多いです（図７）。

原因探索

トークナイゼーション

以上の結果から、LLMが文字列（特に数字列）の数を数えるのが苦手であることがわかります。その原因として真っ先に考えられるのが、トークナイゼーションの影響です。

トークナイゼーションとは、テキストを「トークン（Token）」と呼ばれる意味を持つ最小単位に分割する処理のことを指します。そして、このトークナイゼーションを行うモデルを「トークナイザー（Tokenizer）」と呼びます_[3]。LLMは、このトークン単位でテキストを処理し、ベクトル表現に変換します。そのため、APIの課金もトークン単位で計算されることが多いのです。

トークナイゼーションは、一般的に隣り合う文字の出現頻度に基づいてトークンの境界を決定します。しかし、この仕組みが数字列のカウントにおいて、LLMに混乱を引き起こしている可能性があります。

Hugging Face上で公開されているCognitiveLabの「Tokenizer Arena」_[4]を利用すると、複数の主要なLLMのトークナイザーを同時に比較することができます。このツールを利用して、各モデルがどのようにトークンを分割しているかを具体的に確認してみましょう。

先ほどの質問文のトークンを確認したところ、以下のようになっていました（図８）。

• 1. Claude 3.5のトークナイザーは公開されていないため、ここではClaude 3のトークナイザーを利用しています。ただし、変更点は非常に少ないと想定されます。
• 2. Geminiのトークナイザーは公開されていないため、ここではGemmaのトークナイザーを利用しています。GemmaはGeminiと同じ技術で構築された軽量オープンモデルであり、両者は非常に似ていると考えられます。

数値の分割結果：

• Gemini（Gemma、以下省略）は、他のモデルと異なり、数字一桁を一つのトークンとして認識
• Gemini以外は、小数点以下の２桁数値「11」「90」を一つのトークンとして認識
• GPT-4o、Llama3は、3桁ごとに長い数値を区切る
• Claudeは、他のモデルよりもさらに長い数値を一トークンとして認識

「strawberry」の分割結果：

• Gemini以外のトークナイザーは、「strawberry」を3つのトークンに分割
• Geminiは「strawberry」を一つのトークンとして認識

Gemini以外の結果から、トークナイゼーションの影響が明らかです。

LLMの視点から見るとこうなります：

• 「5.11」と「5.9」の比較
  ＝「⚪︎×□」と「⚪︎×△」の比較（且つ一般常識として「□」>「△」）
• 「strawberry」の「r」の数
  ＝「◇▽◎」の中の「r」の数
• 「100000000000000000000000000000000」の「0」の数
  ＝「▲◾️◾️◾️◾️◾️◾️◾️◾️◾️◾️」の中の「0」の数

それは、わかるわけないですね。

しかし、Geminiは他のトークナイザーとは異なり、少なくとも数字については1桁ずつを1つのトークンとして認識しています。もしトークナイゼーションだけが原因であれば、Geminiは適切に回答できるはずです。実際、上の質問に対するGeminiの回答は僅かに良く見える¹ものの、正解からはまだ程遠い状況です。

LLMは数値計算を理解していない

ここで着目したいのは、「なぜGPT-4o、Llama3のトークナイザーは、3桁ごとに長い数値を区切るか」という点です。

先ほど書いたように、一般的にトークンの境界は「隣り合う文字の出現頻度」に基づいて決定されます。つまり、3桁以内の数値の出現頻度は4桁以上の数値に比べて明らかに高く、このことから3桁目が境界として選ばれたと考えられます。

ここで思い出されるのは、一年前にChatGPTが登場した初期から、LLM（大規模言語モデル）は4桁以上の掛け算が間違いやすいという指摘があったことです_[2][5]。

度重なるアップデートを経た現在も、この問題は解決されてないようです（図９）：

結果、Claude 3.5 Sonnet以外のモデルは、ほぼ毎回見た目が似ている異なる答えを出します。一方、Claude 3.5 Sonnetは自動的にステップバイステップで計算を行う²ため、常に正しい答えを導き出すことができます。

さらに、「1204*1402=1687408」とあえて間違った（かつLLMの誤答とも異なる）答えを教えて訂正してみます（図１０）。

GPT-4o、Claude 3.5 Sonnet（元々正解していたにも関わらず）、Llama3 70b Instructは私が出した間違った答えをすんなり受け入れました。一方、Gemini 1.5 Proは自信満々に先ほど自分が出した誤答を言い張っていました。めちゃくちゃですね。

以上の結果を一般化してまとめると、LLMは以下のような傾向があります：

• 毎回異なる答えを出す
• ただし、誤答の数値は、一見正しそうに見える
• 間違った回答を教えても、疑わずに受け入れる

私は、LLM は数値計算をしているのではなく、過去の学習データからそれらしい回答を思い出そうとしているだけなのではないかと考えられます。

厳密に証明することは難しいですが、これまで見られた現象と辻褄が合っているように思います：

• 3桁以下の数値計算の精度が高い
  → 学習データ中に多く見かけるため、暗記できている
• 小数点以下の桁数が異なる数値の比較や、超長い数値から「0」を数えるのが苦手
  → そもそも学習データにそのようなタスクが含まれていないため、適切な対応ができない
• 4桁以上の掛け算の結果が、正しそうに見えても実際には正しくない
  → 学習データにそのような数式は含まれていないが、近い形式の数式を見たことがあるため、それを元に近似して回答を生成している
• ステップバイステップで計算すると精度が上がる
  → 学習データに見たことのない複雑な数式も、出現頻度の高い簡単な数式に変換することで、暗記された内容がより正確に再現される

一例として、6桁の掛け算をさせてみます：

今度はGPT-4o、Gemini 1.5 Pro、さらにLlama3 70b Instructまで一発で正解を出せました。Claude 3.5 Sonnetは頑張ってステップバイステップで計算した結果、かえって間違ってしまいました（図１１）。

なぜそうなるのか？それは「890625」は「自己同形数」であり、「890625² = 793212890625」という有名な式がWikipedia_[6]にも載っているためです。この情報がすでにLLMに学習されている可能性が非常に高いと考えられます。

LLMの学習ロジックは本質的に「次のトークンの予測（next-token prediction）」³に基づいており、これは「言語の法則」を使って予測しているに過ぎず、「数学的思考」とは根本的に異なります。

つまり、名著をたくさん暗記することで文章作成能力は向上しますが、数式をいくら暗記しても計算能力が向上するわけではないのです。

1. 1. GeminiのLLMは、他の多くのモデルで採用されているdecoder-onlyアーキテクチャとは異なり、encoder-decoderアーキテクチャを採用している点が特徴です。この違いがトークナイザーおよび性能に影響を与えている可能性がありますが、本稿ではその点に関する議論は割愛します。 ↩︎
2. 2. これは、Anthropicがかなり頑張ってLLMにそのような計算方法を適切にチューニングしたためと考えられます。しかし、残念ながら桁数がさらに増えると、途中の計算で間違うケースも見られました。 ↩︎
3. 3. 厳密に言うと、Geminiを代表とするGoogleのLLMが採用しているのはmasked-token predictionです。 ↩︎

改善策

「LLMが簡単な数値問題を解けない」ことを指摘するだけが目的ではありません。適切な方法を見出し、正しい回答を導き出すことができるようになるのも重要です。

ステップバイステップ思考

多くの方になじみのある「ステップバイステップ思考」は、確かに一つ有効な手法です。実際に、Claude 3.5 Sonnetはデフォルトで掛け算の計算をステップバイステップで行おうとしています。

しかし、数値計算においてステップバイステップ思考は精度を大幅に向上させるものの、100%正解を出せるわけではありません（図１２）。

プログラムを実行して回答

LLMは、曖昧な表現も理解できる点が強みです。しかし、裏を返せば、正確性を追求することに向いてないです。LLMに100%の正確性を求めるのは木に縁りて魚を求むようなことです。正確性が求められる数値計算などは、生成AIのLLMに任せるのではなく、プログラムを使いましょう。これは、暗算が苦手な人が電卓を使うのと同じことです。

シンプルに、「プログラムを実行して回答してください」と指示するだけで良いのです。

ちなみに、ここでは「書いて」ではなく「実行して」と明確に伝える必要があります。そうしないと、コードを書いただけで回答が間違ったままになることがあります。

天秤AIはAPIを利用しているだけなのでプログラムを自動で実行することはできませんが、各生成AIサービスのUIでは実行可能です。

以下はChatGPTの例です（図１３ – １５）。

実際、現在のChatGPTに掛け算の問題を出すと、デフォルトでは裏でプログラムを動かして回答しています（図１６）。ネット上ではたまに「LLMの計算能力が向上した」といった記事を見かけますが、それは当然のことですね。

おわりに

OpenAI, Anthropic, Google, Metaといった企業の努力によって、LLMを含む生成AIは格段に使いやすく、私たちの生活に浸透しつつあります。しかし、「生成AIは万能である」という誤解は避けなければなりません。

現状の生成AIはあくまでも確率に基づいてそれらしい文章や画像を生成しているに過ぎず、その出力の正確性や倫理性については常に注意が必要です。

生成AIをより有効に活用するためには、 「生成AIは何が得意で何が苦手なのか」 を理解し、 「道具として適切に使いこなす」 という姿勢が重要になってくるでしょう。

参考資料

• GMO教えてAI. “天秤AI byGMO”. 天秤AI byGMO. https://tenbin.ai. (2024-08-06アクセス) 
• 湊 真一. “ChatGPTはなぜ計算が苦手なのか”. 国立情報学研究所. https://www.nii.ac.jp/event/upload/20230707-03_Minato.pdf. (2024-08-06アクセス) 
• データアナリティクスラボ. “日本語LLMにおけるトークナイザーの重要性”. Journal | データアナリティクスラボ. https://dalab.jp/archives/journal/japanese-llm-tokenizer/#i-4. (2024-08-06アクセス) 
• Cognitive-Lab. “Tokenizer Arena”. Hugging Face. https://huggingface.co/spaces/Cognitive-Lab/Tokenizer_Arena. (2024-08-06アクセス) 
• tueda. “掛け算のできないChatGPT”. Qiita. https://qiita.com/tueda/items/c04799a1eb8a2e46b9f6#fn-1. (2024-08-07アクセス) 
• “自己同形数”. ウィキペディア (Wikipedia): フリー百科事典. https://ja.wikipedia.org/wiki/%E8%87%AA%E5%B7%B1%E5%90%8C%E5%BD%A2%E6%95%B0. (2024-08-07アクセス) 

ブログの著者欄

採用情報

関連記事

• 

  The AI Scientist:Sakana AIの開発した仮説提案、実験、論文執筆から査読まで研究自動化AIエージェント

  技術情報

• 

  Codestral Mamba:Mistral AIのMamba搭載次世代型大規模言語モデル

  技術情報

• 

  Microsoft365でクラウドストレージ初めの一歩

  技術情報

• 

  mbedTLSでTLS 1.3を使ってみる

  技術情報

• 

  ［登壇レポート］GMO DevelopersNight#38 / エンジニア出身者が活躍するカスタマーサポート

  技術情報

• 

  RPAを作りましょう　ハイブリッドフロー編

  技術情報