Indholdsansvarlige, systemejere og udviklere, der driver en RAG-chatbot efter etableringen
Aftal hvem der ejer viden efter lanceringen
Når chatbotten er åbnet, ændrer virksomhedens viden sig fortsat. Vilkår rettes, produkter udgår, medarbejdere skifter rolle, og dokumenter bliver erstattet. En løsning, der kun er testet på den første upload, har endnu ikke dokumenteret denne del af driften.
Placér derfor ansvar for både indhold og teknik. En faglig ejer afgør, hvilken tekst der gælder. En systemejer sikrer, at godkendte ændringer bliver indlæst og kontrolleret. Support eller drift skal vide, hvem der reagerer, hvis et job fejler, eller chatbotten viser en gammel oplysning.
Begynd med en enkel aftale om friskhed: hvor hurtigt skal en godkendt ændring slå igennem, og hvilke oplysninger må ikke bruges, mens opdateringen er uafklaret? Forskellige kilder kan have forskellige krav. En historisk projektbeskrivelse og en ændret leveringsbetingelse bør ikke automatisk få samme prioritet. Denne guide handler om at holde en eksisterende vidensbase korrekt afgrænset over tid.
Giv hver kilde et stabilt ID og en ansvarlig
Et dokumentregister er forbindelsen mellem originalmaterialet og det, chatbotten bruger. Registrér mindst kilde-ID, placering, ejer, version, gyldighed og relevant adgangsområde. Et filnavn alene er skrøbeligt, fordi det kan ændres eller genbruges.
Skeln mellem en teknisk ændringstid og en fagligt gældende version. En fil kan være gemt på ny uden ændret indhold, mens et dokument med samme navn kan have helt nye vilkår. Brug en bevidst metode til ændringsdetektion og bevar den dokumentversion, som hvert indeksuddrag stammer fra.
Metadata skal være kontrolleret, når det indgår i adgang. En ukendt kundetilknytning bør ikke automatisk gøre dokumentet tilgængeligt for alle. Beslut, hvordan mangelfulde poster holdes tilbage og bliver rettet. Microsofts dokumentation viser, at ændringsdetektion afhænger af datakilden og dens opsætning; en tilsluttet kilde er ikke bevis for, at alle ændringer opdages korrekt.
| Felt | Formål |
|---|---|
| Kilde-ID | Følg samme dokument gennem navne- og placeringsændringer |
| Version og indholdsfingeraftryk | Afgør hvad der er nyt, og hvad svaret byggede på |
| Faglig ejer og gyldighed | Find ansvarlig og gældende indhold |
| Adgangsområde | Begræns til de relevante brugere |
| Afledte ID’er | Find uddrag, vektorer og resuméer ved ændring |
| Seneste kontrol | Se om opdateringen også er verificeret i søgning |
Kortlæg de kopier og afledninger, løsningen skaber
En PDF kan blive til udtrukket tekst, chunks, embeddings og et ordindeks. Nogle løsninger tilføjer kontekstforklaringer, dokumentresuméer eller grafrelationer. Et færdigt svar kan derefter blive gemt i samtalehistorik eller cache. Alle disse dele har en forbindelse til kilden, men opdateres ikke nødvendigvis automatisk sammen.
Lav et simpelt datakort, der viser lagring og afhængigheder. For hver afledt post bør I kunne finde kilde-ID og version. Hvis en genereret sammenfatning bygger på flere dokumenter, skal den relation også være kendt. Ellers bliver det svært at afgøre, hvad en ændring eller sletning skal påvirke.
Kortet skal være konkret nok til at bruge ved en fejl. “Data ligger i skyen” fortæller ikke, hvor et gammelt svar kommer fra. Angiv de faktiske komponenter og deres ejere, men hold adgangsnøgler ude af registeret. Vurder samtidig, hvilke kopier der er nødvendige. Færre velbegrundede lag gør vedligeholdelse lettere at kontrollere.
Adskil modtaget, behandlet og kontrolleret ændring
En robust opdatering har synlige tilstande. Først opdages en ny version. Derefter udtrækkes og kontrolleres teksten, afledte poster dannes, og den nye version aktiveres i søgningen. Til sidst gennemføres en kontrol med et kendt spørgsmål eller et direkte opslag.
Det præcise forløb afhænger af teknologien. Nogle indekser understøtter målrettede opdateringer, mens andre ændringer kræver genberegning af flere poster. Pinecones dokumentation beskriver eksempelvis opdatering af records; den funktion opdaterer ikke af sig selv alle andre kopier i jeres applikation.
Beslut også, hvad der sker ved fejl undervejs. Må den tidligere version fortsat bruges, eller skal dokumentet midlertidigt holdes ude? En kritisk forkert oplysning kan kræve øjeblikkelig udelukkelse, mens en mindre redaktionel ændring kan følge et roligere forløb. Valget skal være bevidst og synligt. Et job med status modtaget må aldrig fremstilles som en verificeret opdatering af chatbotens viden.
Lad verificerede rettigheder bestemme søgeområdet
Brugerens identitet og tilladelser skal afgøre, hvilket materiale løsningen må læse. Modellen skal ikke selv vælge en kunde eller en afdeling gennem et frit tekstfelt, når det påvirker adgang. Applikationen bør danne de nødvendige afgrænsninger ud fra en betroet rettighedsmodel.
Gennemgå alle veje til indhold. Ord- og vektorsøgning skal følge samme adgangsgrænse. En reranker må ikke modtage uautoriserede kandidater. Et parent-opslag må ikke udvide et tilladt uddrag til et større dokument med andre rettigheder. Kildelinks og forhåndsvisninger skal også kontrolleres.
Microsoft beskriver sikkerhedsfiltrering som en implementeringsmodel, hvor et filter ikke i sig selv autentificerer nogen. Det er et vigtigt skel: korrekte metadata hjælper kun, når de bruges konsekvent af den betroede applikation. Test med to konti, der har forskellige rettigheder, og med næsten ens dokumenter. Kontrollér både svaret, kildelisten og det materiale, modellen faktisk modtager.
Test adgang igen, når en rolle ændres
Rettigheder kan ændre sig uden ændringer i dokumentets tekst. En medarbejder forlader et projekt, en kunde lukkes, eller en mappe bliver intern. Opdateringsprocessen skal derfor kunne reagere på adgangsændringer selvstændigt. Et indholdsfingeraftryk opdager ikke nødvendigvis den type ændring.
Aftal hvor hurtigt ændringen skal håndhæves, og hvilke aktive sessioner eller caches der påvirkes. Et tidligere tilladt svar kan stadig ligge i en samtalehistorik. Beslut, hvordan løsningen håndterer adgang til allerede gemte resultater, og afprøv det med den konkrete rettighedsmodel.
Brug et kontrolleret testforløb: en testbruger får adgang, henter et dokument og mister derefter adgangen. Den næste søgning og de relevante genbesøg må ikke få adgang gennem en gammel genbrugstilstand. Dokumentér, hvad der kontrolleres, og hvad der eventuelt kræver særskilt administration. En rolleændring er først håndteret, når den faktisk får virkning i den relevante brugeroplevelse.
Slet efter kendte relationer og kontrollér resultatet
Sletning skal have et afgrænset mål. Find kilde-ID, dokumentversion og de afledte poster, der skal fjernes eller holdes ude. Brug en tydelig markering af, at kilden ikke længere må være aktiv, så et forsinket importjob ikke genskaber den under oprydningen.
Den konkrete indeksteknologi bestemmer sletteoperationerne. Pinecone beskriver eksempelvis sletning efter ID eller metadata. Microsofts blobindeksering kræver særskilt planlægning af sletningsdetektion og har begrænsninger ved én kilde til mange indeksdokumenter. Overfør derfor ikke en demonstrations sletteadfærd til jeres egen chunking uden kontrol.
Efter operationen skal relevante ID’er og søgninger læses tilbage. Kontrollér også supplerende ordindeks, resuméer og grafrelationer, hvis de indgår. Et succesfuldt API-svar dokumenterer den anmodning, tjenesten accepterede; den samlede RAG-løsning kræver en efterfølgende kontrol af, at materialet ikke længere bruges. Gem en passende status, så fejlede dele kan genoptages uden at slette andre kilder.
Et opdateret indeks kan stadig give et gammelt svar
Undersøg de steder, hvor tidligere resultater genbruges: søgecache, svarcache, applikationslag, browser og eventuel CDN. En gammel besvarelse kan leve videre, selv om det underliggende dokument er opdateret. Bevar derfor en relation mellem genbrugte resultater og de versioner eller adgangsområder, de bygger på.
HTTP-cachekontrol er kun ét lag. RFC 9111 beskriver blandt andet private og no-store, men de indstillinger erstatter ikke applikationens adgangskontrol eller en særskilt cache, som udvikleren har bygget. Et nyt cacheheader rydder heller ikke automatisk alle tidligere kopier i andre systemer.
Planlæg udløb eller målrettet ugyldiggørelse efter ændringer. Ved personlige svar skal cacheinddelingen passe til den verificerede bruger og relevante rettigheder. Test både et nyt spørgsmål og en gentagelse, som tidligere gav cachehit. Hvis kun det nye spørgsmål bruger den korrekte kilde, er opdateringen ikke færdig i den samlede brugeroplevelse.
Placér ansvar for historik, eksport og backup
Skeln mellem en udgået videnskilde og personoplysninger, der skal håndteres efter en slettefrist eller en konkret anmodning. Den dataansvarlige skal vurdere, hvad der gælder i situationen. En teknisk driftshåndbog bør beskrive, hvor de relevante oplysninger findes, og hvordan en besluttet sletning gennemføres.
Datatilsynet fremhæver, at backup også skal indgå i overvejelserne. Når enkeltsletning i en backup ikke er teknisk mulig, skal slettede oplysninger håndteres ved genetablering. En gendannelse må ikke ubemærket bringe fjernet materiale tilbage i det aktive system.
Kortlæg derfor eksportfiler, evalueringsdata og supportkopier sammen med den almindelige historik. En fejlrapport med et helt dokument kan blive en ny kopi, som ingen tænker på ved sletning. Brug kun nødvendige oplysninger i dokumentationen, og giv også loggen en begrundet opbevaring. Aftal proceduren med de ansvarlige frem for at love, at én sletteknap dækker alle kopier og aftaler.
Prøv en ændret regel fra kilde til svar
Forestil jer en vidensbase med en kursusbeskrivelse og et tilhørende afmeldingsvilkår. Den faglige ejer godkender en ny frist. Et kontrolleret testforløb ændrer kilden, registrerer en ny version og finder alle de uddrag og genbrugte svar, som bygger på den tidligere formulering.
Efter opdatering stilles både et direkte spørgsmål om fristen og et opfølgende spørgsmål i en eksisterende testsamtale. Kilde-ID og version kontrolleres sammen med svaret. Testen gentages med en gammel cache og med en konto, der ikke længere har adgang til det interne bilag.
Til sidst afbrydes et opdateringsjob i testmiljøet, og genforsøget gennemføres. Der må ikke opstå dubletter eller et blandet svargrundlag med begge frister. Eksemplet er en testplan, ikke et dokumenteret driftsresultat. Det viser, hvorfor en vellykket upload alene er et for snævert acceptkriterium for vedligeholdelse.
| Kontrol | Forventet tilstand |
|---|---|
| Direkte kildeopslag | Den aftalte version er aktiv |
| Søgning med kendt spørgsmål | Gamle uddrag bruges ikke |
| Gentagelse med tidligere cache | Gammelt svar genbruges ikke forkert |
| Ændret adgangsrolle | Den aktuelle rettighed håndhæves |
| Genforsøg efter afbrydelse | Ingen dubletter eller utilsigtet genoprettelse |
Overvåg friskhed og fejl med en konkret reaktion
En driftsoversigt bør vise seneste opdagede kildeændring, seneste vellykkede behandling og seneste kontrol af søgbar tilstand. Hvis de tre tidspunkter er forskellige, skal forskellen kunne forklares. Et dashboard med kun “job kører” siger for lidt om, hvilken viden chatbotten faktisk bruger.
Aftal reaktion på manglende metadata, fejl i tekstudtræk, gentagne opdateringsfejl og usædvanligt mange fjernede dokumenter. En masseændring kan være korrekt, men bør kunne undersøges, før den får større konsekvenser. Gem en passende mulighed for at afgrænse eller stoppe berørte kilder.
Definér hvem der modtager et problem, og hvad personen skal kontrollere. En alarm uden ejer og handlemulighed bliver let overset. Brug kendte testspørgsmål som en del af opfølgningen, men lad dem ikke være den eneste kontrol. De skal supplere register, jobstatus og stikprøver af faktiske dokumentversioner.
Saml et lille driftsbrief før næste udvidelse
Et driftsbrief kan begynde med fem ting: kilderne, de ansvarlige, opdateringsforløbet, adgangsmodellen og den nuværende sletteprocedure. Tilføj et eksempel på en rettet kilde og et eksempel på materiale, som er fjernet. Beskriv, hvordan I ved, at ændringerne slog igennem.
Hvis svaret i dag er “det regner vi med”, er det et konkret sted at begynde. Moselstudio kan gennemgå dataflow og kontrolpunkter og afgrænse, hvilke dele der kræver bedre sporbarhed eller automatisering. En første samtale behøver ikke indeholde rå kundedata eller adgangsnøgler.
Aftal derefter en leverance med tydelige acceptkriterier: hvilken ændring der skal kunne gennemføres, hvilke systemlag den berører, og hvordan resultatet læses tilbage. Det gør opgaven mulig at gennemgå for både indholdsansvarlige og udviklere og giver et mere realistisk grundlag for løbende drift end en generel aftale om, at vidensbasen “holdes opdateret”.
Det bliver vi ofte spurgt om.
Skal hele vidensbasen genindlæses ved hver ændring?
Ikke nødvendigvis. Inkrementel indeksering kan behandle ændringer målrettet. Større skift i model, skema eller dokumentopdeling kan dog kræve en bredere genindeksering.
Er et slettet dokument automatisk væk fra chatbotten?
Nej. Indeksuddrag, embeddings, resuméer, caches og historik kan have separate livscyklusser. Kortlæg dem og kontrollér den relevante søge- og svaradfærd efter sletning.
Kan adgang styres med et kundenavn i prompten?
Det er ikke en tilstrækkelig adgangskontrol. Den betroede applikation skal bruge verificeret identitet og rettigheder og håndhæve dem gennem alle dataadgange.
Hvad bør vi vise ved en første gennemgang?
En systemoversigt, et eksempel på en opdatering og jeres nuværende adgangs- og sletteprocedure er et godt udgangspunkt. Brug anonymiserede eksempler frem for følsomt produktionsmateriale.
Læs videre ved kilden.
Vores beslutningsmodeller er rådgivning fra Mosel Studio. Tekniske fakta og rammer understøttes af kilderne her.
- Microsoft: Indexer overview
Kildeafhængig ændringsdetektion og efterfølgende indekskørsler.
- Pinecone: Update records
Målrettet opdatering af indeksrecords.
- Microsoft: Security filter pattern
Filterets rolle og den nødvendige eksterne autentifikation og håndhævelse.
- Pinecone: Delete records
Sletning af poster efter ID eller afgrænsende metadata.
- Microsoft: Changed and deleted blobs
Sletningsdetektion og begrænsninger ved én kilde til flere indeksdokumenter.
- IETF: RFC 9111, HTTP Caching
Betydningen og afgrænsningen af HTTP-cachekontrol.
- Datatilsynet: Sletning
Sletning, dokumentation, backup og genetablering.
