Rustへのコード翻訳のためのLLMの評価

技術の進化に伴い、プログラミング言語から別の言語へのコード翻訳の必要性が高まってきてる。そんな中で、注目されてるアプローチの一つが大規模言語モデル（LLM）の利用だ。これらのモデルは、さまざまなプログラミング言語でコードを理解したり生成したりできるように設計されてるんだ。ただ、これまでのLLMの研究は特定のプログラミング課題に焦点を当てていて、実際のシナリオでの効果はあまり調べられてなかったりする。この記事では、LLMが安全性とパフォーマンスで知られる人気のプログラミング言語Rustに、実世界のコードを翻訳する可能性について探っていくよ。

#背景

コード翻訳は、あるプログラミング言語で書かれたコードを別の言語に変換し、その機能性を保つことを指す。これにはいくつかの重要な理由がある。まず、企業は古いプロジェクトをCやGoみたいな言語からRustのようなモダンな言語に移行させる必要がよくある。次に、ソフトウェア開発の際に異なる言語の強みを活かせるようになる。Rustは特に安全性とパフォーマンスに重点を置いているから人気が高まってるんだ。

従来のルールベースの翻訳ツールは特定の言語ペアに対応するために開発されてきたけど、限界があるし、かなりのエンジニアリング努力が必要だったりする。その点、LLMは複数の言語でコードを書く能力を持っているから期待できそう。翻訳プロセスを自動化して、より速く効率的にする可能性があるんだ。

#コード翻訳の課題

LLMを使ったコード翻訳には、いくつかの課題がまだ残ってる。その一つが、モデルが生成した翻訳の正確さを評価すること。多くの場合、ターゲット言語（この場合はRust）で書かれたテストケースがそもそも存在しないため、検証プロセスが複雑になるんだ。このリソース不足が、実世界のコードを翻訳する際にLLMのパフォーマンスを評価するのを難しくしてる。

もう一つの課題は、実世界のコードの複雑さ。過去の研究で使われたベンチマークは、単純なデータ型の単一関数で構成されることが多いけど、実際のプロジェクトは多数の関数やユーザー定義型、複雑な依存関係が特徴だ。こういった複雑さがLLMが正確な翻訳を出すのを妨げることがあるんだ。

#研究概要

この研究では、LLMが実世界のコードをRustに翻訳する能力を調査するために、大規模な研究を行うことを目指してる。実際のプロジェクトからコードサンプルを自動で抽出するツールを開発して、いくつかのLLMが生成した翻訳をテストした。選んだモデルはGPT-4、Claude 3、Claude 2.1、Gemini Pro、Mixtral。

この研究には以下の主要な要素が含まれてるよ：

1. コードサンプルの抽出: オープンソースプロジェクトからコードサンプルを自動で収集する方法論とツールを作った。このアプローチで、テスト用に多様な実世界のコード例を集めたよ。

2. 検証ツール: 複数言語に対応したファズィングツールを開発して、翻訳されたコードが元のソースプログラムと同等であるかをチェックできるようにした。このファズィングツールはユーザー定義のデータ型にも対応していて、複雑な翻訳に適してる。

3. 翻訳評価: 選んだLLMが成功する翻訳を生成する能力や、バグがあるコードにフィードバックを与えた際に修正できるか評価したよ。

#方法論

#コードサンプル抽出

意味のあるベンチマークを収集するために、CやGoで書かれたプロジェクトに注目したんだ。これらの言語は低レベルのプログラミングタスクでよく使われるから、Rustへの翻訳に適してる候補なんだよ。銀行、幾何学、音声処理といった多様なドメインにわたる7つのオープンソースプロジェクトを選んだ。

各プロジェクトから、特定の基準に合ったコードサンプルを抽出したよ。選ばれたサンプルはサードパーティのライブラリに依存せず、扱いやすい数の関数を含むようにした。合計で、グローバル変数、ユーザー定義型、動的データ構造などのさまざまな特徴を持ったいくつかのコードサンプルを集めたんだ。

#翻訳プロセス

翻訳プロセスは、LLMが提供された初期のコードサンプルに基づいて候補翻訳を生成することから始まる。この翻訳を生成した後、コンパイル駆動の修正フェーズに入る。このフェーズでは、Rustコンパイラから報告されたコンパイルエラーに対処するんだ。

コンパイル可能な翻訳が得られたら、クロスランゲージファズィングツールを使って、元のプログラムと翻訳されたプログラムの入力-出力の同等性をチェックする。ファズィングツールは両方のコードバージョン用に入力を生成して、それを実行して出力を比較する。出力が一致すれば、その翻訳は有効だと見なされる。

#フィードバック戦略

翻訳プロセスを向上させるために、いくつかのフィードバック戦略を導入したよ。これらの戦略は、バグのある翻訳を修正する際にLLMに追加の文脈を提供することで翻訳の質を向上させることを目的としてる。戦略には以下が含まれる：

