[論文レビュー] Frustrated with Code Quality Issues? LLMs can Help!

N. K. Wadhwa, Jui Pradhan+6 more|arXiv (Cornell University)|Sep 22, 2023

Software Engineering ResearchComputer Science被引用数 3

ひとこと要約

本論文では、静的解析の警告に対してコード修正を生成するための指令に従う言語モデル（プロポーザー）を用いて修正候補を生成し、第二の言語モデル（ランカー）がその修正の機能的正しさと品質を評価・順位付けする二段階のLLMベースのシステムCOREを提案する。COREは複数のツールやチェックにおいて、Pythonで59.2%、Javaで76.8%の修正率を達成し、誤検出を25.8%削減し、膨大な工数を要する専用のAPRツールと同等の性能を示した。

ABSTRACT

As software projects progress, quality of code assumes paramount importance as it affects reliability, maintainability and security of software. For this reason, static analysis tools are used in developer workflows to flag code quality issues. However, developers need to spend extra efforts to revise their code to improve code quality based on the tool findings. In this work, we investigate the use of (instruction-following) large language models (LLMs) to assist developers in revising code to resolve code quality issues. We present a tool, CORE (short for COde REvisions), architected using a pair of LLMs organized as a duo comprised of a proposer and a ranker. Providers of static analysis tools recommend ways to mitigate the tool warnings and developers follow them to revise their code. The \emph{proposer LLM} of CORE takes the same set of recommendations and applies them to generate candidate code revisions. The candidates which pass the static quality checks are retained. However, the LLM may introduce subtle, unintended functionality changes which may go un-detected by the static analysis. The \emph{ranker LLM} evaluates the changes made by the proposer using a rubric that closely follows the acceptance criteria that a developer would enforce. CORE uses the scores assigned by the ranker LLM to rank the candidate revisions before presenting them to the developer. CORE could revise 59.2% Python files (across 52 quality checks) so that they pass scrutiny by both a tool and a human reviewer. The ranker LLM is able to reduce false positives by 25.8% in these cases. CORE produced revisions that passed the static analysis tool in 76.8% Java files (across 10 quality checks) comparable to 78.3% of a specialized program repair tool, with significantly much less engineering efforts.

研究の動機と目的

• 静的解析ツールが特定したコード品質上の問題の修正にかかる開発者の負担を軽減すること。
• 大規模な工数やトレーニングデータを必要とし、特定のパターンに限定される既存の自動プログラム修復（APR）ツールの限界を克服すること。
• 静的解析ツールが提供する自然言語による修正推奨を指令として用い、ファイントーニングやトレーニングデータを一切使わず、ゼロショット、フェイシング、またはプロンプト付きゼロショットでのコード修正を可能にすること。
• 静的チェックに合格しても機能を変更する意味的に誤った修正を検出し、除外することで修正品質を向上させること。
• 最小限の工数で、複数の言語、複数のツール、複数のチェックに跨る互換性を実現すること。

提案手法

• COREは、指令微調整済みの二つのLLMを組み合わせる。まず、プロポーザーLLMが静的解析の推奨事項に基づいて候補となるコード修正を生成する。
• プロポーザーLLMは、バグのあるコード、品質上の問題の説明、自然言語による修正推奨を入力として受け取り、修正済みのコードを生成する。
• 生成された修正は、元の静的解析ツールに対して検証され、問題の解決に失敗したものをフィルタリングする。
• 第二のLLM（ランカー）が、人間の受容基準に整合した評価基準を用いて、各候補修正を正しさと機能の保持の観点からスコア化する。
• ランカーは、元のコードと修正後のコードの差分（diff）を用いて意味的変更を推論し、微細な後退をより効果的に検出する。
• 最終的な候補修正はランカーのスコア順に並べ替えられ、開発者に提示され、手動でのレビュー作業が削減される。

実験結果

リサーチクエスチョン

• RQ1 ファインチューニングやトレーニングデータを一切使わず、LLMが静的解析チェックと人間のレビュー基準の両方を満たすコード修正を生成できるか？
• RQ2 第二のLLMが、静的チェックに合格しても意図しない意味的変更を引き起こす修正を効果的に同定・除外できるか？
• RQ3 COREのような二重LLMシステムが、複数のプログラミング言語（例：PythonとJava）、複数の静的解析ツール（CodeQLとSonarQube）、多様なコード品質チェックに一般化できるか？
• RQ4 COREの修正率と誤検出率は、ルールベースの自動プログラム修復ツールと比較して、有効性と工数の観点でどの程度優れているか？
• RQ5 静的解析ツールが提供する自然言語による修正推奨を、ゼロショット環境で直接LLMの指令として使用できるか、その有効性はどの程度か？

主な発見

• COREは52の品質チェックに跨るPythonコードに対して59.2%の修正率を達成し、静的解析ツールと人間のレビュアーの両方の承認を得た。
• ランカーLLMのおかげで、静的チェックに合格しても意図しない機能変更を引き起こす修正を検出し、誤検出を25.8%削減した。
• Javaのベンチマークでは10の品質チェックに跨り76.8%の修正率を達成し、専用のルールベースAPRツール（78.3%）と同等の性能を示したが、はるかに少ない工数で実現した。
• モデルのファインチューニングやタスク固有のデータを一切必要とせず、二つのプログラミング言語と二つの静的解析ツールで多様なコード品質問題を効果的に処理できた。
• GPT-4はコード差分の推論においてGPT-3.5-Turboを上回り、意味的評価におけるモデルの能力の重要性を示した。
• 自然言語による修正推奨をプロンプトとして直接使用することで、大規模なトレーニングデータやパターン抽出を回避した効果的なゼロショットコード修正が可能になった。