KuaishouのKwaiKATチームは、単発のコードスニペットを生成するのではなく、実際の実行可能なソフトウェアリポジトリ内で動作するよう設計されたコーディングモデル、KAT-Coder-V2.5を発表した。提供モデルはStreamLake経由で利用できる。別個のオープンウェイト版であるKAT-Coder-V2.5-Devは、Apache-2.0ライセンスの下でHugging Faceに公開されている。

今回のリリースは、モデルがリポジトリを調査し、タスクを理解し、ファイルを編集し、テストを実行し、パッチが正しいかどうかを検証する必要があるエージェント型コーディングのワークフローを中心としている。この焦点は、コーディングモデルの評価が、孤立したプログラミングプロンプトからリポジトリレベルのソフトウェア保守へと広がっていることを反映している。そこでは、再現可能な環境と信頼できるテストフィードバックが、コード生成品質と同じくらい重要になり得る。このプロジェクトは、リポジトリ環境、データ構築、サンドボックスの信頼性、強化学習インフラ、ベンチマーク評価を重視している。

AutoBuilderは意図したテストを実行する環境を構築

この研究では、検証可能なコーディングタスクを、正確なタスク記述、実行可能なリポジトリ環境、検証テスト群という三つ組として定義している。パッチは、検証セット全体に合格した場合にのみ正しいと見なされる。

タスクは、SWE-benchの流れに沿って、実際のプルリクエストとコミットから抽出される。マージされたコード変更がゴールデンパッチを提供し、それに伴うテスト変更がテストパッチを提供する。システムは、生のイシューテキストを仕様として使用しない。代わりに、タスク記述は3つの要素に再生成される。ゴールデンパッチに基づく問題文、テストパッチから導出された要件、そして両方のソースから推論されたインターフェース制約である。明確性チェックにより、曖昧、不完全、仕様不足、または内部的に矛盾するタスクは除外される。

AutoBuilderは環境構築プロセスを担う。ビルドエージェントがリポジトリを調べ、依存関係をインストールし、クリーンチェックアウトからテストを実行する構成スクリプトを作成する。その後、検証エージェントが隔離されたサンドボックス内でそのスクリプトを実行する。

受け入れプロセスは、終了コードやログパターンの照合には依存しない。代わりに、検証はテストフレームワークからの構造化出力を解析する。期待されるテストの90%超が収集され、合否結果が複数回の実行で再現可能な場合にのみ、環境は受け入れられる。失敗は、反復的な修復のための構造化情報として返される。

事前構成済みのベース環境、ビルドシステムテンプレート、検索可能な蒸留済みビルドレシピのライブラリを組み合わせることで、チームは環境構築の成功率を16.5%から57.2%に引き上げた。結果として得られたデータセットには、12のプログラミング言語にまたがる100,000件超の検証可能な環境が含まれる。Git履歴、コミットメタデータ、その他の悪用可能な痕跡は削除され、エージェントがリポジトリから参照解を直接取得できないようにしている。

Data Scaling Flywheelはプロセス品質でフィルタリング

このプロジェクトは、最終的なテスト成功だけで軌跡をフィルタリングすることは誤解を招く可能性があると主張している。合格した実行の中には、ハードコーディング、意図された仕組みの迂回、テストに合わせた近道に依存しているものがある。一方で、失敗した実行の中にも、有用な探索、局所化、修復の挙動が含まれている場合がある。

KwaiKATは両方のケースに対処する。惜しくも失敗した試行に対しては、解答を明かさずに何を調査または検証すべきかを示す、対象を絞ったプロセスレベルのヒントを与える。これにより、以前は一度も合格しなかったタスクの合格率が約20%まで上がる。ヒント付きの軌跡には推論時には利用できない情報が含まれるため、その後、検証済みパッチを固定し、元のタスク文脈からヒントなしの軌跡を再生成する。検証に合格し、ヒント漏えいがなく、パッチとの整合性を保つサンプルのみが保持される。

すでに合格している軌跡については、ルールベースのゲートにより、無効、不安定、または悪用的な例を除去する。その後のスコアリング段階では、探索、局所化、編集前の推論、仕様への忠実性、リポジトリ規約への準拠、パッチの最小性、検証品質、回復行動、正直さを評価する。

