Problem braku możliwości odtworzenia wyników badań ilościowych może wynikać z szeregu przyczyn - na każdym etapie projektowania, realizacji, analizy oraz opisu wyników badania musimy pamiętać o problemie reprodukowalności - bez wystarczającej uwagi na to poświęconej nie ma szans na zapewnienie możliwości odtworzenia wyników uzyskanych w jednym laboratorium przez inne jednostki badawcze lub osoby.

Wpływ czynników losowych

W samą strukturę badania ilościowego, analizowanego przy użyciu technik wnioskowania statystycznego, wpisane jest oczekiwanie niemożliwości pełnego odtworzenia wyników - tradycyjnie wykorzystywane kryterium istotności (p<0.05) jest przecież niczym innym jak deklaracją, że badacz zgadza się na to, że uzyskane przez niego wyniki mogą być dziełem czystego przypadku nie częściej niż raz na dwadzieścia razy. A więc, z definicji, aż do 5% opublikowanych wyników badań ilościowych może być nieprawdziwe (tj. zaobserwowane związki lub różnice mogą być dziełem przypadku), i nie poddaje się pełnej replikacji. Oczywiście prostym sposobem poradzenia sobie z tym konkretnie aspektem problemu jest zmiana poziomu istotności na 0.01 lub 0.001 - co przekłada się odpowiednio na mniejszą, bo liczącą jeden do stu, lub jeden do tysiąca, szansę że uzyskane przez nas wyniki są dziełem przypadku, a nie odzwierciedlają rzeczywiste zjawisko zaobserwowane w środowisku.

Zniekształcenia psychologiczne i konstrukcja ankiet

Na etapie zbierania danych reprodukowalność może być ograniczona przez nieznajomość nie tylko treści, ale także i formy narzędzia badawczego, np. kwestionariusza. Jeżeli np. jest to ankieta telefoniczna, i ankieter wymienia respondentowi kilka opcji odpowiedzi do wyboru, tzw. efekt świeżości sprawi, że będziemy mieli nadreprezentację odpowiedzi z końca listy. W tej samej ankiecie, zrealizowanej w formie drukowanej lub online, rozkład odpowiedzi na to samo pytanie, z listą wariantów do wyboru, będzie zupełnie inny. Znanych jest szereg zniekształceń przetwarzania informacji przez ludzi, które mogą wpływać, w sposób pozamerytoryczny, na odpowiedzi udzielane przez respondentów. Należą do nich np. efekty zakotwiczenia, pierwszeńswa, asymetrii aktywacji i deaktywacji - każdy z nich będzie przejawiał swój wpływ na odpowiedzi chociażby w zależności od kolejności zadawanych pytań. Chociaż sam problem jest wpisany w naturę badania - nie sposób całkowicie "wyłączyć" mechanizmy wprowadzające zniekształcenia poznawcze, ważne jest, aby przy publikacji wyników badań, zamieszczać nie tylko szczegółowe informacje o treści ankiety, ale także o jej formie i kolejności pytań - a więc najlepiej do wyników załączyć pełną ankietę, lub dowolną inną procedurę wykorzystaną w badaniu.

Zmienność danych

Dane ilościowe wydają się stanowić najlepszą możliwą, twardą, jednoznaczą miarę dowolnego zjawiska. Niestety, w praktyce teoretycznie niezmienne dane... zmieniają się, i to na kilku etapach.

Jako przykład weźmy WVS - World Values Survey - realizowany jest cyklicznie, co kilka lat. Dowolna edycj - np. piąta, z 2005 (obecnie nazywana już edycją 2005-2008) - ma etykietę roku, w którym... zrealizowana została największa część badania - ale typowo nie całe badanie! Próbując zreplikować wyniki z artykułu, opublikowanego w czasopiśmie naukowym, możemy odkryć, że wyniki uzyskiwane przez autorów publikacji różnią się od naszych - np. przez to, że próba badana różni się o ... prawie 1000 osób. Jak to możlwe? Otóż w omawianym przykładzie autorzy publikacji wykorzystali najświeższą, właśnie opublikowaną edycję danych WVS. W międzyczasie do zestawu danych z V edycji Węgrzy dosłali wyniki swojego badania. Kiedy, kilka lat poźniej, ściągamy dane WVS z repozytorium w sieci, i próbujemy odtworzyć wyniki, okazuje się że wielkość próby różni się właśnie o prawie tysiąc osób. W tym konkretnie przypadku dalsze śledztwo wykazało, że źródłem rozbieżności było dodanie kolejnego kraju do zestawu danych.

Z podobny problemem mamy często do czynienia, kiedy korzystamy z ankiet online. W takiej sytuacji często stosowaną procedurą jest pobieranie danych bezpośrednio z sieci, z tabeli, w której zapisywane są wyniki ankiety. Jeżeli dostęp do ankiety nie zostanie zamknięty w chwili pierwszego pobierania danych, nie mamy gwarancji, czy nie pojawią się kolejni respondenci, których odpowiedzi zostaną automatycznie dołączone do zbioru danych przy kolejnym pobraniu. Rozwiązaniem, oprócz oczywiście zamknięcia dostępu do ankiety (co czasami nie jest wskazane), jest wersjonowanie pobieranych danych. A więc zapis lokalnej kopii danych po każdorazowym ich pobraniu z sieci, wraz z markerem czasowym. Wtedy możliwe jest odczytanie wcześniejszej wersji danych z lokalnych zasobów i zweryfikowanie ewentualnych różnic w wynikach.

