Question-Answering Systemer

Et question-answering-system besvarer spørgsmål formuleret i naturligt sprog ved at hente relevant materiale fra dine egne kilder og formulere et svar på grundlag af det. Kilderne kan være intern dokumentation, personalepolitikker, produktdata, tidligere supportsager eller et wiki. Sprogmodellen bidrager med forståelse og formulering, mens indholdet kommer fra videnbasen.

Grænsen mod almindelig søgning går ved outputtet. En søgemaskine returnerer en liste af dokumenter og overlader vurderingen til brugeren. Et Q&A-system returnerer en formuleret påstand med henvisning til det materiale, påstanden bygger på.

Grænsen mod chatbots og agenter går ved handling. Et Q&A-system læser og svarer. Så snart løsningen skal oprette sager, opdatere systemer eller udføre transaktioner, er du ovre i agent-territorium med et andet risikobillede og andre krav til test.

Kæden starter med indeksering. Dokumenter hentes fra deres kilder, renses for navigation og boilerplate, deles i chunks på typisk 300 til 800 tokens og beriges med metadata som titel, ejer, dato og adgangsniveau. Hver chunk omsættes til en embedding og gemmes i en vector database sammen med metadata.

Når et spørgsmål kommer ind, omskrives det ofte først, så forkortelser og pronominer bliver eksplicitte. Derefter søges der, gerne som hybrid mellem vektorsøgning og klassisk nøgleordssøgning, fordi produktnavne og fejlkoder sjældent fanges godt af embeddings alene. Et rerank-trin sorterer kandidaterne og skærer ned til de få uddrag, der reelt skal med i prompten.

Til sidst genereres svaret. Prompten indeholder spørgsmålet, de udvalgte uddrag og instruktioner om kun at bruge det fremlagte materiale og markere, når grundlaget mangler. GPT-5.6 Sol og Claude Sonnet 5 er typiske valg til selve svargenereringen, Gemini 3.1 Pro er relevant ved meget lange dokumenter, og GPT-5 nano kan håndtere billige forled som routing og klassifikation af spørgsmålstype.

Kvaliteten afgøres i overvejende grad af retrieval-leddet. Hvis de rigtige uddrag ikke ligger i konteksten, kan ingen model kompensere.

Den hyppigste fejlkilde er ikke hallucination, men forkert fremfinding. Systemet henter et uddrag, der ligner spørgsmålet sprogligt, men handler om en anden afdeling, et andet land eller en tidligere version af produktet. Svaret bliver velformuleret, korrekt citeret og alligevel forkert.

Chunking er et undervurderet valg. Skæres teksten for fint, mister uddragene den kontekst, der gjorde dem meningsfulde, for eksempel en tabelrække uden overskrift. Skæres den for groft, drukner det relevante afsnit i støj og fortrænger andre kilder fra konteksten.

Forældet indhold er et organisatorisk problem mere end et teknisk. Har videnbasen tre versioner af samme politik uden tydelig datering, vil systemet før eller siden vælge den forkerte. Sletning og versionsmærkning i kilden virker bedre end forsøg på at lære modellen at vurdere aktualitet.

Adgangskontrol skal håndhæves i retrieval-leddet, ikke i prompten. Filtrering på brugerens rettigheder skal ske før søgningen, så fortroligt materiale aldrig indlæses i konteksten. En instruktion om ikke at nævne bestemte dokumenter er ikke en sikkerhedsmekanisme.

Endelig håndterer mange systemer dårligt, at spørgsmålet er uklart. Modellen gætter på en fortolkning i stedet for at spørge, og brugeren opdager ikke, at svaret gælder en anden situation end den, der blev spurgt om.

Et Q&A-system uden evalueringssæt kan ikke forbedres kontrolleret. Byg 50 til 200 realistiske spørgsmål med angivelse af, hvilke dokumenter der indeholder svaret. Så kan du måle retrieval og svarkvalitet hver for sig og se, hvor et fald i kvalitet faktisk opstår.

Driften bør bygge på logning af faktiske spørgsmål. Særligt interessant er de spørgsmål, hvor søgningen gav få eller ingen træffere, fordi de peger direkte på huller i dokumentationen. Sådanne huller lukkes ved at skrive materialet, ikke ved at justere prompten.