MongoDB ha ampliado Atlas con nuevas capacidades destinadas a convertir la propia plataforma de datos en la capa de memoria, contexto y recuperación de información para aplicaciones y agentes de inteligencia artificial. La compañía incorpora embeddings automatizados con modelos de Voyage AI, una API independiente para embeddings y reranking, recuperación vectorial sobre datos en streaming y el nuevo modelo voyage-code-4, especializado en encontrar código relevante para agentes de programación.

Las claves de la nueva apuesta de MongoDB por el RAG en 20 segundos

• Atlas puede generar y actualizar automáticamente los embeddings cuando cambian los documentos.
• MongoDB ofrece los modelos de Voyage AI mediante una API utilizable incluso fuera de Atlas.
• voyage-code-4 está especializado en recuperación de código para agentes de programación.
• El reranking nativo permite reordenar resultados según su relevancia semántica.
• La compañía quiere evitar arquitecturas con base operacional, vector store y pipelines de embeddings separados.

El planteamiento ataca uno de los problemas menos vistosos pero más importantes de los sistemas de generación aumentada por recuperación, conocidos como RAG (Retrieval-Augmented Generation). El rendimiento de un agente no depende únicamente del modelo de lenguaje que utiliza. También importa qué información consigue recuperar antes de tomar una decisión.

Un LLM puede ser muy capaz y recibir un contexto mediocre.

Si una búsqueda vectorial devuelve el documento equivocado, una versión antigua o fragmentos poco relevantes, el modelo razonará sobre información incorrecta. Y cuando un agente tiene capacidad para ejecutar acciones, el problema deja de limitarse a obtener una mala respuesta.

MongoDB quiere acercar esa recuperación al lugar donde ya viven los datos operacionales.

Atlas genera los embeddings cuando cambian los datos

La pieza central es Automated Embedding.

Hasta ahora, una arquitectura RAG habitual podía implicar varios pasos. Una aplicación escribía información en su base de datos, un proceso independiente detectaba el cambio, extraía el texto, llamaba a un modelo de embeddings, almacenaba el vector en otro sistema y posteriormente mantenía ambas copias sincronizadas.

Funcionaba, pero añadía componentes y puntos de fallo.

MongoDB permite ahora configurar un modelo de Voyage AI sobre un índice de Vector Search. Atlas genera automáticamente el embedding del campo seleccionado cuando se indexa el documento y crea también el vector de la consulta en el momento de realizar una búsqueda.

Si el documento cambia, la plataforma vuelve a generar su representación vectorial.

Eso elimina la necesidad de mantener un proceso propio encargado de detectar modificaciones y actualizar un almacén vectorial externo.

La función llegó a Atlas como public preview en mayo y la documentación actual la presenta disponible para clústeres gratuitos M0, Flex y dedicados M10 o superiores. En los clústeres dedicados se exige activar el escalado automático de almacenamiento y del nivel de cómputo para poder absorber la construcción inicial de índices grandes.

El cambio resulta especialmente interesante para agentes que trabajan sobre información que cambia constantemente.

Una copia vectorial actualizada durante la noche puede ser suficiente para una colección documental relativamente estática. Lo es menos si el agente necesita consultar pedidos, incidencias, inventario, conversaciones o registros que acaban de modificarse.

MongoDB quiere evitar el problema del contexto desactualizado

La compañía está utilizando una idea sencilla para explicar su estrategia: un agente debería recuperar información directamente sobre el estado actual del negocio.

Ese objetivo es más complicado cuando existen varias capas independientes.

Una arquitectura puede tener MongoDB como base operacional, otro producto como vector store, un servicio externo para generar embeddings y un modelo adicional para hacer reranking. Cada componente puede funcionar correctamente y, aun así, existir retraso entre el dato original y la representación que termina consultando el agente.

MongoDB intenta eliminar parte de esa sincronización haciendo que operaciones y recuperación semántica compartan plataforma.

No significa que todas las arquitecturas RAG necesiten unificarse. Utilizar productos especializados continúa teniendo ventajas en determinados casos, especialmente cuando ya existe una infraestructura estable o se necesitan características concretas de otros motores.

