Temat: Projekt walidacji R - czas najwyższy

W dyskusjach "SAS/STATA/SPSS/Statistica/XXX vs. R" nieodmiennie pada hasło "R is not validated".

Istnieje wielka wiara w to, że zamknięte, komercyjne systemy muszą zawierać wyłącznie dobrze działający kod. Fakt, że tysiące statystyków, chociażby w badaniach klinicznych na bieżąco waliduje kod R kodem w SAS/etc. i vice versa (często spotykana, typowa procedura dla procedur oznaczonych statusem "critical"), otrzymując takie same lub "rozsądnie zbliżone" (zależnie od przyjętej metody/algorytmu) zdaje się nie mieć większego znacznie w takich dyskusjach.

"Validation" staje się w tym kontekście Świętym Graalem, Arką Przymierza i Yeti jednocześnie. Wszyscy o tym mówią, nikt do końca nie wie, co to słowo ma oznaczać. Ile ja już dyskusji na ten temat czytałem... Jedni mówią, że chodzi o to, że że dział jakości producenta testuje procedury na pewnym zbiorze danych (skąd pewność, że na innych zbiorach też zadziała? Co z uwarunkowaniem macierzy, co z wrażliwością algorytmu na pewne "konfiguracje" zmiennych?) i to daje pewność (?), że wszystko jest OK. Przy czym odnoszę wrażenie, że wiele osób miesza "walidację oferowanych procedur statystycznych" z walidacją kodu, który piszą one same i która z "walidacją producenta" nie ma nic wspólnego. Istnieje także różnica między "walidacją biblioteki" a "walidacją środowiska uruchomieniowego", bo co z tego, że w wersji 3.60 biblioteka w wersji 1.0 działa OK, jak w wersji 3.61 ktoś zmienił domyślną opcję stringsAsFactors = FALSE?

Do tego podnosi się często argument, że w razie "problemów" producent weźmie na siebie odpowiedzialność i pokryje straty post factum.

Z tym drugim stwierdzeniem nie sposób polemizować - bo po pierwsze nie wiadomo, czy tak się stanie (a jeśli nie uzna reklamacji? Może to położyć cień na marce. Jedni wykorzystają na plus - "patrzcie, jacy jesteśmy uczciwi", a inni na minus - zamiotą pod dywan, "ugoda, ale buzia na kłódkę"), a po drugie - jeśli reklamacja zostanie uznana, to mamy fakt dokonany.

R jest używany "na własne ryzyko" i nikt nam strat nie pokryje. W sumie nawet na mail z "żalami" do autorów można by dostać hipotetyczną odpowiedź "ale to państwa problem, państwa ryzyko ja to robię wolontariacko i proszę mi głowy nie zawracać".

Ale na brak walidacji jest metoda. Bardzo prosta. Zwalidować kolejne metody, procedury, funkcje, wreszcie - całe pakiety tak, jak są one tworzone, czyli kolektywnie i podzielić się wynikami ze społecznością.

Przy czym nie chodzi o taką walidację, jak np. http://cran.r-project.org/web/checks/check_results_sql...
która informuje tylko o tym, czy pakiet się buduje i uruchamia.

