Back to "RAG förklarade: Ursprung och grundförutsättningar"

This is a viewer only at the moment see the article on how this works.

To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk

This is a preview from the server running through my markdig pipeline

AI AI-Article LLM Machine Learning RAG Semantic Search

RAG förklarade: Ursprung och grundförutsättningar

Saturday, 22 November 2025

Någonsin sökt efter "deployment guide" och fått ingenting, även om det finns en artikel om "publicering till produktion"? RAG (Retrieval-Augmented Generation) löser detta genom att förstå mening, inte bara nyckelord. Denna serie visar dig hur RAG kom till, hur det fungerar under huven, och hur man bygger produktionssystem. Från semantisk sökning till AI-drivna Q&A med citeringar – alla med fungerande C# kod exempel.

Inledning

på serienavigering: Detta är del 1 av RAG-serien (Retrieval-Augmented Generation):

RAG (Retrieval-Augmented Generation) utvecklades för att göra AI smartare – ge LLMs tillgång till information de inte utbildades på. Men här är vad som är intressant: tekniken öppnar möjligheter långt bortom AI chatbots. Det driver semantisk sökning på webbplatser, innehållsrekommendation, skrivhjälp och kunskapshantering.

Den dubbla karaktären: RAG kan hjälpa kunder (bättre sökning, korrekta svar med citeringar) eller utnyttja dem (manipulativa rekommendationer, begrava negativa recensioner, dyka upp upsell innehåll). Skillnaden är inte tekniken-det är intention. En semantisk sökning som hjälper användare att hitta vad de faktiskt behöver? Bra. En som prioriterar vad som gör dig mest pengar medan visas hjälp? Det är mörkt mönster territorium, och det är därför förståelse hur detta fungerar spelar roll.

Här är sanningen om RAG: Det låter skrämmande. Vector inbäddar? Transformer modeller? KV caches? Men som allt annat i programvara, det handlar bara om att förstå hur det fungerar. Du behöver inte veta matematiken bakom transformatorarkitekturer mer än du behöver för att förstå montering för att skriva C#.

RAG i tre steg:

  1. Omvandla texten till siffror (inbäddningar)
  2. Hitta liknande nummer (vektorsökning)
  3. Använd vad du hittade (visa resultat eller mata till LLM)

Resten är genomförandedetaljer.

Denna serie visar hur man bygger RAG-system med fungerande C#-kod. Ingen handvaxning. Inga antaganden. Bara bitar och hur de passar ihop.

Vad du kommer att lära dig i den här serien:

  • Del 1 (denna artikel): Hur RAG kom till och varför det spelar roll
  • Häfte 2: Komplett teknisk arkitektur och LLM internal
  • Häfte 3: Bygga verkliga system med kodexempel

Senare ska jag också visa dig hur du bygger kompletta RAG-system inklusive:

Vad är RAG?

Retrieval-Augmented Generation: Hitta relevant information och använd den sedan.

flowchart LR
    A[User Question] --> B[Retrieve Relevant Info]
    B --> C[Retrieved Documents/Context]
    C --> D[Generate Response]
    A --> D
    D --> E[Grounded, Accurate Answer]

    style B stroke:#f9f,stroke-width:2px
    style D stroke:#bbf,stroke-width:2px

Utan RAG: Användaren frågar → LLM gissningar från minnet → kan hallucinate

För RAG: Användaren frågar → Hitta relevanta dokument → LLM svar med hjälp av dessa dokument → jordade i verkligheten

// Without RAG: Hope the LLM knows
var answer = await llm.GenerateAsync("How do I deploy Docker?");
// Risk: Might make up outdated or wrong steps

// With RAG: Give it the docs
var relevantDocs = await vectorSearch.FindSimilar("How do I deploy Docker?");
var context = string.Join("\n", relevantDocs.Select(d => d.Text));
var answer = await llm.GenerateAsync($"Context: {context}\n\nQuestion: How do I deploy Docker?");
// Result: Answer based on YOUR actual Docker deployment docs

Nyckelinsikt: Separat kunskapslagring (sök) från resonemang (LLM). Uppdatera dina dokument, sök förblir aktuell. Ingen omskolning behövs.

Varifrån kom RAG?

RAG bygger på årtionden av sökning och NLP-forskning. Att förstå denna historia hjälper dig att förstå varför RAG är utformat som det är – och vilka problem det löser.

Traditionell sökning (före 2010)

