AIエージェントのためのコード検索：なぜベクトル埋め込みが失敗し、ファイルごとのLLMグラフが勝利するのか

AIコーディングツール向けのコードインデックスシステムを構築する1年間の実験で、明確な結果が得られた。コードチャンクへのベクトル埋め込みとTree-sitter AST解析にはどちらも重大な欠点があり、Neo4jグラフにセマンティック全文検索とともに格納されたファイルごとのLLM分析が最も効果的である。この知見は、RepoGraph（ICLR 2025）やCode-Craftなどの最近の論文とも一致する。

テストされたアプローチ

• コードチャンクへのベクトル埋め込み – 完全に破棄。決済サービス内のprocess()という関数と画像パイプライン内のprocess()は、互いに全く関係がないにもかかわらず、類似したベクトルに埋め込まれる。ベクトルはコールグラフ、継承、インポートなどの構造的関係を平坦化する。検索精度は許容できなかった。
• Tree-sitter AST解析 – 正確で高速だが、構造のみ。関数が存在し、何を呼び出すかは教えられるが、「この関数は失敗したStripe支払いのウェブフック再試行を処理する」という質問には答えられない。開発者がビジネス言語で質問する場合に不十分。
• ファイルごとのLLM分析 → グラフ – 機能する。各ファイルにLLM呼び出しを行い、purpose、summary、businessContextを生成し、Neo4jのノードとしてクラス、関数、キーワード、インポートへのエッジとともに格納する。検索にはベクトル類似性ではなく、それらのセマンティックフィールドを対象とした全文検索を使用する。SHA-256差分チェックにより再インデックスを変更されたファイルのみに制限し、初期コストを管理可能にしている。

文献からのベンチマーク

RepoGraph（ICLR 2025）は、グラフアプローチでSWE-benchの性能を+32.8%向上させることを示した。Code-Craftは、コードグラフからのボトムアップLLMサマリーを使用して、トップ1検索精度を+82%達成した。

既存ツールとの比較

チームはcomparison.mdで比較表を公開している。主な違いは以下の通り：

• Bytebell：ファイルごとのLLM → purpose + summary + businessContext + entities；Neo4j + MongoDBストレージ；SHA-256差分認識型再インデックス。
• PageIndex：長いPDF/ドキュメント向けのTOC推論ツリー；コード固有のセマンティクスなし。
• GitNexus：Tree-sitter AST + コミュニティ検出；オプションでシンボルごとのセマンティクス；LadybugDBを使用。
• GraphRAG：チャンクごとのLLMエンティティ + 一般テキスト（コード以外）向けのコミュニティクラスタリング。
• Sourcegraph/Cody：LSIF/SCIP検索インデックス；ノードごとのセマンティクスなし；デプロイはセルフホストまたはSaaS。
• Augment：埋め込みを使用したプロプライエタリなセマンティックインデックス；SaaSのみ；継続的インデックス管理。

オープンソース

このシステムはgithub.com/ByteBell/bytebell-ossでオープンソースとして公開されている。