快手 KAT-Coder-V2.5、実行環境対応のコーディング AI を公開
快手(Kuaishou)の KwaiKAT チームは、実行可能なリポジトリ環境で動作し、10 万件以上の検証済みデータセットを基に訓練されたエージェント型コーディングモデル「KAT-Coder-V2.5」を発表した。
AI算出
主要ニュースainew評価標準
記事は AI コーディングエージェントの最新バージョンとその革新的な学習データ生成プロセスを報じており、AI テクノロジーの核心テーマに該当します。また、明確なモデル名とバージョンが含まれるため検索機会スコアは最高値となりますが、日本企業との直接的な関連性や日本語一次情報としての独自性は限定的です。
6つの評価軸を見る
- AI関連度
- 100
- 情報源の信頼性
- 25
- 新規性
- 75
- 調べる価値
- 75
- 重複の少なさ
- 100
- 日本での有用性
- 25
この記事の3ポイント
- 1
実行可能環境でのトレーニングと検証
- 2
高品質な検証可能環境の自動構築
- 3
プロセスベースのデータフィルタリング
なぜ重要か・誰に関係するか
このアプローチは、コード生成モデルが単なるパターンマッチングではなく、実際の開発環境で動作する実用的な解決策を導き出す能力を劇的に高める可能性があるため重要である。開発者や企業の AI 導入担当者は、生成されたコードの信頼性を検証するための新しい基準として、この「実行可能環境での検証」パラダイムを確認し、自社のワークフローへの適用可能性を検討すべきである。
AI深層分析を開く2026年7月26日 12:16
キーポイント
実行可能環境でのトレーニングと検証
単なるコード生成ではなく、実際のリポジトリ内で動作する環境を構築し、テストの通過率を基準に正当性を厳密に評価する手法を採用している。
高品質な検証可能環境の自動構築
AutoBuilder と呼ばれるシステムが依存関係のインストールやテスト実行を自動化し、成功率を 16.5% から 57.2% に引き上げることに成功した。
プロセスベースのデータフィルタリング
単なる最終結果だけでなく、学習プロセスにおける試行錯誤やヒントの漏洩を検証し、信頼性の高いトレーニングデータを厳選する「Data Scaling Flywheel」を構築した。
オープンウェイトモデルの公開
開発者向けの軽量版「KAT-Coder-V2.5-Dev」が Hugging Face で Apache-2.0 ライセンスの下に公開され、StreamLake からも利用可能である。
インフラ障害の特定と修正によるトレーニング効率化
トレーニング中の報酬曲線の遅延原因がモデルアルゴリズムではなくサンドボックス環境のインフラ障害(約16%)にあることが判明し、ディスク使用率の最適化やトークン整合性の確保によりエラー率を2%未満に削減した。
重要な引用
The served model is available through StreamLake.
A patch is correct only if it passes all of them.
Verification does not read exit codes or grep log patterns. It parses structured test-framework output.
Together, these updates reduced the sandbox feedback error rate from roughly 16% to below 2% and cut training collapses by an order of magnitude.
編集コメントを表示
編集コメント
単なるコード生成を超え、実行可能な環境で検証されることで実用性が担保されたエージェント型モデルの登場は、開発現場における AI ツールの信頼性向上に寄与する。特に、学習プロセス自体を厳密にフィルタリングする手法は、今後の高品質データセット構築の重要な指針となるだろう。
快手 KwaikAT チームは、KAT-Coder-V2.5 を発表しました。このモデルは単発のコードを出力するのではなく、実際の実行可能なリポジトリ内で動作するように訓練されたコーディングモデルです。
提供されているモデルは StreamLake から利用可能です。また、Apache-2.0 ライセンスの下で、オープンウェイト版である KAT-Coder-V2.5-Dev が Hugging Face で個別にリリースされています。
AutoBuilder:実際に意図したテストを実行する環境
本研究では、検証可能なタスクを 3 つの要素(トリプレット)として定義しています。具体的には、正確なタスク説明、実行可能なリポジトリ環境、そして検証用テストセットです。パッチが正しいと判定されるのは、これらすべての条件を満たした場合に限られます。
タスクは SWE-bench の系譜に従い、実際のプルリクエストやコミットから抽出されます。マージされたコード変更が「正解の修正(ゴールデンパッチ)」となり、それに伴うテストの変更が「テスト用パッチ」として機能します。生の issue 記述仕様は採用せず、代わりに説明を 3 つの部分に再構成します。1 つ目はゴールデンパッチに基づいた問題文、2 つ目はテストパッチから導き出された要件、そして両方から推測されるインターフェース制約です。その後、曖昧さや不完全さ、不十分な仕様、内部的な矛盾があるものはすべて排除する明確性チェックが行われます。
AutoBuilder は環境側の処理を担当します。ビルドエージェントがリポジトリを解析し、依存関係をインストールしてテストを実行するための設定スクリプトを作成します。検証エージェントは、このスクリプトを隔離されたサンドボックス内で実行します。
この検証ルールこそが最も興味深い点です。単に終了コードやログパターンを grep するのではなく、構造化されたテストフレームワークの出力を解析します。環境が採用されるのは、期待されるテストの 90% 以上が収集され、かつ実行ごとに結果(合格/不合格)が再現された場合のみです。失敗したケースは構造化情報としてフィードバックされ、反復的な修復に活用されます。
事前設定済みのベース環境、ビルドシステムテンプレート、そして抽出されたビルドレシピの再利用可能なライブラリを組み合わせることで、構築成功率は 16.5% から 57.2% に向上しました。その結果、12 の言語にまたがる 10 万を超える検証可能な環境が生成されました。エージェントがリポジトリから参照解答を読み取れないよう、Git の履歴やコミットメタデータ、その他の利用可能な痕跡はすべて削除されています。
データのスケールアップ・フライホイール:フィルタリングのプロセス
最終的なテストの成否だけで軌道(トライアル)をフィルタリングするのは誤解を招きます。合格した実行の中には、ハードコーディングや仕組みの迂回、テスト対策のための近道に依存しているケースがあります。一方で、失敗した実行には貴重な探索、ローカライズ、修復の行動が含まれていることもあります。
KwaiKAT は両方向の課題に対応しています。わずかに失敗したケースでは、プロセスレベルのヒントが解決策を明かさずに「何を検証すべきか」を示します。これだけで、以前は 0% だったタスクの合格率が約 20% に向上しました。
ただし、ヒント付きの軌跡には推論時に利用できない情報が含まれているため、検証済みのパッチを修正した上で、元のタスク文脈からヒントなしの軌跡を再生成します。最終的に残すのは、検証に合格し、ヒントの漏洩がなく、パッチと整合性が保たれるサンプルだけです。
成功した実行については、ルールベースのゲートで無効・不安定・悪意のある軌跡を除外します。その上で、探索性、特定精度、編集前の推論、仕様への忠実度、リポジトリの慣習遵守、パッチの最小化、検証品質、回復動作、そして誠実さといった項目をスコアリングします。
さらに、ハルネス(テスト環境)への過学習を防ぐ仕組みも用意されています。機能は維持したまま、ツール名や引数の規約、出力形式、プロンプトテンプレートをランダム化します。検証がテスト結果に紐付いているため、1 つのタスクをさまざまなハルネス構成で再実行可能です。また、依存関係の欠落、一時的なコマンド失敗、出力の途中切断、ノイズの多いログといった現実的な摂動も注入しています。
パイプラインの詳細と数値については以下をご覧ください。
(function(){
window.addEventListener("message", function(e){
if(!e.data || typeof e.data.katHeight !== "number") return;
var f = document.getElementById("mtp-kat-frame");
if(f) f.style.height = e.data.katHeight + "px";
});
})();
インフラの不具合が報酬を制限していた
KAT-Coder-V2 のトレーニング中、報酬曲線の伸び悩みは当初、強化学習(RL)アルゴリズムのせいだと考えられていました。しかし監査の結果、軌道の約 16% がモデルの方針ではなくサンドボックスのインフラ問題によって失敗していることが判明しました。具体的には、境界設定の不整合により観測データが約 40 ステップにわたって空になり、報酬値が破損するケースが多発していたのです。
これを受けて 3 つのインフラ対策が講じられました。まず、リリース直後のイメージを早期に削除するポリシーを導入し、ディスク使用率を 95% から 60% に抑えました。その結果、タイムアウトによる無効なロールアウトが 6〜7% から 1% 未満に激減しました。次に、リモートサンドボックスの初期化時に環境変数を修正することで、サンプルの約 6〜7% で報酬を反転させていたシステム側の強制書き換えを防ぎ、エラー率を 1% 以下に抑えました。最後に、ゲートウェイサーバーが主流のチャットエンドポイントを迂回し、直接 /generate を呼び出すように変更しました。これにより、apply_chat_template の再適用や再トークン化によって生じていた、約 200 ターン規模でのトークンドリフト(40%)を解消し、ロールアウト時のトークン整合性を確保しました。
これらの更新により、サンドボックスからのフィードバックエラー率は概ね 16% から 2% 未満に低下し、トレーニングの崩壊は桁違いに減少しました。
非対称 PPO と 3 段階報酬
研究チームは、PPO(Proximal Policy Optimization)を GAE(Generalized Advantage Estimation)付きで採用し、批評家なしの軌道手法を選ばなかった。その理由は、本番環境でのハルネスがセッションを構造的に異なるサンプルに分割するため、グループベースラインの設定が複雑になるからだ。
非対称なアクター・クリティック構造を採用することで、クリティックは報酬、テスト結果、カバレッジ率、パッチ、メタデータ、将来のターンといった特権的なトレーニングコンテキストを利用できる。一方、アクターがアクセスできるのはロールアウト時の状態のみだ。推論時にはクリティックと追加コンテキストは破棄される。
報酬設計は 3 つの階層から成る。「コアタスクスコア」では、fail_to_pass と pass_to_pass の両方のテストをすべてパスすることが必須条件となる。「標準行動制約」では、コードの重複、不適切なツール呼び出し、デバッグ残りの削除がペナルティ対象だ。さらに「失敗軌道インセンティブ」では、F2 を通じたファイル取得にスコアが付与され、部分的なテスト成功にもクレジットが加算される。
5 人の専門家による知見は、逆 KL 発散を用いたマルチティーチャーオンポリシー蒸留によって統合される。この手法にはオフポリシーでの開始と、Prune-OPD から派生したドリフト認識型トリュンケーションが含まれる。
Results
統一された Claude Code ハルネス下で、KAT-Coder-V2.5 は PinchBench で 94.9 のスコアを記録し、Opus 4.8(93.5)を上回ってパネル中最上位となった。SWE-Bench Pro では 65.2 で 2 位(首位は 69.2)、社内ベンチである KAT Code Bench でも 53.1 と 2 位(首位は 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 だ。これは Qwen3.6-35B-A3B を基に、127K の SFT(Supervised Fine-Tuning)例で微調整し、その後 RL(Reinforcement Learning)で追加学習した、総パラメータ数 350 億・アクティブパラメータ数 30 億の MoE モデルである。評価は社内独自のプロトコルで行われたため、主要なフラッグシップモデルの結果とは直接比較できない。
Key Takeaways
KwaiKAT は、エージェント型コーディングをモデルの規模の問題ではなく、インフラストラクチャの問題として捉えています。
AutoBuilder によって環境構築の成功率は 16.5% から 57.2% に引き上げられ、12 の言語にわたる 10 万件以上の検証可能な環境が生成されました。
サンドボックスの監査では、強化学習の軌道の約 16% がポリシーではなくサンドボックス自体の問題で失敗していることが判明しました。この問題を修正した結果、失敗率は 2% 未満にまで低下しています。
KAT-Coder-V2.5 は PinchBench で 94.9 のスコアを記録しトップに立ち、SWE-Bench Pro では Opus 4.8 に次ぐ 65.2 のスコアで 2 位を獲得しました。
オープンウェイトの KAT-Coder-V2.5-Dev は、Apache-2.0 ライセンスの下で公開されている、独自にベンチマークされた 35B-A3B モデルです。
論文、Hugging Face 上のモデル重み、そしてプロダクトページをチェックしてください。本研究のすべての功績は、このプロジェクトの研究チームにあります。
KwaiKAT チームが 10 万件以上の検証可能なリポジトリ環境で訓練されたエージェント型コーディングモデル「KAT-Coder-V2.5」を発表したという記事は、MarkTechPost で最初にお伝えしました。
原文を表示
The KwaiKAT Team at Kuaishou has introduced the KAT-Coder-V2.5. It is a coding model trained to operate inside real, executable repositories rather than emit single-turn code. The served model is available through StreamLake. An open-weight variant, KAT-Coder-V2.5-Dev, was released separately on Hugging Face under Apache-2.0.
AutoBuilder: environments that actually run the intended tests
The research frames a verifiable task as a triplet. It needs a precise task description, an executable repository environment, and a set of validation tests. A patch is correct only if it passes all of them.
Tasks are mined from real pull requests and commits, following the SWE-bench lineage. The merged code change supplies a golden patch and the accompanying test change supplies a test patch. Raw issue text is discarded as a specification. Instead, descriptions are regenerated into three parts: a problem statement grounded in the golden patch, requirements derived from the test patch, and interface constraints inferred from both. A clarity check then drops anything ambiguous, incomplete, underspecified, or internally inconsistent.
AutoBuilder handles the environment side. A build agent analyzes the repository and writes a configuration script that installs dependencies and runs tests from a clean checkout. A verification agent executes that script in an isolated sandbox.
The acceptance rule is the interesting part. Verification does not read exit codes or grep log patterns. It parses structured test-framework output, and accepts an environment only when more than 90% of expected tests are collected and pass/fail outcomes reproduce across runs. Failures are fed back as structured information for iterative repair.
Combining a preconfigured base environment, build-system templates, and a retrievable library of distilled build recipes raised the construction success rate from 16.5% to 57.2%. The result is over 100,000 verifiable environments spanning 12 languages. Git history, commit metadata, and other exploitable traces are stripped so agents cannot read the reference solution out of the repo.
Data Scaling Flywheel: filtering on process
Filtering trajectories by final test success is misleading. Some passing runs rely on hard-coding, mechanism bypassing, or test-oriented shortcuts. Some failing runs contain valuable search, localization, and repair behavior.
KwaiKAT addresses both directions. For near misses, targeted process-level hints indicate what to inspect or verify without revealing the solution. That alone raises the pass rate of previously zero-pass tasks to roughly 20%. Because hinted trajectories contain information unavailable at inference, the verified patch is then fixed and a hint-free trajectory is regenerated from the original task context. Only samples that pass verification, show no hint leakage, and stay consistent with the patch are retained.
For passing runs, rule-based gates remove invalid, unstable, or exploitative trajectories. A scoring stage then rates exploration, localization, pre-edit reasoning, specification fidelity, repository conventions, patch minimality, verification quality, recovery behavior, and honesty.
A third mechanism targets harness overfitting. Tool names, argument conventions, output formats, and prompt templates are randomized while functionality is preserved. Because verification is anchored to test outcomes rather than harness traces, one task can be re-served under many harness configurations. Realistic perturbations are injected too: missing dependencies, transient command failures, truncated outputs, and noisy logs.
Explore the pipeline and the numbers
(function(){
window.addEventListener("message", function(e){
if(!e.data || typeof e.data.katHeight !== "number") return;
var f = document.getElementById("mtp-kat-frame");
if(f) f.style.height = e.data.katHeight + "px";
});
})();
Infrastructure failures capped rewards before algorithmic limits
During KAT-Coder-V2 training, slow reward curves were initially blamed on the RL algorithm. However, an audit revealed that ~16% of trajectories failed due to sandbox infrastructure issues rather than the model policy, with boundary misalignments sometimes emptying observations for ~40 steps and corrupting rewards.
Three infrastructure fixes followed. First, an early-release image eviction policy lowered disk usage from 95% to 60%, reducing timeout-induced invalid rollouts from 6–7% to under 1%. Second, correcting environment variables during remote sandbox initialization stopped system overrides that flipped rewards on 6–7% of samples, cutting errors below 1%. Third, the Gateway Server bypassed mainstream chat endpoints—which caused 40% token drift at a ~200-turn scale by re-applying apply_chat_template and re-tokenizing—and called /generate directly to ensure rollout token alignment.
Together, these updates reduced the sandbox feedback error rate from roughly 16% to below 2% and cut training collapses by an order of magnitude.
Asymmetric PPO and a three-tier reward
The research team chose PPO with GAE over critic-free trajectory methods because production harnesses split sessions into structurally distinct samples, complicating group baselines.
Using asymmetric actor–critic, the Critic gets privileged training context (rewards, tests, coverage, patches, metadata, future turns), while the Actor sees only rollout state. The Critic and extra context are discarded at inference.
Rewards are three-tiered: Core Task Scores require all fail_to_pass and pass_to_pass tests to pass; Standard Behavior Constraints penalize duplication, bad tool calls, and debug remnants; Failed Trajectory Incentives score file retrieval via F2 and give partial test credit.
Five experts fuse via Multi-Teacher On-Policy Distillation using reverse KL, an off-policy start, and drift-aware truncation from Prune-OPD.
Results
Under a unified Claude Code harness, KAT-Coder-V2.5 leads its panel on PinchBench with 94.9, beating Opus 4.8 at 93.5. It places second on SWE-Bench Pro (65.2 vs 69.2) and the internal KAT Code Bench (53.1 vs 57.3).
However, it lags on Terminal-Bench 2.1, placing last with 60.7 behind GLM-5.1 (61.8) and Opus 4.8 (84.6). On SciCode, it scores 50.3, matching GLM-5.2.
Notably, the open-weight KAT-Coder-V2.5-Dev is a separate 35B-total / 3B-active MoE post-trained on Qwen3.6-35B-A3B using 127K SFT examples, then RL. Evaluated on a separate in-house protocol, its results are not comparable to the main flagship table.
Key Takeaways
KwaiKAT treats agentic coding as an infrastructure problem, not a model-scale problem.
AutoBuilder lifted environment construction success from 16.5% to 57.2%, yielding 100,000+ verifiable environments across 12 languages.
A sandbox audit found ~16% of RL trajectories failed because of the sandbox, not the policy; fixes cut that to below 2%.
KAT-Coder-V2.5 tops PinchBench at 94.9 and ranks second on SWE-Bench Pro at 65.2, behind Opus 4.8.
The open-weight KAT-Coder-V2.5-Dev is a separate 35B-A3B MoE under Apache-2.0, with its own benchmark numbers.
Check out the Paper, the Model Weight on Hugging Face, and the Product Page. All credit for this research goes to the researchers of this project.
The post KwaiKAT Team Releases KAT-Coder-V2.5: An Agentic Coding Model Trained on 100,000+ Verifiable Repository Environments appeared first on MarkTechPost.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み