技術要約：コードペアを超えて：LLMコード翻訳のための対話ベースのデータ生成

問題提起

大規模言語モデル（LLM）は、PythonやJavaのような主要な言語におけるコード翻訳において顕著な能力を示している。しかし、低リソースのプログラミング領域（例：Fortran）や専門的なフレームワーク（例：CUDA）においては、高品質な並列学習データが不足しているため、その性能は著しく低下する。既存のエージェントベースのアプローチは、通常、ソースからターゲットへのワークフローに従い、最終的なソース・ターゲットのコードペアを生成する。これらの手法は、構文的に有効なコードを生成することには効果的であるが、プログラムのセマンティクス（意味論）や機能的挙動に関する深い推論を可能にするために不可欠な貴重な中間情報（コンパイラエラー、ランタイム診断、外部ツールとの相互作用など）を破棄してしまう。その結果、静的なコードペアで訓練されたモデルは、複雑な翻訳シナリオにおいてエラーからの回復や、機能的に正しいコードの生成に失敗することが多い。

手法

著者らは、エージェントベースの翻訳ワークフロー内にデュアルLLM「Questioner–Solver（質問者・解決者）」設計を組み込むことで、従来のコードペアを超えた自動データセット生成パイプラインを提案している。このアプローチは、翻訳の洗練化（リファインメント）の背後にある推論プロセスを捉えるマルチターン対話を生成する。

Questioner–Solver モジュール

システムの核となるのは、2つの異なるLLMの役割である：

• Questioner（質問者）: 現在の状態を分析し、対話メモリ（過去の試行、エラー、修正）を活用し、外部シグナル（コンパイラエラー、ランタイム出力）を取り入れる。ターゲットとなる質問を策定し、制約を指定し、ソースとターゲットの一貫性をチェックする。
• Solver（解決者）: 翻訳を実行し、ユニットテストを生成し、修正案を提示し、検証結果を返す。

マルチターン対話生成パイプライン

パイプラインは、ソースプログラミング言語（SPL）のコードを以下のステージを経て処理し、検証済みの対話を生成する：

1. 前処理: ソースコードが自己完結しており、実行可能であり、かつコンテキストウィンドウに適合することを確認するためにフィルタリングを行う。
2. SPLユニットテストの生成と検証: Solverがソースコードに対するユニットテストを生成する。Questionerは実行結果を分析する。失敗が発生した場合、Solverはテストまたはコードを修復する。このループは、テストが通過するまで（上限設定あり）継続される。
3. 初期翻訳: Questionerがターゲット言語への翻訳を要求し、Solverが初期コードを生成する。
4. 翻訳の検証と洗練化: 翻訳されたコードをコンパイルし、ユニットテストに対して実行する。Questionerは結果を評価し、エラーに基づいてSolverに翻訳の洗練化を指示する。この反復的なループが、問題解決の軌跡を捉える。
5. Duo-Test 検証: ソースプログラムと翻訳されたプログラムの間の機能的な等価性を、出力の比較によって最終的に保証する。成功した翻訳とその全対話履歴が、検証済みデータとして保存される。

データセット構築

パイプラインは、ファインチューニングのために2種類のデータ形式を生成する：

• 対話レベル（Dialogue-Level）: 全体のワークフローを捉えたフルマルチターン会話。
• 質問–解決ペア（Question–Solution (QS) Pairs）: 対話から抽出された原子的なやり取りであり、推論を微細なステップへと分解したもの。

著者らは、このパイプラインを Fortran→C++ および C++→CUDA の2つのタスクに適用し、それぞれ3.64kおよび3.93kの対話を生成した。これらはさらに、Fortran→C++では14.1k超、C++→CUDAでは12.7k超のQSペアへと分解された。

主な貢献

1. 自動対話生成パイチライン: デュアルLLM Questioner–Solverモジュールによって駆動され、外部知識（コンパイラ、ランタイム）を構造化された推論トレースに統合するフレームワークであり、静的なコードペアを超えたものである。
2. 新しい翻訳ベンチマーク: Fortran→C++およびC++→CUDAに関する、ユニットテストを伴う検証済み翻訳の大規模データセット。厳格な評価のために3つの独立したテストスイートも付属している。
3. データ構造化戦略の検証: 著者らは、異なるデータ形式が異なるタスクに最適化されることを示している。対話を微細なQSペアに分解することは、構文的な複雑さを習得するのに非常に効果的である一方、フル**対話（Dialogue）**トレースを使用することは、セマンティックな正当性を保持する上で優れている。

実験結果

著者らは、生成されたデータを用いて中規模のオープンウェイトモデル（CodeLlama-13B, DeepSeek-Coder-6.7B, Qwen2.5-7B）をファインチューニングし、評価を行った。

• 機能的正当性: 生成されたデータでのファインチューニングにより、劇的な改善が見られた。困難なC++→CUDAタスクにおいて、CodeLlama-13Bモデルのユニットテスト成功率は、QSペアデータで訓練した場合、12.5%から68.8%へ（56%以上の向上）上昇した。同様に、Fortran→C++の翻訳では、CodeLlama-13Bは42.3%から74.1%へと向上した。
• デバッグラウンドによる利得: 対話データで訓練されたモデルは、コンパイル、実行、およびユニットテストの成功において、複数のデバッグラウンドを通じて一貫した改善を示し、静的なコードペアで訓練されたモデルを上回った。
• プロプライエタリなシステムとの競争力: 対話チューニングされたQwen2.5-7Bモデルは、コンパイルおよび実行の成功といった主要な指標において、より大規模なプロプライエタリなシステム（Gemini 2.5 Flash, Llama 4 Scout 17B）を大幅に上回り、対話中心の監督（supervision）のコスト効率の高さを浮き彫りにした。
• CodeBLEU スコア: ファインチューニングされたモデルは、CodeBLEUスコアにおいても一貫した改善を示しており、これは参照ソリューションに対する構文的および構造的な整合性が高まっていることを示している。

意義

本論文は、対話駆動型の監督が、従来の並列コーパスが存在しない低リソース領域において、複数のオープンウェイトモデルファミリー全体で機能的正当性を一貫して向上させることを主張している。構造化された推論（コンパイラフィードバック、エラー修正ステップ）をデータセットに組み込むことで、このアプローチはLLMに対し、単なる翻訳の最終結果だけでなく、正当性が達成されるまでのプロセスを学習させることを可能にする。結果は、この手法がレガシーコードの近代化において、より小さなオープンウェイトモデルがより大規模なプロプライエタリなシステムに匹敵、あるいは凌駕するための、コスト効率の高い経路を提供することを示唆している。著者らは、本フレームワークはまず第一歩として機能的正当性に焦点を当てているが、今後の課題として、パフォーマンスを考慮した評価指標の組み込みを目指すと述べている。