Jak sprawdzić dane treningowe przed fine-tuningiem modelu językowego

Dlaczego sprawdzenie danych idzie przed treningiem

Żadne ustawienie treningu nie zrównoważy błędnych odpowiedzi w danych. W SFTTrainer z Hugging Face TRL funkcją straty jest entropia krzyżowa na poziomie tokenów, a dla zbiorów typu prompt-completion domyślnie liczy się ją tylko na tokenach odpowiedzi. Model jest nagradzany za odtwarzanie zapisanych odpowiedzi token po tokenie, łącznie z niedbałymi etykietami i wycofanymi zasadami.

Dokumentacja fine-tuningu OpenAI, napisana dla hostowanej platformy zamkniętej już dla nowych użytkowników, zaleca start od około 50 starannie przygotowanych przykładów i przemyślenie zadania lub promptu, jeśli nic nie zmieniają. Ta rada dotyczy też modeli z otwartymi wagami.

Porównaj zapisane odpowiedzi z oceną ekspertów

Dane historyczne wyglądają jak etykiety, ale często nimi nie są. Kategorie zgłoszeń wybiera się w pośpiechu, pola poprawia się dalej w procesie bez zapisania poprawki z powrotem, a flagi oszustw odzwierciedlają reguły, które od tamtej pory się zmieniły. Przed treningiem poproś eksperta dziedzinowego o oznaczenie losowej próbki bez wglądu w zapisaną odpowiedź i przypisz każdą rozbieżność do jednej z tych grup.

• Błędna etykieta: zapis jest po prostu niepoprawny. Popraw go albo usuń.
• Luka w wytycznych: dwóch ekspertów się nie zgadza, bo zasady nie rozstrzygają przypadku. Najpierw spisz regułę, potem oznaczaj ponownie.
• Nieaktualna odpowiedź: poprawna według starej polityki, błędna według obecnej. Odfiltruj według daty albo oznacz ponownie.
• Etykieta z perspektywy czasu: odpowiedź zależy od informacji, które pojawiły się później, na przykład od chargebacku kilka tygodni po decyzji. Wejście może zawierać tylko to, co było wiadomo w chwili decyzji.

Jeśli dwóch ekspertów zgadza się ze sobą rzadziej, niż model ma się zgadzać z nimi, najpierw popraw definicję zadania.

Porównaj przykłady z ruchem, który trafi do modelu

Poprawny zbiór wciąż może być niereprezentatywny. Porównaj dane wejściowe z produkcji z ostatniego miesiąca ze zbiorem treningowym według kategorii, języka, szablonu dokumentu, segmentu klienta i długości wejścia.

Rzadkie klasy licz osobno. Wskazówki do Hugging Face Evaluate zauważają, że przy 99 zwykłych przypadkach i jednym oszustwie model, który zawsze odpowiada, że wszystko jest w porządku, ma 99 procent trafności i nie wyłapuje niczego. Kosztowne przypadki raportuj oddzielnie.

Długość to test, o którym zespoły zapominają. W wersji TRL opisanej w dokumentacji w chwili pisania SFTTrainer przycina sekwencje dłuższe niż max_length, domyślnie 1024 tokeny, i zostawia początek. Licz tokeny tokenizerem modelu bazowego. Jeśli długie dokumenty przekraczają twój limit, podnieś go albo zmień strukturę wejścia, inaczej model uczy się na przykładach z uciętą odpowiedzią.

Zapisz, skąd pochodzi każdy przykład

Gebru i współautorzy zaproponowali, by każdy zbiór danych miał kartę opisującą cel, skład, sposób zebrania i zalecane zastosowania. Dla zbioru do fine-tuningu wystarczy jedna strona na źródło danych, jeśli zapisuje poniższe informacje.

• System źródłowy i zapytanie, którym pobrano dane, wraz z zakresem dat
• Kto wytworzył każdą etykietę: człowiek, reguła, późniejszy wynik czy inny model
• Wersja wytycznych, według których powstały etykiety
• Pola z danymi osobowymi lub poufnymi i sposób, w jaki je usunięto lub zachowano
• Podstawa, na której dane mogą posłużyć do treningu, potwierdzona przez waszych doradców ds. ochrony danych i prawników

Oznacz przykłady wygenerowane przez model lub syntetyczne, sprawdź ich próbkę równie starannie jak etykiety od ludzi i nie dopuszczaj ich do zbioru testowego, żeby móc je usunąć, gdyby później pojawił się problem.

Trzymaj przypadki testowe z dala od danych treningowych

Zbiór testowy mówi coś tylko wtedy, gdy model go nie widział. Lee i współautorzy stwierdzili, że nakładanie się danych treningowych i testowych dotyczyło ponad 4 procent przykładów walidacyjnych w badanych standardowych zbiorach. Dane biznesowe bywają gorsze: maile z szablonów, powtarzające się faktury i jedna sprawa zapisana jako kilka zgłoszeń dają mnóstwo prawie-kopii.

Deduplikuj przed podziałem, na znormalizowanym tekście lub z progiem podobieństwa, a nie tylko po dokładnych dopasowaniach. Potem ustal, na co model ma uogólniać. Jeśli będzie spotykał nowych dostawców lub szablony, odłóż całych dostawców. Jeśli będzie widział głównie przyszłe faktury od znanych dostawców, dziel według czasu, tak by okres testowy następował po treningowym. Losowy podział wierszy nie odpowiada na żadne z tych pytań.

Zamroź zbiór testowy i daj mu właściciela spoza zespołu trenującego.

Przykładowy audyt hipotetycznego zbioru faktur

Załóżmy, że zespół finansowy chce, by mały model wyciągał dwanaście pól z faktur dostawców, i ma 8000 faktur poprawionych przez księgowych. Wszystkie liczby są hipotetyczne, a progi ustala się, zanim ktokolwiek zobaczy wyniki.

1. 1

   Audyt próbki

   Ekspert ponownie oznacza 300 losowych faktur, nie widząc zapisanych wartości. Cel: 97 procent zgodności na poziomie pól. Wynik: 93 procent, bo poprawek VAT wprowadzonych w ERP nigdy nie zapisano z powrotem.

2. 2

   Popraw źródło

   Etykiety zostają odtworzone z końcowych wartości w ERP, a nowa próbka przekracza teraz próg.

3. 3

   Tabela pokrycia

   Skany faktur to 9 procent ruchu z ostatniego kwartału, ale tylko 80 z 8000 przykładów. Zespół dodaje 700 oznaczonych skanów, co daje 780 z 8700, blisko celu 9 procent.

4. 4

   Test długości

   6 procent faktur przekracza 1024 tokeny. Limit zostaje podniesiony, a faktury wielostronicowe dostają osobny wycinek testowy.

5. 5

   Deduplikacja i podział

   Po usunięciu prawie-duplikatów zostaje 7350 z 8700 rekordów, a zespół sprawdza, czy skany nadal stanowią blisko 9 procent. Co miesiąc dochodzą nowi dostawcy, więc 20 procent dostawców trafia w całości do zbioru odłożonego, a drugi zbiór testowy obejmuje ostatni miesiąc od znanych dostawców.

6. 6

   Karta danych

   Jedna strona opisuje źródła, pochodzenie etykiet, wersję wytycznych, usunięte pola osobowe i zgodę doradców.

Trening zaczyna się po kroku szóstym. Tam, gdzie wyniki nigdy nie są zapisywane albo eksperci nie zgadzają się w wielu przypadkach, najpierw zdefiniuj zadanie, a dopiero potem myśl o fine-tuningu.