ハクソク

世界を動かす技術を、日本語で。

2つの10桁の数字を加算できる最小のトランスフォーマー

88日前原文(github.com)

概要

  • AdderBoard Challenge は、10桁同士の加算を99%以上の精度で実行できる最小のTransformer構築コンテスト
  • 手動設計（Hand-coded） と 学習済み（Trained） の2カテゴリで性能を競う
  • 自己回帰型Transformer であることが必須条件
  • 各手法の工夫や結果は リーダーボード で公開
  • パラメータ数の削減 と 正確な加算表現 が主な研究課題

AdderBoard Challengeとは

  • 10桁の整数同士を加算し、 99%以上の精度 で正しい和を出力する最小のTransformerモデルを競うチャレンジ
  • Dimitris Papailiopoulos （@dimitrispapail）による運営
  • 当初はClaude Code（6,080パラメータ）とCodex（1,644パラメータ）がスタート地点
  • コミュニティの貢献で パラメータ数が劇的に削減 されている現状

部門と評価基準

  • Trained（学習済み）部門
    • SGDやAdam、進化的探索など、汎用的な学習アルゴリズムで重みを学習
    • データフォーマットやトークナイゼーション、カリキュラム学習、アーキテクチャ探索の工夫が評価対象
  • Hand-coded（手動設計）部門
    • 重みを理論的に解析的に設定（SGD等の発見性は不問）
    • アーキテクチャが加算を表現できることの構成的証明

主なルール

  • 自己回帰型Transformer であること
    • 少なくとも1層の 自己注意（Self-attention） レイヤーを含む
    • 入力はトークン列、出力は次トークンの予測（逐次的な自動生成）
    • キャリー伝播もこの自己回帰過程から自然に発生する必要
  • forward()は標準的なテンソル入出力計算
    • 問題特化の制御フローや明示的なキャリー変数、文字列操作は禁止
    • 推論ループは他のタスクにも使える汎用的なもの
  • 入力フォーマットの工夫は可
    • 桁の逆順や区切り文字など、固定された形式なら許容
  • 99%以上の精度 を10,000組の乱数ペアで確認

パラメータカウントの基準

  • 重みの重複・タイイング後の一意なパラメータ数 で計測
  • 固定/サイン波的な位置エンコーディングはカウント対象外
  • 学習済みの位置エンコーディングはカウント対象

リーダーボード（抜粋）

Hand-Coded（手動設計）

  • 1位：36パラメータ／100%精度／alexlitz
    • 2層デコーダ、d=5、ALiBi（slope=log(10)）、ゲート付きReLU FFNなど
  • 2位：40パラメータ／100%精度／Wonderfall
    • 1層デコーダ、d=2、周期的RoPE、2ヒンジReLU MLPなど

Trained（学習済み）

  • 1位：311パラメータ／99.999%精度／rezabyt
    • 1層デコーダ、d=4、Rank-3ファクトライゼーション、RMSNorm、グロッキング
  • 2位：335パラメータ／99.92%精度／h3nock
    • カリキュラム学習、タイドエンベッド等の工夫

技術的工夫・発見

  • Rank-3ファクトライゼーション による大幅な圧縮
  • ALiBi の傾きlog(10)設定で基数10の重み付けを実現
  • 自己注意 による桁揃え、 MLP での1桁加算、 自己回帰生成 でキャリー伝播
  • パラメータ数約800 で急激な精度変化（パラメータクリフ現象）
  • 手動設計モデルは学習済みモデルよりはるかに小型化可能 （例：36 vs 311パラメータ）

提出方法

  • Issueの作成 または Pull Request でエントリー
    • コードへのリンク、テスト結果（精度）、検証スクリプトの実行結果を添付
    • 検証はverify.pyで10,000組＋エッジケース10組を評価

研究的意義

  • Transformerが整数加算をどこまで小さく表現できるか の探求
  • 桁揃え・逐次加算・キャリー伝播という3つの能力を最小構成で実現する挑戦
  • 低パラメータ・高精度モデル設計の知見 の蓄積
  • 汎用的な自己回帰モデル設計の理解深化

参考リンク

  • 公式リポジトリ（GitHub）および各エントリーのgist/repo
  • MITライセンス

Hackerたちの意見

