アーカイブ / RAG / LLM
関数やクラスの構造に沿ってコードを分割するcAST：検索と生成の評価結果
cAST
cASTの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Figure 1: Syntax-agnostic chunking often omits crucial information needed to generate functional code. In this example, fixed-size chunking breaks the structure of the compute_stats method, causing the model to lose context regarding its return value. As a result, the model generates incorrect code based on a mistaken assumption of what is returned. In contrast, when given syntax-aware chunks, the model accurately identifies the return values and integrates them correctly within the existing codebase.
概要
- cASTは抽象構文木を使い、関数やクラスの構造に沿って検索用コード片を作る。
- 著者らの表1では、RepoEvalのGIST-baseによるRecall@5が固定長分割の70.7から75.0になった。
- 上位の構文文脈や実行時の動きは分割判断に含まれず、利用先のコードでは別途検証が必要である。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、cASTの仕組み
- 01ソースファイル
- 02構文木に解析
- 03大きな節を再分割
- 04隣接節を結合
- 05検索用コード片
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
cASTは、既存コードを検索して生成モデルに渡す「検索拡張生成」の前段で、ソースファイルを検索可能な片に分ける方法である。分割位置は、モデルが補完や修正の際に参照できるコードの範囲を左右する。
固定長の分割では、関数やクラスの途中に境界が入ることがある。必要な返り値や処理の一部が別の片になれば、検索で片方だけを取り出したときに判断材料が欠ける。
手法
入力はソースファイルと、各コード片の大きさの上限である。まずtree-sitterで抽象構文木に解析する。抽象構文木とは、関数やクラス、条件分岐などを親子関係のある節で表した構造である。
上限に収まらない大きな節は下位の節へ再帰的に分け、隣り合う小さな節は上限内でまとめる。大きさは行数ではなく空白を除いた文字数で測る。例えば長いクラスが一片に収まらなければ内部を分け、得られた片を後段の検索器が取り出して生成モデルに渡す。
新規性
cASTの特徴は、コード検索の前処理に抽象構文木の階層を使い、分割と結合を大きさの上限に応じて行う点にある。可能な範囲で関数などの構文単位を一つの検索用コード片に収める。
著者らは、分割片を順につなぐと元のファイルをそのまま再現できることも設計目標にしている。既存の検索・生成の流れで、検索対象となる片の作り方を置き換える方法である。
従来手法との違い
比較対象は、コードを一定の大きさで区切る固定長分割である。著者らの図では、この分割がメソッドの途中に入り、返り値の情報を見失った生成モデルが誤ったコードを作る例を示している。
cASTは、構文上のまとまりと大きさの上限を両立させるよう境界を決める。表1は複数の検索器・生成モデルで両方式を比べているが、個別の評価値には改善しない条件もある。
実験結果
著者らは、ファイル内のコード補完を扱うRepoEval、別ファイルを参照するCrossCodeEval、単一ファイルの編集で解ける300問のSWE-bench Liteで評価した。表1では固定長分割と比べ、RepoEvalのGIST-baseによるRecall@5が70.7から75.0、SWE-benchのBGE-baseとClaudeによるPass@1が13.7から16.3だった。
Recall@5は上位5件の検索結果に関する再現率、Pass@1は1回の生成で課題を通過した割合を示す。一方、RepoEvalのBGE-baseによるnDCG@5は71.3から71.1となった。検索順位も評価に含むこの指標では、同条件で改善していない。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：社内リポジトリの既存関数を参照して、単一ファイルの修正案を作る支援に試す。入力は検索を許可したソースコードと修正依頼文、出力は参照したコード片と修正案とする。
対象言語の構文解析を確認し、ソースコードをcASTで分割してから依頼文に合う片を検索する。追加のモデル学習用データやセンサーは想定しない。検証には、過去の修正依頼と正解の変更箇所を示すラベルが必要になる。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：対象リポジトリのソースコードを用意し、対象言語を構文解析できるか確かめる。同じ検索器と生成モデルを使い、固定長分割とcASTで検索以降の条件をそろえて比較する。追加学習用データやセンサーは使わない計画とする。
過去の修正依頼、正解の変更箇所を示すラベル、実行して成否を確認できる課題を準備する。必要なコード片が検索上位5件に入る割合、修正案が課題を通る割合、解析できないファイル数を測る。文字数上限も記録し、分割方式以外の差を確認する。
限界と課題
著者らが挙げる限界は、上位の構文単位が持つ文脈を各コード片に明示していないことと、主にコード本文を対象にしていることである。コメント中の説明など別の表現や、実行時の動きも分割判断には取り込んでいない。
編集上の検証事項は、対象言語を解析できる範囲、短い片から修正に必要な文脈を得られるか、実際の修正依頼で成果が変わるかである。示されたベンチマークの結果を、そのまま社内コードの改善値とは扱えない。
出典
元のタイトル・要旨を確認する（英語）
cAST: Enhancing Code Retrieval-Augmented Generation with Structural Chunking via Abstract Syntax Tree
Retrieval-Augmented Generation (RAG) has become essential for large-scale code generation, grounding predictions in external code corpora to improve actuality. However, a critical yet underexplored aspect of RAG pipelines is chunking -- the process of dividing documents into retrievable units. Existing line-based chunking heuristics often break semantic structures, splitting functions or merging unrelated code, which can degrade generation quality. We propose chunking via Abstract Syntax Trees (\ourwork), a structure-aware method that recursively breaks large AST nodes into smaller chunks and merges sibling nodes while respecting size limits. This approach generates self-contained, semantically coherent units across programming languages and tasks, improving performance on diverse code generation tasks, e.g., boosting Recall@5 by 4.3 points on RepoEval retrieval and Pass@1 by 2.67 points on SWE-bench generation. Our work highlights the importance of structure-aware chunking for scaling retrieval-enhanced code intelligence.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01