1. Zapisz pytanie, zanim przygotujesz warianty
Przydatne porównanie odpowiada na konkretną decyzję: czy zwiększenie maksymalnej długości zapobiega uciętym odpowiedziom? Czy poziom szczegółowości zachowuje potrzebne kontury? Czy większa grupa kończy pracę bez błędów? Wybierz jedno pytanie i jeden parametr. „Znalezienie najlepszych ustawień” jest zbyt szerokie na pierwsze podejście.
Nazwij A punktem odniesienia, a B wariantem. Zapisz dokładnie zmienioną wartość. Zmiana jednocześnie modelu, wymiarów i liczby przejść może dać inny wynik, nie ujawniając, która modyfikacja go wyjaśnia. Zachowaj takie próby na osobne porównania.
2. Ustal mały zbiór i zasady oceny
Zbierz te same wejścia dla A i B. Kilkanaście przypadków może wystarczyć na pierwszą, ograniczoną decyzję, jeśli obejmują trudności projektu: drobny tekst na obrazie, długi dokument, brakujące dane lub nietypowy format. Ta liczba to praktyczny wybór, nie statystyczna gwarancja. Unikaj uwzględniania wyłącznie przykładów, które już się udawały.
Dla każdego wejścia zapisz warunki sukcesu jeszcze przed testem. Odróżnij preferencję prezentacji od wady blokującej. W asystencie dokumentowym przyjemniejsza odpowiedź może zostać odrzucona, jeśli wymyśla regułę. W przypadku wizualizacji produktu atrakcyjny kolor nie zrekompensuje zniknięcia ważnego elementu.
Ustal także minimalną liczbę zaakceptowanych przypadków, zabronione wady i maksymalny czas kontroli. Te progi właściwe dla projektu muszą pozostać identyczne, gdy analizujesz wyniki.
| Co ustalić | Przykład notatki | Dlaczego to ważne |
|---|---|---|
| Wejścia | przypadek-01 do przypadek-12, te same pliki i te same sformułowania | Porównanie tych samych trudności |
| Kryterium jakości | Odpowiedź weryfikowalna w dokumencie i bez wymyślania | Uniknięcie sytuacji, w której płynny wynik maskuje błąd |
| Błąd krytyczny | Nieobecna reguła przedstawiona jako pewna | Odrzucenie wady, nawet jeśli suma wypada lepiej |
| Zmienna | A: 128; B: maksymalnie 256 nowych tokenów | Przypisanie różnicy do zidentyfikowanej zmiany |
3. Zachowaj tę samą sesję i te same zależności
Zachowaj model, jego wersję, rozszerzenia, silnik obliczeniowy i pozostałe parametry. Użyj tego samego środowiska i tego samego GPU, nie uruchamiając innego przetwarzania między obiema wariantami. Zanotuj to, czego nie możesz kontrolować: widoczną konkurencyjną aktywność, wymuszoną zmianę wersji lub inne wczytywanie. Porównanie zakłócone przez takie zmiany wymaga większej ostrożności.
Jeśli narzędzie używa losowego ziarna i pozwala je ustalić, zachowaj tę wartość dla każdej pary przebiegów. Ułatwia to porównanie, ale nie gwarantuje identycznego wyniku wszędzie. PyTorch wskazuje, że pełna powtarzalność nie jest gwarantowana między wersjami ani platformami, nawet przy identycznym ziarnie.
Utwórz dwa foldery, A i B, z tą samą listą identyfikatorów. Zachowaj surowe wyniki przed jakąkolwiek ręczną korektą. Późniejsza poprawka musi być widoczna jako dodatkowa operacja, wraz z jej czasem pracy, a nie przypisana do ustawienia, które wytworzyło pierwotny plik.
4. Wykonaj przebieg kontrolny, a następnie porównaj pary
Najpierw sprawdź, czy proste wejście dociera aż do pobranego pliku lub odpowiedzi. Ten przebieg kontroluje metodę. Osobno odnotuj pierwsze wczytanie lub szczególne przygotowanie: nie porównuj pełnego startu A z przebiegiem B, w którym wszystkie elementy są już wczytane.
Wykonaj te same przypadki dla A i B. Zmień kolejność, jeśli narzędzie na to pozwala, a następnie powtórz kilka rozstrzygających par w odwrotnej kolejności. Sprawdź, czy pojedynczy wynik lub przewaga kolejności nie przesądza o całym wniosku.
Odnotuj także błędy i odrzucone wyniki. Jeśli B zawodzi na dużym wejściu, nie usuwaj go z tabeli, aby poprawić jego średnią. Ewentualnie usuń przyczynę w osobnym przebiegu B2. Zachowasz w ten sposób czytelne porównanie zamiast folderu, w którym wariant zmienia się wraz z pojawiającymi się trudnościami.
5. Oddziel zaakceptowany wynik od zaobserwowanego czasu
Najpierw oceń jakość w docelowym rozmiarze lub w narzędziu użytkowym. Jeśli to możliwe, tymczasowo ukryj nazwy A i B w momencie oceny. Jedna osoba może po prostu przejrzeć wyniki w pomieszanej kolejności, a następnie przywrócić ich przyporządkowanie. Zachowaj ogłoszone kryteria i krótkie uzasadnienie każdego odrzucenia.
W przypadku czasu wybierz jedną definicję: na przykład od uruchomienia do zapisania pełnego wyniku. Następnie oddziel kontrolę człowieka i korekty. Stoper wokół wywołania GPU nie zawsze mierzy zakończone obliczenie: w PyTorch/CUDA operacje mogą być asynchroniczne. Aby wyizolować obliczenie, użyj metody pomiaru udokumentowanej przez narzędzie.
Jeśli powtórzenia się nakładają lub pomiar czasu pozostaje przybliżony, zapisz „różnica czasu nierozstrzygająca”. Niewielka różnica w pojedynczym uruchomieniu nie uzasadnia procentowego zysku przedstawianego jako pewny.
Przykład: 128 lub 256 nowych tokenów dla asystenta dokumentowego
Mały zespół chce pełnych odpowiedzi na dwanaście stałych pytań. Zachowuje ten sam model, te same dokumenty, tę samą instrukcję i to samo GPU. Zmienia się tylko limit odpowiedzi: A pozwala na 128 nowych tokenów, B na 256. W Transformers max_new_tokens ogranicza generowanie, nie licząc tokenów tekstu wejściowego. Token to nie słowo: limit nie określa dokładnej liczby zdań.
Przed próbą zespół ustala przykładową regułę: co najmniej dziesięć zaakceptowanych odpowiedzi na dwanaście i żadnej wymyślonej reguły. Poniższa tabela to fikcyjny scenariusz czytania wyników. Nie opisuje zmierzonego asystenta i nie przewiduje wpływu tych wartości na Twój model.
A osiąga minimum, B uzyskuje więcej zaakceptowanych odpowiedzi, ale zachowuje krytyczną wadę. Decyzja polega na zachowaniu A dla tego zakresu, z ponownym przeglądem odpowiedzi, oraz na zbadaniu przyczyny wady B przed kolejnym porównaniem. Większa długość nie jest ani dowodem jakości, ani pewną przyczyną wymyślania.
Zespół powtarza pytania, które różnicują A i B, oraz dwa pytania już udane. Jeśli wada pojawia się także z A, zawiesza werdykt: początkowy korpus nie wystarczył do ustalenia stabilności. Zachowuje ślad obu przebiegów, zamiast zachować tylko ten korzystniejszy.
| Kryterium scenariusza | A: maksymalnie 128 tokenów | B: maksymalnie 256 tokenów |
|---|---|---|
| Zaakceptowane odpowiedzi | 10 z 12 | 11 z 12 |
| Krytyczne wady | 0 | 1 wymyślona reguła |
| Czas trwania | Do odnotowania w rzeczywistej sesji | Do odnotowania tą samą metodą |
| Zgodność z ogłoszoną regułą | Tak, w tym ograniczonym scenariuszu | Nie, mimo najlepszego wyniku łącznego |
Unikaj wniosków, na które twój test nie pozwala
Nie wybieraj B tylko dlatego, że jedno z jego wyjść jest spektakularne, podczas gdy pozostałe się pogarszają. Nie zmieniaj korpusu w trakcie, nie licz dwóch powtórzeń jako dwóch różnych pozycji i nie usuwaj porażki z mianownika. Dwanaście przedstawionych pozycji to wciąż dwanaście przypadków do wyjaśnienia, nawet jeśli niektóre nie wygenerowały żadnego pliku.
Wybrane ustawienie obowiązuje dla zbadanych pozycji, wersji i kryteriów. Może już nie pasować do dziesięć razy dłuższego dokumentu lub innych obrazów. Stopniowo dodawaj reprezentatywne przypadki. Ten postęp rozszerza kontrolę; nie zamienia małego testu w certyfikację systemu.
Zachowaj krótką decyzję i następne sprawdzenie
Twoja końcowa dokumentacja zawiera korpus, dwie konfiguracje, wyjścia, werdykty według identyfikatora i kilka linijek wniosku. Wskaż wybrane ustawienie, powód i ograniczenie: „A zachowane na tych dwunastu pytaniach; dwie odpowiedzi pozostają do ponownego sprawdzenia; dodatkowe długie dokumenty nie są objęte”. Inna osoba musi móc zrozumieć ten wybór bez udziału w sesji.
Zachowaj A jako punkt odniesienia do następnej diagnozy. Jeśli żaden wariant nie spełnia kryteriów, nie wybieraj żadnego do dostawy; sformułuj nową hipotezę. Zarezerwuj czas na kopiowanie i kontrolę przed uruchomieniem tego ciągu dalszego. Zakończony test z jasno określonym ograniczeniem daje już decyzję; nie wymaga kontynuowania aż do znalezienia zwycięzcy.