💬 NLP

Evidence Absence Is Not Evidence Insufficiency: Diagnosing NEI Construction Artifacts in Fact Verification

Dit artikel introduceert NEI-CAP, een diagnostisch protocol dat aantoont dat modellen voor feitelijke verificatie vaak niet in staat zijn om competentie in het beoordelen van "onvoldoende informatie" te generaliseren over verschillende methoden voor het construeren van bewijs, omdat geaggregeerde scores de onderliggende afhankelijkheid van kortsluitingskoppelingen en constructiespecifieke artefacten kunnen maskeren.

Oorspronkelijke auteurs: Jingxi Qiu, Zeyu Han, Cheng Huang

Gepubliceerd 2026-05-27

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Jingxi Qiu, Zeyu Han, Cheng Huang

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 detective inhuurt om mysteries op te lossen. Je doel is om te zien of ze het verschil kunnen maken tussen drie dingen:

De zaak is opgelost (Het bewijs ondersteunt de bewering).
De zaak is gekraakt (Het bewijs weerlegt de bewering).
We hebben nog niet genoeg informatie (Het label "NEI").

Dit artikel betoogt dat we, terwijl we detectives testen op hoe goed ze zaken oplossen, ze hebben laten trappen in een valstrik bij de test "We hebben nog niet genoeg informatie". We hebben hen aanwijzingen gegeven die zo duidelijk ontbreken dat de detective niet slim hoeft te zijn om het probleem te zien; ze hoeven alleen maar het formaat van de ontbrekende aanwijzing te herkennen.

Hier is de uiteenzetting van de bevindingen van het artikel, met behulp van eenvoudige analogieën.

1. Het probleem: De "lege doos"-truc

Bij het controleren van feiten betekent het wanneer een computermodel zegt "Niet genoeg informatie" (NEI), dat het geleverde bewijs niet voldoende is om een bewering te bewijzen of weerleggen.

Het artikel ontdekte dat veel datasets (de trainingstests voor deze modellen) "NEI"-voorbeelden op een slordige manier creëren.

De "makkelijke" truc: Ze geven het model een bewering zoals "Het Chinese Muur staat in Brazilië" en geven vervolgens geen enkel bewijs (een lege doos) of een stuk tekst over pizza (helemaal niet gerelateerd).
Het resultaat: Het model leert een shortcut. Het denkt: "Oh, als er geen tekst is of de tekst gaat over pizza, moet ik 'Niet genoeg informatie' zeggen." Het controleert niet echt of het bewijs ontoereikend is; het controleert alleen of het bewijs ontbreekt of raar is.

2. De echte test: De "halfvolle doos"

Het artikel introduceert een nieuwe testmethode genaamd NEI-CAP. In plaats van het model alleen een lege doos te geven, geven ze het een halfvolle doos.

Het scenario: De bewering is "Het Chinese Muur staat in Brazilië". Het geleverde bewijs is een lange, gedetailleerde paragraaf over het Chinese Muur, maar het spreekt alleen over de lengte en waar het zich in China bevindt. Het noemt Brazilië niet, maar het is duidelijk gerelateerd aan het onderwerp.
De uitdaging: Een slimme detective zou moeten beseffen: "Deze tekst gaat over het Chinese Muur, maar het vertelt me niet of het in Brazilië staat. Ik heb meer informatie nodig."
Het falen: Het artikel ontdekte dat modellen die zijn getraind op de "lege doos"-trucs (de makkelijke NEI) deze "halfvolle doos"-test volledig falen. Ze kijken naar de gerelateerde tekst, zien dat het er ondersteunend uitziet (omdat het over het Chinese Muur gaat), en zeggen vol vertrouwen: "Dit ondersteunt de bewering!" of "Dit weerlegt het!" Ze missen het feit dat het specifieke detail dat ze nodig hebben, ontbreekt.

3. De "bouw"-metafoor

De auteurs noemen de manier waarop deze tests zijn opgebouwd "Constructiefamilies".

