アーカイブ / RAG
Javaコードの利用元をたどる検索手法DKB:構文木から作るグラフの効果と費用
DKB
DKBの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
(a) Deterministic AST-derived ontology graph (DKB).
概要
- DKBはJavaの構文木から依存関係のグラフを作り、質問時に依存先と利用元の両方をたどる。
- 著者によるShopizerの15問の判定では、DKBが15問正答、LLM-KBが13問正答・2問部分正答、No-Graphが6問正答だった。
- ShopizerではLLM-KBの抽出結果から377ファイルが欠けた。回答の正誤と併せて、索引の取り込み範囲や遅延を確認する必要がある。
補足:編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、DKBの仕組み
- 01Javaソースと質問
- 02構文木で関係作成
- 03類似検索と関係探索
- 04根拠コードで回答
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
DKBは、Javaコードのクラス間の関係をたどり、設計や処理の流れに関する質問へ回答する材料を集める方法だ。RAGとは、回答を作る前に外部の情報を検索する仕組みを指す。
質問と意味が近いコード片だけを探すと、別ファイルにある呼び出し側を見落とす場合がある。例えばサービスを使う制御クラスを知りたいときは、実装だけでなく、そのインターフェースや利用元まで調べる必要がある。
手法
まずTree-sitterでJavaソースを解析し、構文木を作る。構文木は宣言などを文法上のまとまりとして表したものだ。DKBはプロジェクト内の型を見つけ、継承、インターフェースの実装、フィールドやコンストラクタ引数に現れる依存関係を抽出する。クラスなどを点、関係を向きのある線として結ぶグラフに記録する。
質問時は、意味の近さで見つけたコード片を起点に、依存先と利用元を調べて回答用のコードを集める。例えば買い物かごの実装が見つかれば、それが実装するインターフェースへ進み、その利用元も探す。こうして集めた関係情報とコードを回答の材料にする。
新規性
DKBの特徴は、Javaの文法構造から依存関係を抽出し、検索で見つけたクラスから依存先と利用元の両方へ探索を広げる点にある。実装クラスからインターフェースを経由し、その利用元を探す処理も含む。
著者は回答の正誤に加え、索引に取り込めたファイルやコード片の数を比較した。関係抽出時の欠落が、その後に検索できる範囲へ及ぶことを実行記録で示している。
従来手法との違い
No-Graphは、コードを分割した片から質問に意味が近いものを検索し、関係のグラフは使わない。LLM-KBは大規模言語モデル(LLM)に各Javaファイルの要素と依存関係を抽出させ、検索時に関連コードを加える。
DKBは関係を構文木から作る。Shopizerでのグラフ作成時間はDKBが2.81秒、LLM-KBが200.14秒。索引全体ではそれぞれ22.09秒、215.09秒で、LLM-KBは抽出漏れにより取り込んだコード片も少ない。
実験結果
著者はShopizer、ThingsBoard、OpenMRS Coreで、各リポジトリに合わせた設計・コード追跡の15問を用意し、同じリポジトリ内では3方式に同じ質問を与えた。索引作成時間、質問遅延、取り込み範囲、費用、回答の正誤を調べている。
Shopizerの正誤判定はDKBが15問正答、LLM-KBが13問正答・2問部分正答、No-Graphが6問正答だった。平均質問遅延は順に10.51秒、13.36秒、9.52秒。LLM-KBで抽出に成功したファイルは1210件中833件で、コード片は3465件、No-Graphの5403件に対して64.1%だった。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案:社内のJavaサービスで「買い物かごの処理を使う画面側の入口はどこか」という調査を支援する。入力は調査対象のJavaソースと質問、出力は候補となるクラス、関係、根拠コードを添えた回答とする。
必要な元データは対象リポジトリのソースで、追加の学習データ、学習用ラベル、センサーは想定しない。現場で使う依存関係の書き方に抽出規則を合わせ、担当者が候補をコードで確認する。調査時間の短縮は検証すべき仮説である。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案:対象のJavaリポジトリから、利用元の特定を含む質問を少数選ぶ。必要な元データはJavaソースで、担当者が正解のクラスと根拠コードを評価用ラベルとして記録する。追加の学習データやセンサーは使わない。
同じ質問を類似検索のみの方式とDKB型の方式に与え、必要なファイルの取り込み、回答の正誤、質問遅延、索引作成時間を比べる。導入先の書き方に合わせて抽出規則を調整し、拾えなかった関係も記録する。
限界と課題
著者が報告する制約として、LLM-KBは入力をまとめる際にファイル内容を切り詰めており、Shopizerでは377ファイルが抽出結果から欠けた。DKBの質問遅延も一定ではなく、OpenMRS Coreでの最大値は37.15秒だった。
編集上の検証事項は、自社コードの依存関係を抽出できるか、探索で増えたコードが回答に役立つかである。正誤の内訳を確認できるのはShopizerの15問であり、他のリポジトリに同じ正答数を当てはめることはできない。
出典
元のタイトル・要旨を確認する(英語)
Reliable Graph-RAG for Codebases: AST-Derived Graphs vs LLM-Extracted Knowledge Graphs
Retrieval-Augmented Generation for software engineering often relies on vector similarity search, which captures topical similarity but can fail on multi-hop architectural reasoning such as controller to service to repository chains, interface-driven wiring, and inheritance. This paper benchmarks three retrieval pipelines on Java codebases (Shopizer, with additional runs on ThingsBoard and OpenMRS Core): (A) vector-only No-Graph RAG, (B) an LLM-generated knowledge graph RAG (LLM-KB), and (C) a deterministic AST-derived knowledge graph RAG (DKB) built with Tree-sitter and bidirectional traversal. Using 15 architecture and code-tracing queries per repository, we measure indexing time, query latency, corpus coverage, cost, and answer correctness. DKB builds its graph in seconds, while LLM-KB requires much longer graph generation. LLM-KB also shows indexing incompleteness: on Shopizer, 377 files are skipped or missed, reducing embedded chunk coverage and graph size compared to DKB. End-to-end cost is modest for DKB relative to the vector-only baseline but much higher for LLM-KB, especially as repository scale increases. Query latency is similar for No-Graph and DKB, while LLM-KB is slower and more variable. On the Shopizer question suite, DKB achieves the highest correctness, LLM-KB is close behind, and the vector-only baseline performs worst on upstream architectural queries and has the highest hallucination risk. Overall, deterministic AST-derived graphs provide more reliable coverage and multi-hop grounding than LLM-extracted graphs at substantially lower indexing cost.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新:2026-10-01