Nyckelordsbaserad sökning:

  • TF-IDF-värde: Term frekvens × invers dokument frekvens - vanliga ord materia mindre
  • BM25 Ordförande: Probabilistisk ranking - fortfarande baslinje för sökordssökning
  • Fuzzy matchning:
    • Ljudex: Phonetisk algoritm ("Smith" matchar "Smythe")
    • Levenshtein avstånd: Redigera avstånd (hur många tillägg/deltioner/ersättningar)
    • N-Grams: Tecken/ordsekvenser för partiell matchning

Problemet: Dessa matchade tecken, inte betydelseSök "container orkestrering" och du kommer inte att hitta "Docker Swarm" om inte dessa exakta ord visas. De kan hantera stavfel men inte semantik.

Tidigt svar på frågor (2010)

Watson (IBM, 2011):

  • Kombinerad hämtning med regelbaserat resonemang
  • Vann Jeopardy! men krävde massiva handgjorda kunskapsteknik
  • Fortfarande starkt beroende av sökord matchning

Läsförståelsemodeller:

  • Kan hämta svar från angivna avsnitt
  • Men du var tvungen att ge dem rätt passage först
  • Ingen semantisk sökning för att hitta den passagen

Den djupa inlärningsrevolutionen (2017+)

Transformatorer (2017): "Uppmärksamhet är allt du behöver"

  • Neurala nätverk som kan förstå sammanhang
  • Grund för allt som följde

BERT (2018):

  • Sammanhangsmässig förståelse av språket
  • "Bank" betyder olika saker i "driverbank" jämfört med "sparbank"
  • Kan generera inbäddningar som fångade mening

GPT-2/3 (2019/2020):

  • Stora språkmodeller som skulle kunna generera sammanhängande text
  • Men begränsad till deras träningsdata
  • Hallucinationsproblem uppstod

Täta vektorrepresentationer:

  • Text → meningsfulla tal i högdimensionellt utrymme
  • Liknande betydelser → närliggande vektorer
  • Detta gjorde semantisk sökning möjlig

BART (Facebook AI, oktober 2019):

  • Dubbelriktad och automatisk regressiv transformer av Mike Lewis et al.
  • Kombinerad BERT-liknande kodare med GPT-liknande dekoder
  • Denoising autoencoder tränas genom att korrumpera text sedan rekonstruera den
  • Utmärkt för textgenerering och förståelse uppgifter
  • Blev grunden för RAG

M2M-100 (Facebook AI, oktober 2020):

  • Den första flerspråkiga översättningsmodellen
  • Direkt översättning mellan 100 språk utan engelsk pivot
  • 2.200 språkanvisningar (10x mer än tidigare modeller)
  • Visade transformatorer kunde hantera massiva tvärspråkiga uppgifter

Verkligt exempel: Mitt neural maskin översättningsverktyg använder BART som en reservöversättningsmodell när primära tjänster inte finns tillgängliga, vilket visar hur dessa transformatorbaserade modeller blev praktiska byggstenar för produktionssystem.

Modern RAG:s födelse (maj 2020)

Seminariepapperet "Retrieval-Augmented Generation for Knowledge-Intensive NLP uppgifter" av Patrick Lewis et al. (Facebook AI Research) formellt introducerade RAG, bygger direkt på BART:

Vad de kombinerade:

  • Dense Passage Retrieval (DPR) - lärda vektor representationer, inte nyckelord
  • BART generator - den följande 2seq modellen från 2019
  • End-to-end differentiable arkitektur - hämta och generera tillsammans

Resultaten: RAG-system överträffade mycket större modeller på kunskapsintensiva uppgifter samtidigt som de var effektivare och modernare. Du kunde uppdatera kunskapsbasen utan att omskola modellen.

Varför RAG exploderade (2023- närvarande)

ChatgPT, GPT-4 och Claude gjorde RAG nödvändigt:

  1. Hallucinationsproblem - LLM:s hittar på fakta.
  2. Knowledge Cutoff - LLMs utbildade på 2021 data vet inte om 2024 händelser. RAG använder aktuella dokument.
  3. Privata uppgifter - LLMs kan inte komma åt företagets interna dokument.
  4. Kostnad - Finjustering LLMs är dyrt ($10K-100K+). RAG är billigt (lagring + inbäddningar).
  5. Förklarande faktorer - RAG kan citera källor, vilket gör det revisionsbart och pålitligt.

Idag (2024–2025): RAG är den faktiska standarden för produktion AI-system som behöver noggrannhet och auditability. Varje större AI-företag erbjuder RAG verktyg.

