--- title: "Dostawca wycofał model. Co dalej z Waszym systemem" url: "https://predictes.com/pl/blog/dostawca-wycofal-model-co-dalej-z-waszym-systemem" description: "Wersja modelu zostaje wycofana z kilkumiesięcznym wyprzedzeniem. Nic się jeszcze nie zepsuło, ale prompty i progi były dostrojone do niej. Jak utrzymanie planuje wymianę." --- # Dostawca wycofał model. Co dalej z Waszym systemem 22 października 2026·4 min czytania·predictes Mail przychodzi we wtorek, od dostawcy modelu, na adres osoby, która kiedyś założyła konto. Wersja modelu zostaje wycofana. Po dacie odległej o kilka miesięcy zapytania do niej będą odrzucane. Zalecana jest nowsza wersja, a migracja opisana jako prosta. System, którego to dotyczy, działa w produkcji od ponad roku. Klasyfikuje przychodzące zgłoszenia, pisze pierwszą wersję odpowiedzi, a wszystko niepewne kieruje do człowieka. Prompty strojono przez kilka miesięcy pod nawyki tego konkretnego modelu. Próg „niepewności” ustawiono, patrząc, jak wygląda pewność tego modelu na prawdziwych sprawach. Zestaw ewaluacyjny, o ile istnieje, ostatnio uruchomiono właśnie na nim. Nic się nie zepsuło. Nic nie zepsuje się też w dniu wycofania, jeśli ktoś zmieni nazwę modelu w konfiguracji. System będzie dalej odpowiadał. Po prostu będzie odpowiadał trochę inaczej i nikt nie zdecyduje, czy ta różnica ma znaczenie. Przyczyną jest rozjazd skal czasu. Dostawca zarządza wersjami modeli według własnego kalendarza, liczonego w miesiącach. Wasz system zbudowano tak, jakby model był częścią stałą, jak silnik bazy danych. Nie jest. Jest zależnością z własnym cyklem życia, i to jedyną częścią systemu, nad którą nie macie kontroli. ## Co idzie źle, gdy wymiana jest improwizowana **Nikt nie wie, co zależy od modelu.** Klasyfikator, krok piszący odpowiedź i próg kierowania do człowieka mogą każdy wywoływać model, i niekoniecznie ten sam. Bez inwentarza komunikat o wycofaniu czyta się jako dotyczący „systemu”, a nie trzech konkretnych komponentów, i jeden z nich zostaje pominięty. **Prompty strojono pod nawyki modelu, a nie pod specyfikację.** Prompt z poleceniem „odpowiadaj zwięźle” dawał właściwą długość na starym modelu, bo tak ten model go czytał. Nowy czyta go inaczej. Prompt się nie zmienił, zachowanie tak. **Próg jest teraz zły w kierunku, którego nikt nie widzi.** Jeśli nowy model inaczej raportuje pewność, udział spraw kierowanych do człowieka się przesuwa. W górę, i Wasz zespół nagle ma więcej pracy. W dół, i więcej spraw przechodzi bez człowieka, bez żadnego alarmu, bo nic nie poszło źle w sposób, który system potrafi zauważyć. **Zestaw ewaluacyjny nigdy nie był projektowany pod wykrycie zmiany modelu.** Wiele zestawów sprawdza, czy system poprawnie odpowiada na łatwe sprawy. Wymiana modelu psuje rzeczy na brzegach: nietypowy dokument, dwuznaczne zgłoszenie, sprawa, którą kiedyś odrzucał. Jeśli tych przypadków nie ma w zestawie, wynik prawie się nie rusza, a problem jest prawdziwy. **Wymiana odbywa się raz, w produkcji, w terminie.** Bo nikt jej nie przećwiczył, zmiana jest robiona na tydzień przed datą wycofania, pod presją, bez możliwości uruchomienia obu modeli obok siebie i bez poprzedniej wersji do powrotu, bo poprzednia wersja to właśnie ta usuwana. **Koszt się przesuwa i nikt go nie pilnuje.** Nowszy model jest inaczej wyceniany, odpowiada w innym tempie i może zużywać inną liczbę tokenów na tę samą pracę. Faktura zmienia się miesiąc później, a pytanie dlaczego trafia do tego, kto akurat jest w pokoju. 1. 01InwentarzKtóre komponenty wywołują którą wersję modelu, z jakimi promptami i progami. 2. 02Zestaw ewaluacyjny, który wykrywa zmianęZ przypadkami brzegowymi i znanymi odmowami, oceniony na starym modelu jako punkt odniesienia. 3. 03Przećwiczona wymianaNowy model uruchomiony na tych samych sprawach i na żywym ruchu w cieniu, zanim cokolwiek zostanie przełączone. 4. 04Plan awaryjnyDrugi model albo węższy tryb, do którego system może zejść, jeśli wymiana zachowa się źle. 5. 05Przełączenie i obserwacjaJakość, udział kierowania do człowieka, koszt i czas odpowiedzi porównywane z punktem odniesienia przez tygodnie, nie dni. Okres wypowiedzenia to cały budżet czasu. Inwentarz i zestaw ewaluacyjny muszą istnieć, zanim zacznie biec. ## Co zamiast tego robi utrzymanie **Prowadzi inwentarz zależności.** Dla każdego utrzymywanego systemu: który komponent wywołuje którą wersję modelu, przez który prompt, z jakim progiem. Nudne w utrzymaniu i pierwsze, co się czyta, gdy przychodzi komunikat o wycofaniu. Połowa pracy przy migracji to znajomość jej zakresu. **Traktuje datę wycofania jak datę wydania.** Termin trafia do kalendarza w dniu, w którym przychodzi komunikat, a migracja jest planowana od niego wstecz, z czasem na próbę i z czasem na to, żeby wymiana raz się nie udała. Wydanie przypięte do cudzego terminu wciąż jest wydaniem, a [wydanie systemu AI to kod, prompt, model i indeks naraz](https://predictes.com/pl/blog/wydanie-systemu-ai-to-kod-prompt-model-i-indeks-naraz). **Ocenia nowy model, zanim przejmie jakikolwiek ruch.** Zestaw ewaluacyjny uruchomiony na starym modelu daje punkt odniesienia. Ten sam zestaw na nowym pokazuje, co się przesunęło: które kategorie, które przypadki brzegowe, jak zmienił się udział kierowania do człowieka. Jeśli w zestawie nie ma trudnych spraw, najpierw dodaje się je z logów produkcyjnych, bo bez nich porównanie nic nie znaczy. **Stroi na nowo, potem ocenia na nowo.** Prompty i progi są dopasowywane do nowego modelu z zestawem ewaluacyjnym jako sędzią, jedna zmiana naraz. Celem nie jest identyczne zachowanie, bo to rzadko osiągalne, tylko zachowanie, którego różnice są znane i zaakceptowane przez właściciela biznesowego. **Utrzymuje plan awaryjny, którym nie jest wycofany model.** Drugi dostawca, inna rodzina modeli albo węższy tryb, w którym system kieruje więcej spraw do ludzi. Wybrany i przetestowany przed wymianą, żeby „cofnij zmianę” znaczyło cokolwiek w dniu, w którym stara wersja już nie istnieje. **Spisuje, co się zmieniło.** Krótka notatka dla właściciela biznesowego: co nowy model robi inaczej, gdzie teraz leży próg, jakiego kosztu zadania się spodziewać. Ta sama notatka, której [SLA dla systemu AI](https://predictes.com/pl/blog/sla-dla-systemu-ai-co-da-sie-obiecac) powinno już wymagać po każdej zmianie. ## Czego nie da się obiecać Nie tego, że nowy model będzie się zachowywał tak samo. Nie będzie, a dostawca, który twierdzi inaczej, nie robił migracji. Da się obiecać, że różnice zostaną zmierzone, zanim spotkają je użytkownicy, i że ktoś po Waszej stronie je zaakceptuje. Nie tego, że każdy przypadek brzegowy zostanie wyłapany. Zestaw ewaluacyjny jest tak dobry, jak sprawy, które w nim są, a część różnic wychodzi dopiero w produkcji. Da się obiecać, że obserwacja trwa tygodnie po wymianie, a nie kończy się w jej dniu. Nie tego, że migracja jest za darmo. To praca, za każdym razem, a umowa utrzymaniowa, która jej nie wycenia, albo ją ukrywa, albo jej nie robi. I nie tego, że utrzymanie zewnętrzne jest właściwą odpowiedzią dla każdego systemu. Dla małego narzędzia wewnętrznego, z wyrozumiałym procesem i inżynierem, który je zbudował i wciąż jest w firmie, przećwiczona wymiana to jedno popołudnie i nie potrzebuje nikogo z zewnątrz. Usługa jest na miejscu tam, gdzie system dotyka klientów albo pieniędzy, gdzie zespół budujący odszedł, albo gdzie systemów jest kilka i nikt nie spisał, od których modeli zależą. ## Test do zrobienia dziś Znajdźcie nazwę modelu w konfiguracji swojego systemu. Potem zadajcie dwa pytania: kiedy dostawca planuje wycofać tę wersję i co uruchomilibyście zamiast niej, gdyby jutro została odrzucona. Jeśli obie odpowiedzi przychodzą szybko, z datą i przetestowaną alternatywą, system jest prowadzony. Jeśli pierwsza odpowiedź to przeszukiwanie strony dostawcy, a druga to zgadywanie, komunikat o wycofaniu jest już w drodze, a czas, który Wam da, pójdzie na inwentarz i zestaw ewaluacyjny, a nie na samą wymianę. To ta sama luka, która otwiera się w [drugim roku transformacji](https://predictes.com/pl/blog/drugi-rok-transformacji-ai-co-zwykle-sie-rozpada), gdy zespół budujący odszedł, a kalendarz dostawcy dalej się przesuwa. ## Nasza część W [utrzymaniu systemów AI](https://predictes.com/pl/services/ai-managed-services) cykl życia modeli jest częścią usługi, a nie incydentem: inwentarz, zestaw ewaluacyjny, przećwiczona wymiana i plan awaryjny, testowane na Waszych sprawach, zanim zmiana do Was dotrze. [predictes](https://predictes.com/pl) nie odsprzedaje żadnego modelu ani platformy, więc za rekomendacją, na co migrować, nie stoi żadna marża. - migracja modelu - wycofanie modelu - ewaluacja - utrzymanie - plan awaryjny ## Czytaj dalej - [Baza operacyjna i lakehouse: dwie pamięci systemu AI-native](https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-systemu-ai-native) - [Drugi rok transformacji AI: co zwykle się rozpada](https://predictes.com/pl/blog/drugi-rok-transformacji-ai-co-zwykle-sie-rozpada)