BlogModele

Jak przetestować dostrojony model na tle modelu, który ma zastąpić

Dostrojony model warto wdrożyć, gdy pokonuje model, który ma zastąpić, na przypadkach, których żaden z nich nie widział w treningu, według kryteriów spisanych przed porównaniem: jakość ogółem i na najważniejszych przypadkach, format odpowiedzi, opóźnienie i pełny koszt zapytania. Niższa strata treningowa czy lepszy wynik w publicznym benchmarku mówi, że trening się wykonał. Nie mówi, że zmiana się opłaci.

Zaktualizowano

Spisz kryteria akceptacji przed pierwszym wynikiem

Gdy wynik już leży na stole, kusi, by uznać, że spadek o dwa punkty w jednej kategorii nie ma znaczenia. Ustal poprzeczkę z góry z product ownerem i ekspertem dziedzinowym, który będzie pracował z modelem. Dla hipotetycznego routera zgłoszeń, który ma zastąpić hostowany model frontierowy, kryteria mogłyby wyglądać tak.

  • Ogółem: macro F1 na zbiorze odłożonym nie gorsze niż w obecnym modelu
  • Krytyczny wycinek: recall dla skarg prawnych co najmniej taki jak w obecnym modelu, bo każda przeoczona jest kosztowna
  • Format: każda odpowiedź parsuje się zgodnie ze schematem routingu
  • Opóźnienie: p95 poniżej 800 milisekund w produkcyjnej konfiguracji serwowania
  • Koszt: niższy łączny koszt 1000 zapytań, z serwowaniem i utrzymaniem

Każda linia wskazuje metrykę, punkt odniesienia i próg. Jeśli linii nie da się zapisać tak precyzyjnie, zespół nie uzgodnił jeszcze, co znaczy lepiej.

Porównuj z konfiguracją, którą naprawdę zastępujesz

Dokumentacja fine-tuningu OpenAI, napisana dla hostowanej platformy zamkniętej już dla nowych użytkowników, zaleca wydzielenie danych holdout przed treningiem i użycie ich jako grupy kontrolnej. Ta zasada dotyczy każdego modelu. Dla biznesu liczy się jednak nie niedostrojony model bazowy, lecz obecna konfiguracja produkcyjna: ten sam hostowany model, prompt, przykłady i przetwarzanie końcowe co dziś. Pokonanie słabego punktu odniesienia niewiele dowodzi.

Daj obecnemu modelowi uczciwą szansę. Jeśli jego prompt nie był ruszany od roku, popraw go przed porównaniem. Przepuść oba modele przez tę samą uprząż testową, z tym samym parsowaniem i kodem oceniającym, żeby różnice wynikały z modeli, a nie z otoczki.

Jakie muszą być odłożone przypadki

Zbiór porównawczy nie może zawierać przypadków treningowych ani ich prawie-kopii, a jego podział musi odpowiadać temu, z czym model się zmierzy: późniejszy okres dla powtarzalnej pracy, niewidziani klienci lub szablony, jeśli takie będą się pojawiać. Jeśli nadreprezentujesz rzadkie przypadki, by zmierzyć krytyczny wycinek, raportuj go osobno albo przeważ wynik ogólny do proporcji z produkcji. Wskazówki do Hugging Face Evaluate zalecają odłożenie od 10 do 30 procent zbioru na ewaluację, z danymi testowymi możliwie bliskimi produkcyjnym.

Małe różnice wymagają ostrożności, więc porównuj modele przypadek po przypadku. Załóżmy, że w hipotetycznym zbiorze 600 zgłoszeń kandydat ma rację w 31 przypadkach, w których obecny model się myli, a myli się w 19, w których obecny ma rację. Zysk netto to 12 przypadków, czyli 2 procent, a test dla par, na przykład test McNemara, pokaże, czy to więcej niż szum. Przeczytaj te 19 pogorszeń jedno po drugim, bo jeden poważny błąd może przeważyć zysk netto.

Oceniaj tak, jak zapada decyzja

Trafność ukrywa błędy na rzadkich klasach, więc przy niezrównoważonych klasach używaj precision i recall dla każdej klasy albo F1, a ekstrakcję oceniaj pole po polu. Dla swobodnego tekstu przewodnik OpenAI po ewaluacji zaleca łączenie metryk z oceną ludzi i ufanie modelowi w roli sędziego dopiero wtedy, gdy jego oceny zgadzają się z etykietami twoich ekspertów.

