Ulepszenie, którego nie poprosiłeś
Aktualizacje modelu mogą cicho uszkodzić działający system AI. Oto jak złapać regresję przed zgłoszeniem jej przez klientów.
Kiedy aktualizacje niosą niespodzianki
Twoja systemowa inteligencja sztuczna działała w piątek. W poniedziałek nadal dostarcza odpowiedzi, reaguje w ułamku sekundy i przechodzi wszystkie sprawdziany na pulpicie sterowania. Jednak odpowiedzi te są subtelnie inne – dłuższe, bardziej zawiłe, sformatowane w sposób zakłócający analizę lub zaufanie do polityki, którą wcześniej akceptowała.
Nic nie zepsuło się. Twój dostawca wysyłał aktualizacje modelu.
Ten tryb awarii zaskakuje zespoły kierownicze najbardziej, ponieważ wygląda zupełnie inaczej niż awaria. Nie ma czerwonego światła. System zgłasza się jako zdrowy, podczas gdy jakość jego wyjścia przesunęła się pod Twoją kontrolą. Klienci zauważają to przed Twoim systemem monitorowania.
Dlaczego aktualizacje niszczą to, co działało?
Nowszy model jest lepszy średnio i inny w szczególe. Dostawcy optymalizują dla agregowanych benchmarków; Ty wdrażasz się przeciwko wąskiej szczelinie swojej rzeczywistości. Kiedy model się zmienia, zachowania, na które dostosowałeś swój system – frazy, w których opierał się Twój prompt, struktura JSON, którą oczekiwał Twój integracyjny interfejs, granica odmowy zatwierdzona przez Twoją zespół zgodności, długość dopasowana do Twojego interfejsu użytkownika – również się zmieniają.
Aktualizacje docierają do Ciebie trzema sposobami: dostawca wycofuje starszą wersję i migruje Cię, używasz pływającego aliasu, który cicho rozwiązuje się do najnowszej wersji, lub celowo aktualizujesz, aby zmniejszyć koszty lub opóźnienia, zakładając, że jakość tylko się poprawi. W każdym przypadku skutki są takie same: zachowanie zmieniło się, a nikt nie zmierzył tego, co się zmieniło.
Stwórz narzędzie, które Ci o tym powie
Jedynym istotnym kontrolą jest ustalenie zestawu testów z znanymi dobrymi odpowiedziami – złotego zestawu. 200 rzeczywistych przykładów z Twojego ruchu internetowego, obejmujących Twoje typowe przypadki, krawędziowe i sytuacje, w których błąd jest kosztowny. Każdy z nich zawiera odpowiedź, którą Twój biznes uważa za właściwą.
Uruchom ten zestaw przeciwko aktualnemu modelowi i zapisz wyniki. To jest Twój punkt odniesienia. Kiedy nowy model pojawi się, uruchom ten sam zestaw ponownie i porównaj. Porównanie to całe produkt: masz teraz dowody, a nie wrażenia.
Budowa tego trwa kilka dni i wymaga zaangażowania operatorów, a nie inżynierów, aby zdefiniować, co oznacza "właściwe". Większość organizacji pomija ten krok, ponieważ wydaje się dodatkowym obciążeniem przed uruchomieniem. Jest to najtańsza ubezpieczenie w całej strukturze systemu.
Kontroluj moment, w którym zmiana dotknie Cię
Przypinaj konkretne wersje modelu we wszystkich konfiguracjach produkcyjnych. Przypięta wersja zamienia zasadniczą zmianę w podjętą decyzję, którą możesz zaplanować. Następnie traktuj każdą aktualizację jak mały projekt:
- Uruchom złoty zestaw przeciwko nowej wersji i porównaj go z bazowym przypadkiem po przypadku
- Poproś właściciela biznesu o przeglądanie każdego przypadku, w którym odpowiedź zmieniła się, nie tylko w tych, które się pogorszyły – ulepszenia mogą również zakłócać systemy nadrzędne
- Wyślij niewielki odsetek ruchu na nową wersję i obserwuj sygnały operacyjne: tempo eskalacji, średni czas obsługi, ilość edycji wprowadzanych przez personel przed wysłaniem systemu, liczba kliknięć "nie" w ciągu tygodnia.
- Zachowaj starszą wersję dostępną w oknie cofania się i poznaj osobę upoważnioną do przełączenia
- Zapisz decyzję, datę i dowody, aby następna aktualizacja mogła rozpocząć się od znanego stanu.
Na tej liście nie ma demonstracji. Obserwowanie nowego modelu odpowiadającego na pięć pytań imponująco nie mówi nic o 20. procentylu Twojego ruchu, z którego pochodzą Twoje skargi.
Obserwuj sygnały, które Twój biznes już generuje
W okresach między aktualizacjami jakość spadku pokazuje się w liczbach, które prawdopodobnie już zbierasz. Eskalacje do człowieka. Średni czas obsługi. Jak często personel musi poprawiać wstępny projekt systemu przed wysłaniem. Powtarzające się kontakty w tej samej sprawie w ciągu tygodnia. Każda zmiana o 3-4 punkty w dwutygodniowym okresie jest warte spojrzenia na to, co zmieniło się w warstwie modelu.
Przydziel jednej osobie stałą pracę polegającą na cotygodniowej przeglądaniu tych liczb w porównaniu z wersją modelu w produkcji. Nie komitet, nie kwartalny przegląd. Jednoosobowe posiadanie i 15-minutowa kontrola.
Umieść to w umowie
Poproś swojego dostawcę o pisemne powiadomienie przed wycofaniem wersji, udokumentowane minimalne okno wsparcia dla przypiętych wersji oraz dostęp do poprzedniej wersji podczas migracji. Dostawcy obsługujący sektory regulowane zazwyczaj oferują takie gwarancje. Ci, którzy tego nie robią, poinformują Cię o tym, a ta odpowiedź jest użyteczna przed rozpoczęciem pracy z nimi, a nie po.
Prawdziwa pozycja
Nie możesz powstrzymać dostawcy od ulepszania swoich modeli i nie chcesz tego robić. To, co możesz zrobić, to upewnić się, że ulepszenie następuje zgodnie z Twoimi warunkami: zmierzone, etapowe, odwracalne i prowadzone przez kogoś.
To jest niezauważalny ciężar prowadzenia AI w produkcji, a nie tylko testowania go – i jest to część naszej pracy dla klientów, którzy wolą poświęcić swoją uwagę na prowadzenie biznesu. W każdym razie, zbuduj złoty zestaw. Wszystko inne zależy od niego.