Common-Mode Failure: Wenn zwei Prüfpfade denselben Fehler machen

👁 114 Aufrufe

Ein Artikel von Fabio Rovai, angenommen für den AI for Science Workshop auf der NeurIPS 2026, beschreibt einen konkreten Fehler in einer Datenpipeline, die zwei offene Register von Objekten im Erdorbit vergleicht. Der Autor analysiert den Mechanismus eines sogenannten „Common-Mode Failure“ - eines Fehlers im gemeinsamen Modus.

Was ist doppelte Verifikation und warum hat sie diesmal versagt

Eine Standardabsicherung in Datenpipelines ist redundante Berechnung: Jede zu veröffentlichende Zahl wird mit zwei unterschiedlichen Methoden auf Basis verschiedener Technologien ermittelt. Weichen die Ergebnisse voneinander ab, stoppt die Pipeline. Im beschriebenen Fall nutzte ein Pfad Python und Mengenoperationen, der andere SPARQL-Abfragen auf einem RDF-Graphen. Das Vergleichsmodul gab für sieben geprüfte Werte die Meldung ALL CROSS-CHECKS AGREE aus. Drei davon waren fehlerhaft. Einer der falschen Werte war um mehr als das Vierfache zu hoch: Die Pipeline lieferte 932 statt der korrekten 220.

Warum hat die Verifikation das nicht erkannt? Beide Pfade importierten dieselben Konstanten, in denen eine fehlerhafte Interpretation des Status-Wörterbuchs aus dem Quelldokument kodiert war. Da der Fehler in beiden Pfaden identisch war, hatte das Vergleichsmodul keine Chance, ihn zu bemerken - beide Ergebnisse waren auf dieselbe Weise falsch und „bestätigten“ sich gegenseitig die Korrektheit.

Auch die Korrektur war fehlerhaft

Der Autor prüfte anschließend den korrigierten Code anhand der Phasenhistorie jedes Objekts, die in einer Quelldatei gespeichert war, welche die Pipeline nie ausgelesen hatte. Es stellte sich heraus, dass auch die Korrektur Fehler enthielt: 42 von 261 Diskrepanzen waren Artefakte. Keiner der drei von Rovai beschriebenen Kontrolltests erkannte diese Artefakte.

Experiment mit Sprachmodellen

Der Autor führte eine kontrollierte Replikation mit drei Sprachmodellen bei deaktivierten zusätzlichen Werkzeugen durch. Auf die Aufforderung, unabhängige Verifikationspfade zu generieren: 72 von 75 generierten Pfaden berechneten denselben fehlerhaften Wert wie der ursprüngliche Defekt. Bemerkenswert: 29 von 30 Pfaden berechneten den falschen Wert selbst dann, wenn der Prompt die Definitionen der Statuscodes aus der Dokumentation der Quelle selbst enthielt. Rovai zieht daraus keine weitergehenden Schlüsse über den beschriebenen Fall hinaus - er betont ausdrücklich, dass die Belege eine Pipeline und eine Fehlerklasse betreffen.

Schlussfolgerung aus dem Dokument

Der Autor formuliert es so: Die Redundanz verifizierte die Implementierung, während die Fehler, die bis zur Veröffentlichung gelangten, Fehler der Bedeutung waren. Die Pipeline prüfte, ob beide Pfade dasselbe Ergebnis liefern - und das taten sie. Sie prüfte nicht, ob die gemeinsamen Annahmen, auf denen beide Pfade basierten, korrekt waren. Rovai liefert den Fehlermechanismus, ein detailliertes Objektregister, das jede Zahl abgleicht, sowie drei Tests, die auf die Quelldokumentation zurückgreifen und sowohl am fehlerhaften Code als auch an dessen Korrektur gemessen wurden. Code, Prompts, Rohausgaben der Modelle und Aufzeichnungen einzelner Versuche sind unter der im Artikel angegebenen Adresse öffentlich verfügbar.

Was bedeutet das für die Praxis

Diese Fallstudie stellt eine Annahme infrage, die viele Ingenieure als selbstverständlich betrachten: dass zwei unterschiedliche technische Implementierungen derselben Logik Verifikationsunabhängigkeit bieten. Rovai zeigt, dass technische Unabhängigkeit nicht semantische Unabhängigkeit bedeutet - wenn der Fehler im Verständnis der Eingangsdaten liegt und nicht im Code, wird ihn keine Anzahl paralleler Pfade erkennen. Das Ergebnis des Experiments mit Sprachmodellen - 72 von 75 Pfaden wiederholten denselben Fehler, selbst mit Definitionen im Prompt - legt nahe, dass Modelle solche Common-Mode Failures verstärken können, statt sie aufzudecken. Der Autor selbst schränkt jedoch ein, dass es sich um einen Fall und eine Fehlerklasse handelt, weshalb man nicht zu weit extrapolieren sollte.

Quelle: arXiv cs.AI: Independent Verification Paths Are Not Independent: A Case Study of Common-Mode Failure in a Satellite Catalogue Pipeline (Dokument vom 30.09.2026). Diese Besprechung basiert auf dem vollständigen Text des Dokuments, nicht auf Berichten anderer Medien.

// weiterlesenEine Uhr, die den Kern der Zeit misst: Wie Thorium-229 das Unsichtbare sichtbar machen sollWeltraumWenn der Klimaretter untergeht: Warum steigende Meere Mangroven zu Kohlenstoffquellen machenKlimaEin Wachstums-Chart fürs Gehirn: Wie 54.583 MRT-Scans den Verlauf von Alzheimer und Schizophrenie sichtbar machenMedizin

Kinetyra