Wanneer dubbele verificatie faalt: common-mode failure
Een studie toont aan hoe twee onafhankelijke verificatiepaden dezelfde fout kunnen maken. Zelfs AI-modellen reproduceerden de fout in 72 van 75 gevallen.
👁 117 keer gelezen
Een artikel van Fabio Rovai, geaccepteerd voor de AI for Science workshop tijdens NeurIPS 2026, beschrijft een specifieke fout in een datapipeline die twee open registers van objecten in een baan om de aarde vergelijkt. De auteur beschrijft het faalpatroon dat hij “common-mode failure” noemt - een fout in de gemeenschappelijke modus.
Wat is dubbele verificatie en waarom faalde het
Een standaard beveiligingsmaatregel in datapipelines is redundante berekening: elk gepubliceerd getal wordt met twee verschillende methoden bepaald, gebaseerd op verschillende technologieën. Als de resultaten verschillen, stopt de pipeline. In dit geval gebruikte het ene pad Python en set-operaties, het andere SPARQL-queries op een RDF-graph. De vergelijkingspoort printte de melding ALL CROSS-CHECKS AGREE voor zeven gecontroleerde waarden. Drie daarvan waren fout. Een van de foute waarden was meer dan vier keer te hoog: de pipeline gaf 932 in plaats van de correcte 220.
Waarom detecteerde de verificatie dit niet? Beide paden importeerden dezelfde constanten, waarin een foutieve interpretatie van het statuswoordenboek uit het brondocument was gecodeerd. Omdat de fout identiek was in beide paden, had de vergelijkingspoort geen kans om het te merken - beide resultaten waren op dezelfde manier fout, dus “bevestigden” ze elkaars correctheid.
Ook de correctie bevatte fouten
De auteur controleerde vervolgens de gecorrigeerde code aan de hand van de fasegeschiedenis van elk object, opgeslagen in een bronbestand dat de pipeline nooit las. Het bleek dat ook de correctie fouten bevatte: 42 van de 261 discrepanties waren artefacten. Geen van de drie door Rovai beschreven controletests detecteerde deze artefacten.
Experiment met taalmodellen
De auteur voerde een gecontroleerde replicatie uit met drie taalmodellen, waarbij extra tools waren uitgeschakeld. Op verzoek om onafhankelijke verificatiepaden te genereren: 72 van de 75 gegenereerde paden berekenden dezelfde foute waarde als het oorspronkelijke defect. Belangrijk: 29 van de 30 paden berekenden de foute waarde zelfs wanneer de prompt de definities van statuscodes uit de documentatie van de bron zelf bevatte. Rovai trekt hieruit geen bredere conclusies die verder gaan dan het beschreven geval - hij benadrukt expliciet dat het bewijs betrekking heeft op één pipeline en één familie van defecten.
Conclusie uit het document
De auteur formuleert het als volgt: redundantie verificeerde de implementatie, en de fouten die de publicatie bereikten waren fouten in betekenis. De pipeline controleerde of beide paden hetzelfde resultaat gaven - en dat was zo. Hij controleerde niet of de gemeenschappelijke aannames waarop beide paden waren gebaseerd correct waren. Rovai levert het faalmechanisme, een gedetailleerd register op objectniveau dat elk getal verantwoordt, en drie tests die teruggaan naar de brondocumentatie, gemeten op zowel de defecte code als op de correctie. Code, prompts, ruwe modelresultaten en logs van individuele runs zijn publiekelijk beschikbaar op het in het artikel genoemde adres.
Google · Jouw bronnenHoger in Google - met één klikToevoegen aan voorkeursbronnen →Wat dit betekent
Deze case study ondermijnt een aanname die veel ingenieurs als vanzelfsprekend beschouwen: dat twee verschillende technische implementaties van dezelfde logica onafhankelijke verificatie opleveren. Rovai toont aan dat technische onafhankelijkheid geen semantische onafhankelijkheid betekent - als de fout ligt in het begrip van de invoergegevens en niet in de code, zal geen enkel aantal parallelle paden het detecteren. Het resultaat van het experiment met taalmodellen - 72 van de 75 paden reproduceerden dezelfde fout, zelfs met definities in de prompt - suggereert dat modellen dit soort common-mode failures kunnen versterken in plaats van ze op te vangen. De auteur zelf benadrukt echter dat dit één geval en één familie van defecten betreft, dus men moet niet te ver extrapoleren.
Bron: arXiv cs.AI: Independent Verification Paths Are Not Independent: A Case Study of Common-Mode Failure in a Satellite Catalogue Pipeline (document van 30-09-2026). Deze bespreking is gebaseerd op de volledige tekst van het document, niet op verslagen van andere media.
More on this from HELDER
benchmarks·YouTube thumbnails met AI: leesbaarheidstest op 320 pixelsZes thumbnails gegenereerd en getest op 320 pixels breedte. Drie zeer goed, drie goed, en drie praktische conclusies over wat werkt en wat niet.