記事一覧へ戻る
メモリ・コンテキスト

CodeNib:コードリポジトリ文脈を再利用可能なデータシステムへ

読了目安 3 分

導入

コーディングエージェントが実際のコードベースで作業するとき、時間とトークンの多くはコードの修正そのものではなく、「どこに必要な情報があるか」を探すことに使われる。grep で検索し、ファイルを読み、言語サーバーに問い合わせ、タスク内の履歴を保持する。しかし、それらはしばしば分断され、リポジトリが更新されるたびに同じ発見作業が繰り返される。CodeNib はこの問題を、単なる検索改善ではなくデータシステムの問題として捉える。

主なポイント

  • 複数ビューによるリポジトリ表現:CodeNib はリポジトリの各コミットに対して、語彙ビュー、密ベクトルビュー、構造ビューを構築する。語彙ビューはキーワード検索に、密ベクトルビューは意味的検索に、構造ビューはシンボル移動やコード関係の把握に向いている。
  • ソース範囲の統一:各ビューの出力は、リポジトリ相対のソース範囲へ対応付けられる。これにより、索引、言語サーバー、エージェント履歴の間で位置情報がばらばらになる問題を抑えられる。
  • ビューごとの増分保守:リポジトリが変化しても、常に全体を再構築するのではなく、選択されたビューを増分的に保守する。論文は 100 個のスナップショットで品質とコストの関係を調べ、出力が独立再構築と一致する場合に、グラフ更新とベクトル更新の中央値が再構築よりそれぞれ 8.7 倍、25.4 倍高速だったと報告している。
  • 単一ランタイムでの提供:CodeNib はランキング検索、シンボルナビゲーション、制限付きコンテキストを同じランタイムから提供する。正規化された live-server 位置と一致した静的ナビゲーションのサブセット、すなわち 1,000 リクエスト中 63% において、live/static のリクエスト単位の中央値レイテンシ比は 4.7 倍とされる。
  • トークン消費の削減:5 つのモデルに対して、選択されたコンテキスト方針はローカライズ品質を保ちながら、grep/read の組み合わせに比べて軌跡トークンを 50〜87% 削減した。

意義と影響

CodeNib の重要性は、特定の検索アルゴリズムよりも、コード文脈を管理可能な基盤として設計した点にある。エージェントは毎回ゼロからコードベースを探索するのではなく、更新可能な複数ビューを通じて必要な範囲だけを受け取れる。これは、推論や編集に使える予算を増やす方向に働く可能性がある。

一方で、結果の適用範囲も明確に限定されている。増分更新の高速化は独立再構築と出力が一致した場合に限られ、ナビゲーションの比較も互換性のあるサブセットに基づく。リポジトリ文脈の正しさは操作ごとに異なるため、この慎重な境界設定は実用上も重要である。

大規模で変化の速いコードベースにエージェントを長期的に適用するなら、CodeNib のような多視点コンテキストサービスは、モデルとリポジトリの間に置かれる標準的な基盤になり得る。

出典:Hugging Face Daily Papers

コメント

ログイン状態を確認中…

コメントを読み込み中…

関連記事

CCTest · Blog
Agent の記憶は検索だけではない:ACM が文脈管理をライフサイクル問題として再定義
メモリ・コンテキスト
cctest.ai

Agent の記憶は検索だけではない:ACM が文脈管理をライフサイクル問題として再定義

この論文は Agentic Context Management(ACM)を提案し、本番環境のエージェント失敗の多くは推論能力ではなく、推論コンテキストの管理不全にあると論じている。

続きを読む
CCTest · Blog
ReflectWorld-MM、動画記憶を「フレーム」から「実体」へ
メモリ・コンテキスト
cctest.ai

ReflectWorld-MM、動画記憶を「フレーム」から「実体」へ

ReflectWorld-MM は、連続する動画の中で誰が何度現れ、何が変わったのかを、実体単位で記憶することを狙った研究です。動画を切り出して保存する発想から、世界の出来事を整理して覚える発想へと移っています。

続きを読む