RAG i produktion: Chunking, embeddings, reranking och evals

RAG är lätt att demonstrera och svårt att driftsätta. Den här guiden går igenom chunking, embeddings, retrieval, reranking och evals - de delar som avgör om systemet håller i produktion.

RAG (Retrieval-Augmented Generation) är bedrägligt enkelt att demonstrera. Mata in några dokument, koppla på en embeddingmodell och en LLM, och du har en chatt som svarar på din data inom en eftermiddag. Problemet är att avståndet mellan den demon och ett system som håller i produktion är enormt. De flesta RAG-projekt som fastnar gör det inte i modellen - de gör det i de delar ingen visar upp i demon: chunking, retrieval-kvalitet och utvärdering.

Den här guiden går igenom de fyra delarna som faktiskt avgör utfallet. Vill du ha hjälp att bygga eller rädda ett RAG-system arbetar jag med det inom AI Engineering.

Del 1: Document ingestion & chunking-strategier

Hur du delar upp dina dokument avgör vad modellen någonsin kan hitta. Chunkar du för grovt drunknar det relevanta i brus; chunkar du för fint tappar du sammanhang.

Fixed-size vs recursive vs semantic chunking - när välja vad

Fixed-size (dela var n:te token) är enkelt och förutsägbart men klyver ofa meningar mitt itu. Recursive chunking respekterar struktur (stycken, rubriker) och är en bra standard för de flesta dokument. Semantic chunking grupperar text efter betydelse och lönar sig först när dokumenten är långa och tematiskt spretiga - annars är det överarbete. Börja recursive; gå till semantic bara om utvärderingen visar att du behöver det.

Chunk overlap och metadata-berikad chunking

En liten överlappning mellan chunkar bevarar sammanhang vid gränserna. Minst lika viktigt är metadata: tagga varje chunk med källa, rubrik, datum och avdelning. Det gör att du kan filtrera retrieval ("bara HR-dokument, bara senaste året") - vilket ofta höjer kvaliteten mer än någon modelluppgradering.

Del 2: Embeddings och vektordatabaser

OpenAI text-embedding-3 vs Cohere vs E5-large: benchmarks

Embeddingmodellen är billigare att byta än du tror och viktigare än du tror. text-embedding-3 är en stark standard; Cohere och öppna modeller som E5-large kan vara bättre för specifika språk eller domäner. Det viktiga är att mäta på er data - publika benchmarks förutsäger sällan hur det går på era dokument.

pgvector vs Qdrant vs Weaviate - val för produktion

Mitt vanligaste råd: börja med pgvector i den Postgres ni redan har. Det räcker långt - typiskt miljontals vektorer med rätt index. Gå till en dedikerad vektordatabas som Qdrant eller Weaviate först när ni faktiskt behöver avancerad filtrering i extrem skala. Att börja med en separat databas innan behovet finns är det vanligaste överengineeringsmisstaget i tidiga RAG-projekt.

Del 3: Retrieval och reranking

Hybrid search: BM25 + vektor i kombination

Ren vektorsökning missar exakta termer (produktnamn, artikelnummer, paragrafer). Ren nyckelordssökning missar synonymer och omformuleringar. Hybrid search kombinerar BM25 (nyckelord) med vektorsökning och ger nästan alltid bättre träffar än någondera ensam.

Reranking med Cohere Rerank och cross-encoders

Hämta brett, ranka smalt. Ett första retrieval-steg hämtar säg 50 kandidater; en reranker (Cohere Rerank eller en cross-encoder) sorterar om dem efter verklig relevans och du skickar bara de bästa till modellen. Det här steget hoppar de flesta över - och det är ofta den enskilt största kvalitetshöjningen.

▶ Bygg RAG-system med SIAX. Från arkitektur till evals - se AI Engineering.

Del 4: Evals och kontinuerlig förbättring

Ragas, ARES och custom evals i CI/CD

Det här är skillnaden mellan ett demo och ett system du vågar lita på. Utan evals vet du inte om en ändring i prompt, chunking eller modell gjorde det bättre eller sämre - du gissar. Ramverk som Ragas mäter faithfulness (hänger svaret ihop med källan?) och answer relevance. Bygg en uppsättning verkliga frågor med facit och kör dem i CI, så att varje ändring valideras automatiskt. Mer om det i Evals för LLM-appar.

Relaterat

Vill du ta det vidare?

Jag bygger och granskar RAG-system för svenska bolag - med evals som kvalitetsgrind från dag ett. Boka ett samtal så går vi igenom ert use case.

Vanliga frågor

Behöver vi en dedikerad vektordatabas för RAG?

Oftast inte i början. pgvector i en befintlig Postgres räcker långt - typiskt miljontals vektorer med rätt index. En dedikerad databas som Qdrant blir motiverad först vid avancerad filtrering i stor skala.

Varför misslyckas RAG-system i produktion?

Sällan på grund av modellen. Det vanliga är dålig chunking, ren vektorsökning utan hybrid/reranking, och avsaknad av evals - så att ingen vet om ändringar gör systemet bättre eller sämre.

Vad är en eval i RAG-sammanhang?

En automatiserad utvärdering mot en uppsättning frågor med känt facit, som mäter t.ex. faithfulness och answer relevance. Körd i CI fångar den regressioner när prompt, chunking eller modell ändras.