En funktion, der bygger på en sprogmodel, kan give to forskellige svar på det samme spørgsmål, og begge kan være rigtige. Derfor kan den ikke testes alene med de automatiske tests, udviklere ellers bruger. Løsningen er en fast samling af eksempler, der køres gennem funktionen ved hver ændring og bedømmes efter aftalte kriterier. Det kaldes ofte evals, en forkortelse for evalueringer, og det er det vigtigste redskab, I har til at styre kvaliteten.
Artiklen er skrevet, så en ledelse kan stille de rigtige spørgsmål. Udviklerne skal bygge det, men ledelsen skal beslutte, hvad der er godt nok.
Hvorfor almindelig test ikke rækker
En almindelig test siger: når input er A, skal resultatet være B. Det holder, når koden er forudsigelig. En sprogmodel formulerer sig forskelligt fra gang til gang, og små ændringer ét sted kan flytte svarene et helt andet sted. En rettelse til instruktionerne, der løser ét problem, kan skabe to nye.
Dertil kommer, at noget kan ændre sig, uden at I selv har rørt ved det. Udbyderen kan udsende en ny modelversion, og jeres data vokser. Uden måling opdager I først det, når kunderne skriver.
Den faste samling af eksempler
Start med tyve til halvtreds eksempler, og lad samlingen vokse. Et godt eksempel består af et realistisk spørgsmål, de data, funktionen må bruge, og en beskrivelse af, hvad et godt svar skal indeholde.
Hent eksemplerne her:
- Rigtige spørgsmål fra kunder, renset for oplysninger, der ikke må bruges til formålet.
- De typiske opgaver, som funktionen er bygget til.
- De svære tilfælde: uklare spørgsmål, sjældne fagudtryk, lange tekster og dansk blandet med engelsk.
- Spørgsmål, hvor det rigtige svar er “det ved jeg ikke”. De afslører, om funktionen digter.
- Forsøg på at få funktionen til at gøre noget, den ikke må, se prompt injection.
- Hver fejl, en kunde har meldt. Når en fejl er rettet, kommer den ind i samlingen og bliver der.
Det sidste punkt er det mest værdifulde. Samlingen bliver jeres hukommelse om, hvad der er gået galt.
Tre måder at bedømme på
Eksemplerne er kun nyttige, hvis nogen eller noget bedømmer svaret.
- Faste kontroller. Noget kan kontrolleres med almindelig kode: indeholder svaret det rigtige tal, peger kildehenvisningen på et dokument, der findes, og overholder svaret det aftalte format? Det er billigt og pålideligt.
- Bedømmelse af en anden model. En model kan vurdere, om et svar lever op til en beskrivelse. Det egner sig til vurderinger som “svarer på spørgsmålet” eller “bygger kun på kilden”. Metoden er selv upræcis, så den skal holdes op mod menneskers vurdering med jævne mellemrum.
- Mennesker, der kender faget. En person fra support eller en fagperson hos jer bedømmer et udsnit. Det tager tid, og det er det, der gør de to andre metoder troværdige.
Lad kørslen give et enkelt resultat pr. kategori, som kan sammenlignes med sidste kørsel. Fordi svarene varierer, bør vigtige eksempler køres flere gange, så en tilfældig afvigelse ikke tolkes som en forbedring eller en forværring.
Hvornår testen skal køre
Kør samlingen ved hver af disse ændringer:
- instruktionerne til modellen ændres,
- modellen eller modelversionen skiftes,
- måden, data findes og hentes frem på, ændres,
- funktionen får nye data eller nye værktøjer.
Bind samlingen ind i den automatik, der bygger og udgiver produktet, så en ændring stoppes, når resultatet falder under den aftalte grænse. Det er samme tankegang som ved mindre og hyppigere udgivelser. Lås desuden modelversionen, hvor udbyderen tillader det, så et skift bliver noget, I selv vælger, og køres gennem testen først. Er en version ved at udgå, så planlæg skiftet i god tid.
Testen stopper ikke ved udgivelsen. I drift skal I følge brugernes meldinger og lægge nye fejl ind i samlingen, som beskrevet i demoen virker.
Sådan læser ledelsen resultatet
En ledelse behøver ikke se den enkelte test. Bed om én side, der svarer på fire spørgsmål:
- Hvor godt klarer funktionen sig på de vigtigste kategorier, og hvordan er udviklingen siden sidst?
- Hvor fejler den, og hvad betyder det for kunderne?
- Hvor er grænsen for, hvad vi udgiver, og hvem har besluttet den?
- Hvor stor er samlingen, og hvornår blev den sidst udvidet?
Grænsen skal afspejle, hvad en fejl koster. En funktion, der foreslår tekst, som brugeren altid læser, kan have en anden grænse end en, der fylder felter ud i et regnskab. Lad det stå i de tekniske beslutninger, I skriver ned, så grænsen ikke flytter sig stille og roligt, når en lancering er tæt på.
Tænkt eksempel: et softwarehus skifter til en nyere modelversion, fordi den er hurtigere. Testen viser, at de fleste svar er blevet bedre, mens svar på spørgsmål med dansk fagsprog er faldet. Det er en beslutning, ledelsen kan tage med åbne øjne, i stedet for at høre det fra kunderne en måned senere.
Det skal I lade være med
- At teste med de samme fem spørgsmål, som demoen brugte · de er valgt, fordi de virker.
- At lade udviklerne alene afgøre grænsen · kvalitet er en beslutning om kundens oplevelse.
- At skifte modelversion uden kørsel af samlingen · selv en mindre opdatering kan flytte svarene.
- At kopiere kundedata ind i testen uden at tænke sig om · samlingen skal følge jeres egne regler for data.
Det skal I kræve af den eksterne
- ☐ En plan for, hvordan samlingen bygges op, og hvem der ejer den.
- ☐ En enkel oversigt over kvalitet, som ledelsen kan læse uden fagord.
- ☐ En aftalt grænse for udgivelse, sat sammen med produktansvarlig.
- ☐ Regler for skift af modelversion, også når udbyderen tager initiativet.
- ☐ Krav til leverandøren om test, hvis en anden bygger funktionen.
Senest gennemgået: november 2026.
Næste skridt
Læs også: AI-funktioner i produktet: de tekniske valg · Hvornår er en leverance færdig?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
