KwaiKAT Team prezentuje KAT-Coder-V2.5: Model kodujący uczony na ponad 100 000 weryfikowalnych środowiskach

Zespół KwaiKAT z firmy Kuaishou zaprezentował KAT-Coder-V2.5, innowacyjny model kodujący, który został zaprojektowany do działania w rzeczywistych, wykonywalnych środowiskach repozytoriów, zamiast generować kod w pojedynczych turach. Model jest dostępny za pośrednictwem platformy StreamLake, a jego wariant o otwartej wadze, KAT-Coder-V2.5-Dev, został udostępniony oddzielnie na Hugging Face na licencji Apache-2.0.

Metodologia szkolenia i weryfikacji

Badania definiują weryfikowalne zadanie jako trójkę elementów: precyzyjny opis zadania, wykonywalne środowisko repozytorium oraz zestaw testów walidacyjnych. Poprawka jest uznawana za prawidłową tylko wtedy, gdy przejdzie wszystkie te etapy. Zadania są pozyskiwane z rzeczywistych zgłoszeń pull request i commitów, kontynuując linię SWE-bench. Zmiana kodu, która została scalona, dostarcza „złotą poprawkę” (golden patch), a towarzysząca jej zmiana testowa dostarcza „poprawkę testową” (test patch). Surowy tekst problemu jest odrzucany jako specyfikacja. Zamiast tego, opisy są regenerowane w trzech częściach:

• Stwierdzenie problemu oparte na złotej poprawce.
• Wymagania wynikające z poprawki testowej.
• Ograniczenia interfejsu wywnioskowane z obu.

Następnie przeprowadzana jest kontrola klarowności, która eliminuje wszelkie niejednoznaczne, niekompletne, niedookreślone lub wewnętrznie niespójne elementy.

Za środowisko odpowiada system AutoBuilder. Agent budujący analizuje repozytorium i tworzy skrypt konfiguracyjny, który instaluje zależności i uruchamia testy z czystej kopii. Agent weryfikujący wykonuje ten skrypt w izolowanym środowisku piaskownicy. Reguła akceptacji jest szczególnie interesująca: weryfikacja nie odczytuje kodów wyjścia ani nie przeszukuje wzorców logów. Zamiast tego, analizuje ustrukturyzowane dane wyjściowe frameworka testowego i akceptuje środowisko tylko wtedy, gdy ponad 90% oczekiwanych testów zostanie zebranych, a wyniki zaliczeń/niezaliczeń powtórzą się w kolejnych uruchomieniach. Niepowodzenia są przekazywane z powrotem jako ustrukturyzowane informacje do iteracyjnej naprawy.

Połączenie wstępnie skonfigurowanego środowiska bazowego, szablonów systemów kompilacji i biblioteki destylowanych przepisów budowania podniosło wskaźnik sukcesu konstrukcji z 16,5% do 57,2%. W rezultacie uzyskano ponad 100 000 weryfikowalnych środowisk obejmujących 12 języków programowania. Historia Git, metadane commitów i inne możliwe do wykorzystania ślady są usuwane, aby agenci nie mogli odczytać referencyjnego rozwiązania z repozytorium.

Optymalizacja procesu szkoleniowego i infrastruktury

Filtrowanie trajektorii na podstawie końcowego sukcesu testów może być mylące. Niektóre udane przebiegi opierają się na twardym kodowaniu, omijaniu mechanizmów lub skrótach zorientowanych na testy. Niektóre nieudane przebiegi zawierają cenne zachowania związane z wyszukiwaniem, lokalizacją i naprawą. KwaiKAT zajmuje się obiema tymi kwestiami. W przypadku „bliskich pomyłek” ukierunkowane wskazówki na poziomie procesu sygnalizują, co należy zbadać lub zweryfikować, nie ujawniając rozwiązania. Samo to podnosi wskaźnik zaliczeń zadań, które wcześniej miały zero zaliczeń, do około 20%. Ponieważ trajektorie z podpowiedziami zawierają informacje niedostępne podczas wnioskowania, zweryfikowana poprawka jest następnie naprawiana, a trajektoria bez podpowiedzi jest regenerowana z oryginalnego kontekstu zadania. Zachowywane są tylko próbki, które przechodzą weryfikację, nie wykazują wycieku podpowiedzi i pozostają spójne z poprawką.

W przypadku udanych przebiegów, bramki oparte na regułach usuwają nieprawidłowe, niestabilne lub eksploatacyjne trajektorie. Etap punktacji ocenia następnie eksplorację, lokalizację, rozumowanie przed edycją, wierność specyfikacji, konwencje repozytorium, minimalność poprawki, jakość weryfikacji, zachowanie odzyskiwania i uczciwość.

