アーカイブ / LLM / RAG
コードをファイルからフォルダへ要約し、階層ごとに検索するRAG手法
Bottom-Up Knowledge Aggregation
Bottom-Up Knowledge Aggregationの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Figure 1: Workflow for generating Implicit Knowledge from a given set of hierarchical files
概要
- ファイルの説明を生成し、子の説明から親フォルダの説明を作って、各階層をRAGの検索対象にする。
- 著者らの10問の評価では、検索用文書数が490件から156件に減り、フォルダ単位のE-F1は0.23から0.28になった。
- 結果はGMの一つの非公開コードリポジトリで得られたもので、別のコード群での精度や更新時の運用には検証が必要だ。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、Bottom-Up Knowledge Aggregationの仕組み
- 01コードとフォルダ階層
- 02各ファイルの説明
- 03親フォルダの説明
- 04検索して回答
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
この手法は、ファイルとフォルダが階層をなすコードリポジトリに、自然な言葉で質問するためのものだ。RAGは質問に関連する文書を探し、その内容を大規模言語モデルに渡して回答を作る方法を指す。
生のコードを検索用の文書にすると、長いファイルを扱う必要があり、フォルダ全体の役割も文書から捉えにくい。著者らが扱った車両シミュレーション用リポジトリは、長年集めた多様なファイルからなり、全体に一貫した整理がないという。
手法
まず、木構造の末端にある各ファイルを大規模言語モデルに渡し、ファイル用の指示文に沿って説明を作り、知識ベースに保存する。木構造は親フォルダと子の関係を表し、知識ベースは検索する文書の集まりだ。指示文には、スクリプトの関数、入出力、パラメータなどを説明する項目がある。
次に、同じ親フォルダに属する子の説明を集め、フォルダ用の指示文で全体の説明を作る。これを最上位まで繰り返し、各階層の説明を検索対象にする。たとえば「TrackとCoastの空力データを扱うファイルはあるか」という質問には、関連文書を検索し、その内容をモデルに渡して回答を生成する。
新規性
提案の中心は、ファイルの説明を個別に作るだけで終えず、子の説明を集約して親フォルダの説明を作り、根まで各階層を検索対象にする点にある。複数のファイルにまたがる質問に対し、フォルダ単位の文書を用意できる。
著者らが「暗黙の知識」と呼ぶのは、モデル内部の記憶ではなく、元のコードから生成して知識ベースに保存する説明文だ。階層をたどって得た内容を、検索可能な文書へ変換する。
従来手法との違い
比較対象は、コードの生の内容とファイル名・パスなどのGitHubメタデータを、ベクトルデータベースへ直接登録するRAGである。ベクトルデータベースは、質問に関連する文書を探すための保存先を指す。
提案法は、登録する内容をファイルとフォルダの説明に替える。検索した文書を基に回答を作る点は共通だが、提案法には事前の説明生成が加わる。比較はGMの一つの非公開リポジトリと、その内容に関する質問で行われた。
実験結果
著者らは、GMの非公開コードリポジトリについて、ファイル単位とフォルダ単位の質問を各5問用意し、分野の担当者が正解を確認した。回答と正解の語の重なりをBLEU-1、語の適合率と再現率を合わせたE-F1、正解中の語が回答に現れる割合として定義したEMで評価した。
従来法、提案法の順に、フォルダ単位のE-F1は0.23、0.28、EMは0.54、0.81だった。ファイル単位のBLEU-1はともに0.21、EMは0.61、0.60で、提案法がわずかに低い。検索用文書数は490件、156件だった。著者らの結果は、このリポジトリと10問での比較である。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：車両シミュレーション用の社内コードで、担当者が「目的の処理を行うファイルはどれか」と尋ねる探索支援に使う。閲覧を許可されたコードとフォルダ構造を入力に、関連するファイル名やフォルダの説明を踏まえた回答を出す。
新たなモデル学習用データはこの案の前提にせず、対象コードから説明を生成する。評価には担当者が確認した質問と正解のラベルが必要で、センサー入力は使わない。別のコード群では、説明生成の指示文を内容に合わせて調整する。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：閲覧許可のある小規模なコード群とフォルダ構造を用意し、生のコードとファイル名・パスを登録する方式を比較基準にする。同じ範囲で、ファイルから親フォルダへ説明を作る方式も構築し、対象コードに合わせて指示文を調整する。
担当者がファイル単位・フォルダ単位の質問と正解ラベルを作り、両方式へ同じ質問を与える。必要な原本はコードと階層で、追加の学習用データやセンサー入力は設けない。回答の事実関係、ファイル名の欠落、文書数を測り、コード更新後に説明が追随するかも確かめる。
限界と課題
著者らは、実験対象が特定のコードリポジトリに限られると述べる。また、検討した説明の形式は単純なMarkdownであり、説明の詳しさと回答性能の兼ね合いや、階層を持たないグラフへの適用を今後の課題としている。
編集上の検証事項は、要約時に重要な関数名や条件が落ちないか、コード変更後に親フォルダまで説明を更新できるかである。文書数の減少だけでは、説明の生成・更新にかかる作業量や、検索から回答までの時間は判断できない。
出典
元のタイトル・要旨を確認する（英語）
Is Implicit Knowledge Enough for LLMs? A RAG Approach for Tree-based Structures
Large Language Models (LLMs) are adept at generating responses based on information within their context. While this ability is useful for interacting with structured data like code files, another popular method, Retrieval-Augmented Generation (RAG), retrieves relevant documents to augment the model's in-context learning. However, it is not well-explored how to best represent this retrieved knowledge for generating responses on structured data, particularly hierarchical structures like trees. In this work, we propose a novel bottom-up method to linearize knowledge from tree-like structures (like a GitHub repository) by generating implicit, aggregated summaries at each hierarchical level. This approach enables the knowledge to be stored in a knowledge base and used directly with RAG. We then compare our method to using RAG on raw, unstructured code, evaluating the accuracy and quality of the generated responses. Our results show that while response quality is comparable across both methods, our approach generates over 68% fewer documents in the retriever, a significant gain in efficiency. This finding suggests that leveraging implicit, linearized knowledge may be a highly effective and scalable strategy for handling complex, hierarchical data structures.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01