🤖 machine learning

From Failure to Alignment: A Requirements Engineering Framework for Machine Learning Systems

Dit artikel stelt REAL voor, een modelgebaseerd Requirements Engineering-framework dat data-, model- en systeemvereisten integreert en gebruikmaakt van foutanalyse en iteratieve verfijning om ervoor te zorgen dat machine learning-systemen overeenstemmen met de behoeften van belanghebbenden en betrouwbaar zijn.

Oorspronkelijke auteurs: Amel Bennaceur, Gopi Krishnan Rajbahadur, Prince Mercy, Bashar Nuseibeh, Faeq Alrimawi

Gepubliceerd 2026-07-01

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Amel Bennaceur, Gopi Krishnan Rajbahadur, Prince Mercy, Bashar Nuseibeh, Faeq Alrimawi

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een robot leert om een auto te besturen. Je zegt tegen de robot: "Rijd nooit tegen een voetganger aan." Simpel, toch? Maar in de echte wereld wordt het rommelig. De robot kan er niet bij zien een klein kind in de regen, of hij remt te hard voor een plastic zak die over de weg waait.

Dit artikel, getiteld "From Failure to Alignment," introduceert een nieuwe manier om deze slimme systemen te bouwen. De auteurs noemen hun methode REAL (Requirements Engineering for mAchines that Learn - and Fail).

Hier is de kern van het idee, uitgelegd met eenvoudige analogieën:

1. Het Probleem: De "Perfecte Wereld" Valstrik

Traditionele software is als een recept: als je de stappen precies volgt, krijg je elke keer hetzelfde gebakje. Machine Learning (ML) is anders. Het is meer als het leren aan een hond om te apporteren. Je laat de hond een bal zien, en hij leert te apporteren. Maar als je een stok, een frisbee of een schoen gooit, kan de hond in de war raken.

De auteurs stellen dat wanneer we deze "lerende" systemen boulen, we vaak aannemen dat de wereld er precies zo uit zal zien als de trainingsdata. Maar de echte wereld zit vol verrassingen (mist, vreemde kleding, kleine kinderen). Wanneer het systeem faalt, proberen ingenieurs meestal gewoon "de bug te reparen." De auteurs zeggen: Stop met het behandelen van falen als een bug. Behandel het als een aanwijzing.

2. De Oplossing: Het REAL-framework

Het REAL-framework is een driestapslus die "falen" omzet in "betere instructies." Denk aan het als een detectiveverhaal waarbij de fout de plaats delict is, en het doel is om te achterhalen welke regel ontbrak.

Stap 1: Op zoek naar de "Wat als"-scenario's (Scenario Exploration)

In plaats van de auto alleen te testen op een zonnige dag, gebruikt het framework een "grammatica" (een set regels) om automatisch duizenden vreemde, lastige of zeldzame situaties te genereren.

Analogie: Stel je een level-generator voor een videogame voor die miljoenen verschillende weersomstandigheden, voetganger-groottes en oversteekhoeken creëert. Het zoekt specif으로 naar de momenten waarop de auto bijna een ongeluk krijgt of iemand mist.
Het Doel: Het vinden van de "geldige fouten" – situaties die realistisch zijn, maar waar het systeem de fout in ging.

Stap 2: De "Waarom"-onderzoek (Obstacle Analysis)

Zodra een fout is gevonden, vra-agt het framework: Waarom gebeurde dit? Het zegt niet alleen "de sensor faalde." Het koppelt de fout terug aan de oorspronkelijke regels.

Analogie: Als de auto een klein kind mist, zegt het framework niet alleen "fix de camera." Het realiseert zich dat de oorspronkelijke regel was: "Zie alle voetgangers." De fout onthult een verborgen aanname: "We namen aan dat alle voetgangers groot genoeg zijn om gemakkelijk gezien te worden."
Het Resultaat: De fout wordt geherclassificeerd als een Obstakel. Het is alsoer je een bordje op een kaart zet met de tekst: "Hier klopt onze huidige kaart niet."

Stap 3: De Meerlaagse Reparatie (Mitigation)

Nu we weten wat er mis is, lossen we het op. Maar de auteurs zeggen dat je niet zomaar één ding kunt repareren; je moet naar vier verschillende lagen kijken, zoals het repareren van een huis:

