何が変わったのか

長文コンテキストの処理はLLMにとって計算上のボトルネックになりつつある。従来の圧縮手法はKVキャッシュをフルサイズで展開してから不要部分を削除する設計だが、LCLMはこのアプローチを根本的に変える。専用のエンコーダーが入力トークン列をデコーダーへ渡す前に圧縮する仕組みだ。

研究チームのMicah Goldblum氏は「膨張し続けるコンテキストはメモリと計算の両面でボトルネックになっている。長い文脈を効率よく正確に扱えるモデルを作れれば、あらゆる処理がより安価で高速になる」と述べている。

精度と速度のデータ

RULERベンチマークでの評価結果は以下のとおりだ。

圧縮率精度備考
なし（ベースライン）94.41%—
4倍圧縮91.76%差は約2.65ポイント
16倍圧縮75.06%入力トークンの93.75%を削除、検証済み全KVキャッシュ手法を上回る

速度面では16倍圧縮時にKVキャッシュベースラインより8.8倍の高速化を達成した。また100万トークンのコンテキストをNVIDIA H200 GPU 1枚で処理可能で、非圧縮手法ではメモリ不足となる規模の処理に対応できる。

アーキテクチャと学習

LCLMは6億パラメータのエンコーダーと40億パラメータのデコーダーを組み合わせた構成で、3500億トークン超のデータで学習した。学習データは継続事前学習データ、教師ありファインチューニングデータ、補助的な再構成タスクの3種類を混合している。

Goldblum氏は「人間がコンテンツをざっと読んで関連箇所に集中するのと同じ」と説明する。膨大なテキストやコードを高速にスキャンしたうえで、必要な部分だけを精読するマルチスケールなアプローチが可能になるという。

既存システムへの組み込み方

Goldblum氏によれば、既存のLLMをLCLMに置き換える手順は単純だ。「ドキュメントを取得してモデルのコンテキストに流し込む場面では、まずLCLMの圧縮器にかけるだけでよい。既存のLLMをそのままLCLMに差し替えられる」としている。

モデルとコードはHuggingFace（huggingface.co/latent-context）とGitHub（github.com/LeonLixyz/LCLM）でオープンソース公開されている。

残された課題と業界動向

研究チームは未解決の課題も明示している。RAGパイプラインへの完全な統合にはチューニングが必要で、推論トレースのオンライン圧縮は未検証のままだ。Goldblum氏は「推論トレースを生成しながら定期的に圧縮する素朴なアプローチは機能するかもしれないが、まだ確認されていない」と述べている。

エンタープライズ側でも文脈処理の効率化への関心は高まっている。VB Pulse Q1 2026調査（従業員100名以上の組織対象）によると、ハイブリッド検索の採用意向は2026年1月の10.3%から同年3月には33.3%へと2カ月で約3倍に増加した。回答者の28.9%が検索最適化を優先課題に挙げている。

出典：VentureBeat

関連リンク