Samokonfiguracja jako zasada inżynierska

Konfiguracja jest częścią modelu

Gdy porównuje się dwa systemy segmentacyjne, nazwa architektury jest tylko jedną częścią procedury. Na wynik mogą wpływać odstępy, zmiana próbkowania, obsługa intensywności, rozmiar fragmentu obrazu, strategia próbkowania, augmentacja, budżet treningowy, przetwarzanie końcowe, łączenie modeli w zespoły oraz podział danych. Bardziej złożona sieć może pozornie wygrywać dzięki lepszej konfiguracji, a prosta sieć może wydawać się słaba, ponieważ skala danych wejściowych albo harmonogram treningu nie odpowiadały zbiorowi danych.

Samokonfiguracja odpowiada na to wąskie gardło inżynierskie. Zamiast wymagać od każdego użytkownika ręcznego wyboru wszystkich ustawień przetwarzania wstępnego i treningu, system samokonfigurujący może zbadać zadeklarowane właściwości zbioru danych i wyprowadzić powtarzalną procedurę. Odstępy wokseli, wymiary obrazu, proporcje klas i dostępna pamięć mogą wpływać na wybory dotyczące reprezentacji, podziału na fragmenty obrazu, konfiguracji sieci i optymalizacji. Nie jest to twierdzenie, że każdy możliwy wybór można zautomatyzować ani że jedna procedura jest optymalna dla każdego zadania. Jest to zasada: konfiguracja powinna być jawna, systematyczna i powiązana z danymi, aby nieudokumentowane ręczne dostrajanie nie stało się ukrytym źródłem przewagi.

nnU-Net jest datowanym przykładem tej zasady

Publikacja o nnU-Net z 2021 roku (PMID 33288961) jest użytecznym, datowanym przykładem tej strategii. Jej znaczenie dla tego rozdziału nie polega na trwałym twierdzeniu, że jedna implementacja zwycięży w każdym przyszłym benchmarku. Pokazuje ona, jak konwencjonalną rodzinę U-Net osadzono w szerszej procedurze, która konfiguruje przetwarzanie wstępne, reprezentację przestrzenną, trening i przetwarzanie końcowe na podstawie zbioru danych, zamiast traktować architekturę jako jedyną zmienną badawczą.

Wniosek na przyszłość ma charakter metodologiczny. Zanim obserwowaną przewagę przypisze się nowej architekturze, trzeba ustalić, czy porównanie wykorzystywało zgodne geometrie danych wejściowych, przetwarzanie wstępne, podziały danych, budżety treningowe, przetwarzanie końcowe i definicje oceny. Jeżeli implementacja oferuje opcjonalne łączenie modeli w zespoły lub inne tryby, stanowią one część porównywanego systemu. Niewielka przewaga, która nie utrzymuje się przy porównywalnych procedurach, powtarzanych dopasowaniach lub w odpowiednich warunkach testowych, jest słabym dowodem przewagi architektonicznej. Porównanie powinno zatem oceniać zamrożone, skonfigurowane procedury: przed obejrzeniem przypadków ewaluacyjnych należy zamrozić przetwarzanie wstępne, geometrię danych wejściowych, procedurę i budżet treningu, stan wyboru modelu lub procedury, łączenie modeli w zespoły, przetwarzanie końcowe oraz progowanie, jeśli ma zastosowanie. Przewaga może uzasadniać przypisanie wyniku architekturze tylko wtedy, gdy interpretuje się ją w zgodnych warunkach testowych, raportuje jej niepewność i odnosi do określonego z góry, istotnego praktycznie marginesu dla wskazanego zadania. Nie ustanawia to uniwersalnego rankingu architektury względem konfiguracji, nie istnieje też uniwersalny próg definiujący małą przewagę.

Nazwy narzędzi są datowanymi przykładami, a nie regułą inżynierską

Narzędzie do automatycznej segmentacji może dostarczać wiele masek anatomicznych, dzięki czemu wygenerowane obszary mogą być wielokrotnie wykorzystywane jako dane wejściowe do późniejszych pomiarów. Jest to ilustracja lekcji o infrastrukturze, a nie twierdzenie, że liczba struktur, obsługiwane modalności, wersja lub skuteczność konkretnego narzędzia pozostaną niezmienne. Nazwane narzędzia, informacje o wydaniach i wyniki o ograniczonym zakresie należą do datowanego internetowego materiału uzupełniającego, gdzie można je ponownie zweryfikować, zamiast opierać na nich stabilny wywód.

Konsekwencja infrastrukturalna pozostaje aktualna nawet po zmianie narzędzia. Automatyczne maski nadal wymagają kontraktu danych wejściowych, kontroli geometrii, oceny względem odniesienia lub oceny uwzględniającej zadanie oraz decyzji, które błędy są dopuszczalne na dalszym etapie. Tanie wytwarzanie masek może zwiększyć liczbę pomiarów narażonych na błąd granicy; nie czyni z wyniku modelu niepodważalnego odniesienia.

Przed przypisaniem zasługi architekturze porównuj kompletne procedury

Platforma implementacyjna może udostępniać zasoby do budowy potoków obrazowania medycznego, ale nazwa platformy nie jest wynikiem oceny. Niezależnie od tego, czy potok powstał z użyciem platformy, systemu samokonfigurującego czy własnego kodu, porównanie powinno określać kontrakt danych i każdy dopasowany albo wybrany etap. Praktyczne pytanie brzmi, czy proponowana zmiana wnosi informację lub poprawia kontrolowaną procedurę, a nie czy dodaje bardziej imponującą etykietę modelu. Nazwy obecnych platform i listy ich funkcji należą do internetowego materiału uzupełniającego, a nie do tego stabilnego twierdzenia.

Takie podejście wyznacza też właściwe miejsce obecnych narzędzi. Model lub platforma mogą być wartościowe w datowanym eksperymencie, a mimo to zostać zastąpione, przekonfigurowane lub pokonane w innym zadaniu, dla innej modalności albo przy innym podziale. Trwałym nawykiem inżynierskim jest zapewnienie audytowalności konfiguracji i testowanie całej procedury w warunkach objętych twierdzeniem. Następna część stosuje tę samą dyscyplinę o jeden etap wcześniej: do rekonstrukcji tworzącej obraz, na którym działa model.