В мире генеративного искусственного интеллекта мы привыкли оценивать модели по их способности генерировать текст, код или изображения в изолированном режиме. Однако настоящий прорыв в области программирования происходит, когда ИИ-агент выходит за пределы простого генерации фрагментов кода и начинает работать внутри реальных, исполняемых репозиториев. Команда KwaiKAT из компании Kuaishou представила модель KAT-Coder-V2.5, которая позиционирует себя не просто как языковую модель, а как полноценного агента, способного понимать контекст, исправлять ошибки и проходить тесты в сложных средах. Это не просто очередное обновление весов; это сдвиг парадигмы в сторону «инфраструктурного» подхода к обучению агентов.
Что делает KAT-Coder-V2.5 особенным? В отличие от традиционных подходов, где модель выдает однократный ответ, эта система обучается на 100 000 верифицируемых сред репозиториев. Модель доступна через платформу StreamLake, а также существует открытая версия KAT-Coder-V2.5-Dev с лицензией Apache-2.0 на Hugging Face. Но за цифрами скрывается сложнейшая инженерная работа по созданию среды, в которой агент может учиться на реальных ошибках и успехах, а не на синтетических примерах.
01AutoBuilder: Создание сред, которые действительно работают
Фундаментальная проблема агентов-программистов заключается в том, что они часто не могут запустить свой собственный код. Чтобы решить эту задачу, KwaiKAT разработала систему под названием AutoBuilder. Исследователи определяют верифицируемую задачу как тройку элементов: точное описание задачи, исполняемую среду репозитория и набор тестов для валидации. Патч считается правильным только в том случае, если он проходит все тесты.
Данные для обучения добываются из реальных pull-запросов и коммитов, следуя методологии, заложенной в проекте SWE-bench. Однако здесь есть важное отличие: сырой текст задач (issue text) отбрасывается как спецификация. Вместо этого описания регенерируются в три части: формулировка проблемы, основанная на «золотом патче» (golden patch), требования, выведенные из тестового патча, и ограничения интерфейса, выведенные из обоих. Затем проводится проверка на ясность, которая отбрасывает любые двусмысленные, неполные или внутренне противоречивые спецификации.
AutoBuilder берет на себя работу с окружением. Агент сборки анализирует репозиторий и пишет скрипт конфигурации, который устанавливает зависимости и запускает тесты с чистой копии. Агент верификации выполняет этот скрипт в изолированной песочнице. Ключевой момент здесь — правило принятия. Верификация не просто читает коды выхода или ищет паттерны в логах. Она парсит структурированный вывод тестовых фреймворков и принимает среду только тогда, когда более 90% ожидаемых тестов собраны, а результаты (pass/fail) воспроизводятся от запуска к запуску.
Результатом этой работы стало создание более 100 000 верифицируемых сред, охватывающих 12 языков программирования. Использование предварительно настроенной базовой среды, шаблонов систем сборки и извлекаемой библиотеки дистиллированных рецептов сборки повысило успешность построения сред с 16,5% до 57,2%. При этом история Git, метаданные коммитов и другие следы, которые могли бы подсказать агенту решение, намеренно удаляются, чтобы предотвратить «читерство» модели.
02Цикл масштабирования данных: фильтрация по процессу
Одной из самых сложных задач при обучении агентов является фильтрация траекторий. Простая фильтрация по финальному успеху тестов может быть обманчивой. Некоторые успешные запуски могут полагаться на хардкод, обход механизмов безопасности или использование тестовых уязвимостей. В то же время некоторые неудачные запуски содержат ценное поведение поиска, локализации и исправления ошибок.
KwaiKAT решает эту проблему с двух сторон. Для «почти успешных» попыток (near misses) применяются целевые подсказки на уровне процесса, которые указывают, что нужно проверить, не раскрывая само решение. Это само по себе повысило долю успешных задач, которые ранее имели нулевой результат, примерно до 20%. Поскольку подсказанные траектории содержат информацию, недоступную во время вывода (inference), проверенный патч затем фиксируется, и траектория без подсказок регенерируется из исходного контекста задачи. Остаются только те образцы, которые прошли верификацию, не показали утечки подсказок и остаются согласованными с патчем.
Для успешных запусков применяются правила-фильтры, удаляющие недействительные, нестабильные или эксплуатирующие траектории. Затем происходит этап оценки, который ранжирует траектории по таким критериям, как исследование, локализация, рассуждение до редактирования, соответствие спецификации, соблюдение конвенций репозитория, минимальность патча, качество верификации, поведение восстановления и честность.
Третий механизм направлен на борьбу с переобучением на конкретную среду выполнения (harness). Названия инструментов, соглашения об аргументах, форматы вывода и шаблоны промптов рандомизируются при сохранении функциональности. Поскольку верификация привязана к результатам тестов, а не к следам использования инструментов, одна задача может быть подана в множество конфигураций. Вводятся реалистичные возмущения: отсутствующие зависимости, временные сбои команд, усеченные выводы и зашумленные логи.
03Инфраструктурные сбои как главный враг обучения
В процессе обучения KAT-Coder-V2.5 команда столкнулась с неожиданной проблемой: кривые вознаграждения росли слишком медленно. Изначально это приписывали алгоритму RL (обучения с подкреплением). Однако аудит выявил, что около 16% траекторий терпели неудачу из-за проблем с инфраструктурой песочницы, а не из-за политики модели. Несоответствие границ иногда приводило к тому, что наблюдения пустели на протяжении ~40 шагов, что портило вознаграждения.
Были предприняты три инфраструктурных исправления. Во-первых, политика принудительного удаления образов раннего выпуска снизила использование диска с 95% до 60%, сократив недействительные запуски из-за тайм-аутов с 6–7% до менее чем 1%. Во-вторых, исправление переменных окружения при удаленной инициализации песочницы остановило системные переопределения, которые меняли вознаграждения на 6–7% образцов. В-третьих, Gateway Server обошел основные чат-эндпоинты, которые вызывали дрейф токенов на ~200-шаговом масштабе, и вызывал /generate напрямую, чтобы обеспечить выравнивание токенов.
Вместе эти обновления снизили ошибку обратной связи песочницы с примерно 16% до менее чем 2% и сократили сбои обучения на порядок величины. Это наглядный пример того, что в агентном ИИ инфраструктура часто важнее архитектуры модели.
04Асимметричный PPO и трехуровневое вознаграждение
Команда выбрала PPO (Proximal Policy Optimization) с GAE (Generalized Advantage Estimation) вместо методов без критика, потому что производственные системы разбивают сессии на структурно различные образцы, что усложняет создание групповых базовых линий. Используя асимметричного актора-критика, Критик получает привилегированный контекст обучения (вознаграждения, тесты, покрытие, патчи, метаданные, будущие ходы), в то время как Актор видит только состояние развертывания. Критик и дополнительный контекст отбрасываются во время вывода.
Вознаграждения имеют трехуровневую структуру:
- Core Task Scores: требуют прохождения всех тестов fail_to_pass и pass_to_pass.
- Standard Behavior Constraints: штрафуют за дублирование, плохие вызовы инструментов и остатки отладки.
- Failed Trajectory Incentives: оценивают извлечение файлов через F2 и дают частичный кредит за тесты.
Для стабилизации обучения используется метод Multi-Teacher On-Policy Distillation с обратной KL-дивергенцией, стартом off-policy и усечением, чувствительным к дрейфу, из Prune-OPD.
05Открытая версия и практическое применение
Открытая версия KAT-Coder-V2.5-Dev представляет собой отдельную модель с архитектурой MoE (Mixture of Experts) с 35B общих параметров и 3B активными. Она была дообучена на Qwen3.6-35B-A3B с использованием 127K примеров SFT, а затем RL. Важно отметить, что ее результаты оцениваются по отдельному внутреннему протоколу и не являются напрямую сопоставимыми с основной таблицей бенчмарков флагманской версии.
Для разработчиков в России и странах СНГ доступ к таким моделям становится все более актуальным. Хотя прямое использование облачных API может быть ограничено, наличие весов на Hugging Face под лицензией Apache-2.0 позволяет локально развернуть KAT-Coder-V2.5-Dev на собственных серверах. Это открывает возможности для корпоративного использования, где конфиденциальность кода и контроль над инфраструктурой критически важны.
06Что это значит на практике
Выход KAT-Coder-V2.5 знаменует собой переход от «генерации кода» к «инженерии решений». Модель больше не просто пишет функцию; она понимает, как собрать проект, как запустить тесты и как исправить ошибку, если что-то пошло не так. Успех KwaiKAT демонстрирует, что ключ к созданию надежных ИИ-агентов лежит не только в увеличении размера модели, но и в качестве инфраструктуры, в которой она обучается.
Для разработчиков это означает, что в будущем мы сможем видеть более надежных помощников, которые могут самостоятельно разбираться в сложных legacy-кодах, не ломая существующую функциональность. Для исследователей это сигнал о том, что инвестиции в инфраструктуру верификации и фильтрации данных дают более высокую отдачу, чем просто поиск новых архитектурных решений. KAT-Coder-V2.5 — это шаг в сторону автономной разработки ПО, где ИИ становится полноценным членом команды, способным не только писать, но и проверять, и исправлять код в реальных условиях.
Источник: MarkTechPost ↗