Data-laag (De Ingrediënten): Misschien heeft de robot tijdens de training nooit een kind in de regen gezien. Oplossing: Laat het meer foto's zien van kinderen in de regen.
Model-laag (Het Brein): Misschien is het "brein" van de robot te traag of te verward. Oplossing: Verander de wiskunde binnenin het brein om carefuller te zijn.
Systeem-laag (Het Lichaam): Misschien is het brein traag, dus de auto heeft een back-up plan nodig. Oplossing: Voeg een regel toe die zegt: "Als je niet 100% zeker bent, vertraag dan rustig."
Requirement-laag (Het Contract): Misschien was de oorspronkelijke regel onmogelijk. Oplossing: Geef toe dat de auto niet kan rijden in dikke mist en update de regel naar: "Rijd niet in mist."

3. De Test in de Praktijk: De Remmende Auto

Om te bewijzen dat dit werkt, testten de auteurs REAL op een autonoom remsysteem (een auto die stopt voor voetgangers).

De Opstelling: Ze gebruikten een simulator (een videogame-wereld) om scenario's te creëren met kinderen, volwassenen, mist en verschillende soorten kleding.
De Ontdekking: Het systeem bleef kleine kinderen missen, vooral in slecht weer.
Het REAL-proces:
- Ze vonden de fout (het missen van het kind).
- Ze identificeerden het obstakel (het systeem hield geen rekening met "kleine omvang" en "laag zicht").
- Ze pasten oplossingen toe: Ze voegden meer trainingsdata van kinderen toe, pasten de betrouwbaarheidsdrempels van de auto aan en verduidelijkten de regels over wanneer de auto mag rijden.
Het Resultaat: Door deze lus te gebruiken, verminderden ze het aantal gemiste kinderen van 100% (in de slechtste gevallen) naar 8%, en maakten ze de regels voor de auto veel duidelijker.

De Belangrijkste Conclusie

Het artikel beweert dat falen niet het einde van de weg is; het is de kaart.

In plaats van te proberen een perfect systeem te bouwen dat nooit faalt (wat onmogelijk is), gebruikt het REAL-framework falen om het "contract" van het systeem met de echte wereld constant bij te werken. Het legt de verbanden tussen:

Wat mensen willen (Veiligheid).
Hoe de wereld echt is (Mist, kleine kinderen).
Wat de computer daadwerkelijk doet (Dingen missen).

Door falen te gebruiken als een diagnostisch hulpmiddel, helpt het framework ingenieurs om systemen te bouwen die eerlijk zijn over hun beperkingen en veiliger zijn in de echte wereld.

Wat het artikel NIET claimt:

Het claimt niet dat dit elk probleem in AI oplost.
Het claimt niet dat dit perfect werkt voor alle soorten AI (zoals chatbots of medische diagnoses) nog, hoewel ze van plan zijn dit te proberen.
Het belooft niet dat het systeem nooit meer zal falen; het belooft dat het systeem beter zal worden in het begrijpen van waarom het faalde en hoe het de regels kan aanpassen.

Technische Samenvatting: Van Falen naar Afstemming: Een Requirements Engineering Framework voor Machine Learning Systemen

Probleemstelling

Organisaties die Machine Learning Systemen (MLS) ontwikkelen, worden geconfronteerd met aanzienlijke uitdagingen bij het waarborgen dat deze systemen betrouwbaar zijn en afgestemd op de behoeften van belanghebbenden. In tegenstelling tot traditionele software wordt het gedrag van MLS geleerd van data in plaats van expliciet geprogrammeerd te worden, wat betekent dat prestaties afhankelijk zijn van de distributie en falen inherent is door generalisatie en onzekerheid. Huidige Requirements Engineering (RE) praktijken worstelen met het systematisch modelleren en redeneren over MLS-eisen omdat:

Ondergespecificeerdheid: Operationele domeinen zijn open einde, en een volledige voorafgaande specificatie is onrealistisch.
Impliciete Aannames: Domeinaannames (bijv. datadekking, sensorgrenzen) zijn vaak impliciet, wat leidt tot een mismatch tussen de doelen van belanghebbenden, domeinaannames en systeemgedrag wanneer er fouten optreden.
Gebrek aan Integratie: Hoewel foutdetectie gebruikelijk is bij ML-testen, is er een kloof in het systematisch integreren van het ontdekken van fouten in het RE-proces om de verfijning van eisen aan te drijven. Bestaande benaderingen behandelen fouten vaak als testartefacten of debugging-problemen in plaats van als diagnostisch bewijs voor het verfijnen van eisen en domeinaannames.