Eenvoudige constructie: Alsof je een muur bouwt van karton. Het ziet eruit als een muur, maar het is flinterdun. Als je een model traint op kartonnen muren, leert het karton te herkennen, niet echte bakstenen.
Moeilijke constructie: Alsof je een muur bouwt van echte bakstenen, maar een gat in het midden laat. Het model moet de structuur van de muur begrijpen om te weten dat het onvoltooid is.

Het artikel toont aan dat als je een model traint op "karton" (makkelijk, niet-gerelateerd of leeg bewijs), het een perfecte score behaalt op de test. Maar zodra je overschakelt naar "echte bakstenen met een gat" (semantisch gerelateerd maar ontoereikend bewijs), stort het model in. Het scoort nul.

4. De illusie van de "magische score"

Op dit moment, wanneer we naar het rapport van een model kijken, zien we één groot getal: "NEI-score".

De waarschuwing van het artikel: Dit getal is een leugen. Het is alsof een student een "A" krijgt voor een wiskundetoets omdat de leraar hen alleen heeft gevraagd nullen op te tellen. Als je hen vraagt breuken op te tellen, zakken ze.
Het artikel bewijst dat een model een perfecte "NEI-score" kan hebben op makkelijke tests, maar volledig nutteloos is in real-world scenario's waar bewijs gerelateerd maar onvolledig is. De "gemiddelde score" verbergt het feit dat het model alleen het formaat van de test uit zijn hoofd heeft geleerd, en niet de vaardigheid heeft aangeleerd.

5. De oplossing: NEI-CAP

De auteurs stellen een nieuw protocol voor genaamd NEI-CAP. Denk hierbij aan een nieuwe manier om de detective te beoordelen:

Geef niet alleen een score: Rapporteer in plaats daarvan hoe de test is opgebouwd. Hebben we de "lege doos" of de "halfvolle doos" gebruikt?
Audit de trucs: Controleer of het model alleen shortcuts herkent (zoals "geen tekst = NEI") of of het daadwerkelijk de inhoud begrijpt.
Menselijke controle: Voor de moeilijkste tests verifiëren mensen of het bewijs werkelijk ontoereikend is, zodat het model niet wordt misleid door dubbelzinnige data.

Samenvatting

Het artikel concludeert dat de manier waarop we "Niet genoeg informatie"-tests creëren, bepaalt wat de AI leert.

Als we de tests te makkelijk maken (lege dozen), leert de AI leegte te herkennen, niet ontoereikendheid.
Als we de tests moeilijk maken (gerelateerde maar onvolledige informatie), moet de AI daadwerkelijk nadenken.
Op dit moment "valsminken" de meeste AI-modellen bij de makkelijke tests. Ze zien er slim uit, maar ze zakken als het bewijs lastig is. Het artikel dringt er bij ons op aan om te stoppen met ons te verschuilen achter gemiddelde scores en precies te rapporteren op welk type "bewijsconstructie" het model is getest.

Technische Samenvatting: Afwezigheid van Bewijs is Niet Gelijk aan Onvoldoende Bewijs: Diagnose van NEI-bouwartefacten in Feitelijke Verificatie

Probleemstelling

Feitelijke verificatiesystemen classificeren claims doorgaans in drie categorieën: ONDERSTEUND, WEERLEGD, of NIET GENOEG INFORMATIE (NEI). Het NEI-label is bedoeld om aan te geven dat de beschikbare bewijsset $E$ onvoldoende is om de waarheid of onwaarheid van een claim $c$ vast te stellen. De paper betoogt echter dat de operationalisering van het NEI-label een ontwerpkiezing is die aanzienlijk varieert tussen benchmarks (bijv. FEVER, SciFact, HoVer) en vaak ongedefinieerd blijft in evaluatieprotocollen.

Het kernprobleem dat wordt geïdentificeerd, is dat "afwezigheid van bewijs" (bijv. lege velden, niet-gerelateerde passages) observationeel onderscheiden moet worden van "onvoldoende bewijs" (bijv. semantisch gerelateerd maar onvolledig bewijs). Huidige benchmarks verwarren deze condities vaak. Bijgevolg kunnen modellen leren om specifieke bouwartefacten (zoals ontbrekende tekst, onderwerp-mismatches of positionele biases) te herkennen, in plaats van de beoogde vaardigheid om echte onvoldoende bewijsvoering te identificeren. Dit leidt tot een situatie waarbij geaggregeerde NEI-prestatie-metrics (zoals NEI-F1) hoog kunnen zijn, terwijl het model volledig faalt op semantisch gerelateerd onvoldoende bewijs.

