Så testar jag om en Humanizer faktiskt förbättrar texten
Det är lätt att demonstrera en Humanizer. Ta en stel AI-text, kör den genom verktyget och visa en omskriven version som känns bättre vid första läsningen. Det är mycket svårare att svara på den viktigare frågan: blev texten faktiskt bättre utan att något viktigt gick sönder?
Det är lätt att demonstrera en Humanizer. Ta en stel AI-text, kör den genom verktyget och visa en omskriven version som känns bättre vid första läsningen. Det är mycket svårare att svara på den viktigare frågan: blev texten faktiskt bättre utan att något viktigt gick sönder?
När jag började behandla Humanizern som ett system i stället för en prompt blev evals därför en central del. Jag vill kunna uppdatera en regel, en modell eller en adapter och sedan se om förbättringen håller över flera texttyper – och framför allt om jag introducerat regressioner i fakta, röst eller genre.
Börja med att definiera vad "bättre" betyder
Om målet bara är "mer mänskligt" går testet inte att göra ordentligt. Jag delar därför upp kvaliteten i separata dimensioner: trohet (samma fakta, siffror, datum, namn, citat, länkar och säkerhetsgrad måste finnas kvar), tydlighet (texten ska bli lättare att förstå, inte bara mer varierad), naturlighet (mekanisk rytm, tom inflation och översättningslik syntax kan förbättras när de faktiskt finns), röst (den observerbara formalitetsnivån och direktheten ska bevaras), genre (en juridisk text, en produktguide och en personlig essä ska inte normaliseras till samma stil) och minimalitet (en bra Humanizer ska kunna låta fungerande text vara ifred).
Det sista kriteriet är viktigt. Ett system som får hög poäng bara när det gör stora förändringar kommer att lära sig att överredigera.
Jag använder tre typer av testfall
Min testsvit är uppdelad i standardfall, edge cases och adversarial cases.
Standardfallen är sådant som verktyget ska klara varje gång: ett mekaniskt stycke med upprepade meningsstarter, en sakprosatext med tom inflation eller en svensk text med översättningslik meningsbyggnad.
Edge cases är texter där en aggressiv redigering lätt gör skada. Det kan vara juridisk text, teknisk dokumentation, en text med avsiktlig repetition eller en författare med kort och fragmentarisk stil.
Adversarial cases testar om Humanizern följer fel mål när användaren ber den göra något tveksamt. Exempel:
Ett robust system ska inte bara skriva bättre. Det ska också kunna vägra den del av uppgiften som bryter mot trohetskraven.
Golden set före benchmark
Jag behöver inte börja med tusentals texter. Ett litet golden set med väl valda fall är mer användbart än ett stort dataset där jag inte vet vad som faktiskt ska vara oförändrat.
För varje testfall sparar jag input, texttyp och målgrupp, låsta fakta, önskat redigeringsläge, vad som faktiskt är fel i texten, vad som inte får "fixas", och bedömningskriterier. Det gör testet reproducerbart. Om en ny version plötsligt skriver om ett exakt tal kan jag peka på en konkret regression, inte bara säga att resultatet "kändes sämre".
Faithfulness är hard gate
Jag skiljer på kvalitetsfel och stoppfel. En lite ojämn mening kan ge lägre stilpoäng. Ett ändrat faktapåstående ska däremot underkänna hela körningen.
Jag använder därför ungefär följande prioritet: fakta och innehållslås, säkerhetsgrad och ståndpunkt, juridisk/teknisk precision, genre och röst, tydlighet, naturlighet, variation. Om en version är mer elegant men ändrar betydelsen är den inte bättre.
A/B-testa regeln, inte bara modellen
En vanlig fälla är att byta modell och tolka resultatet som ett test av Humanizern. Jag försöker i stället isolera förändringen. Om jag ändrar regeln för tematisk överförklaring kör jag samma testfall med samma modell före och efter regeländringen. Om jag byter modell håller jag instruktionerna konstanta.
Det gör felsökningen mycket enklare. Annars vet jag inte om förbättringen kommer från modellen, prompten, den nya redigeringsregeln eller ren variation mellan två samplingar.
OpenAI rekommenderar samma grundtanke i sina evals-resurser: definiera uppgiftsspecifika kriterier och kör återkommande tester när systemet förändras, i stället för att förlita sig på enstaka demos (OpenAI Evals — adressen kan flytta eller döpas om, så kontrollera länken vid publicering).
Automatiska kontroller där det går
Allt behöver inte bedömas av en språkmodell. Vissa regressioner är bättre som deterministiska tester: finns alla siffror kvar, finns alla URL:er kvar, är citat oförändrade, har markdown-strukturen brutits, har kodblock ändrats trots att uppdraget gällde prosa, och har texten blivit 70 procent längre utan uttryckligt skäl?
Sedan kan en kvalitativ evaluator bedöma sådant som rytm, tydlighet och röstbevarande. Jag vill alltså inte använda en LLM-domare för det som en enkel diff kan avgöra säkrare.
Pairwise slår ofta absoluta poäng
Det är svårt att svara konsekvent på "är den här texten 8,3 av 10?". Jag får bättre signal av pairwise-frågor:
Vilken version löser det identifierade problemet bäst samtidigt som fakta och röst bevaras – A eller B?
Det går dessutom att blinda ordningen så att evaluatorn inte vet vilken version som är den nya.
För en Humanizer kan jag använda fyra utfall: A bättre, B bättre, likvärdiga, hard fail på trohet. Det ger mer handlingsbar information än ett genomsnittsbetyg som döljer att tre texter blev fantastiska och två fick faktafel.
Testa också när systemet ska göra nästan ingenting
Ett av mina viktigaste regressionstest är redan välskriven text. Humanizern ska inte känna ett behov av att demonstrera sitt värde genom att skriva om allt.
Jag lägger därför in exempel där korrekt output är texten oförändrad, eller bara en eller två mikrojusteringar. Det här fångar en särskild typ av modellbeteende: "helpfulness drift", där verktyget fortsätter optimera trots att uppgiften redan är löst.
Forskning ska testas inom sin domän
Min Humanizer använder bland annat resultat från StoryScope som underlag för vissa fiktionskontroller. Studien gäller lång engelskspråkig bokfiktion och specifika modeller. Jag gör därför inte ett eval där svensk myndighetstext förväntas få fler subplots eller temporal diskontinuitet.
Forskningsregler måste ha en scope. Om en regel flyttas utanför sitt evidensområde ska den märkas som redaktionell hypotes och testas separat.
Källa: StoryScope: Investigating idiosyncrasies in AI fiction.
Min release gate
Innan en ny Humanizer-version får ersätta den gamla vill jag minst ha: 0 hard fails på fakta/citat/länkar, inga nya regressioner i edge cases, förbättring eller neutralitet på standardfallen, adversarial cases som beter sig enligt policy, inga systematiska röstförändringar, och en changelog som beskriver vad som faktiskt ändrats.
Jag vill också kunna peka på vilka testfall som motiverade ändringen. "Den nya prompten känns bättre" räcker inte som versionsargument.
Det jag inte använder som huvudmått
Jag använder inte AI-detektorscore som kvalitets-KPI. En detektor försöker klassificera ursprung; jag försöker förbättra text. De två målen kan ibland korrelera, men de är inte samma sak.
Jag använder inte heller lexical diversity som ensam KPI. Ett system kan öka ordvariationen genom synonymcykling och samtidigt göra texten sämre.
Och jag använder inte "mer förändring" som framgång. En Humanizer är en redaktör, inte en transformationsmaskin.
Det verkliga testet
En Humanizer är bättre när den löser fler verkliga textproblem utan att öka risken för innehållsregression. Det är en mycket högre ribba än att kunna visa ett snyggt före/efter-exempel.
När evals finns på plats kan jag dessutom förbättra systemet med större självförtroende. Jag behöver inte hoppas att en ny regel fungerar. Jag kan se exakt vilka typer av texter som blev bättre, vilka som blev sämre och var jag måste backa.