Skąd się to wzięło?

Wakacje 2026. Fala upałów, jakiej Warszawa nie pamięta od lat. W dzień nie da się pracować w ogóle a wieczory poświęca się na rozrywkę, czyli zadania, o których nie wiadomo, czy kiedykolwiek przyniosą komuś jakikolwiek pożytek. Szczególnie w badaniach, w których od dłuższego już czasu jakość danych zdaje się mieć coraz mniejsze znaczenie.

Bezpośrednim impulsem powstania programu był widok, którego żaden metodolog nie powinien oglądać bez uprzedniego psychicznego przygotowania: studenci wprowadzający dane ankietowe wprost do komórek popularnego programu biurowego bądź też nieznacznie od nich sprytniejsi — choć wciąż niewystarczająco — przepisujący je ręcznie do internetowego formularza. Rozwiązanie drugie, wprawdzie odrobinę lepsze, pozostaje niemal tym samym generatorem błędu, tyle że w nowym opakowaniu, do którego dołączono bonus w postaci znacząco wydłużonego czasu pracy. Czasu, który znacznie rozsądniej można byłoby przeznaczyć na właściwą walidację danych zamiast na ich bezrefleksyjne przepisywanie.

Ktoś mógłby w tym miejscu słusznie zauważyć, że programy do wprowadzania danych istnieją od dawna i mają swoją własną, niekiedy szacowną historię. To prawda. Wśród rozwiązań krajowych wspomnieć można choćby legendarne WD (nie mylić ze smarem do łańcuchów rowerowych, choć na łańcuchy danych działał właśnie jak smar do roweru) przygotowane przez Wojciecha Niepokojczyckiego dla LUTAY H. C. Zbigniewa Sawińskiego, znanego z olbrzymiego wkładu w rozwój przetwarzania danych sondażowych (i nie tylko!), czy późniejszy, odwołujący się do legendy WD, windowsowy DGS od YAC Software. Oprócz rozmaitych udogodnień zachowywał on zresztą wsteczną zgodność ze składnią języka WD co lokowało go w gronie bezpośredniego następcy i kontynuatora chlubnej tradycji. Na obu tych programach pracowano w swoim czasie chyba w większości agencji badawczych w Polsce. Niektóre z ograniczeń, jak przykładowo uproszczona jednowarunkowa składnia i nakładane lejkowe filtry ograniczające możliwość zaawansowanego routingu zostały wyeliminowane w kolejnych wersjach rozwojowych Punchera produkcji URUSoft, za pomocą którego wczytano przykładowo wszystkie edycje Polskiego Generalnego Sondażu Społecznego od 2005 roku włącznie.

Oddzielną kategorią programów do wprowadzania danych są narzędzia potężne, lecz na tyle złożone, że opanowanie ich własnego języka i struktury pochłania więcej czasu, niż można później zaoszczędzić dzięki ich użyciu. W prostych projektach czyni to je narzędziami porównywalnymi z młotem pneumatycznym używanym do wbijania pinezki: technicznie skutecznymi, praktycznie niewspółmiernymi do zadania. Studenci radzą sobie więc dość racjonalnie, szczególnie że darmowych narzędzi do wprowadzania danych współcześnie wcale nie ma na rynku aż tak wiele bo większość z nich zniknęła pozostawiając po sobie miłe wspomnienie. Narzędzie DE jest odpowiedzią na tę lukę — to darmowy (dla studentów), prosty program do wprowadzania danych z papierowych formularzy zbliżony do rozwiązań istniejących lecz wzbogacony o rozwiązania sprzyjające efektywności pracy.