Wiem, ze są firmy, które oferują tego rodzaju usługi (np. http://www.mango-solutions.com/r-validation.html ) ale skoro R jest OpenSource i tworzony/wspierany jest przez ochotników, to warto, by i ten aspekt był "otwarty i wolny".

Mam już dość wysłuchiwania narzekań "R is not validated", dlatego postanowiłem coś w tym kierunku zrobić. Zaczynam zastanawiać się nad formą przedsięwzięcia i zadałem sobie szereg pytań i wynotowałem kilka uwag:
__________________________________________________________________________________

1. Jaka forma walidacji byłaby najlepsza: najprostsza + przekonywująca?

- np. użycie takiej metody na pewnym (udostępnionym) zbiorze danych, a następnie wykonanie tej samej operacji w innym programie, komercyjnym i udostępnienie wyników w postaci:
- daty wykonania analizy
- nazwy pakietu z linkiem do niego
- wersją pakietu
- zrzutem środowiska
- linku do danych do pobrania (CSV / TabSV)
- kodu w R i danym pakiecie (plik tekstowy)
- zrzutu ekranu z R i danego pakietu użytego do walidacji

Każdy walidujący powinien podać swój kod licencji dla uwiarygodnienia. Mógłby także podać nazwisko i kontakt do siebie - ale to rodzi problem z GIODO :/

Myślę, że dopuszczalne byłoby także zamieszczanie wyników z wersji "testowych" (demonstracyjnych) takich programów - w sumie chyba każdy producent udostępnia takie wersje. Ostatnio nawet SAS wydał darmową wersję dla uczniów :) Napisałem "myślę, że dopuszczalne", ponieważ nie wiem, czy takie wersje dema mają taki sam poziom "zwalidowania" jak pełna wersja. Czasem pewnie tak - jeśli wersja demo i pełna to ten sam kod, tylko zależny od licencji, a czasem może nie.

- Oczywiście procedura może być powtarzana dla najróżniejszych zbiorów danych - im ich więcej, tym lepiej! 2450 znaczków "validated" wygląda lepiej niż 1 taki znaczek.

Należy opracować procedurę umieszczania danych, uwzględniającą, m.in.: maksymalny rozmiar, nakaz "zaciemniania" danych personalnych albo podpisanie elektronicznego oświadczenia, że dane są wygenerowane sztucznie, podpisanie elektronicznego oświadczenia, że dane nie są niczyją własnością i że umieszczający zdaje sobie sprawę, że jego IP jest logowane, przez co właściciel danych może dochodzić roszczeń od danej osoby, zakaz dublowania zbiorów danych (hash z danych i porównanie zgodności pewnego zdefiniowanego zbioru statystyk opisowych jako podstawowe zabezpieczenie).

- Należy się spodziewać, że najwięcej testów miałyby najpopularniejsze procedury, jak np. lm, aov, nlme, lme4, survfit i generalnie zawartość biblioteki "recommended" itp. Ale nie szkodzi, zawsze to więcej, niż nic, nie od razu R napisano...

- Pakietów jest ponad 6 tysięcy, ale też nie wszystkie trzeba walidować, np. tworzące grafikę, jak ggplot2 czy lattice. Bedą też funkcjonalności, których brak w oprogramowaniu konkurencyjnym, np. DataTable czy SQLDF czy "101 sposób na obliczenia/przetwarzanie w grupach, czyli SASowe >BY<". Trudno porównywać tego rodzaju "podobne rozwiązania", bo brak tu wspólnego punktu odniesienia. Podobnie może nie być sensu walidować procedur transformujących dane. Po pierwsze - ilu programistów, tyle podejść (na samo "by" chociażby, o .FIRST i .LAST nie wspomnę). Co najwyżej można tym pokazać, że w R istnieją procedury pozwalające otrzymać identyczną postać danych ze zbioru źródłowego - a to akurat nie jest celem walidacji.

- Pewne funkcje mogą być zdefiniowane inaczej w SAS i R, np. różne domyślne kontrasty, typy sum kwadratów, poprawki. Wynik walidacji musi zawierać wzmiankę, że "uzyskane różnice wynikają z XXXX" lub "do celów walidacji ustawiono taki a taki parametr".

- Jeśli dana metoda ma kilka wariantów (algorytmów), zaś w obu programach brak dokładnych odpowiedników, pozostaje użyć tego, co jest (w R - metoda X wariant A, w SAS metoda X wariant B) - wtedy trzeba opisać, czy dla osoby analizującej ewentualne uzyskane różnice miedzy wynikami są akceptowalne i dlaczego.

