ソースコード問い合わせのための長コンテキストLLM向けRAG手法の提案

IEICE KBSE 2024年5月研究会発表
2024-05-17

Transcript

1. ソースコード問い合わせのための 長コンテキストLLM向けRAG手法の提案 神谷年洋 (島根大学総合理工学部) KBSE 2024年5月研究会 @ 機械振興会館 1
2. 図: ChatGPT-4oの利用例 ソフトウェア開発とLLM（大規模言語モデル） ソフトウェア開発にもLLMは導入されている ChatGPT等のチャットUIのLLMにソースコードを 作成／修正してもらう LLMを応用したソフトウェア開発アシスタント ソースコード向けにファインチューニング／追加学 習したLLM LLMに入力するテキストを「プロンプト」、その出力 を「応答」と呼ぶ 2
3. 図 AutoGenの構成図 (文献より引用) LLMソフトウェア開発アシスタント Github Copilot IDEに組み込まれたLLMが、開発者が編集中のコードを参照して、コード生成やチャ ットによる応答を行う GitHub Copilot の概要, https://docs.github.com/ja/copilot/using-github-copilot/getting-started-with-github-copilot AutoGen LLMでコードを生成し、生成したコード を実行して結果をLLMにより分析して、 結果をコード生成AIに戻してコードを修 正する・・・の繰り返し 文献: AutoGen: Enabling next-generation large language model applications, Microsoft Research, 2023-09-25 Blog https://www.microsoft.com/en-us/research/blog/autogen- enabling-next-generation-large-language-model- applications/ 3
4. ソフトウェアの再利用 ソフトウェア開発にはライブラリの再利用が不可欠 再利用によりプロダクトは見かけより大きくなる 例えば、後述の実験で対象としたrich-cliは、プロダクト自体は900行だが、 ライブラリを含めると22万行 ライブラリの再利用は直接・間接的に行われる 不具合の原因の特定などでは、利用しているライブラリを含めて分析したい 4
5. ソースコードを入力するとエラーが多発する いざソースコードを入力して質問すると「入力が長すぎる」エラーが多発する プログラミング授業の演習問題程度の量ならともかく 2000行程度のソースコードをプロンプトに含めてエラーになった例 実際、多くのLLMのチャットUIでは、数千行くらいのソースコードしかプロンプト に含められない制限がある 5
6. コンテキスト = プロンプト ＋ 応答 ‧‧‧するプログラムを作成してく ださい 次のプログラムは‧‧‧ import os .... コンテキスト LLMには処理できるコンテキストの長さ の制限（コンテキスト長）がある コンテキスト長を超えると応答の内 容が悪くなる チャットUIのLLMではプロンプトの 最大長を制限している 代表的なLLMのコンテキスト長 （200kトークンまでのものが多い） LLM プロンプト長 gpt-4 ※1 8k 〜 128k Gemini 1.5 Pro ※2 1m Claude 3 ※3 200k Llama 3 ※4 8k Mistral v0.2 ※5 32k Mixtral v0.1 ※6 64k ※1 https://platform.openai.com/docs/models/ ※2 https://ai.google.dev/gemini-api/docs/models/gemini? hl=ja#gemini-1.5-pro ※3 https://www.anthropic.com/news/claude-3-family ※4 https://huggingface.co/meta-llama/Meta-Llama-3-8B- Instruct ※5 https://huggingface.co/mistralai/Mistral-7B-Instruct- v0.2 ※6 https://mistral.ai/news/mixtral-8x22b/ 原因: コンテキスト長 6
7. 図: アテンション行列の例 (文献より引用) コンテキスト長を大きくすれば解決？ ソースコードが100万行（≒ 7mトークン）なら、コンテキスト長10mトークンの LLMを用意すればLLMに問い合わせが可能になる？ 問題1: コンテキストの2乗に比例する計算時間 → 簡単にはコンテキストを長くできない LLMで利用されているTransformer系のNNでは、アテンシ ョンという機構が用いられている アテンションは、LLMが応答の次のトークンを生成するた めに、コンテキスト中のトークンのどれに注目して次のト ークンを生成するべきかを決定する コンテキスト＝プロンプトやこれまでに生成した応答 アテンションの実装にはアテンション行列が使われる。ア テンション行列の要素数＝コンテキストの長の2乗 文献: J. Adrián, G. García-Mateos. "Preliminary Results on Different Text Processing Tasks Using Encoder-Decoder Networks and the Causal Feature Extractor" Applied Sciences 10, no. 17: 5772. https://doi.org/10.3390/app10175772 (2020). 7
8. 図: アテンション行列を間引く例 (文献1より引用) 図: コンテキストの長さと応答の正確さ (文献2より引用) コンテキスト長を大きくすれば解決？ 問題2: 干し草の中の針(needle in a haystack)問題 アテンション行列を間引いて計算コストを下げることで、 コンテキスト長を大きくする工夫が種々提案されている ただし、 長いコンテキストを持つLLMであっても、入力テキスト が長くなるほどLLMの推論が低下すると報告されている 入力テキストの中から質問に答えるのに必要な箇所を 特定するのが、入力テキストが長いほど難しくなる 文献1: Jiayu Dingら, "LongNet: Scaling Transformers to 1,000,000,000 Tokens," https://www.microsoft.com/en-us/research/publication/longnet-scaling-transformers- to-1000000000-tokens/ , 2023. 文献2: M. Levy, A. Jacoby, Y. Goldberg, "Same Task, More Tokens: the Impact of Input Length on the Reasoning Performance of Large Language Models," arXiv:2402.14848v1, 2024. 8
9. 背景: RAG（検索拡張生成） RAG(Retrieval-Augmented Generation; 検索拡張生成) = LLM＋検索 ① 検索: 質問に関連するドキュメントを検索 検索の手法はweb検索や意味ベクトルによるものなど様々 ② 生成: 質問とドキュメントを含めたプロンプトをLLMに入力して応答を生成 RAGの利点 訓練データにないドキュメントに関する問い合わせの実現 ハルシネーション（幻覚）の軽減（応答の裏付けとなるドキュメントがある） 質問 解答 プロンプト 応答 質問 解答 プロンプト 応答 検索 LLM LLM 質問 通常の⽣成 9
10. 実行中に呼び出された関数のみ のソースコードを抽出する → LLMに入力するソースコード の量を削減 +α: 関数が 呼び出された順序 にしたがってソースコードを並 べる → LLMがソースコードを上から 順に読むだけで理解できるよう にする 実⾏中に呼び出された 関数のみのソースコード 関数が呼び出された 順序 プロダクトの実⾏ 提案手法 プロダクトの実行に関係するソースコードだけを抽出するRAG 10
11. ステップ1. プロダクトを実行し、実行 トレースを記録 ステップ2. 実行された関数やそれらの 呼び出し関係を特定 ステップ3. 関数のソースコード上での 位置を取得 ステップ4. 関数の呼び出し関係を表す コールツリーを作成 ステップ5. 問い合わせのテキストと、 コールツリー、対応するソースコードを プロンプトとしてLLMに入力し、応答を 生成 提案手法の処理 プロダクトのソースファイル 実⾏＆ 実⾏トレー ス取得 呼び出し関 係の特定 ソースコー ド位置の取 得 コールツリ ーの作成 実⾏トレース コールツリー ソースコード 応答 LLM プロンプト 問い合わせ 再現条件 ※ 発表当⽇の質疑 応答を受けて追加 11
12. 実験の概要 対象プロダクト（オープンソースのプロダクト）に対して次を用意する ソフトウェアの開発で起こり得ると想定される具体的な問い合わせ その問い合わせに対する応答の品質を評価する基準 4つの問い合わせ ✕ 提案手法のプロンプトとその変種(計5種類) ✕ 3つのLLM = 合計 60回の生成 問い合わせ: プロンプト1〜4まで。難易度が徐々に上がる 実験1: 提案手法のどの部分が応答の品質に寄与するか 実験2: 元のソースコードと比較してコンテキストのサイズを小さくできたか 12
13. 利用したLLM 長コンテキストを持つLLMを利用 LLM プロンプト長 Gemini 1.5 Pro 1M Claude 3 Sonnet 200K ChatGPT-4 128k 元となるソースコードが大きいため、RAGにより選別しても長コンテキストの LLMが必要だった 実験当時の各社の最新最上位モデル ※ ただし、Claude 3 Sonnetについては、実験実施時点で最上位モデルのOpusの200Kコンテキストのものが利用できなかったた め、ひとつ下位のモデルであるSonnetを利用 13
14. 対象プロダクト OSSのコマンドラインのツール rich-cli 機能: CSVやMarkdown, ReStructuredTextといったフォーマ ットのファイルを入力し、整形して ターミナルに出力する 選定の理由: 機能が豊富であり実験 に適切な規模。CLIツールであるた めに実行の再現性が高い 14
15. プロンプトの変種 提案手法ではプロンプトに、問い合わせのテキスト、コールツリー、ソースファイ ルを含めるが、それぞれを削除／変更した変種を用意する 変種 問い合わせ コーツルリー ソースファイル full ◯ ◯ ◯（関数の呼び出し順） A ◯（アルファベット順） C × ◯（関数の呼び出し順） CA ◯（アルファベット順） T ◯ × 提案手法のプロンプトは「full」 変種「CA」では、コーツツリーが含まれず、ソースファイルもアルファベット 順であるため、関数の呼び出し順に関する情報が含まれない 「関数の呼び出し順」にソースコードを並べたものは、ある関数が異なる関数から呼ばれるときには、その関数のソースコード を複数回含める。アルファベット順では、関数のソースコードは1回しか含めない 15
16. 実際のプロンプトの例 「CSVファイルを与えたときにテーブルに整形して出力する機能を修正しようと している」「テーブルの外観に関わる関数などを教えてほしい」 「コールツリーとソースコードを示す」 16
17. CSVファイルを整形してターミナルに表 示する機能について、外見を決めている 関数等、および、外見を変更する方法を 尋ねる 採点基準(①〜④につき各1.0点) ① 機能を実現しているクラスや関数の 名前を出力 ② テーブルの外見の要素として罫線以 外にも色やパディングなどがあることを 説明 ③ 変更の内容（変更後のコードまたは 変更の仕方）を出力 ④ 変更すべき箇所を関数名により出力 結果 多くのケースで4.0点（満点） 「＊」を付けた部分はデータ漏洩 （コンタミ）疑い プロンプトには含まれない識別 子が応答に含まれていた プロンプト1 17
18. データ漏洩（コンタミネーション） テストデータと同じものが訓練データに紛れ込んでいること 商用LLMは訓練データを明かしてない（ものが多い）ためデータ漏洩を直接確認 する方法がない データ漏洩の影響を調査として、新規にベンチマークを書き起こして評価すると LLMによってはベンチマークの成績が下がることが報告されている 文献: Hugh Zhangら, "A Careful Examination of Large Language Model Performance on Grade School Arithmetic", arXiv:2405.00332v3, 2024. 18
19. テーブルが含まれているMarkdownファ イルを整形してターミナルに表示する機 能について、外見を決めている関数等、 および、外見を変更する方法を尋ねる 採点基準はプロンプト1と同じ プロンプト1と似ているが、CSVフ ァイルよりMarkdownファイルのほ うが多くの書式を持つため、関連す るコードの量も多く、難易度が上が っている プロンプトの大きさも2倍になった （後述） 結果 全体的に評価値が下がった 各LLMについて、fullまたはAが最高 の評価値 プロンプト2 19
20. 2つの機能を比較する（CSVファイルを 整形して表示／テーブルが含まれている Markdownファイルを整形して表示） 採点基準(①〜④につき各1.0点) ① 実装の違いと共通点を説明 ② 制御フローの違いを示す重要な関数 やメソッドの名前を示す ③ 利用されているデータ構造の違いを クラス名で説明 ④ テーブルに関する両者の機能の違い （右寄せの有無など）を説明 プロンプトには、2つの実行の出力 を含めている 2つの実行を含んでいるため、プロ ンプトの長さは最大（後述） 結果 ChatGPT-4のfullの評価値が小さい ことが目立つ プロンプトの長さがLLMのコン テキスト長に近くなったことが 理由であると推測 プロンプト3 20
21. オプション --emoji が、テキストをコマ ンドラインで与えると機能するが、ファ イルで与えると機能しない。その原因と 修正方法を尋ねる 採点基準(①〜④につき各1.0点) ① 原因を出力 ② 変更の内容を出力 ③ 変更すべき箇所を関数名により出力 ④ 既存の機能を再利用した修正プラン を出力 2つの実行を含む 設計に関する知識を問う どこに機能を追加すべきか 再利用しつつ機能を実装する 結果 すべてのLLMでfullが評価値が最大 ChatGPT-4ではすべての変種で 同じだった プロンプト4 21
22. 0 1 2 3 4 full A C CA T Gemini 1.5 Pro Claude 3 Sonnet ChatGPT-4 AVE1 AVE2 実験1 分析 「提案手法のどの部分が応答の品質に寄与す るか」 各変種（full, A, C, CA, T）について、プロン プト1〜4の評価値を平均したグラフ 黒(AVE1, AVE2) すべてのLLMについて評 価値を平均したもの AVE2はデータ漏洩疑いを除いたもの それ以外は、LLM毎の評価値 全体（AVE）の傾向 ソースコードを含む変種fullやA ＞ 含まない変種T ソースコードを含む変種full, A, C, CAのうち、関数呼び出しの順序をデータとし て含む変種fullやAやC ＞ 含まない変種C 変種full, A, Cのうち、コールツリーを含む変種fullやA ＞ 含まない変種C 22
23. 実験2 分析 「元のソースコードと比較してコンテキ ストのサイズを小さくできたか」 元のプロダクト（22万行）と比較する と、変種fullでも1/20より小さい 仮に開発者が必要なソースファイルを 過不足なく指摘できたとしても（提案 手法は関数定義を単位として抽出する ため）より小さくなる LLMのコンテキスト長との比較 プロンプト3変種fullでは、ChatGPT-4の コンテキスト長の7割近くに達していて 応答の品質に影響した可能性？ 23
24. まとめ ソースコードに関する問い合わせを実現するためのRAGを提案 実行トレースから呼び出されている関数と呼び出しの順序を取得して、プロ ンプトにソースコードを含める 呼び出し順序はコールツリーとしても与える 22万行のPythonプログラムに対して適用する実験 コールツリー、ソースコード、関数の並び順も、応答の品質に影響する 効果的にコンテキストサイズを削減できる LLMのコンテキスト長には余裕が必要？ 課題・発展 オープンソースのLLMでも長コンテキストのものが登場しつつある より広範なプロダクトに適用実験を行う 24
25. 謝辞 本研究はJSPS科研費 22K11975 の助成を受けたものである． 25