Methodologie: NEI-CAP

Om dit aan te pakken, introduceren de auteurs NEI-CAP (NEI Construction-Aware Protocol), een diagnosekader dat de constructie van NEI-bewijs behandelt als een expliciete variabele in de evaluatie.

1. Constructietaxonomie

NEI-CAP categoriseert NEI-voorbeelden in specifieke constructiefamilies op basis van hoe het onvoldoende bewijs is gegenereerd. De taxonomie onderscheidt tussen:

Shortcut-gevoelige constructies: Voorbeelden ontworpen om format-, onderwerp- of positie-shortcuts bloot te leggen.
- Plaatsvervanger: Vaste of lege bewijsmarkeringen.
- Willekeurig irrelevant: Bewijs uit niet-gerelateerde onderwerpen.
- Positie-biased: Niet-rationele bewijsvoering uit voorspelbare documentlocaties.
Semantisch gerelateerd onvoldoende bewijs (Hard NEI): Voorbeelden waarbij bewijs thematisch gerelateerd is maar logisch onvolledig.
- BM25 near-miss: Hoge lexicaal overlap maar onvoldoende ondersteuning.
- Geciteerde non-rationele: Bewijs uit geciteerde documenten dat niet de feitelijke ratione is.
- Zelfde-document non-rationele: Niet-rationele bewijsvoering uit hetzelfde brondocument.
- Missing-hop: Multi-hop bewijs waarbij een vereist feit is verwijderd.

2. Diagnoseworkflow

Het protocol volgt vijf fasen:

Constructie: Wijs een constructiefamilie ( $z$ ) en groeps-ID ( $g$ ) toe aan elk voorbeeld. Het model wordt nooit blootgesteld aan $z$ ; het wordt uitsluitend gebruikt voor auditing en gestratificeerde rapportage.
Audit: Meet shortcut-kenmerken (bijv. lengte, overlap, dekking) om oppervlakkige aanwijzingen te identificeren die modellen zouden kunnen exploiteren.
Valideren: Gebruik menselijke adjudicatie om "kandidaat" hard NEI te scheiden van voorbeelden die feitelijk ondersteund, weerlegd of ambigu zijn. Dit creëert een "menselijk-geadjudiceerde hard-NEI" subset.
Stress-test: Evalueer modellen die zijn getraind op specifieke constructiefamilies tegen andere families om transferabiliteit te testen.
Rapportage: Publiceer metrics gestratificeerd per constructiefamilie in plaats van geaggregeerde scores.

3. Experimentele Opstelling

Het protocol wordt voornamelijk geïnstancierd op SciFact (wetenschappelijke claimverificatie), met FEVER en HoVer als afgebakende externe controles.

Modellen: De primaire verifier is DeBERTa-v3-base, met RoBERTa en SciBERT als secundaire backbones.
Trainingsregimes: Modellen worden getraind op enkele constructiefamilies (bijv. alleen plaatsvervangers) of gemengde regimes (gemengde, moeilijke of gebalanceerde combinaties).
Evaluatie: Gebruik van constructie-shift-matrices (trainen op Familie A, testen op Familie B) en menselijk-geadjudiceerde hard-NEI recall.

Belangrijkste Resultaten

1. Transferfalen van Shortcut-gevoelige Training

Modellen getraind op "makkelijke" NEI-constructies (bijv. plaatsvervangers) bereiken een perfecte NEI-F1 op overeenkomstige testsets, maar storten in tot 0.000 NEI-F1 wanneer geëvalueerd op "moeilijke" constructies (BM25 near-miss of geciteerde non-rationele).

Dit falen is geen kalibratie-artefact; de waarschijnlijkheidsmassa verschuift volledig naar ONDERSTEUND of WEERLEGD.
De instorting is stabiel over verschillende modelarchitecturen (DeBERTa, RoBERTa, SciBERT) en willekeurige zaden.

2. Menselijk-geadjudiceerde Hard NEI Legt Modelzwaktes Bloot