要するに、別の重みのセットを入れ替えて、同じ推論コードを使って別のタスクをこなせるなら、そのセットアップは正当だよ。もし推論コードがアルゴリズムから切り離せないなら、それはダメだね。なんで自分たちでコードを書かないのか不思議だな。そうすれば、モデルに焦点を当てられるのに。

└

手書きでコードを書くって、これ、6ヶ月前のこと？

ルールにどれくらい合ってるか分からないけど、Twitterで誰かが28パラメータって言ってたのを見たよ。

そういう単目的のネットワークを固定重みでLLMの中に埋め込むのって、事前学習の前に意味あるかな？

└

いい質問だね。うまくいくかもしれない、こういうテストを実行することも考えたよ。でも、いくつかの条件が必要なんだ。サブネットワークは「勾配抵抗」になるように作るか、凍結したままでなきゃダメ。発見された回路や手作りの回路がそのまま勾配圧力に耐えられるわけじゃないからね。特に、初期のプレトレーニングで飛んでくる勾配の種類はね。実際のLLMのプレトレーニング中に形成されるネイティブな表現とインターフェースできる必要があるけど、これは簡単じゃない。プレトレーニングの早い段階でこれが起こるべきだよ。勾配がサブネットワークを通るようにルーティングされ始めなきゃ。そこから「リッチがリッチになる」ダイナミクスに任せられるけど、そのためにはフルネットワークがサブネットワークを発見して使い始める必要がある。そして最後に、我々が望む用途で使われ始めなきゃいけない。もし「加算プリミティブ」の構造が他の何かに吸収される可能性もあるよ、トレーニングランに早めに入れたら、LLMのネイティブ回路が存在しない時にね。全体的に、初期テストとしては、同じサブネットワークの200の凍結コピーをLLMの異なる層に散布して、プレトレーニングを通してのダイナミクスを観察するのがいいと思う。発見を助けるために、プレトレーニングデータに追加の合成加算問題を入れるのもアリだね。原則的な解決策というより、エンジニアリング的な解決策だね。

└

それについても考えてた。もし、（一部の）チューリングマシンの能力を持つサブネットワークを手作りしたらどうなるかな？そういう回路はトレーニング中に自然に出てくるのかな？推論はそれを使って複雑な計算ができるの？

自分の提出物についてブログ記事を書いたよ（現在、36パラメータでトップの手書きのやつ）。

└

この質問は、あなたのブログ記事が数学を知っている誰かによって英語で書かれていることを確認する以上のことができない自分からのものです。もしN人の賢い人間が手動でLLMを作ったら、最前線のモデルと同じくらい賢いものができるかもしれないけど、サイズは45倍小さくなる可能性があるってこと？（1644 / 36 ≈ 45、Nは非常に大きい、時間は指定なし）

└

詳細は全部見てないけど、最初の埋め込みがどうなってるか見たかったんだ。14x5の行列があるのも確認したよ。手動で設定する時（学習するんじゃなくて）、「パラメータ」を数える定義がちょっと曖昧になるよね。あれは全部パラメータだって言えるかも！たとえシンプルに設定してもね。

すごくクールだけど、代わりにaddのCPU命令を提案してもいい？64ビットの数をサポートしてるし、ハードウェアにエンコードされてるから、パワーを食うGPUを経由する必要もないし。しかも、ほぼすべてのISAが最初からaddを持ってるから、クロスプラットフォームの可能性も高いよ。

└

「2つの数を足すことができる最小のスパコンクラスター」

└

まあ、すごいスピードで近くでレースさせるために、たくさんの高性能な車をサーキットに入れる必要はないよね。特に、都市バスはずっと前からあるし。

└

いや、無理だよ。それは問題に対して間違ったツールだ。君のその小さな「追加」には、LLMがツールコールとして出力するオーバーヘッドがあるし、解決を待っている間にLLMの推論を一時停止しなきゃいけない。それから結果をトークンとしてエンコードして戻さなきゃいけない。逆に、「トランスフォーマー・ネイティブ」の加算回路は？単一のフォワードパス内で非常に低コストで実行できて、トランスフォーマー・ネイティブな表現を生成し、プレフィルと自己回帰生成の両方で動作できるし、もっと色々できる。こっちの方が安上がりだよ。

