Hvad er RAG, og hvorfor er det nødvendigt?

Gevinster:

• Forklarer, at RAG injicerer kontekst uden at ændre vægten af modellen og arbejder med en 'åben bog eksamen'-logik
• Sammenligning af RAG med finjustering og lange konteksttilgange i henhold til omkostninger, aktualitet og brugsscenarie
• Liste over trinene i en typisk RAG-pipeline bestående af indekserings- og forespørgselsfaser

Uanset hvor stærk en sprogmodel (kunstig intelligens, der forstår og producerer tekst; vi kalder den kort for kort fra nu af) er, kender den ikke den kontrakt, din virksomhed underskrev i går, din interne wiki-side (intern videnbase) eller udgivelsesnotatet, der blev offentliggjort i morges. Modellen er begrænset til generel viden op til den dato, den blev trænet; Dette kaldes "skæringsdatoen for uddannelse". RAG (Retrieval-Augmented Generation) udfylder netop dette hul: den finder virksomhedens dokumenter relateret til spørgsmålet, giver den til modellen som kontekst (det vil sige den ekstra tekst, den vil læse, mens den producerer svaret) og får svaret fremstillet ud fra denne kontekst.

I denne enhed vil vi tydeligt se, hvad RAG er, hvornår det foretrækkes frem for hvilke alternativer, og trinene i en typisk RAG-pipeline. Alle efterfølgende enheder vil uddybe delene af dette kort én efter én.

Den grundlæggende idé med RAG: Open Book Exam

Lad os forklare RAG i én sætning: "Find først det relevante dokument, få derefter modellen til at læse dokumentet og udskrive svaret i overensstemmelse hermed."

Den mest nyttige analogi er denne: RAG flytter modellen fra en "lukket bog eksamen" til en "åben bog eksamen." I lukket bogeksamen svarer eleven kun efter hukommelsen; Der er stor risiko for at finde på det, du ikke husker. I åben bog-eksamen svarer eleven ved at se på kilden, der er placeret foran ham. I RAG svarer modellen ikke længere ud fra sin egen hukommelse, men ud fra den aktuelle og specifikke tekst man giver den.

Kritisk pointe: RAG ændrer ikke på vægtene af modellen, det vil sige de milliarder af numeriske parametre, som modellen har lært. Man omskoler ikke modellen. For hvert spørgsmål injicerer du bidder af tekst, der er relevant for det pågældende spørgsmål, i prompten (instruktionstekst sendt til modellen). Så du behøver ikke at genoptræne modellen, når et dokument opdateres; du genopfrisker blot den relevante post i søgedatabasen.

Tip: To spørgsmål bestemmer kvaliteten af ​​RAG: (1) Fandt du det rigtige dokument? (2) Læste modellen den korrekt? Den første er "hentningskvalitet", den anden er "generationskvalitet". De to måles og forbedres hver for sig.

RAG, finjustering eller lang kontekst?

Tre veje er ofte forvirrede, når man leder efter en løsning på et organisatorisk problem. Lad os afklare deres forskelle. Finjustering er at opdatere modellens vægte med dine data og lære den en ny adfærd/stil. Lang kontekst betyder at udfylde alle dokumenter direkte i prompten uden nogen valg.

tilgang

Hvad gør

Hvornår er det passende?

Omkostninger/risiko

RAG

Injicerer det relevante dokument som kontekst

Hyppigt skiftende, omfattende, specifik information

Lav; let at opdatere, kilden kan citeres

Finjustering

Opdaterer vægte med nye data

Fast stil/format/sprogundervisning

Høj; Efteruddannelse påkrævet ved hver opdatering

Kun lang sammenhæng

Udfylder alle dokumenter i prompten

Lille, stationært dokumentsæt

De symbolske omkostninger og risikoen for at "miste den midterste del" stiger

