LLMを「出現回数の表」で補強するCOUNT、追加学習なしで分野を切り替える仕組み｜2026年10月20日版
LLMの性能を上げる手段に、GPU上のモデルを大きくする以外の選択肢が加わった。10月14日に公開された研究「COUNT」は、文章中のトークンの並びと出現回数を集計し、サーバーのメインメモリから言語モデルへ補助情報を渡す。
特徴は、COUNTを組み込んで学習したモデルなら、推論時に参照表を替えて専門分野へ適応させられることだ。モデルの重みを更新せず、数学や法律などの文章から作った統計を利用する。既存の任意のLLMに表を接続するだけで使える機能ではない。
2026年10月20日（日本時間）時点の公開論文と実装をもとに、仕組みと導入時の確認点を整理する。
- 補助情報は、トークンの並びに続いて何が出やすいかという統計。
- 大きな参照表はGPUメモリではなく、ホスト側のRAMに置く。
- 研究では性能改善を確認したが、表の容量と実装の処理速度が実用上の条件になる。
COUNTは「次に来やすいトークン」を入力へ戻す
COUNTの核は、古くからあるn-gramの統計を、Transformerの入力に組み込むことだ。
n-gramとは、連続するn個のトークンの並びを指す。文章データからその並びを数えると、ある文脈の後にどのトークンが多く続くかを集計できる。
COUNTは次の流れで、この統計をモデルに渡す。
- 入力末尾のトークン列に合う履歴を、事前作成した表から探す。
- その履歴に続きやすいトークンと頻度に基づくスコアを取り出す。
- 候補トークンに対応するモデルの出力側ベクトルを、スコアで重み付けして足し合わせる。
- 得られたベクトルを通常の入力埋め込みに加える。
モデルは、入力された文章に加えて「この並びの後には何が現れやすいか」という手掛かりを受け取る。文書そのものを検索してプロンプトに挿入する方式とは、情報を渡す場所も形式も異なる。論文の手法説明
GPUメモリを増やさず、ホストRAMを使う
参照表は読み取り専用だ。学習中に表の各行を勾配で更新する必要がないため、ホストRAMに置ける。
一方、通常の学習可能な埋め込み表は、重みや更新用の状態を保持するためにGPUメモリを使う。COUNTは既存の出力側ベクトルを再利用し、追加の学習パラメータを設けずに統計情報を取り込む設計になっている。
ただし、GPUメモリの節約と、システム全体の軽量化は同じではない。代表的な10億パラメータの実験では、約797GBの参照表を使用した。モデルの大きさだけで、必要なサーバー構成を判断することはできない。
研究チームは、この構成で通常のTransformerに学習計算量を57％多く与えた場合に相当する検証損失を報告した。これは特定の実験条件での予測誤差の比較であり、あらゆる業務の正答率が57％上がるという意味ではない。COUNT公式実装の概要
専門分野への適応は「表の混ぜ方」で変わる
運用上おもしろいのは、学習後の表の交換だ。
研究では、数学・生物医学・法律の文章から専用の表を作り、一般分野の表と混ぜて評価した。専門分野の表を25％、一般分野の表を75％の比率で混ぜた条件では、三分野すべてで損失が改善した。一方、正答率の結果は一様ではなく、生物医学では改善と悪化が混在した。
つまり、専門文書を多く集めて表を置き換えれば、そのまま専門家向けの回答品質が保証されるわけではない。表の交換後には、対象業務に合わせた評価が必要になる。論文の分野適応実験
日本語の業務利用でも、確認すべき点は具体的だ。
- 対象の日本語文書を、モデルと同じトークナイザーで処理できるか。
- 専門分野の改善と引き換えに、一般的な質問への回答が悪化しないか。
- 表の作成・保管・更新に必要な費用を含めて運用できるか。
これらは導入を検討する際の評価項目であり、日本語業務での効果が今回の結果から保証されたわけではない。
公開コードと論文の速度測定は分けて見る
再現を試す開発者は、公開実装の範囲にも注意したい。
公式GitHubには、集計表を作る処理、OLMo-coreを拡張したモデル実装、評価用のコードが公開されている。表を交換したチェックポイントの評価も用意されている。
ただしREADMEは、公開コードが論文の速度測定に使った最適化済みランタイムではないと明記する。たとえば、公開版の表検索は学習プロセスの主処理上で実行される。手法を検証できることと、報告された処理速度をそのまま再現できることは分けて判断する必要がある。公式READMEの実装範囲
継続ウォッチ：表を替えた後の品質と費用
COUNTが示したのは、モデルの重みとは別に、交換可能な統計表を性能改善に使う道だ。企業の開発者にとっては、再学習の頻度を減らせるかを検証する研究対象になる。
次に見たいのは、次の三点だ。
- 日本語での評価：専門用語や表記の揺れを含む文書で、どの程度改善するか。
- 小さい表での品質：利用可能なRAM容量に収めたとき、効果がどこまで残るか。
- 実装を含む総費用：集計処理、RAM、検索処理の時間まで含めて、追加学習と比較できるか。
試すなら、まず同じチェックポイントで一般表と専門表を切り替え、業務に近い固定問題で差を測りたい。専門問題の改善だけでなく、一般問題の悪化と処理時間も同時に記録することが、導入判断の出発点になる。