- Jeśli wyniki danych metod wywołanych z domyślnym zestawem parametrów różnią się, ale można je sprowadzić "do wspólnego mianownika" - należy podać wszystkie dodatkowe czynności potrzebne do uzyskania identycznych wyników w obu pakietach

- Można by wykombinować jakiś system "współzawodnictwa" i "kusić punktami" za przetestowanie procedur, które zostały zgłoszone do testów (każdy może zgłosić funkcję i pakiet, może go także sam przetestować), a za które jeszcze "nikt się nie wziął"

- warto wprowadzić dodatkowe rewizje kodu przez specjalistów z zakresu statystyki i programowania, którzy dodatkowo potwierdzą, że kod wygląda OK. Oczywiście będą oni w stałym kontakcie z twórcami badanego pakietu, to na nich spoczywać będzie obowiązek zgłoszenia i "poprowadzenia" błędu do końca, nim klikną "mark source code for v1.2.323 as validated".

- warto także wprowadzić walidację "zgodne z materiałami referencyjnymi" - tzn. czy zaprogramowana formuła odpowiada rzeczywiście wzorowi znajdującemu się w materiałach, na których opierał się autor? A może taki materiał otrzymał erratę i trzeba poprawić kod procedury?

- walidacja każdej wersji każdego pakietu może być wycofana przez każdego, kto dostarczy obowiązkowo dane + kod ujawniający problem.

- walidacja mogłaby też być automatyczna - na serwerze, np. dla nowych wersji.
Dysponując zbiorem [dane wejściowe; metoda; oczekiwane wyniki] system mógłby "zapuszczać" testy na dostępnych zbiorach danych w odpowiedzi na zdarzenie, np. "podbicie wersji pakietu".

Wystarczy, że dla bieżącej wersji pakietu paru wolontariuszy przygotuje dane wejściowe, "zapuści" metodę w R i np. SPSS/SAS i uzupełni scenariusz testowy. Im więcej różnych (prawdziwych!) zbiorów danych, tym lepsza jakość walidacji. Potem, gdy nastąpi zwiększenie wersji pakietu, zdarzenie to wyzwala trigger wykonujący cały ciąg analiz.

Nie trzeba do tego wcale jakiejś dużej mocy obliczeniowej, bo pakiety nie zmieniają się w CRAN codziennie. Nawet, jak metoda jest bardzo wyczerpująca obliczeniowo, np. metoda dokładna, bootstrap, albo wrażliwa na liczbę wymiarów danych - policzy się 2 godziny i po wszystkim.

__________________________________________________________________________________

2. Czy tego rodzaju walidacja będzie przekonywująca? Czy proces walidacji w komercyjnych firmach wygląda inaczej? Jeśli nie - to powinna być przekonywująca. Tu nie da się nic "zamieść pod dywan", a testującym może być każdy, nie tylko zamknięty zespół w dziale QA producenta.

- Przydatne byłoby wprowadzenie jakichś metodyk testowania, rodem z profesjonalnych działów QA i sformułować wytyczne, których każdy testujący musiałby przestrzegać, tak, by maksymalnie uwiarygodnić wyniki. By nie dało się powiedzieć "sorry, nie ufam wam, bo na pewno nie testujecie tak superancko jak ci w SAS Institute".

Czy to, kto utrzymuje stronę miałoby wpływ na zaufanie do wyników? Twórcy R to znane, rozpoznawane w środowisku osoby z dużym dorobkiem naukowy, więc pewnie zaufanie do strony byłoby spore. Z drugiej strony mogą nie mieć czasu na rozwijanie takiego projektu (skoro do dziś nie powstał), więc musiałaby zrobić osoba z zewnątrz. Chyba, że np. istniałaby jakaś forma "uznania" z ich strony na zasadzie "podpisujemy się pod tym".
__________________________________________________________________________________

