En empirisk undersøgelse prikker til et ømt punkt i AI. 833 tests på seks modeller blev kørt for at se, om leverandørers foreslåede rettelser til produktionsfejl faktisk gør nytte. Konklusionen er kras: “Mostly, it didn’t.” Metode og datasæt er gjort åbne via primærkilden, så enhver kan gentage forsøget uden gætteleg.
Nyheden er ikke klagen over forskellen på demo og drift, men størrelsen og åbenheden i forsøget. Testene viser, at små AI‑fejl vælter hele systemer, især når modeller kædes i flere trin. Og at “stramme” fixes som hård format‑håndhævelse, post‑hoc validators og regex‑filtre ofte enten ikke hjælper eller i værste fald forværrer fejl.
Testen kort fortalt
Emmanuel Nwanguma beskriver 833 målrettede tests fordelt på seks modeller for at efterprøve konkrete vendor‑korrigeringer. Resultatet er klart: De fleste fixes holdt ikke i praksis. Data, prompts og scripts er publiceret som open source, linket findes i primærkilden. Testene gælder de pågældende modeludgaver på testtidspunktet, ikke en tidløs sandhed om enhver modelversion.
To ting driver svigtet: modelkapacitet, altså hvad modellen reelt kan, og formkompleksitet, kravet til struktur og flertrinsforløb. Kombinationen gør små afvigelser dyre, hvilket en pæn demo sjældent afslører.
Metoden, og hvorfor den tæller
Fordi data, prompts og evalueringer er åbne, kan man se, hvordan konklusionerne lander. Uenighed kan handle om parametre og design i stedet for mavefornemmelse. Artiklen beskriver også begrænsningerne, blandt andet at valg i testopsætningen kan begunstige bestemte mønstre. For ingeniører og evaluatører er den gennemsigtighed sjælden og nyttig.
Et vigtigt greb er, at evalueringen måler et helt forløb, ikke bare et enkelt svar. Når man kombinerer formatkrav, valideringslogik og kæder flere trin, ligner testen virkeligheden. Fejl viser sig der, hvor pæne enkeltprompt‑tests normalt glider let.
Hvor det går galt i praksis
Små unøjagtigheder forplanter sig. En manglende nøgle i et JSON‑output. En forveksling af feltetiketter i et formularflow. For sig selv ligner det kosmetik. I en kæde er det en kortslutning, fordi næste trin forventer præcis struktur. Formkompleksitet presser systemet ud over kanten oftere, end man tror.
Kædede modeller multiplicerer fejl. Hvis hvert trin er 95 procent korrekt, falder helheden, når fem trin stables. Banalt, men usynligt i demoer, hvor kæden ofte er skåret ned til en pæn sti.
Et kort eksempel fra virkeligheden
Tænk et kundeserviceflow i fire trin: 1) udtræk kundedata fra fri tekst, 2) udfyld et JSON‑skema, 3) slå sagstype op, 4) opret sag i systemet. I trin 2 forsvinder feltet “preferred_contact” sporadisk. Trin 3 accepterer outputtet, fordi skemaet ser rigtigt ud på overfladen, men mapper forkert kontaktkanal. Trin 4 laver en sag, der er “well‑formed”, men den ringer kunden op i stedet for at sende mail. Formatet så pænt ud, men semantikken var forkert, og fejlen skete tidligere i kæden.
Når “stram håndhævelse” giver bagslag
Et nærliggende fix er at låse formatet hårdt, med post‑hoc validering, regex‑filtre og afvisning af alt uden for skabelonen. Testen viser, at det ofte ikke hjælper og nogle gange skubber modellen i den gale retning. Modellen presses til at levere noget, den ikke kan stabilt, eller fejlmeldinger får den til at flakke i stedet for at lande korrekt.
Her rammer en bredere blind vinkel: “well‑formed” checks fanger ikke, om indholdet er rigtigt. De scorer struktur, ikke sandhed eller beslutningskvalitet. Derfor sniger de skadelige fejl under radaren, når valideringen kun kigger på overfladen.
Målefælder, der narrer teams
Evalueringsdesign kan både fremprovokere og skjule fejl. Måler man kun på pæn struktur, overser man alvorlige fakta‑ eller beslutningsfejl. Selv når menneskelige evaluatører er enige, kan de være enige om det forkerte, hvis kriteriet er skævt. Den farlige del er den falske tryghed, hvor en grøn metrik i lab bliver til røde hændelser i drift.
Konsekvensen er lavere release‑kvalitet. Pæne demoer, venlige data, håndplukkede prompts, og så et brag i produktion. Ikke teori, men hverdag i mange projekter.
Hvad resultaterne betyder i praksis
For produktledere betyder det nye releasekriterier. Et fix er ikke godkendt, fordi det klarede en happy path. Det skal igennem kædede scenarier, ugunstige inputs og have en klar tilbagetrækning, hvis signaler knækker. Uden rollback‑plan er et AI‑fix bare et håb.
For ingeniører og arkitekter er rækkefølgen vigtig. Vælg modellen før du bygger tung infrastruktur. Kræver opgaven stramme formater eller lange flows, er modelkapacitet og kontekststyrke afgørende. Orkestrering bagefter, ikke før.
Tekniske greb, der hjælper
Anbefalinger fra faglige praksisguides og Snillds vurderinger peger samme vej. Brug retrieval‑augmented generation for at mindske fri fantasi, når domænekundskab er kritisk, og hold øje med kilde‑drift og forældede indeks. Sandboxing af værktøjsopkald og sideeffekter begrænser skaden, når et fejltrin ellers ville skrive til en database eller et kundesystem. Det koster latenstid, men køber sikkerhed.
Derudover hjælper dynamisk prompt‑orkestrering med at nedtrappe kompleksitet. Gør formkrav eksplicitte i hvert trin og split flows i mindre, validerbare handlinger, der kan gentages lokalt. Kombinér det med realtidsmonitorering, der ikke kun tjekker form, men også semantik via referencekontrol, heuristikker eller letvægtsklassifikatorer. Og vigtigst, hav robust rollback med featureflag og modelversioner.
Sikkerhedslag og governance
Model‑agnostiske sikkerhedslag er ikke nice to have. De er nødvendige. Adversarial testning og røde‑team øvelser afslører netop de fejl, som hård format‑håndhævelse overser. Uden kontinuerlig monitorering og klart ejerskab for metrikker og hændelser går selv et godt fix i stykker ved første kantsten i virkeligheden.
Governance handler også om, hvem der må rulle hvad ud, og på hvilke data. Acceptkriterier skal være målbare, ikke manuelle nik. Korte eskaleringsveje, når en metrik går gul. Og en politik for, hvornår man falder tilbage til en regelbaseret sti i stedet for at lade en model improvisere.
Agentiske pipelines rammer muren oftere
Problemerne vokser i agentiske opsætninger og dokumentintelligens, hvor mange små værktøjer og afhængigheder spiller sammen. AutoFigure‑tutorialen beskriver helt lavpraktiske ting, som at løse afhængighedsproblemer, blandt andet Pillow‑kompatibilitet, og opsætte SVG og PNG‑rendering. Pointen er ikke figurer i sig selv, men at miljø og dependency‑kæder kan vælte output eller skabe tavse fejl, selv når modellen gjorde sit.
Jo flere trin, jo flere steder kan et svagt signal dø. Et pipeline‑eksempel: en model vælger figurtype, et værktøj gengiver SVG, et tredje post‑processerer PNG. Sniger der sig en upræcis instruktion ind, eller et versionshop i et bibliotek, ender man med en “pæn” fil med forkert indhold. Overfør samme logik til sagsbehandling eller supportautomatisering.
Branchens kontekst lige nu
Debatten i Towards AI’s nyhedsbrev peger på en skæv udvikling. Flere bygger AI‑funktioner, men adoptionen er ujævn, og robust engineering bliver flaskehalsen. Hurtigere modeller hjælper, men løser ikke orkestrering, måling og drift. Det er her mange snubler, og det er præcis her, den nye undersøgelse rammer plet.
Konsekvensen er færre teaterkulisser, flere vagtværn. Enterprise‑miljøer efterspørger dokumenteret robusthed, ikke en sceneoptræden. Det kan leveres, men kun med fokus på test, overvågning og styring.
Måling, der virker i produktion
Hvad skal man måle? For det første outputform, ja, men også semantik mod en sandhedskilde eller konsistens i næste systemled. For det andet kæderobusthed, sandsynligheden for at hele flowet lykkes, ikke kun et enkelt trin. For det tredje fejltyper, så man skelner mellem formatfejl, hallucinationer, klassifikationsskævheder og sekvensfejl, også når kilden ikke leverer en finmasket opdeling pr. model i en tabel.
En lille acceptliste, klar til at kopiere
Brug den som gate for et AI‑flow før release:
- Kæde‑successrate over X procent på realistiske edge‑cases, ikke kun happy paths.
- Semantisk korrekthed mod reference, målt med heuristik eller let model, ikke kun form.
- Klar rollback, med featureflag og versionering, testet i staging og verificeret i produktion.
- Vagter omkring værktøjer, inklusive sandbox, kvoter og sideeffekt‑kontrol.
- Monitorering i realtid med få, ejede metrikker, og aftalt on‑call for hændelser.
Konkrete ændringer i pipeline og drift
Start med modelvalget. Er opgaven stramt formateret eller flerstegs, så prioriter modeller med dokumenteret styrke i struktur og lang kontekst, før du forfiner prompts og værktøjer. Skær derefter flows i mindre, idempotente blokke med klare kontrakter. Hver blok skal kunne rettes og genkøres uden at rive resten med ned.
Tilføj en valideringspipeline, der kører parallelt: syntaks, semantik, sideeffekter. Router usikre outputs til fallback eller manuel gennemgang. Log alt, men skel mellem signal og støj. Få, tydelige metrikker slår 40 dashboards, ingen ser på. Planlæg versionering, så du kan rulle model eller prompt tilbage uden drama.
Røde‑team skabeloner, der virker i praksis
Gør testningen ubehagelig. Prøv:
- Format‑drilleri, indsæt ekstra felter, byt rækkefølge, brug ugyldige enum‑værdier.
- Semantiske fælder, plausible men forkerte kilder, modstridende fakta, datoer i forskellige formater.
- Kædeafbrydelser, fjern et mellemtrin eller giv det tomt input, se om resten fejler stille.
- Værktøjsangreb, langsomme eller tavse API‑svar, versionshop i et bibliotek.
- Prompt‑injektion tæt på brugerens data, test at guardrails griber før sideeffekt.
Skeptikernes indvendinger, og hvor de har en pointe
Nogle vil sige, at andre datasæt eller parametre kunne have givet pænere resultater. Sandt, og forfatteren erkender grænserne og inviterer til gentagelse. Men når 833 forsøg på tværs af seks modeller peger samme vej, er det svært at afskrive som kuriositet.
Andre peger på, at fremtidige modeller løser meget af det her. Måske. Historien viser, at stærkere modeller løfter baseline, men ikke fjerner behovet for governance, sikkerhedslag og måling. Ofte gør flere muligheder det bare lettere at fejle kreativt.
Tre trin til at stå skarpere i morgen
Kort sigt, denne uge: Lav en målbar acceptliste for jeres vigtigste AI‑flow, med kæde‑successrate, semantisk korrekthed mod reference og en dokumenteret rollback. Kør ti realistiske, grimme scenarier. Falder noget fra hinanden, ruller I ikke ud.
Mellemlang sigt, 4 til 8 uger: Byg en model‑agnostisk sikkerhedskæde med sandbox for værktøjer, semantiske guardrails og røde‑team tests, der opdateres løbende. Indfør metrik‑ejerskab hos en tydelig rolle, der kan sige stop. Dokumentér, hvad jeres modeludbydere faktisk gør, ikke kun hvad brochuren lover.
Lang sigt: Etabler en datadrevet valideringspipeline, der følger features over tid, og en releaseproces, hvor AI‑komponenter behandles som eksperimenter med kontrollerede flag. Planlæg for kædefejl som standard, ikke undtagelse.
Bundlinjen
Den åbne undersøgelse giver det, mange har fornemmet, en rygrad af data. Leverandørers hurtigfix holder sjældent i produktion, især når modelkapacitet og formkompleksitet møder kædede flows. Løsningen er ikke flere regex‑filtre, men bedre modelvalg til opgaven, klare kontrakter mellem trin, skarpere måling og en drift, der forventer fejl og håndterer dem.
Og vigtigt, stop med at lade “well‑formed” være lig “fungerer”. Forskellen mærker man først, når det hele kører live.