La propuesta de MongoDB consiste en reducir componentes cuando esa especialización no compensa el coste operacional.

El caso del Financial Times sirve como referencia aportada por la compañía. El periódico utiliza Automated Embedding con modelos de Voyage AI para su búsqueda semántica y afirma procesar más de 100.000 búsquedas diarias, mientras experimenta con diferentes modelos para equilibrar precisión y coste.

MongoDB también cita a Eve, una plataforma de inteligencia artificial jurídica, entre los usuarios que están probando su API de embeddings y reranking para recuperar documentación relevante dentro de expedientes legales.

Son experiencias comunicadas por los propios clientes en el anuncio y no benchmarks independientes.

voyage-code-4: buscar código exige un modelo diferente

Una de las novedades más específicas es voyage-code-4, diseñado para recuperación de código.

El problema que intenta resolver es cada vez más habitual con agentes como Codex, Claude Code o herramientas que trabajan sobre grandes repositorios.

Antes de modificar una aplicación, el agente necesita encontrar los archivos, funciones, clases o implementaciones relacionadas con la tarea. Una búsqueda puramente textual puede no ser suficiente y un modelo de embeddings generalista tampoco tiene por qué representar correctamente las relaciones semánticas entre piezas de software.

MongoDB presenta voyage-code-4 como un modelo especializado precisamente en esa recuperación.

Esto tiene implicaciones más amplias que generar una respuesta sobre documentación.

Un agente de programación puede recibir una petición como corregir un fallo de autenticación y necesitar encontrar:

• el middleware que valida sesiones;
• el modelo de usuario;
• las pruebas relacionadas;
• una función de renovación de tokens;
• configuraciones que utilizan nombres diferentes para el mismo concepto.

La calidad de ese primer paso condiciona todo lo que ocurre después.

MongoDB asegura que sus modelos Voyage ocupan posiciones destacadas en el Retrieval Embedding Benchmark (RTEB). La compañía ya había presentado anteriormente la familia Voyage 4 indicando que superaba a otras alternativas en el conjunto público de pruebas. Esa afirmación corresponde a los resultados del benchmark y a la interpretación publicada por MongoDB, no implica que vaya a ser superior para todos los conjuntos de datos o aplicaciones reales.

Embeddings y reranking ya no dependen de utilizar MongoDB como base

Hay otro detalle importante en la estrategia.

La nueva Embedding and Reranking API permite consumir modelos de Voyage AI directamente desde Atlas aunque los datos o la aplicación estén alojados en otra plataforma.

Esto convierte a MongoDB también en proveedor de modelos de recuperación.

El desarrollador crea una clave para modelos desde Atlas y puede llamar a los servicios de Voyage AI mediante una API separada. MongoDB utiliza un modelo de precios basado en tokens y no obliga a que la aplicación almacene sus datos en MongoDB.

La decisión tiene sentido después de que MongoDB adquiriera Voyage AI en 2025.

El valor de la compra no se limita ahora a mejorar Vector Search dentro de Atlas. Los modelos pasan a poder utilizarse como un servicio independiente.

Además de los embeddings aparece el reranking.

Una búsqueda vectorial puede recuperar, por ejemplo, 50 candidatos razonablemente cercanos a una consulta. El reranker recibe posteriormente esos documentos y vuelve a ordenarlos utilizando un modelo más preciso.

La primera fase prioriza velocidad y cobertura.

La segunda intenta maximizar relevancia.

MongoDB añadió a finales de junio soporte nativo para esta operación mediante la fase de agregación $rerank en MongoDB Search y Vector Search.

Para RAG puede ser una diferencia importante: reducir el número de documentos irrelevantes enviados al LLM disminuye ruido y también puede recortar tokens consumidos.

El coste del agente también se decide antes de llamar al LLM

Esta relación entre recuperación y coste suele quedar en segundo plano.

Supóngase que un agente necesita contestar una pregunta a partir de documentación interna.

Una recuperación poco precisa puede obligar a enviar 20 documentos al modelo.

Una mejor búsqueda quizá permita quedarse con cinco.

El ahorro no procede de utilizar un LLM más barato, sino de darle menos contexto y de mayor calidad.