Hur RAG fungerar: Den stora bilden

Innan du dyker djupt in i de tekniska detaljerna (som vi täcker i del 2), låt oss förstå högnivåarbetsflödet.

De tre faserna

RAG-system fungerar i tre olika faser:

Fas 1: Indexering (engångsinställning)

flowchart LR
    A[Your Documents] --> B[Split into Chunks]
    B --> C[Generate Embeddings]
    C --> D[Store in Vector DB]

    style C stroke:#f9f,stroke-width:2px
    style D stroke:#bbf,stroke-width:2px

Vad händer:

  1. Ta din kunskapsbas (doktorer, blogginlägg, manualer)
  2. Delas upp i hanterbara bitar (punkterna, sektionerna)
  3. Konvertera varje bit till en vektor inbäddning (array av siffror)
  4. Lagra vektorer i en databas optimerad för likhetssökning

Nyckelbegrepp: Liknande betydelser producerar liknande vektorer, så "Docker container" och "containerization plattform" hamnar nära varandra i vektorutrymme.

Fas 2: Återhämtning (varje fråga)

flowchart LR
    A[User Question] --> B[Generate Query Embedding]
    B --> C[Search Vector DB]
    C --> D[Top K Most Similar Chunks]

    style B stroke:#f9f,stroke-width:2px
    style C stroke:#bbf,stroke-width:2px

Vad händer:

  1. Användaren ställer en fråga
  2. Konvertera fråga till en vektor (samma modell som används för indexering)
  3. Hitta de flesta liknande vektorer i databasen
  4. Returnera de översta K mest relevanta bitarna (vanligen 3-10)

Varför det fungerar: "Hur distribuerar jag containrar?" (query) är semantiskt lik bitar om Docker distribution, även om de exakta orden skiljer sig åt.

Fas 3: Generation (varje fråga)

flowchart TB
    A[User Question] --> B[Build Prompt]
    C[Retrieved Context] --> B
    B --> D[LLM]
    D --> E[Generated Answer with Citations]

    style B stroke:#f9f,stroke-width:2px
    style D stroke:#bbf,stroke-width:2px

Vad händer:

  1. Ta användarens fråga
  2. Ta de återvunna sammanhangsbitarna
  3. Konstruera en uppmaning: "Ge detta sammanhang ..., svara på denna fråga ..."
  4. Skicka till LLM för generering
  5. LLM ger svar som grundar sig på det givna sammanhanget

Den magiska: LLM kan inte hallucinera fakta som inte finns i sammanhanget. Det kan bara syntetisera och förklara vad som tillhandahålls.

Ett enkelt exempel

Låt oss spåra en fråga genom systemet:

Användaren frågar: "Hur använder jag Docker Compose?"

Steg 1 - Återhämtning:

Query embedding: [0.234, -0.891, 0.567, ...]

Search vector DB for similar embeddings...

Retrieved chunks:
1. "Docker Compose is a tool for defining multi-container applications..." (similarity: 0.92)
2. "To use Docker Compose, create a docker-compose.yml file..." (similarity: 0.87)
3. "The docker-compose up command starts all services..." (similarity: 0.83)

Steg 2 – Generation:

Prompt to LLM:
"Context:
[1] Docker Compose is a tool for defining multi-container applications...
[2] To use Docker Compose, create a docker-compose.yml file...
[3] The docker-compose up command starts all services...

Question: How do I use Docker Compose?

Answer (use the context above):"

LLM Response:
"To use Docker Compose [1], start by creating a docker-compose.yml file [2] that
defines your services. Then run 'docker-compose up' to start all services [3]..."

Resultat: Exakt svar med implicita citeringar från din dokumentation.

RAG mot andra metoder

För att förstå när man ska använda RAG (och när man inte ska) krävs det att man jämför det med alternativ.

RAG mot Fin-Tuning

SYFTE OCH VERKSTÄLLIGHETER |--------|-----|-------------| | Kunskapsuppdateringar Omskolning krävs omedelbart (bara uppdatera kunskapsbasen). | Kostnad på låg (lagring + inbäddning) på hög (GPU-träningstid) | Noggrannhet på grund av källor kan hallucinera | Anpassning Obegränsad till hämtning på djup modellanpassning | Förklarande faktorer på hög (kan citera källor) på låg (svart låda) | Bästa för "Kunskapsintensiva uppgifter" Stil-/formatanpassning

