LLM-verifikatorer bliver mere lemfældige efter audit-reparation – vigtigt for automatiserede pipelines

Når en sprogmodel bruges som automatisk kontrollør i en pipeline, hvor en anden model retter fejl, ændrer selve sekvensen – audit efterfulgt af reparation – hvordan kontrolløren vurderer efterfølgende input. Det viser et nyt papir fra Hugging Face, Prior Audit-Repair Context Shifts LLM Verifier Thresholds Toward Leniency.

Forskerne målte falske alarmer på ProcessBench-spor, som mennesker havde verificeret som korrekte, mens selve opgaven blev holdt byte-identisk. Resultatet: en fuldført audit-reparation-episode i modellens kontekst reducerede falske alarmer i 15 ud af 15 model- og formulering-kombinationer, med 2,8 til 11,5 procentpoint sammenlignet med en kontrol uden audit – en relativ reduktion på 9 til 25 procent.

Overraskende nok peger retningen modsat, hvad litteraturen om akkumulerede beskeder forudsiger: En episode, hvor audit rapporterede en fejl, sænkede falske alarmer yderligere – på alle fem formuleringer hos den model, hvor manipulationen ramte rent – selvom en negativitets-asymmetri skulle forudsige flere flag.

Ved at dekomponere episoden fandt forskerne, at reparationsindhold og audit-udfald er komplementære: Forskellige komponenter bærer effekten på forskellige modelfamilier. Signal-detektionsanalyse placerede ændringen i tærsklen snarere end i diskrimination – kriteriet flyttede sig i 15 ud af 15 kombinationer og overlevede korrektion i 13, mens d' ikke overlevede i nogen, dog med halv følsomhed i testen.

En manuel gennemgang af 50 falske alarmer viste, at 82% var simpelthen forkerte, så ved dette driftspunkt behøver skiftet ikke at være skadeligt. Med reasoning aktiveret beholdt effekten sin relative størrelse på begge testede modeller, og tærskel-aflæsningen holdt også der.

For beslutningstagere, der bygger automatiserede kvalitetskontrolsystemer, betyder det, at konteksten omkring en verifikator ikke er neutral: Den samme model kan rapportere forskellige fejlrater afhængigt af, hvad den har set tidligere. Det er afgørende at forstå, når man designer pipelines, hvor modeller både tjekker og retter – og når man fortolker output fra sådanne systemer.