Produktansvarlige, udviklere og fagteams, som tester AI og automatisering
Beslut, hvad testdataene skal bevise
Et stort datasæt er ikke nødvendigvis et godt testsæt. Begynd med den beslutning, testen skal understøtte. Skal I kontrollere, at en formular afviser ugyldige værdier, at en model finder det rigtige beløb, eller at en chatbot overdrager usikre spørgsmål? Hver opgave kræver andre eksempler og andre forventede resultater.
Syntetiske testdata bruges her bredt om konstruerede tilfælde. Nogle kan fremstilles direkte fra regler og opdigtede scenarier. Andre genereres af en model, der har lært mønstre fra virkelige data. Forskellen har betydning for, hvad I kan sige om repræsentativitet og beskyttelse af oplysninger. Et håndskrevet eksempel kan dække en bestemt fejl, men siger meget lidt om fejlens hyppighed i produktion.
Skriv en kort kontrakt for datasættet: målgruppe, anvendelse, tilladte formål, hvilke egenskaber der skal bevares, og hvad datasættet ikke kan bruges til at konkludere. Et sæt til at teste skærmbilleder bør ikke senere blive brugt til at påstå en models nøjagtighed på virkelige kundesager. Gem kontrakten sammen med dataene, så begrænsningen følger kopier og senere versioner.
Vælg fremstillingsmetode efter det nødvendige signal
Regelbaserede data er velegnede, når kontrakten er tydelig: beløb, datoer, statusværdier og relationer mellem poster. I kan konstruere en ordre med to varelinjer og beregne det forventede totalbeløb uafhængigt. Det giver en kontrollerbar test, selv om ordren ikke ligner alle virkelige køb.
Modelgenererede tekster kan give variation i formuleringer, stavefejl og rækkefølge. Bed modellen om bestemte scenarier frem for blot flere realistiske eksempler. Kontrollér derefter, at variationen faktisk er til stede. En model kan levere mange næsten ens tekster, som kun ser forskellige ud på overfladen. Den kan også opfinde korrekte labels til en sag, der i virkeligheden er tvetydig.
Statistisk syntese af eksisterende tabeldata kan bevare udvalgte fordelinger og sammenhænge, men kræver adgang til et relevant grundlag og særskilt evaluering. ICO beskriver både anvendelsesmuligheder og risiko for genkendelighed. Den britiske vejledning er under revision og bruges her som teknisk baggrund, ikke som afgørelse af dansk ret. Vælg den mindst komplicerede metode, der giver det nødvendige testsignal, og dokumentér, om virkelige oplysninger indgik under fremstillingen.
Byg en dækningsmatrix før I genererer flere rækker
Del opgaven op i egenskaber, som kan ændre resultatet. Ved dokumentudtræk kan det være sprog, layout, manglende felter, decimaltegn og modstridende beløb. Ved en supportassistent kan det være uklare spørgsmål, forældede kilder og forsøg på at udløse en handling. Lad en fagperson vælge de vigtigste kombinationer.
Hold normaltilfælde og bevidst svære tilfælde adskilt i rapporteringen. En testsamling med mange sjældne fejltilfælde er nyttig til at finde svagheder, men dens samlede fejlrate er ikke et estimat af produktionsfejlraten. Skriv, hvorfor hver gruppe er med. Manglende dækning er et konkret fund, som kan prioriteres.
Tabellen viser et illustrativt sæt for en løsning, der udtrækker fakturafelter til et udkast. Det er en testplan, ikke et gennemført benchmark. Antal tilfælde og grænser skal tilpasses anvendelsen. Først når forventningerne er tydelige, giver det mening at automatisere fremstillingen af flere varianter. Ellers skalerer I blot en uklar test.
| Gruppe | Konstrueret tilfælde | Forventet kontrol |
|---|---|---|
| Normal | To varelinjer, entydig dato og sum | Felter stemmer med uafhængigt facit |
| Talformat | Punktum eller komma som decimaltegn | Beløb fortolkes korrekt eller sendes til kontrol |
| Manglende oplysning | Ingen betalingsfrist | Felt forbliver ukendt; ingen opfundet dato |
| Modstrid | Total matcher ikke linjesum | Sagen markeres til faglig afklaring |
| Layout | Varelinje fortsætter på næste side | Ingen sammenblanding af rækker |
| Uønsket instruktion | Dokumenttekst beder om at ændre systemregler | Indhold behandles som data, ikke autorisation |
| Ugyldig struktur | Forkert datatype i et påkrævet felt | Validering afviser resultatet |
| Gentagelse | Samme dokument indsendes igen | Ingen utilsigtet dobbelt handling |
Skriv facit, som kan være uenig med generatoren
Hvert testtilfælde skal have et forventet udfald eller en vurderingsrubrik. Ved strukturerede data kan det være præcise feltværdier. Ved fritekst kan det være krav om bestemte fakta, udelukkelse af udokumenterede påstande og korrekt overdragelse. Et grammatisk godt svar er ikke nødvendigvis et rigtigt svar.
Lad ikke den samme model ukritisk generere sagen, facit og den endelige karakter. Den kan gentage sin egen misforståelse i alle tre led. Brug beregninger, regler eller faglig gennemgang, hvor det er muligt. Ved tvetydige tilfælde kan det korrekte udfald netop være et afklarende spørgsmål eller en afvisning af at konkludere.
Kontrollér facit på et udvalg af hver gruppe, før datasættet vokser. Hvis en label ændres under gennemgangen, skal begrundelsen gemmes. Slet ikke vanskelige tilfælde alene, fordi de trækker scoren ned. Markér i stedet, om opgaven ligger uden for systemets formål, om facit var forkert, eller om systemet faktisk fejler. De tre situationer kræver forskellige handlinger og bør kunne skelnes i rapporten.
Hold udvikling, afprøvning og afsluttende test adskilt
Et team lærer af de tilfælde, det bruger til at rette instruktioner og kode. Derfor er det ikke en uafhængig kontrol at rapportere den endelige kvalitet på præcis de samme eksempler. Lav et udviklingssæt, et fast regressionssæt og et tilbageholdt sæt til en afsluttende vurdering. Dokumentér, hvem der har haft adgang til hvad.
Adskillelsen skal følge de underliggende scenarier, ikke kun række-ID. Ti omskrivninger af samme kundesag kan lække det samme mønster mellem datasæt. Gruppér derfor varianter fra samme skabelon, dokument eller hændelse, når I fordeler data. Hvis en generator har set et tilbageholdt facit, kan I ikke efterfølgende kalde de frembragte varianter en uafhængig test af netop det materiale.
Et tilbageholdt sæt mister sin særlige rolle, når teamet gentagne gange bruger resultaterne til at optimere løsningen. Det kan fortsat være værdifuldt som regressionstest, men skal navngives derefter. Opret nye relevante tilfælde til den næste uafhængige vurdering. Bevar tidligere tests for at kontrollere, at kendte fejl ikke vender tilbage, uden at fremstille et voksende træningskendskab som dokumenteret generalisering.
Undersøg oplysningerne gennem hele fremstillingen
At output kaldes syntetisk fortæller ikke alene, om personer kan genkendes. Undersøg også input, generatorens adgang, mellemprodukter, fejlbeskeder og de filer, der deles med testere. Hvis virkelige personoplysninger bruges i fremstillingen, skal den behandling vurderes, selv om slutproduktet senere viser sig egnet til en anden adgangsramme.
Se efter direkte identifikatorer og sjældne kombinationer. En opdigtet adresse hjælper ikke nødvendigvis, hvis en unik hændelse, stilling og præcis dato er bevaret. Sammenlign relevante dele med kildedata i et kontrolleret miljø, hvis der findes et sådant grundlag og den nødvendige adgang. Undersøg både næsten identiske poster og genbrug af særprægede tekststykker.
Datatilsynets vejledning lægger vægt på muligheden for at identificere en person i den konkrete kontekst. Maskering, pseudonymisering og anonymisering er ikke synonymer. En automatisk scanning uden fund er heller ikke et bevis på anonymitet. Aftal, hvem der vurderer identificerbarhed og delingsramme, og bevar begrænsningerne, indtil vurderingen er afsluttet. Et datasæt kan være nyttigt til intern test, selv om det ikke er egnet til offentlig deling.
Mål nytte og beskyttelse som forskellige egenskaber
Et datasæt kan ligne originalens gennemsnit og stadig mangle de sammenhænge, som jeres opgave afhænger af. Undersøg derfor både enkle fordelinger, relevante relationer og resultatet af den konkrete test. NISTs SDNist og forskningsværktøjet SynthEval illustrerer, at vurdering af syntetiske tabeldata kan omfatte flere mål for nytte og mulige afsløringer. De er ikke universelle godkendelsesstempler.
Et lavt antal fund i en bestemt angrebstest siger noget om den test under de valgte forudsætninger. Det beviser ikke beskyttelse mod alle fremtidige forsøg. Hvis differential privacy indgår, skal definition af den beskyttede enhed, parametre, sammensætning af flere udgivelser og implementering forstås. NIST SP 800-226 beskriver netop faldgruber mellem en matematisk egenskab og dens praktiske anvendelse.
Vælg målene før sammenligningen og rapportér svagheder pr. undergruppe. Hvis sjældne sager forsvinder, må en god samlet score ikke skjule det. Vurder også, om mere realisme øger en uønsket genkendelighed. Den praktiske beslutning kan være at bruge forskellige datasæt til skærmtest, funktionstest og faglig kvalitetsmåling frem for at forsøge at gøre én fil egnet til alle formål.
Eksempel: et kontrolleret sæt til en fakturapilot
Et økonomiteam vil teste, om en assistent kan foreslå felter fra fakturaer, før en medarbejder godkender dem. I dette illustrative forløb skriver teamet først regler for gyldige felter og konstruerer et mindre sæt dokumenter med opdigtede virksomheder. Beløb og summer beregnes uden for sprogmodellen, så der findes et uafhængigt facit.
Udvikleren fremstiller derefter layoutvarianter, mens fagpersonen tilføjer sager med manglende frist, kreditnota og modstridende total. Teamet kontrollerer, at dokumenterne virkelig indeholder de tilsigtede udfordringer. En variant, hvor teksten er blevet ulæselig ved billedgenerering, mærkes som en OCR-test frem for at indgå ubemærket i testen af regneforståelse.
Piloten må kun skrive til et isoleret testmiljø. Der er ingen forbindelse til bogføring eller afsendelse. Resultaterne vises pr. gruppe med antal forsøg, fejl og overdragelser. Hvis systemet opfinder et beløb i stedet for at markere en uklar sag, stopper frigivelsen af den funktion. Eksemplet viser en metode til at finde konkrete fejl; det dokumenterer ingen bestemt nøjagtighed, besparelse eller egnethed til automatisk bogføring.
Giv datasættet en ejer, version og tydelige stopkriterier
Før datasættet deles, skal ejeren kunne forklare oprindelse, fremstillingsmetode, kontroller, kendte mangler og tilladt anvendelse. Registrér generatorversion, instruktioner, regler og eventuelle tilfældighedsfrø, når de er relevante. Et frø garanterer ikke identisk output fra en ekstern tjeneste, som kan ændre sig, så gem også de faktisk anvendte filer.
Stop deling, hvis der findes genkendelige virkelige oplysninger, ukendt kildegrundlag eller uafklaret adgang. Stop den kvalitetsmæssige godkendelse, hvis facit er upålideligt, nødvendige grupper mangler, eller udviklings- og testdata er blandet sammen. Det er forskellige stopårsager, og de bør få hver sin ansvarlige og rettelse.
Når et fund er rettet, gentages de berørte kontroller, og versionen opdateres. Undlad at overskrive et datasæt, som allerede indgår i en rapport, uden at bevare sammenhængen til resultaterne. Ved afslutning fjernes overflødige mellemprodukter efter den aftalte opbevaringsplan. En velbeskrevet begrænsning gør data mere anvendelige: den hjælper det næste team med at bruge sættet til det, der faktisk er undersøgt, og med at se, hvad de selv skal afprøve.
Det bliver vi ofte spurgt om.
Er syntetiske testdata altid anonyme?
Nej. Det afhænger blandt andet af fremstillingen, de bevarede oplysninger og mulighederne for at identificere personer. Også behandlingen af input og mellemprodukter kan være relevant. En syntetisk etiket eller en scanning uden fund erstatter ikke en konkret vurdering af det datasæt, der skal bruges eller deles.
Hvor mange testtilfælde skal vi lave?
Der findes ikke ét passende antal. Start med de scenarier, fejltyper og undergrupper, som skal dækkes, og tilføj variation, hvor den ændrer opgaven. Hvis I vil udtale jer statistisk om produktion, kræver det et andet grundlag end et håndplukket sæt af svære eksempler.
Kan vi bruge samme model til data og evaluering?
Det kan være en del af en arbejdsgang, men det giver afhængigheder og risiko for fælles fejl. Kontrollér facit med regler, beregninger eller fagpersoner, hvor det er muligt. Oplys tydeligt, når en model vurderer en anden models svar, og kald ikke det en uafhængig menneskelig test.
Kan syntetiske data erstatte al test på virkelige forhold?
De kan dække bestemte scenarier og reducere behovet for kopier af produktionsdata. De kan ikke alene vise, at jeres antagelser om den virkelige brug er korrekte. En passende, lovligt etableret kontrol af faktisk anvendelse kan derfor stadig være nødvendig før eller under afgrænset drift.
Læs videre ved kilden.
Vores beslutningsmodeller er rådgivning fra Mosel Studio. Tekniske fakta og rammer understøttes af kilderne her.
- ICO: Synthetic data
Teknisk baggrund fra britisk myndighed. Siden er under revision efter britisk lovændring; ikke dansk retsgrundlag. Gennemgået 7. september 2026.
- Datatilsynet: Hvad er personoplysninger?
Primærkilde gennemgået 7. september 2026.
- NIST: SDNist Synthetic Data Report Tool
Værktøjsbeskrivelse, ikke en godkendelse af et konkret datasæt; gennemgået 7. september 2026.
- Lautrup m.fl.: SynthEval
Forskningsartikel fra 2024 om evaluering af syntetiske tabeldata; gennemgået 7. september 2026.
- NIST SP 800-226: Evaluating Differential Privacy Guarantees
Publikation fra 2025; gennemgået 7. september 2026.
