フィードバック重視：1〜3Bコード生成でパイプライン構造より実行フィードバックが重要な理由

Abstract

小型の言語モデル（1-3B）はローカルで実行するのに現実的ですが、より難しいコード生成タスクでは個別には能力が限られています。そこで、それらをパイプラインとして組み合わせることで、失われた能力の一部を取り戻せるのかを問いかけます。実行フィードバックを用いた1-3Bモデルから構築したコード生成パイプラインを研究し、より複雑なパイプライン構造が、単純な改良（refinement）ループを超えて役立つかどうかを検証するために、NEATに着想を得た進化的探索を用います。評価はHumanEval（164問）およびサニタイズ済みMBPP（427問）で行い、すべて単一のラップトップ上でローカル推論します。実行フィードバックによる自己改良（self-refinement）は、両方のベンチマークでコード生成を4標準偏差以上改善します。改善は機構としては限定的です。すなわち、改良は多くの実行時エラー（特にNameErrorとSyntaxError）を修正しますが、AssertionErrorのような論理エラーはほとんど修正できません。テストした汎用モデルのプールにおいては、生成器（generator）の同一性は、改良器（refiner）の能力ほど重要ではありません。1.5Bの生成器に3Bの改良器を組み合わせると、両方の役割を行う3Bモデルと同等の性能が得られました。早期停止（early stopping）は不可欠です。これなしでは、すべてのイテレーションが純損失になります。検証した汎用パイプライン設定のすべてを、コード特化モデルが上回り、モデルの特化がパイプラインのアーキテクチャよりも重要であることを示唆します。実行フィードバックなしの事前段階のテキストのみのパイプライン実験では、この規模での改善は見られませんでした。制約された探索空間では、進化的探索は主に、手作業で見出したのと同じ単純な「生成—実行—改良」ループを再発見しており、追加されたトポロジによる明確な有意な改善はありませんでした。単一評価（single-evaluation）による適応度（fitness）は結果を5〜7パーセント膨らませ、良いゲノムよりも幸運なゲノムを選んでしまいます。これらのベンチマークにおいて1-3Bスケールでは、合成（composition）を助けるかどうかの決定要因として、実行フィードバックは追加されたパイプライン複雑性よりも重要でした。