Vad är RAG och varför är det nödvändigt? — RAG- och AI-agenter

Vinster:

Förklara att RAG injicerar sammanhang utan att ändra vikterna av modellen och arbetar med en logik för "öppen bok tentamen"
Jämför RAG med finjusteringar och långa kontextansatser enligt kostnad, aktualitet och användningsscenario
Lista stegen i en typisk RAG-pipeline som består av indexerings- och frågefaser

Oavsett hur kraftfull en språkmodell (artificiell intelligens som förstår och producerar text; vi kallar den för kortare modell från och med nu) är, så känner den inte till kontraktet ditt företag skrev på igår, din interna wiki-sida (intern kunskapsbas) eller releasenoten som publicerades i morse. Modellen är begränsad till allmän kunskap fram till det datum den utbildades; Detta kallas för "stoppdatum för utbildning". RAG (Retrieval-Augmented Generation) fyller exakt denna lucka: den hittar företagsdokumenten som är relaterade till frågan, ger den till modellen som kontext (det vill säga den ytterligare texten den kommer att läsa medan den producerar svaret) och får svaret framtaget utifrån detta sammanhang.

I den här enheten kommer vi tydligt att se vad RAG är, när det föredras framför vilka alternativ och stegen i en typisk RAG-pipeline. Alla efterföljande enheter kommer att fördjupa delarna av denna karta en efter en.

Grundidén med RAG: Open Book Exam

Låt oss förklara RAG i en mening: "Hitta först det relevanta dokumentet, låt sedan modellen läsa dokumentet och skriv ut svaret därefter."

Den mest användbara analogin är denna: RAG flyttar modellen från en "sluten bok tentamen" till en "öppen bok tentamen." På tentamen med sluten bok svarar eleven endast efter minnet; Det är stor risk att hitta på det du inte kommer ihåg. I öppen bokprovet svarar eleven genom att titta på källan placerad framför honom. I RAG svarar modellen inte längre från sitt eget minne, utan från den aktuella och specifika texten man ger den.

Kritisk punkt: RAG ändrar inte vikterna av modellen, det vill säga de miljarder numeriska parametrar som modellen har lärt sig. Man skolar inte om modellen. För varje fråga injicerar du bitar av text som är relevant för den frågan i prompten (instruktionstext skickas till modellen). Så du behöver inte träna om modellen när ett dokument uppdateras; du uppdaterar helt enkelt den relevanta posten i sökdatabasen.

Tips: Två frågor avgör kvaliteten på RAG: (1) Hittade du rätt dokument? (2) Läste modellen den korrekt? Den första är "hämtningskvalitet", den andra är "generationskvalitet". De två mäts och förbättras separat.

RAG, finjustering eller lång kontext?

Tre vägar blandas ofta ihop när man letar efter en lösning på ett organisatoriskt problem. Låt oss klargöra deras skillnader. Finjustering är att uppdatera modellens vikter med dina data och lära den ett nytt beteende/stil. Långt sammanhang innebär att du fyller i alla dokument direkt i prompten utan något val.

Tillvägagångssätt

Vad gör

När är det lämpligt?

Kostnad/risk

RAG

Injicerar det relevanta dokumentet som sammanhang

Ofta föränderlig, omfattande, specifik information

Låg; lätt att uppdatera, källa kan anges

Finjustering

Uppdaterar vikter med nya data

Fast stil/format/språkundervisning

Hög; Omskolning krävs vid varje uppdatering

Endast långt sammanhang

Fyller alla dokument i prompten

Liten, stationär dokumentuppsättning

Tokenkostnaden och risken att "tappa mittdelen" ökar

Som regel: Finjustering lär modellen hur man pratar; RAG talar om för modellen vad den ska veta. I de flesta företagsscenarier prövas RAG först eftersom det är billigt, uppdateringsbart och kan visa källan till svaret. Långt sammanhang är rimligt om dokumentuppsättningen är riktigt liten och fast (t.ex. en enda 20-sidig manual); Men med tusentals sidor är det dyrt och modellen kan missa information mitt i lång text.

En typisk RAG Pipeline

RAG består av två huvudfaser: indexering (förberedelse, gjort en gång eller periodiskt) och sökning (körs på varje användarfråga).

Steg för steg indexering (offline, utan att användaren väntar):

Samla in: Hämta dokument från källor (PDF, wiki, biljettsystem, databas, e-post).
Chunking: Bryt lång text i mindre hanterbara bitar.
Bädda in: Konvertera varje del till inbäddning (den talvektor som bär innebörden av texten).
Spara: Skriv vektorerna tillsammans med texten och metadata (källa, datum, behörighetsinformation) till vektordatabasen.

Steg-för-steg-fråga (online, medan användaren väntar):

Konvertera användarens fråga till inbäddning.
Hämta de mest lika delarna från vektordatabasen.
Placera dessa bitar + fråga i en snabbmall.
Få det kontextuella svaret och dess källor från modellen.

# Begreppsmässig översikt över förfrågningsfasen (inte beroende av språk)question = "Hur många dagars årlig semester?"question_vektor = embed(question)parts = vektor_db.search(question_vektor, top_k=4) # most similar partsprompt = f"""Besvara FRÅGAN med hjälp av "kontexten nedan." Fitting.CONTEXT:{parts}FRÅGA: {question}"""answer = model.uret(prompt) # t.ex. modell: claude-opus-4-8

Detta flöde är en karta över varje steg, som vi kommer att packa upp en efter en i efterföljande enheter.

