AI-serie intervjuspørsmål 11: Hvordan optimalisere RAG?

Optimalisering av RAG er ikke bare en justering av én enkelt komponent, men en helhetlig optimaliseringsprosess. Nedenfor gir jeg systematiske optimaliseringsstrategier fra fire dimensjoner: dataindekseringssiden, søkesiden, genereringssiden og evalueringssiden, og legger ved praktiske erfaringer som kan nevnes i intervjuer.

1. Optimalisering av dataindekseringssiden (forbedre kvaliteten på «kunnskapsbasen»)

Dette er det mest oversette, men raskest virkende stedet.

Optimaliseringspunkt	Problem	Konkrete tiltak	Effektindikator
Dokumentanalyse	Tabeller og flytskjema i PDF ignoreres, eller tekst blir uleselig og rekkefølgen feil.	Bytt til bedre analysebibliotek (f.eks. `unstructured`, `pypdf` sin layoutbevaringsmodus); for tabeller, bruk `pandas` for å trekke ut og konvertere til Markdown.	Gjenkallingsrate +5~15 %
Tekstblokkstørrelse	Chunk for liten mister kontekst (f.eks. «han» i «hans inntektsvekst i år»); chunk for stor fører til mye støy i søket.	Eksperimenter med ulike chunk-størrelser (256/512/768 tokens), overlapp på 10–20 %; for lange dokumenter, del etter semantiske grenser (avsnitt/overskrifter) i stedet for fast lengde.	Treffrate / troverdighet
Metadatatillegg	Finner relevante avsnitt, men kan ikke spore tilbake til kilde eller tid, eller trenger domenefiltrering.	Legg til metadata for hver chunk: `source` (filnavn/URL), `timestamp`, `page_num`, `doc_type`. Bruk filter under søk (f.eks. `doc_type == 'legal'`).	Filtreringspresisjon
Valg av embeddermodell	Generell embedding fungerer dårlig i vertikale domener (medisin, kode, juss).	Bruk domene-fintunede modeller (BGE-large-zh, GTE-Qwen2-7B-instruct); eller fintune din egen embeddermodell (med triplet loss).	Søk MRR@10 +10~20 %

2. Optimalisering av søkesiden (gjør «oppslag» mer nøyaktig)

Søket bestemmer kvaliteten på «referansene» som gis til LLM.

Optimaliseringspunkt	Problem	Konkrete tiltak	Effekt
Hybridsøk	Vektorsøk kan ikke matche presise termer (f.eks. produktmodell `ABC-123`), nøkkelordsøk forstår ikke synonymer.	Bruk både vektorsøk (semantisk) og BM25 (nøkkelord), vekting (f.eks. 0,7vektor + 0,3BM25) eller rerank-fusjon.	Gjenkallingsrate +10~25 %
Re-rangering (Rerank)	De første resultatene fra vektorsøk er ikke alltid mest relevante; det 10. er best.	Bruk cross-encoder-modell (f.eks. BGE-reranker-v2, Cohere Rerank) for å skåre kandidatsettet (f.eks. topp 20) på nytt, ta top-K.	Treffrate betydelig forbedret (spesielt top-1)
Spørringsomskriving	Brukerens spørsmål er uklart eller med uklare referanser i flerturnssamtaler («Hva er prisen på den?»).	Bruk LLM til å omskrive det opprinnelige spørsmålet til en mer søkbar form (f.eks. «Hva er prisen på iPhone 15?»); eller utnytt samtalens historie for å fullføre.	Gjenkallingsrate +5~15 %
HyDE	Brukerspørsmål er for kort eller for abstrakt (f.eks. «Fortell om fotosyntese»), direkte søk fungerer dårlig.	La LLM generere et hypotetisk svar først, og bruk dette svaret til å søke i dokumentene.	Egnet for åpne domener, men ikke for presise faktaspørsmål
Justering av søkeantall Top‑K	For liten K kan miste nøkkelinformasjon; for stor K øker tokenforbruk og støy.	Eksperimenter med K=3/5/10, observer balansen mellom gjenkallingsrate og svar-troverdighet.	Avveining mellom effektivitet og resultat