När du ska använda Fine-Tuning:

  • Du behöver modellen för att lära dig en specifik stil eller format
  • Du har en stor, ren datauppsättning
  • Du behöver modellen för att internalisera mönster, inte fakta
  • Exempel: Att få GPT att skriva som Shakespeare

När du ska använda RAG:

  • Du behöver Faktisk exakthet med citeringar
  • Din kunskapsbas förändras ofta
  • Du har privata/proprietära uppgifter
  • Kostnad och enkelhet materia
  • Exempel: Kundsupport chatbot (mitt företags dokument ändras varje vecka)

Kan du kombinera båda? Fint läge för stil, RAG för fakta.

RAG vs. Long Context Windows

Moderna LLMs skryter med enorma sammanhangsfönster (GPT-4: 128K polletter, Claude: 200K polletter). Varför inte bara dumpa alla dina dokument i sammanhanget?

Problem med långa sammanhang:

  1. Kostnad: Prissättning skalor med polletter - $ 10-100 per fråga lägger upp snabbt
  2. Tröskelvärde: Bearbetning 100K polletter tar tid
  3. Förlorad i mitten: LLMs kämpar för att använda information mitt i långa sammanhang
  4. Spädning: Relevant information blir begravd i buller
  5. Praktiska begränsningar: Du kan inte passa hela företagets dokument i sammanhang

När ett långt sammanhang är vettigt:

  • Ett enda stort dokument (t.ex. analys av ett kontrakt)
  • Allt är relevant (inget behov av att filtrera)
  • Kostnaden är inget problem.
  • Låg sökvolym

När RAG är vettigt:

  • Stor kunskapsbas (miljoner dokument)
  • Behov av att hitta relevant delmängd
  • Hög frågevolym (kostnadsfrågor)
  • Uppdateringar i realtid av kunskap

Bästa praxis: Använd RAG för att välja det mest relevanta innehållet, sedan använda långa sammanhang för den delmängd.

RAG mot Prompting med exempel

Få-shot frammanande (ger exempel i prompten) är en enkel baslinje.

Exempel på prompt:

Examples:
Q: What is Docker?
A: Docker is a containerization platform...

Q: How does Kubernetes work?
A: Kubernetes orchestrates containers...

Q: What is my new question?
A: [LLM generates answer]

Begränsningar:

  • Begränsat till vad som passar i sammanhangsfönstret
  • Manuell kurering av exempel
  • Skalar sig inte till stora kunskapsbaser
  • Ingen semantisk sökning - du väljer manuellt exempel

Förbättring av RAG:

  • Hittar automatiskt bästa exempel (via likhetssökning)
  • Skalor till obegränsade exempel (endast topp K skickas till LLM)
  • Anpassar till förfrågan (olika frågor hämtar olika exempel)

Du kan tänka på RAG som "automatiserad några-shot frammana i skala."

Hybridsökning: RAG + traditionell sökning

Du kan kombinera RAG med traditionell fulltextsökning med hjälp av Reciprocal Rank Fusion (RRF).

Varför hybrid?

  • Semantisk sökning: Bra för konceptuella matcher ("terrorhantering" hittar "undantagshantering")
  • Sök efter nyckelord: Bra för exakta termer ("Docker Compose", "Entity Framework")
  • Hybrid: Bäst av båda världarna
public async Task<List<SearchResult>> HybridSearchAsync(string query)
{
    // Run both searches in parallel
    var semanticTask = SemanticSearchAsync(query, limit: 20);
    var keywordTask = KeywordSearchAsync(query, limit: 20);

    await Task.WhenAll(semanticTask, keywordTask);

    var semanticResults = await semanticTask;
    var keywordResults = await keywordTask;

    // Combine using Reciprocal Rank Fusion
    return ApplyRRF(semanticResults, keywordResults);
}

private List<SearchResult> ApplyRRF(
    List<SearchResult> list1,
    List<SearchResult> list2,
    int k = 60)
{
    var scores = new Dictionary<string, double>();

    // Score from first list
    for (int i = 0; i < list1.Count; i++)
    {
        var id = list1[i].Id;
        scores[id] = scores.GetValueOrDefault(id, 0) + 1.0 / (k + i + 1);
    }

    // Score from second list
    for (int i = 0; i < list2.Count; i++)
    {
        var id = list2[i].Id;
        scores[id] = scores.GetValueOrDefault(id, 0) + 1.0 / (k + i + 1);
    }

    // Merge and sort by combined score
    var allResults = list1.Concat(list2)
        .GroupBy(r => r.Id)
        .Select(g => g.First())
        .OrderByDescending(r => scores[r.Id])
        .ToList();

    return allResults;
}

