Retrieval-augmented generation (RAG) is de gangbare manier om een taalmodel antwoorden te laten geven op basis van je eigen documenten: je zoekt eerst de relevante fragmenten op en geeft die als context mee aan het model. Veel teams zien dat als de veilige variant, omdat het model niet op je documenten wordt getraind. Dat klopt, maar het zegt niets over waar die documenten tijdens het gebruik heen gaan. Dit artikel loopt de keten stap voor stap langs en laat zien wat er per stap over de lijn gaat, zodat je kunt beoordelen of inference in een Nederlands datacenter voor jouw situatie iets oplost of alleen anders voelt.
De misvatting: alleen de vraag gaat naar buiten
Het beeld dat vaak leeft: de documenten staan bij ons, de API krijgt alleen de vraag. In werkelijkheid heeft een RAG-opstelling vier componenten die elk hun eigen verkeer veroorzaken:
- Embeddingmodel — zet tekst om in vectoren. Bij het indexeren ziet dit model elk fragment van elk document; bij elke vraag ook de vraag zelf.
- Vectordatabase — bewaart de vectoren, en in de praktijk ook de tekstfragmenten erbij, want die moet je straks terug kunnen geven.
- Reranker — optioneel, maar steeds gebruikelijker: krijgt de vraag plus een stapel kandidaatfragmenten en sorteert die op relevantie.
- Chatmodel — krijgt de vraag en de beste fragmenten als context, en schrijft het antwoord.
Zet je één van die componenten bij een externe API, dan gaat bij elke stap waar die component aan te pas komt een deel van je corpus over de lijn. Wie een jaar lang vragen stelt over zijn documentatie, heeft op den duur een groot deel daarvan naar het chatmodel gestuurd.
Wat er per stap over de lijn gaat
Het helpt om het verkeer per fase te bekijken, omdat de volumes sterk verschillen.
- Indexeren — het grootste volume. Elk document wordt in fragmenten geknipt en elk fragment gaat naar het embeddingmodel. Dit is je volledige corpus, in platte tekst, over de lijn.
- Vraag stellen — klein. De vraag gaat naar het embeddingmodel, de vector naar de vectordatabase. Een vector is een rij getallen, daar lees je de vraag niet uit terug.
- Zoeken en rerangschikken — middelgroot. De vectordatabase geeft kandidaatfragmenten terug; de reranker krijgt ze allemaal en de vraag erbij. Dit is weer tekst.
- Antwoord genereren — de vraag plus de geselecteerde fragmenten gaan als één prompt naar het chatmodel. Ook tekst, bij elke vraag.
Het punt dat teams het vaakst missen is de vectordatabase. Die klinkt als een bak abstracte getallen, maar het tekstfragment staat er bijna altijd naast opgeslagen. Een beheerde vectordatabase buiten de deur is dus een kopie van je corpus buiten de deur, met het zoekverkeer er bovenop.
Re-indexeren: bandbreedte en egress
Indexeren doe je niet één keer. Je wisselt van embeddingmodel, verandert de fragmentgrootte, of je documenten worden bijgewerkt. Bij elke volledige herindexering gaat je hele corpus opnieuw naar het embeddingmodel. Wie zijn documenten in een hyperscaler heeft staan en het embeddingmodel ergens anders, betaalt daar ook egress over, en bij de meeste cloudaanbieders is uitgaand verkeer de dure richting.
Staan opslag, embeddingmodel en vectordatabase in hetzelfde datacenter, dan is herindexeren verkeer binnen het rack of over een cross-connect. Dat kost geen egress en de bandbreedte is meestal niet de bottleneck; het embeddingmodel zelf is dat.
Alles in één datacenter: wat het wel en niet oplost
De opstelling die het verkeer binnenhoudt, is eenvoudig te beschrijven: je eigen servers met de documenten en de vectordatabase in colocatie, het embeddingmodel, de reranker en het chatmodel in hetzelfde gebouw, en daartussen een cross-connect of een privé-VRF op de EVPN-fabric. Geen enkel fragment raakt het publieke internet.
Wees wel eerlijk over wat dat betekent. Het lost de vraag op waar je documenten zijn en wie ze onderweg zou kunnen zien. Het lost niet op wie er bij de servers kan, wat er gelogd wordt en of een model op je data traint; dat regel je contractueel, met een verwerkersovereenkomst en afspraken over logging. En ook binnen één datacenter zet je TLS gewoon aan, want een privaat netwerk is geen reden om verkeer onversleuteld te laten.
Eerlijk over latency
Latency wordt vaak als tweede argument genoemd, en dat verdient nuance. Een cross-connect binnen één datacenter zit typisch onder de 0,3 ms heen en terug; Ede–Amsterdam ligt rond de 1 tot 2 ms en Nederland–Verenigde Staten rond de 80 tot 120 ms. Dat zijn gangbare waarden, niet door ons gemeten.
Zet daar het genereren van één chatantwoord naast: honderden milliseconden tot seconden. Voor een gebruiker die één vraag stelt, verdwijnt de netwerkwinst in de ruis. Waar het wél telt:
- Agents en meerstaps-RAG — een taak die 10 tot 100 aanroepen achter elkaar doet, telt elke ronde netwerk mee. Honderd keer 100 ms is tien seconden; honderd keer 0,3 ms merk je niet.
- Indexeren in batches — duizenden embedding-aanroepen kort na elkaar.
- Spraak — transcriptie en antwoord in dezelfde pijplijn, waar elke ronde wachttijd hoorbaar is.
Kies dus niet voor één datacenter omdat het sneller voelt, maar omdat je weet welk type werklast je draait.
RAG bij Xyphen IT
Wij leveren AI-inference in BIT-2C in Ede met een OpenAI-compatibele API, gedeeld per token of op dedicated kaarten. Embeddings, reranking en chat draaien daar naast elkaar; hoe je daarop aansluit, staat op de technische pagina. Staan je documenten en vectordatabase in een eigen rack bij ons in BIT-colocatie, dan koppelen we die met een cross-connect of een privé-VRF op onze EVPN-fabric. Geen training op je data en geen opslag van prompts leggen we vast in een addendum en de verwerkersovereenkomst. Heb je nog geen RAG-pijplijn, dan kunnen we die als softwareontwikkeling bouwen.
Wil je weten of dit voor jouw corpus en werklast past? Vraag een voorstel aan of neem contact op.