AI-serie interviewspørgsmål 11: Hvordan optimeres RAG?

Optimering af RAG handler ikke om justering af en enkelt komponent, men en fuld kædeoptimering. Nedenfor giver jeg systematiske optimeringsstrategier fra fire dimensioner: dataindekseringssiden, søgesiden, generationssiden og evalueringssiden, med praktiske erfaringer, der kan nævnes i en samtale.

1. Optimering af dataindekseringssiden (forbedring af "vidensbase"-kvalitet)

Dette er det mest oversete, men ofte det mest effektive område.

Optimeringspunkt	Problem	Specifik fremgangsmåde	Effektmåling
Dokumentparsning	Tabeller og flowcharts i PDF ignoreres, eller tekst bliver forvrænget og rækkefølgen forkert.	Brug bedre parserbiblioteker (f.eks. `unstructured`, layoutbevarende tilstand i `pypdf`); for tabeller, ekstraher med `pandas` og konverter til Markdown.	Recall +5~15%
Tekststørrelse	Chunk for lille mister kontekst (f.eks. "hans" i "hans årsomsætning voksede" – reference tabt); chunk for stor giver søgestøj.	Eksperimentér med forskellige chunk-størrelser (256/512/768 tokens), overlap på 10~20%; for lange dokumenter, del efter semantiske grænser (afsnit/overskrifter) i stedet for fast længde.	Hitrate / troværdighed
Metadata-tilføjelse	Relaterede afsnit findes, men kilde eller tid kan ikke spores, eller der er behov for faglig filtrering.	Tilføj metadata til hver chunk: `source` (filnavn/URL), `timestamp`, `page_num`, `doc_type`. Brug filtre under søgning (f.eks. `doc_type == 'legal'`).	Filtreringspræcision
Valg af indlejringsmodel	Generel embedding klarer sig dårligt i specialiserede domæner (medicin, kode, jura).	Brug domænefinjusterede modeller (BGE-large-zh, GTE-Qwen2-7B-instruct); eller finjuster din egen embedding-model (med triplet loss).	Søg MRR@10 +10~20%

2. Optimering af søgesiden (gør "opslag" mere præcist)

Søgningen bestemmer kvaliteten af "referencematerialet" til LLM'en.

Optimeringspunkt	Problem	Specifik fremgangsmåde	Effekt
Hybrid søgning	Vektorsøgning matcher ikke præcise termer (f.eks. produktmodel `ABC-123`), nøgleordssøgning forstår ikke synonymer.	Brug både vektorsøgning (semantisk) og BM25 (nøgleord), fusioner via vægtning (f.eks. 0,7vektor + 0,3BM25) eller reranking.	Recall +10~25%
Reranking	De første resultater fra vektorsøgning er ikke nødvendigvis mest relevante; nummer 10 er måske bedst.	Brug en cross-encoder-model (f.eks. `BGE-reranker-v2`, Cohere Rerank) til at genberegne score for kandidater (f.eks. top 20) og vælg top-K.	Hitrate markant forbedret (især top-1)
Forespørgselsomskrivning	Brugerspørgsmål er vage eller har uklare referencer i flerturnssamtaler ("Hvad er prisen?").	Brug LLM til at omskrive det originale spørgsmål til en mere søgbar form (f.eks. "Hvad er prisen på iPhone 15?"); eller udfyld ved hjælp af samtalehistorik.	Recall +5~15%
HyDE	Brugerspørgsmål er for korte eller abstrakte (f.eks. "Forklar fotosyntese"), direkte søgning er dårlig.	Få LLM til at generere et hypotetisk svar først, brug derefter dette svar til at søge i dokumenter.	Velegnet til åbne domæner, men ikke til faktuelle præcise spørgsmål
Justering af Top-K	For lille K kan miste nøgleinformation; for stor K øger tokenforbrug og støj.	Eksperimentér med K=3/5/10, observer balance mellem recall og svar troværdighed.	Afvejning mellem effektivitet og kvalitet

