Dostawca wycofał model. Co dalej z Waszym systemem

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.

Infografika

Wycofanie modelu jako zaplanowane zdarzenie

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.

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.

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 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, gdy zespół budujący odszedł, a kalendarz dostawcy dalej się przesuwa.

Nasza część

W utrzymaniu systemów AI 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 nie odsprzedaje żadnego modelu ani platformy, więc za rekomendacją, na co migrować, nie stoi żadna marża.