0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@masataka46(孝充 大政)

論文まとめと実装例：SERA: Soft-Verified Efficient Repository Agents

0
Posted at

はじめに

LLMの再学習分野で最近のものの中から重要論文として、ICML2026の以下の論文
[1] E. Shen, et. al. SERA: Soft-Verified Efficient Repository Agents. ICML 2026
のまとめ。

1. 概要

  1. SERA（Soft-Verified Efficient Repository Agents）は、特定のソースコードリポジトリに適応したCoding Agentを効率的に構築するための再学習手法
  2. 従来、Coding Agentを再学習するには、ユニットテストによる正解確認や強化学習（RL）が必要となり、大きな計算コストがかかっていたが、SERAでは、Soft-Verified Generation（SVG） という手法を用いて、コードの正しさを厳密に検証せずに学習データを大量生成する
  3. さらに、生成したデータを用いて通常のSFT（Supervised Fine-Tuning）を実施することで、Coding Agentの性能向上を実現している
  4. 同等の性能に到達するまでのコストが、比較対象の強化学習方式より26倍、従来の合成データ生成方式より57倍効率的であった

2. Coding AgentとSWE-agent

まずは Coding Agent の仕組みから。

通常のLLMによるコード生成は、指示文を入力し、コードを出力するが、Coding Agentは、LLMが外部ツールを使用しながら、複数ステップでソフトウェア開発を行う。

SERAでは、SWE-agent というAgent Frameworkを使用している。

SWE-agentの仕組み

SWE-agentは、LLMがソースコードの検索、閲覧、編集、コマンド実行などを行うためのフレームワークである。

例えば、バグ修正では次のように動作する。

  1. ユーザーがバグ修正を指示する。
  2. LLMが関連ファイルを検索するコマンドを生成する。
  3. SWE-agentがコマンドを実行する。
  4. 実行結果をLLMへ返す。
  5. LLMが結果を確認し、ファイル閲覧やコード編集を指示する。
  6. 修正が完了するまで繰り返す。

この一連の操作履歴を本論文では Trajectory（軌跡） と呼ぶ。

例えば、次のような情報が含まれる。

User: このバグを修正してください

Assistant: 関連ファイルを検索します
Tool: grep による検索
Result: 関連ファイル一覧

Assistant: 対象ファイルを確認します
Tool: ファイル閲覧
Result: ソースコード

Assistant: コードを修正します
Tool: ファイル編集
Result: 編集結果

Assistant: 修正が完了しました

SERAでは、このTrajectoryをSFTの教師データとして使用する。

3. SERAの提案手法：Soft-Verified Generation

SERAの中心となるのは、 SVG（Soft-Verified Generation） である。SVGでは、強力な教師モデルを使用し、コード変更を2回実施する。その結果を比較して学習データを選別する。

スクリーンショット 2026-11-09 4.51.56.png

Step 1：教師モデルによるコード変更

最初に、対象リポジトリからランダムに関数を選択する。さらに、51種類のバグ・改善カテゴリから1つを選び、教師LLMに曖昧な修正指示を与える。

例えば、次のような指示である。「calculate_total関数に入力値の検証に関する問題があります。修正してください。」

教師LLMにはGLM-4.5-Airなどの高性能モデルが使用され、SWE-agentを通じてコードの検索・閲覧・編集を実施する。その結果、Trajectory $T_1$ とPatch $P_1$ が生成される。

(T_1, P_1) = M(f_i, bug_j, C)

ここで、
$M$：教師LLM
$f_i$：ランダムに選択された関数
$bug_j$：選択されたバグ・改善カテゴリ
$C$：コードベース
$T_1$：1回目の操作履歴
$P_1$：1回目のコード変更

ただし、実際にバグが存在することや、変更後のコードが正しいことは保証されない。

Step 2：Synthetic PRの生成

次に、Step 1で生成されたTrajectoryを用いて、Synthetic PR（合成Pull Request）の説明文を生成する。

例えば、Step 1で入力チェックが追加された場合には、次のようなPRを生成する。「calculate_total関数でNoneが入力された際の例外処理を改善する。」つまり、コード変更を先に作り、その変更に対応する開発タスクの説明文を後から生成するという構成である。

このSynthetic PRは学習用のタスクであり、実際のGitHubリポジトリにPRを提出するわけではない。

Step 3：教師モデルによる再実行

次に、コードベースを元の状態に戻し、Synthetic PRの説明だけを教師LLMに与える。教師モデルは、最初のPatchを見ずに、再びSWE-agentを使用してコード修正を行う。

その結果、2回目のTrajectory $T_2$ とPatch $P_2$ を得る。

(T_2, P_2) = M(synth\_PR, C)

この段階では、最初のコード変更をどの程度再現できるかが重要となる。

Step 4：Soft Verification

SERAでは、通常のユニットテストによる正解判定の代わりに、2つのPatchの一致度を評価する。