Wersjonowanie danych jest tematem rzadko omawianym - a zdecydowanie wartym uwagi. Szczególnie w odniesieniu do danych naukowych, które mogą być publicznie dostępne - ich składowanie w darmowym repozytorium typu GitHub powinno być przyjętym sposobem postępowania. W przypadku danych, które nie powinny być widoczne publicznie, warto rozważyć wykorzystanie prywatnych repozytoriów Git lub SVN.

"Rzemieślnicze" transformacje danych

W trakcie przygotowywania surowych danych do analizy, praktycznie niezbędne jest ich oczyszczenie, usunięcie błędów, braków danych itp. W niektórych programach, np. w Excelu czy pakietach statystycznych typu Statistica, SPSS, PSPP, przekształcenia danych można robić "ręcznie". Np. w polu "rok urodzenia" respondent wpisuje pełną datę (jak 1999-02-12). Z punktu widzenia dalszej analizy danych to błąd - należy taką daną albo usunąć, albo naprawić. Ręczne naprawienie - wykasowanie części miesiąca i roku - jest najłatwiejsze. Problem w tym, że jeżeli otrzymamy nową wersję danych, tego typu korekty musimy ponownie wykonywać ręcznie - i nie ma żadnej gwarancji, że gdzieś się nie pomylimy. Nie ma też gwarancji, że nie pomyliliśmy się poprzednio - w takiej sytuacji, próba zrozumienia skąd biorą się różnice w wynikach analiz pomiędzy wersjami zbiorów danych, jest skazana na porażkę.

Rozwiązanie jest mało przyjemne dla tych, którzy przyzwyczaili się do ręcznego poprawiania danych (i piszę tu także o sobie - ręczne zmiany są złudnie proste!): wyrażenia regularne i korekty przy użyciu kodu. Np. dla pola "rok urodzenia", przy użyciu wyrażenia "\d\d\d\d" możemy wydobyć cztery kolejno po sobie występujące cyfry, i zastąpić nimi cokolwiek wcześniej znajdowało się w danym polu. Pozwoli to na automatyczną zamianę wpisów typu "Urodziłem się w 1999" lub "19/1/1999" na czterocyfrowy zapis roku.

Drugą ważną regułą przy transformacjach danych jest zachowywanie wersji początkowej danych - na takiej wersji nie powinno się robić żadnych przekształceń, powinna ona być dostępna jako "backup" do którego możemy sięgnąć, jeśli coś nie powiedzie się przy przekształceniach danych. A same przekształcenia - robimy je na kopii zbioru danych.

Trzecią sugestią jest takie wykonywanie przekształceń, aby ich wielokrotne wykonanie nie spowodowało błędów. Przykładowo, powiedzmy że mamy do czynienia z kolumną, w której zapisana jest płeć, kodowana przy użyciu symboli: 1 - kobieta, 2 - mężczyzna. Jeżeli, w celu połączenia z innym zbiorem danych, w którym kodowanie płci jest odwrotne, zamierzamy odwrócić kody, tak aby 1 oznaczało mężczyznę, warto wykonać taką transformację do nowej kolumny, zachowując starą, oryginalną zmienną. Możemy wtedy taką transformację wykonać wielokrotnie, za każdym razem otrzymamy poprawny wynik. Jeżeli natomiast nadpiszemy oryginalną zmienną wersją zrekodowaną, powtórne wykonanie rekodowania ... przywróci oryginalne wartości. To niby niewielki problem, ale wcześniej lub później dotrzemy do punktu, w którym już nikt nie będzie wiedział, czy w danej chwili "1" oznacza kobietę czy też mężczyznę.

Problem: odtwarzalność algorytmów

Rzadko kiedy można spotkać dyskusje nad tym problemem, ponieważ ujawnia się on po kilku lub kilkunastu latach. Jeżeli obróbka danych i analizy są realizowane w wersji oprogramowania, która przestanie być rozwijana, po kilku latach może się okazać, że nie potrafimy ponownie uruchomić kodu odpowiedzialnego za przekształcenia danych lub analizy. W wypadku tego problemu rozwiązanie powinno zależeć od horyzontu czasowego, w jakim chcemy zachować zdolność do re-analizy danych. W skrajnych przypadkach warto rozważyć rozwiązania polegające na pełnej wirtualizacji środowiska analiz, tak aby zachować kompletny ekosystem: dane, polecenia przekształceń i analiz, ale także oprogramowanie do analizy danych, system operacyjny oraz wirtualny hardware. Szansa na uruchomienie z sukcesem za 10 lat maszyny wirtualnej w formacie VMVare lub VirtualBox jest dużo większa, niż na uruchomienie na obecnym sprzęcie i oprogramowaniu kodu do analiz sprzed 10 lat, odwołującego się do nieaktualnych i niedostępnych już bibliotek.

Previous Post Next Post