AI-seriens intervjufråga 11: Hur optimerar man RAG?

Optimering av RAG är inte en justering av en enskild del, utan en process av fullkedjeoptimering. Nedan ger jag systematiska optimeringsstrategier utifrån fyra dimensioner: dataindexeringssidan, hämtningssidan, genereringssidan och utvärderingssidan, och bifogar praktiska erfarenheter som kan nämnas i intervjuer.

1. Optimering på dataindexeringssidan (förbättra kvaliteten på "kunskapsbasen")

Detta är den mest förbisedda men samtidigt mest effektiva förbättringen.

Optimeringspunkt	Problemobservation	Specifik åtgärd	Effektmått
Dokumenttolkning	Tabeller och flödesdiagram i PDF ignoreras, eller texten blir otydlig och ordningen felaktig.	Byt till bättre tolkningbibliotek (t.ex. `unstructured`, `pypdf` med layoutbevarande läge); för tabeller, använd `pandas` för extraktion och konvertera till Markdown.	Återkallelse +5~15%
Textstyckestorlek	För små chunkar förlorar sammanhang (t.ex. "hans intäkter växte i år" där "hans" referens försvinner); för stora chunkar leder till mer brus vid sökning.	Experimentera med olika chunk-storlekar (256/512/768 tokens), med överlappning satt till 10–20%; för långa dokument, klipp efter semantiska gränser (stycken/rubriker) istället för fast längd.	Träfffrekvens / pålitlighet
Metadata-tillägg	Relevanta stycken hittas men kan inte spåras till källa eller tid, eller det behövs filtrering efter ämne.	Lägg till metadata för varje chunk: `source` (filnamn/URL), `timestamp`, `page_num`, `doc_type`. Använd filter vid sökning (t.ex. `doc_type == 'legal'`).	Filtreringsprecision
Val av inbäddningsmodell	Generisk embedding presterar dåligt inom vertikala domäner (medicin, kod, juridik).	Använd domänfinjusterade modeller (BGE-large-zh, GTE-Qwen2-7B-instruct); eller finjustera en egen inbäddningsmodell (med triplet loss).	Sök-MRR@10 +10~20%

2. Optimering på söksidan (göra "bläddringen" mer träffsäker)

Sökningen avgör kvaliteten på de "referensmaterial" som matas till LLM:en.

Optimeringspunkt	Problemobservation	Specifik åtgärd	Effekt
Hybridsökning	Vektorsökning kan inte matcha exakta termer (t.ex. produktmodell `ABC-123`), nyckelordssökning förstår inte synonymer.	Använd både vektorsökning (semantisk) och BM25 (nyckelord), kombinera via viktning (t.ex. 0.7vektor + 0.3BM25) eller rerankning.	Återkallelse +10~25%
Omrankning (Rerank)	De första resultaten från vektorsökning är inte alltid mest relevanta; det 10:e kan vara bäst.	Använd en cross-encoder-modell (t.ex. `BGE-reranker-v2`, Cohere Rerank) för att poängsätta kandidater (t.ex. topp 20) och ta top-K.	Träfffrekvensen ökar markant (särskilt top-1)
Frågeomformulering	Användarens fråga är vag eller otydlig i flervändskonversation ("Vad är priset på den?").	Låt LLM:en omformulera den ursprungliga frågan till en mer sökvänlig form (t.ex. "Vad är priset på iPhone 15?"); eller komplettera med dialoghistorik.	Återkallelse +5~15%
HyDE	Användarens fråga är för kort eller abstrakt (t.ex. "Berätta om fotosyntes"), direkt sökning fungerar dåligt.	Låt först LLM:en generera ett hypotetiskt svar, använd sedan detta svar för att söka i dokumenten.	Lämplig för öppna domäner, men inte för faktabaserade exakta frågor
Justering av sökantal Top-K	För litet K kan missa viktig information; för stort K ökar tokenförbrukning och brus.	Experimentera med K=3/5/10, observera balansen mellan återkallelse och svarspålitlighet.	Avvägning mellan effektivitet och resultat

