Ile testów ciążowych potrzeba do obliczenia wyników Spisu Powszechnego?

SymulatorNSP

Wątpliwości dotyczące rzetelności Głównego Urzędu Statystycznego przy przeprowadzaniu Narodowego Spisu Powszechnego były zawsze, jednakże dopiero po jego zakończeniu, niebywała opieszałość w publikacji danych obudziła najgorsze demony teorii spiskowych. Nie ma się co dziwić, bo skala okazuje się absurdalnie powalająca, kiedy do odczuć, przeczuć i opinii dołożymy kilka twardych liczb.

Dla przypomnienia, Narodowy Spis Powszechny (NSP) 2021 zakończył się 30 września 2021. 02 grudnia 2022 GUS łaskawie obdarował opinię publiczną enigmatycznymi wynikami, informując, że ludność Polski liczyła 38,0361 mln, z czego 33,0418 mln zadeklarowało narodowość wyłącznie polską, 391 tys. wyłącznie niepolską i na dokładkę 3,7476 mln stanowi część nieustalona. Nad tą ostatnią powstało już wiele elaboratów, ale trudno się dziwić, bo ilu interpretujących tyle interpretacji. Elektrykowi skojarzyć może się to z obwodami, które znalazły się poza obszarami stabilności i zmieniają swój stan w czasie, będąc tym samym nieustalonymi. Z perspektywy fizyka można by pomyśleć o “narodowości Schroedingera”, która jest nieustalona (tzn. przyjmuje wszystkie możliwe wartości jednocześnie) do czasu kiedy obserwator na nią “spojrzy”. Zaś prezes NBP pewnie powiedziałby, że to zależy czy będzie tarcza, czy nie będzie tarczy. W końcu jak tarcza będzie to będzie rosło, a jak rośnie to spada.

Z perspektywy informatycznej, z której dziś spojrzymy na całą sytuację, optymistycznie zakładając uczciwość i apolityczność GUS, nasuwa się pytanie na jakim sprzęcie liczono te wyniki? Po niezbyt skomplikowanych obliczeniach można stwierdzić, że podanie szczątkowych danych dotyczących struktury narodowo-etnicznej zajęło 14 miesięcy, czyli 36,8064 mln sekund – prawie sekundę na klasyfikację rekordu do jakiejś, faktycznej opcji narodowościowej (np. polskiej, niemieckiej, etc.). Taki wynik byłby czymś dającym się wytłumaczyć przy ręcznym spisywaniu danych i milionach papierowych formularzy wypełnianych przez rachmistrzów w rozmowach twarzą w twarz. Spis był jednak realizowany głównie w formie internetowej, więc te dane musiały trafić do jakiejś bazy danych, a te w dzisiejszych czasach są szybkie – piekielnie szybkie. Zazwyczaj wykonując rutynowe czynności na komputerze, laptopie, smartfonie, smartwatchu, a nawet teście ciążowym, nie zdajemy sobie sprawy z faktycznej liczby koni, które drzemią pod maską. Taktowanie 4GHz (4 mld na sekundę) to już standard, który pozwala na przetwarzanie miliardów jednostek informacyjnych w ułamki sekund. Na teście ciążowym, który został wyposażony przez producenta w procesor z zegarem 4MHz [1], z powodzeniem i bez klatkowania pewien pasjonat z twittera (Foone) uruchomił otwierającą scenę gry Skyrim. Tymczasem GUS nie może dać sobie rady z bazą zawierającą 38 mln rekordów, przez 14 miesięcy.

Chęć sprawdzenia jak jest naprawdę przerodziła się w motywację do napisania prostej aplikacji, którą roboczo nazwano Symulator NSP 2021. Pierwszym krokiem było stworzenie modelu z typowymi dla osoby fizycznej informacjami (imię, nazwisko, adres, narodowość, etc.). Z braku szczegółowych, bądź choćby surowych danych z GUS populację trzeba było wylosować. Przygotowano więc generator losowy z listą dostępnych opcji i prawdopodobieństwami ich wylosowania na podstawie szczątkowych wyników z GUS (np. 33/38 dla narodowości “polskiej”). Następnie należało wygenerować populację liczącą 38 mln rekordów. Proces losowania ten zajął około minuty i ukradł ok. 7 GB RAMu z zasobów komputera. Przyszedł czas na kwerendę, która miała sprawdzić ile naprawdę zajmie proces przeanalizowania takiego zbioru w poszukiwaniu narodowości: “polska”. Nie było zaskoczeniem, że kwerenda trwała mniej niż 5 sekund na maszynie z 8-letnim procesorem Intela (i7 4790k), wyposażonej w 16 GB pamięci RAM (1333MHz). Tymczasem GUS potrzebował, przypomnijmy, 36,8064 mln sekund. Zakładając, że dla każdej narodowości konieczna jest manualna kwerenda to choćby i były setki różnych opcji, w porównaniu z domowym komputerem, wynik GUS przekracza granice absurdu.

