7月8日、dev.toユーザーのgdeが「Stop Your LLMs from Forgetting: How a 2016 String Algorithm Solves AI's Biggest Memory Loss Problem」と題した記事を公開した。2016年に考案された文字列結合アルゴリズムを木構造として再解釈し、LLMの多文書集約に応用することで、Sequential比95%高速化と情報網羅率100%を同時に達成する——というのが本稿の核心だ。古典的アルゴリズムが9年越しに現代のAI課題を解くという展開が注目を集めている。
2016年のアルゴリズムが、なぜ2025年のLLMに効くのか
著者であるgde（tanaikech）は、2016年にGoogle Apps Scriptの文字列結合を高速化する研究を発表している。当時のGoogle Apps ScriptはV8エンジン以前の実装で、文字列を順番に結合していくと計算量が$O(N^2)$になる問題があった。これを木構造で階層的に結合する「Pyramid Method」に変えることで$O(N)$に抑え、実行コストを99.7%削減した。
最近この論文をZenodoにアーカイブする作業をしていたとき、著者はあることに気づいた。
「このピラミッド木構造は、現代の生成AIが複数ドキュメントを集約する処理にも使えるのではないか？」
LLMがロングテキストを処理するとき、Attentionの計算量は入力長$L$に対して$O(L^2)$でスケールする——かつての文字列結合問題と同じ構造だ。LLMに大量のドキュメントを読ませて要約させると、AIは「忘れる」。この問題を定量的に実験し、古典的なアルゴリズムで解決したのが本記事の内容だ。
AIの「忘却バイアス」は2種類ある
複数ドキュメントをLLMに集約させる従来手法には、それぞれ固有のバイアスがある。
1. Batch-Concatenate（一括結合）
32本のドキュメントをすべて連結して一度にLLMへ投げる。LLMはプロンプトの先頭と末尾に注意が偏るため、中間のドキュメントが無視される「Lost in the Middle」現象（Primacy Bias）が起きる。
2. Sequential Update（逐次更新）
ドキュメントを1本ずつ読ませ、そのたびにサマリーを更新していく。出力に厳しい文字数制限がある場合、古い情報を捨てて新しい情報を入れるしかなく、32本目に到達するころには最初のドキュメントの内容がほぼ消える「Information Drift」（Recency Bias）が発生する。
Pyramid Aggregation：3階層の木構造で解く
Pyramid Aggregationは、ドキュメント集約をバランスの取れた木構造で組織化する。32ドキュメントの場合、処理は3段階になる。
- Level 1（Local Extraction）：32本を8グループ（各4本）に分け、並列でサマリーを生成
- Level 2（Intermediate Merging）：8本の中間サマリーを2グループ（各4本）に分け、並列でマージ
- Level 3（Final Merger）：残った2本をマージして最終サマリーを生成
LLM呼び出しは合計11回（Level 1で8回、Level 2で2回、Level 3で1回）だが、各レベル内の呼び出しは互いに独立しているため、同一レベルの呼び出しをすべて並列化できる。記事では**Antigravity Python SDK**（著者自身が開発したGoogle Gemini API向けの非同期エージェントSDK）のasync with Agent(config) + asyncio.gatherを使って並列実行を実現している。
この並列化により時間計算量は逐次処理の$O(\theta)$から$O(\log_\phi \theta)$へと圧縮される。ここで$\theta$は総LLM呼び出し回数、$\phi$は各レベルでのグループ分割数（ブランチング係数）を指す。木が深くなるほど対数的にスケールするという性質だ。
実験結果：Sequential比で95.1%の高速化、かつ情報網羅率100%
実験は32本の合成システムログ（各ログが特定ソフトウェアモジュールのエラーを報告）とgemini-3.1-flash-lite（※元記事記載のモデル名。執筆時点でのGeminiモデルラインナップと表記が異なる可能性があるが、元記事の記載に従う）を使って実施。最終サマリーは50語以内、かつ1文に3モジュール名以上列挙禁止という制約を設けた。
実行時間の結果が特に明確だ。
| 手法 | 実行時間 |
|---|---|
| Batch-Concatenate | 5.44秒 |
| Sequential Update | 166.02秒（約3分） |
| Pyramid Aggregation | 8.10秒 |
Pyramid AggregationはSequentialより95.1%速く、Batchとほぼ同等の速度でありながら情報網羅率は100%を達成した。
情報網羅率の指標として、この実験では障害ドメインカバレッジ（32本のログが属する障害カテゴリを最終サマリーが何割カバーしているか）を用いている。Batch・Sequential両手法は個別のモジュール名を（限られた範囲で）回収しようとするが、この障害ドメインカバレッジは**50.0%にとどまった。一方Pyramid Aggregationは個別名の回収率0.0%（具体的な名前は出てこない）だが、障害ドメインのカバレッジは100.0%**。個別名を「memory failures, network failures, database failures」といった上位カテゴリに抽象化することで、32本すべてのドキュメントをサマリーに反映させた。
これを著者はクラスの自己紹介に例えている。最初の3人の名前だけ読み上げるか（Batch）、「このクラスにはアスリートが10人、アーティストが12人、プログラマーが10人います」と全員を代表する形で紹介するか（Pyramid）の違いだ。
実装の核心：なぜ今この手法が使えるのか
Pyramid Aggregationの考え方自体は古典的な木構造の再帰分割であり、目新しいデータ構造ではない。ただし実用化には非同期オーケストレーションが必要で、各レベルのLLM呼び出しを並列実行できるSDKやフレームワークが前提となる。記事ではAntigravity Python SDKを使っているが、asyncioベースの実装であれば同様のアプローチは他のLLMフレームワークにも応用できる。
RAGパイプラインや複数ログの横断分析、AIエージェントでの大量ドキュメント処理に取り組んでいるエンジニアには、試す価値がある手法だ。論文のプレプリントはZenodoで公開されている。
詳細はStop Your LLMs from Forgetting: How a 2016 String Algorithm Solves AI's Biggest Memory Loss Problemを参照していただきたい。