3. Czy środowisko twórców R (zarówno base team jak i twórcy popularniejszych pakietów) wykażą zainteresowanie? Czy stanie się on częścią projektu GNU R, przynajmniej jako "contrib"? Myślę, że taka inicjatywa byłaby ogromną wartością dodaną. A jeśli w przyszłości powstawałyby podobne systemy - można by wzajemnie uznawać swoje wyniki i agregować je.

Mało tego, serwis taki mógłby udostępniać API przez które można by na bieżąco sprawdzać status danego projektu w danej wersji i umieścić go na stronach pakietów CRAN (chodzi o takie strony: http://cran.r-project.org/web/packages/sqldf/index.html ). Wymagałoby to znacznej współpracy ze środowiskiem twórców CRAN, ale efekt mógłby być rewelacyjny. Zielona kropka - pakiet zwalidowany, w nawiasie liczba walidacji. Żółta kropka - zwalidowane poprzednie wersje. Czerwona kropka - brak walidacji, link "Poproś o walidację" --> zgłoszenie na stronę "ValidatedR.com" (i ew. mail do autora/ów).





- Sami twórcy swoich pakietów zapewne z chęcią dokonywaliby pierwszych walidacji (nieobowiązkowo!) posiadając dostęp do komercyjnych ("zwalidowanych") pakietów statystycznych.

- A stąd już tylko krok do procedur pozwalających tworzyć "w pełni zwalidowane środowiska pracy", czym nie pogardziliby ludzie z branży badań klinicznych.

- Dodatkowo można by pobierać ze strony projektu PDF z potwierdzeniem walidacji pakietu (lista zbiorów danych, wyniki, zrzuty ekranu z innych pakietów plus timestamp - wszystko zawarte jednym pliku), co stanowiłoby "podkładkę" dla użytkowników.

__________________________________________________________________________________

4. Czy testujący powinni ponosić odpowiedzialność za jakość przeprowadzanych testów? A jeśli tak, to jaki system kar? "Wall of shame" - lista użytkowników, którzy sfałszowali wyniki? Ale jak udowodnić celowe działanie? To mogłoby zniechęcać wolontariuszy.
__________________________________________________________________________________

5. Istotny jest problem zależności pakietów. Walidowany pakiet B zależy od niezwalidowanych pakietów A i D. I co teraz? Czy wystarczy walidować konkretny pakiet B, czy dopiero walidacja wszystkich pakietów z łańcucha zależności (A i D) pozwala zamieścić status "Validated"?
__________________________________________________________________________________

Jedno jest pewne - R NIGDY nie przebije się przez barierę "not trusted, not validated", jeśli ktoś nie wykona pierwszego kroku i chociaż nie spróbuje. Można podawać przykłady "wielkich korporacji", które korzystają z R, setki publikacji opartych o wykorzystanie R, które uwiarygadniają go w ten sposób, ale to zawsze będzie za mało. Bo "darmowe = niezweryfikowane".

Co do technologii - ASP.NET MVC + jakaś wygodna biblioteka do tworzenia GUI, np. znany Bootstrap. Ma być bez wodotrysków, łatwo, szybko, czytelnie i prosto. A ta konfiguracja pozwala szybko tworzyć aplikacje webowe. Zapewne ktoś powie, że "lepsze PHP, bo lepiej pasuje do tradycji OpenSource", ale nie będę się uczył nielubianego przeze mnie PHP tylko z tego powodu. Zresztą kod byłby otwarty, a także pisany w sposób przenośny, by dało się uruchomić na Mono pod Linuksem. Można by też użyć jakiegoś CMSa, wtyczki do Wordpressa lub podobnego rozwiązania... To może być ważne, gdyby kiedyś twórcy CRAN zechcieli mieć taką bazę na własnych serwerach.

To tak na szybko, bo już późno w nocy. Jakie są Wasze opinie na ten temat? Wiem, że dużo i może nieco chaotycznie, ale projekt nie jest trywialny i jest tam masa niuansów.Ten post został edytowany przez Autora dnia 14.12.14 o godzinie 09:48