Dokumentation af chatbot-svar med kilder: Link-tjek og usikkerhed

En kildeangivelse under et chatbot-svar virker ved første øjekast som en lille detalje. I virkeligheden er den afgørende for, om besøgende kan efterprøve et udsagn, sætte det i den rette kontekst og bruge det sikkert videre. Et link alene er dog ikke nok: Det kan føre til den forkerte side, være forældet eller kun have en løs forbindelse til det påståede indhold. Gode kildehenvisninger kombinerer derfor tekniske oprindelsesdata, en forståelig præsentation og en robust fallback-løsning.

Denne praktiske guide viser, hvordan website-ejere underbygger chatbot-svar med kilder uden at skabe en falsk følelse af præcision. I centrum står koblingen af enkelte udsagn til specifikke kildesteder, verifikation af links, en ærlig visning af usikkerhed samt en review-proces for support-, marketing- og produktteams.

Hvorfor kildehenvisninger er mere end bare pynt

Generative systemer kan formulere indhold overbevisende, selvom et udsagn er ufuldstændigt eller forkert. NIST AI RMF Generative AI Profile beskriver udtrykkeligt sådanne konfabuleringer og påpeger, at selv opdigtede citater fejlagtigt kan øge tilliden. Derfor må en chatbot ikke opfinde passende kilder i efterrationaliseringens navn. Kildehenvisningerne skal stamme fra den faktiske videnkontekst, der blev hentet.

En god kildevisning opfylder tre opgaver: Den viser, hvor et udsagn stammer fra, den gør det muligt at foretage sin egen kontrol, og den afgrænser svarets rækkevidde. Dette er især vigtigt ved priser, dækningsomfang, tidsfrister, tekniske forudsætninger og retningslinjer. Jo større konsekvenserne af et forkert svar er, desto strengere bør kildested, aktualitet og godkendelse kontrolleres.

Fra dokument til dokumenterbart udsagn

Fundamentet lægges allerede ved indlæsningen af videnskilderne. Ud over teksten bør der mindst gemmes kanonisk URL, sidetitel, dokumenttype, sprog, indhentningstidspunkt, indholdsversion og godkendelsesstatus. Ved lange sider har hvert afsnit brug for en stabil tilknytning til kilden. Kun da kan systemet senere forklare, hvilket uddrag der understøtter et konkret udsagn.

Kildeobjekter i stedet for fri URL-generering

Sprogmodellen bør ikke selv have lov til at formulere vilkårlige links. Det er bedre at bruge et struktureret kildeobjekt fra retrieval-laget: et internt kilde-ID, den godkendte mål-URL, en kort sidetitel, det relevante afsnit og en versionsangivelse. Svaret refererer kun til disse ID'er. Først applikationen omdanner dem til sikre links. På den måde kan tilladte domæner, protokoller og link-attributter kontrolleres uafhængigt af modellen.

Dette mønster hjælper også mod tekniske risici. Den aktuelle OWASP-vejledning om Improper Output Handling anbefaler at behandle model-outputs som ikke-betroede input, validere dem og kode dem i henhold til konteksten. For kildelinks betyder det: Ingen uverificerede HTML-fragmenter, ingen farlige protokoller og ingen automatisk klassificering af URL'er som betroede.

Påstand og kildested skal passe sammen

En side kan være emnemæssigt relevant og alligevel ikke understøtte den konkrete påstand. Derfor bør QA-kontrollen tjekke på udsagnsniveau: Er informationen reelt indeholdt i det refererede afsnit? Er forbehold og begrænsninger bevaret? Blev en generel beskrivelse fejlagtigt lavet om til en garanti? NIST-forskningen om evaluering af maskingenererede rapporter fremhæver netop denne forbindelse mellem påstande og kildedokumenter som en forudsætning for verificerbarhed.