Varför RAG har betydelse

Nu när du förstår vad RAG är, var det kom ifrån, och hur det jämförs med alternativ, här är varför det spelar roll:

1. Demokratisering av AI

  • Du behöver inte en $100K finjusterande budget
  • Du behöver inte ett team av ML ingenjörer
  • Alla utvecklare kan bygga RAG-system med befintliga verktyg

2. Praktisk noggrannhet

  • Hallucination är det största problemet med LLMs i produktionen
  • RAG löser det genom att motivera svaren i verkliga dokument
  • Omnämnanden gör det revisionsbart och pålitligt

3. Alltid up-to-dat

  • Traditionell AI: Tåg en gång, kunskap är fryst
  • RAG: Uppdatera dina dokument, kunskapsuppdateringar omedelbart
  • Kritisk för snabbrörliga domäner (teknik, nyheter, regler)

4. Sekretess och kontroll

  • Dina data stannar i din infrastruktur
  • Kan köra helt lokalt (lokala inbäddningar + lokal LLM + lokal vektor DB)
  • Inga data skickas till OpenAI eller andra molnleverantörer

5. Kostnadseffektivitet

  • Lagring är billigt (pennies per GB)
  • Inbäddningar är billiga (fraktioner på en procent per 1000 dokument)
  • Mycket billigare än finjustering eller långa sammanhangsfönster

6. Mångsidiga tillämpningar

  • Semantisk sökning (ingen LLM behövs!)
  • Q&A-system med citeringar
  • Innehållsrekommendation
  • Författarassistenter
  • Kunskapshantering
  • Dokumentationshjälpare
  • Forskningsassistenter

Slutsats: Från historia till genomförande

Vi har spårat RAG:s utveckling:

  • För-2010: Nyckelordssökning (tecken, betyder inte)
  • 2010 års priser: Läsförståelse (behöver rätt passage)
  • 2017-2020: Transformatorer och inbäddningar (betyder → vektorer)
  • 2020: Modern RAG (hämtning + generera)
  • 2023-närvarande: Produktionsstandard (hallucination + kostnad + avskildhet)

Viktiga insikter från del 1:

  • Separata RAG-enheter kunskapslagring (vektor DB) från skäl (LLM)
  • Det löser hallucinationsproblemet genom att utesluta svaren i verkliga dokument
  • Det är billigare och mer flexibelt än finjustering
  • Det fungerar bättre än långt sammanhang för stora kunskapsbaser
  • Det är i grund och botten "automatiska få-shot frammana i skala"

Den trestegs mentala modellen:

  1. Omvandla texten till siffror (inbäddningar)
  2. Hitta liknande nummer (vektorsökning)
  3. Använd vad du hittade (visa eller mata till LLM)

Allt annat är optimering.

Fortsätt till del 2: Arkitektur och interner

Du förstår nu vad RAG är, varför det är viktigt, och där Men hur fungerar det under huven?

Till Del 2: RAG:s arkitektur och interner, vi dyker djupt in i de tekniska detaljerna:

Fullständig RAG-ledning:

  • Fas 1: Indexering (textextraktion, bitningsstrategier, inbäddning av generering, vektorlagring)
  • Fas 2: Återhämtning (förfrågans inbäddningar, likhetsmått, omklassificering)
  • Fas 3: Generation (promptkonstruktion, LLM-parametrar, efterbehandling)

Inhemska LLM-enheter:

  • Vad är polletter och varför de betyder något för RAG
  • KV-cachen: Hur LLM minns sammanhang
  • Sammanhangsfönster och polletthanteringsstrategier
  • Optimera RAG för symbolisk effektivitet och kostnad

Tekniska djupdyk:

  • Vektordatabaser och likhetssökningsalgoritmer
  • Inbäddning av modeller och normalisering
  • Chunking strategier som bevarar sammanhanget
  • Praktiska kodexempel i C#

Fortsätt till del 2: Arkitektur och interner →

Efter del 2, kommer du att vara redo för del 3, där vi bygger riktiga system, löser gemensamma utmaningar, och utforska avancerade tekniker som HyDE, multi-query RAG, och kontextuell kompression.

Resurser

Grunddokument:

Läs vidare:

Nästa i denna serie:

Fortsätt till del 2 →

logo

© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.