Nowszy model nie zawsze jest lepszy w konkretnym zastosowaniu. Aktualizacja wymaga sprawdzenia, a nie samej podmiany pliku.
Zestaw sprawdzający
Te same przykłady co przy pierwszym wyborze, z oczekiwanym wynikiem. Bez niego porównanie sprowadza się do wrażenia.
Zestaw nie musi być duży. Kilkanaście przypadków z codziennej pracy, w tym kilka trudnych — dokument niepełny, nietypowy układ, treść z błędami — wystarcza, żeby wychwycić pogorszenie. Ważniejsze od liczby przykładów jest to, żeby przy każdej próbie były dokładnie te same.
Polecenia przygotowane pod model
Instrukcje dostrojone do jednej wersji potrafią działać gorzej w innej. Po aktualizacji trzeba je sprawdzić, a czasem poprawić.
Dotyczy to zwłaszcza poleceń narzucających ścisłą formę wyniku. Nowa wersja może odpowiadać sensownie, a mimo to inaczej układać strukturę odpowiedzi — i wtedy program odbierający wynik przestaje go rozumieć, choć sama treść jest poprawna. To najczęstsza niespodzianka po podmianie. Ten wątek rozwija tekst o tym, od czego zależy jakość odpowiedzi.
Zachowanie poprzedniej wersji
Do czasu potwierdzenia, że nowa działa lepiej. Powrót musi być możliwy jednym poleceniem.
Warunkiem powrotu jest komplet: plik modelu, ustawienia uruchomienia i treść poleceń w wersji sprzed zmiany. Sam model nie wystarczy. To dokładnie ten sam zakres, który obejmują kopie zapasowe środowiska, więc obie sprawy warto załatwić razem.
Powrót trzeba też przećwiczyć, zanim będzie potrzebny. Możliwość zapisana w dokumentacji i możliwość sprawdzona w praktyce to dwie różne rzeczy, a różnicę odkrywa się zwykle w najgorszym momencie.
Kiedy aktualizacja nie jest potrzebna
Jeśli obecny model wykonuje swoje zadanie i nikt nie zgłasza braków, wymiana wnosi wyłącznie ryzyko. Nowsza wersja nie poprawi procesu, który już działa poprawnie, a każda podmiana wymaga ponownego sprawdzenia poleceń i zestawu przykładów. Aktualizacja ma sens wtedy, gdy istnieje konkretne zadanie, z którym obecna wersja sobie nie radzi.
Rytm
Sprawdzanie nowości co kwartał wystarcza. Podmiana przy każdej publikacji to praca bez końca i ciągła niestabilność wyników.
Wyjątkiem są poprawki dotyczące bezpieczeństwa narzędzia uruchamiającego — te wchodzą osobnym trybem i nie czekają na kwartał. Warto rozdzielić te dwa rytmy, bo dotyczą różnych rzeczy: jeden modelu, drugi programu, który go obsługuje.
Format zapisu
Zmienia się rzadziej niż same modele, ale zmienia. Aktualizacja narzędzia uruchamiającego bywa warunkiem wczytania nowszej wersji.
Kolejność ma tu znaczenie. Najpierw sprawdzenie, czy nowsza wersja narzędzia nadal obsługuje to, co już działa, a dopiero potem podmiana modelu. Dwie zmiany naraz utrudniają ustalenie, która z nich zawiniła.
Zapis wyników
Wyniki zestawu sprawdzającego dla każdej wersji. To jedyny sposób, żeby po roku wiedzieć, czy jakość rosła, czy spadała.
Wystarczy krótka notatka: data, wersja, wynik na zestawie, uwagi. Przy okazji jest to gotowa odpowiedź na pytanie, dlaczego firma pracuje akurat na tym modelu, a nie na najnowszym z przeglądu modeli otwartych.