Trzeci mechanizm dotyczy nadmiernego dopasowania do uprzęży (harness overfitting). Nazwy narzędzi, konwencje argumentów, formaty wyjściowe i szablony promptów są randomizowane, podczas gdy funkcjonalność jest zachowana. Ponieważ weryfikacja jest zakotwiczona w wynikach testów, a nie w śladach uprzęży, jedno zadanie może być ponownie obsługiwane w wielu konfiguracjach uprzęży. Wprowadzane są również realistyczne perturbacje: brakujące zależności, przejściowe awarie poleceń, skrócone dane wyjściowe i zaszumione logi.

Podczas szkolenia KAT-Coder-V2 początkowo wolne krzywe nagród przypisywano algorytmowi RL. Jednak audyt wykazał, że około 16% trajektorii zakończyło się niepowodzeniem z powodu problemów z infrastrukturą piaskownicy, a nie z powodu polityki modelu. Niezgodności graniczne czasami powodowały puste obserwacje przez około 40 kroków i uszkodzenie nagród.

Trzy poprawki infrastrukturalne znacząco poprawiły sytuację:

• Polityka wczesnego usuwania obrazów obniżyła wykorzystanie dysku z 95% do 60%, redukując nieważne uruchomienia spowodowane przekroczeniem limitu czasu z 6-7% do poniżej 1%.
• Korekta zmiennych środowiskowych podczas zdalnej inicjalizacji piaskownicy zatrzymała nadpisywanie systemu, które zmieniało nagrody w 6-7% próbek, redukując błędy poniżej 1%.
• Serwer Gateway ominął główne punkty końcowe czatu, które powodowały 40% dryft tokenów przy skali około 200 tur, i wywoływał /generate bezpośrednio, aby zapewnić wyrównanie tokenów uruchomienia.

Łącznie te aktualizacje zmniejszyły wskaźnik błędów sprzężenia zwrotnego piaskownicy z około 16% do poniżej 2% i dziesięciokrotnie zmniejszyły liczbę załamań treningowych.

Architektura i wyniki

Zespół badawczy wybrał algorytm PPO z GAE zamiast metod trajektorii bez krytyka, ponieważ produkcyjne uprzęże dzielą sesje na strukturalnie odrębne próbki, co komplikuje grupowanie linii bazowych. Wykorzystując asymetryczny aktor-krytyk, krytyk otrzymuje uprzywilejowany kontekst treningowy (nagrody, testy, pokrycie, poprawki, metadane, przyszłe tury), podczas gdy aktor widzi tylko stan uruchomienia. Krytyk i dodatkowy kontekst są odrzucane podczas wnioskowania.

Nagrody są trójpoziomowe:

• Core Task Scores wymagają, aby wszystkie testy fail_to_pass i pass_to_pass zakończyły się sukcesem.
• Standard Behavior Constraints karzą za duplikację, złe wywołania narzędzi i pozostałości debugowania.
• Failed Trajectory Incentives punktują pobieranie plików za pomocą F2 i przyznają częściowe punkty za testy.

Pięciu ekspertów łączy się za pomocą Multi-Teacher On-Policy Distillation z wykorzystaniem odwrotnego KL, startu off-policy i obcinania uwzględniającego dryft z Prune-OPD.

W testach przeprowadzonych na ujednoliconej uprzęży Claude Code, KAT-Coder-V2.5 osiągnął wynik 94.9 na PinchBench, pokonując Opus 4.8, który uzyskał 93.5. Zajął drugie miejsce na SWE-Bench Pro (65.2 vs 69.2) oraz na wewnętrznym KAT Code Bench (53.1 vs 57.3). Model ten jednak odstaje na Terminal-Bench 2.1, zajmując ostatnie miejsce z wynikiem 60.7, za GLM-5.1 (61.8) i Opus 4.8 (84.6). Na SciCode uzyskał 50.3, dorównując GLM-5.2.

Warto zauważyć, że otwarty model KAT-Coder-V2.5-Dev to oddzielny wariant MoE (Mixture of Experts) o łącznej liczbie 35 miliardów parametrów i 3 miliardach aktywnych, post-trenowany na Qwen3.6-35B-A3B z wykorzystaniem 127 tysięcy przykładów SFT, a następnie RL. Jego wyniki, oceniane według oddzielnego wewnętrznego protokołu, nie są porównywalne z główną tabelą flagowych modeli.

Znaczenie dla rozwoju AI w kodowaniu

Wprowadzenie KAT-Coder-V2.5 i szczegółowe podejście do jego szkolenia i weryfikacji, w tym zaawansowane metody radzenia sobie z problemami infrastrukturalnymi i optymalizacją nagród, stanowią istotny krok w rozwoju agentów AI zdolnych do samodzielnego kodowania. Skupienie się na rzeczywistych środowiskach repozytoriów i rygorystycznych procesach weryfikacji podnosi poprzeczkę dla przyszłych modeli, wskazując kierunek, w którym AI może stać się bardziej niezawodnym i autonomicznym narzędziem w inżynierii oprogramowania. Wyniki modelu, choć zróżnicowane w zależności od benchmarku, pokazują jego potencjał i obszary, w których dalsze badania mogą przynieść znaczące ulepszenia.

Źródło: marktechpost.com