Vektordatabasarkitektur för On-Premises RAG-pipelines

Varför valet av vektordatabas är ett infrastrukturbeslut i första klass

Retrieval-augmented generation lyckas eller misslyckas beroende på kvaliteten och hastigheten hos retrievallagret. När du kör det lagret helt on-premises är vektordatabasen inte bara ett index — det är en långlivad driftskomponent som måste integreras med dina backuprutiner, säkerhetskontroller och kapacitetsplaneringsprocesser. Organisationer som behandlar den som en konfigurationsdetalj snarare än ett infrastrukturåtagande stöter regelbundet på problem sex månader in i produktion: oväntat minnestryck, ogenomskinglig replikeringssemantik eller indexformat som inte kan uppgraderas utan driftstopp.

Det här inlägget går igenom vad som skiljer de viktigaste självhostade alternativen, hur man utformar lagrings- och servetopologin, och vilka driftsvanor som förhindrar de problem som tyst urholkar RAG-tillförlitligheten.

Kartläggning av det självhostade landskapet

Fyra vektordatabaser dominerar on-premises RAG-driftsättningar idag: pgvector (ett PostgreSQL-tillägg), Qdrant, Milvus och Weaviate. Var och en av dem befinner sig på en annan position på komplexitets-kapabilitetskurvan.

pgvector är det pragmatiska standardvalet för organisationer som redan kör PostgreSQL. Du kan köra vektorsimilaritetsfrågor bredvid relationella joins, ha ett enda backupmål och använda välkänd verktygslåda. Taket är reellt — pgvector:s IVFFlat- och HNSW-index når ett mättnadspunkt vid tiotals miljoner vektorer på en enda nod — men de flesta företagsbaserade kunskapsbaserna håller sig väl inom den gränsen. Om ditt team redan behärskar PostgreSQL-drift slipper du introducera ett andra lagringssystem i förtid.

Qdrant är skriven i Rust och bygger kring HNSW-algoritmen med en segmenterad lagringsmodell. Den hanterar hundratals miljoner vektorer per nod trovärdigt, exponerar ett rent gRPC- och REST-API, och stöder namngivna nyttolastfält för metadatafiltrering. Dess on-disk-läge lagrar vektorer utanför RAM, vilket möjliggör stora index på blygsam hårdvara till priset av något högre slutlatens.

Milvus separerar lagring, koordination och frågekörning i distinkta komponenter. Den arkitekturen skalas horisontellt över många noder men tillför driftskomplexitet: du behöver etcd för koordination och MinIO eller ett S3-kompatibelt lager för segmentpersistens. Milvus är rätt val när din organisations retrievalarbetsbelastning verkligen är distribuerad och du har plattformsteknisk kapacitet att drifta det.

Weaviate levererar ett modulsystem som kan anropa inbäddningsmodeller och omrangordnare som en del av fråge-pipelinen. För team som vill ha en tätare koppling mellan retrieval och modellinferens minskar den integrationen pannplåtskod. Avvägningen är att Weaviates modulkörning introducerar ett beroende på dess egna containeravbildningar och releasecykel.

Lagrings- och minnestopologi

Vektorindex är minneshungriga. HNSW-grafer kräver vanligtvis ungefär 1,4–1,6 byte per dimension per vektor för platt float32-lagring, plus graf-anslutningsoverhead. En samling med fem miljoner 1536-dimensionella inbäddningar kräver ungefär 12 GB RAM för att servas med låg latens om den hålls helt i minnet. Planera din nodstorleksbestämning innan samlingarna växer, inte efteråt.

Två strategier minskar minnestrycket. Den första är kvantering: skalär kvantering till int8 eller produktkvantering kan minska minnesstorleken med 4–8x till priset av en liten minskad återkallning. Både Qdrant och Milvus stöder detta inbyggt. Den andra är nivåad lagring: håll heta samlingar i RAM-backed index och flytta kalla samlingar till diskbackad lagring. Automatisera nivåbefordrings- och degraderingslogiken baserat på åtkomstfrekvens.

För driftsättningar med hög tillgänglighet, replikera över minst två noder och testa failoverbeteendet under realistisk belastning innan topologin certifieras för produktion.

Integration av inbäddningspipeline

Vektordatabasen är bara en del av retrievalpipelinen. On-premises RAG kräver också en inbäddningsmodell som körs lokalt, en dokumentinmatkningstjänst och ett inbäddningssteg vid frågetid. Valet av inbäddningsmodell är kopplat till vektordatabasens schema: att byta modell innebär att återinbädda och återindexera alla dokument, vilket kan ta timmar eller dagar för stora korpusar.

Utforma din inmatningspipeline kring explicit modelversioneringsmetadata. Lagra inbäddningsmodellens namn och revision tillsammans med varje vektor. När du uppgraderar inbäddningsmodellen, kör de nya och gamla versionerna parallellt, återindexera inkrementellt och byt retrieval-trafik först efter att återkallning validerats på en hållen frågeuppsättning.

Inferensgenomströmning för inbäddning är ofta flaskhalsen, inte vektordatabasen i sig. Batch-inmatningsjobb bör gruppera dokument i stora batchar och använda en dedikerad GPU- eller CPU-arbetspool separat från den interaktiva inferensvägen.

Multi-tenancy och åtkomstkontroll

Företags-RAG-driftsättningar behöver nästan alltid isolera data mellan team, produkter eller kundsegment. Vektordatabaser hanterar detta på olika sätt, och valet har säkerhetskonsekvenser.

Den starkaste isoleringen är en separat samling per klient. En klients dokument separeras fysiskt; en felkonfigurerad fråga kan inte korsa gränser. Driftskostnaden är proportionell mot antalet samlingar. Den här modellen fungerar bra när klienterna är ett dussintal.

Nyttolastbaserad filtrering med delade samlingar minskar driftsmängden men kräver att applikationslagret tillämpar klientidentifierare på varje fråga. Qdrant stöder namngivna nyttolastfält som förstklassiga filteruttryck. pgvector förlitar sig på standard PostgreSQL rad-nivå-säkerhetspolicies, som integreras naturligt med befintliga databaskontroller.

Observerbarhet och driftshygien

Vektordatabaser sänder ut mätvärden som de flesta infrastrukturövervakningstackar inte samlar in som standard. Instrumentera som minimum: frågelatens per samling, återkallningsuppskattning via syntetiska benchmark-frågor på schema, indexstorlek och segmentantal, skrivködjup och replikeringsfördröjning. Dessa mätvärden talar om för dig om retrievallagret är friskt långt innan användare rapporterar försämrad svarskvalitet.

Schemalägg tunga komprimeringsjobb under lågtrafiktimmar och konfigurera resursgränser så att de inte kan svälta ut frågekörningstrådarna. I pgvector, granska autovacuuminställningarna för tabeller som tar emot höga infogningsfrekvenser under dokumentinmatningsburst.

Inkludera vektordatabasen i din vanliga backup- och återhämtningstestvecka. En kall återställning av en stor samling tar längre tid än de flesta team förväntar sig — mät det innan du behöver det.

Omslagsbild av Donald Wu på Unsplash.