Zmiana modelu AI w działającym systemie: jak nie uzależnić firmy

Zmiana modelu AI w działającym systemie jest pewna, niepewny jest tylko termin. Dostawcy wycofują starsze modele regularnie, więc system oparty na jednym konkretnym modelu ma wpisaną datę ważności. Żeby nie uzależnić firmy od jednego dostawcy, trzymaj we własnym kodzie prompty, zestaw testów odpowiedzi i jedną warstwę, przez którą system rozmawia z modelem, a w umowach zapisz, kto pilnuje wycofań i kto płaci za przejście. Poniżej opisuję, co psuje się przy zmianie modelu, jak ją przetestować, jak policzyć koszt i co zapisać w umowie z wykonawcą.

Dlaczego zmiana modelu AI dotyczy każdej firmy korzystającej z API

Model językowy dostępny przez API to zależność taka sama jak biblioteka czy wersja PHP: ma cykl życia i koniec. Różnica polega na tym, że o końcu decyduje dostawca i robi to częściej, niż firmy są przyzwyczajone.

Zasady są opisane publicznie. OpenAI na stronie o wycofywaniu modeli z API deklaruje co najmniej 6 miesięcy uprzedzenia dla modeli ogólnie dostępnych i znacznie krótszy czas, np. 2 tygodnie, dla modeli w wersji preview. Na tej samej stronie widać, że 14 października 2026 r. firma powiadomiła o wyłączeniu części modeli z serii GPT-4 z dniem 14 stycznia 2027 r.

Anthropic w dokumentacji wycofań modeli zapowiada co najmniej 60 dni uprzedzenia dla modeli udostępnionych publicznie i wprost pisze, że zapytania do wycofanego modelu kończą się błędem. Obaj dostawcy powiadamiają klientów o wycofaniach e-mailem, na adres przypisany do konta. Jeśli konto API założył kiedyś wykonawca albo pracownik, który już nie pracuje w firmie, ostrzeżenie może trafić donikąd.

Co się psuje przy zmianie modelu

Nowy model zwykle jest lepszy w testach dostawcy, ale odpowiada inaczej niż poprzedni. System zbudowany pod stary model polega na jego nawykach, często nieświadomie.

Najczęstsze różnice, które wychodzą po przełączeniu:

• format odpowiedzi: inna kolejność pól, dodatkowy komentarz przed danymi, inna wielkość liter w etykietach,
• długość i ton: odpowiedzi dłuższe albo krótsze, bardziej ostrożne, z innymi zastrzeżeniami,
• odmowy: zapytania, na które stary model odpowiadał, a nowy odmawia albo odwrotnie,
• koszt i czas: inna cena za tokeny, inny sposób liczenia tokenów, inny czas odpowiedzi,
• prompty: instrukcje dostrajane miesiącami pod jeden model na innym działają gorzej.

Weźmy przykład: system sortuje wiadomości od klientów do działów i oczekuje etykiety „reklamacja”. Nowy model zwraca „Reklamacja” z wielkiej litery i krótkim uzasadnieniem. Integracja nie rozpoznaje etykiety, wiadomości trafiają do kolejki ogólnej, a nikt tego nie zauważa przez kilka dni, bo system nie zgłasza błędu.

Osobny przypadek to wyszukiwanie semantyczne i asystenci typu RAG. Jeśli zmienia się model, który zamienia tekst na wektory, całą bazę dokumentów trzeba przeliczyć od nowa, bo wektory z różnych modeli do siebie nie pasują. Przy dużych zbiorach to osobny etap projektu, o czym warto pamiętać, czytając o tym, jak przygotować dane pod RAG.

Co trzymać we własnym kodzie

Niezależność od dostawcy nie polega na używaniu kilku modeli naraz. Polega na tym, że wiedza o tym, jak Twój system ma działać, jest u Ciebie, a nie w panelu dostawcy.

• Prompty w repozytorium. Wersjonowane jak kod, z historią zmian i opisem, po co dana instrukcja jest w prompcie.
• Zestaw testów odpowiedzi. Prawdziwe przypadki z Twojej firmy, od kilkudziesięciu do kilkuset, z opisem oczekiwanego wyniku. To najcenniejszy element przy każdej zmianie modelu.
• Jedna warstwa pośrednia. Całe połączenie z modelem w jednym miejscu kodu, a nazwa modelu w konfiguracji. Zmiana modelu ma być zmianą ustawienia i testów, a nie przeszukiwaniem całego systemu.
• Walidacja odpowiedzi. System sprawdza, czy odpowiedź ma oczekiwany format, zanim użyje jej dalej, i zgłasza błąd zamiast cicho przepuszczać śmieci.
• Zapis wersji modelu. Przy każdej odpowiedzi w logach, żeby po zmianie dało się porównać zachowanie przed i po.