W tym samym czasie, gdy rodził się pomysł DE, przyjaciółka z GESIS (Leibniz-Institute für Sozialwissenschaften), Petra Brien, pracująca w Department of Survey Data Curation, kontrolując dane z polskiej edycji badania ISSP Digital Societies, zgłosiła mi obserwację godną samego Holmesa: dwa rekordy w polskim zbiorze wyglądają na niemal identyczne, a jednak stopień ich podobieństwa nieznacznie nie sięga progu, przy którym opracowany przez GESIS DSDC skrypt do diagnostyki duplikatów uznałby je za takie. Narzędzie GESIS wykrywa duplikaty o podobieństwie 100% oraz podobne rekordy (near-duplicates) powyżej progu 96% (z wyłączeniem zmiennych metryczkowych). Sprawą duplikatów rekordów w ISSP GESIS zajmuje się zresztą już od 2014 roku. Szeroka dyskusja w Komitecie Metodologicznym ISSP, przeprowadzona podczas Walnego Zgromadzenia w Guadalajarze w 2018 roku, podjęta między innymi wskutek ustaleń raportu przedłożonego przez Archiwum GESIS autorstwa Insy Bechert, Petry Brien i Marcusa Quandta wraz z rekomendacjami zaowocowała dołączeniem do analiz duplikatów również analizy bliskiego podobieństwa (near-duplicates), zgodnie z metodologią opracowaną przez Kuriakose i Robinsa po jej adaptacji do struktury zbiorów ISSP. Jednocześnie krajowych PI zobligowano wówczas do przeprowadzania samodzielnie właściwych testów, co dokumentowane jest w Raportach Technicznych (dawniej SMQ – Study Monitoring Questionnaire), opisujących kontekst metodologiczno-wykonawczy badań krajowych. Narzędzia GESIS, o czym warto wspomnieć, znakomicie spełniają swoje zadanie po dziś dzień.

Głębsza refleksja nad problemem nieuchronnie prowadziła mnie jednak do wniosku, że na zjawisko duplikatów w bazach danych można patrzeć na co najmniej dwa sposoby. Pierwszy ma charakter graniczny: wyznacza się — w istocie arbitralnie — próg, powyżej którego dwa dostatecznie podobne do siebie rekordy zostają uznane za duplikaty. Takie założenie zgodne jest z logiką audytu, w którym granica pozwalająca na pozytywną bądź negatywną kwalifikację musi zostać określona. Drugie spojrzenie, moim zdaniem bardziej realistyczne ale i ważniejsze z perspektywy kontroli jakości danych, a oparte na metodologii Kuriakose i Robinsa, akcentującej stopień podobieństwa, zakłada, że jest ono zarazem miarą redundancji informacji, którą owe rekordy — a szerzej: dane — ze sobą niosą. Im bardziej dwa rekordy są do siebie podobne, tym mniej nowej informacji wnosi drugi z nich w stosunku do pierwszego. Jeśli tak, stopień owego podobieństwa warto wyrażać raczej na skali ciągłej, zamiast ograniczać się do punktowego wskazania wartości, powyżej lub poniżej której podobieństwo jest bądź przestaje być akceptowane.

Przełożenie powyższego na obserwację Petry okazało dla mnie kosztowniejsze, niż sądziłem — reszta wieczoru upłynęła na rozmyślaniu, w jaki sposób można byłoby rozwiązać problem tak, aby oprócz wyznaczania granicznej wartości akceptacji danych, zgodnie choćby z wymaganiami metodologicznymi programu ISSP, narzędzie umożliwiało możliwie szeroki i elastyczny ogląd całego zbioru oraz jego dowolnych fragmentów, między innymi pod względem podobieństwa rekordów.

Elastyczność ta dawałaby co najmniej dwie możliwości metodologicznej oceny jakości danych. Po pierwsze, pozwalałaby identyfikować te fragmenty kwestionariusza, które są najsłabsze pod względem niesionej wartości informacyjnej. Po drugie, umożliwiałaby wykrywanie rekordów podobnych (near-duplicates), elastycznie traktując jednocześnie strukturę samego zbioru, co do pewnego stopnia czyni już narzędzie wytworzone przez GESIS a oparte na module zewnętrznym Staty autorstwa samego Kuriakose (2015).

Z tej właśnie drobnej refleksji zrodził się zamysł znacznie ambitniejszy niż samo tropienie duplikatów. Skoro można diagnozować podejrzane pary rekordów, można również zacząć badać same wzorce odpowiedzi — zwłaszcza w bateriach pytań mierzonych na identycznych skalach. Nie jest to oczywiście nic nowego, choć w kontekście oceny wartości informacyjnej danych rzadko bywa używane. Po drodze do zestawu dołączono kolejne parametry diagnostyczne, które przydały się nie tylko do wyłapywania anomalii, lecz również do zwyczajnej analizy danych.

Zamysł ten urósł ostatecznie do rangi osobnego podprojektu: Audit 2.0 — modułu zdolnego analizować również dane pochodzące skądinąd, niekoniecznie wprowadzone bezpośrednio przy użyciu programu, choć to nadal pozostaje jego głównym powołaniem. Tak oto z DE narodził się DEVS: to samo narzędzie, tyle że wzbogacone o funkcje diagnostyczno-kontrolne służące ocenie jakości danych — również tej mniej oczywistej, związanej z ich wartością informacyjną. Wątek ten będzie kontynuowany i znacząco rozszerzony w kolejnych narzędziach, w szczególności w planowanym Project S: QA. Tak narodził się też Project S:, pod którego parasolem wytworzone zostały oba narzędzia, a planowanych jest co najmniej kilka następnych, wszystkie skupione wokół zagadnień związanych z kolejnymi wymiarami badania jakości danych.

