Pipeline to wykonywalny opis analizy

Notatka „uruchomiono aligner, potem policzono geny" nie wystarcza do odtworzenia wyniku. Workflow powinien jawnie określać wejścia, narzędzia, parametry, referencje, zależności między krokami i oczekiwane wyjścia — tak, by ktoś inny (albo ty za rok) uruchomił go jednym poleceniem. Kontrola jakości nie jest osobnym raportem na początku; to zestaw bramek rozłożonych po całym przepływie, z których każda ma regułę decyzji ustaloną, zanim zobaczysz wynik biologiczny.

Kontrola jakości działa jak seria bramek wzdłuż całego pipeline'u — od pobrania po model. Na każdej z nich decyzja powinna mieć regułę ustaloną, zanim zobaczysz wynik biologiczny.
Kontrola jakości działa jak seria bramek wzdłuż całego pipeline'u — od pobrania po model. Na każdej z nich decyzja powinna mieć regułę ustaloną, zanim zobaczysz wynik biologiczny.

Zacznij od projektu eksperymentu

Przed pobraniem danych utwórz arkusz próbek: jeden wiersz to jednostka biologiczna, a kolumny opisują grupę, dawcę, partię, preparat, plik i wykluczenia. Ustal kontrast statystyczny oraz potencjalne czynniki zakłócające. Jeżeli wszystkie próbki kontrolne sekwencjonowano w poniedziałek, a leczone we wtorek, efekt dnia jest nierozdzielny (zmylony, confounded) z efektem leczenia — żadna analiza tego już nie naprawi. Randomizacja i zrównoważenie partii są decyzją projektową, nie obliczeniową.

Zamroź surowe wejścia: nie edytuj FASTQ ręcznie. Zapisz numery dostępu, sumy kontrolne, wersję referencji i plik adnotacji. Każdy wynik powinien dać się powiązać z konkretnym zestawem wejściowym.

Kontrole na kolejnych bramkach — z realnymi narzędziami

  • Po pobraniu sprawdź integralność (md5sum), kompletność par i zgodność nazw z tabelą próbek.
  • Po kontroli FASTQ oceń jakość baz, adaptery, długość, duplikację i skład — narzędziami FastQC (pojedyncze próbki), fastp (QC + przycinanie w jednym), a przy podejrzeniu zanieczyszczenia FastQ Screen lub Kraken2 (identyfikacja gatunków w odczytach). Nie stosuj automatycznego przycinania tylko dlatego, że program pokazał ostrzeżenie — decyzja zależy od technologii i dalszego narzędzia.
  • Po uliniowieniu lub pseudo-uliniowieniu sprawdź odsetek przypisanych odczytów, wielokrotne mapowanie, rozkład na geny i regiony oraz zgodność kierunkowości biblioteki. Dla RNA-seq używa się tu STAR lub HISAT2 (mapowanie do genomu) albo salmon/kallisto (szybka pseudo-kwantyfikacja), a metryki liczą samtools flagstat/stats, Qualimap, RSeQC i Picard (CollectRnaSeqMetrics). Zliczenia agreguje featureCounts lub htseq-count. Niski wynik może wskazywać złą referencję, kontaminację albo niewłaściwy typ biblioteki; nazwa narzędzia jest jednak mniej ważna niż zapisane parametry i wersje.
  • Po utworzeniu macierzy obejrzyj rozkłady wielkości bibliotek, próbki odstające, korelacje, PCA i zgodność z metadanymi. PCA nie rozstrzyga automatycznie, którą próbkę usunąć — wykluczenie wymaga wcześniej określonej reguły albo mocnego, zapisanego uzasadnienia technicznego.
  • Po modelu sprawdź diagnostykę, wielkość efektu, niepewność, wielokrotne testowanie i stabilność na rozsądne zmiany parametrów. Lista „istotnych genów" bez kierunku, efektu i kontroli jakości jest trudna do interpretacji.
Wielokrotne testowanie i naginanie analizy

