Funkcja AI, której nikt nie odważy się zmienić

W większości organizacji, które wcześnie sięgnęły po AI, jest gdzieś taka funkcja. Uruchomiona mniej więcej rok temu, ludzie z niej korzystają, w większości działa. Osoba, która ją zbudowała, przeszła do innego projektu. Prompt urósł o zdanie po każdej skardze. Nikt nie wie, jak dobra jest ta funkcja, więc nikt nie chce jej zmieniać, więc się nie zmienia.

Nie przeszkadza to, dopóki coś nie wymusi zmiany. Wtedy okazuje się, że to najdroższy rodzaj systemu, jaki można mieć: taki, od którego zależycie i którego nie możecie bezpiecznie dotknąć.

Co wymusza zmianę

Model zostaje wycofany. Dostawcy wycofują modele według własnego harmonogramu. Funkcja zbudowana pod jeden konkretny model będzie musiała się przenieść, czy ktoś jest gotowy, czy nie — a bez sposobu na zmierzenie jakości przenosiny są zgadywaniem pod presją terminu.

Rachunek rośnie. Użycie rośnie, koszt razem z nim, a oczywiste dźwignie — mniejszy model, krótsze prompty, cache — niosą to samo pytanie: co to zrobi z jakością? Bez odpowiedzi nikt po nie nie sięga.

Zmienia się proces. Nowa linia produktów, nowa regulacja, nowy wzór dokumentu. Funkcja musi nauczyć się czegoś nowego, a każda edycja grozi zepsuciem czegoś, co już robiła.

Incydent. Błędna odpowiedź trafia do klienta. Ktoś pyta, jak często to się zdarza. Nikt nie umie odpowiedzieć.

Żadna z tych sytuacji nie jest wyjątkowa. Każda działająca funkcja AI prędzej czy później trafi na którąś z nich, a pytanie brzmi tylko, czy da się wtedy zmierzyć skutki zmiany.

Dlaczego łatanie nie wyprowadza z tej sytuacji

Naturalną reakcją na każdą z tych rzeczy jest łatka: zdanie dopisane do promptu, szczególny przypadek w kodzie. Każda łatka jest rozsądna i każda utrudnia rozumienie systemu, bo nikt już nie widzi, przed czym chroniły poprzednie.

Funkcja w takim stanie nie potrzebuje kolejnych łatek. Potrzebuje sposobu, żeby stwierdzić, czy zmiana ją poprawiła, czy pogorszyła. Dopóki go nie ma, każda zmiana — łącznie z tą wymuszoną — jest hazardem.

Jak wygląda przejęcie

Infografika

Przejęcie działającej funkcji AI

1. 01Czytać, zanim się dotknieLogi, historia promptu, skargi i przypadki, które ludzie pamiętają.
2. 02Zbudować zestaw ewaluacyjnyPrawdziwe wejścia z produkcji, dobre odpowiedzi uzgodnione z ekspertami.
3. 03Ocenić stan obecnyPunkt odniesienia i często pierwsza uczciwa miara jakości.
4. 04Wykonać wymuszoną zmianęModel, koszt albo wymaganie, ze zmierzonym wpływem na jakość.
5. 05Oddać systemEwaluacja przy każdej zmianie, powody spisane, Wasz zespół u steru.

Najpierw czytanie. Logi, historia promptu, skargi, przypadki, które ludzie pamiętają. Pierwsze dni to głównie słuchanie.

Zestaw ewaluacyjny z tego, co funkcja naprawdę widzi. Prawdziwe wejścia z produkcji, łącznie z niewygodnymi, ze znanymi dobrymi odpowiedziami uzgodnionymi z kimś, kto wykonuje tę pracę. To zwykle mniej więcej pierwszy tydzień i zwykle ujawnia właściwy problem — często nie ten, z powodu którego ktoś zadzwonił.

Ocena systemu w obecnym stanie. Zanim cokolwiek się zmieni. Ta liczba jest punktem odniesienia dla każdej późniejszej decyzji i często pierwszym momentem, w którym ktokolwiek wie, jak dobra jest funkcja.

Jedna zmiana naraz. Najpierw ta wymuszona — migracja modelu, obniżka kosztu — z wpływem na jakość zmierzonym, a nie zakładanym.

System, który da się zmieniać. Z zestawem ewaluacyjnym uruchamianym przy każdej zmianie, spisanymi powodami każdej łatki i Waszym zespołem zdolnym zrobić następną zmianę samodzielnie.

Ile to kosztuje Was w czasie i uwadze

Dostęp do logów produkcyjnych i do ludzi, którzy na funkcję narzekają. Kilka godzin eksperta dziedzinowego na uzgodnienie, jak wyglądają dobre odpowiedzi w przypadkach ewaluacyjnych — bez tego praca staje. I osoba decyzyjna gotowa usłyszeć, że funkcja jest gorsza, niż zakładano, albo lepsza, albo dobra w połowie swojej pracy i słaba w drugiej.

Jak wygląda dobry wynik

Migracja modelu, obniżka kosztu albo nowe wymaganie są wdrożone, a na dowód jest wynik jakości sprzed zmiany i po niej. Funkcja ma zmierzoną jakość, którą ktoś regularnie przegląda. A następna wymuszona zmiana jest rutynową pracą, a nie kryzysem.

Kiedy wezwać pomoc

Najlepiej przed terminem. Zapowiedź wycofania modelu z kilkumiesięcznym wyprzedzeniem to dość czasu, żeby zbudować zestaw ewaluacyjny, ocenić obecny system i spokojnie przeprowadzić migrację. Ta sama zapowiedź, gdy zostało kilka tygodni, zamienia to wszystko w hazard opisany wyżej.

Przy inżynierii aplikacji AI-native przejęcie istniejącego kodu zaczynamy od zestawu ewaluacyjnego, bo bez niego każda zmiana w odziedziczonym systemie AI jest hazardem. To zwykle pierwszy tydzień i zwykle pokazuje, jaki jest prawdziwy problem.