Команда KwaiKAT компании Kuaishou представила KAT-Coder-V2.5 — модель для программирования, рассчитанную на работу внутри реальных исполняемых программных репозиториев, а не на генерацию одношаговых фрагментов кода. Обслуживаемая версия модели доступна через StreamLake. Отдельный вариант с открытыми весами, KAT-Coder-V2.5-Dev, выпущен на Hugging Face под лицензией Apache-2.0.

Релиз сосредоточен на агентных рабочих процессах программирования, в которых модель должна изучать репозиторий, понимать задачу, редактировать файлы, запускать тесты и проверять корректность патча. Такой фокус отражает более широкий сдвиг в оценке моделей для программирования: от изолированных задач на написание кода к сопровождению ПО на уровне репозитория, где воспроизводимые окружения и надежная тестовая обратная связь могут быть так же важны, как качество генерации кода. В проекте сделан акцент на окружениях репозиториев, построении данных, надежности sandbox, инфраструктуре обучения с подкреплением и оценке на бенчмарках.

AutoBuilder создает окружения, которые запускают нужные тесты

В исследовании проверяемая задача программирования определяется как триада: точное описание задачи, исполняемое окружение репозитория и набор валидационных тестов. Патч считается корректным только в том случае, если он проходит весь набор проверок.

Задачи извлекаются из реальных pull request и коммитов, следуя линии SWE-bench. Объединенное изменение кода дает эталонный патч, а сопутствующее изменение тестов — тестовый патч. Система не использует исходный текст issue как спецификацию. Вместо этого описания задач заново формируются из трех компонентов: постановки проблемы, основанной на эталонном патче, требований, выведенных из тестового патча, и интерфейсных ограничений, полученных из обоих источников. Проверка ясности удаляет задачи, которые являются неоднозначными, неполными, недостаточно специфицированными или внутренне противоречивыми.

AutoBuilder отвечает за процесс построения окружения. Агент сборки анализирует репозиторий и пишет конфигурационный скрипт, который устанавливает зависимости и запускает тесты из чистой checkout-копии. Затем агент верификации выполняет этот скрипт в изолированной sandbox-среде.

Процесс приемки не опирается на коды завершения или сопоставление шаблонов в логах. Вместо этого верификация разбирает структурированный вывод тестовых фреймворков. Окружение принимается только тогда, когда собрано более 90% ожидаемых тестов, а результаты pass/fail воспроизводятся при повторных запусках. Сведения о сбоях возвращаются в структурированном виде для итеративного исправления.

Комбинируя предварительно настроенное базовое окружение, шаблоны систем сборки и извлекаемую библиотеку очищенных рецептов сборки, команда повысила успешность построения окружений с 16.5% до 57.2%. Получившийся датасет включает более 100,000 проверяемых окружений на 12 языках программирования. История Git, метаданные коммитов и другие пригодные для эксплуатации следы удаляются, чтобы агенты не могли получить эталонное решение напрямую из репозитория.

Data Scaling Flywheel фильтрует данные по качеству процесса

В проекте утверждается, что фильтрация траекторий только по итоговому успеху тестов может вводить в заблуждение. Некоторые успешные запуски могут зависеть от жестко заданных решений, обхода предполагаемых механизмов или сокращенных путей, подстроенных под тесты. В то же время некоторые неудачные запуски могут содержать полезное поведение при поиске, локализации и исправлении.

KwaiKAT обрабатывает оба случая. Для попыток, близких к успеху, целевые подсказки на уровне процесса указывают, что следует проверить или верифицировать, не раскрывая решение. Это повышает долю успешных прохождений для задач, ранее не имевших ни одного успешного запуска, примерно до 20%. Поскольку траектории с подсказками содержат информацию, недоступную во время инференса, затем фиксируется проверенный патч и из исходного контекста задачи заново генерируется траектория без подсказок. Сохраняются только те образцы, которые проходят верификацию, не содержат утечки подсказок и остаются согласованными с патчем.

Для траекторий, которые уже проходят проверку, правила-фильтры удаляют некорректные, нестабильные или эксплуатирующие примеры. Затем этап скоринга оценивает исследование, локализацию, рассуждение до редактирования, соответствие спецификации, соблюдение соглашений репозитория, минимальность патча, качество верификации, поведение при восстановлении и честность.

