En AI-chatbot med egne data bygges ved at forbinde en sprogmodel med en kontrolleret vidensbase, typisk via RAG, embeddings og søgning i dokumenter. Målet er ikke at træne modellen til at huske alt, men at hente relevante kilder, styre adgang og teste svarene systematisk.
En AI-chatbot med egne data bør bygges som en kontrolleret datakæde, hvor RAG, embeddings, søgning, adgangsregler og test arbejder sammen. Fokus ligger på at vælge autoritative kilder, klargøre dokumenter, begrænse dataadgang og måle, om chatbotten faktisk svarer korrekt på realistiske spørgsmål.
Hvad betyder en AI-chatbot med egne data?
En AI-chatbot med egne data er en chatløsning, hvor brugeren kan stille spørgsmål, og hvor systemet henter svargrundlag fra virksomhedens, organisationens eller projektets egne dokumenter. Det kan være manualer, politikker, produktdata, supportartikler, kontraktskabeloner, tekniske beskrivelser, interne procedurer eller offentligt materiale, som er samlet i en afgrænset vidensbase.
Den centrale forskel fra en almindelig chatbot er datakilden. En generel sprogmodel kan formulere svar ud fra sin træning og den aktuelle samtale, men den kender ikke automatisk dine nyeste dokumenter, dine interne processer eller dine adgangsregler. Derfor skal chatbotten kobles til en kontrolleret datakæde, hvor egne data kan hentes frem, når de er relevante.
En god løsning består normalt af fem dele: datakilder, klargøring af dokumenter, søge- eller retrieval-lag, sprogmodel og sikkerhedskontroller. Hvis en af delene er svag, kan chatbotten virke imponerende i korte demoer, men give upræcise, forældede eller utilgængelige svar i daglig brug.
Hvornår er RAG bedre end finjustering?
RAG, retrieval augmented generation, er ofte den mest praktiske metode, når chatbotten skal bruge egne data, som ændrer sig over tid. Metoden lader systemet hente relevante tekststykker fra en vidensbase, før sprogmodellen formulerer svaret. AI Mentors forklaring af Retrieval Augmented Generation uddyber selve mønstret.
Finjustering kan give mening, når du vil ændre modellens adfærd, format eller specialiserede mønstergenkendelse. Den er derimod sjældent den bedste vej til levende produktviden, personalepolitikker, dokumentarkiver eller tekniske vejledninger, fordi indholdet hurtigt kan ændre sig. Hvis du lægger viden ind i en model og senere ændrer dokumenterne, har du stadig et vedligeholdelsesproblem.
En praktisk tommelfingerregel er, at RAG passer til viden, som skal kunne spores, opdateres og afgrænses. Finjustering passer bedre til gentagne opgaveformer, klassifikationer eller særlige sproglige mønstre. Mange produktionsløsninger bruger ikke kun én metode, men kombinerer retrieval, instruktioner, evalueringsdata og klare outputregler.
Hvilke data skal med i vidensbasen?
Byg ikke vidensbasen som en ukritisk mappe med alle dokumenter. Start med de spørgsmål, chatbotten faktisk skal kunne besvare. Lav derefter en liste over de kilder, der er autoritative for netop de spørgsmål. En kundeservicebot kan for eksempel bruge hjælpecenterartikler, returregler, leveringsvilkår og produktmanualer, men ikke nødvendigvis interne salgsnoter eller gamle udkast.
Data bør have ejer, dato, version, sprog, adgangsniveau og dokumenttype. Uden metadata bliver det sværere at afgøre, om chatbotten må bruge et dokument, om det stadig er gyldigt, og om det kun gælder for bestemte kunder, produkter eller lande. Metadata er derfor ikke pynt; det er styring af, hvilke svar der kan gives i hvilken situation.
Hvis du arbejder med personoplysninger, fortrolige kundesager eller interne beslutningsdata, bør afgrænsningen ske før teknikken vælges. En lokal opsætning kan være relevant, hvis data ikke må sendes til en ekstern tjeneste. AI Mentors guide til lokal RAG forklarer den type arkitektur på et mere teknisk niveau.
Hvordan klargøres dokumenter til søgning?
Dokumenter skal normalt renses og opdeles, før de kan bruges godt. PDF’er, websider, regneark og tekstfiler har forskellige strukturer, og rå tekstudtræk kan indeholde menuer, sidefødder, dubletter, skjulte tegn eller tabeller, der mister deres betydning. Hvis chatbotten får rodet materiale ind i vidensbasen, bliver retrieval-laget også rodet.
Det næste skridt er chunking, hvor større dokumenter deles op i mindre tekststykker. Stykkerne skal være store nok til at bevare sammenhæng, men små nok til at et enkelt søgeresultat handler om én tydelig oplysning. En produktmanual kan deles efter afsnit, mens en FAQ ofte kan deles efter spørgsmål og svar.
En enkel klargøringsproces kan se sådan ud:
- Udvælg autoritative dokumenter og fjern forældede kopier.
- Konverter dokumenterne til ren tekst eller struktureret HTML uden navigationsstøj.
- Del indholdet i tekststykker med meningsfulde overskrifter og metadata.
- Tilføj kilde, version, dato, sprog og adgangsniveau til hvert tekststykke.
- Test, om de opdelte tekststykker faktisk kan besvare realistiske spørgsmål.
Den sidste test er afgørende. En teknisk velfungerende pipeline kan stadig give dårlige svar, hvis tekststykkerne ikke indeholder den nødvendige kontekst, eller hvis flere næsten ens versioner af samme dokument konkurrerer i søgeresultatet.
Hvordan bruges embeddings og vektordatabase?
Embeddings er talrepræsentationer af tekst, som gør det muligt at sammenligne betydning i stedet for kun ord. Når dine tekststykker omdannes til embeddings, kan systemet finde indhold, der handler om det samme som brugerens spørgsmål, selv om ordene ikke matcher præcist. AI Mentor har en særskilt forklaring af AI embeddings.
En vektordatabase eller et vektorindeks gemmer embeddings, metadata og henvisninger til kildeteksten. Når brugeren stiller et spørgsmål, bliver spørgsmålet også omdannet til en embedding. Systemet søger derefter efter de mest beslægtede tekststykker og sender dem videre som kontekst til sprogmodellen.
En vektordatabase er ikke altid nødvendig som særskilt produkt. Mindre løsninger kan bruge en hosted retrieval-funktion, et søgeindeks eller en database med vektorunderstøttelse. Det vigtige valg er, om løsningen kan filtrere efter metadata, håndtere adgangsregler, opdatere data sikkert og give stabile søgeresultater på realistiske spørgsmål.
| Valg | Styrke | Risiko ved forkert brug |
|---|---|---|
| Hosted file search | Hurtig opsætning og mindre drift | Mindre kontrol over detaljer i indeks, chunking og dataplacering |
| Vektordatabase | God styring af embeddings, metadata og skalerbar søgning | Kan blive unødigt kompleks for små vidensbaser |
| Hybrid søgning | Kombinerer semantisk søgning med nøgleord og filtre | Kræver test for at vægte resultaterne korrekt |
Hvordan designes svarflowet fra spørgsmål til svar?
Et robust svarflow begynder med at klassificere brugerens spørgsmål. Systemet bør afklare, om spørgsmålet kan besvares fra vidensbasen, kræver et opslag, ligger uden for chatbotten, eller skal sendes videre til et menneske. Hvis alle spørgsmål behandles ens, bliver chatbotten både mindre præcis og sværere at kontrollere.
Derefter henter retrieval-laget relevante tekststykker. De bør rangeres, filtreres og eventuelt efterkontrolleres, før de sendes videre. Sprogmodellen skal instrueres i at bruge det hentede materiale, angive usikkerhed, undgå at gætte ved manglende kilder og holde sig til den rolle, systemet er bygget til.
Et praktisk flow består ofte af disse trin:
- Modtag brugerens spørgsmål og identificer formål, sprog og eventuel adgangskontekst.
- Hent relevante tekststykker fra vidensbasen med semantisk, nøgleordsbaseret eller hybrid søgning.
- Filtrer resultater efter adgang, dokumenttype, dato og kildeprioritet.
- Lad sprogmodellen formulere et svar ud fra det godkendte materiale.
- Kontroller svaret for format, kildehenvisninger, usikkerhed og eventuelle risikoområder.
Svaret bør ikke skjule, når vidensbasen er utilstrækkelig. En chatbot, der tydeligt siger, at den mangler grundlag, er ofte mere brugbar end en chatbot, der fylder hullerne ud med sandsynlige formuleringer.
Hvordan vælger du model, værktøjer og infrastruktur?
Valget bør begynde med kravene, ikke med et bestemt modelnavn. Afklar først datatyper, sprog, forventet mængde spørgsmål, krav til svartid, krav til dataplacering, adgangsstyring og behov for integrationer. En intern HR-chatbot, en offentlig supportbot og en teknisk udviklerassistent har forskellige risikoprofiler.
En mindre prototype kan bygges med en hosted model, en filbaseret vidensbase og en simpel webgrænseflade. En produktionsløsning kræver typisk versionsstyring af dokumenter, evalueringsdata, logning, adgangskontrol, overvågning, fejlrapportering og en proces for at opdatere vidensbasen. Det er ofte her, forskellen mellem demo og drift viser sig.
Vælg også, om chatbotten kun skal svare, eller om den må udføre handlinger. En chatbot, der kan oprette sager, sende e-mails, ændre kundedata eller kalde API’er, kræver stærkere kontrol end en ren spørge-svar-løsning. Handlinger bør have begrænsede rettigheder, klare godkendelsesregler og logning.
Hvilke sikkerhedsregler skal bygges ind fra starten?
Sikkerhed starter med datagrænser. Chatbotten bør kun kunne hente de dokumenter, brugeren har ret til at se. Hvis to afdelinger, kunder eller adgangsniveauer deler samme tekniske indeks, skal retrieval-laget håndhæve rettighederne, før sprogmodellen får materialet. Det er ikke nok at skjule følsomme svar i brugerfladen bagefter.
Derudover skal systemet kunne modstå manipulerende input og skjulte instruktioner i dokumenter. Egne data er ikke automatisk troværdige, bare fordi de ligger i en intern mappe. Dokumenter kan være forældede, kopierede, fejlagtige eller påvirket af tekst, som forsøger at styre chatbotten væk fra dens formål.
Hvis chatbotten behandler personoplysninger, bør du afklare formål, dataminimering, opbevaring, adgang og sletning. Det er også relevant at undersøge lovkravene for AI-chatbots, fordi krav kan afhænge af rolle, sektor, brugssituation og datatyper. Denne afklaring bør ske som en del af systemdesignet, ikke først efter lancering.
Hvordan tester du kvaliteten før lancering?
Test bør måle hele kæden, ikke kun om sprogmodellen lyder flydende. Start med et sæt realistiske spørgsmål, som dækker simple opslag, flertydige spørgsmål, forældede dokumenter, manglende data, adgangsbegrænsninger og risikable emner. For hvert spørgsmål bør der findes et forventet svargrundlag og en vurdering af, hvilke kilder der er acceptable.
Mål mindst fire ting: om retrieval-laget finder de rigtige tekststykker, om modellen bruger dem korrekt, om svaret afviser eller afgrænser ved manglende grundlag, og om sikkerhedsreglerne virker. Hvis testen kun vurderer det færdige svar, kan du overse, at chatbotten fik det rigtige svar af den forkerte grund.
En nyttig testtabel kan indeholde spørgsmål, forventet kilde, faktisk hentet kilde, svarvurdering, fejltype og rettelse. Over tid bliver tabellen en regressionstest: Når du ændrer model, chunking, indeks, dokumenter eller adgangsregler, kan du se, om kvaliteten bliver bedre eller dårligere.
Hvordan holdes chatbotten opdateret?
En chatbot med egne data bliver hurtigt forældet, hvis datakilderne ikke har en fast opdateringsproces. Når et dokument ændres, skal det nye indhold udtrækkes, deles op, indlejres på ny og gøres søgbart. Hvis et dokument slettes, bør både tekststykker, embeddings, metadata og eventuelle cachede resultater håndteres.
Der bør være en tydelig ejer for hver datakilde. Ejeren skal kunne godkende ændringer, angive gyldighed, fjerne forældede versioner og reagere på fejlmeldinger fra brugere. Uden ejerskab bliver chatbotten et teknisk lag oven på et uklart dokumentarkiv, og så bliver kvaliteten svær at forbedre.
Logning kan hjælpe, hvis den bruges disciplineret. Spørgsmål, søgninger, valgte kilder, afvisninger og brugerfeedback kan afsløre huller i vidensbasen. Logs kan dog selv indeholde følsomme oplysninger, så de skal behandles med samme forsigtighed som andre driftsdata.
Hvad koster kompleksiteten i drift og vedligehold?
De synlige omkostninger er modelkald, hosting, database, udvikling og eventuelle licenser. De mindre synlige omkostninger ligger ofte i dataklargøring, adgangsstyring, kvalitetstest, support, overvågning og løbende rettelser. En chatbot med egne data er derfor ikke kun et AI-projekt; det er også et informationsarkitekturprojekt.
Kompleksiteten stiger især, når chatbotten skal dække mange datakilder, flere sprog, forskellige adgangsniveauer eller handlinger i eksterne systemer. Hver ny datakilde kræver beslutninger om ejerskab, opdatering, rettigheder, kvalitet og fejlretning. Hver ny handling kræver beslutninger om ansvar, godkendelse og logning.
En fornuftig start er en smal version med få autoritative datakilder og tydelige succesmål. Når den virker stabilt, kan den udvides. Det giver bedre læring end at begynde med alle dokumenter, alle brugergrupper og alle integrationer på én gang.
Hvilke fejl bør du undgå?
Den første fejl er at tro, at flere dokumenter automatisk giver bedre svar. Flere dokumenter kan også betyde flere dubletter, flere forældede versioner og flere modstridende kilder. En mindre, kurateret vidensbase kan være mere præcis end et stort arkiv uden ejerskab.
Den anden fejl er at teste chatbotten med for pæne spørgsmål. Brugere skriver ufuldstændigt, blander emner, bruger interne forkortelser og spørger om ting, som ikke findes i materialet. Testen bør derfor indeholde realistiske fejl, uklare formuleringer og spørgsmål, chatbotten skal afvise eller sende videre.
Den tredje fejl er at lade modellen få mere adgang end nødvendigt. Hvis chatbotten kun skal svare på produktmanualer, bør den ikke samtidig have adgang til kundedata, økonomisystemer eller interne sagsmapper. Begrænset adgang gør systemet lettere at forklare, teste og styre.
Den fjerde fejl er at mangle en plan for fejl. Brugerne skal kunne rapportere dårlige svar, og teamet bag chatbotten skal kunne se, om fejlen skyldes datakilden, chunking, retrieval, modellen, adgangsregler eller en uklar brugerforespørgsel. Uden denne opdeling bliver fejlretning gætteri.
Hvilke kilder ligger til grund?
Den tekniske gennemgang bygger blandt andet på Microsofts dokumentation om RAG i Azure AI Search, OpenAI-dokumentationen om file search og OpenAI-dokumentationen om embeddings.
Sikkerheds- og datadelen er afstemt med NIST AI Risk Management Framework og EUR-Lex-teksten til GDPR-forordningen. Kilderne understøtter artiklens skelnen mellem retrieval, datastyring, risikostyring og persondatahensyn.