3. Optimalisering av genereringssiden (få LLM til å utnytte referansene godt)

Selv med godt søk, hjelper det ikke med dårlig prompt eller svak modell.

Optimaliseringspunkt	Problem	Konkrete tiltak	Effekt
Prompt engineering	LLM ignorerer søkeinnhold eller finner på ting.	Tydelig instruks: «Svar kun basert på følgende refererte materiale. Hvis materialet er mangelfullt eller irrelevant, svar 'Ikke nok informasjon'.» Legg til few-shot-eksempler som viser hvordan kilder skal siteres.	Troverdighet +20~40 %
Kontekstkomprimering	Søkeresultatet er for langt (over modellens kontekstvindu) eller inneholder mye støy.	Bruk `LLMLingua` eller `selektiv kontekst`-komprimering, behold de mest relevante setningene før de sendes til LLM.	Reduserer risiko for informasjonstap
Oppgradering av LLM-modell	Små modeller (7B) kan ikke utføre kompleks resonnering eller huske lang kontekst.	Bytt til sterkere modell (GPT-4o, Claude 3.5 Sonnet, Qwen2.5-72B).	Resonneringsnøyaktighet forbedres betydelig
Strømming og sitater	Brukeren kan ikke verifisere svar pålitelighet.	La LLM generere `[citation:1]` som henviser til nummeret i søkedokumentene. Bakende legg ved originaltekstlenke.	Brukertillit + feilsøkingsmulighet
Kalibrering av avvisningssvar	Modellen finner på ting når den ikke bør, eller sier «vet ikke» når den burde svare.	Sett en likhetsgrense: Hvis cosinuslikheten mellom topp-1 chunk og spørsmålet er under 0,7, gi LLM beskjed om «materialet er irrelevant».	Reduserer hallusinasjonerate

4. Evaluering og iterasjon (vite hvor man skal justere)

Uten måling kan man ikke optimalisere.

Optimaliseringspunkt	Tiltak	Indikator
Opprett evalueringssett	Forbered 100–300 ekte brukerspørsmål + standardsvar + korrekte søkedokument-ID-er.	Dekk ulike vanskelighetsgrader og intensjoner.
Automatisert evaluering	Bruk RAGAS (Faithfulness, Answer Relevance, Context Recall) eller TruLens.	Tre kjerneindikatorer: troverdighet, svarrelevans, kontekstgjenkalling.
Manuell evaluering	Test ukentlig 20 dårlige tilfeller, analyser feiltype (søkefeil / genereringsfeil / manglende kunnskapsbase).	Prioritering av forbedringer.
A/B-testing	Del brukere i produksjonsmiljø for å teste ulike søkestrategier (f.eks. BM25 vs hybridsøk).	Online-indikatorer: brukertilfredshet, andel svar uten svar.

5. Praktiske erfaringer som kan nevnes i intervjuer (bonuspoeng)

«I RAG-prosjektet jeg hadde ansvar for, var basistreffraten bare 67 %. Jeg gjorde tre ting:
1. Endret blokkstørrelse fra fast 1024 til dynamisk semantisk segmentering (etter overskrift+avsnitt), treffraten økte til 74 %;
2. La til hybridsøk (vektor + BM25) og en liten rerank-modell, treffraten steg til 83 %;
3. Optimaliserte prompt og krevde [Ingen relevant informasjon funnet], hallusinasjoneraten sank fra 22 % til under 5 %.

I tillegg bygde vi en kontinuerlig evalueringspipeline, der vi før hver endring kjørte RAGAS-poengsum for 200 spørsmål for å sikre ingen forringelse.»

Oppsummering: En komplett RAG-optimaliseringsveikart

Datalag ─→ Dokumentrensing, blokkoptimalisering, metadataforsterkning, domenespesifikk embedding
Søkelag ─→ Hybridsøk, rerank, spørringsomskriving, HyDE, Top-K-justering
Genereringslag ─→ Promptforsterkning, instruksjonskrav, komprimering, sitater, avvisningsgrense
Evalueringslag ─→ Evalueringssett, RAGAS, manuell analyse, A/B-eksperiment