I praksis er det i første omgang nok at underbygge de sætninger, der indeholder fakta, tal, betingelser eller handlingsanvisninger. Hilsner og rene dialogmæssige overgange behøver intet kildemærke. Det holder brugerfladen rolig, mens de afgørende udsagn forbliver verificerbare.

Tjek links før og efter publicering

En korrekt kildehenvisning kan senere blive ubrugelig. Sider flyttes, omdirigeringer ændres, eller indhold forsvinder. Et regelmæssigt link-tjek bør derfor registrere HTTP-status, endelig mål-URL, indholdstype og domæne. HTTP-standarden RFC 9110 skelner blandt andet mellem permanente omdirigeringer, ikke-fundne ressourcer og definitivt fjernet indhold. Disse tilstande kræver forskellige reaktioner.

• Succesfuldt svar: Målet er tilgængeligt, indholdstypen er plausibel, og kildestedet eksisterer stadig.
• Permanent omdirigering: Opdater den kanoniske URL efter redaktionelt tjek uden at miste den tidligere version.
• Midlertidig fejl: Marker kilden midlertidigt, tjek igen, og undlad at bruge den stiltiende i kritiske svar.
• 404 eller 410: Bloker kilden, søg efter en erstatningskilde, og kør test af de berørte svar.
• Ændret indhalt: Sammenlign ikke kun linkstatussen, men også det relevante afsnit og dets fingeraftryk (fingerprint).

Det er vigtigt at adskille "URL tilgængelig" og "udsagn stadig understøttet". En HTTP 200-status bekræfter kun den tekniske tilgængelighed. Først en indholdssammenligning viser, om den relevante passage stadig findes.

Vis kilder letforståeligt i chat-grænsefladen

Kilder bør placeres tæt på det understøttede udsagn, for eksempel som nummererede henvisninger eller som en kompakt liste direkte under svaret. Linktekster som "Kilde 1" er i sig selv ikke særlig hjælpsomme. W3C-vejledningen til WCAG 2.2, Link Purpose anbefaler beskrivende linknavne eller en programmatisk genkendelig kontekst. I en chat kan det for eksempel være "Leveringsbetingelser – afsnit om leveringstider".

På mobile enheder må kildelisten ikke dække hele dialogen. Et kort sammendrag med fokus, som kan foldes ud for flere detaljer, er som regel bedre end en bred tabel. Tastaturfokus, screenreader-navn og målvisning skal forblive forståelige, selvom flere kilder understøtter det samme svar.

Vis desuden forskellen på en primær kilde og en supplerende henvisning. En officiel produktside kan dokumentere en ydelsesbetingelse, mens et blogindlæg måske blot leverer en forklaring. Denne vægtning bør stamme fra redaktionelle regler – ikke fra modellens sproglige selvsikkerhed.

Gør usikkerhed synlig, før tilliden svigter

Ikke alle spørgsmål har en entydig, aktuel kildehenvisning. Systemet har derfor brug for definerede tilstande frem for et enkelt konfidens-tal. En praktisk model skelner mellem "dokumenteret", "delvist dokumenteret", "forældet kilde", "modstridende kilder" og "ingen kilde fundet". Svarets formulering følger denne tilstand.

• Ved dokumenteret kan chatbotten svare klart og vise kildestedet.
• Ved delvist dokumenteret nævner den de bekræftede dele og afgrænser uafklarede punkter.
• Ved forældet angiver den datodelen og undgår aktuelle tilsagn.
• Ved modstrid beskriver den forskellen og eskalerer sagen til den ansvarlige afdeling.
• Ved uden kilde stiller den et opfølgende spørgsmål, henviser til en sikker kontaktmulighed eller oplyser gennemskueligt, at der ikke foreligger noget verificeret svar.

En bemærkning som "Dette svar kan indeholde fejl" er for generel til dette formål. En konkret forklaring er langt mere nyttig: "I de godkendte kilder finder jeg ingen aktuel leveringsfrist." Dermed forstår brugeren, hvad der mangler, og hvad det næste fornuftige skridt er.

