Reprodukowalność badań w naukach ścisłych

Reprodukowalność badań w naukach ścisłych oznacza, że ktoś inny (lub nawet my sami w przyszłości) może powtórzyć cały proces badawczy — od zebrania danych, poprzez kod i metody analizy, aż po otrzymane wyniki — i otrzymać te same (lub bardzo zbliżone) rezultaty. W praktyce chodzi o to, by:

Udostępniać pełny zestaw danych i kodu: Każdy element analizy (skrypty do wczytywania danych, przetwarzania ich, trenowania modeli, generowania wykresów itp.) jest jawny i przejrzysty.
Dokładnie dokumentować procedury: Opisujemy krok po kroku, w jakich warunkach zbieraliśmy dane, jakie parametry używaliśmy w algorytmach, jakie wersje oprogramowania.
Zapewniać izolację etapów analizy: Na przykład w uczeniu maszynowym nigdy nie korzystamy z zestawu testowego (danych do ostatecznej oceny modelu) podczas trenowania lub dobierania hiperparametrów, bo to zafałszuje wyniki. (reproducible.cs.princeton.edu

Co to jest „kryzys reprodukowalności w nauce opartej na uczeniu maszynowym”?

Artykuł dostępny pod adresem https://reproducible.cs.princeton.edu/ wskazuje, że w wielu dziedzinach nauki, w których wykorzystuje się modele uczenia maszynowego (ML) do formułowania i weryfikowania hipotez, dochodzi do systematycznych błędów prowadzących do niemożności odtworzenia opublikowanych wyników. Najczęściej wynika to z tzw. przecieku danych (data leakage), czyli sytuacji, gdy do trenowania modelu nieumyślnie trafiają informacje, które powinny być dostępne dopiero w fazie testowej lub wyjściowej. Przez to algorytm „ucz się i testuj na tych samych danych”, co prowadzi do nierealistycznie wysokich ocen jakości modelu i w efekcie do błędnych wniosków naukowych (reproducible.cs.princeton.edu).

Najważniejsze przyczyny kryzysu:

Brak wyraźnego oddzielenia danych treningowych od testowych:
- Jeśli ten sam zestaw lub powiązane dane zostaną użyte do trenowania i oceny modelu (np. przez przypadek łączymy proces wstępnej obróbki dla obu zestawów), ocena wydajności modelu jest obarczona ryzykiem przecieku.
Wykorzystywanie nieuprawnionych cech (features):
- Często w praktyce dodaje się do modelu zmienne, które w rzeczywistości są silnie skorelowane albo nawet bezpośrednio odzwierciedlają zmienną zależną (np. w badaniach medycznych: cecha „wynik testu” może w rzeczywistości ujawnić już fakt choroby). Takie „legalne” przekroczenie granicy informacji daje modelowi nieuczciwą przewagę.
Różnica rozkładów danych trenowanych i używanych do wnioskowania naukowego:
- Nawet gdy technicznie zachowujemy separatę train/test, jeżeli dane testowe pochodzą z innego źródła lub są zebrane w innym czasie niż dane, na których opieramy wnioski naukowe, model może działać dobrze w eksperymentarium, ale niewiarygodnie w praktyce.

W efekcie publikowane prace dają wrażenie „znakomitej skuteczności” modelu, ale gdy ktoś spróbuje powtórzyć całą ścieżkę badawczą albo zastosować model do nowego zestawu danych, wyniki okazują się znacznie gorsze niż zakładano (reproducible.cs.princeton.edu).

Dlaczego to jest istotne dla naukowca?

Utrata zaufania do wyników
Jeśli dany model lub algorytm w pracy opiera się na błędnym rozdzieleniu etapów trenowania i testowania, finalne wnioski (np. że „ten biomarker świetnie przewiduje status choroby”) mogą być błędne. Inni badacze, którzy próbują powtórzyć tę pracę, nie uzyskają tych samych wyników.
Potencjalne koszty etyczne i finansowe
W medycynie czy biologii kostiumowana „zawodność” modelu może prowadzić do fałszywych diagnoz lub błędnych rekomendacji terapeutycznych. W informatyce stosowanej – do nieefektywnego wykorzystania zasobów.
Blokada postępu naukowego
Jeśli kolejne prace bazują na niepoprawnych wynikach, wątki badawcze się rozwidlają i trudniej jest odróżnić, co jest wartościowe, a co trzeba odrzucić jako artefakt złych praktyk. (reproducible.cs.princeton.edu).

Jakie konkretne błędy (data leakage) wyróżniono w przeglądzie?

Przygładowa, niepełna lista ośmiu kategorii przecieków danych (według taksonomii zaproponowanej w tamtym artykule) pokazuje, jak subtelne mogą być pomyłki:

Brak czystego rozdzielenia zestawów
- Czasem wpada się w pułapkę: wstępnie scala się (merge) lub normalizuje (scale) wszystkie dane naraz, zamiast robić to osobno dla zbioru treningowego i testowego.
Wykorzystywanie nieuczciwych cech (illegitimate features)
- Model może się nauczyć ze spektrum informacji, które nie powinny być dostępne w momencie predykcji (np. zmienna proxy).
Zestaw testowy nie pochodzi z tej samej populacji, co dane źródłowe
- Model może być świetny w specyficznych warunkach, ale w rzeczywistości wnioski naukowe opierają się na szerszym kontekście.
Selekcja cech na danych testowych
- Często w praktyce wybiera się najlepsze zmienne (np. za pomocą statystycznych testów) patrząc na cały zbiór danych, a dopiero potem dzieli się go na train/test. To już jest przeciek.
Powtórzenia (duplikaty) pomiędzy train i test
- Jeśli te same rekody lub bardzo podobne obserwacje (np. dwa fragmenty obrazu z tej samej próbki) lądują w obu zestawach, wynik jest zafałszowany.
Czasowy przeciek (temporal leakage)
- W badaniach medycznych/epidemiologicznych może pojawić się sytuacja, że informacje z przyszłych pomiarów (które przecież nie byłyby dostępne w chwili prognozy) trafiają do fazy treningowej.
Nieprawidłowa walidacja krzyżowa (cross-validation)
- Jeżeli przy podziale na fałdy (foldy) linkuje się ze sobą rekordy, które w rzeczywistości nie są niezależne (np. próbki tego samego pacjenta), również mamy przeciek.
Preprocessing (skalowanie, standaryzacja) wykonywane na całym zbiorze
- Wszystkie te etapy powinny być wykonywane oddzielnie: najpierw bierzemy tylko zestaw treningowy, liczymy parametry skalowania (średnia, odchylenie), przekształcamy trening, a dopiero potem, używając tych samych parametrów, skalujemy test.

Zbadano 41 publikacji z 30 różnych dziedzin i w rezultacie aż 648 prac wykazywało przynajmniej jeden z tych błędów. W niektórych przypadkach wnioski były wręcz absurdalnie optymistyczne, bo model „nauczył się” tych niewłaściwych skrótów od rzeczywistych relacji. (reproducible.cs.princeton.edu).

Proponowane rozwiązania i dobre praktyki

1. Model Info Sheet (karta informacyjna modelu)

To dokument wzorowany na tzw. „model cards” (Jeffrey Mitchell i wsp.) – ma strukturę, w której krok po kroku wyjaśniamy, jakie dane zostały użyte, jak je podzielono, jakie preprocessingi zastosowano, jakie miary oceny, skąd wzięto kod, itp.
Karta powinna zawierać precyzyjne argumenty na temat braku przecieku danych:
1. W jaki sposób odseparowano zestaw treningowy od testowego we wszystkich krokach analizy.
2. Jakie cechy zostały uwzględnione i dlaczego są „legitimate” (racjonalne, uzasadnione naukowo).
3. Z jakiego rozkładu danych model czerpie, i czy odpowiada on temu, o czym badamy wnioski.

2. REFORMS Checklist

To gotowy zestaw punktów kontrolnych (checklist) publikowany w czasopiśmie „Patterns” (2023), który pomaga zweryfikować, czy w procesie analizy nie pojawiają się typowe pułapki.
Składa się z takich elementów jak:
- Równe partycjonowanie: upewnij się, że dane są losowo, ale jednocześnie właściwie podzielone na trening i test.
- Niezależność obserwacji: sprawdź, czy nie ma powtórzeń/duplikatów między zbiorami.
- Selekcja cech: wykonaj ją wyłącznie na zestawie treningowym.
- Walidacja: stosuj metody cross-validation, ale tak, aby w żadnym fałdzie nie doszło do przecieku informacji.
- oraz inne kroki związane z inżynierią cech, normalizacjami, walidacją itp.
Regularne stosowanie tego checklisty zwiększa szansę, że unikniemy większości uproszczeń prowadzących do niereprodukowanych wyników. (reproducible.cs.princeton.edu).

3. Otwarty kod i kontenery

Udostępnianie kodu (np. GitHub, GitLab):
- Każda osoba powinna mieć dostęp do pełnej historii commitów, co ułatwia śledzenie zmian w analizie i wyłapywanie momentu, w którym mógł pojawić się przeciek.
Konteneryzacja (Docker, Singularity):
- Dzięki kontenerom dokładnie wiemy, w jakim środowisku (wersje bibliotek, system operacyjny) uruchomiono eksperyment. To zmniejsza ryzyko, że różnice w konfiguracji sprzętu/oprogramowania wywołają nowe nieprzewidziane błędy.

4. Przegląd kodu (code review)

Wewnętrzna lub zewnętrzna weryfikacja kodu przez innego eksperta pomaga wychwycić subtelne błędy, szczególnie jeśli ktoś „na świeżo” sprawdza, czy rzeczywiście w modelu nie ma też dostępu do danych testowych w procesie treningu.
Dobry recenzent powinien sprawdzać:
1. Strumień analizy od surowych danych do wyników: czy gdzieś nie przekopiowano fragmentów plików?
2. Logikę podziału: czy jest losowa, czy może w strukturze danych istnieje jakaś czasowa lub przestrzenna korelacja?
3. Parametryzację: czy przy każdej próbie trenowania zestaw testowy nie przecieka w metody skalowania lub selekcji cech?

5. Edukacja i świadomość

Zespół powinien być świadomy istnienia „kryzysu reprodukowalności” i głównych przyczyn przecieków. Nawet prosta zmiana przyzwyczajeń (np. robienie train_test_split jako pierwszego kroku, zanim cokolwiek przekształcimy) może wyeliminować liczne problemy.
Organizowanie warsztatów lub kursów z dobrych praktyk w ML (z naciskiem na izolację etapów, walidację itp.) znacząco obniża ryzyko, że ktoś „dla przyspieszenia” zrobi preprocessing na wszystkich danych naraz.

Praktyczne kroki, które możesz od razu zastosować

Zacznij każdy projekt ML od jasnego podziału na zestawy
- W kodzie (np. w Pythonie) powinieneś zawsze robić train, test = train_test_split(dane, test_size=…) jako pierwszy krok, a dopiero potem każdą operację preprocessingową stosować osobno do train i osobno do test.
Dokumentuj każdą procedurę w README lub w komentarzach
- Jakie metody preprocessingowe, jakie algorytmy, dlaczego akurat one i jakie parametry. Z czasem samo przejrzenie dokumentacji wskaże, czy gdzieś nie zrobiliśmy czegoś niepoprawnie.
Korzystaj z gotowych bibliotek i frameworków, które wymuszają dobrą praktykę
- Na przykład scikit-learn w Pythonie ma klasy Pipeline (rurki), dzięki którym możemy łańcuchować preprocessing i trenowanie w taki sposób, że przypadkowo nie „uderzymy” w set testowy.
Twórz Model Info Sheets jako część artefaktów publikacji
- Nawet jeśli nikt tego nie wymaga, sam fakt, że masz gotowy dokument z tabelą: „krok 1: podział danych, krok 2: preprocessing na train, krok 3: selekcja cech na train, krok 4: walidacja…” ułatwia zarówno Tobie, jak i recenzentom ocenę poprawności.
Raz na jakiś czas przeglądaj listę prac, w których znaleziono przecieki w Twojej dziedzinie
- Artykuł grupujący przypadki (turn0view0) pokazuje, że niemal każda dziedzina (np. neuroobrazowanie, bioinformatyka, medycyna, inżynieria oprogramowania) miała swoją falę „straconych wniosków” z powodu data leakage. Wiedza o tym pomaga uniknąć podobnych pułapek.

Podsumowanie

W skrócie, link do strony „Reproducible Research” (https://reproducible.cs.princeton.edu/) oznacza zwrócenie uwagi na kryzys reprodukowalności w nauce opartej na uczeniu maszynowym. Autorzy dokumentują, że w bardzo wielu pracach ML-owych popełniono błędy prowadzące do niemożliwych do powtórzenia (czyli nierzetelnych) wyników, a najczęstszą przyczyną jest data leakage. W odpowiedzi proponują taksonomię głównych rodzajów przecieków, checklistę REFORMS oraz wzór „Model Info Sheet”, które mają usystematyzować proces badawczy i zminimalizować ryzyko takich błędów. Jeśli pracujesz z danymi i modelami ML, warto już dzisiaj wdrożyć te zasady: jawność kodu i danych, ścisłe oddzielenie etapów analizy, dokładne dokumentowanie oraz wielokrotna weryfikacja (przegląd kodu, walidacja krzyżowa) — to fundamenty badań, które da się skutecznie reprodukować (reproducible.cs.princeton.edu).

Źródło:
Leakage and the Reproducibility Crisis in ML-based Science, Princeton University, maj 2023. (reproducible.cs.princeton.edu)

Reprodukowalność badań w naukach ścisłych by www.doktoraty.pl