Hva er RAG og hvorfor er det nødvendig?

Gevinster:

• Forklarer at RAG injiserer kontekst uten å endre vektene til modellen og arbeider med en "åpen bok eksamen"-logikk
• Sammenligning av RAG med finjustering og lange konteksttilnærminger i henhold til kostnad, aktualitet og bruksscenario
• Liste over trinnene i en typisk RAG-pipeline som består av indekserings- og spørringsfaser

Uansett hvor kraftig en språkmodell (kunstig intelligens som forstår og produserer tekst; vi kaller den kort for kort fra nå av) er, kjenner den ikke kontrakten bedriften din signerte i går, din interne wiki-side (intern kunnskapsbase) eller utgivelsesnotatet som ble publisert i morges. Modellen er begrenset til generell kunnskap frem til datoen den ble opplært; Dette kalles «skjæringsdatoen for utdanning». RAG (Retrieval-Augmented Generation) fyller akkurat dette gapet: den finner bedriftsdokumentene knyttet til spørsmålet, gir det til modellen som kontekst (det vil si tilleggsteksten den vil lese mens den produserer svaret) og får svaret produsert basert på denne konteksten.

I denne enheten vil vi tydelig se hva RAG er, når det foretrekkes fremfor hvilke alternativer, og trinnene i en typisk RAG-rørledning. Alle påfølgende enheter vil utdype delene av dette kartet én etter én.

Den grunnleggende ideen til RAG: Open Book-eksamen

La oss forklare RAG i én setning: "Finn først det relevante dokumentet, la deretter modellen lese det dokumentet og skriv ut svaret deretter."

Den mest nyttige analogien er denne: RAG flytter modellen fra en "lukket bok-eksamen" til en "åpen bok-eksamen." I lukket bokeksamen svarer studenten kun etter hukommelsen; Det er stor risiko for å finne på det du ikke husker. I åpen bok-eksamen svarer studenten ved å se på kilden som er plassert foran seg. I RAG svarer ikke modellen lenger fra sin egen hukommelse, men fra den aktuelle og spesifikke teksten du gir den.

Kritisk poeng: RAG endrer ikke vektene til modellen, det vil si de milliarder av numeriske parametere som modellen har lært. Du omskoler ikke modellen. For hvert spørsmål injiserer du biter av tekst som er relevant for det spørsmålet i ledeteksten (instruksjonstekst sendt til modellen). Så du trenger ikke trene modellen på nytt når et dokument oppdateres; du bare oppdaterer den aktuelle posten i søkedatabasen.

Hint: To spørsmål bestemmer kvaliteten på RAG: (1) Fant du riktig dokument? (2) Leste modellen riktig? Den første er "hentingskvalitet", den andre er "generasjonskvalitet". De to måles og forbedres hver for seg.

RAG, finjustering eller lang kontekst?

Tre veier blir ofte forvirret når man leter etter en løsning på et organisatorisk problem. La oss avklare forskjellene deres. Finjustering er å oppdatere modellens vekter med dataene dine og lære den en ny oppførsel/stil. Lang kontekst betyr å fylle alle dokumenter direkte inn i ledeteksten uten noe valg.

Tilnærming

Hva gjør

Når er det passende?

Kostnad / risiko

RAG

Setter inn det relevante dokumentet som kontekst

Hyppig skiftende, omfattende, spesifikk informasjon

Lav; lett å oppdatere, kilden kan oppgis

Finjustering

Oppdaterer vekter med nye data

Fast stil/format/språkundervisning

Høy; Omskolering kreves ved hver oppdatering

Kun lang kontekst

Fyller alle dokumenter inn i ledeteksten

Lite, stasjonært dokumentsett

Tokenkostnad og risiko for å "miste midtdelen" øker