Opbyg et test-set til kilder og fallbacks

Udvid dit eksisterende svar-test-set med kildebaserede scenarier. Guiden til måling af chatbot-svarkvalitet beskriver Golden Sets og RAG-tests. For kildehenvisninger tilføjes der ekstra kontrolpunkter:

1. Ethvert faktuelt kerneudsagn henviser til mindst én faktisk indlæst kilde.
2. Det refererede afsnit indeholder udsagnet og dets begrænsninger.
3. Intet svar genererer en URL, der mangler i det tilladte kildeobjekt.
4. Omdirigeringer, 404-, 410- og timeout-tilfælde udløser den tilsigtede status.
5. Modstridende kilder fører ikke til en opdigtet syntese.
6. Kilder er letforståelige og tilgængelige via tastatur og screenreader.
7. Dansk og andre målsprog bevarer de samme fakta og kildemål.

Test ikke kun idelle spørgsmål. Brug slåfejl, uklare tidsangivelser, spørgsmål med forkerte antagelser og blandinger af to emner. Modtagelige modeksempler er særligt værdifulde: en passende kilde uden det påståede tal, et teknisk tilgængeligt link med ændret indhold eller to gyldige sider med forskellig gyldighedsstatus.

Redaktionelt flow: fra kilde til godkendelse

Kildekvalitet er en fælles opgave. Indholdsansvarlige vedligeholder ejerskab, gyldighed og prioritet; udviklingsteams sikrer retrieval, URL-validering og output; support eller fagafdelinger tjekker risikofyldte udsagn. Artiklen om Chatbot Content Governance hjælper med at fastlægge roller og godkendelser hertil.

Et smidigt flow består af fem trin: Registrer kilden, udtræk indholdet, versioner relevante afsnit, test svar-kilde-par og aktiver derefter. Ændringer kører igennem disse trin igen. Hvis et problem først opdages i drift, bør en klar Degraded Mode træde i kraft. Vores Incident Response Playbook for AI-chatbots viser, hvordan problematisk indhold kan begrænses og rulles kontrolleret tilbage.

Tjekliste til website-ejere

• Må svar udelukkende citere godkendte kilde-ID'er?
• Er URL, titel, sprog, version, indhentningstidspunkt og godkendelsesstatus gemt?
• Refereres der til det konkrete kildested i stedet for blot hele domænet?
• Tjekker et automatiseret job både HTTP-status og indholdsændringer?
• Er der beskrivende, handicapvenlige linktekster til stede?
• Findes der definerede tilstande for forældede, modstridende og manglende kilder?
• Indeholder test-sættet manipulerede, døde og kun tilsyneladende passende kilder?
• Kan teamet blokere en fejlbehæftet kilde uden at slukke for hele videnbasen?

Konklusion: Behandl verificerbarhed som en produktegenskab

Kildehenvisninger er ikke en kosmetisk tilføjelse. De forbinder retrieval, Content Governance, sikkerhedstjek, tilgængelig UX og redaktionelt ansvar. Et robust system viser kun kilder, det faktisk har brugt, tjekker løbende deres destinationer og formulerer usikkerhed konkret.

Start med et afgrænset område, for eksempel fragt, returnering eller tekniske forudsætninger. Definer ti til tyve vigtige spørgsmål der, knyt udsagn til kildestederne og test også fejltilfælde. Derefter kan mønsteret udvides skridt for skridt. Hvis du vil opbygge en AI-chatbot med efterprøveligt website-indhold, finder du en oversigt på ChatReact-funktionssiden.

Kilder

• NIST: Artificial Intelligence Risk Management Framework – Generative AI Profile
• NIST: On the Evaluation of Machine-Generated Reports
• OWASP: LLM05:2025 Improper Output Handling
• IETF/RFC Editor: RFC 9110 – HTTP Semantics
• W3C WAI: Understanding Link Purpose (In Context)