1M contextは記憶力ではない、agent運用で見える限界

大きなcontext windowは、agentツールで最も目立つ数字の一つだ。200K、1M、2Mトークンと聞くと、コードベース全体と長い指示を一度に保持できるように見える。Garrit Frankeの記事がHacker Newsで読まれたのは、その期待と実作業のずれを具体的に言語化したからだ。

記事はcontext windowの中に「smart zone」と「dumb zone」があると説明する。前半ではモデルが指示や細部を比較的よく扱えるが、窓が埋まるにつれてattentionが弱まり、少し前に与えた条件も落とし始める。筆者は、その実用上の境界が広告上の最大値ではなく、およそ100Kトークン付近で現れると見る。

コーディングagentではこの問題が早く来る。ファイル読み込み、長いログ、テスト出力、ツール履歴、会話の寄り道が重なると、1つのセッションはすぐに大きくなる。自動圧縮や要約は助けになるが、品質が落ちた状態のcontextから作られた要約なら、重要な判断を落とす可能性がある。

対応策は、窓を大きくすることだけではない。人が書いたspec、plan、handoff noteのような小さなartifactに判断を移す方が信号密度は高い。次のセッションや次の担当者が、長い履歴を掘らずに重要点から始められる。

HNの議論も、大きなcontextは便利だが万能ではないという方向だった。実効性能は窓の大きさだけでなく、情報の置き方、圧縮、検索、そして決定事項を外部化する習慣に左右される。agent開発ではcontextを無制限の倉庫ではなく、予算のある作業メモリとして扱う必要がある。

出典: Don’t trust large context windows. HN議論: item 48524620.