Avancerad RAG-arkitektur 2026. Från chunking till adaptive RAG.
Den naiva RAG-pipelinen som blev standard runt 2023 - dela dokument i lika stora bitar, embedda, hämta de fem närmaste, klistra in i prompten - tar dig till en demo, men sällan längre. När jag kallas in för att rädda ett RAG-system som "svarar fel" eller "hittar inte det uppenbara" sitter problemet nästan aldrig i modellen. Det sitter i hur dokumenten styckas, hur sökningen görs och i att inget steg sorterar bort bruset innan det når modellen. Det här är vad som skiljer en RAG-arkitektur 2026 från en treårig, och varför ett modellbyte sällan löser det folk tror.
Jag bygger och granskar retrieval-system inom AI Engineering, och förbättringarna nedan ligger nästan alltid där den verkliga vinsten finns - i hämtningen, inte i genereringen.
Chunking: sluta dela blint
Att klyva text var n:te token är enkelt och nästan alltid fel. Det skär meningar mitt itu och blandar orelaterade stycken i samma bit, så att en träff innehåller halva svaret och hälften brus. Min standard idag är strukturmedveten chunking som respekterar rubriker, stycken och listor, med en liten överlappning så att sammanhang inte tappas vid gränserna. Minst lika viktigt är metadata: varje chunk taggas med källa, rubrik, datum och avdelning. Det låter dig filtrera sökningen - "bara gällande dokument, bara HR" - vilket ofta höjer kvaliteten mer än något modellbyte, och dessutom gör svaren spårbara.
Hybrid retrieval: vektorer räcker inte
Ren vektorsökning är bra på betydelse men dålig på exakthet. Den missar artikelnummer, produktnamn, paragrafhänvisningar och förkortningar - precis det användare ofta söker på. Lösningen är hybrid retrieval: kombinera vektorsökning med klassisk nyckelordssökning (BM25) och slå ihop resultaten. Nästan varje system jag rör vid blir bättre av det, eftersom de två metoderna fångar olika sorters relevans. Den som bara kör vektorer lämnar kvalitet på bordet, och det är en av de billigaste förbättringarna som finns.
Reranking: hämta brett, skicka smalt
Det enskilt mest underskattade steget. Istället för att skicka de fem första träffarna rakt in i modellen hämtar du brett - säg trettio kandidater - och låter en reranker (en cross-encoder eller en dedikerad rerank-modell) sortera om dem efter verklig relevans till frågan. Sedan skickar du bara de bästa vidare. Det här filtrerar bort nästan-relevant brus som annars förvirrar modellen och drar upp kostnaden, och är ofta den enskilt största kvalitetshöjningen för pengarna. Vektorsökning är grovsorteringen; reranking är finsorteringen.
- Query-omskrivning: låt en modell förtydliga eller dela upp användarens fråga innan sökning - korta, vaga frågor hämtar dåligt.
- Filtrering på metadata: begränsa sökrummet innan vektorsökningen, så du inte rerankar skräp och slösar tokens.
- Citat och källor: be modellen ange vilken chunk varje påstående bygger på - det avslöjar dålig retrieval direkt och bygger förtroende hos användaren.
Adaptiv RAG: gör inte allt varje gång
Nästa steg är att låta systemet anpassa sig efter frågan. En enkel faktafråga behöver kanske inte hela maskineriet, medan en komplex jämförelsefråga vinner på flera sökrundor och mer kontext. Adaptiv RAG låter en lättviktig router avgöra hur mycket arbete varje fråga förtjänar. Det sänker både kostnad och latens utan att offra kvalitet på de svåra frågorna. Men inför det först när grunden sitter - annars optimerar du något som ändå är trasigt, och får bara svårare att se var felet egentligen ligger.
Utan evals gissar du
Den röda tråden i allt ovan: du kan inte förbättra det du inte mäter. Varje ändring i chunking, retrieval eller reranking måste valideras mot en uppsättning verkliga frågor med känt facit, helst i CI. Annars vet du inte om en justering gjorde systemet bättre eller bara annorlunda, och du riskerar att en "förbättring" tyst försämrar svaren på frågor du inte testade. Jag sätter alltid upp en eval-svit innan jag rör pipelinen - det är skillnaden mellan teknik och tur, och det är den investering som betalar sig snabbast i ett RAG-projekt.
Relaterat
- Automatisera innehållsproduktion med AI: Workflows för SEO-artiklar i skala
- n8n self-hosted på Docker: Installation, backup och autoskalning
- n8n vs Make vs Zapier: När automation-plattformen skalar
Ett exempel på ett RAG-system i drift finns i kundcase.
Vill du ta det vidare?
Jag bygger och räddar RAG-system för svenska bolag - med hybrid retrieval, reranking och evals som kvalitetsgrind. Boka ett förutsättningslöst samtal så går vi igenom ert use case.
“När ett RAG-system svarar fel sitter problemet nästan aldrig i modellen. Det sitter i hur dokumenten styckas, hur sökningen görs och i att inget steg sorterar bort bruset.”
- Simon Axelsson
Vanliga frågor
- Räcker det inte att byta till en bättre modell?
- Sällan. När ett RAG-system hittar fel dokument hjälper ingen modell - den kan bara resonera kring det den får. Vinsten ligger nästan alltid i chunking, hybrid retrieval och reranking, inte i modellvalet.
- Vad är skillnaden mellan vektorsökning och hybrid retrieval?
- Vektorsökning matchar på betydelse men missar exakta termer som artikelnummer och paragrafer. Hybrid retrieval kombinerar vektor med klassisk nyckelordssökning (BM25) och fångar därför båda sorters relevans, vilket nästan alltid ger bättre träffar.
- När ska vi införa adaptiv RAG?
- Först när grunden sitter. Adaptiv RAG sparar kostnad och latens genom att låta enkla frågor använda mindre maskineri, men det är meningslöst att optimera en pipeline som ännu hämtar fel. Få chunking, retrieval och evals på plats först.
Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.
Fler artiklar