3つ目の仕組みは、ハーネスへの過剰適合を減らすことを目的としている。機能は変えずに、ツール名、引数規約、出力形式、プロンプトテンプレートをランダム化する。検証はハーネスの痕跡ではなくテスト結果に結び付けられているため、同じタスクを複数のハーネス構成で提示できる。システムはまた、依存関係の欠落、一時的なコマンド失敗、切り詰められた出力、ノイズの多いログなど、現実的な揺らぎも注入する。

サンドボックス障害がアルゴリズム上の限界より先に報酬へ影響

KAT-Coder-V2の学習中、報酬曲線の伸びの遅さは当初、強化学習アルゴリズムに起因すると見られていた。後の監査で、軌跡の約16%がモデル方策ではなくサンドボックスインフラの問題によって失敗していたことが判明した。境界の不整合により、約40ステップにわたって観測が空になり、報酬が破損する場合があった。

チームは3つのインフラ修正を実施した。第一に、早期解放型のイメージ退避ポリシーによりディスク使用率を95%から60%に下げ、タイムアウトに起因する無効なロールアウトを6–7%から1%未満に低減した。第二に、リモートサンドボックス初期化時の環境変数を修正することで、サンプルの6–7%で報酬を反転させていたシステム上書きを防ぎ、これらのエラーを1%未満に減らした。第三に、Gateway Serverは主流のチャットエンドポイントを迂回した。これらのエンドポイントはapply_chat_templateの再適用と再トークン化により、約200ターン規模で40%のトークンドリフトを引き起こしていた。代わりに、システムはロールアウトのトークン整合性を維持するため、/generateを直接呼び出した。

これらの変更により、サンドボックスフィードバックのエラー率は約16%から2%未満に低下し、学習崩壊は1桁削減された。この結果は、エージェント型コード学習における実務上の制約も示している。すなわち、報酬品質はモデルアーキテクチャや最適化手法だけでなく、周囲の実行システムにも依存する。

非対称PPOと3層の報酬

研究者らは、クリティックを使わない軌跡手法ではなく、GAEを用いたPPOを選択した。これは、本番ハーネスがセッションを構造的に異なるサンプルへ分割し、グループベースラインをより難しくするためである。

学習設定では、非対称のactor–critic設計を使用している。Criticは、報酬、テスト、カバレッジ、パッチ、メタデータ、将来ターンなどの特権的な学習コンテキストを受け取る。Actorはロールアウト状態のみを見る。推論時には、Criticと追加コンテキストは破棄される。

報酬は3層に整理されている。Core Task Scoresでは、すべてのfail_to_passおよびpass_to_passテストに合格する必要がある。Standard Behavior Constraintsは、重複、無効なツール呼び出し、デバッグの残骸にペナルティを与える。Failed Trajectory Incentivesは、F2によるファイル取得を採点し、テストに対して部分点を割り当てる。

5つのエキスパートは、逆KL、オフポリシー開始、Prune-OPDによるドリフト認識型の打ち切りを用いたMulti-Teacher On-Policy Distillationによって統合される。

ベンチマーク結果

統一されたClaude Codeハーネスの下で、KAT-Coder-V2.5はPinchBenchにおいて94.9のスコアでパネル首位となり、93.5のOpus 4.8を上回った。SWE-Bench Proでは65.2対69.2で2位、内部のKAT Code Benchでも53.1対57.3で2位だった。

一方、Terminal-Bench 2.1での成績は相対的に弱く、60.7で最下位となり、GLM-5.1の61.8およびOpus 4.8の84.6を下回った。SciCodeでは50.3を記録し、GLM-5.2と同等だった。こうした混在した結果は、リポジトリのパッチ適用、ターミナル操作、科学コーディングのテストが、エージェント型コーディングシステムの異なる部分を測定しているため、ハーネスとベンチマークの範囲が解釈上重要であることを示している。

オープンウェイトのKAT-Coder-V2.5-Devは、Qwen3.6-35B-A3Bを基盤に127K件のSFT例でポストトレーニングし、その後に強化学習を行った、総35B / アクティブ3Bの別個のMoEモデルである。これは別の社内プロトコルで評価されているため、その結果は主力モデルの主要ベンチマーク表とは比較できない。

プロジェクトの主要資料には、論文、StreamLake製品ページ、およびHugging Face上のKAT-Coder-V2.5-Devモデルウェイトが含まれる。