Szczególnie ważna jest korekta wielokrotnego testowania. W typowym RNA-seq testuje się kilkanaście–dwadzieścia tysięcy genów naraz. Przy progu p < 0,05 bez korekty sam przypadek dałby setki „istotnych" genów — czysto losowo. Dlatego kontroluje się odsetek fałszywych odkryć (FDR), najczęściej metodą Benjaminiego-Hochberga, i raportuje wartości skorygowane (q). Mylenie surowego p z wynikiem po korekcie to jeden z najczęstszych błędów. Równie ryzykowne jest naginanie analizy (p-hacking) — próbowanie wielu wariantów i wybór „ładnego". Antidotum to ustalenie kontrastu i reguł jeszcze przed obejrzeniem danych (a w badaniach konfirmacyjnych — prerejestracja).

Automatyzacja bez ukrywania decyzji

Menedżer workflow oddziela jedną definicję pipeline'u od środowiska wykonania: ten sam kod biegnie na laptopie, klastrze SLURM i w chmurze, a każdy krok w kontenerze. Provenance (raport, versions.yml, konfiguracja) powstaje z każdego biegu.
Menedżer workflow oddziela jedną definicję pipeline'u od środowiska wykonania: ten sam kod biegnie na laptopie, klastrze SLURM i w chmurze, a każdy krok w kontenerze. Provenance (raport, versions.yml, konfiguracja) powstaje z każdego biegu.

Menedżery workflow opisują zależności między zadaniami, zrównoleglają je i pozwalają wznawiać przerwaną pracę: Nextflow, Snakemake, a w świecie standardów — WDL (z silnikiem Cromwell) i CWL. Ich siła polega na oddzieleniu logiki od infrastruktury: ten sam pipeline działa na laptopie, klastrze SLURM i w chmurze, a każdy krok biegnie w kontenerze (Docker/Apptainer) lub środowisku conda, więc wersje narzędzi są utrwalone.1 Nie trzeba pisać wszystkiego od zera — projekt nf-core dostarcza recenzowane, gotowe potoki (np. nf-core/rnaseq, nf-core/sarek do wariantów)3, a platforma Galaxy udostępnia analizy przez interfejs graficzny, bez kodu.

Odtwarzalność nie wynika jednak z nazwy narzędzia. Kontener utrwala zależności programu, ale nie wersję danych referencyjnych ani parametry — te muszą znaleźć się w konfiguracji i raporcie. Dobry pipeline ma mały zestaw testowy, automatyczne sprawdzenie oczekiwanych plików (CI, np. GitHub Actions, nf-test) i wersjonowaną konfigurację. Z każdego biegu warto zachować provenance: raporty wykonania (Nextflow report/trace/timeline), plik versions.yml z wersjami narzędzi i użytą konfigurację. Gotowe workflow można też współdzielić i cytować przez WorkflowHub (z DOI).

Raport QC ma prowadzić do decyzji

Dla każdego wskaźnika określ:

  • co biologicznie lub technicznie mierzy;
  • jaki zakres jest oczekiwany w tym eksperymencie;
  • czy próg jest twardy, czy wymaga przeglądu;
  • co zrobić po przekroczeniu;
  • czy decyzja zapadła bez znajomości wyniku biologicznego.

Agregator raportów — MultiQC — zbiera wyniki dziesiątek narzędzi i próbek w jeden przegląd, świetny do porównań, ale nie zamienia wszystkich sygnałów w jeden „wynik jakości".2 Interpretacja bramek pozostaje decyzją człowieka, opartą na wcześniej ustalonych regułach.

Definicja ukończonej analizy

Analiza jest gotowa, gdy nowe środowisko uruchamia ją jednym udokumentowanym poleceniem; log zawiera wersje i parametry; wynik jest połączony z próbkami; raport pokazuje bramki jakości; a człowiek zatwierdził biologiczną interpretację. Dopiero wtedy warto optymalizować czas i koszt, co omawia artykuł Moc obliczeniowa i przechowywanie danych; narzędzia bazowe (Git, środowiska, kontenery) opisuje Linux, Git, Python i R.