Duch przodka

Podobna myśl nawiedziła autora nie po raz pierwszy. W roku 2002, wspólnie z dr. Tomaszem Jerzyńskim, stworzyliśmy Validator 1.0 — program wykorzystany w Polskim Generalnym Sondażu Społecznym 2002, którego głównym zadaniem było przeprowadzanie zaawansowanej kontroli logicznej zbioru danych oraz walidacji samego kwestionariusza względem reguł przejścia i przeskoku ale również kontroli zaawansowanej zmiennych niezwiązanych logiką samego narzędzia. Nie było to zresztą zadanie proste, bo znacząca ich część wyrażona była w postaci opisowych instrukcji dla ankietera, interpretowanych in situ. Były to jednak czasy, gdy narzędzia miały formę papierową, znacznie bardziej elastyczną niż zalgorytmizowane skrypty CAPI czy MOBI. Praca z nimi wymagała też od ankieterów znacznie lepszego przygotowania zawodowego, niż ma to miejsce obecnie. Reguły sterujące przebiegiem wywiadu trzeba było więc najpierw odtworzyć mając na uwadze logikę nie tylko wywiadu ale również respondenta a nawet i samego ankietera. Piękne czasy gdy badania, wskutek swej pozornej algorytmicznej niedoskonałości wymuszały rozumienie sytuacji wywiadu odeszły niestety w niepamięć ustępując bezdusznym skryptom i automatyzacji, tracąc jednocześnie istotę tego, o co w nich przecież chodzi.

Próby uczynienia z Validatora 1.0 narzędzia bardziej uniwersalnego zakończyły się jednak fiaskiem godnym osobnej książki. Przy adaptacji do edycji PGSS z 2005 roku okazało się, że oparcie programu na sztywnym, statycznym kodzie było błędem strategicznym — każda kolejna, nawet drobna zmiana w strukturze kwestionariusza pochłaniała więcej wysiłku dostosowania programu, niż ten był w stanie później oddać w postaci oszczędności pracy. Te same cele można było osiągnąć szybciej i skuteczniej zupełnie inną drogą. Program odszedł zatem w spokojne zapomnienie, nie doczekawszy się następcy w postaci kolejnej edycji.

Sam pomysł — połączenie automatycznej walidacji z samym aktem wprowadzania danych — był jednak trafny i w 2002 roku sprawdził się znakomicie. Dowodzi to, że dobre idee potrafią przetrwać nawet porażkę narzędzia, które je ucieleśniało.

DEVS wraz z modułem Audit 2.0 jest zatem, w pewnym sensie, wnukiem Validatora: tą samą ideą, tym razem jednak zbudowaną na zupełnie odmiennej filozofii niż dwie dekady wcześniej i wzbogaconą o co najmniej kilkadziesiąt innych funkcji, o których, tworząc Validatora ponad dwadzieścia lat temu, autorzy nawet nie pomyśleli.

A co z owymi dwoma rekordami?

Tu historia serwuje czytelnikowi swój najbardziej przewrotny zwrot akcji: przypadki zgłoszone przez Petrę zostały ostatecznie usunięte ze zbioru ISSP Digital Societies — jednak wcale nie z powodu domniemanej duplikacji. Dalsza analiza ujawniła zupełnie inne usterki jakościowe.

Niepokojące, choć niewystarczające podobieństwo okazało się sygnałem alarmowym — fałszywym tropem, który mimo wszystko doprowadził do właściwego sprawcy całego zamieszania. Mechanizm zadziałał więc bez zarzutu, tyle że nie w sposób, którego ktokolwiek się spodziewał, co, jak się zdaje, stanowi najlepszy możliwy początek biografii narzędzia stworzonego do wykrywania anomalii. Dane z badania, w tym również części polskiej, pobrać można ze strony https://doi.org/10.4232/5.ZA10020.1.0.0 (ISSP Research Group, 2026. International Social Survey Programme: Digital Societies I - ISSP 2024. ZA10020; Version 1.0.0. GESIS, Cologne), oczywiście pozbawione dwóch, wadliwych rekordów, od których wszystko się zaczęło.

Marcin W. Zieliński
Lato 2026