Som regel: Finjustering lærer modellen hvordan den skal snakke; RAG forteller modellen hva den skal vite. I de fleste bedriftsscenarier blir RAG prøvd først fordi det er billig, kan oppdateres og kan vise kilden til svaret. Lang kontekst er rimelig hvis dokumentsettet er veldig lite og fast (f.eks. en enkelt 20-siders manual); Men med tusenvis av sider er det dyrt og modellen kan savne informasjon midt i lang tekst.

En typisk RAG-rørledning

RAG består av to hovedfaser: indeksering (forberedelse, gjort en gang eller periodisk) og spørring (kjører på hvert brukerspørsmål).

Trinnvis indeksering (frakoblet, uten brukerventing):

1. Samle: Trekk dokumenter fra kilder (PDF, wiki, billettsystem, database, e-post).
2. Chunking: Bryt lang tekst i mindre håndterbare biter.
3. Embed: Konverter hver del til embedding (tallvektoren som bærer betydningen av teksten).
4. Lagre: Skriv vektorene sammen med teksten og metadataene (kilde, dato, autorisasjonsinformasjon) til vektordatabasen.

Steg-for-trinn-spørring (online, mens brukeren venter):

1. Konverter brukerens spørsmål til innebygging.
2. Hent de mest like delene fra vektordatabasen.
3. Plasser disse brikkene + spørsmålet i en ledetekstmal.
4. Få det kontekstuelle svaret og dets kilder fra modellen.

# Konseptuell disposisjon av forespørselsfasen (ikke avhengig av språk)question = "Hvor mange dager med årlig permisjon?"question_vektor = embed(question)parts = vektor_db.search(question_vektor, top_k=4) # most similar partsprompt = f"""Svar på SPØRSMÅLET ved å bruke "konteksten nedenfor." Fitting.CONTEXT:{parts}SPØRSMÅL: {question}"""svar = model.uret(prompt) # f.eks. modell: claude-opus-4-8

Denne flyten er et kart over hvert trinn, som vi vil pakke ut en etter en i påfølgende enheter.

Svak forespørsel / sterk forespørsel

Selv med samme RAG-kontekst endrer kvaliteten på forespørselen svaret.

Svak melding (åpen for modelltilpasning, krever ikke ressurser):

Bruk denne informasjonen og si årlig ferie: {deler}. Spørsmål: {question}

Kraftig ledetekst (jording + «jeg vet ikke»-tillatelse + ressursforespørsel):

Svar kun basert på KONTEKST nedenfor. Hvis det ikke er et klart svar i sammenhengen, skriv "Jeg fant ikke informasjon om dette i dokumentasjonen"; Ikke gjett. Legg til [Source: file_name]-taggen til stykket du stoler på på slutten av svaret. KONTEKST: {pieces} SPØRSMÅL: {question}

Tre minivesker

Sak 1 – HR-assistent (Human Resources). En bedrift har en 340-siders HR-håndbok og ansatte stiller i gjennomsnitt 90 spørsmål om dagen. Finjustering ble forsøkt, men siden manualen ble oppdatert månedlig, ble det nødvendig med omskolering hver gang; Kostnaden nådde tusenvis av dollar per måned. Etter byttet til RAG ble oppdateringen redusert til trinnet "indekser dokumentet på nytt" (minutter) og korrekt svarfrekvens økte fra 71 % til 93 % ved manuell måling.

Tilfelle 2 – Kundestøtte. Supportteamet har 12 000 løste billetter og 800 hjelpeartikler. Det tar i gjennomsnitt 4 minutter for en representant å finne et svar manuelt. Da RAG-assistenten kom med de 5 mest relevante postene og laget et utkast til svar, ble tiden redusert til 40 sekunder; Men teamet innså risikoen for å «se usikker ut ved å bringe feil artikkel» og gjorde det obligatorisk å sitere kilden.