10桁の数字の加算に「ホールドアウトテストセット」なんて考えたら、思わず笑っちゃったよ。

└

トランスフォーマーの出力がもっと伝統的に定義された関数と一致することを正式に証明するための良いツールはないと思う。でも、主要なトランスフォーマーは小さすぎて、正式な検証が可能かもしれない。正式な検証なしでは、2つの10桁の数字の入力空間は64ビットより少し大きいから、すべての可能な入力を徹底的に検証するのは実用的じゃない。各提出物を検証するために同じ入力空間のサブセットを使うのが公平であるための最も簡単な方法のように思えるし、そのサブセットを競争相手に開示しないのは明らかに必要だね。

じゃあ、11桁の数字でテストしたらどうなるの？これは「やったね、バカなトランスフォーマー」っていうつもりじゃないよ。もっと、桁を増やすと精度が下がるのか、それともトランスフォーマーのスタックオーバーフローみたいになって、燃えてるスプーンの画像を出力するのか？それにしても、9桁の数字はどうなるの？そっちの方が正確なのか、それともこの子たちは10桁の数字を加算するのが得意なだけなの？基本的に、失敗のパターンは精度の緩やかな低下なのか、それともパラメータ外での派手な失敗なのか。

└

トランスフォーマーがどう訓練されているかによるね。もし11桁の例を見ていたらうまくいくかもしれないけど、そうでなければ入力が分布外になって、意味不明な数字で返すことになるよ。例えば、現在のハイスコアモデル（311パラメータ[0]）は、12345678900 + 1を与えると、96913456789と返す。面白い実験は、無限加算を扱うのに必要な最小パラメータ数は何か、ということだね（ツールコールにオフロードせずに）。もちろん、メモリ制約があるからそんな実験は無理だろうけど。だから、妥当な代理としては、モデルが訓練されていない数字の長さを扱えるようにするためには、どんなニューラルネットアーキテクチャと訓練が必要か、ということになると思う。これが可能かどうかは疑わしいけど。[0] https://github.com/rezabyt/digit-addition-311p

└

LLMアーキテクチャの大きな制限の一つは、失敗モードが入力によって予測不可能に変わることだね。特定の失敗モード（あるいは成功した出力）を持つ11桁の数字のセットには、明確なパターンがなくて、トレーニングプロセスがモデルに組み込んだランダムさしかない。いつ大失敗するかを事前に予測することはできないし、失敗ケースの明確な境界を引くこともできない。最初の大きな例は、redditデータでトレーニングされたほとんどのLLMに導入された「グリッチトークン」だった。でも、「一般的に言って」「特定のサイズの全入力における平均的な失敗率」という答えはあるよ：入力があまりにも複雑になると、LLMのパフォーマンスは急激に落ちる。人間と比べると、子供にN桁の数字を足させると、エラー率はNに対してほぼ線形になるからね。

セルフアテンションは必須です。モデルには少なくとも1つのセルフアテンション層が含まれていなければなりません。これがトランスフォーマーの定義的な特徴です — これがなければ、MLPやRNNであって、トランスフォーマーではありません。2つのネットワークが同じデータセットでトレーニングされ、アーキテクチャが同じで、片方のネットワークにセルフアテンション層があるというチャレンジを見てみるのは面白いと思います。今のところ、セルフアテンションはネットワークに新しい能力をもたらしたように思えます - 基本的に、入力に応じてネットワークの機能を変えるんです。従来のフィードフォワードネットワークが解決できない問題（つまりデータセット）があって、同じサイズのトランスフォーマーネットワークが解決できるかどうかを見るのは面白いでしょう。私の予想では、そういうのはあると思うし、それはLLMで見られる「変動タスク」データセットのようなものです。つまり、入力の一部がタスク自体を示し、もう一部がそのタスクのデータを示すようなものです。

└

今のところ、セルフアテンションはネットワークに新しい能力をもたらしたように思えます。セルフアテンションがなぜそんなにユニークに強力なのか、素人にもわかる説明はある？「セルフアテンションを使えるから」以上の何かが知りたいな。

90年代には、ニューロンで論理回路をエミュレートする論文があったよ。これよりも大きくなるけど、少なくとも常に正しいんだ。

高速行列乗算はもっと役立つベンチマークになると思うよ： https://fmm.univ-lille.fr/