3. Optimering af generationssiden (få LLM til at bruge referencematerialet ordentligt)

Selv med god søgning, dårlig prompt eller model hjælper det ikke.

Optimeringspunkt	Problem	Specifik fremgangsmåde	Effekt
Prompt engineering	LLM ignorerer søgeresultater eller finder på noget.	Tydelig instruktion: "Svar kun baseret på følgende referencemateriale. Hvis materialet er utilstrækkeligt eller irrelevant, svar 'Ikke tilstrækkelig information'." Tilføj few-shot eksempler der viser, hvordan kilder citeres.	Troværdighed +20~40%
Kontekstkomprimering	Søgeresultater er for lange (overstiger modellens kontekstvindue), eller indeholder meget støj.	Brug `LLMLingua` eller `selektiv kontekst` komprimering, behold kun de mest relevante sætninger før de sendes til LLM.	Reducerer risiko for informationstab
LLM modelopgradering	Lille model (7B) kan ikke udføre kompleks ræsonnering eller huske lang kontekst.	Skift til stærkere model (GPT-4o, Claude 3.5 Sonnet, Qwen2.5-72B).	Ræsonneringsnøjagtighed markant forbedret
Streaming og citering	Brugere kan ikke verificere svar.	Få LLM til at output `[citation:1]` under generering, svarende til nummeret på søgedokumentet. Backend vedlægger original link.	Brugertillid + fejlsøgning
Kalibrering af afvisningssvar	Model finder på svar, når den ikke bør, eller siger ved ikke, når den burde svare.	Indstil en similaritetstærskel: Hvis cosinus-ligheden mellem top-1 chunk og spørgsmål er under 0,7, bed LLM om at sige "Materialet er ikke relevant".	Reducerer hallucination

4. Evaluering og iteration (ved, hvor der skal justeres)

Uden måling kan man ikke optimere.

Optimeringspunkt	Fremgangsmåde	Måling
Opret evalueringssæt	Forbered 100~300 rigtige bruger-spørgsmål + standard svar + korrekte dokument-ID'er til søgning.	Dæk forskellige sværhedsgrader og intentioner.
Automatiseret evaluering	Brug RAGAS (Faithfulness, Answer Relevance, Context Recall) eller TruLens.	Tre kernemålinger: troværdighed, svarrelevans, kontekst-recall.
Manuel evaluering	Ugentlig test af 20 dårlige cases, analyser fejltyper (søgefejl / generationsfejl / manglende vidensbase).	Prioritering af forbedringer.
A/B-test	Opdel trafik i produktion for at teste forskellige søgestrategier (f.eks. BM25 vs hybrid søgning).	Onlinemålinger: brugertilfredshed, rate af svar uden information.

5. Praktiske erfaringer at nævne i en samtale (bonus)

"I det RAG-projekt, jeg stod for, var baseline-hitraten kun 67%. Jeg gjorde tre ting:
1. Skiftede fra fast 1024-chunk til dynamisk semantisk opdeling (efter overskrift + afsnit), hitraten steg til 74%;
2. Tilføjede hybrid søgning (vektor + BM25) og en lille rerank-model, hitraten steg til 83%;
3. Optimerede prompten og påbød [Ingen relevant information fundet], hallucination faldt fra 22% til under 5%.

Derudover byggede vi en kontinuerlig evalueringspipeline, der kørte RAGAS-scorer på 200 spørgsmål før hver ændring for at sikre ingen regression."

Afsluttende opsummering: En komplet RAG-optimeringsplan

Datalag ─→ Dokumentrensning, chunk-optimering, metadataforbedring, domæne-embedding
Søgelag ─→ Hybrid søgning, reranking, forespørgselsomskrivning, HyDE, Top-K-justering
Generationslag ─→ Promptforstærkning, instruktionskrav, komprimering, citering, afvisningstærskel
Evalueringslag ─→ Evalueringssæt, RAGAS, manuel analyse, A/B-eksperimenter