Som regel: Finjustering lærer modellen at tale; RAG fortæller modellen, hvad den skal vide. I de fleste virksomhedsscenarier prøves RAG først, fordi det er billigt, kan opdateres og kan vise kilden til svaret. Lang kontekst er rimelig, hvis dokumentsættet er virkelig lille og fast (f.eks. en enkelt 20-siders manual); Men med tusindvis af sider er det dyrt, og modellen kan savne information midt i lang tekst.

En typisk RAG-rørledning

RAG består af to hovedfaser: indeksering (forberedelse, udført én gang eller periodisk) og forespørgsel (kører på hvert brugerspørgsmål).

Trin for trin indeksering (offline, uden bruger at vente):

1. Indsaml: Træk dokumenter fra kilder (PDF, wiki, billetsystem, database, e-mail).
2. Chunking: Bryd lang tekst op i mindre håndterbare stykker.
3. Indlejring: Konverter hver del til indlejring (den talvektor, der bærer betydningen af ​​teksten).
4. Gem: Skriv vektorerne sammen med teksten og metadataene (kilde, dato, autorisationsoplysninger) til vektordatabasen.

Trin-for-trin forespørgsel (online, mens brugeren venter):

1. Konverter brugerens spørgsmål til indlejring.
2. Hent de mest lignende dele fra vektordatabasen.
3. Placer disse stykker + spørgsmål i en promptskabelon.
4. Få det kontekstuelle svar og dets kilder fra modellen.

# Konceptuel oversigt over forespørgselsfasen (ikke afhængig af sprog)question = "Hvor mange dages årlig ferie?"question_vektor = embed(question)parts = vektor_db.search(question_vektor, top_k=4) # most similar partsprompt = f"""Besvar SPØRGSMÅLET ved at bruge "CONTEXT" ikke i konteksten nedenfor. Fitting.CONTEXT:{parts}SPØRGSMÅL: {question}"""svar = model.uret(prompt) # f.eks. model: claude-opus-4-8

Dette flow er et kort over hver etape, som vi pakker ud en efter en i efterfølgende enheder.

Svag prompt / stærk prompt

Selv med den samme RAG-kontekst ændrer kvaliteten af prompten svaret.

Svag prompt (åben for modeltilpasning, kræver ikke ressourcer):

Brug disse oplysninger og sig årlig ferie: {dele}. Spørgsmål: {spørgsmål}

Kraftig prompt (jordforbindelse + "Jeg ved det ikke"-tilladelse + ressourceanmodning):

Svar kun baseret på KONTEKTEN nedenfor. Hvis der ikke er et klart svar i sammenhængen, så skriv "Jeg kunne ikke finde information om dette i dokumentationen"; Lad være med at gætte. Tilføj tagget [Kilde: filnavn] for det stykke, du stoler på, i slutningen af ​​dit svar. KONTEKST: {pieces} SPØRGSMÅL: {question}

Tre mini etuier

Case 1 — HR-assistent (Human Resources). En virksomhed har en HR-håndbog på 340 sider, og medarbejderne stiller i gennemsnit 90 spørgsmål om dagen. Finjustering blev forsøgt, men da manualen blev opdateret månedligt, var der behov for genoptræning hver gang; Omkostningerne nåede tusindvis af dollars om måneden. Efter skift til RAG blev opdateringen reduceret til trinnet "genindekser dokumentet" (minutter), og korrekte svarprocenten steg fra 71 % til 93 % ved manuel måling.

Case 2 — Kundesupport. Supportteamet har 12.000 løste billetter og 800 hjælpeartikler. Det tager i gennemsnit 4 minutter for en repræsentant at finde et svar manuelt. Da RAG-assistenten bragte de 5 mest relevante poster og udarbejdede et udkast til svar, blev tiden reduceret til 40 sekunder; Men holdet indså risikoen ved at "se usikker ud ved at bringe den forkerte artikel" og gjorde kildeangivelse obligatorisk.