Lo mismo ocurre con agentes que ejecutan varias búsquedas durante una tarea. Si cada paso introduce contexto innecesario, el gasto se multiplica con cada llamada.

MongoDB lleva tiempo trabajando precisamente en esta relación entre calidad, dimensiones del embedding y coste. La familia Voyage 4 utiliza un espacio de embeddings compartido que permite, según la compañía, crear vectores de documentos con un modelo y consultar posteriormente ese mismo espacio con otro modelo más ligero.

También admite representaciones de diferentes dimensiones mediante técnicas de matryoshka learning, lo que permite reducir almacenamiento en determinados escenarios.

Son posibilidades técnicas que necesitan evaluarse en cada aplicación: reducir dimensiones o utilizar un modelo más pequeño puede disminuir costes, pero la prioridad sigue siendo conservar suficiente precisión para el caso de uso.

Vector Search llega también a los datos en movimiento

La cuarta pieza anunciada es la incorporación de recuperación vectorial a Atlas Stream Processing.

MongoDB Stream Processing ya permite recibir flujos desde fuentes como Kafka o cambios en bases de datos, transformarlos continuamente y escribir sus resultados en colecciones, otros tópicos o destinos externos.

Añadir búsqueda vectorial a este proceso busca que los agentes puedan relacionar acontecimientos en movimiento con información semánticamente similar.

Esto abre casos distintos del RAG documental tradicional.

Un flujo de eventos podría comparar una nueva incidencia con incidentes anteriores, relacionar telemetría con situaciones conocidas o enriquecer mensajes en tiempo real antes de entregarlos a otro sistema.

La idea de MongoDB es que los datos en streaming no tengan que convertirse primero en una colección estática para poder participar en una recuperación semántica.

Aquí el interés para operaciones puede ser considerable. Los agentes orientados a observabilidad, soporte o detección de incidencias necesitan contexto mientras el evento todavía está ocurriendo, no horas después.

MongoDB se está colocando en medio de la arquitectura de agentes

Todas estas novedades forman parte de una estrategia más amplia que la búsqueda vectorial.

En el Build Fest celebrado el 13 de agosto en San Francisco, MongoDB presentó su plataforma alrededor de cuatro conceptos: memoria, estado, contexto y recuperación para agentes.

La compañía también anunció integraciones con Claude, Claude Code, ChatGPT, Codex, Grok Build y Devin, además de un servidor MCP gestionado para Atlas.

El objetivo comercial es claro: que MongoDB no sea únicamente el lugar donde una aplicación guarda documentos, sino una capa desde la que un agente pueda consultar estado vivo, buscar contexto semántico y acceder a herramientas.

Esto coloca a las bases de datos en una posición distinta dentro del auge de la IA agéntica.

Los primeros chatbots podían trabajar principalmente con un prompt y un modelo. Los agentes de producción necesitan recordar, consultar, actuar y comprobar qué ha cambiado desde la última ejecución.

Y cuanto más autónomo es el software, más importante se vuelve una cuestión aparentemente menos llamativa que el modelo utilizado: qué información recuperó antes de tomar la decisión.

MongoDB está apostando a que esa capa terminará formando parte natural de la propia plataforma de datos.

Preguntas frecuentes

¿Qué es Automated Embedding de MongoDB Atlas?

Es una función que genera automáticamente embeddings con modelos de Voyage AI cuando se indexan documentos y cuando se realizan consultas. También vuelve a generar los vectores cuando cambian los datos, evitando mantener un pipeline separado.

¿Qué es voyage-code-4?

Es un modelo de embeddings de Voyage AI especializado en recuperación de código. Está dirigido especialmente a agentes y aplicaciones que necesitan encontrar fragmentos relevantes dentro de repositorios de software.

¿Es necesario utilizar MongoDB para acceder a los modelos de Voyage AI?

No. MongoDB ofrece una Embedding and Reranking API independiente a través de Atlas que puede utilizarse desde aplicaciones construidas con otros sistemas de almacenamiento.

¿Para qué sirve el reranking en un sistema RAG?

Permite volver a ordenar un conjunto inicial de documentos recuperados utilizando un modelo más preciso. El objetivo es enviar al LLM menos información irrelevante y mejorar la calidad del contexto final.