Op de menselijk-gevalideerde hard-NEI subset (54 voorbeelden) bereiken modellen getraind op plaatsvervangers of positie-biased data een 0.000 recall. Ze voorspellen overweldigend ONDERSTEUND (vals positief) met hoge zekerheid.

Zelfs "willekeurig irrelevant" training, die minder extreem is dan plaatsvervangers, faalt om te generaliseren naar moeilijke onvoldoendheid (0.216 recall).
Alleen modellen getraind op moeilijke constructies (BM25/geciteerd) tonen gedeeltelijk herstel, maar ze bereiken nog steeds geen perfecte transfer.

3. Gemengde Training Elimineert Constructiegevoeligheid Niet

Training op gemengde constructieregimes (combinatie van makkelijke en moeilijke voorbeelden) verbetert de hard-NEI recall in vergelijking met single-family training, maar elimineert het prestatieverschil niet.

Modellen getraind op "gebalanceerde" mengsels vertonen nog steeds constructie-gestratificeerde profielen, waarbij ze significant beter presteren onder makkelijke condities dan onder moeilijke condities.
Dit geeft aan dat gemengde training een sterkere stress-test is, maar geen vervanging voor constructie-bewuste rapportage.

4. Impact op Niet-NEI Labels

Fixed-claim diagnostics onthullen dat de keuze van NEI-constructie de zekerheid van het model in ONDERSTEUND- en WEERLEGD-labels beïnvloedt. Wanneer referentiebewijs wordt ingeruild voor onvoldoende bewijs, falen modellen getraind op makkelijke NEI om hun zekerheid in het oorspronkelijke label te verlagen, terwijl modellen getraind op moeilijke NEI een waarschijnlijkheidsdaling vertonen. Dit suggereert dat bouwartefacten de gehele drie-weg taak beïnvloeden, niet alleen de NEI-hoek.

Bijdragen

Herdefiniëren van NEI: De paper herformuleert NEI niet als een enkel negatief label, maar als een constructie-gevoelige bewijsconditie.
NEI-CAP Protocol: Introduceert een diagnoseprotocol dat expliciet constructiefamilies bijhoudt, shortcut-kenmerken auditeert en moeilijke gevallen valideert via menselijke adjudicatie.
Empirisch Bewijs van Falen: Demonstreert via SciFact-, FEVER- en HoVer-experimenten dat shortcut-gevoelige training faalt om te transferen naar semantisch gerelateerd onvoldoende bewijs, en dat geaggregeerde NEI-F1-scores deze falen kunnen verbergen.

Betekenis en Claims

De paper stelt dat geaggregeerde NEI-F1-scores onvoldoende zijn voor het evalueren van feitelijke verificatiesystemen, omdat ze kunnen verbergen of een model heeft geleerd om echte onvoldoende bewijsvoering te herkennen of slechts de artefacten van hoe NEI-voorbeelden zijn geconstrueerd.

Bescheiden Scope: De auteurs stellen expliciet dat NEI-CAP een diagnoseprotocol is, geen complete oplossing voor redeneren over onvoldoende bewijs. Het identificeert constructiegevoeligheid en biedt audittools, maar garandeert geen universele redenering over voldoendeheid.
Rapportage-discipline: De primaire bijdrage is een verschuiving in rapportagediscipline: elk NEI-resultaat moet worden begeleid door de constructiefamilie die het heeft geproduceerd.
Beperkingen: Het sterkste bewijs is afgeleid van SciFact-stijl wetenschappelijke verificatie. FEVER en HoVer worden gebruikt als afgebakende controles en zijn in deze context geen menselijk-gevalideerde hard-NEI-benchmarks. De paper erkent dat verschillende domeinen mogelijk extra constructiefamilies vereisen en dat menselijke validatie labelvaliditeitsrisico's vermindert maar niet elimineert.

Concluderend betoogt de paper dat de constructie van onvoldoende bewijs moet worden behandeld als een kernonderdeel van het evaluatieprotocol, naast labels en metrics, om ervoor te zorgen dat feitelijke verificatiesystemen de beoogde vaardigheden leren in plaats van datasetspecifieke shortcuts.