Sag 3 — Lov. Et kontrakthold spurgte "i hvilke kontrakter varer fortrolighedsklausulen 5 år?" han stiller spørgsmålet. I det lange kontekstforsøg blev 60 kontrakter udfyldt i en enkelt prompt; modellen sprang de to midterste kontrakter over. Da kun de relevante varer blev introduceret med RAG, faldt token-omkostningerne med 80 %, og den manglende overspringning blev nulstillet.

Hvorfor er der brug for RAG?

• Aktuelt: Du får adgang til information efter træningens skæringsdato.
• Særlige oplysninger: Dine interne dokumenter er ikke inkluderet i uddannelsen af ​​nogen model; Kun du kan give.
• Verificerbarhed: Du kan citere kilden til svaret (citat) - afgørende for revision og tillid.
• Hallucinationskontrol: Den er afhængig af teksten, der er placeret foran den i stedet for at lave en model.
• Omkostninger: Det er meget billigere og hurtigere at sætte i drift end finjustering.

Forsigtig: RAG er ikke magi. Hvis du tager det forkerte stykke ind, kommer modellen frem til det forkerte svar og ser "sikker" ud. Husk sætningen "Gentagekvalitet = RAG-kvalitet".

Almindelige fejl

• Forveksler RAG med finjustering: RAG ændrer ikke vægtene; Det tilføjer blot kontekst. At forveksle disse to vil føre til at vælge den forkerte arkitektur.
• Tillad ikke "Jeg ved det ikke": Hvis prompten lader modellen fri til at udfylde det tomme felt, vil det fyldes op.
• Ikke kildeangivelse: Et svar uden kilde kan ikke kontrolleres; Brugeren kan ikke bemærke fejlen.
• At samle alt i én prompt: Lang kontekst ser billig ud, men er dyr og savner den midterste information.
• At blive hængende i generation uden at måle genfindingen: Hvis svaret er dårligt, spørg først "Ankom den rigtige del?" skal spørges.

Sammenfattende

• RAG er en tilgang, der injicerer dokumenter, der er relevante for spørgsmålet, i modellen som kontekst; ændrer ikke vægtene ("åben bog eksamen").
• Finjustering lærer stil/format, RAG giver aktuelle og specifikke oplysninger; lang kontekst fungerer godt for små faste sæt. I de fleste scenarier prøves RAG først.
• Pipelinen har to faser: offline indeksering (chunk + indlejring + gem) og online forespørgsel (hentning + prompt + generering).
• RAG giver aktualitet, specifik information, verificerbarhed, hallucinationskontrol og lave omkostninger.
• Kvaliteten af ​​systemet afhænger direkte af kvaliteten af ​​hentning: forkert stykke betyder forkert svar.

Ansøgningsopgave

Vælg en ægte informationskilde fra dit eget team (f.eks. et proceduredokument eller FAQ-side). (1) Skriv 5 faktuelle spørgsmål om denne kilde. (2) Bemærk, hvilken del af dokumentet der indeholder det rigtige svar for hvert spørgsmål - dette bliver din "gyldne svar"-liste. (3) Brug skabelonen "stærk prompt" ovenfor, indsæt manuelt den relevante sektion som kontekst og spørg en model. (4) Sammenlign svaret givet af modellen med det gyldne svar og marker som sandt/falsk. Dette er den første manuelle version af vurderingen, som du vil automatisere i fremtidige enheder.

tjekliste

• [ ] Jeg kan forklare i en sætning, at RAG ikke ændrer vægtene, det tilføjer blot kontekst.
• [ ] Jeg kan skelne mellem RAG, finjustering og lang kontekst og hvornår, hvad der er passende.
• [ ] Jeg kan tælle faserne indeksering (collect-shred-embed-save) og query (embed-fetch-prompt-generate) i rækkefølge.
• [ ] Jeg ved, hvorfor jeg tilføjede instruktionerne "hvis det ikke er i konteksten, så sig, at jeg ved det ikke" og "citer kilde" til prompten.
• [ ] Jeg kan tilpasse princippet om "Gentagekvalitet = RAG-kvalitet" til min egen sag.