Het artikel adresseert drie onderzoeksvragen (RQ's):

RQ1: Hoe kan het redeneren over eisen worden geoperationaliseerd voor MLS?
RQ2: Hoe kan het ontdekken en mitigeren van fouten systematisch worden geïntegreerd in het RE-proces?
RQ3: In welke mate kan foutgedreven, cross-layer adaptatie de bevrediging van eisen meetbaar verbeteren?

Methodologie: Het REAL Framework

De auteurs stellen REAL voor (Requirements Engineering for mAchines that Learn - and Fail), een modelgebaseerd framework dat falen behandelt als een eersteklas construct. REAL werkt volgens drie kernprincipes: het samenweven van data-, model- en systeemvereisten; het gebruik van falen om de exploratie van alternatieve eisen aan te drijven; en iteratieve, traceerbare verfijning.

Het framework vestigt een iteratieve afstemmingslus bestaande uit drie fasen:

1. Identificeren van Falen door Scenario-exploratie

In plaats van uit te gaan van uniforme eisbevrediging, operationaliseert REAL het domein als een geparametriseerde scenarioruimte $D(\theta)$ .

Grammatica-gestuurde Generatie: Het gebruikt Grammatical Evolution (GE) met een Domain Specific Language (DSL) die is gedefinieerd door een formele grammatica om automatisch gestructureerde scenario's (actoren, omgevingen, gedragingen) te genereren.
Admissibiliteitsfiltering: Het framework maakt onderscheid tussen geldige fouten (voorkomend binnen toelaatbare domeinaannames) en spuriële fouten (getriggerd door scenario's buiten de scope). Alleen geldige fouten, waarbij $D(\theta), S \not\models R$ en aan de admissibiliteitsbeperkingen wordt voldaan, worden doorgegeven voor analyse.

2. Analyseren van Falen door Obstakelanalyse

Fouten worden geherinterpreteerd als obstakels in een KAOS-stijl doelmodel.

Tegenvoorbeeld Interpretatie: Een fouttrace wordt behandeld als een tegenvoorbeeld voor de bevredigingsrelatie.
Obstakel Afleiding: Fouten worden geclusterd om terugkerende patronen te identificeren, waarbij empirische tegenvoorbeelden worden verheven tot expliciete obstakelcondities ( $O$ ) waar $O \Rightarrow \neg R$ . Dit diagnosticeert mismatches tussen de doelen van belanghebbenden, domeinaannames en systeemgedrag.

3. Mitigeren van Falen door Multi-Layer Adaptatie

REAL onderscheidt vier lagen van adaptatie om de bevredigingsrelatie te herstellen ( $D, S \models R$ ):

Data-niveau: Het aanvullen van trainingsdistributies of het herbalanceren van klassen om distributieve hiaten aan te pakken.
Model-niveau: Het aanpassen van architecturen, hyperparameters of beslissingsdrempels om de geleerde beslissingsgrens te hervormen.
Systeem-niveau: Het introduceren van vertrouwensbewuste controlelogica, fail-safe gedrag of redundantie zonder het geleerde model zelf te wijzigen.
Eis-niveau: Het verfijnen van de eisen ( $R$ ) of de domeinaannames ( $D$ ) zelf (bijv. het afbakenen van het Operational Design Domain) wanneer fouten onthullen dat er ondergespecificeerde behoeften of onrealistische aannames zijn.

Dit proces is iteratief; nieuwe adaptaties kunnen nieuwe schendingen blootleggen, wat verdere verfijning van de triple $(D, S, R)$ vereist.

Belangrijkste Bijdragen

Het artikel levert vier primaire bijdragen:

Operationele Koppeling: Het verbindt de eisen van belanghebbenden met uitvoerbare domeinvariabiliteit via grammatica-gestuurde scenario-exploratie, wat de systematische ontdekking van relevante tegenvoorbeelden mogelijk maakt.
Obstakel-gebaseerde Interpretatie: Het herinterpreteert empirische fouten als obstakels in een doelmodel, wat een principieel mechanisme biedt om mismatch te diagnosticeren.
Multi-Layer Mitigatiestrategie: Het definieert en evalueert gecoördineerde adaptatie over de data-, model-, systeem- en eis-lagen, en toont expliciet aan hoe mitigatiebeslissingen de eisbevrediging beïnvloeden.
Autonoom Rijden Demonstrator: Het biedt een publiek beschikbaar replicatiepakket dat het framework demonstreert op een automatisch remsysteem met behulp van CARLA, Scenic en evolutionaire scenario-generatie.

Experimentele Resultaten

Het framework werd geëvalueerd met behulp van een automatisch remsysteem met een voetgangersdetectiecomponent (YOLOv5) en een deterministische remcontroller.

Experimentele Opstelling:

Omgeving: CARLA-simulator met Scenic voor scenario-specificatie.
Generatoren: GRAPE (Grammatical Evolution) voor scenario-generatie.
Focus: Systematische variatie van voetgangersgrootte, afstand, richting, kleding en weersomstandigheden (mist).

Bevindingen:

Foutidentificatie: Het framework identificeerde succesvol geldige eisovertredingen, zoals gemiste detecties van kind-voetgangers (omvang-gerelateerd), falen onder lage visuele salientie (kledingcontrast) en gedegradeerde prestaties in mist (zichtbaarheid).
Obstakelanalyse: Fouten werden gegroepeerd in drie obstakelklassen: PedestrianSizeTooSmall, VisualSaliency, en AdverseWeather.
Effectiviteit van Mitigatie:
- Model-niveau (M1): Het overstappen naar een groter model (YOLOv5m) verbeterde de nauwkeurigheid (+17%), maar introduceerde latentie-gerelateerde fouten in scenario's op korte afstand.
- Data-niveau (M2): Gerichte fine-tuning op data van kind-voetgangers elimineerde de omvang-gerelateerde fouten en verbeterde de prestaties in mist aanzienlijk (botsingspercentage daalde van 100% naar 0% in nominale weersomstandigheden).
- Systeem-niveau (M4): Het implementeren van vertrouwensbewuste remacties verminderde de resterende botsingen met kinderen van 100% naar 8% zonder hertraining.
- Eis-niveau (M5): Het expliciet afbakenen van het Operational Design Domain (ODD) en het definiëren van kwantitatieve drempels verduidelijkte de grenzen van de veiligheidsgaranties.
Algehele Impact: Gecoördineerde cross-layer adaptatie verminderde de botsingen met kinderen van 100% (baseline) naar 8% en elimineerde fouten in nominale weersomstandigheden. De studie toonde aan dat geïsoleerde modeloptimalisatie onvoldoende is; afstemming vereist het aanpakken van de interactie tussen data, model, systeem en eisen.

Betekenis en Claims

Het artikel claimt dat REAL een systematisch proces biedt voor het integreren van testresultaten in RE-artefacten. De betekenis ligt in:

Verschuiving van het Perspectief op Falen: Het verschuiven van het zien van een fout als een technisch defect naar het zien van een fout als diagnostisch bewijs van een mismatch tussen eisen, aannames en implementatie.
Operationaliseren van Afstemming: Het bieden van een concreet mechanisme om hoge-niveau doelen van belanghebbenden te koppelen aan laag-niveau systeemgedrag en domeinaannames door middel van obstakelanalyse.
Cross-Layer Coördinatie: Het demonstreren dat het herstellen van afstemming in MLS gecoördineerde adaptatie over meerdere lagen (data, model, systeem, eisen) vereist in plaats van geïsoleerde fixes.

De auteurs hanteren een bescheiden standpunt en erkennen dat de evaluatie beperkt is tot een vereenvoudigd veiligheidskritisch voorbeeld en dat het proces geen convergentie in alle gevallen garandeert. Ze merken op dat hoewel het framework het proces structureert, menselijke oordeelsvorming essentieel blijft voor het interpreteren van fouten en het selecteren van mitigatiestrategieën. Toekomstig werk wordt voorgesteld om REAL uit te breiden naar Large Language Models (LLMs), stakeholderwaarden dieper te integreren en de convergentievoorwaarden van de iteratieve afstemmingslus te onderzoeken.