1. シンプルリスタート: LLMが過去の翻訳を使わずに、元のプロンプトに基づいて新しい翻訳を生成する。

2. ヒンティッドリスタート: 成功した例と失敗した例をファズィングツールから元のプロンプトに追加して、LLMを望ましい動作に導く。

3. 反例ガイド付き修正: ファズィングツールから反例を提供して、LLMが特定のバグに対処するよう促す戦略。

4. 対話的修正: LLMとの対話を複数回にわたって構築し、以前の誤った翻訳を取り入れて同じミスを繰り返さないようにする方法。

これらのフィードバック戦略が翻訳の成功率全体に与える影響を評価したよ。

#結果

私たちの実験には、選んだLLMと抽出したコードサンプルを使った8160の翻訳試行が含まれてる。結果はいくつかの重要な洞察を明らかにしたよ。

#翻訳成功率

各LLMの成功率は大きく異なった。Claude 2が約47.7%で最も高い成功率を示したのに対し、Mixtralは約21%の低い成功率だった。このパフォーマンスの差は、違うコードサンプルを扱う際のモデルの能力のばらつきを表してる。

ベンチマークごとに成功率を分析したところ、あるプロジェクトはLLMにとって翻訳がしやすいことが分かった。特に、ACHプロジェクトはLLMの一つに対して80%の成功率を示したんだが、これはそのコードサンプルの構造が比較的シンプルだったから。

#コードの複雑さの影響

コードサンプルの複雑さが翻訳の成功率に直接影響を与えてた。コードの行数や関数が増えるにつれて、成功する翻訳の可能性が減っていった。この傾向は、大きく複雑なコード構造に伴う固有の課題を反映してる。

#イディオマティックなRustの生成

LLMが生成したRustコードの質を、成功した翻訳をRustのビルトインリンターであるClippyを使って評価した。結果は、LLMが主に機能的なコードを生成したものの、イディオマティックな使い方に関しては時折問題があったことを示していた。特定の翻訳では、スタイル、複雑さ、パフォーマンスに関する警告が出ており、Rustのベストプラクティスに沿ったコード生成の改善の余地があることを示唆してた。

#フィードバック戦略の効果

実施したフィードバック戦略の効果はさまざまだった。分析によると、フィードバック戦略は一般的に成功率を向上させたけど、最もシンプルなアプローチ-元のプロンプトを繰り返すこと-が、カウンター例を提供した複雑な戦略と同じかそれ以上の効果を示すことが多かった。この結果は予想外で、LLMがファズィングツールで生成されたカウンター例を効果的に解釈するのに苦労している可能性を示してる。

#ルールベースのツールとの比較

LLMベースの翻訳結果と、C2Rustのようなルールベースの翻訳ツールが生成したものを比較した。C2Rustは理論的には正確性を保証できるけど、LLMはより簡潔でイディオマティックなコードを生成する傾向があった。多くの場合、LLM生成の翻訳はコードファイルを短くし、可読性や保守性において追加の価値を提供できることを示唆してる。

#考察

私たちの研究の結果は、LLMが実世界のコードをRustに翻訳するための大きな可能性を持っていることを示している。でも、成長と改善が必要なエリアはいくつかあるよ。

#フィードバックメカニズムの改善

反例の翻訳品質向上における限られた効果は、フィードバック戦略で使用される入力の性質について疑問を投げかける。反例をより効果的にLLMに導くためにどう作成できるかをさらに探ることが有益かもしれない。また、どのタイプの例がより直感的なフィードバックを生み出すのかを理解するために、入力選択技術に関する研究も役立つかもしれない。

#コードの複雑さへの対処

今後の研究では、大きくて複雑なコードサンプルを扱うことが重要になる。1つのアプローチとして、プログラムをより小さくて管理しやすいチャンクに分けて、それぞれを個別に翻訳して検証する方法が考えられる。複雑なコードを分解することで、成功する翻訳の可能性が高まり、LLMの予測の確率的な性質に起因するエラーを減少させることができるかもしれない。

#ファズィングツールの改善

クロスランゲージファズィングツールの改善も翻訳結果の向上に寄与するかもしれない。より複雑なデータ型や特徴を扱う能力を拡張することで、翻訳の成功率を高め、シリアライゼーションの問題による失敗を最小限に抑えることができるかもしれない。

#結論

結論として、この研究はLLMを使って実世界のコードをRustに翻訳する可能性の高さを示している。課題は残ってるけど、私たちの発見はLLMがこのタスクで合理的な成功率を達成できることを示唆している。フィードバック戦略の改良やコードの複雑さへの対処、検証ツールの強化に関するさらなる作業が、今後の翻訳努力の改善につながるだろう。LLMの能力と限界を探求し続けることで、ソフトウェア開発とコード翻訳の進化する風景における彼らの役割をより良く理解できるはずだ。