Gdy dwie niezależne ścieżki weryfikacji mylą się tak samo - studium przypadku

👁 144 przeczytań

Artykuł Fabio Rovaia, przyjęty na warsztat AI for Science podczas NeurIPS 2026, dotyczy konkretnego błędu w potoku danych porównującym dwa otwarte rejestry obiektów krążących wokół Ziemi. Autor opisuje mechanizm awarii, którą określa mianem „common-mode failure” - błędu wspólnego trybu.

Czym jest podwójna weryfikacja i dlaczego tym razem nie zadziałała

Standardowym zabezpieczeniem w potokach danych jest redundantne obliczanie: każdą publikowaną liczbę wyznacza się dwiema różnymi metodami opartymi na różnych technologiach, a jeśli wyniki się różnią, potok zatrzymuje się. W opisywanym przypadku jedna ścieżka korzystała z Pythona i operacji na zbiorach, druga - z zapytań SPARQL do grafu RDF. Brama porównująca oba wyniki wydrukowała komunikat ALL CROSS-CHECKS AGREE dla siedmiu sprawdzanych wartości. Trzy z nich były błędne. Jedna z błędnych wartości była zawyżona ponad czterokrotnie: potok zwrócił 932 zamiast prawidłowego 220.

Dlaczego weryfikacja tego nie wykryła? Obie ścieżki importowały te same stałe, w których zakodowane było błędne odczytanie słownika statusów ze źródłowego dokumentu. Skoro błąd był identyczny w obu ścieżkach, brama porównująca wyniki nie miała szans go zauważyć - oba wyniki były tak samo błędne, więc wzajemnie sobie „potwierdzały” poprawność.

Korekta też była błędna

Autor sprawdził następnie poprawiony kod pod kątem historii faz każdego obiektu, przechowywanej w pliku źródłowym, którego potok nigdy nie czytał. Okazało się, że korekta również zawierała błędy: 42 spośród 261 niezgodności to artefakty. Żaden z trzech opisanych przez Rovaia testów kontrolnych nie wykrył tych artefaktów.

Eksperyment z modelami językowymi

Autor przeprowadził kontrolowaną replikację z udziałem trzech modeli językowych przy wyłączonych dodatkowych narzędziach. Na żądanie generowania niezależnych ścieżek weryfikacji: 72 z 75 wygenerowanych ścieżek obliczyło tę samą błędną wartość co oryginalny defekt. Co istotne, 29 z 30 ścieżek obliczało błędną wartość nawet wtedy, gdy prompt zawierał definicje kodów statusów z dokumentacji samego źródła. Rovai nie wyciąga z tego szerszych wniosków wykraczających poza opisywany przypadek - wprost zaznacza, że dowody dotyczą jednego potoku i jednej rodziny defektów.

Wniosek z dokumentu

Autor formułuje to następująco: redundancja zweryfikowała implementację, a błędy, które dotarły do publikacji, były błędami znaczenia. Potok sprawdzał, czy obie ścieżki dają ten sam wynik - i tak było. Nie sprawdzał, czy wspólne założenia, na których obie ścieżki się opierały, są poprawne. Rovai dostarcza mechanizm błędu, szczegółowy rejestr na poziomie obiektów uzgadniający każdą liczbę, oraz trzy testy wracające do dokumentacji źródłowej, zmierzone zarówno na wadliwym kodzie, jak i na jego korekcie. Kod, prompty, surowe wyniki modeli i zapisy poszczególnych prób są dostępne publicznie pod adresem wskazanym w artykule.

Czytasz Promptowego częściej? Dodaj go do preferowanych źródeł w Google, a nowe teksty będą wyżej w Twoich wynikach.

Co z tego wynika

To studium przypadku uderza w założenie, które wielu inżynierów traktuje jako oczywiste: że dwie różne techniczne implementacje tej samej logiki dają niezależność weryfikacji. Rovai pokazuje, że niezależność techniczna nie oznacza niezależności semantycznej - jeśli błąd leży w rozumieniu danych wejściowych, a nie w kodzie, żadna liczba równoległych ścieżek go nie wykryje. Wynik eksperymentu z modelami językowymi - 72 z 75 ścieżek powtórzyło ten sam błąd, nawet z definicjami w prompcie - sugeruje, że modele mogą wzmacniać tego rodzaju błędy wspólnego trybu zamiast je wychwytywać. Sam autor zastrzega jednak, że to jeden przypadek i jedna rodzina defektów, więc nie należy ekstrapolować zbyt daleko.

Źródło: arXiv cs.AI: Independent Verification Paths Are Not Independent: A Case Study of Common-Mode Failure in a Satellite Catalogue Pipeline (dokument z 2026-09-30). To omówienie powstało na podstawie pełnego tekstu dokumentu, nie relacji innych mediów.