Sak 3 – Lov. Et kontraktsteam spurte "i hvilke kontrakter varer konfidensialitetsklausulen i 5 år?" han stiller spørsmålet. I den lange kontekstforsøket ble 60 kontrakter fylt ut i en enkelt prompt; modellen hoppet over de to midterste kontraktene. Da kun de relevante elementene ble introdusert med RAG, sank token-kostnaden med 80 % og manglende hopp ble tilbakestilt.

Hvorfor trengs RAG?

• Aktuelt: Du får tilgang til informasjon etter treningsskjæringsdatoen.
• Spesiell informasjon: Dine interne dokumenter er ikke inkludert i opplæringen av noen modell; Bare du kan gi.
• Verifiserbarhet: Du kan oppgi kilden til svaret (sitering) - avgjørende for revisjon og tillit.
• Hallusinasjonskontroll: Den er avhengig av teksten som er plassert foran den i stedet for å lage en modell.
• Kostnad: Det er mye billigere og raskere å sette i drift enn finjustering.

Forsiktig: RAG er ikke magi. Hvis du tar inn feil brikke, kommer modellen frem til feil svar og ser "sikker" ut. Husk uttrykket "Hentingkvalitet = RAG-kvalitet".

Vanlige feil

• Tar feil av RAG for finjustering: RAG endrer ikke vektene; Det legger bare til kontekst. Å forveksle disse to vil føre til å velge feil arkitektur.
• Ikke tillate "jeg vet ikke": Hvis ledeteksten lar modellen stå fritt til å fylle ut det tomme, vil det gjøre opp.
• Ikke siterer kilder: Et svar uten kilde kan ikke kontrolleres; Brukeren kan ikke legge merke til feilen.
• Å stappe alt inn i én melding: Lang kontekst ser billig ut, men er dyr og savner den midterste informasjonen.
• Å bli sittende fast i generasjon uten å måle gjenfinningen: Hvis svaret er dårlig, spør først "Kom den rette delen?" bør spørres.

Oppsummert

• RAG er en tilnærming som injiserer dokumenter som er relevante for spørsmålet inn i modellen som kontekst; endrer ikke vektene ("åpen bok eksamen").
• Finjustering lærer stil/format, RAG gir aktuell og spesifikk informasjon; lang kontekst fungerer bra for små faste sett. I de fleste scenarier prøves RAG først.
• Rørledningen har to faser: offline indeksering (chunk + embedding + save) og online spørring (henting + prompt + generer).
• RAG gir aktualitet, spesifikk informasjon, etterprøvbarhet, hallusinasjonskontroll og lave kostnader.
• Kvaliteten på systemet avhenger direkte av kvaliteten på gjenfinningen: feil brikke betyr feil svar.

Søknadsoppgave

Velg en ekte informasjonskilde fra ditt eget team (f.eks. et prosedyredokument eller FAQ-side). (1) Skriv 5 faktaspørsmål om denne kilden. (2) Legg merke til hvilken del av dokumentet som inneholder det riktige svaret for hvert spørsmål - dette blir din "gyldne svar"-liste. (3) Bruk malen "sterk melding" ovenfor, lim inn den relevante delen manuelt som kontekst og spør en modell. (4) Sammenlign svaret gitt av modellen med det gylne svaret og merk som sant/usant. Dette er den første manuelle versjonen av vurderingen som du vil automatisere i fremtidige enheter.

sjekkliste

• [ ] Jeg kan forklare i en setning at RAG ikke endrer vektene, det legger bare til kontekst.
• [ ] Jeg kan skille mellom RAG, finjustering og lang kontekst og når som er passende.
• [ ] Jeg kan telle fasene for indeksering (collect-shred-embed-save) og spørring (embed-fetch-prompt-generate) i rekkefølge.
• [ ] Jeg vet hvorfor jeg la til instruksjonene "hvis det ikke er i kontekst, si at jeg ikke vet" og "siter kilde" i ledeteksten.
• [ ] Jeg kan tilpasse prinsippet om "Hentingkvalitet = RAG-kvalitet" til min egen sak.