RAG förklarad: tekniken som avgör om din webbplats hamnar i AI-svaret

För er webbplats blir RAG regelsystemet bakom synligheten: ni konkurrerar om att bli ett av de dokument som hämtas — och sedan används i svaret. Det är därför GEO handlar om crawlbarhet, indexerbarhet och citerbarhet och inte om magi. Hur motorerna väljer källor i praktiken finns i Hur väljer AI-motorerna vilka företag de citerar?; här är tekniken bakom, från grunden.

Hur fungerar Retrieve-Read steg för steg?

Naive RAG är en fast pipeline: indexing → retrieval → generation. Översatt till vad som händer när en kund ställer en fråga:

Surveyn kallar detta ”Retrieve-Read”-ramverket — hämta, sedan läsa. Det är inget att förväxla med mer avancerade varianter; begreppet att hålla sig till är just Retrieve-Read, inte ”retrieval-inference” eller andra namn som cirkulerar i marknadsmaterial.

Varje steg har dessutom sitt eget språk, och det lönar sig att kunna det när ni läser leverantörsmaterial: indexets bitar kallas chunks, urvalet styrs av likhetsmått, och det som skickas vidare till modellen kallas kontext. Notera vad det innebär — det är bitar av text, inte hela webbsidor, som konkurrerar om platsen i svaret. En sida som blandar fem ämnen ger fem svaga bitar; fem sidor med ett ämne var ger fem tydliga.

Varför är crawlbar HTML en förutsättning i varje steg?

För att varje steg har en egen tröskel — och ni faller ur spelet på den första ni misslyckas med. Grunden är dessutom enkel att kontrollera, vilket är den vanligaste orsaken till att den försummas:

• Indexering: crawler blockerad i robots.txt = sidan finns aldrig i indexet = aldrig ens kandidat, oavsett innehåll.
• Hämtning: innehåll som bara renderas med JavaScript kan saknas i indexets text — då finns det inget att matcha frågan mot.
• Läsning: en sida utan stödbara påståenden kan i värsta fall hämtas men blir aldrig källa — modellen har inget att bygga svaret på.

Trösklarna är kumulativa: en sida som faller på steg ett finns inte ens med i steg två och tre. Därför är ordningen i varje åtgärdsplan viktig — crawlbarhet före innehåll, innehåll före formuleringar. Och det är därför en sajt kan vara tekniskt felfri och ändå osynlig: den klarar alla tre trösklar men vinner inget urval i hämtningssteget, eftersom ingen faktisk kundfråga matchar dess formuleringar.

Vad skiljer Naive, Advanced och Modular RAG åt?

Surveyns tre paradigmer är bra vokabulär när leverantörer säljer ”AI-sök” — då kan ni fråga vilka delar som faktiskt körs:

För er del ändrar paradigmen inte grunderna — de förbättrar hur bra systemet hittar och använder rätt material. En bättre hämtningsmotor hittar er sida oftare, men bara om den finns i indexet och innehåller något stödbart. Advanced-varianternas åtgärdsnamn är dessutom användbara i omvänd riktning: när någon lovar bättre AI-synlighet, fråga vilka av dessa steg som ingår — frågeomskrivning, finare segmentering, metadata i indexet, reranking, kontextkompression. Det är surveyns konkreta lista, och den handlar om systemet — inte om er sida.

Varför blir svaret fel även när tekniken fungerar?

För att varje steg kan misslyckas på sitt sätt. Surveyn kategoriserar Naive RAG:s brister i tre grupper — och de är förklarliga nog att känna igen i riktiga svar:

• Hämtningsproblem — precision och recall: felmatchade eller irrelevanta bitar väljs ut, och viktig information missas helt.
• Genereringsproblem — hallucination: svaret innehåller påståenden som inte stöds av den hämtade kontexten.
• Sammanfogningsproblem — osammanhängande utdata, redundans när flera källor säger samma sak, och överdrivet följa det hämtade: modellen ekar källorna i stället för att svara.

Och även när rätt dokument faktiskt hämtats kan läs-steget strypa användningen av det: positionseffekten lost in the middle — med det relevanta dokumentet i mitten svarade GPT-3.5-Turbo rätt i 53,8 % av fallen, sämre än utan dokument alls (56,1 %). Hämtning är en nödvändig, inte tillräcklig, förutsättning.

Den sista bristkategorin — att modellen följer det hämtade för mycket — låter kanske harmlös, men den förklarar en del av det som känns godtyckligt i AI-svar: svaret lånar källornas formuleringar snarare än frågans. En källa som uttrycker saken tydligt är en källa som svaret lånar av. Texten på er sida är alltså inte bara er text — den blir material som andras svar byggs av.

Vad kan ni påverka utan att röra tekniken?

Mer än ni tror — och det är samma tre saker varje gång:

1. Åtkomst. Kontrollera att motorernas crawlers är insläppta i robots.txt och att sidorna renderar riktig HTML utan JavaScript. Detta är indexeringens tröskel.
2. Matchbarhet. En fråga per sida, med den frågans ord i rubrik och brödtext — hämtningssteget matchar text mot fråga, inte varumärke mot önskan.
3. Citerbarhet. Svar-först och påståenden med stöd i samma stycke. Det är den tröskeln som avgör om en hämtad sida blir en källa — samma logik som fick OpenAI att bygga in referenser i WebGPT från början.

Hela åtgärdslistan, i rätt ordning, finns i GEO-guiden. Vill ni veta var ni står idag: 10-minutersdiagnosen visar om ni ens är kandidat.

Vanliga frågor