Dla odpowiedzi, których nie da się łatwo ocenić automatycznie, użyj ślepego porównania parami: ekspert widzi dwie odpowiedzi na ten sam przypadek, nie wiedząc, który model napisał którą, i wybiera lepszą albo zaznacza remis.

Koszt i opóźnienie w tej samej tabeli co jakość

Wskazówki Hugging Face nazywają ten kompromis wprost: nieco mniej dokładny model może być lepszym wyborem, jeśli jest szybszy i potrzebuje mniej sprzętu. Mierz opóźnienie w konfiguracji serwowania, której naprawdę użyjesz, pod realistycznym obciążeniem, a koszt zapytania licz z pełnego rachunku, z bezczynnymi godzinami GPU, hostowanym modelem zapasowym i ponownym trenowaniem. Poniższe zestawienie jest hipotetyczne i zakłada 1,5 miliona zapytań miesięcznie, jedno dedykowane GPU pracujące całą dobę dla dostrojonego modelu oraz obecną cenę za token modelu hostowanego.

  • Obecny model hostowany: macro F1 0,86, recall dla skarg prawnych 0,91, p95 1,6 s, 4,10 € za 1000 zapytań
  • Dostrojony model 8B: macro F1 0,88, recall dla skarg prawnych 0,89, p95 0,5 s, 1,30 € za 1000 zapytań

Według powyższych kryteriów ten kandydat odpada. Jest tańszy i szybszy, ale recall dla skarg prawnych spadł, a ta linia była uzgodniona jako twardy wymóg. Następny krok to więcej oznaczonych skarg prawnych i kolejny trening, a nie dyskusja, czy dwa punkty mają znaczenie.

Od zaliczonego testu do produkcji

Zaliczony test na danych odłożonych to wynik offline. Przed zmianą uruchom kandydata w trybie cienia na ruchu produkcyjnym, gdy obecny model nadal odpowiada, i porównaj ich decyzje. Wskazówki Hugging Face odróżniają ewaluację offline przed wdrożeniem od ewaluacji online na danych produkcyjnych, a zmiana modelu wymaga obu.

Metoda słabnie tam, gdzie prawdziwe wyniki przychodzą po miesiącach albo wcale, oraz w zadaniach otwartych bez jednej poprawnej odpowiedzi. Wtedy większą wagę ma ślepa ocena ekspertów, a próbka musi być większa. Trzymaj model hostowany jako zapasowy, dopóki liczby online nie zgodzą się z offline.

Pytania

Czy wynik z publicznego benchmarku może zastąpić nasze własne porównanie?

Nie. Rankingi i karty modeli opisują ogólne możliwości, a Hugging Face zaznacza, że wyniki w kartach modeli często podaje sam autor modelu. Pomagają zawęzić listę modeli bazowych. Czy model jest wystarczająco dobry do twojego zadania, pokażą dopiero twoje własne odłożone przypadki.

Jak duży powinien być zbiór odłożony?

Na tyle duży, by każdy krytyczny wycinek zawierał sensowną liczbę przypadków, co często oznacza kilkaset przypadków łącznie, z celowo nadreprezentowanymi rzadkimi klasami raportowanymi osobno. Jeśli wycinek ma 15 przypadków, jeden błąd przesuwa wynik o prawie 7 punktów procentowych, więc dołóż przypadków, zanim mu zaufasz.

Kto zatrzymuje zbiór ewaluacyjny po zakończeniu projektu?

Ty. W projektach Cloudsail zbiór odłożony, kod oceniający i wyniki zostają u twojego zespołu, żeby to samo porównanie mogło ocenić kolejny model, ponowny trening albo zmianę dostawcy.

Porozmawiaj z inżynierem

Przyjdź z jednym zadaniem, które chcesz usprawnić. Rozmowa trwa 30 minut i nie wymaga dostępu do twoich systemów ani danych.

Rezerwacja odbywa się w Kalendarzu Google.

Wolisz najpierw napisać? Zostaw adres e-mail i kilka zdań, a odpowiemy, proponując terminy.

Przycisk przygotowuje e-mail w twoim własnym programie pocztowym, a wysyłasz go samodzielnie. Polityka prywatności (wersja robocza)