この評価には、Line-level Recallを使用する。

r = \frac{|P_2 \cap P_1|}{|P_1|}

ここで、
$P_1$：1回目のPatchに含まれる変更行
$P_2$：2回目のPatchに含まれる変更行
$r$：1回目の変更が2回目で再現された割合

例えば、Step 1で10行を変更し、Step 3でそのうち7行が再現された場合、

r = \frac{7}{10} = 0.7

となる。論文では、例えば $$r \geq 0.5$$ のような閾値を用いてTrajectoryを選別する。 Soft Verificationの本質は、コードの正しさではなく、変更内容の再現性を評価する点にある。

Step 5：SFTによる生徒モデルの再学習

選別したTrajectoryを使って、生徒モデルをSFTする。SERAでは主にQwen3-32Bを使用し、Qwen3-8Bでも実験している。

教師モデルのTrajectoryには、検索、ファイル閲覧、コード編集、ツール実行結果を踏まえた次の操作の判断などが含まれる。そのため、生徒モデルは、単にコードを生成するだけでなく、どの状況でどのツールを使用するべきかというAgenticな動作を学習できる。

なお、学習アルゴリズムそのものは通常のSFTであり、GRPOなどの強化学習は使用していない。推論時にもSWE-agentのような外部Frameworkが必要であり、LLM単体でファイル操作が実行されるわけではない。

4. 実験結果

4.1 SWE-bench Verified

SERAでは、実際のGitHub IssueをもとにしたSWE-bench Verifiedを用いて評価している。

スクリーンショット 2026-11-09 5.13.44.png

SERA-32Bに対して本手法による学習を実施したところ、ベースモデルの24.4%からから約25ポイントの性能改善が確認された。

4.2 特定リポジトリへの適応

SERAでは、Django、Sympy、Sphinxなどのリポジトリに特化した学習も実施している。

各リポジトリから約8,000件のTrajectoryを生成して再学習した結果、DjangoやSympyでは32Bの生徒モデルが教師モデルGLM-4.5-Airと同等以上の性能を示した。

これは、特定のリポジトリに適応させることで、比較的小さなモデルでも大型の汎用モデルに匹敵する性能を得られる可能性を示している。

スクリーンショット 2026-11-09 5.15.27.png

ただし、すべてのリポジトリで教師モデルを上回ったわけではなく、性能差の統計的な不確実性にも注意が必要である。

5. SERAの特徴と課題

SERAの最大の特徴は、ユニットテストを必須とせず、Agentの操作履歴を大量に作成できることである。

これにより、テスト環境が整備されていないコードベースでも、Coding Agent向けのSFTデータを生成できる。

一方で、次のような課題が残る。

  • 教師モデルへの依存：高精度な教師LLMが必要であり、教師の性能が低い場合の効果は限定的と考えられる。
  • コードの正しさを保証しない：同じ誤ったコードを2回生成した場合も、Soft Verificationを通過する可能性がある。
  • 長いコンテキストが必要：AgentのTrajectoryは長くなりやすく、学習時のVRAM消費が大きい。
  • 実験対象の制約：主にPythonリポジトリとQwen3系列で検証されている。

特に興味深いのは、論文の実験では、Soft Verificationを厳格化しても性能への影響が比較的小さかったことである。

著者らは、Coding Agentの学習において、最終コードの正しさだけでなく、リポジトリの探索やコード編集などの操作経験が重要である可能性を示している。

6. Local LLMへの応用と今後の研究

SERAは、企業固有のコードベースに特化したLocal Coding LLMを構築するうえで、有望な手法である。

例えば、企業が保有するPythonコードからSynthetic PRとTrajectoryを生成し、Qwen3などの小型モデルをQLoRAで再学習することが考えられる。

これにより、社内のコード構造、命名規則、開発パターンに適応したCoding Agentを構築できる可能性がある。

また、今後の研究としては、次のような方向が考えられる。

  1. 小型モデルへの適用：Qwen3-4Bなど、24GB VRAMのGPUで学習可能なモデルにSERAを適用する。
  2. 教師モデルの性能比較：異なる性能の教師LLMを使用し、生徒モデルへの影響を測定する。
  3. 実行検証との組み合わせ：Soft Verificationに加え、ユニットテストや静的解析を用いて学習データの品質を改善する。
  4. SFTとGRPOの組み合わせ：SERAでAgent操作を学習した後、実行成功率を報酬として強化学習する。

7. まとめ

  1. SERAは、従来のコード生成モデルのように正解コードだけを学習するのではなく、Coding Agentがコードを検索・閲覧・編集する一連の操作履歴を学習する点が特徴である
  2. また、Soft Verificationによって正解コードの厳密な検証を省略することで、大量の学習データを効率よく生成できることを示した
  3. 今後、Local LLMを企業固有のコードベースに特化させる際に、重要なアプローチの一つになると考えられる

参考文献

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?