Jak przetestować zmianę modelu AI

Zmianę modelu testuje się jak każde wydanie systemu, tylko z większym naciskiem na porównanie. Kolejność, którą uważam za rozsądną:

1. Uruchom zestaw testów odpowiedzi na nowym modelu i porównaj wyniki ze starym, przypadek po przypadku.
2. Popraw prompty tam, gdzie wyniki się rozjechały, i powtórz testy.
3. Zmierz koszt i czas odpowiedzi na tych samych danych.
4. Puść część prawdziwego ruchu równolegle do nowego modelu bez pokazywania wyników użytkownikom i porównaj odpowiedzi.
5. Przełącz stopniowo, z możliwością szybkiego powrotu do starego modelu, dopóki jest dostępny.

Najgorszy moment na pierwszy test to tydzień przed datą wyłączenia. Dlatego testy warto zacząć, gdy tylko dostawca ogłosi wycofanie, a najlepiej mieć je gotowe, zanim to nastąpi.

Jeden dostawca czy kilku

Utrzymywanie kilku dostawców równolegle w każdej funkcji kosztuje: każdy model wymaga osobnych testów i często osobnych promptów. Dla większości firm rozsądniejszy jest układ: jeden dostawca główny i jeden przetestowany wariant zapasowy, na który da się przełączyć w razie wycofania, awarii albo zmiany cennika.

Wariantem zapasowym może być model innego dostawcy albo model uruchomiony we własnej infrastrukturze. Ten drugi ma sens zwłaszcza przy danych wrażliwych i opisałem go w tekstach o własnym modelu językowym na GPU oraz o polskich modelach w zamkniętej sieci. Trzeba tylko pamiętać, że model we własnej infrastrukturze też się starzeje, a jego aktualizacja jest już w całości po Twojej stronie.

Jak policzyć koszt zmiany

Koszt zmiany modelu to głównie praca, a nie cena tokenów. Do rachunku warto wziąć:

• przygotowanie albo uzupełnienie zestawu testów, jeśli go nie ma,
• poprawki promptów i ponowne testy,
• zmiany w integracji, jeśli nowy model ma inne API albo inny format odpowiedzi,
• przeliczenie bazy wektorów w systemach wyszukiwania i RAG,
• różnicę w kosztach działania po zmianie, w górę albo w dół.

Pierwsza zmiana jest zwykle najdroższa, bo dopiero wtedy powstają testy i warstwa pośrednia. Każda kolejna kosztuje mniej. Szerszy rachunek kosztów utrzymania AI opisałem w tekście o tym, z czego składa się koszt wdrożenia AI.

Co zapisać w umowie z wykonawcą i u dostawcy

Zmiana modelu powinna być przewidziana w umowie, zanim stanie się pilna. Lista punktów do sprawdzenia:

• prompty, zestaw testów i konfiguracja to część dostarczanego systemu, z prawami jak do reszty kodu,
• konto API jest założone na firmę, z firmowym adresem e-mail, na który przychodzą powiadomienia o wycofaniach,
• wykonawca w ramach utrzymania śledzi ogłoszenia dostawcy i w ustalonym czasie przedstawia plan przejścia,
• jasna zasada, czy migracja na nowy model mieści się w abonamencie utrzymaniowym, czy jest wyceniana osobno,
• dokumentacja: który model obsługuje którą funkcję i gdzie zmienia się to w konfiguracji.

Po stronie dostawcy sprawdź warunki dotyczące danych, regionu przetwarzania i tego, czy dane z zapytań są używane do trenowania. Przy zmianie modelu albo dostawcy te warunki mogą być inne niż przy poprzednim, a to dotyczy zasad, o których pisałem we wpisie o danych firmowych w narzędziach AI.

Zmiana modelu AI nie musi być kryzysem, jeśli system jest na nią przygotowany. Zacznij od prostego spisu: gdzie w firmie używacie modeli przez API, jakich dokładnie, kto jest właścicielem konta i na jaki adres przychodzą powiadomienia. Taki spis to niewielka praca, a pokazuje, czy następne wycofanie modelu będzie dla firmy zmianą w konfiguracji, czy projektem robionym w pośpiechu.