JetBrainsが語るセマンティックコード検索のためのRAGパイプライン構築：解析、チャンク化、ベクトル化

JetBrainsは、セマンティックコード検索プラットフォームAir Contextの構築に関する開発者ダイアリーの第1部を公開しました。これは、LLMエージェントに「grepがたまたま拾い上げるものではなく、実際のリポジトリから正確で引用可能な証拠」を提供するRAGパイプラインです。Adam Malek氏とAshot Kazaryan氏が執筆した第1部では、解析、チャンキング、ベクトル化について説明しています。

なぜセマンティック検索なのか、grepではないのか

この記事では、キーワード検索とgrepが失敗する理由は、エージェントが事前に正確なテキストを知っている必要があるからだと主張しています。具体例として、「セッショントークンがどこで更新されるかを探しているエージェントは、コードに親切にも『refresh』という単語が含まれていることに頼ることはできない」という点が挙げられています。抽象的な領域を推論するには、エージェントは意味で検索する必要があります。RAGは意味を捉える形でソースコードをインデックス化し、エージェントが自由文検索を通じて必要な部分をオンデマンドで取得できるようにします。

解析とチャンキング

解析／チャンキングは前処理ステップであり、JetBrainsはこれを「しばしば見落とされがち」と呼んでいます。本番リポジトリには、それぞれ数百から数千行に及ぶ何千ものファイルが含まれており、エージェントは「多作な書き手」であることでコードベースをさらに膨らませます。ファイルには、関連性が異なる多くのクラス、フィールド、メソッドが含まれている可能性があります。

記事によると、間違ったアプローチは次のとおりです:

• ファイル全体の埋め込み — たとえファイルを埋め込みモデルに収められたとしても、検索はファイル全体を返し、特定の関数、シンボル、スニペットを見つけるという目標を損ないます。
• 行ごとの埋め込み — 個々の行は「周囲のコンテキストなしでは意味的に重要ではない」。一般的な関数名やコメントは「埋め込みに値せず、誤った検索結果を生み出す」ため、エージェントを重要でないマイクロ結果で過負荷にします。

目標は、適切にスコープされた単位です。エージェントの探索ワークフローは主に特定の関数、シンボル、コードスニペットの検索に関わるため、チャンクの境界はそれらの単位に合わせるべきです（記事の表現では「解析とチャンキングの細かいAST」）。

次に来るもの

これはシリーズの第1部です。著者らは、前処理からストレージ、エージェント統合までの各段階を、彼らが取った「回り道」も含めて取り上げる予定だと述べています。この記事はベクトル化段階の詳細を説明する前に途中で終わっているため、チャンクがどのように埋め込み表現に変換されるかについての続編が期待されます。

誰向けか

大規模なコードベース上でコーディングエージェント向けの検索を構築している開発者、またはコードRAGのチャンキング戦略を評価している人々。