LLMがコードベース全体を理解してくれればいいのでは？: バンドリングによるRAGの試み
(gist.github.com/atjsh)> 「この記事では、多数のファイルを含むTypeScriptコードベースをバンドリング（bundling）によって1つのJavaScriptファイルに圧縮したうえでLLMに渡したとき、LLMがコードベースに関する質問へどれほど正確に回答できるかを確認する。」
- NestJSベースのWebサーバーコードベースを1つ用意
- esbuildでコードを圧縮（バンドリング）
- 圧縮されたコードをpromptに埋め込む
- ChatGPT o3-miniにプロンプトを渡す
- コードベースに関する質問にどれほど正確に答えるかを確認
- Swagger生成テスト: ほとんどの試行で、21個のエンドポイントのうち19個以上のエンドポイントを正確に文書化することに成功
- APIエンドポイントの説明要求テスト: 非開発者向け／開発者向けマニュアルの生成に成功
- 限界点は存在
- 結論
> 「LLMに対してコードベース全体をRAGするため、コードベース全体を1つのファイルに圧縮してLLMへ渡すテストを設計した。
>
> 既存のバンドリングツールをそのまま使ってコードベースを圧縮した場合でも、LLMはコードベース全体のAPIドキュメントを作成したり、特定のAPIに対する詳細なマニュアルを書いたりできた。
>
> コードベース圧縮の過程で発生する情報損失については、元のファイルに対する追加のSemantic searchによって補完できると見込まれる。」
8件のコメント
バンドルしたファイルをプロンプトに入れたり、アプリケーションに添付してLLMにクエリしたりすることをRAGと言えるのでしょうか？ どの部分がRetrievalに当たるのか気になります
私も似たような考えです
バンドルしたファイルをもとに、LLMがretrievalして元のコードを持ってくるということではないですか？
興味深いですね。minifyされた js でもある程度うまく認識するのですね。https://ja.news.hada.io/topic?id=19552 や https://ja.news.hada.io/topic?id=19540 で紹介されたツールなどを活用して、ディレクトリ構造を追加のコンテキストとして提供してあげてもよさそうですね。
最近はLLMとコーディングをかなり多くやっているので、いつも効率的な情報伝達をどうするか悩んでいるのですが、興味深い実験をありがとうございます。
海外では codebase の syntax を graph として抽出してクエリしていた試みもありましたが、
バンドリングのほうがもう少し一般的に適用しやすい方法な気がしますね。（その言語がバンドリングをサポートしているなら）
https://x.com/daniel_mac8/status/1908332949251948808
ただ、最近は gemini の性能がとても良いので、o3 と比較してみるとさらに興味深い気がします。
興味深く読みました。バンドルされたソースコードからビジネスロジックをここまで抽出できるとは……。SPAで作成されたWebアプリのリバースエンジニアリングのコストも画期的に削減されそうです。
読んでみようとしたら、ブログが現在 500 エラーになっていますね
ブログが不安定なようです。アクセスできない方は、こちらの gist.github.com で内容をお読みいただけます。