Rozróżnij kampanię, konfigurację i uruchomienie
Kampania niesie ze sobą pytanie, na przykład porównanie baseline'u z adaptacją. Konfiguracja opisuje wybory techniczne. Run to próba uruchomienia tej konfiguracji, z ziarnem losowości, początkiem, końcem i statusem. Dwie identyczne próby zachowują więc dwa identyfikatory, nawet jeśli druga zastępuje przerwany test.
Dodaj identyfikator oceny, gdy ten sam artefakt jest oceniany na kilku zbiorach lub z nową metryką. Pozwala to uniknąć pomylenia nowego modelu z nowym odczytem istniejącego modelu. Powiąż próbę wznowienia z poprzedzającą ją próbą oraz z załadowanym checkpointem.
MLflow również organizuje śledzenie wokół runów, parametrów, metryk i artefaktów. To rozróżnienie jest przydatne nawet w prostym katalogu plików. Możesz je zastosować w swoim zwykłym narzędziu; żadna konkretna platforma śledzenia nie jest potrzebna, aby zacząć.
Źródła techniczne: MLflow — runy, parametry, metryki i artefakty
Zapisz manifest faktycznie wykonany
Zachowaj parametry rozwiązane po zastosowaniu wartości domyślnych i argumentów uruchomienia. Oryginalny plik konfiguracyjny może pomijać domyślny batch lub opcję zmienioną w trakcie uruchomienia. Zapisz to, co zostało rzeczywiście użyte, wraz z kopią kodu lub niezmienną rewizją oraz stanem niezapisanych zmian.
Manifest łączy także wersje modelu i tokenizera, środowisko programowe, faktycznie użyty GPU, precyzję, dane, seedy i definicję metryk. Opisuje próbę, nie stając się poradnikiem instalacji. Zapisuj jednostki: sekundy, bajty, tokeny, punkty lub proporcję od 0 do 1 w zależności od miary.
Na starcie status jest w toku; na końcu staje się zakończony, nieudany lub przerwany, zależnie od tego, co zaobserwowano. Nie uzupełniaj po fakcie zapomnianej wersji tą obecnie zainstalowaną. Oznacz nieznaną informację i ogranicz wniosek, który od niej zależy.
| Blok | Elementy do zachowania | Rozwiązane pytanie |
|---|---|---|
| Tożsamość | campaign_id, config_id, run_id, ewentualny parent_run_id | Która próba daje ten wynik? |
| Kod i model | Dokładne rewizje, zmiany lokalne, model bazowy i tokenizer | Jakie obliczenie zostało faktycznie uruchomione? |
| Dane | Wersja, split, przetwarzanie wstępne, identyfikatory i istotna kolejność | Na jakich danych wejściowych? |
| Parametry | Wartości efektywne, ziarna i jednostki | Z jakimi ustawieniami? |
| Ocena | Oceniany artefakt, metryka/wersja, próg i populacja | Co oznacza wynik? |
| Zamknięcie | Status, błąd, wygenerowane pliki i decyzja | Czy próba jest użyteczna? |
Zidentyfikuj dane poza nazwą katalogu
Ścieżka taka jak dane/final nie oznacza stabilnej wersji. Zachowaj inwentarz plików lub przykładów, splity i procedurę transformacji. Jeśli poprawiasz etykiety lub filtrujesz wiersze, utwórz nową wersję i zachowaj relację z poprzednią. Stary wynik powinien nadal wskazywać na swoje stare dane.
Hugging Face Datasets przypisuje fingerprinty do stanu zbioru danych i jego transformacji, aby zarządzać pamięcią podręczną. Ten mechanizm jest przydatny, ale trzeba też zachować pochodzenie danych i przetwarzanie wstępne. Transformacja, której nie da się zahashować, może na przykład prowadzić do losowego fingerprintu: identyfikator pamięci podręcznej sam w sobie nie zastępuje Twojej dokumentacji pochodzenia.
Dla zamrożonych artefaktów dodaj rozmiar i sumę kontrolną pliku. Digest SHA-256 obliczony przed i po kopiowaniu pozwala zweryfikować, że bajty odpowiadają zachowanej referencji. Nie dowodzi ani jakości etykiet, ani praw do użycia, ani braku wycieku między splitami.
Źródła techniczne: Hugging Face Datasets — fingerprinty i transformacje · Python 3.14 — sumy kontrolne plików z hashlib
Powiąż metryki, predykcje i artefakty
Wiersz metryki powinien identyfikować run, oceniany artefakt, zbiór ewaluacyjny, wersję metryki i jej zakres. Określ, czy wartość dotyczy checkpointu pośredniego, modelu końcowego czy podgrupy. Sama krzywa nie wystarczy, jeśli nie wiadomo już, który plik odpowiada wybranemu punktowi.
Zachowaj predykcje wraz z ich identyfikatorem wejściowym, statusem i informacjami niezbędnymi do ewaluacji. Oczekiwane referencje mogą pozostać w osobnym, wersjonowanym pliku. W przypadku ustrukturyzowanego wyniku rozróżnij wynik surowy, wynik sparsowany i werdykt: poprawianie parsowania nie może nadpisać początkowego wyniku.
MLflow pozwala powiązać metryki z modelami i danymi. W przypadku plików zastosuj tę samą zasadę przez jawne identyfikatory. Prowadź czytelny inwentarz artefaktów: wagi lub adapter, parametry generowania, wyniki, raport z ewaluacji i notatkę decyzyjną. Nie zakładaj, że zrzut ekranu zastąpi te pliki.
Źródła techniczne: MLflow — łączenie metryk, modeli i zbiorów danych
Przykład: sześć runów i duplikat, który ukrywa brak
Rozważmy przykład klasyfikacji z dwiema konfiguracjami i trzema ziarnami. Daje to sześć zaplanowanych runów. Każdy powinien przewidzieć te same 300 identyfikatorów ewaluacyjnych: kompletny katalog oczekuje zatem 6 × 300 = 1800 unikalnych par (run_id, input_id). To obliczenie opisuje oczekiwany inwentarz, a nie faktycznie przeprowadzony eksperyment.
Załóżmy, że plik zawiera 300 wierszy, ale identyfikator doc-042 występuje dwa razy, a doc-117 brakuje. Łączna liczba wierszy wydaje się poprawna; jest jednak tylko 299 unikalnych identyfikatorów. Ten run nie przechodzi kontroli pokrycia, dopóki anomalia nie zostanie wyjaśniona i poprawiona.
Jeśli każdy run jest następnie oceniany na pełnym korpusie i na swojej podgrupie długich tekstów, otrzymujesz dwanaście wierszy metryki dla danej metryki. To wciąż sześć runów, a nie dwanaście niezależnych treningów. Klucz ewaluacji musi obejmować zakres, aby zachować to rozróżnienie.
| Kontrola | Oczekiwane | Anomalia ilustracyjna |
|---|---|---|
| Runy | 2 konfiguracje × 3 ziarna = 6 | Ponowne uruchomienie otrzymuje nowy identyfikator |
| Predykcje na run | Oczekiwane 300 unikalnych ID | 300 wierszy, ale tylko 299 unikalnych ID |
| Pary run/wejście | 6 × 300 = 1 800 | Sam globalny licznik nie wykrywa wszystkich duplikatów |
| Ewaluacje | 6 runów × 2 zakresy = 12 | Dwanaście wyników nie tworzy dwunastu runów |
Zamknij katalog czytelną decyzją
Zanim uznasz run za zakończony, sprawdź obecność i otwieralność plików, zgodność identyfikatorów, przeliczalność metryk oraz status każdego błędu. Technicznie zakończona próba może pozostać odrzucona z powodu niewystarczającej jakości. Trzymaj te dwa stany rozdzielone.
Notatka decyzyjna zbiera pytanie, porównywane warianty, ogłoszone kryterium, wybrane wyniki i powody wykluczenia. Podawaj run_id i ścieżki artefaktów zamiast „ostatniego modelu”. Dodaj ograniczenia: mało powtórzeń, niewystarczająca podgrupa, nieodnaleziona wersja lub porównanie, które stało się niemożliwe.
Późniejsza poprawka musi pozostawić ślad: nową ewaluację, nowy raport i powód zmiany. Zachowaj poprzedni wniosek jako oznaczoną wersję historyczną, nie pozwalając, by pojawiał się jako bieżąca decyzja. Na koniec sprawdź, czy wyeksportowana kopia otwiera się ze swojego katalogu docelowego.
Unikaj zbędnego zbierania danych i obietnic reprodukcji
Zbieraj pola niezbędne do dowodu, a nie wszystkie zmienne środowiskowe czy historię terminala. Konfiguracja lub URL może zawierać token; przygotuj wersję do udostępnienia bez sekretów, a dane, które muszą pozostać prywatne, trzymaj w ich dozwolonym miejscu. Techniczne identyfikatory próby nie muszą zawierać imienia i nazwiska.
Kompletny katalog zwiększa możliwość powtórzenia i zrozumienia eksperymentu. Nie gwarantuje jednak numerycznej równości między platformami czy wersjami: PyTorch dokumentuje te ograniczenia powtarzalności. Rozróżnij odtworzenie protokołu, ponowne wczytanie artefaktu i dokładne odtworzenie liczb.
Carnet IteraGPU może przechowywać Twoje cele, parametry i decyzje wraz z użytecznymi referencjami. Nie uruchamia runów ani nie zbiera automatycznie plików czy telemetrii. Używaj go jako indeksu swojego rozumowania, a katalog artefaktów trzymaj we własnych kopiach zapasowych.
Źródła techniczne: PyTorch 2.14 — granice odtwarzalności między środowiskami
Praktyczne pytania
Czy commit Git wystarczy, aby odtworzyć eksperyment?
Commit identyfikuje wersję kodu, ale niekoniecznie dane, wagi, efektywne parametry czy niezapisane zmiany. Powiąż go z manifestem oraz wytworzonymi artefaktami. Bez tych powiązań dwa uruchomienia tego samego commita mogą odpowiadać różnym eksperymentom.
Czy należy zachować wszystkie predykcje?
Zachowaj wyniki potrzebne do zweryfikowania wniosków i ponownego obliczenia ewaluacji, w granicach swoich uprawnień i ograniczeń dotyczących przechowywania. W przypadku ograniczonego korpusu porównawczego identyfikatory i pełne predykcje czynią błędy audytowalnymi. Sam zagregowany wynik zwykle nie pozwala odnaleźć brakujących przykładów.
Czy wznowienie powinno użyć tego samego run_id?
Proponowany schemat nadaje nowy identyfikator każdej próbie i wiąże wznowienie z poprzednim runem oraz wczytanym checkpointem. Możesz zgrupować te próby w ramach jednego logicznego eksperymentu. Taki rozdział uwidacznia przerwanie, koszty i pliki faktycznie wytworzone na każdym etapie.