Retrieval-infrastructuur en vectorstores

Een proof-of-concept voor vectorzoeken en een productiesysteem dat standhoudt onder reëel querybelasting zijn twee verschillende engineeringproblemen. Wij bouwen en beheren de retrieval-infrastructuurlaag die onder uw RAG-pipeline, uw agentische workflows of uw semantische-zoekproduct ligt — de vector-engine, de embedding-pipeline die deze voedt, het indexlevenscyclusbeheer dat deze gezond houdt, en de observability-stack die kwaliteitsverlies opmerkt voordat gebruikers het merken.

Wij zijn leverancierneutraal wat de engine betreft. Onze praktijk is engine-agnostisch over Qdrant, Milvus, Weaviate, pgvector en Elasticsearch kNN, en welke we aanraden hangt af van uw vectoraantal, querypatronen, multitenancy-eisen en operationele capaciteit.

Van een demo met 50K vectoren naar productie met 200M vectoren

De kloof tussen een demo en een productiesysteem is vrijwel volledig een infrastructuurprobleem. De demo laadt 50K vectoren in Pinecone, voert een cosinus-similariteitsquery uit en retourneert resultaten in 40ms. Productie ziet er totaal anders uit.

• 200M vectoren en 500 queries per seconde aanhoudend
• 15 metadata-filterdimensies en documenten die worden bijgewerkt — elk uur
• Drie teams die één cluster delen onder strikte tenantisolatie

Op die schaal doen HNSW-compactiepieken uw P99 exploderen tot 800ms, degradeert recall stilzwijgend na een week aan incrementele updates, en kan de embedding-pipeline uw documentwijzigingssnelheid niet bijhouden. Dit is waar wij werken.

Enginekeuze is een benchmarkoefening, geen merkbeslissing

Elke leverancier claimt best-in-class prestaties; de benchmarks vertellen een genuanceerder verhaal. Wij kiezen geen database uit een featurematrix — we laden uw werkelijke vectoren, voeren uw werkelijke queries uit met uw werkelijke metadatafilters, en meten recall bij operationeel relevante k -waarden naast P50/P95/P99-latentie onder gelijktijdige belasting.

De resultaten spreken regelmatig de leveranciersmarketing tegen. Pinecones serverless-tier lijkt kosteneffectief totdat aanhoudende high-QPS-workloads de read-unit-kosten voorbij het break-evenpunt van self-hosting duwen, en pgvector lijkt beperkend totdat iteratieve scans de gefilterde-zoekkloof dichten.

De embedding-pipeline is waar productieretrieval in werkelijkheid breekt

Teams besteden 60% van hun engineeringinspanning voor vectorzoeken aan de pipeline, niet aan de store. De pipeline verzorgt documentingestie, chunking, inferentie van het embedding-model, incrementele herindexering bij documentupdates, en metadatapropagatie — en elke fase heeft faalvormen die stilzwijgend de retrievalkwaliteit degraderen.

• Verouderde kennis — de op één na meest voorkomende productie-RAG-storing. Een document wordt bijgewerkt in Confluence maar de index bedient nog steeds de oude embedding. De oplossing is change-data-capture-triggers die incrementeel opnieuw embedden, geen nachtelijke batch-herindexering.
• Spookdocumenten — een brondocument wordt verwijderd maar de vector blijft bestaan, waardoor resultaten worden geretourneerd voor content die niet langer bestaat. Omdat atomaire transacties over een source-of-truth-systeem en een vectorstore heen bijna onmogelijk zijn in gesplitste architecturen, bouwen wij reconciliatielagen die verweesde vectoren detecteren en opschonen.

De keuze van het embedding-model is belangrijker dan de meeste teams beseffen, en later wisselen is duur: het opnieuw embedden van 8M documenten wanneer u upgradet van text-embedding-ada-002 naar text-embedding-3-large kost dagen rekentijd en vereist dual-write-infrastructuur om downtime te vermijden. Wij evalueren modellen tegen uw domeinspecifieke queryset voordat u zich vastlegt.

• Cohere embed-v4 — leidt in meertalige retrieval tegen $0,01 per miljoen tokens over 100+ talen.
• Nomic Embed v2 — 137M parameters, draait op CPU, met de beste kwaliteit-tot-grootteverhouding op de markt.
• OpenAI text-embedding-3-large — een sterke allrounder.

De juiste keuze hangt af van uw talenmix, latentie-eisen, en of u API-afhankelijkheid kunt accepteren of on-premises inferentie nodig heeft.

Indexlevenscyclus: het operationele probleem waar niemand u voor waarschuwt

HNSW-indices degraderen — geen bug, maar een architecturale realiteit. Bij 160M vectorenduurt een volledige HNSW-rebuild 3–6 uur. Incrementele updates maken de grafiekstructuur suboptimaal en eroderen recall in de loop van de tijd; compactie-events doen de querylatentie pieken; en elke upsert, delete en segmentmerge triggert subindex-rebuilds die CPU verbranden aan onderhoud in plaats van aan het bedienen van queries. De afweging is onontkoombaar: het opvoeren van 0,8 naar 0,95 recall verhoogt de HNSW-latentie met ruwweg 31%.

