Skjemaet har blitt sendt inn.
Mer informasjon finner du i postkassen din.
Lei oss 
Om oss 
Teknologier Portefølje
Lei oss 
Hvis du allerede har prøvd en LLM-chatbot på jobben, vet du hvor skoen trykker: Den høres selvsikker ut, men så spør noen om en detalj i retningslinjene, en produktregel eller den siste interne prosessen, og svaret er feil eller vagt. Teamet ditt ender opp med å dobbeltsjekke alt, søke gjennom PDF-er og wikier uansett, og bekymre seg for hvem som nettopp så hva i chatten.
En RAG-chatbot kobler en LLM til godkjent bedriftskunnskap på spørsmålstidspunktet. Den henter de riktige passasjene fra dokumentene dine, bruker dem som grunnlag for svaret, og kan vise kildeteksten slik at folk kan verifisere den. Tilgangsregler kan være en del av oppsettet, slik at boten ikke viser sensitivt innhold til feil person.
I denne guiden vil jeg forklare Definisjon av RAG-chatbot, hvordan Retrieval-Augmented Generation fungerer, hvor det passer best, og hvordan du implementerer det trinn for trinn, inkludert de funksjonene og sikkerhetskontrollene team vanligvis trenger i virkelige miljøer.
En RAG-chatbot, eller gjenfinning utvidet generasjon chatbot, LLM er en chat-assistent som svarer med dataene dine rett foran seg. Før den svarer, søker den i dokumentene, databasene eller API-ene dine etter de mest relevante delene, og deretter skriver LLM svaret ved hjelp av den konteksten som er hentet. Kontrasten er enkel. En vanlig LLM svarer basert på det den husker (fra tidligere innlagte data). A RAG AI chatbot svar etter den sjekker kildene dine, noe som reduserer hallusinasjoner og legger til kildehenvisninger for å underbygge påstandene.
For å forstå RAG chatbot betydning uten sjargong, se for deg dette. Mandag morgen. Du skal bestille en 9-timers flyreise for en kunde, og du vil (helt sikkert) være rask, så du sender en melding i chatten for å sjekke om selskapet ditt dekker premium økonomi for flyreiser på over 6 timer. Den grunnleggende boten svarer ja med en gang. Du bestiller. Det er gjort.
To uker senere blir utgiftskravet ditt avvist. Uten at du visste det, ble retningslinjene endret i forrige kvartal, og det ble lagt til et nytt godkjenningstrinn. Nå har du en dialog med økonomiseksjonen, sjefen din blir trukket inn, og du graver deg gjennom wikien for å prøve å bevise hva regelen egentlig er.
De flesta RAG-drevet chatbot håndterer det samme spørsmålet ved å sjekke reisepolicyen først, sitere den eksakte regelen og droppe lenken. Du bestiller det riktige, eller du får godkjenning først. Uansett, ingen overraskelse senere.
Forskjellene er lettere å forstå når vi ser på vanlige eksempler:
Du kan vanligvis se i løpet av uke én om en chatbot vil holde seg. Hvis folk ikke kan stole på svarene, slutter de å bruke dem. Hvis de ikke kan sjekke kilden, slutter de enda raskere. RAG gir dem noe solid å lene seg på. Her er de gevinstene jeg oftest ser når det fungerer:
Vi har bygget mange dokumenttunge systemer for interne team: retningslinjer, kunnskapsbaser, portaler, hele pakka. Så vi vet hva som går i stykker først. Hvis du planlegger en RAG-chatbot for en bedrift, er dette de funksjonene teamene spør mest etter. Ikke fordi de høres kule ut. Fordi de redder deg når de virkelige brukerne dukker opp.
Når en bot svarer uten å vise kilden, nøler folk fordi de ikke kan stole fullt ut på den. Kildeangivelse legger til en lenke eller merknad til det nøyaktige dokumentet og delen svaret kommer fra. Så når noen spør: “Hvor kom det fra?”, kan boten peke på kvitteringen i stedet for å tvinge folk til å lete gjennom wikien.
Noen spørsmål er nøkkelord som feil 0x801c03f3, et delenummer eller en policy-ID. Andre er bare hvordan folk snakker, for eksempel “Hvorfor feiler denne etter oppdateringen?” Hybridsøk dekker begge deler. Det kjører søkeordssøk (BM25) sammen med vektorsøk, slik at boten kan matche den eksakte strengen og likevel fange opp hensikten bak spørsmålet. Uten det får du de irriterende feilene. Du spør om en eksakt kode eller ID, dokumentet har den eksakte koden, og boten trekker fortsatt feil side eller sier at den ikke fant noe.
Folk snakker ikke til roboter på samme måte som de snakker til et søkefelt. De skriver raskt, hopper over detaljer og dropper vage oppfølginger. Omskriving av spørsmål løser dette før søket i det hele tatt starter. Den rydder opp i skrivefeil, fyller ut manglende kontekst der den kan, og gjør et uklart spørsmål om til noe systemet faktisk kan slå opp. På denne måten unngår du LLM RAG chatbot tar tak i feil dokument fra første trinn.
Søk gir sjelden én perfekt match. Det gir deg en haug med treff som er nære nok. Og modellen har en tendens til å ta det første den ser, og bygge svaret rundt det. Omrangering løser dette. Den tar de beste resultatene, rangerer dem på nytt og setter de beste først før modellen begynner å skrive. Forskjellen er åpenbar i praktisk bruk. Du får færre rare omveier og færre svar basert på feil avsnitt.
De fleste bedriftsdokumenter er lange, og den nyttige delen er sjelden i første avsnitt. Uten komprimering henter boten inn hele avsnitt, og svaret begynner å vandre. Takket være komprimering reduserer den kilden til de få linjene som faktisk er viktige for spørsmålet, og dropper resten. Dermed får du et renere svar.
En lenke til en sitering er bedre enn ingenting, men den sender deg likevel inn i en gigantisk PDF-fil, og du bruker fem minutter på å lete etter én setning. Med forhåndsvisning av sitater slipper du det. Du holder musepekeren over sitatet, og LLM RAG chatbot viser nøyaktig hvilke linjer som er brukt. Du sjekker det på to sekunder og går videre.
Ekte chat er en kjede, ikke et enkelt spørsmål. Du spør om noe, får et svar og fortsetter. Samtaleminnet holder boten på tråden, slik at den forstår hva du refererer til og kan fortsette uten å tilbakestille. Uten dette glemmer boten, du må gjenta alt på nytt, og chatten begynner å føles som et skjema med ekstra trinn.
Teamene oppbevarer nøkkelinformasjon i tabeller, diagrammer, skjermbilder og skannede PDF-filer. En bot som kun bruker tekst, kan ikke lese dette innholdet, og kan dermed gå glipp av detaljer som er avgjørende for svaret. Med multimodal støtte kan boten lese disse formatene og bruke dem i svaret. Denne funksjonen er viktig i håndbøker og finansrapporter, der svaret ofte ligger i én tabellcelle.
Den chatbot ved hjelp av RAG må følge tilgangsreglene dine, på samme måte som alle andre ansatte, inkludert de rotete tilfellene der ett dokument har åpne og begrensede seksjoner. Gjør du dette feil, blir utrullingen blokkert. Gjør du det riktig, kan folk bruke chatten uten å bekymre seg for at den skal røpe noe de ikke burde.
Noen miljøer trenger strengere kontroller rundt integritet og misbruk. En tilnærming jeg har sett i en referanseimplementasjon, er å legge til et blokkjedelag for styring. Det kan lagre poster på en måte som kun er knyttet til vedlegg, mens smartkontrakter kjører styringsregler ved hjelp av stemmegivning og konsensus for regelhåndhevelse. Men du trenger ikke dette for alle prosjekter. Vurder det når du ønsker sterkere kontroll over hvordan innhold og tillatelser endres over tid.
RAG-systemer angripes på spesifikke måter. Prompt-injeksjon og forgiftet innhold er vanlig. Du kan legge til overvåking som gjennomgår chat-logger for å se etter risikable mønstre, skanner dokumenter for tegn på forgiftning og overvåker dataflyten for uvanlig aktivitet. Hvis noe ser mistenkelig ut, flagges det og dirigeres til en responsbane, for eksempel blokkering av kilden, varsling av sikkerhetsavdelingen eller fremtvinging av et gjennomgangstrinn.
Du trenger ingen fancy grunn til å bygge dette. Hvis teamet ditt stadig spør om det samme, og svaret allerede er skrevet ned et sted, betaler du søkeskatten. En bot som kan sitere kilden, reduserer denne smerten raskt. Jeg har samlet de brukstilfellene der dette gapet er størst.
Tradisjonelle chatboter holder seg vanligvis til en fast meny med spørsmål. Hvis du går utenfor den, går de i stå. En RAG-drevet chatbot kan slå opp svaret i kildene du kobler til, slik at svarene samsvarer med det som faktisk står i dokumentene og systemene dine.
Velg først ett fokusert domene, for eksempel supportdokumenter, interne retningslinjer eller IT runbooks. Skriv ned de viktigste spørsmålene du ønsker å dekke, og definer hva som teller som et riktig svar. Bestem hva boten skal gjøre når kildene ikke støtter et svar. For eksempel ved å henvise brukeren til riktig dokumentdel, eller stille et oppfølgingsspørsmål for å avgrense forespørselen.
Begynn med å liste opp alle kildene du forventer at LLM RAG chatbot som skal brukes, hvem som eier den, hvor aktuell den er og hvilke tilgangsregler som gjelder. Deretter rydder du opp i det som kan bli vanskelig å hente senere:
Hvis retningslinjene endres ofte, bør dere bli enige om en enkel versjonsregel, slik at gamle utkast ikke vinner hele tiden. Lagre også tillatelser sammen med dokumentene, og håndhev dem hver gang boten henter innhold.
Kvaliteten på gjenfinningen avhenger av to ting: hvordan du deler opp innholdet og hvordan du merker det. Når det gjelder retningslinjer og prosedyrer, bør du dele opp etter seksjoner og overskrifter, slik at teksten som hentes opp, er lesbar alene. Legg til en liten overlapping, slik at du ikke klipper en regel over to deler. Fjern gjentakelser slik at kopierte avsnitt ikke dominerer gjenfinningen. Når tekstblokkene er oppstykket og renset, sender du dem gjennom en innbyggingsmodell for å konvertere dem til vektornumre, slik at databasen senere kan søke etter betydning og kontekst.
Legg til metadata du vil filtrere på senere (tittel, seksjon, dato, team, region, produkt, versjon). Angi utløsere for reindeksering, for eksempel en dokumentoppdatering, en ny versjon eller en endring i tillatelser. Kjør tekstuttrekk og kvalitetskontroller for PDF-filer og skanninger, slik at du ikke indekserer ødelagt tekst.
Som du allerede vet, trenger en RAG-chatbot noen få deler som fungerer sammen:
Nå har du et reelt valg: Velg et ferdig oppsett, eller bygg din egen stabel.
Med ett klikk får du raskt en demo. Men det gjør det også vanskelig å gjøre endringer senere. En stabel du har kontroll over, gir deg rom for å flytte. Med et React-brukergrensesnitt med Python-tjenester bak kan du for eksempel bytte LLM-leverandør eller hentelag uten å bygge om alt.
Her anbefaler jeg å velge det andre alternativet hvis du ønsker å beholde kontrollen når ting endrer seg.
Tillatelseslekkasje er en feil som det er vanskelig å komme seg etter. For eksempel stiller en nyansatt et harmløst spørsmål om lønn. Den RAG-drevet chatbot går på leting, henter en linje fra administrerende direktørs private mappe og legger den inn i chatten. Nå er det et selskapsproblem.
Derfor må tillatelser være en del av gjenfinningen. Filtrer under henting ved hjelp av dokumenttilgangslister, gruppemedlemskap og metadatatagger. Kjør de samme kontrollene igjen når brukeren åpner en kildelink.
Planlegg også for delvis tilgang. Noen brukere kan se én del av et dokument, men ikke en annen, og det påvirker chunking og metadata. Hvis brukerne ber om eksakte koder, ID-er eller policynumre, fungerer hybrid gjenfinning (semantisk pluss nøkkelord) ofte bedre enn bare embeddings.
Etter at henting og tillatelser er satt opp, bestemmer du hva som skal vises i svaret. Folk vil ha to ting: svaret og beviset rett under det.
En solid standard ser slik ut:
Sett deretter en regel om å ikke gjette. Hvis det boten har hentet ut, ikke støtter svaret, bør boten si det og enten stille et målrettet oppfølgingsspørsmål eller sende brukeren til kildedelen.
Før du starter, må du teste RAG-drevet chatbot med virkelige spørsmål fra faktiske brukere. Se etter svake punkter, for eksempel når hentingen finner feil seksjon, ikke finner riktig dokument, eller når svaret går utover det som står i kilden. Bruk disse funnene til å justere størrelsen på delene, innstillingene for gjenfinning, metadatafiltre og ledetekster.
Gjør evalueringsprosessen enkel ved å dele den inn i to deler. Først sjekker du om hentingen fant riktig avsnitt. Deretter sjekker du om svaret holdt seg innenfor passasjen. Følg med på treffprosent, sitatdekning og hvor mange svar som støttes av kilden for å måle fremgangen over tid.
Legg til kontroller for prompt injection, registrer hvem som spurte hva, og lagre kildene som brukes for hvert svar. Hvis miljøet ditt er utsatt for høyere risiko, bør du se etter skadelig innhold og merkelig dataflyt som ikke ser ut som den skal. Redigér hemmeligheter og personopplysninger når det er nødvendig, fastsett klare regler for oppbevaring av chattelogger og utdrag som hentes ut, og lag revisjonslogger som viser brukeren, kildene som hentes ut, og det endelige svaret.
Send ut i små utgivelser. Begynn med en pilot, les ekte chatter, fiks det som går i stykker, og utvid deretter tilgangen. Etter lansering kan du oppnevne eiere for innholdsoppdateringer, justering av gjenfinning og endringer i tillatelser. Uten eiere endres dokumenter, mapper flyttes, og boten begynner sakte å gi svar som folk slutter å stole på.
Min erfaring er at en liten pilot vanligvis er ferdig i løpet av fire til åtte uker. Det er ett domene, én chatteflyt som fungerer fra ende til annen, kilder og sitater, pluss grunnleggende tilgangskontroller. Nok til å bevise at boten kan svare og vise at den fungerer. Ikke nok til å bli en hel sideoppgave.
En bredere utrulling tar vanligvis 10 til 16 uker. Den ekstra tiden går med til å hente fra flere kildetyper, håndtere strengere tillatelser, legge til overvåking og logger og teste med de rotete spørsmålene som folk faktisk skriver.
Laget ser vanligvis slik ut:
Du kan også hente inn en ML-sikkerhetsingeniør når prompt injection og forgiftet innhold er en reell risiko. Eller du kan legge til blockchain-kompetanse, men bare når styring med en append-only-post er en del av planen.
Når en RAG-chatbot settes i drift, kan teamene oppnå en produktivitetsøkning på 41% og en økning på 20% i oppdagelsen av innbruddsforsøk. Ganske vilt.
Jeg kan ikke love at du vil se de samme tallene. Disse resultatene kom fra spesifikke konstruksjoner, og detaljene er viktige. I hvert fall ikke før vi har gått gjennom omfanget ditt. Poenget står fortsatt ved lag. Når boten svarer fra godkjente kilder og tilgangsreglene er stramme, går arbeidet raskere, og risikofylt aktivitet oppdages tidligere.
Hvis du vil sjekke om en RAG-chatbot passer for teamet ditt, viser vi deg hva en RAG-basert chatbot er, Vi deler lignende tilfeller, går gjennom brukstilfellene og datakildene dine, og hjelper deg med å utforme en løsning som passer til dine begrensninger.
Den kan bruke interne dokumenter, artikler i kunnskapsbaser, wikisider, supportinnhold og andre tekstkilder du godkjenner. Det viktigste er at du kontrollerer kildene og tilgangsreglene.
Et vanlig eksempel er en chatbot i et internt samarbeidsverktøy der ansatte ber om sammendrag, trekker ut klausuler og sammenligner dokumenter, mens boten returnerer kildesnutter og håndhever visningsgrenser.
Ikke alltid. Mange bruker eksisterende modeller for innbygging og generering, og fokuserer deretter på datapreparering, gjenfinningskvalitet, tillatelser og overvåking.
Vanlige problemer inkluderer henting av feil del, manglende nøkkelkontekst og at prompt injection styrer modellen. Sikkerhetsgjennomganger og overvåking hjelper, i tillegg til svarformater som peker tilbake til kildeteksten.
