MongoDB heeft Atlas uitgebreid met nieuwe functies die gericht zijn op het transformeren van het gegevensplatform zelf tot een laag van geheugen, context en informatieherwinning voor applicaties en artificiële intelligentie-agenten. Het bedrijf voegt geautomatiseerde embeddings toe met Voyage AI-modellen, een zelfstandige API voor embeddings en reranking, vectorsearch over streamingdata, en het nieuwe voyage-code-4-model, dat zich specialiseert in het vinden van relevante code voor programmeeragenten.
De kernpunten van MongoDB’s nieuwe RAG-strategie in 20 seconden
- Atlas kan automatisch embeddings genereren en bijwerken wanneer documenten veranderen.
- MongoDB biedt Voyage AI-modellen via een API die zelfs buiten Atlas gebruikt kan worden.
voyage-code-4is gespecialiseerd in codeherstel voor programmeeragenten.- Native reranking maakt het mogelijk resultaten semantisch te herschikken op basis van relevantie.
- Het bedrijf streeft ernaar om architecturen met gescheiden operationele systemen, vector stores en embedding pipelines te vermijden.
Deze aanpak richt zich op een van de minder zichtbare maar toonaangevende uitdagingen bij verhoogde generatieve systemen via retrieval, bekend als RAG (Retrieval-Augmented Generation). De prestaties van een agent hangen niet alleen af van het taalmodel zelf, maar ook sterk van de kwaliteit en actualiteit van de informatie die wordt teruggevonden voordat een beslissing wordt genomen.
Een grote taalmodel kan zeer capabel zijn en toch een matige context ontvangen.
Als een vectorzoekactie het verkeerde document, een oudere versie, of slechts fragmenten teruggeeft die niet relevant zijn, dan zal het model oordelen op basis van incorrecte informatie. En wanneer een agent acties kan uitvoeren, wordt het probleem niet meer beperkt tot het geven van een verkeerde respons.
MongoDB wil die informatieherwinning dichter bij de operationele data brengen, waar deze al bestaat.
Atlas genereert embeddings bij datawijzigingen
De sleutel is Automated Embedding.
Tot voor kort vereiste een typische RAG-architectuur meerdere stappen. Een applicatie schreef data naar de database, een apart proces detecteerde wijzigingen, extraheerde tekst, riep een embedding-model aan, sloeg het vectorbestand op in een ander systeem, en hield beide stores synchroon.
Dat werkte, maar voegde extra componenten en potentiële faillissementspunten toe.
Nu maakt MongoDB het mogelijk om een Voyage AI-model te koppelen aan een index voor Vector Search. Atlas genereert automatisch een embedding voor een geselecteerd veld zodra een document wordt geïndexeerd, en creëert ook het vectorrepresentatie bij zoekopdrachten.
Wanneer een document wijzigt, wordt de vectorrepresentatie automatisch hernieuwd.
Dit maakt het overbodig een extern proces te onderhouden dat wijzigingen detecteert en vector stores bijwerkt.
Deze functie werd in mei als public preview gelanceerd en de huidige documentatie toont dat hij beschikbaar is voor gratis cluster types M0, Flex, en betaalde clusters vanaf M10 of hoger. Voor dedicated clusters is het noodzakelijk om automatische schaalbaarheid van opslag en rekenkracht te activeren om de initiële opbouw van grote indices te kunnen ondersteunen.
Deze aanpak is vooral interessant voor agents die werken met voortdurend veranderende data.
Een bijgewerkte vectorcopy gedurende de nacht kan voldoende zijn voor relatief statische documentenverzamelingen. Minder geschikt is het wanneer agents snel moeten reageren op nieuwe orders, incidenten, voorraden, gesprekken of logboeken die net zijn aangepast.
MongoDB wil voorkomen dat agents werken met verouderde context
Het bedrijf gebruikt een eenvoudige verklaring voor zijn strategie: een agent zou direct informatie moeten ophalen over de actuele stand van zaken.
Deze doelstelling wordt bemoeilijkt door meerdere losse lagen en systemen.
Een architectuur kan MongoDB als operationele basis gebruiken, daarnaast een apart vector store-product, een extern embedding-systeem, en een model voor reranking. Elkeen functioneert op zichzelf correct, maar er bestaat altijd vertraging tussen de actuele data en de representatie waarmee de agent werkt.
MongoDB probeert die synchronisatie te verkleinen door operatie en semantisch ophalen op hetzelfde platform te brengen.
Dat betekent niet dat alle RAG-architecturen moeten verenigen. Gespecialiseerde tools bieden nog steeds voordelen, vooral als er al een robuuste infrastructuur bestaat of specifieke functies nodig zijn van andere systemen.
De strategie van MongoDB is om componenten te reduceren wanneer die specialisatie niet operationeel rendabel is.
De casus van Financial Times wordt als voorbeeld aangehaald. De krant gebruikt Automated Embedding met Voyage AI-modellen voor semantische zoekopdrachten en verwerkt meer dan 100.000 zoekacties per dag. Ze zijn bezig met verschillende modellen om een balans te vinden tussen nauwkeurigheid en kosten.
MongoDB noemt ook Eve, een juridische AI-platform, dat hun API voor embeddings en reranking test voor het herstellen van relevante documenten in juridische dossiers.
Deze voorbeelden komen van klanten zelf en zijn geen onafhankelijke benchmarks.
voyage-code-4: zoeken naar code vereist een ander model
Een belangrijke nieuwe ontwikkeling is voyage-code-4, ontworpen specifiek voor codeherstel.
Deze oplossing speelt in op de groeiende behoefte bij agents die werken met repositories en grote codebases, zoals Codex, Claude Code en soortgelijke tools.
Voorafgaand aan het aanpassen van een applicatie moet de agent relevante bestanden, functies, klassen of implementaties vinden die bij de taak horen. Een puur tekstuele zoekopdracht volstaat niet altijd, en een generiek embeddingsmodel kan de semantische relaties tussen stukken software onvoldoende vastleggen.
MongoDB positioneert voyage-code-4 als een gespecialiseerd model voor deze hersteltaak.
Dit opent bredere toepassingen dan enkel het beantwoorden van documentatievragen.
Bijvoorbeeld, een programmeeragent die een authenticatiefout moet oplossen, kan moeten vinden:
- de middleware voor sessiebeheer,
- de gebruikerstoegangscode,
- gerelateerde testcases,
- een token-vernieuingsfunctie,
- configuraties met verschillende benamingen voor hetzelfde concept.
De nauwkeurigheid van die eerste stap bepaalt de kwaliteit van alles wat daarna gebeurt.
MongoDB claimt dat zijn Voyage-modellen hoog scoren op de Retrieval Embedding Benchmark (RTEB). Ze kondigden eerder Voyage 4 aan als superieur aan andere modellen op publieke tests, wat op benchmarkresultaten en interpretaties van MongoDB gebaseerd is. Echter, dat betekent niet automatisch dat het in elke real-world toepassing of dataset de beste keuze is.
Embeddings en reranking hoeven niet altijd vanuit MongoDB te komen
Een andere belangrijke strategiepunt is dat de nieuwe Embedding and Reranking API het mogelijk maakt om Voyage AI-modellen direct vanuit Atlas te gebruiken, ook als de data of applicatie op een andere cloud of systeem staat.
Hierdoor wordt MongoDB ook leverancier van recovery-modellen, los van de database-implementatie.
Ontwikkelaars kunnen via Atlas een API-sleutel aanmaken om Voyage AI te gebruiken, zonder dat data in MongoDB zelf nodig is. De facturering is op tokens gebaseerd. Zo kunnen applicaties gebruikmaken van deze modellen zonder dat ze afhankelijk zijn van een MongoDB-deploy.
De overname van Voyage AI in 2025 maakte de strategische verschuiving mogelijk. Het doel is niet alleen het verbeteren van Vector Search binnen Atlas, maar ook het aanbieden van de modellen als zelfstandige service.
Naast embeddings introduceert men ook reranking. Een initiële vectorsearch kan bijvoorbeeld tientallen zoekkandidaten opleveren; een reranker herschikt die resultaten op basis van een precisere modellering, zodat relevantere documenten eerder komen.
Deze reranking kan de hoeveelheid irrelevante resultaten verminderen en het aantal tokens dat het LLM moet verwerken beperken, wat belangrijk is voor kosten en efficiëntie.
Begin juli werd ondersteuning voor $rerank toegevoegd binnen MongoDB Search en Vector Search, wat de integratie voor RAG-toepassingen versterkt.
Agentkosten worden ook vooraf bepaald
De relatie tussen retrieval en kosten wordt vaak over het hoofd gezien. Bijvoorbeeld, als een agent een vraag beantwoordt door documenten te zoeken, dan bepaalt de kwaliteit van de retrieval de hoeveelheid en de relevantie van de data die aan het model wordt gevoerd.
Een minder precieze zoekactie kan dat betekenen dat 20 documenten worden doorgestuurd, terwijl een betere zoekactie het aantal kan terugbrengen tot slechts vijf.
Het besparen komt niet door een goedkopere LLM te kiezen, maar doordat het model minder en relevantere context krijgt, wat de kosten verlaagt.
Voor agents die meerdere zoekacties uitvoeren, geldt hetzelfde: elke overbodige zoekopdracht vergroot het kostenplaatje. Het optimaliseren van retrieval en embeddingdimensies helpt deze kosten te beheersen.
MongoDB experimenteert met het gebruik van gedeelde embedding-ruimte, zodat een documentvector met een model wordt gemaakt en deze later met een lichter model kan worden benaderd. Ook het reduceren van dimensies via technieken als matryoshka learning kan opslag en rekenkosten drukken.
Deze technieken moeten per toepassing worden geëvalueerd: kleinere vectoren of eenvoudiger modellen kosten minder, maar kunnen ten koste gaan van de nauwkeurigheid die nodig is voor het specifieke gebruik.
Vector search voor data in beweging
De vierde nieuwe functionaliteit is de integratie van vectorherwinning binnen Atlas Stream Processing.
MongoDB Stream Processing maakt het mogelijk realtime data van bronnen zoals Kafka, of van databasewijzigingen te ontvangen, te transformeren en de resultaten te schrijven naar collecties of externe systemen.
Door vectorsearch hieraan toe te voegen kunnen agents incidenten en gebeurtenissen in real-time koppelen aan semantisch vergelijkbare informatie.
Dit opent nieuwe use-cases buiten de traditionele document-gebaseerde RAG.
Voorbeeld: een stroom gebeurtenissen kan een nieuwe incidentenrapportage vergelijken met eerdere incidents, telemetrie koppelen aan bekende situaties of berichten in real-time verrijken.
MongoDB’s ambitie is dat streaming data niet eerst in een statische collectie hoeven te worden geconverteerd om semantische recall mogelijk te maken.
Deze aanpak is waardevol voor operationele systemen, zoals monitoring, support of incidentdetectie, waar context snel en vroeg nodig is, terwijl het event nog wordt afhandeld.
MongoDB’s rol in de agent-architectuur
Deze innovaties passen binnen een bredere strategie die zich richt op een centraal geheugen- en contextmodel voor agenten.
Tijdens de Build Fest op 13 augustus in San Francisco presenteerde MongoDB haar platform met vier kernbegrippen: geheugen, status, context en recovery voor AI-agenten.
Het bedrijf kondigde ook integraties aan met Claude, Claude Code, ChatGPT, Codex, Grok Build en Devin, plus een managed MCP-server voor Atlas.
Het commerciële doel is duidelijk: MongoDB moet niet alleen een plek zijn om documenten op te slaan, maar ook een laag waar een agent context, status en tools kan ophalen om datagedreven beslissingen te nemen.
Zo verbreedt de rol van databases zich naar dataplatforms die vaak de ruggengraat vormen van autonome AI-systemen.
Vroeger konden chatbots werken met enkel een prompt en een taalmodel. Moderne agents moeten kunnen herinneren, opzoeken, handelen en wijzigingen bijhouden.
En hoe autonomer de software, hoe belangrijker het wordt om te weten welke informatie wordt opgevraagd voordat een besluit wordt genomen.
MongoDB zet in op deze visie, waarbij de database zelf een natuurlijke rol krijgt in het semantisch ophalen en hergebruik van actuele gegevens binnen een alomvattend data-platform.
Veelgestelde vragen
Wat is Automated Embedding van MongoDB Atlas?
Een functie die automatisch embeddings genereert met Voyage AI-modellen tijdens het indexeren van documenten en bij zoekopdrachten. Het model wordt hergebruikt om vectors te hernieuwen bij datawijzigingen, waardoor een aparte pipeline overbodig wordt.
Wat is voyage-code-4?
Een Voyage AI-model dat gespecialiseerd is in codeherstel. Het helpt bij het vinden van relevante codefragmenten binnen grote repositories, gericht op ontwikkelaars en tools die met software repositories werken.
Moet ik MongoDB gebruiken om toegang te krijgen tot Voyage AI-modellen?
Nee. MongoDB biedt een losstaande Embedding en Reranking API die je kunt gebruiken zonder dat je data in MongoDB hoeft te bewaren. Het is een service die via Atlas toegankelijk is en losstaat van je database-infrastructuur.
Wat is reranking in een RAG-systeem?
Het is het opnieuw ordenen van een eerste set gevonden documenten met een nauwkeurigere model. Hierdoor worden relevantere resultaten naar voren gehaald en wordt de context voor het taalmodel geoptimaliseerd, met minder irrelevante gegevens en lagere tokenskosten.