Wij engineeren levenscyclusbeheer dat continue ingestie absorbeert zonder kwaliteitsverlies:

• Blauw-groene indexrotatie — rebuild op aparte infrastructuur en wissel atomair met nul downtime.
• Geautomatiseerde recall-validatiepoorten — vergelijk een gouden queryset met de huidige index na elke grote operatie; als recall onder de drempel zakt, vindt de wissel niet plaats.
• GPU-versnelde HNSW-opbouw in Qdrant en Elasticsearch verkort rebuild-tijden met een orde van grootte, hoewel de orkestratie van wanneer te rebuilden, hoe te valideren en hoe te wisselen maatwerkengineering is.

Kwantisatie breidt dit verder uit. Qdrant biedt nu 1,5-bit, 2-bit en asymmetrische kwantisatie, en Elasticsearch BBQ reduceert de heap met meer dan 95% ten opzichte van float32. Deze besparen geheugen en verbeteren de doorvoer, maar elk schema heeft een ander recall-profiel tegen verschillende dataverdelingen — dus karakteriseren wij de recall-impact op uw specifieke vectoren voordat we kwantisatie in productie inzetten.

Multitenancy en isolatie op reële schaal

Platformteams die 200+ interne ML-teamsbedienen, of SaaS-producten met duizenden klanttenants, hebben infrastructuur nodig die isolatie garandeert: de queries van tenant A mogen nooit de data van tenant B retourneren, auditlogs moeten elke query herleiden tot een tenantidentiteit, en koude tenants mogen geen resources verbruiken die hete tenants nodig hebben.

• Weaviate — het one-shard-per-tenant-model met tenantstatussen (ACTIVE, INACTIVE, OFFLOADED naar S3) is de meest volwassen implementatie voor deployments met een hoog tenantaantal.
• Milvus — ondersteunt isolatie op database-, collectie-, partitie- of partitiesleutelniveau, waarbij de granulariteit wordt afgestemd op uw compliance-eisen.

Beide vereisen maatwerkorkestratie op schaal — tenantprovisioning, statustransities, quotabeheer en detectie van cross-tenant-lekkage worden niet door de database zelf afgehandeld. Wij bouwen de operationele laag die multitenancy beheersbaar maakt voor gereguleerde deployments die SOC 2- of ISO 27001- compliance vereisen.

Agentische workflows hervormen de infrastructuureisen

De agentische-AI-golf verandert wat vectorstores moeten doen. Statische RAG haalt documenten op uit een vast corpus. Agentische workflows vereisen episodisch geheugen (conversatiegeschiedenis en tussentijdse redenering), semantisch zoeken over een groot documentcorpus, en gebruikersprofiel-lagen — vaak alle drie in één agentstap. De latentie-eis van sub-400ms is strakker dan bij batch-RAG, en ACID-transactieondersteuning wordt essentieel voor multistap-agents die de status bijwerken zonder gedeeltelijke writes.

Geen enkele vectordatabase verwerkt alle drie de geheugenlagen goed, dus stellen teams multistore-architecturen samen: Redis voor sessiestatus, Qdrant of Milvus voor semantisch zoeken, en een grafiekdatabase voor relatietracking. Oracle's Unified Memory Core (maart 2026) poogt vector-, JSON-, grafiek-, relationele en ruimtelijke queries in één engine te doen convergeren. Wij ontwerpen de retrieval-laag voor agentische systemen — welke stores welke geheugentypes verwerken, hoe queries over stores routeren, en hoe consistentie standhoudt wanneer een agent in één redeneringsstap de status over meerdere backends bijwerkt.

Wat wij leveren

Elk traject begint met een benchmarkingfase: we laden uw vectoren, voeren uw queries uit en produceren gekwantificeerde engine-aanbevelingen. Van daaruit bouwen we de productie-infrastructuur:

• Het vectorstore-cluster, met capaciteitsplanning en scaling-runbooks.
• De embedding-pipeline, met CDC-getriggerde incrementele herindexering en beheer van modelversies.
• De indexlevenscyclus-automatisering, met blauw-groene rotatie en recall-validatiepoorten.
• De multitenancy-orkestratielaag, wanneer u tenantisolatie nodig heeft.
• De observability-stack, met driftdetectie, recall-regressiewaarschuwingen en P95/P99-latentiemonitoring.
• Migratietooling voor teams die tussen engines overstappen, met tussentijdse Parquet -formaten om embeddings te behouden waar de dimensionaliteit overeenkomt in plaats van een volledige her-embed af te dwingen.

Wij scopen elk traject met expliciete maandelijkse infrastructuurkostenprojecties, zodat u weet wat productie zal kosten voordat u zich vastlegt.