大きなコンテキストウィンドウを信用するな
(garrit.xyz)- LLMのコンテキストウィンドウは、モデルが鋭く動作するスマート領域と、注意力が落ちて先ほどの指示を忘れ始める鈍い領域に分けられる可能性がある
- 境目はおよそ100kトークン付近にあり、宣伝されているコンテキストウィンドウの大きさが、そのまま実際の作業可能範囲を意味するわけではない
- コーディングエージェントは、ファイル読み込み、長いデバッグ、大規模なテスト実行だけでも、すぐにトークンを消費して100kトークンに達しうる
- RULERとChromaのcontext rotレポートは、有効なコンテキストが宣伝値の一部にすぎず、ウィンドウを埋めるほど性能が段階的に低下することを示している
- 長いセッションを自動要約する方式よりも、手書きの仕様書と小さな成果物として情報をセッション外に残す方式のほうが、作業をスマート領域に留めやすい
コンテキストウィンドウの実際の限界
- LLMのコンテキストウィンドウは、モデルが鋭いスマート領域と、注意力が落ちる鈍い領域に分けられる可能性がある
- 鈍い領域では、モデルは数分前に伝えた内容を忘れ始める
- 境目はおよそ100kトークン付近にある
- 宣伝されているコンテキストウィンドウの大きさが大きくても、この境目が消えるわけではない
- コーディングエージェントは、現代的な使い方ではトークンを急速に消費する
- 数回のファイル読み込み、長いデバッグセッション、広範なテスト実行だけで100kトークンに達することがある
- ベンダーは200k、1M、2Mのコンテキストウィンドウを宣伝するが、この数字が利用可能な作業セットを意味するわけではない
- 大きなコンテキストウィンドウは、ほとんどマーケティング上の数字に近い
- その背後のアーキテクチャは動作するが、基本的な注意機構が実際には解決できていない問題を覆い隠している
- 製品表示の数字はリリースごとに大きくなるが、使える部分は同じ速度では追いつかない
- RULERとChromaのcontext rotレポートは、有効コンテキストが宣伝された数字の一部でしかないことを示している
- コンテキストウィンドウを埋めるほど性能は段階的に低下する
セッションを短く保つ作業方法
- 最新のエージェントは、長いセッションを扱うために自動圧縮機能を備え始めている
- Claude Codeはセッションが長くなると履歴を要約して再スタートするauto-compactを実行する
- この方式は役に立つが、すでに鈍い領域で時間を過ごした後に動作する
- 要約自体も、すでに性能が低下したモデルが生成する
- より良い引き継ぎ方法は、新しいセッションを開き、手書きの仕様書を渡すことだ
- 手書きの仕様書は、自動要約よりもシグナルの強い引き継ぎ資料になる
- 今後何が重要かを人間が直接決められるからだ
- この方式は、次のセッションや次の担当者がきれいに引き継げる成果物を残すbreadcrumbアプローチに当たる
- obra/superpowersとmattpocock/skillsは、小さく名前の付いた成果物を中心にエージェントのワークフローを構成している
- PRD、計画、スキル、サブエージェントへの引き継ぎがこうした成果物に当たる
- 各成果物は情報をライブセッションの外へ移し、次のセッションが読めるようにする
- この方式は、作業セッションがスマート領域に留まるのに役立つ
- コンテキストウィンドウは予算のように扱うべきだ
- 実際に役立つ部分は前方の一部チャンクだけだと考える
- ライブセッションからwritten artifactへ移した情報は、モデルの注意力が競い合う対象を減らす
2件のコメント
10万どころか、4〜5万トークン程度でも手に余っているのが見て取れます
Hacker Newsの意見
AIの基本を学ぶこと自体はかなり楽しいが、今進んでいる方向には同意できない。
こういうスレッドのコメントがどれほど不安を感じさせるか、言葉にするのは難しい。「XYZは自分にはこうだった」という善意の体験談が、Facebookのペットの世話や料理スレッドの助言のように見える。
3DプリンティングのFacebookグループはさらにひどいが、プリントはしていても実際に何が起きているのか理解したい人なら、何を言いたいかわかると思う。
LLMの世界、とくにクラウドLLMの世界では、共有された厳密さが完全に崩れ去り、結局は呪術的な模倣にまで縮んでしまったように感じる。誰もが他の誰より正しいとも間違っているとも言えなくなる。
「コンテキストをDawn食器用洗剤で洗って乾かしてから、のりスティックを一層塗ってみましたか？」というような雰囲気だ。
助けようとしている人たちをあまりきつく言いたいわけではない。ただ、他の話題のスレッドとあまりにも違って感じる。普通は誰かの提案を他の人たちが議論したり磨いたりして、bashのヒストリ選択方式のようなものを誰かが説明して人生が変わることもあるのに、こういうスレッドは結局「脅せば効くのっておかしくないですか？」に流れていく。
LLMワークフローの恣意的で非決定的な性質は本当に気持ち悪い。長く組み込み／システム寄りをやってきた人間として、これまでは常に決定性と再現可能性を優先してきた。
それでもエージェントはすごいし、「思考プロセスの設計者」になるのも楽しい。もう元には戻らないだろう。今日AI開発が止まったとしても、自分のキャリアは以前と同じではないはずだ。
テック業界では、LLMが登場するずっと前からこういうことは常にあった。
客観的で測定可能な基準ではなく、「少し有名な会社がそうしているから」で決まる会議をあまりにも多く経験してきた。その会社が実際にはそのやり方を一般的に採用していないという証拠でさえ、驚くほど力を持たなかった。
ITの助言には、もともとある程度こういう面があった。システムと結果が複雑になるほど、「より良い」と「より悪い」を明確に定義しにくくなる。
そこにLLMが強く非決定的だという事実まで加わると、LLMの助言は事実上、園芸の助言のようになる。
さらに「ベンチマーク」ですら、多くは誰かの感覚をある程度うまく結晶化しようとする試みに近い。
そのもどかしさには大いに共感するし、おおむね同意する。LLMベースのワークフローを形式化しようとするたびに、なぜあるものはうまくいって、あるものはうまくいかないのかを誰も本当にはわかっていないようで、また失望させられる。
だから結局
/planに戻って、「実装を繰り返す前に、後のためにMarkdown文書に書いておけ」と指示し、来月あたりにはもっと厳密で合理的な根拠のある何かが出てくることを期待する。のりスティックはまったく使っていない。必要がないからだ。ただ、DawnはBambuのビルドプレートを再びよく密着させるのにかなり効果があるようだ。わざわざ探して使ったわけではなく、食器洗い用としてすでに家にあった。IPAが効かなかったのでDawnを試してみたところ、何度も出力物が再びよく密着するようになった。まだN=30まではいっていない。
頭の中にある「共有された厳密さ」自体が幻想で、LLMとそのコンテキスト問題がそれを露わにしているだけなのかもしれない。
何十年も生きてきたテック業界で、厳密さをほとんど見たことがない。道具は増え、パラダイムは生まれては死に、また現れ、何かを測る物差しには単位の違う競合する物差しがある。電力と信号の物理、シリコンウェハの支配的コストを越えてしまえば、もっと古い少数学問と比べて、私たちはほとんど皆、熟練度が違うだけの修理屋に近い。
コンテキストの限界には比較的うまく対処してきた。仕様を定め、範囲を制限すればよい。LLMが良い結果を出すには、明確な仕様と強いガイダンスが必要だ。
しかし、これも現時点の場当たり的な実務感覚にすぎない。もしかすると90日後にはこの負担すら消え、簡単なプロンプト一つで世界水準のオペレーティングシステムとプログラミング言語、さらにその両者のための数学的形式基盤まで生成できるようになっているかもしれない。
エージェントループに単純な制約を1つ課すことで、コンテキストサイズの問題を避けている。ユーザーの最上位会話スレッドでは、すべてのツール呼び出しを禁止する。ツール呼び出しが必要な作業はエージェントの再帰呼び出しの中でのみ行い、結果だけを呼び出し元に返すようにしている
100万LOCを超えるコードベースでも、同じ高レベルの会話を一日中続けながら、意味のあるトークン上限に達したことはなかった。圧縮や要約のコツも不要。再帰呼び出しで5000万トークン使っても、ルート会話スレッドは10万トークンにも触れずに済む
エージェントが再びNarniaへ降りていくたびに「ブートストラップ」するやり直しは必要だが、常にすべてを詰め込もうとする巨大な平面コンテキストを持ち歩くより、はるかに効率的だ
再帰はトークン使用量の制御に非常に効果的だが、限界もある。再帰の深さ1を超えて利益があったことはない。エージェントが何度か試みるのは見たが、実際の性能は出なかった。外部の記号的再帰は最前線のモデルが学習した対象ではないようだ。コンテキスト内で再帰を真似るのは得意だが、トークン使用量を減らすのが目的なら、それは望ましくない方向だ
この時点ではメイン会話は作業を調整する役割だけを担うことになる
問題解決やデータ分析の流れでよく見かけるが、データ収集と集計をサブエージェントに投げ、要約結果だけを持ち帰る
同様に、メインエージェントが設計文書やMarkdownファイルにコンテキストを保持しつつ進め、更新させることもある。そうすると、いつでも削除、再開、引き継ぎが可能になる
いわば末尾呼び出し最適化のある再帰に近い
ある意味では仕様駆動アプローチの一般化で、形式仕様に加えて引き継がれるバッファがメモリに残る
専門家でなくても、この「簡単なコツ」はコンテキスト問題を直し、トークン使用をはるかにきめ細かく制御できるようにしてくれそうだ。こういうヒントをHNコメントで共有してくれてありがとう。今後、知っている人たちのAIエージェントの使い方が変わるかもしれない。追いかけるのが大変だ
Anthropicがサブスクリプションプランで100万トークンのコンテキストウィンドウを提供して以降、Opusでこうした経験はしていない。普段から50万トークンをよく超えるし、ときどき80万トークン近くまで行ってもこの問題は見えない
本当の限界に近い90万トークン以上では多少見たが、投稿者が見たほど深刻ではなかった
そもそも単一の作業や、同じコンテキストを維持するほど関連した作業のまとまりでは、そこまでコンテキストウィンドウを埋めることはまれで、たいていは20万〜60万程度だ
こうした経験をする人がまったくいないという意味ではないが、ある人たちには名前まで付くほど頻繁に起きるというのは不思議に感じる
個人的には、Opusの賢い領域は6万トークン未満だと思う。Opus 4.7と4.8は、より細分化されたトークナイザーのせいでさらに悪い
品質は上昇傾向に見える
モデルやモデルのバージョンごとに異なるアテンション構造を使っており、これは長いコンテキスト性能に影響する。長期コンテキスト学習の量や種類も明らかに違うはずだ
エージェントごとにコンテキストの組み立て方やコンテキスト圧縮の実装も違う
同じモデル、同じエージェント／ハーネス、非常によく似た作業でない限り、コンテキストサイズに関するモデルの振る舞いの体験が同じになると考える理由はない
問題によっては大きなコンテキストウィンドウが機能することもあるが、30万未満の小さめのコンテキストに寄せたほうが効果的だと感じる
Opus 4.5は20万の上限に近づくとツール呼び出しが失敗し始め、Opus 4.6は混乱し始める前に約30万まで行けて、Opus 4.7は40万くらいまで伸ばせたが、その後に間抜けな領域が始まった。Opus 4.8では50万を楽に超えたセッションもあった
Fableは使った時間が限られていたが、80万〜90万まで問題なく行けたセッションも何度かあった
最近のバージョンのOpusは10万を超えても大丈夫だが、通常は20万未満に保つようにしている
だから、いわゆるメモリシステムはたいていモデルをより愚かにする失敗だと思う。モデルにはメモリがあるのではなくコンテキストがあるだけで、無関係な事実をコンテキストに押し込むほど、問題に使えるコンテキストは減っていく。邪魔が少ないほど結果は良くなる
エージェントに何かを覚えさせる方法は、人間の開発者が他の開発者に親切なプロジェクトを作るときのように、作業を文書化させることだ。索引ページのある優れた開発文書と、チェックリスト付きの良い計画を簡潔なMarkdownファイルとして保存し、リポジトリにコミットすることが、モデルにとって理想的なメモリであり、モデルがいったい何をしてきたのか把握するために必要な理想的な文書でもある。人間や他のモデルがコードレビューするときにも役立ち、欠点がない
だから「メモリを確認するよう覚えておけ！」がまたメモリに保存される。明らかにうまく機能しているシステムではない
ここのコメントのほとんどすべてが個人経験に訴えている。一方で元記事は、複数のモデルについて何らかの標準化されたテスト性能を比較した2本の研究を参照している。
それらのテストがどれほど優れているかは何とも言えないが、LLMの性能のように曖昧で主観的なものについての逸話的証拠より悪いはずはない
Chromaの結果ではSonnet 4が出ているが、私の経験でもSonnet 4はひどかった。Sonnet 4.5では完璧に動いた同じプロンプトが、Sonnet 4では悲惨な失敗に終わった。
最新の最先端モデルと公開ウェイトモデルの両方を含む新しいテストを見てみたい。最先端モデルは常に指示追従がうまく、話題から逸れにくいように見えるので、それを裏づけるデータがあるとよい
AIのプロダクトマネージャーのように振る舞い、作る機能ごとに短いPRDを書くよう強く求めるやり方で、かなり効果を感じている。
こうすると時間が経っても何が作られたのか参照できるし、各機能ごとに漂流しにくくなる。機能ごとに別の会話を持つ。
私にとっては、脱線を防ぎつつ必要なときに過去の決定を参照させる、ちょうどよい折衷案だ。Pocockのやり方で気に入らないのは、PRDをあまり書かず、まず深い議論でアラインメントを取る形になっていて、その最初の往復で最も良い時間帯を浪費しすぎることだ
私もまず計画を立てるほうだが、セッション内のToDoリストとして残るので、後から参照しにくい
エージェント内部で何が起きているのかを気にすることは、おそらく長くソフトウェア開発の一部ではあり続けないだろう。
個人的には、私はすでにLLMとエージェントをブラックボックスとして見ている。各機能要求を複数のLLMに与えて結果を比較している。「セッション」を手で書くことはない。結果だけを見る。気に入らなければ
git reset --hardしてプロンプトを変え、その機能要求を最初からやり直す。どのエージェントが最も優れているか継続的に感触をつかむためにログを残し、自分の要求を最もうまく満たすエージェントのELOスコアを計算している。私にとって重要なのはそのスコアであって、エージェントがどうやってそれを達成したかはそれほど重要ではない
セキュリティやその他の検証があまり必要ないフロントエンド作業の類いには向いているのかもしれないと推測する。
だが、規制産業や極度の慎重さが必要な作業には向いていないように思える
そう、コンテキスト管理が鍵だ。
独自フレームワークを作り、この問題のデバッグに多くの時間を費やしているが、絶対的なコンテキストサイズよりも、ウィンドウ内にゴミや誤った方向づけが入っていて、ユーザーが重要だと考える内容を覆い隠してしまう確率のほうが問題だ。
これは、LLMが直前のアプローチで失敗したことを何度も繰り返そうとする形で現れる。コンテキストウィンドウ内で何かが頻繁に出てくると、たとえそれが誤りでも重みを持ってしまう。
LLMに大量のツールを与えるのではなく、ツールを検索するためのツールを与える、といったコツもいろいろある。
しかし、より大きな解決策はプロセスにある。superpowersのようなものを使ってLLMを段階的に強制し、今後持ち越すコンテキストを制御しなければならない
Pi向けにごく小さな個人用拡張を作って、
/lastコマンドを追加した。セッション全体を消去し、エージェントの最後の出力メッセージだけを残す。これで手動の「圧縮」ができる。基本的にはエージェントに「話し合った計画を、編集すべきファイル参照付きで要約しろ」と言ってから
/lastを呼び、その後で実装するよう指示する。[1] https://pi.dev/
ここで「モデルたち」とひとまとめにするのは好きではない。モデルごとにアテンション構造が異なり、そのため長いコンテキストでの挙動にも大きな差が出る可能性がある。
長いコンテキストが問題で、ほとんどのモデルで品質低下が起きるという点には同意するが、古いモデルの挙動を新しいモデルにそのまま一般化するつもりはない