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.
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.
Powiązane usługi
Trenowanie własnych modeli
Mały model open-weight wytrenowany do jednego zadania i porównany z twoim obecnym modelem pod względem kosztu i dokładności.
Inżynieria i architektura AI
Asystenci, interfejsy głosowe i agenci w produktach, które sprzedajesz, razem z serwowaniem modeli i wyszukiwaniem pod spodem.
Więcej z bloga
Jakość danych do fine-tuningu
Cztery testy, które pokazują, czy twoje przykłady nadają się do fine-tuningu: błędy w etykietach, pokrycie realnego ruchu, pochodzenie danych i przecieki do zbioru testowego.
Jakość po kwantyzacji
Które testy powtórzyć, zanim skwantyzowany model zastąpi oryginał: jakość zadania, ustrukturyzowane odpowiedzi, długie wejścia, testy zachowania i wydajność serwowania, z porównaniem kosztu na GPU.
Zadania dla małych modeli
Jak znaleźć zadania o dużym wolumenie, z którymi mały model językowy poradzi sobie niezawodnie: lista kontrolna, test przed jakimkolwiek treningiem i porównanie kosztów przy twoim wolumenie.
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.
Sprawdź wersję roboczą w swoim programie pocztowym
Wyślij ją stamtąd, a inżynier odpowie ci osobiście, proponując terminy 30-minutowej rozmowy. Jeśli wersja robocza się nie otworzyła, napisz do nas na adres miki@cloudsail.com.