Третий механизм направлен на снижение переобучения под harness. Названия инструментов, соглашения об аргументах, форматы вывода и шаблоны prompt рандомизируются при сохранении функциональности. Поскольку верификация привязана к результатам тестов, а не к следам harness, одна и та же задача может быть предъявлена в нескольких конфигурациях harness. Система также вносит реалистичные возмущения, включая отсутствующие зависимости, временные сбои команд, усеченный вывод и зашумленные логи.

Сбои sandbox влияли на награды раньше, чем алгоритмические ограничения

Во время обучения KAT-Coder-V2 медленный рост кривых награды сначала связывали с алгоритмом обучения с подкреплением. Последующий аудит показал, что примерно 16% траекторий завершались неудачно из-за проблем sandbox-инфраструктуры, а не политики модели. Несовпадения границ иногда обнуляли наблюдения примерно на 40 шагов и искажали награды.

Команда внедрила три инфраструктурных исправления. Во-первых, политика раннего удаления образов снизила использование диска с 95% до 60%, сократив число недействительных rollout из-за timeout с 6–7% до менее 1%. Во-вторых, исправление переменных окружения при инициализации удаленной sandbox-среды предотвратило системные переопределения, которые меняли награды на 6–7% образцов, снизив эти ошибки ниже 1%. В-третьих, Gateway Server обошел основные chat-endpoints, которые вызывали 40% drift токенов на масштабе примерно 200 ходов из-за повторного применения apply_chat_template и повторной токенизации. Вместо этого система напрямую вызывала /generate, чтобы сохранить выравнивание токенов rollout.

В совокупности эти изменения снизили уровень ошибок обратной связи sandbox примерно с 16% до менее чем 2% и сократили срывы обучения на порядок. Этот вывод также подчеркивает практическое ограничение обучения агентного программирования: качество награды зависит не только от архитектуры модели или метода оптимизации, но и от окружающей системы исполнения.

Асимметричный PPO и трехуровневые награды

Исследователи выбрали PPO с GAE вместо методов траекторий без critic, поскольку производственные harness делят сессии на структурно разные образцы, что усложняет групповые базовые линии.

В обучающей схеме используется асимметричная архитектура actor–critic. Critic получает привилегированный обучающий контекст, включая награды, тесты, покрытие, патчи, метаданные и будущие ходы. Actor видит только состояние rollout. На этапе инференса Critic и дополнительный контекст отбрасываются.

Награды организованы в три уровня. Core Task Scores требуют прохождения всех тестов fail_to_pass и pass_to_pass. Standard Behavior Constraints штрафуют за дублирование, некорректные вызовы инструментов и остатки отладки. Failed Trajectory Incentives оценивают извлечение файлов через F2 и присваивают частичный балл за тесты.

Пять экспертов объединяются через Multi-Teacher On-Policy Distillation с использованием reverse KL, off-policy старта и drift-aware truncation из Prune-OPD.

Результаты бенчмарков

В едином Claude Code harness модель KAT-Coder-V2.5 лидировала в своей группе на PinchBench с результатом 94.9, опередив Opus 4.8 с 93.5. Она заняла второе место на SWE-Bench Pro с 65.2 против 69.2 и второе место на внутреннем KAT Code Bench с 53.1 против 57.3.

На Terminal-Bench 2.1 модель выступила слабее: она заняла последнее место с 60.7, уступив GLM-5.1 с 61.8 и Opus 4.8 с 84.6. На SciCode она набрала 50.3, сравнявшись с GLM-5.2. Смешанные результаты делают важными контекст harness и область применения бенчмарка, поскольку исправление репозиториев, работа в терминале и научное программирование измеряют разные части агентной системы программирования.

KAT-Coder-V2.5-Dev с открытыми весами — это отдельная MoE-модель с 35B параметров всего / 3B активных параметров, дообученная на Qwen3.6-35B-A3B с использованием 127K SFT-примеров, а затем обучения с подкреплением. Она оценивалась по отдельному внутреннему протоколу, поэтому ее результаты несопоставимы с основной таблицей флагманских бенчмарков.

Основные материалы проекта включают статью, страницу продукта StreamLake и веса модели KAT-Coder-V2.5-Dev на Hugging Face.