KwaiKATチームは、単一ターンのコード生成ではなく、実際の実行可能なリポジトリ内で動作するコーディングモデルKAT-Coder-V2.5を発表した。このモデルはStreamLakeを通じて提供され、オープンウェイト版のKAT-Coder-V2.5-DevはApache-2.0ライセンスでHugging Face上に公開されている。
研究では、検証可能なタスクを3つの要素からなるものとして定義している：正確なタスク記述、実行可能なリポジトリ環境、および一連の検証テスト。パッチはすべてのテストに合格した場合のみ正しいとみなされる。タスクは実際のプルリクエストとコミットからマイニングされ、SWE-benchの系統を踏襲している。マージされたコード変更はゴールデンパッチを提供し、付随するテスト変更はテストパッチを提供する。生の課題テキストは仕様として破棄され、代わりにゴールデンパッチに基づく問題文、テストパッチから導出された要件、および両方から推論されたインターフェース制約の3つの部分に再生成された説明が用いられる。明確性チェックにより、曖昧、不完全、不正確、または内部的に矛盾するものは排除される。
AutoBuilderが環境面を担当する。ビルドエージェントはリポジトリを解析し、クリーンチェックアウトから依存関係をインストールしてテストを実行する設定スクリプトを作成する。検証エージェントはそのスクリプトを隔離されたサンドボックス内で実行する。受け入れルールは重要な部分である。検証は終了コードの読み取りやログパターンのgrepを行わず、構造化されたテストフレームワークの出力を解析し、期待されるテストの90%以上が収集され、合格/不合格の結果が実行間で再現可能な場合にのみ環境を受け入れる。失敗は反復的な修復のための構造化情報としてフィードバックされる。
事前設定されたベース環境、ビルドシステムテンプレート、および検索可能なビルドレシピライブラリを組み合わせることで、構築成功率は16.5%から57.2%に向上し、12言語にわたる10万以上の検証可能な環境が生成された。Git履歴やコミットメタデータなどの痕跡は除去され、エージェントがリポジトリから参照ソリューションを読み取れないようにしている。
データスケーリングフライホイール：最終テストの成功による軌跡のフィルタリングは誤解を招く。成功した実行の中には、ハードコーディングやメカニズムの回避、テスト指向のショートカットに依存するものがある。失敗した実行の中には、価値のある探索、位置特定、修復動作を含むものがある。
KwaiKATは両方の方向に対処する。惜しい失敗に対しては、解決策を明かさずに検査または検証すべき項目を示すプロセスレベルのヒントが提供される。これだけで、以前はゼロ通過だったタスクの通過率が約20%に向上する。ヒントを含む軌跡には推論時には利用できない情報が含まれているため、検証済みパッチを修正し、元のタスクコンテキストからヒントなしの軌跡を再生成する。検証に合格し、ヒント漏れがなく、パッチと一貫性のあるサンプルだけが保持される。
成功した実行については、ルールベースのゲートが無効、不安定、または搾取的な軌跡を除去する。スコアリング段階では、探索、位置特定、編集前推論、仕様への忠実性、リポジトリ規則、パッチの最小性、検証品質、回復動作、および正直さを評価する。
3番目のメカニズムはハーネスの過適合を対象とする。ツール名、引数規則、出力形式、プロンプトテンプレートは、機能を維持しながらランダム化される。検証はハーネスの痕跡ではなくテスト結果に基づくため、同じタスクを複数のハーネス構成で提供できる。現実的な摂動も注入される：依存関係の欠落、一時的なコマンド失敗、切り詰められた出力、ノイズの多いログ。
インフラストラクチャの障害は、アルゴリズムの限界以前に報酬を制限していた。KAT-Coder-V2の訓練中、遅い報酬曲線は当初RLアルゴリズムのせいにされたが、監査により約16%の軌跡がモデルポリシーではなくサンドボックスインフラの問題で失敗していたことが判明した。境界のずれにより、約40ステップにわたって観測が空になり、報酬が破損することもあった。
3つのインフラ修正が行われた。まず、早期解放イメージ退去ポリシーによりディスク使用率が95%から60%に低下し、タイムアウトによる無効なロールアウトが6-7%から1%未満に減少した。次に、リモートサンドボックス初期化時の環境変数を修正し、6-7%のサンプルで報酬を反転させていたシステムの上書きを防止し、エラー率を1%未満に削減した。最後に、Gateway Serverは主流のチャットエンドポイント（約200ターンの規模でapply_chat_templateの再適用と再トークン化により40%のトークンドリフトを引き起こしていた）をバイパスし、/generateを直接呼び出してロールアウトのトークンアライメントを確保した。
これらの更新により、サンドボックスフィードバックエラー率は約16%から2%未満に低下し、訓練の崩壊は桁違いに減少した。
非対称PPOと3層の報酬
研究チームは、プロダクションハーネスがセッションを構造的に異なるサンプルに分割するため、グループベースラインが複雑になることから、批評家なしの軌跡手法よりもGAEを用いたPPOを選択した。
非対称アクター・クリティックを使用し、クリティックは特権的な訓練コンテキスト（報酬、テスト、カバレッジ、パッチ、メタデータ、将来のターン）を得る一方、アクターはロールアウト状態のみを見る。クリティックと追加コンテキストは推論時に破棄される。
報酬は3層構造：コアタスクスコアはすべてのfail_to_passとpass_to_passテストの合格を要求；標準行動制約は重複、悪いツール呼び出し、デバッグ痕跡をペナルティ；失敗軌跡インセンティブはF2によるファイル取得をスコアリングし、部分的なテストクレジットを与える。
5人のエキスパートが、逆KL、オフポリシースタート、およびPrune-OPDによるドリフト認識トランケーションを用いたマルチティーチャーオンポリシー蒸留により融合される。
結果
統一されたClaude Codeハーネスの下で、KAT-Coder-V2.5はPinchBenchで94.9を記録し、Opus 4.8の93.5を上回ってリード。SWE-Bench Proでは65.2で2位（Opus 4.8は69.2）、内部のKAT Code Benchでは53.1で2位（Opus 4.8は57.3）。しかし、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は別個の35B総パラメータ/3BアクティブのMoEモデルであり、Qwen3.6-35B-A3Bをベースに12.7万のSFT例で事後訓練され、その後RLが行われた。独立した社内プロトコルで評価されており、その結果は主力のフラッグシップテーブルとは比較できない。