Van zoekindex naar rekening

Hoe RAG in Azure werkt

Een RAG-architectuur in Azure bestaat typisch uit drie lagen. Azure AI Search indexeert je documenten en slaat vectorembeddings op, de numerieke representaties van tekst die semantisch zoeken mogelijk maken. Azure OpenAI Service genereert antwoorden op basis van wat de zoeklaag ophaalt. Azure Blob Storage of een andere bron bevat de originele documenten.

Van die drie lagen is Azure AI Search veruit de meest complexe in de kostenstructuur. En het minst begrepen.

De tier-indeling van Azure AI Search

Azure AI Search kent meerdere tiers, van Free tot Storage Optimized, en heeft geen autoscaling. Dat betekent handmatig kiezen. Basic biedt een beperkt aantal indexen, maximaal 2 GB opslag, geen replica’s of partities. Geschikt voor kleine pilots. Standard S1, S2 en S3 zijn de meest gebruikte productietiers. S1 begint rond €250 per maand, S3 loopt op tot een paar duizend euro per maand per Search Service. Het verschil zit in queryvolume, indexgrootte en de mogelijkheid om replica’s en partities toe te voegen. Storage Optimized L1/L2 is voor zeer grote indexen (tot 12 TB), met kosten vanaf een paar duizend per maand.

Replica’s en partities worden apart doorberekend bovenop de basistierprijs. Elke extra replica (voor hoge beschikbaarheid) of partitie (voor schaalbaarheid) vermenigvuldigt de kosten.

Bij een klant die we recent doorlichtten zagen we dit in de praktijk. Drie replica’s en twee partities geconfigureerd voor hun RAG-omgeving. Maandelijkse kosten: bijna €18.000. Na analyse bleek één replica ruim voldoende voor het queryvolume. Ze zitten nu rond de €1.900 per maand.

Hoe je per ongeluk op de verkeerde tier belandt

De meest voorkomende oorzaken die wij zien:

Kopiëren van productie-instellingen naar niet-productieomgevingen. Een Storage-configuratie die voor productie terecht is, wordt gekopieerd naar een testomgeving die een tiende van het queryvolume heeft. Niemand past de tier aan.

Redundantie als standaard. Drie replica’s instellen voor de zekerheid, zonder te analyseren of de uptime-vereisten dat rechtvaardigen. Voor een interne kennisbank die een uurtje per dag offline mag zijn, zijn drie replica’s een dure luxe.

Vectordimensies en indexgrootte onderschat. Bij RAG-systemen met video- of afbeeldingscontent worden vectorembeddings significant groter dan bij tekstdocumenten. Grotere indexen dwingen je naar hogere tiers of meer partities, maar dat wordt zelden vooraf doorgerekend.

Geen review na de pilotfase. Na livegang groeit het gebruik niet zo hard als verwacht, maar de tier wordt niet naar beneden bijgesteld. De pilotconfiguratie wordt de productieconfiguratie.

Het redundantievraagstuk

Een zoekindex in Azure AI Search is afleidbaar uit de brondata. Als die brondata (documenten, video’s, bestanden) op een andere locatie beschikbaar en veilig opgeslagen is, is de index herbouwbaar. Niet in een seconde, maar wel binnen acceptabele tijd voor de meeste toepassingen.

Dat betekent dat hoge beschikbaarheid van de index zelf voor veel use cases niet noodzakelijk is. Toch kiezen teams standaard voor maximale redundantie, zonder die afweging expliciet te maken.

Het gevolg: een organisatie betaalt meer dan twee ton per jaar voor een zoekindex die drie keer redundant staat, terwijl de onderliggende video’s gewoon lokaal aanwezig zijn. De index kapot? Herbouwen duurt vier uur. Dat rechtvaardigt niet die redundantiekosten.

I/O-tuning als alternatief voor tier-opschaling

Net als bij GPU-workloads geldt ook bij Azure AI Search: trage query-respons leidt vaak tot de conclusie dat je naar een hogere tier moet. De bottleneck zit ook hier regelmatig in de configuratie, niet in de capaciteit.

Vectorzoeken is rekenintensief, maar de performance wordt sterk beïnvloed door het aantal vectoren, de keuze van het vectoralgoritme (HNSW vs. exhaustive KNN), de dimensionaliteit van de embeddings, en de manier waarop hybride zoeken (semantisch en keyword-zoeken gecombineerd) is geconfigureerd.

Overmatig brede zoekopdrachten die grote stukken van de index doorzoeken in plaats van gerichte top-K queries kosten onevenredig veel query-capaciteit. Dit drijft het verbruik op zonder dat de resultaten er beter van worden.

Tuning op dit niveau (kleinere vectordimensies, juiste algoritme-instellingen, query-optimalisatie) kan de belasting op de Search Service met 30 tot 50% verminderen. Dat is het verschil tussen S3 en S2, of tussen S2 met twee partities en S2 zonder.

Wat je concreet kunt doen

Analyseer je huidige queryvolume en indexgrootte ten opzichte van je tier: zijn ze in balans? Beoordeel per replica wat de werkelijke beschikbaarheidsbehoefte is van de applicatie. Check of de brondata al elders beschikbaar is voordat je voor volledige indexredundantie kiest. Profileer je zoekopdrachten: zijn er brede queries die te veel capaciteit verbruiken? Review de tier na elke significante wijziging in gebruik, omhoog én omlaag.

Dit zijn geen grote technische ingrepen. Het zijn overwegingen die nu vaak worden overgeslagen omdat organisaties nog in de leerfase zitten en niemand er eigenaarschap over heeft. Onze aanbeveling: elk nieuw RAG-project al bij het aanvragen van een Azure AI Search-service uitvragen op verwacht queryvolume, indexgrootte en tier-keuze. Geen onderbouwing? Geen goedkeuring boven Basic/S1. En na 90 dagen een review.

Grip op AI-kosten begint bij architectuurbegrip

RAG is geen product dat je koopt, het is een architectuur die je bouwt. Elke architectuur heeft componenten met eigen kostenprofielen die met elkaar interacteren. Een keuze in de indexlaag heeft gevolgen voor de OpenAI-kosten. Een brede query kost meer Search-capaciteit én meer tokensverbruik bij het taalmodel.

Dat totaalplaatje ontbreekt bij de meeste teams die RAG in productie draaien. Ze zien de afzonderlijke factuurregels, maar niet de samenhang. Zonder die samenhang is sturen op kosten gissen.

Draait je RAG-omgeving in Azure en vraag je je af of de tier-keuze nog klopt?

OptimaSure analyseert je AI Search-configuratie en geeft je binnen 30 dagen een concreet optimalisatieplan. Neem contact op.