Jak sprawdzić nowy model albo wersję agenta na twoich repozytoriach, zanim stanie się domyślna

Co naprawdę zmienia się przy aktualizacji

Poradnik Anthropic o ewaluacji podkreśla coś, co ma tu znaczenie: oceniając agenta, oceniasz harness i model razem. Aktualizacja może zmienić model, wersję narzędzia, jego ustawienia domyślne albo sposób czytania twoich instrukcji, a każda z tych zmian może przesunąć wyniki na twoich repozytoriach.

Aktualizacje przychodzą też bez niczyjej decyzji. Aliasy modeli w Claude Code wskazują zalecaną wersję i zmieniają się z czasem, natomiast pełna nazwa modelu przypina wersję, a administratorzy mogą ograniczyć dostępne modele przez availableModels w zarządzanych ustawieniach. W Copilot Business i Enterprise GitHub automatycznie włącza nowo wyznaczony model bazowy po 60 dniach i zobowiązuje się utrzymać model z długoterminowym wsparciem przez rok od jego wyznaczenia.

Dwa zestawy o różnych zadaniach

Anthropic oddziela ewaluacje możliwości od ewaluacji regresji i ten podział dobrze pasuje do decyzji o aktualizacji.

• Zestaw regresji: zadania, które obecna konfiguracja przechodzi niezawodnie, na przykład typowe poprawki błędów, dopisywanie testów i aktualizacje zależności z twojej historii. Powinien przechodzić niemal w całości, więc każdy spadek jest ostrzeżeniem.
• Zestaw możliwości: zadania, z którymi obecna konfiguracja sobie nie radzi i na których lepszy model powinien się wykazać. Z założenia zaczyna od niskiego odsetka zaliczeń.
• Sprawdzenia zachowania w obu: skryptowe kontrole twoich ograniczeń, na przykład nietknięte ścieżki z kodem generowanym, brak usuniętych testów i brak nowych zależności bez polecenia.

Anthropic uważa, że 20 do 50 zadań wziętych z prawdziwych porażek to dobry początek. Zbuduj je ze zmergowanych zmian odtwarzanych w izolowanych kopiach repozytorium, których historia kończy się przed zmianą, bez późniejszych refów, remote'ów i dostępu sieciowego do zmergowanego rozwiązania. Agent widzi istniejące testy, a testy akceptacyjne dodane z każdą zmianą są wstrzymane do oceny.

Jak przeprowadzić uczciwe porównanie

1. 1

   Utrzymaj resztę bez zmian

   Te same zadania, pliki instrukcji, uprawnienia i narzędzia dla obu wersji. Zapisuj wersję narzędzia, identyfikator modelu i ustawienia dla każdego uruchomienia i zmieniaj naraz tylko jedno z nich, jeśli narzędzie na to pozwala.

2. 2

   Każdą próbę zaczynaj od czystego stanu

   Świeże środowisko dla każdego uruchomienia, bez plików, cache'y, pamięci agenta ani historii z wcześniejszych prób.

3. 3

   Kilka prób na zadanie

   Wyniki różnią się między uruchomieniami. Raportuj odsetek zaliczeń za pierwszym razem, a dla zadań, które muszą się zawsze udawać, to, jak często przechodzą wszystkie próby. Przy 75 procentach sukcesu na próbę trzy niezależne próby przechodzą wszystkie tylko w około 42 procentach przypadków, a prawdziwe próby rzadko są w pełni niezależne.

4. 4

   Najpierw sprawdź zepsute zadania

   Zadanie, którego żadna wersja nigdy nie zalicza, to według Anthropic częściej zepsute zadanie niż niezdolny agent. Napraw je, zanim zniekształci porównanie.

Jak czytać wyniki przypadek po przypadku

Porównuj wersje dla każdego zadania, a nie tylko w sumie: które zadania kandydat zalicza po raz pierwszy, których po raz pierwszy nie zalicza, a które się nie zmieniły. Wyższa suma może ukryć regresję w jednym typie zadań. Potem przeczytaj transkrypty każdej nowej porażki. Zespoły Anthropic nie traktują wyników dosłownie, dopóki ktoś nie przeczyta transkryptów, bo porażka może równie łatwo wynikać z zadania, oceny albo harnessu, jak z modelu.

Hipotetyczny wynik: na 40 zadaniach regresji, po trzy próby każde, kandydat utrzymuje 37 i po raz pierwszy nie zalicza 3, wszystkich dotyczących migracji bazy danych. W zestawie możliwości po raz pierwszy zalicza 6 z 25 zadań, a koszt zaliczonego zadania jest mniej więcej taki sam. Transkrypty pokazują, że przepisuje już zmergowane migracje, czego plik instrukcji zabrania w linii dopasowanej do nawyków starego modelu, czyli wpisie tego rodzaju, do którego dokumentacja Claude Code zaleca wracać po dużych zmianach modeli. Zespół doprecyzowuje tę instrukcję, co zmienia harness, więc uruchamia ponownie pełne zestawy regresji, możliwości i zachowania z tą ostateczną konfiguracją, a obecną wersję testuje z tymi samymi instrukcjami, żeby zobaczyć, ile poprawy należy do modelu. Dopiero wtedy kandydat staje się domyślny, a stara wersja zostaje przypięta na wypadek wycofania.

Od wyniku do nowej wersji domyślnej

• Przed uruchomieniem ustal, jaka różnica jest istotna i co zablokowałoby aktualizację, i dopuść wynik nierozstrzygnięty.
• Najpierw przełącz grupę ochotników, potem wersję domyślną, a poprzednią wersję trzymaj przypiętą i dozwoloną na wypadek wycofania.
• Zapisz decyzję z wersją zestawu testów, wersją narzędzia, identyfikatorem modelu i ustawieniami, żeby kolejna aktualizacja zaczynała od znanego punktu odniesienia.
• Utrzymuj zestaw przy życiu: dodawaj zadania z nowych porażek, przenoś zadania możliwości, które teraz przechodzą niezawodnie, do zestawu regresji i zastępuj zadania, z których repozytorium wyrosło.

Ewaluacje na twoich repozytoriachJak zaprojektować uczciwy pilotaż agentów kodujących