Du behöver inte en dedikerad vektordatabas för att komma igång med RAG. Den här guiden visar hur man bygger en produktionsduglig RAG-pipeline på Supabase med pgvector - embeddings, hybridsök, re-ranking och källcitering.
Det vanligaste misstaget i tidiga RAG-projekt är att börja med en dedikerad vektordatabas innan man behöver den. För de flesta use-cases under några miljoner dokument räcker pgvector på Postgres - och om ni redan kör Supabase har ni allt på plats. Här är hur man bygger det rätt.
Varför Supabase + pgvector
RAG kräver tre saker: ett ställe att lagra embeddings, ett sätt att söka semantiskt, och er språkmodell. Supabase ger de två första via pgvector - och fördelen är att era vektorer lever bredvid er relationsdata, så att ni kan filtrera på behörigheter, metadata och datum i samma query. Det är ofta avgörande i produktion.
Steg 1: Chunking - viktigare än modellvalet
Hur ni delar upp dokumenten påverkar resultatet mer än vilken embedding-modell ni väljer. Tumregler:
- Dela på semantiska gränser (stycken, rubriker), inte på fast teckenantal.
- Lägg in lite överlapp mellan chunks så att kontext inte kapas mitt i en mening.
- Behåll metadata (källa, rubrik, datum) på varje chunk - det behövs för filtrering och citering.
Steg 2: Embeddings och lagring
Generera embeddings (OpenAI, Cohere eller en open-source-modell) och lagra dem i en pgvector-kolumn. Skapa ett HNSW-index för snabb approximate nearest neighbor-sökning. För svensk text: testa flera embedding-modeller mot ert eget innehåll - skillnaden i återhämtningskvalitet kan vara stor.
Steg 3: Hybridsök slår ren vektorsök
Ren semantisk sökning missar exakta termer (produktnamn, koder, förkortningar). Ren nyckelordssökning missar betydelse. Hybridsök kombinerar Postgres full-text search (BM25-liknande) med vektorsök och slår nästan alltid båda var för sig. Väg ihop resultaten med Reciprocal Rank Fusion.
Steg 4: Re-ranking för precision
Hämta fler kandidater än ni behöver (säg 20), och låt en cross-encoder re-ranker välja ut de bästa 5. Det här steget lyfter precisionen märkbart till en låg kostnad, eftersom re-rankern bara körs på en handfull kandidater.
Steg 5: Källcitering - icke förhandlingsbart
En RAG-lösning utan källcitering är en lösning ni inte kan lita på. Skicka med chunk-metadata till modellen och instruera den att citera källan för varje påstående. Det gör svaren verifierbara och avslöjar när modellen svarar på tunt underlag.
Steg 6: Mät med evals
Utan en eval-pipeline vet ni inte om en ändring förbättrade eller försämrade systemet. Bygg ett testset med representativa frågor och förväntade källor, och mät återhämtning (hittades rätt chunk?) och svarskvalitet vid varje ändring. Det här är skillnaden mellan en demo och ett system ni vågar sätta i produktion.
När ni ska byta från pgvector
pgvector räcker långt - typiskt upp till några miljoner vektorer med bra index. När ni passerar det, eller behöver avancerad filtrering i extrem skala, är det dags att titta på Qdrant eller Pinecone. Men börja inte där. Börja med det ni har.
“Det vanligaste misstaget i tidiga RAG-projekt är att börja med en dedikerad vektordatabas innan man behöver den. För de flesta räcker pgvector - börja med det ni har.”
- Simon Axelsson
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
