Virksomheder med en chatbot eller prototype, som skal godkendes og vedligeholdes
Skriv hvad chatbotten må hjælpe med
Første testdokument bør være en kort beskrivelse af chatbotens mandat. Hvem bruger den, hvilke opgaver kan den afslutte, og hvornår skal den sende sagen videre? En offentlig FAQ-chat og en intern assistent med adgang til kundesager skal ikke godkendes efter samme kriterier.
Beskriv forventet adfærd som konkrete situationer. “Svar professionelt” er vanskeligt at bedømme. “Forklar gældende returvilkår med relevant kilde, og spørg om produkttype, hvis undtagelserne afhænger af den” er mere brugbart. Tilføj hvad løsningen ikke har grundlag eller tilladelse til at afgøre.
Aftal en faglig ejer, som kan vurdere svarene, og en teknisk ejer, som kan undersøge fejl i søgning og integration. NISTs AI RMF Playbook er et frivilligt rammeværk, der kan støtte arbejdet med ansvar, måling og opfølgning. Det erstatter ikke jeres konkrete acceptkriterier og er ikke i sig selv en certificering af chatbotten.
Hent spørgsmål fra arbejdet og gør dem testbare
Saml eksempler fra support, søgninger og de personer, der kender målgruppen. Fjern unødvendige personoplysninger, men bevar de sproglige variationer, som gør spørgsmålene realistiske. En samling pænt omskrevne spørgsmål kan skjule de problemer, rigtige brugere møder med forkortelser, stavefejl og ufuldstændige beskeder.
Fordel eksemplerne efter opgave og sværhedsgrad. Medtag både hyppige spørgsmål og sjældne situationer med stor konsekvens. Brug ikke kun det, prototypen allerede klarer. En enkel efterspørgsel efter åbningstid tester noget andet end et spørgsmål om en kundes konkrete aftale.
Gem også forudsætningerne. Er brugeren logget ind? Hvilken kundesag er valgt? Hvilke dokumentversioner gælder? Et svar kan være korrekt i én sammenhæng og forkert i en anden. Anthropic anbefaler opgavespecifikke evalueringer og kriterier på flere dimensioner; her omsættes det til eksempler fra netop den arbejdsgang, I vil sætte i drift.
Giv hver testcase en forventning og en kilde
Et testkort bør indeholde et stabilt ID, brugerens input, relevant samtalehistorik, adgangsrolle og det materiale, der gælder. Skriv derefter forventet adfærd og eventuelle uacceptable resultater. Det gør testen lettere at gentage efter en ændring.
Facit behøver ikke være én ordret sætning. En chatbot må gerne formulere sig forskelligt, hvis de nødvendige fakta, forbehold og næste skridt er korrekte. Beskriv derfor de udsagn, svaret skal indeholde, og de slutninger, det ikke må foretage. En kildehenvisning skal pege på det konkrete grundlag, der understøtter udsagnet.
Eksempel: Kilden angiver forventet afsendelse, men ingen leveringsdato. Et acceptabelt svar forklarer afsendelsen og markerer den manglende leveringsdato. Et uacceptabelt svar lover ankomst på en bestemt dag. Forskellen er vigtigere end, om begge svar har samme tone eller længde.
| Felt | Illustrativt indhold |
|---|---|
| ID og opgave | SUP-014: forventet levering |
| Forudsætning | Logget ind på den rigtige kundesag |
| Kilde | Ordrestatus med forventet afsendelse |
| Skal ske | Skeln mellem afsendelse og levering |
| Må ikke ske | Opfind en leveringsdato |
| Kontrol | Fakta, kilde, adgang og eventuel handling |
Brug ti forskellige situationer som en første prøve
Ti velvalgte situationer kan være et nyttigt første gennemløb, men er ikke et fuldt godkendelsesgrundlag for enhver chatbot. Vælg dem, så de afslører forskellige fejl. Tabellen er en skabelon, som skal tilpasses jeres mandat og kilder.
Til hver situation tilføjes mindst én realistisk variation, når teamet har set det første resultat. Et opfølgende spørgsmål kan ændre betydningen, og en negation kan vende et behov. Det er derfor ikke nok at teste ti isolerede, velformulerede sætninger.
Bevar et særskilt sæt, som ikke bruges til løbende promptjustering. Ellers risikerer I at forbedre løsningen til de kendte formuleringer uden at lære, hvordan den klarer nye tilfælde. Den afsluttende kontrol skal ligne opgaven, men ikke blot være en gentagelse af udviklerens demonstration.
| Situation | Det I undersøger |
|---|---|
| Et almindeligt spørgsmål | Korrekt svar fra gældende kilde |
| Et upræcist spørgsmål | Relevant afklaring før konklusion |
| Et ukendt emne | Tydelig grænse uden opdigtet viden |
| To modstridende kilder | Synlig konflikt og korrekt prioritering |
| En gammel dokumentversion | Den gældende kilde bruges |
| En personlig sag | Adgang verificeres |
| En anden kundes oplysninger | Ingen lækage i tekst eller kilder |
| En instruktion skjult i et dokument | Opgavens rammer bevares |
| Et fejlet systemopslag | Ærlig fejl og brugbar vej videre |
| Et ønske om et menneske | En fungerende overdragelse |
Bedøm fakta, dækning og oplevelse hver for sig
Brug en lille rubric med tydelige beskrivelser. Faktuel korrekthed handler om, hvorvidt udsagnene følger det relevante grundlag. Dækning handler om, hvorvidt de nødvendige dele af spørgsmålet er besvaret. Kildebrug handler om, hvorvidt dokumentationen faktisk støtter påstandene. Brugeroplevelse handler blandt andet om forståelighed og næste skridt.
Undgå at samle alt i ét uigennemsigtigt gennemsnit. Et venligt svar, som viser en anden kundes oplysninger, er ikke acceptabelt, selv om det scorer højt på sprog. Aftal derfor fejl, der stopper godkendelsen, og andre fejl, som kan prioriteres efter omfang og konsekvens.
Registrér tilfredshed særskilt. Brugere kan være tilfredse med et overbevisende, men forkert svar, eller utilfredse med en nødvendig afvisning. Begge signaler er relevante, men de må ikke erstatte den faglige kontrol. Giv bedømmerne nogle fælles eksempelbesvarelser, så skalaen ikke betyder noget forskelligt for hver person.
Find ud af hvor et forkert svar opstod
Når en testcase fejler, bør I følge forløbet baglæns. Var brugerens behov forstået korrekt? Blev de nødvendige kilder fundet? Kom de rigtige uddrag med i modelinputtet? Blev materialet fortolket korrekt? Og udførte en eventuel integration den handling, den skulle?
Denne opdeling gør rettelser mere præcise. Hvis en kilde mangler i indekset, hjælper det sjældent at skrive en længere prompt. Hvis den rigtige kilde findes, men en gammel version får forrang, skal versionering og filtrering undersøges. Hvis begge dele virker, kan instruktion eller svarverifikation være det næste sted at se.
Gem kun de oplysninger, der er nødvendige for at undersøge fejlen, og følg jeres adgangs- og opbevaringsregler. Et teknisk spor kan ofte bruge dokument-ID’er, versionsnumre og fejlstatus frem for at kopiere hele følsomme samtaler til endnu et system. Testloggen skal hjælpe fejlsøgning uden at skabe en ukontrolleret ny vidensbase.
Test adgang og instruktioner med kontrollerede data
Brug testkonti og syntetiske dokumenter til at undersøge grænser. Opret eksempelvis to kunder med næsten ens sager og forskellige testoplysninger. Kontrollér, at den ene brugers samtale, kildeliste og eventuelle værktøjsresultater aldrig indeholder den andens materiale.
Prøv også et testdokument, der indeholder en instruktion om at ændre opgaven. Chatbotten skal behandle den som dokumentindhold og bevare sit mandat. OWASP beskriver adskillelse af instruktioner og data samt begrænsede værktøjstilladelser som dele af et samlet forsvar. En prompt med et forbud er ikke alene en teknisk adgangsgrænse.
Sikkerhedsfiltre skal dannes af applikationen ud fra verificerede rettigheder. Microsofts dokumentation gør det tydeligt, at et identitetsfelt i et filter i sig selv blot er en streng; den omkringliggende autentifikation og håndhævelse er afgørende. Test derfor alle relevante søgeveje og efterfølgende opslag, ikke kun det første søgeresultat.
Et godt svar er ikke nok, hvis fejlvejen er blind
Afbryd et opslag kontrolleret, gør en testkilde utilgængelig, og lad en integration svare langsomt. Chatbotten skal kunne fortælle, hvad den ikke kunne gennemføre, uden at vise interne detaljer eller påstå, at en handling lykkedes. En fast “tak, vi har modtaget” er misvisende, hvis sagen aldrig blev oprettet.
Overdragelse til et menneske skal afprøves fra brugerens situation til den faktiske modtagelse. Hvilket team får sagen, hvilke oplysninger følger med, og kan brugeren se næste skridt? Brug en aftalt testmodtager, og læs resultatet tilbage i modtagersystemet. En synlig kontaktknap alene dokumenterer ikke et fungerende forløb.
Kontrollér også, at brugeren kan rette fejl uden at begynde forfra. Formularfelter bør bevares ved en leveringsfejl, og fejlbeskeder skal være forståelige og tilgængelige. W3C anbefaler tydelig feedback om fejl og gennemført behandling. Det er relevant, når chatten afsluttes med en kontakt- eller opgaveformular.
Brug en AI-bedømmer som hjælp med egen kontrol
Ved mange svar kan en model hjælpe med at sortere kandidater til gennemgang. Giv den den samme klare rubric, relevante kilder og eksempler på gode og dårlige vurderinger. Lad den pege på det konkrete problem frem for kun at returnere en karakter.
Forskningen i LLM-as-a-judge beskriver blandt andet bias i modelbaserede vurderinger. Derfor bør bedømmeren kontrolleres mod et menneskeligt vurderet udsnit. Undersøg, om den overser en forkert kilde, foretrækker lange svar eller ændrer vurdering, når rækkefølgen af to svar byttes. Resultater fra en forskningsopgave er ikke en garanti for jeres rubric.
Hold faglig uenighed synlig. Hvis to mennesker ikke kan afgøre, hvad et godt svar er, kan det være et uklart krav eller en modstridende kilde. En ekstra modelscore løser ikke nødvendigvis problemet. Afklar kriteriet, før scoret bruges til at vælge en model eller godkende en ændring.
Gentag relevante tests, når noget ændres
En chatbot afhænger af mere end modellens navn. Prompt, dokumenter, embeddingmodel, filtre, søgeparametre og integrationer kan ændre adfærden. Gem derfor et versionsgrundlag sammen med testresultatet. Det skal være muligt at se, hvilken kombination der blev godkendt.
Når en fejl bliver rettet, tilføjes en regressionstest, der fastholder den ønskede adfærd. Gentag også beslægtede sager, så rettelsen ikke kun virker på den præcise formulering. En ændring, der hjælper returspørgsmål, kan eksempelvis gøre reklamationer for restriktive, hvis begreberne blev blandet sammen.
Planlæg kontrollen efter ændringens betydning. En ny dokumentversion kræver især tests af de berørte fakta, mens et modelskift kan kræve et bredere sæt. Brug et separat kontrolmiljø, når eksterne handlinger indgår. Beslut på forhånd, hvordan I går tilbage til en tidligere fungerende konfiguration, hvis den nye version giver kritiske fejl.
Skriv en rapport, der kan bruges til en beslutning
Rapporten skal vise testens omfang, dato, versioner, resultater og åbne begrænsninger. Angiv antallet af sager pr. opgavetype og de fejl, der stopper godkendelsen. Undlad at kalde en lille vellykket stikprøve en dokumenteret løsningsgrad for alle fremtidige samtaler.
Et illustrativt resultat kan være: almindelige FAQ-svar er acceptable i det afprøvede materiale, men kundespecifikke opslag er ikke klar, fordi en adgangstest fejlede. Den konklusion er mere brugbar end et samlet højt procenttal, som skjuler problemet. En afgrænset åbning kan kun være relevant, hvis den tekniske løsning faktisk holder den ikke-godkendte funktion ude.
Beskriv næste skridt med ejer og kontrol. Det kan være en kilderettelse, en ændret filterregel eller en gentest af overdragelsen. Efter åbning bruges reelle fejl til at udvide testsættet, mens logning og gennemgang følger de aftalte datagrænser. Test er vedligeholdelse af et beslutningsgrundlag, ikke en engangsdemonstration.
Forbered ti repræsentative spørgsmål til en gennemgang
Til en første faglig gennemgang kan I samle ti forskellige spørgsmål med de kilder, der skal besvare dem. Medtag mindst et tilfælde uden svargrundlag og et tilfælde, hvor chatbotten skal bede om hjælp. Beskriv også de handlinger og systemer, som indgår efter svaret.
Anonymiser materialet, og fjern adgangsnøgler og unødvendige kundeoplysninger. Vi behøver ikke følsomme produktionssamtaler for at vurdere, om testdesignet mangler centrale situationer. En kort demonstration af den nuværende løsning og et par dokumenterede fejl kan give et konkret udgangspunkt.
Moselstudio kan hjælpe med at gennemgå testkort, bedømmelseskriterier og de tekniske kontrolpunkter. Målet med en indledende vurdering er at afklare, hvad der skal testes og rettes, før løsningen kan bruges inden for sit mandat. Et fuldt testforløb, integrationer og løbende opfølgning kan derefter afgrænses i en konkret leverance.
Det bliver vi ofte spurgt om.
Hvor mange spørgsmål kræver en chatbot-test?
Der findes ikke ét antal, som passer til alle løsninger. Begynd med relevante opgavetyper og kritiske undtagelser, og udvid med variationer og faktiske fejl. Ti spørgsmål er en første gennemgang, ikke en universel certificering.
Kan vi bruge kundernes tilfredshed som kvalitetsmål?
Ja, som et særskilt signal. Det skal suppleres med kontrol af fakta, kilder, adgang og handlinger. Et overbevisende forkert svar kan godt få en positiv vurdering.
Skal testen gentages efter nye dokumenter?
De berørte fakta og relevante grænser bør kontrolleres. Ved ændring af model, søgemetode eller adgangsregler kan en bredere gentest være nødvendig.
Kan Moselstudio teste en eksisterende chatbot?
En gennemgang kan tage udgangspunkt i jeres nuværende løsning, mandat og repræsentative spørgsmål. Adgang, omfang og eventuelle eksterne testhandlinger skal afgrænses til den konkrete opgave.
Læs videre ved kilden.
Vores beslutningsmodeller er rådgivning fra Mosel Studio. Tekniske fakta og rammer understøttes af kilderne her.
- NIST: AI RMF Playbook
Frivilligt rammeværk for ansvar, vurdering og løbende håndtering.
- Anthropic: Define success criteria and build evaluations
Opgavespecifikke og flerdimensionelle evalueringer.
- OWASP: LLM Prompt Injection Prevention
Kontrollerede sikkerhedstests, adskillelse og begrænsede tilladelser.
- Microsoft: Security filter pattern
Skel mellem metadatafiltre og den nødvendige adgangshåndhævelse.
- W3C WAI: User notifications
Tydelig og tilgængelig feedback ved fejl og gennemført behandling.
- Zheng m.fl.: Judging LLM-as-a-Judge
Muligheder og bias ved modelbaseret bedømmelse.
