アーカイブ / LLM
正解コードの一部を補完して学ぶStructureCoder：テスト付き課題から選好ペアを作る
StructureCoder
StructureCoderの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Figure 2: An overview of our FIM-style preference modeling process. A concrete example (right) illustrates the task of completing an is_prime function, with correctness judged via downstream function tests.
概要
- StructureCoderは正解コードを構文単位で分け、中間補完の候補を既存のテストで判定してDPO用の選好ペアを作る。
- 著者らの1.5Bモデルでは、HumanEval標準版のPass@1が75.6で通常のDPOの74.4を上回った。一方、学習順を外した条件は同課題で78.7だった。
- 適用には正誤を判定できるテストと、元モデルの十分な中間補完能力が必要である。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、StructureCoderの仕組み
- 01課題・正解・テスト
- 02構文木で部分抽出
- 03前後から中間補完
- 04テストで合否判定
- 05選好ペアで学習
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
StructureCoderは、テストで正誤を確かめられるコード課題を細かく使い、コード生成モデルを調整する方法だ。著者らが学習に使ったAPPSの訓練集合は5,000件で、正確なテスト付きデータの少なさを課題に挙げる。
DPO（直接選好最適化）は、望ましい出力と望ましくない出力の組でモデルを調整する方法である。コード全体の組では、誤りが一部分に限られていても、長い共通部分を含む応答を比べることになる。
手法
入力は課題文、正解コード、テストである。正解コードをAST（抽象構文木、コードの構造を表す木）に変換し、if、for、while、関数のブロックを選ぶ。FIM（中間補完）では選んだ部分を空欄にし、課題文と前後のコードを示して候補を生成する。論文では、素数判定関数の一部を補う例を示す。
候補を元の位置に戻してテストし、正答と誤答が両方得られた部分で選好ペアを作る。各誤答には、文字列を直す手数の尺度である編集距離が最小の正答を対応させる。DPOの損失は生成した中間部分だけで計算し、対話形式の例も混ぜる。学習例は対象部分の行数順に、短いものから長いものへ進める。
新規性
著者らの提案は、一つのテスト付き課題から、正解コードの構文上まとまった部分を複数選び、それぞれを補完対象にして選好ペアを作る点にある。限られた課題を、部分ごとの学習に使う。
前後のコードを示す中間補完形式と通常の対話形式を併用し、損失計算を生成した中間部分に絞る。学習時には対象部分の行数で例を並べ、短いものから長いものへ進める。
従来手法との違い
通常のDPOは、課題への正答コードと誤答コードを全体として比べる。著者らは、一部分だけが違う場合でも、誤りの後に続く共通部分が損失計算に入り、学習を妨げると分析する。StructureCoderでは生成した中間部分だけを計算対象にする。
実験上の比較対象はDPO、KTO、Focused-DPOである。Focused-DPOは生成結果に共通する前後の部分を利用するが、StructureCoderは正解コードの構文から補完対象を選ぶ。比較結果は、報告されたモデルと評価課題の範囲で読む必要がある。
実験結果
著者らはAPPS訓練集合5,000件でQwen2.5-Coder-Instructの1.5B、3B、7Bを調整した。HumanEvalとHumanEval+、MBPPとMBPP+、APPS、LiveCodeBench、BigCodeBenchを評価し、指標にPass@1（一つ生成した回答が正解する割合）を用いた。
1.5BのHumanEval標準版では、StructureCoderが75.6、通常のDPOが74.4だった。LiveCodeBenchの2024年7月から2025年1月の評価では29.2対28.6である。一方、1.5BのHumanEval標準版では、学習例を行数順に並べない条件が78.7で、StructureCoderの75.6を上回った。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：社内のPython関数を補完する開発支援を試す。入力には、利用可能な課題文、正解コード、正誤を判定できるテストが要る。正解コードを教師データとし、テストの合否を候補のラベルにする。物理センサーからの入力は想定しない。
条件分岐やループを空欄にし、前後のコードから補完候補を出力する。候補を関数へ戻してテストし、正答と誤答の組でモデルを調整する。利用時は補完案を開発者が確認する流れとし、社内コードでの効果は別途測る。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：利用可能なPython課題文、正解コード、正誤を判定できるテストを少数集める。正解コードを教師データ、テストの合否を候補のラベルとし、物理センサー入力は用いない。対象モデルの中間補完能力を先に測る。
正解コードを構文解析して一部を空欄にし、候補を戻してテストする。正答と誤答がそろった箇所で学習し、同じ元モデルと訓練課題を使う通常のDPOと比べる。学習に使わない課題のPass@1、合否を判定できた候補の割合、テストの網羅範囲を記録する。
限界と課題
著者らが明記する制約は、元のモデルに十分な中間補完能力が必要なことだ。教師あり調整後にその能力が弱いモデルもあり、手法の効果は対象モデルの補完能力に左右される。確認できた本文の範囲では、制約節の次の項目は途中で切れている。
編集上の検証事項は、社内の正解コードを構文単位で分けられるか、テストが候補の誤りを十分に検出できるかである。報告された実装はPythonのif、for、while、関数ブロックを対象とするため、別言語で同じ結果が出るとは判断できない。
出典
元のタイトル・要旨を確認する（英語）
Alignment with Fill-In-the-Middle for Enhancing Code Generation
The code generation capabilities of Large Language Models (LLMs) have advanced applications like tool invocation and problem-solving. However, improving performance in code-related tasks remains challenging due to limited training data that is verifiable with accurate test cases. While Direct Preference Optimization (DPO) has shown promise, existing methods for generating test cases still face limitations. In this paper, we propose a novel approach that splits code snippets into smaller, granular blocks, creating more diverse DPO pairs from the same test cases. Additionally, we introduce the Abstract Syntax Tree (AST) splitting and curriculum training method to enhance the DPO training. Our approach demonstrates significant improvements in code generation tasks, as validated by experiments on benchmark datasets such as HumanEval (+), MBPP (+), APPS, LiveCodeBench, and BigCodeBench. Code and data are available at https://github.com/SenseLLM/StructureCoder.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01