Svag prompt / Stark prompt

Även med samma RAG-kontext ändrar kvaliteten på uppmaningen svaret.

Svag uppmaning (öppen för modellanpassning, kräver inga resurser):

Använd denna information och säg årlig semester: {parts}. Fråga: {question}

Kraftfull prompt (jordning + "Jag vet inte"-behörighet + resursbegäran):

Svara endast baserat på KONTEXT nedan. Om det inte finns något tydligt svar i sammanhanget, skriv "Jag kunde inte hitta information om detta i dokumentationen"; Gissar inte. Lägg till taggen [Source: file_name] för den del du litar på i slutet av ditt svar. KONTEXT: {pieces} FRÅGA: {question}

Tre minifodral

Fall 1 — HR-assistent (Human Resources). Ett företag har en 340-sidig HR-handbok och anställda ställer i genomsnitt 90 frågor om dagen. Finjusteringar prövades, men eftersom manualen uppdaterades varje månad krävdes omskolning varje gång; Kostnaden nådde tusentals dollar per månad. Efter bytet till RAG reducerades uppdateringen till steget "indexera om dokumentet" (minuter) och korrekt svarsfrekvens ökade från 71 % till 93 % vid manuell mätning.

Fall 2 — Kundsupport. Supportteamet har 12 000 lösta ärenden och 800 hjälpartiklar. Det tar i genomsnitt 4 minuter för en representant att hitta ett svar manuellt. När RAG-assistenten kom med de 5 mest relevanta posterna och gav ett utkast till svar, reducerades tiden till 40 sekunder; Men teamet insåg risken att "se osäker ut genom att ta med fel artikel" och gjorde källan obligatorisk.

Fall 3 – Lag. Ett avtalsteam frågade "i vilka kontrakt gäller sekretessklausulen i 5 år?" ställer han frågan. I det långa sammanhangsförsöket fylldes 60 kontrakt i en enda uppmaning; modellen hoppade över de två mittersta kontrakten. När endast de relevanta artiklarna introducerades med RAG minskade tokenkostnaden med 80 % och den saknade överhoppningen återställdes.

Varför behövs RAG?

Aktuellhet: Du får tillgång till information efter träningens stoppdatum.
Särskild information: Dina interna dokument ingår inte i utbildningen av någon modell; Bara du kan ge.
Verifierbarhet: Du kan citera källan till svaret (citat) - väsentligt för revision och förtroende.
Hallucinationskontroll: Den förlitar sig på texten som placeras framför den istället för att göra en modell.
Kostnad: Det är mycket billigare och snabbare att sätta i drift än att finjustera.

Varning: RAG är inte magi. Om du tar in fel bit kommer modellen fram till fel svar och ser "säker ut". Tänk på frasen "Hämtningskvalitet = RAG-kvalitet".

Vanliga misstag

Misstar RAG för finjustering: RAG ändrar inte vikterna; Det lägger bara till sammanhang. Att blanda ihop dessa två leder till att man väljer fel arkitektur.
Inte tillåta "Jag vet inte": Om uppmaningen lämnar modellen fri att fylla i det tomma fältet, kommer den att kompensera.
Att inte citera källor: Ett svar utan källa kan inte kontrolleras; Användaren kan inte märka felet.
Kläm ihop allt i en uppmaning: Långt sammanhang ser billigt ut men är dyrt och missar mittinformationen.
Att fastna i generationen utan att mäta hämtningen: Om svaret är dåligt, fråga först "Kom rätt del?" bör frågas.

Sammanfattningsvis

RAG är ett tillvägagångssätt som injicerar dokument som är relevanta för frågan i modellen som kontext; ändrar inte vikterna ("öppen bok tentamen").
Finjustering lär ut stil/format, RAG ger aktuell och specifik information; lång kontext fungerar bra för små fasta uppsättningar. I de flesta scenarier prövas RAG först.
Pipelinen har två faser: offline-indexering (chunk + inbäddning + spara) och online-förfrågan (hämtning + prompt + generera).
RAG tillhandahåller aktualitet, specifik information, verifierbarhet, hallucinationskontroll och låg kostnad.
Kvaliteten på systemet beror direkt på kvaliteten på hämtningen: fel bit betyder fel svar.

Applikationsuppgift

Välj en äkta informationskälla från ditt eget team (t.ex. ett procedurdokument eller FAQ-sida). (1) Skriv 5 faktafrågor om denna källa. (2) Notera vilken del av dokumentet som innehåller det korrekta svaret för varje fråga - detta blir din lista med "gyllene svar". (3) Använd mallen "stark uppmaning" ovan, klistra in det relevanta avsnittet manuellt som sammanhang och fråga en modell. (4) Jämför svaret från modellen med det gyllene svaret och markera som sant/falskt. Detta är den första manuella versionen av bedömningen som du kommer att automatisera i framtida enheter.

checklista

[ ] Jag kan förklara i en mening att RAG inte ändrar vikterna, det lägger bara till sammanhang.
[ ] Jag kan skilja mellan RAG, finjustering och långt sammanhang och när som är lämpligt.
[ ] Jag kan räkna faserna för indexering (collect-shred-embed-save) och fråga (embed-fetch-prompt-generate) i ordning.
[ ] Jag vet varför jag lade till instruktionerna "om det inte finns i sammanhanget, säg att jag inte vet" och "citera källa" till uppmaningen.
[ ] Jag kan anpassa principen om "Hämtningskvalitet = RAG-kvalitet" till mitt eget fall.