Securely indexing large codebases｜大規模コードベースの安全なインデックス化

**大規模コードベースの安全なインデックス化** セマンティック検索は、AIエージェントの性能を大きく左右する要素である。最近の評価では、応答精度が平均12.5%向上し、コード変更がコードベースに残りやすくなり、全体的なリクエスト満足度も上昇したことが確認されている。 Cursorはプロジェクトを開く際、セマンティック検索を可能にするためにコードベースの検索可能なインデックスを構築する。小規模プロジェクトではこれは瞬時に行われるが、数万ファイルを抱える大規模リポジトリでは、単純な方法ではインデックス作成に数時間を要し、作業の80%が完了するまで検索機能は利用できない。 この課題に対し、開発チームは「ほとんどのチームはほぼ同一のコードベースのコピーで作業している」という観察に基づき、インデックス化の高速化を図った。実際、同一組織内のユーザー間では、同じコードベースのクローンは平均92%の類似性を示す。 つまり、新たなメンバーが参加したりマシンを切り替えたりする際に毎回一からインデックスを再構築するのではなく、**チームメイトの既存のインデックスを安全に再利用**できる。これにより、最大規模のリポジトリでも、初回検索までの待機時間が数時間から数秒に短縮される。 Cursorはコードベースの最初の状態を**マークルツリー**を用いて把握する。このツリーには各ファイルの暗号学的ハッシュに加え、子要素のハッシュに基づいて計算された各フォルダのハッシュが含まれる。これにより、変更されたファイルやディレクトリを全体を再処理することなく正確に検出できる。 クライアント側での小さな編集が行われた場合、変更されたファイル自体と、ルートに至るまでの親ディレクトリのハッシュのみが更新される。Cursorはこれらのハッシュをサーバー側のバージョンと比較し、両方のマークルツリーがどこで分岐したかを正確に把握する。ハッシュが異なるエントリのみが同期され、一致するものはスキップされる。この同期プロセスでは、クライアント側のファイルが変更されることはない。 マークルツリーのアプローチにより、各同期で転送する必要のあるデータ量が大幅に削減される。5万ファイルのワークスペースでは、ファイル名とSHA-256ハッシュのみで約3.2MBとなるが、ツリー構造を用いることで、ハッシュが異なるブランチのみを走査すれば済む。 ファイルが変更されると、Cursorはそれを**構文上のチャンク（塊）に分割**する。これらのチャンクはセマンティック検索を可能にする**埋め込み表現（エンベディング）** に変換される。この埋め込みの作成が計算コストの高いステップであるため、Cursorはこれを非同期でバックグラウンド実行する。 ほとんどの編集では、チャンクの大半は変更されない。Cursorはチャンク内容ごとに埋め込み表現をキャッシュする。変更のないチャンクはキャッシュがヒットするため、推論時に再計算するコストをかけずに、エージェントの応答を高速に保つことができる。結果として

大規模コードベースの安全なインデックス化

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト