Vad är RAG och varför spelar det roll

Standard GPT-4o känner inte till ditt företags interna dokument, din produktkatalog eller dina kunddata. RAG löser detta: du lagrar ditt innehåll som vektorinbäddningar i en databas, och vid frågetillfället hittar du de mest relevanta delarna och skickar dem som kontext till LLM:en.

Resultatet: en AI-assistent som svarar på frågor om din specifika data, korrekt och med källhänvisningar.

För svenska företag är RAG-applikationer särskilt värdefulla för: interna kunskapsbaser (personalhandböcker, processpolicyer), kundsupport-chatbots baserade på produktdokumentation, och juridiska eller regelverksmässiga fråge-och-svars-system. Och eftersom all data stannar i din Supabase-instans uppfyller du enkelt GDPR:s krav på datalagring inom EU.

Steg 1: Aktivera pgvector i Supabase

Supabase levereras med pgvector inbyggt. I Supabase SQL-redigeraren kör du: CREATE EXTENSION IF NOT EXISTS vector;

Skapa sedan din dokumenttabell: CREATE TABLE documents ( id bigint primary key generated always as identity, content text, embedding vector(1536), metadata jsonb, created_at timestamptz default now() );

Skapa ett index för snabb likhetssökning: CREATE INDEX ON documents USING ivfflat (embedding vector_cosine_ops);

Detta är den enda SQL du behöver skriva. Välj EU-region när du skapar ditt Supabase-projekt (t.ex. eu-west-1 i Frankfurt) för att säkerställa att vektordata stannar inom EU.

Steg 2: Generera inbäddningar med Xano

I Xano skapar du en endpoint som accepterar en textsträng, anropar OpenAI Embeddings API (text-embedding-3-small) och lagrar resultatet i din Supabase documents-tabell.

Funktionsstacken: (1) Hämta textinput, (2) Anropa OpenAI API POST /v1/embeddings, (3) Extrahera inbäddningsarrayen från svaret, (4) Infoga i Supabase via Supabase API-kopplingen.

Kör detta för varje dokument, artikel eller FAQ-post du vill att din AI ska känna till. För svenska bolag kan detta vara: produktblad, prissättningsdokument, kundserviceskript eller juridiska avtal. Processen är identisk oavsett dokumenttyp.

Steg 3: Semantisk sökning i Xano

Skapa en andra endpoint som: (1) Accepterar en användarfrågesträng, (2) Genererar en inbäddning för frågan (samma OpenAI-anrop), (3) Kör en vektorlikhetssökning i Supabase.

Supabase RPC-funktionen för detta: SELECT content, 1 - (embedding <=> query_embedding) as similarity FROM documents ORDER BY embedding <=> query_embedding LIMIT 5;

Detta returnerar de 5 mest semantiskt relevanta delarna av användarens fråga. Systemet förstår innebörd, inte bara nyckelordsmatchning, en fråga om "semesterpolicy" hittar rätt avsnitt även om det exakta ordet inte finns i dokumentet.

Steg 4: Generera svaret med GPT-4o

Med de hämtade delarna anropar du OpenAI Chat Completions API. Systemprompten:

"Du är en hjälpsam assistent. Svara på användarens fråga med ENBART det kontext som tillhandahålls nedan. Om svaret inte finns i kontexten, säg det.

Kontext: [INFOGA HÄMTADE DELAR HÄR]"

Detta förankrar LLM:ens svar i din faktiska data och förhindrar hallucinationer. För svenska företag kan du justera systemprompten för att svara på svenska som standard, använda formellt eller informellt tilltal beroende på sammanhang, och referera till svenska regelverk eller branschterminologi.

Steg 5: Bygg chatt-UI:et i WeWeb

I WeWeb skapar du ett chattgränssnitt med en meddelandelista och ett inmatningsfält. Vid skickning: anropa din Xano sökendpoint, strömma sedan GPT-svaret med Xanos strömningsstöd eller ett direkt OpenAI-anrop från WeWebs anpassade kod.

För produktion, lägg till: meddelandehistorik (lagra i Supabase), källcitat (visa vilka dokument som hämtades) och en feedbackmekanism (tumme upp/ner för att förbättra hämtningskvaliteten).

Hela systemet kan vara live och betjäna verkliga användare inom 2-3 veckor. En intern kunskapsbas-chatbot är ett utmärkt första RAG-projekt: väldefinierat scope, mätbart värde (minskad tid på att söka i dokumentation) och låg risk.

Att välja rätt embedding-modell

OpenAI erbjuder tre embedding-modeller 2025: text-embedding-3-small (1536 dimensioner, 0,02 USD/1M tokens), text-embedding-3-large (3072 dimensioner, 0,13 USD/1M tokens), och den äldre text-embedding-ada-002. För de flesta RAG-applikationer är text-embedding-3-small rätt val: den balanserar kostnad, hastighet och hämtningskvalitet för standard dokumentsökning.

text-embedding-3-large är värt att överväga när hämtningsprecision är kritisk, juridisk avtalsanalys, medicinsk litteratursökning, eller applikationer där ett missat relevant avsnitt har betydande konsekvenser. I våra projekt jämförde vi 3-small mot 3-large på en kunskapsbas med 10 000 dokument och fann att 3-small uppnådde 94 % av 3-larges hämtningsnoggrannhet till 15 % av kostnaden.

För flerspråkiga applikationer (vanligt i vår europeiska kundbas) hanterar båda OpenAI-modellerna franska, tyska, svenska och nederländska rimligt bra. För specialiserad branschterminologi på icke-engelska språk, överväg dock att testa mot flerspråkiga specialmodeller som Coheres multilingual-22-12 via Cohere API som ett riktmärke.

Chunkningsstrategier: den dolda variabeln i RAG-kvalitet

Hur du delar upp dina dokument i chunkar är utan tvekan den viktigaste variabeln för RAG-kvalitet, mer avgörande än modellval för de flesta applikationer. För stora och dina hämtade chunkar innehåller irrelevant innehåll som förvirrar LLM:en. För små och du förlorar den kontext LLM:en behöver för att svara sammanhängande.

I våra produktions-RAG-projekt använder vi en hybrid chunkningsstrategi: dela först vid styckegränser (naturliga semantiska enheter), och tillämpa sedan en maximal chunkstorlek på 512 tokens och en minimistorlek på 100 tokens. Chunkar som är för små slås ihop med sin granne. Detta bevarar semantisk sammanhållning samtidigt som det förhindrar för stora chunkar. För strukturerade dokument (FAQ-sidor, produktspecifikationer) chunkar vi på fråga-och-svar- eller avsnittsnivå istället för efter tokenantal.

En ofta förbisedd teknik: lägg till överlappning mellan chunkar. Om chunk N slutar vid mening 10 och chunk N+1 börjar vid mening 11 går kontext som överbryggar gränsen förlorad. Vi lägger till en överlappning på 50 tokens, meningarna 9-10 från chunk N upprepas i början av chunk N+1. Denna 10-procentiga overhead förbättrar avsevärt hämtningen för frågor som refererar till koncept som spänner över chunkgränser.

Vektorlikhetströsklar och hämtningsjustering

Inte alla hämtade chunkar är lika relevanta. Cosinuslikhetspoängen som pgvector returnerar sträcker sig från 0 (ingen likhet) till 1 (identisk). I praktiken får relevanta chunkar vanligtvis poäng över 0,75, och du bör filtrera bort allt under 0,60 för att undvika att mata irrelevant kontext till LLM:en.

I din Supabase RPC-funktion, lägg till en likhetströskel: WHERE 1 - (embedding <=> query_embedding) > 0.70 ORDER BY embedding <=> query_embedding LIMIT 5. Börja med 0,70 och justera baserat på din data. Om din assistent säger "jag har ingen information om det" för frågor du vet att den borde kunna svara på, sänk tröskeln. Om den ger svar från svagt relaterade chunkar, höj den.

