トークン圧縮の幻想：なぜ私はRTK（Recursive Token Compression）に懐疑的なのか

最近話題のトークン圧縮技術（RTK）ですが、個人的には正直なところ「幻想」ではないかと感じています。処理効率の向上を謳う手法の多くは、コンテキストの質を犠牲にしているケースが少なくありません。なぜ多くのエンジニアがこのアプローチに飛びつく一方で、私が慎重な姿勢を崩さないのか、その技術的懸念点を共有します。

1. ゲーム感覚の節約 vs 実際のAPI利用料

ツール使用の出力は、私の出力の大部分を占めているよ。入力トークン3.9Mに対して3.7Mトークンを削減できた。トークンは節約できればそれに越したことはない。

3. 正確性のベンチマークはどこにある？

RTKのユーザーとしては、正確性のベンチマークが見られたら嬉しいね。でも、圧縮の結果としてモデルが何か重要なものを見落としたという証拠は今のところない。彼らの設計思想の一部として、正確性の維持にはかなり厳格で、フィルタリングに失敗すれば未加工の出力に戻すようになっている。よく使うコマンドについてはソースを確認したけど、納得のいく内容だったし、今のところ信頼しているよ。

git、cargo、npm、grepがターミナルのフォーマットを少し変えたり、エラー出力のレイアウトを変えたりした日には、RTKの正規表現やパース用フィルタは壊れる。そして「サイレントな失敗」の罠に逆戻りだ。明示的なエラーは出さず、静かに失敗して、破損したテキストや不完全なテキストをエージェントに送り込むことになる。

重ねて言うけど、フィルタが失敗すれば単純に未加工の出力に切り替わるんだ。彼らの核心的な柱の一つは、まさに今言ったようなシナリオを避けることにある。RTKが破損したデータや不完全なテキストをエージェントに送り込むことは本来ないはずだよ。

懸念はもっともだけど、批判するなら証拠もセットで見せてほしい。RTKを使ったことがあるのかい？正確性が損なわれているという証拠は見つかったの？

私が「LLM魔法の箱」業界と呼んでいるものについて、ようやくこうした記事が盛り上がりを見せ始めていて嬉しいよ。Caveman modeからRTK、セマンティック検索まで全部含めてね。開発者はエンジニアじゃなくて、呪文を唱える魔術師になってしまった。特に、自分の魔法の呪文こそが究極のトークン削減術だと信じて疑わない連中が職場にいると最悪だ。

私の基準はこうだ。「ハーネス（テスト環境）に入っていないものは大したことない」（最高レベルのアイデアはCodexやClaudeに集約されると思っている）、そして「トークン削減率を謳うGitHubのプロジェクトは信じるな」。

このインチキ商品（スネークオイル）を見極めるのは難しいけど、みんながこれについて批判的に考え始めてくれることを願うよ。

試してみたけど、メッセージは圧縮されなかった。私のコンテキストの9割はメッセージだったから、結局トークン使用量のほんの一部しか圧縮できていないことになる。注意深く読めば、そのことは明確に書かれているよ。/contextを見ればわかると思うけど、ツール呼び出しがトークンを消費しているわけじゃないから、ツール呼び出しを圧縮するプロキシを入れても大した効果はない。ツール呼び出しを8倍圧縮しているというのは事実でも、長時間のコーディングセッションにおいては、そんなに重要じゃないんだ。

「ネイティブや組み込みのReadやcatツールについては、RTKのシェルフックではデータがインターセプトされない」

記事を書いた本人です。正直に理由を話すと、ソフトウェアエンジニアの視点から見てrtk aiが非常に奇妙に見えたからなんだ。スターの数に対して正確性への言及がまったくないこと、そして経営層がコスト最適化のためにこういったツールを押し付けている現状だね。今やみんなが手当たり次第にコマンドをrtkでラップして、あらゆる主要コマンドを処理しようとし、どの出力を採用すべきか判断しようと躍起になっている。

メインストリームのCLIや開発ツールは、LLMが消費しやすい --compact や --json-stream フラグをネイティブで簡単に提供できるはずだ。

それが実現するまでは……そうすぐには無理だろうね。rtk、caveman、ponytailなんかは、増え続けるコスト（2,000人規模の組織なら、今や約2.5Mトークンだからね）に対処しようとしているだけ。これはトレードオフなわけで、みんな分かった上で調整しているんだ。筆者の主張とは違って、私たちはトレードオフをよく理解しているし、ツールをフォークしたり、ベンチマークを取ったり、出力品質がニーズに合っているか検証したりして使いこなしている。盲目的に使っているわけじゃない。

個人開発者なら、わざわざ導入せずとも別のモデルをセルフホストする方がいいかもしれない。でも組織にとっては、そこが厄介な部分なんだ。

こういった記事が問題に光を当ててくれるのはいいことだけど、ツールを扱う時と同じように、この記事の内容も鵜呑みにせず、割り引いて受け取る必要があるね。

Macでたった今 rtk gain を打ってみたところだ。不運にもメインの開発マシンはメモリの問題でクリーンインストールしたばかりで少し調子が悪いんだけど、Mac上では入力トークンを約51k、出力トークンを23k削減できて、1コマンドあたり平均3秒の短縮になった。何がそんなに憤慨することなのか、わざわざこの記事を書くほどのことなのかよくわからないな。

誰がスタックトレースをRTKに通しているのか知らないけど、私は特定のプログラムにしか使っていない。コンパイラの出力をわざわざ通すのは馬鹿げているし、エージェントに対して「この特定のコマンドセットにだけRTKを使え」と指示すればいいだけの話だよ。

この記事が指摘している保守性の問題の多くは妥当な気がする。特にアップデートやバージョンの出力形式変更についてはね。ただ、一番シンプルな代替案さえ提示されていない。サポートされているコマンドのほとんどには、ノイズを取り除いて出力を減らすためのフラグがあるはずだ。もしかしたら、エージェントがそういった使い方の訓練を受けていないのかもしれない。

余談だけど、コマンド出力を軽量なローカルモデル経由でプロキシする、デュアルエージェント構成を試した人はいる？ツール出力すべてをQwenかなにかでローカルにフィルタリングして圧縮するようなシナリオはありだと思うんだよね。

まず第一に、エージェントがRTKの圧縮を認識して、バイパスオプション（私は RTK_DISABLE=1 を使っている）を設けることで、元の全文に戻すという方法で切り詰めを察知させることは可能だよ。

これでうまくいく。「圧縮」という点ではコマンドの出力しか圧縮されないから、影響を受けるのは入力トークンだけだしね。

同意。私もエージェントがRTKの出力で混乱して、堂々巡りになったり、変な回避策をとったりするのを何度も見てきた。

https://github.com/chopratejas/headroom を使った経験がある人はいる？トークン削減という目的は似ているみたいだけど、headroomの方がより広い範囲をカバーしているように見える。