Jeg brugte en formiddag på at bygge et tilbud til en kunde sammen med en sprogmodel. Teksten blev god. Bedre, end jeg selv ville have skrevet den på den tid — argumentet for rækkefølgen i forløbet, formuleringen af hvad kunden faktisk sidder med bagefter, indvendingerne skrevet frem, før kunden når at tænke dem.
Så kørte jeg valideringen. Den fejlede.
tilbud/kunde-a › frontmatter › cvr: 12345678 is not of types "null", "string"
CVR-nummeret var blevet skrevet som et tal. Det skal være en tekststreng, for et CVR-nummer er en identifikator og ikke en mængde. Man lægger dem ikke sammen, og man regner ikke gennemsnit af dem. Som tal ville skemaet også acceptere 5 og -12 og 3,14; som streng med mønsteret ^[0-9]{8}$ findes der præcis én gyldig form. Og i det øjeblik nummeret skal ud af huset — i en CSV-fil, i et regneark eller som momsnummeret DK39337622 — er det tekst og har altid været det.
Det er hele pointen i det her indlæg.
To forskellige discipliner, der bliver forvekslet
Sprogmodeller er blevet gode til to ting: at skabe tekst og at analysere tekst. Virkelig gode. Et tilbud, et brev, en analyse af et jobopslag, et udkast til en indvending — det er arbejde, der før tog en formiddag, og nu tager tyve minutter plus gennemlæsning.
Men der er en tredje ting, folk forventer af dem, som de ikke er gode til: at garantere noget.
Forskellen er ikke gradsforskel. Den er kategorisk. Når en model skriver, arbejder den med sandsynligheder — hvad der plausibelt kommer efter det foregående. Det er præcis den egenskab, der gør den god til sprog, og præcis den egenskab, der gør den uegnet som kontrolinstans. En model, der læser sit eget output igennem og siger "det ser rigtigt ud", har ikke valideret noget. Den har afgivet endnu en sandsynlig udtalelse.
En validator siger ikke "det ser rigtigt ud". Den siger nej, og den siger hvorfor, og den siger det hver eneste gang.
Hvad et skema faktisk er
I min egen notesamling er der syv dokumenttyper med skema: CV'er, ansøgningsbreve, oplæg, tilbud, virksomhedsprofiler, persondossierer og udgående mails. Et skema er en fil, der beskriver, hvad noten skal indeholde: hvilke felter der er obligatoriske, hvilke værdier de må have, hvilke afsnit der skal være, og hvor lange de må være.
Det lyder som bureaukrati. I praksis er det det modsatte. Det er det, der gør, at jeg tør lade en model skrive.
Tag tilbudsskemaet. Det kræver, at der er en sektion, der hedder Forudsætninger — hvad kunden selv skal levere af data, adgange og navngivne folks tid. Den sektion er obligatorisk, fordi det er den, der afgør, hvem der betaler for en forsinkelse. Et tilbud uden den er ikke et dårligt tilbud. Det er et tilbud, der kommer til at koste penge om tre måneder.
Det kræver også et felt, der hedder valid_until. Et tilbud uden udløbsdato er en prisliste, kunden kan tage frem om to år og bede om samme pris.
Og det kræver, at beløbet i feltet amount findes som tal, så hele pipelinen kan lægges sammen uden at åbne noterne.
Ingen af de tre regler handler om sprog. De handler om, hvad et tilbud er. Og de virker, uanset hvor overbevisende teksten ovenover er skrevet.
Begrænsningen gør det kreative bedre
Her er det, der overraskede mig mest, første gang jeg byggede sådan et system.
Man skulle tro, at skemaet begrænser modellen. At man får en mere firkantet tekst, fordi den skal passe ind i en form. Det modsatte sker.
Da jeg lavede en skabelon til udgående salgsmails, lagde jeg to regler ind i skemaet: mailen må ikke indeholde punktopstillinger, og den må højst fylde omkring 400 tokens — en god halv side. Begge regler er hårde. Overskrides de, afvises noten.
Resultatet er ikke en dårligere mail. Det er en bedre. Punktopstillingen i en kold mail er dér, hvor man holder op med at argumentere og begynder at opremse fordele, og modtageren kan lugte det på et halvt sekund. Længdegrænsen tvinger den ene tanke frem, der bærer mailen, i stedet for de fire, der udvander den.
Begrænsningen er ikke en spændetrøje om det kreative. Den er den ramme, det kreative skal fortjene sin plads indenfor. Enhver, der har skrevet en sonet eller en annoncetekst på 30 tegn, kender mekanismen.
Det er derfor, jeg vender det om, når folk spørger, hvordan man styrer en sprogmodel. Man styrer den ikke med instruktioner om at være præcis. Man styrer den med en form, der afviser det, der ikke er.
Skabelonen, der fejlede sin egen validering
Det pæneste eksempel fra samme formiddag er det, jeg selv trådte i.
Jeg skrev skemaet til de udgående mails, og jeg skrev skabelonen, der skal producere dem. Skemaet siger, at emnelinjen skal være ét afsnit på højst 30 tokens. Skabelonen havde emnelinjen plus en forklarende sætning om, hvordan man skriver en god emnelinje.
Da jeg oprettede den første note fra skabelonen, fejlede den. To afsnit, hvor der måtte være ét. Fyrre tokens, hvor der måtte være tredive.
Jeg fjernede forklaringen. Så fejlede den igen — nu var der slet ingen emnelinje, når man oprettede en tom note.
Det er en flov lille fejl, og den er præcis derfor, den er værd at fortælle om. Jeg havde skrevet både reglen og det, der skulle overholde den, med tyve minutters mellemrum. Havde jeg kun læst det igennem, ville jeg have sagt god for begge dele. Det gjorde jeg også. Valideringen sagde nej to gange, og først derefter var skabelonen rigtig.
Et menneske, der læser korrektur på sit eget arbejde, ser det, det gerne vil se. Det gør en sprogmodel også. En parser gør ikke.
Den anden slags validering: det, der kan slås op
Der er en variant af det her, som er endnu mere håndfast, og som handler om fakta frem for form.
Samme dag skrev jeg en profil på den virksomhed, tilbuddet skulle sendes til. Selskabet stod registreret med en branchekode for finansielle holdingselskaber, men driver noget helt andet. Det matcher ikke. Jeg skrev den mest sandsynlige forklaring: at der måtte være et driftsselskab ved siden af holdingselskabet, som er en helt almindelig konstruktion.
Det var et godt gæt. Det var også forkert.
Da jeg slog selskabet op direkte i CVR-registeret, var svaret entydigt: ét selskab, én produktionsenhed, samme adresse, samme branchekode, én ejer. Der er intet driftsselskab. Bureauet kører gennem et selskab, der bare står registreret forkert.
Forskellen mellem det plausible og det rigtige var ét opslag i et register. Ingen mængde eftertanke havde lukket det spørgsmål, for gættet var jo fornuftigt — det var bare ikke sandt. Det er det, kildebinding handler om, og det er grunden til, at ethvert faktum i en kundeprofil skal kunne pege på, hvor det kommer fra.
Hvad det betyder for jeres virksomhed
Hvis I bygger noget med AI i, er det her den arbejdsdeling, der virker:
Lad modellen skrive og analysere. Det er dét, den er god til. Udkast, omskrivninger, sammenfatninger, forslag til indvendinger, første analyse af et dokument. Der er ægte produktivitet at hente, og den er stor.
Lad kode validere. Skemaer, typetjek, regler, opslag i registre, tests. Alt hvad der skal være rigtigt hver gang, skal afgøres af noget deterministisk — noget der giver samme svar på samme input, i dag og om et år.
Lad ikke en model kontrollere en model. To sprogmodeller, der er enige, er ikke en verifikation. Det er to sandsynlige svar oven på hinanden. Der findes gode grunde til at bruge en model til at gennemgå et udkast, men det er redaktion, ikke kontrol, og forskellen skal stå klart for alle i huset.
Skriv reglerne ned ét sted. Det, der gør et skema værdifuldt, er ikke, at det afviser fejl. Det er, at det tvinger jer til at blive enige om, hvad et tilbud, en kundeprofil eller en faktura er hos jer. Det arbejde er I nødt til at gøre alligevel. AI gør det bare pludselig presserende.
Og så den vigtigste, som jeg har skrevet om før i Validering: kan I ikke definere en klar test for, hvornår outputtet er rigtigt, skal opgaven ikke automatiseres med en sprogmodel. Ikke endnu.
Det er ikke et argument mod AI
Tværtimod. Jeg fik lavet et tilbud, en kundeprofil, et personportræt og en kold mail på en formiddag, og jeg tør sende dem, fordi der sidder et lag under teksten, som ikke er til forhandling.
Det kreative og begrænsningen er ikke modsætninger, der skal afvejes. De er to halvdele af det samme system. Modellen leverer sproget, formuleringen, den gode indvending, den rigtige rækkefølge i argumentet. Skemaet leverer garantien om, at der står et CVR-nummer, at der er en udløbsdato, og at de interne noter aldrig havner i den PDF, kunden får.
Den sidste er i øvrigt også en regel i kode. Jeg stoler på mig selv til meget, men ikke på at jeg husker at slette mine egne noter, hver eneste gang, kl. 16.45 på en fredag.
Se også Validering om lukkede valideringsloops, Source grounding om at binde output til kilder, og Datakvalitet om det fundament, det hele står på.