För avancerad hämtning, implementera en hybridsökning som kombinerar vektorlikhet med nyckelordssökning (PostgreSQLs inbyggda fulltextsökning). Denna hybridmetod, ofta kallad "reciprocal rank fusion", förbättrar precisionen för frågor med specifika egennamn, produktnamn eller tekniska termer som embeddings ibland hanterar dåligt. Supabase stöder både vektor- och fulltextsökning nativt, vilket gör hybridhämtning genomförbar utan anpassad infrastruktur.

Kostnadsoptimering för RAG i produktion

De huvudsakliga kostnadsdrivarna i ett RAG-system är: inbäddningsgenerering (när du lägger till nya dokument), inbäddning av frågor (varje användarmeddelande), och LLM-inferens (varje GPT-4o-anrop). För en typisk intern kunskapsbas med 5 000 dokument och 500 dagliga frågor är den månatliga kostnadsuppdelningen ungefär: inbäddningsingestion (engångskostnad) 0,20 USD, dagliga frågeinbäddningar 0,30 USD/månad, GPT-4o-svar vid 3 000 tokens genomsnittlig kontext 45 USD/månad. Totalt: ungefär 50 USD/månad för 500 dagliga användare.

För att minska LLM-kostnaderna, implementera ett cachningslager för vanliga frågor. Lagra de 100 vanligaste frågorna och deras svar i Supabase. Innan du anropar GPT-4o, kontrollera om en semantiskt liknande fråga har besvarats nyligen (cosinuslikhet > 0,95 mot en cachad frågeinbäddning). Cache-träffar levererar det lagrade svaret direkt, inget LLM-anrop behövs. I våra produktions-RAG-appar är 30-40 % av frågorna cache-träffar, vilket minskar LLM-kostnaderna med en tredjedel.

För applikationer med mycket hög volym, överväg att växla svarsgenereringen från GPT-4o till GPT-4o-mini för lågkomplexa frågor. Implementera ett routningslager som klassificerar frågor som enkla (faktauppslagning, enkällesvar) kontra komplexa (flerkällesyntes, analys), och dirigerar till den billigare modellen för enkla frågor. Denna hybrid-LLM-metod minskar inferenskostnaderna med 60-70 % för typiska kunskapsbasbelastningar.

Produktionsöverväganden: tillförlitlighet, övervakning och dataaktualitet

RAG-system i produktion har driftskrav som prototyp-guider ignorerar. Dokumentaktualitet är avgörande: om din kunskapsbas är föråldrad ger din AI fel svar med ett självsäkert klingande språk. Implementera en automatiserad re-ingestionspipeline, när ett dokument uppdateras i ditt CMS eller din databas, utlös ett Xano-bakgrundsjobb för att bädda in de påverkade chunkarna på nytt och uppdatera vektorindexet.

Övervakning i produktion innebär att spåra: frågelatens (inbäddning + hämtning + LLM kombinerat, bör vara under 3 sekunder för bra användarupplevelse), hämtningskvalitet (logga likhetspoängen för hämtade chunkar, ett fall i genomsnittspoängen signalerar att din dokumentmängd kanske inte täcker senaste frågorna), och användarnöjdhet (tumme upp/ner-feedback lagrad i Supabase, granskad varje vecka). I våra projekt är veckovis granskning av lågt rankade svar den enskilt mest effektiva kvalitetsförbättringsaktiviteten.

För dataisolering i multi-tenant-RAG-appar, lägg till en workspace_id-kolumn i din documents-tabell och lägg till den i varje RLS-policy och hämtningsfråga. Varje kunds kunskapsbas är helt isolerad, en användare kan bara hämta och få svar från sina egna dokument. Detta är inte förhandlingsbart för någon app som hanterar konfidentiell affärsdata, och Supabases RLS gör det enkelt att implementera korrekt.