W działaniach GUS ewidentnie brakuje transparentności. Nie może więc jej zabraknąć przy tym teście. Kod aplikacji (wraz z plikiem wykonywalnym) został udostępniony publicznie na repozytorium: github.com/skowront/SymulatorNSP2021. Każdy może sprawdzić na własnym komputerze, o ile razy szybciej zliczyłby wyniki, wyręczając GUS, gdyby tylko surowe dane były dostępne. Nie ulega wątpliwości, że niejeden przedstawiciel mniejszości narodowej lub etnicznej chętnie poświęciłby trochę mocy obliczeniowej, a w konsekwencji prądu, by poznać szczegółowe wyniki Narodowego Spisu Powszechnego 2021. Sama aplikacja doczekała się też wersji przeglądarkowej, która choć niezaskakująco wolniejsza niż klasyczny .exe, i tak przebija GUS. Tym sposobem każdy kto chciałby się przekonać o skali opóźnienia z wynikami NSP może to zrobić wchodząc na stronę symulatornsp2021.regios.org.pl i skorzystać z wersji przeglądarkowej Symulatora NSP 2021 lub tej uruchamianej bezpośrednio na komputerze po przejściu kilku prostych kroków instalacji. Wciąż mówimy jednak o aplikacjach działających na domowym sprzęcie, bazy danych, które wykorzystuje GUS najprawdopodobniej działają na potężnych, wielordzeniowych, wielowątkowych procesorach i wykorzystują wiele Gigabajtów RAMu oraz szybkie dyski SSD (Solid State Drive). Nie ma więc podstaw by sądzić, że GUS utknął na kwerendach.

Na obronę GUS-u można powiedzieć, że zbieranie i obrabianie danych, w których znajdowały się otwarte pola tekstowe, w które użytkownik mógł wpisać wszystko lub prawie wszystko, jest trudne. To jest niepodważalny fakt. Ze względu na sposób tworzenia formularzy i ich zabezpieczania informatycy uwielbiają rozwijane listy z predefiniowanymi opcjami, przełączniki typu radio box, checkbox, etc. Oczywiście nie rozwiązują one wszystkich problemów, bowiem i tak muszą zabezpieczać się przed “niestandardowymi wpisami” takimi jak “drop database *;”, usuwającymi dane w bazie SQL, które mogłyby znaleźć się na przykład w polu narodowość. Dla samej analizy sprawa również nie jest prosta. Może pojawić się literówka, a może pojawić się nieprzewidziana opcja, ale i na to są sposoby (np. Dopasowania rozmyte ciągów znakowych – ang. Fuzzy string matching). Problem klasyfikacji ciągów znakowych do istniejących kubełków nie pojawił się przecież pierwszy raz w roku 2021 podczas spisu, tylko jest obecny już od dawna. Przykładem instytucji, która poradziła sobie z tym wyzwaniem może być Wikipedia, która potrafi ocenić, że po wpisaniu losowych liter jak “kagf” ma nam zaproponować Kafr Quasim (miasto w Izraelu), a gdy w wyszukiwarce pojawia się “kmgf” zostanie nam zaproponowane utworzenie nowego artykułu (kubełka), bo nie istnieje żaden dość podobny. Są oczywiście algorytmy mniej i bardziej dokładne, mniej i bardziej zasobożerne, ale w XXI wieku nie jest to czarna magia, tylko norma.

Idąc za literówkami, Symulator NSP 2021 wyposażono również w możliwość symulowania losowo przekręconych znaków, by pokazać, że nawet jeśli skorzystamy z pomocy algorytmów, które analizują każdy rekord dodając pewną tolerancję na błąd, ale dzięki temu klasyfikują go do istniejącego kubełka, to z wyścigu domowy komputer i tak wyjdzie zwycięsko. Zaimplementowano więc dwa algorytmy obliczające odległość edycyjną pomiędzy parą wyrazów. Algorytm Hamminga oraz algorytm Levenshteina. Choć mogą brzmieć groźnie to realizują dość proste zadanie. Ten pierwszy oblicza liczbę różnych znaków dla dwóch ciągów znakowych tej samej długości, która staje się odległością edycyjną. Na przykład w odległość edycyjna słowa “pxlska” od “polska” z wykorzystaniem algorytmu Hamminga wyniesie 1. Algorytm Levenshteina bierze pod uwagę minimalną liczbę zmian, które trzeba wykonać aby pierwsze słowo zamienić w drugie. Tym sposobem odległość między “polska”, a “pxlsk” wyniesie 2, dla “pols” i “polska” również 2, a dla “polska” i “śląska” wyniesie 3. Ustawiając odpowiedni próg tolerancji (przyjęto 2) udało się uzyskać klasyfikację niektórych rekordów z literówkami do istniejących opcji, tym samym automatyzując część procesu i zachowując czas analizy 38 mln rekordów, w okolicy 6 sekund (w wersji .exe aplikacji). Upraszczając nieco, bo zależność taktowania od mocy obliczeniowej nie jest w stosunku 1:1, dochodzimy do wniosku, że proces analogicznej analizy rekordów trwałby ok. 1000 razy dłużej na wspomnianym wcześniej teście ciążowym. Niestety, dla GUS, byłoby to i tak tysiące razy szybciej niż okres jaki musieliśmy czekać na cząstkowe wyniki. W meczu test ciążowy – GUS 1:0.

Skoro wiemy już, że przetwarzanie danych nie jest problemem, wymagającym 14 miesięcy, co udowodniła też Republika Czeska sprawnie radząc sobie z wynikami spisu po tamtej stronie granicy, pozostaje ponowić zasadne pytanie: Co jest rzeczywistą przyczyną takiego opóźnienia? Najlepsza odpowiedź jaką można podać na ten moment to niestety fakt, że przyczyna jest nieustalona. Tymczasem odpowiedź na, jak się okazuje prostsze pytanie: Ile testów ciążowych potrzeba do obliczenia wyników Spisu Powszechnego? brzmi: “Mniej niż GUSów”.

[1] https://www.theverge.com/tldr/2020/9/4/21422628/digital-pregnancy-test-teardown-processor-ram-ibm-pc?fbclid=IwAR3eA0y1aTIcNHmdnaaAUK_5_gz_zhwV84Zcthy7DHdolPxvL0PxpF1BDiI

Tags:

Brak komentarzy

Dodaj komentarz