3. Optimering på genereringssidan (få LLM:en att använda referensmaterialet väl)

Även om sökningen är träffsäker, om prompten är dålig eller modellen inte räcker till, så blir det inget bra.

Optimeringspunkt	Problemobservation	Specifik åtgärd	Effekt
Promptteknik	LLM:en ignorerar sökresultaten eller hittar på fakta.	Tydlig instruktion: "Svara endast baserat på de medföljande referensmaterialen. Om materialet inte räcker eller är irrelevant, svara 'Det finns inte tillräcklig information'." Lägg till few-shot-exempel som visar hur man citerar källor.	Pålitlighet +20~40%
Kontextkomprimering	Det hämtade materialet är för långt (över modellens kontextfönster) eller innehåller mycket brus.	Använd `LLMLingua` eller `selektiv kontext`-komprimering, behåll de mest relevanta meningarna innan de skickas till LLM:en.	Minskar risk för att förlora information
Uppgradering av LLM-modell	Liten modell (7B) klarar inte komplexa resonemang eller minns lång kontext dåligt.	Byt till starkare modell (GPT-4o, Claude 3.5 Sonnet, Qwen2.5-72B).	Resonemangsprecision förbättras avsevärt
Strömning och citering	Användaren kan inte verifiera svarspålitlighet.	Låt LLM:en under genereringen mata ut `[citation:1]` som motsvarar det hämtade dokumentets ID. Bifoga originaltextlänk på serversidan.	Användartillit + felsökning
Kalibrering av nekande svar	Modellen hittar på när den inte borde svara, eller säger 'vet inte' när den borde svara.	Sätt en likhetströskel: om cosinuslikheten mellan den hämtade top-1-chunken och frågan är lägre än 0,7, uppmana LLM:en att "materialet är irrelevant".	Minskar hallucinationer

4. Utvärderings- och iterationssidan (veta vart man ska justera)

Utan mätning går det inte att optimera.

Optimeringspunkt	Åtgärd	Mått
Skapa utvärderingsset	Förbered 100–300 verkliga användarfrågor + standardsvar + korrekta dokument-ID:n för sökning.	Täck olika svårighetsgrader och avsikter.
Automatiserad utvärdering	Använd RAGAS (Faithfulness, Answer Relevance, Context Recall) eller TruLens.	Tre kärnmått: pålitlighet, svarsrelevans, kontextåterkallelse.
Manuell utvärdering	Varje vecka granska 20 dåliga fall, analysera feltyper (sökfel / generationsfel / kunskapsbrist).	Prioriteringsordning för förbättringar.
A/B-test	I produktionsmiljö, testa olika sökstrategier i delade grupper (t.ex. BM25 vs hybridsökning).	Online-mått: användarnöjdhet, andel obesvarade frågor.

5. "Praktiska erfarenheter" att nämna i intervjuer (pluspoäng)

"I det RAG-projekt jag ansvarade för var baslinjeträfffrekvensen initialt bara 67%. Jag gjorde tre saker:
1. Ändrade chunkning från fast 1024 till dynamisk semantisk uppdelning (efter rubrik + stycke), träfffrekvensen steg till 74%;
2. Lade till hybridsökning (vektor + BM25) och en liten rerank-modell, träfffrekvensen steg till 83%;
3. Optimerade prompten och tvingade fram [Ingen relevant information hittad], hallucinationerna minskade från 22% till under 5%.

Dessutom byggde vi en kontinuerlig utvärderingspipeline; varje ändring testades mot 200 frågor med RAGAS-poäng för att säkerställa ingen försämring."

Slutlig sammanfattning: En komplett roadmap för RAG-optimering

Datalager ─→ Rengöring av dokument, optimering av uppdelning, metadataförbättring, domänanpassad embedding
Söklager ─→ Hybridsökning, rerankning, frågeomformulering, HyDE, Top-K-justering
Genereringslager ─→ Promptförbättring, instruktionskrav, komprimering, citering, tröskel för nekande svar
Utvärderingslager ─→ Utvärderingsset, RAGAS, manuell analys, A/B-experiment