Creación de un proceso RAG a partir de datos web en tiempo real (sin índices obsoletos)

Un proceso RAG en tiempo real recupera la información de la web abierta en el momento de la consulta, en lugar de leerla de un índice vectorial rastreado previamente. Esto garantiza que las respuestas estén actualizadas, ya que los datos se obtienen cuando el usuario realiza la consulta, y no semanas antes, cuando se llevó a cabo el rastreo. La disyuntiva es clara: la obtención en tiempo real añade latencia y un coste por consulta, mientras que un índice almacenado en caché es rápido, pero la información puede quedar obsoleta. La mayoría de los sistemas de producción que observamos se sitúan en un término medio híbrido, obteniendo los datos en tiempo real para consultas urgentes y reutilizando fragmentos almacenados en caché dentro de un plazo de validez (TTL) que garantiza la actualidad de la información.

Puntos clave

• El sistema RAG clásico ofrece respuestas a partir de un índice estático, por lo que su límite máximo de actualidad es la fecha de su último rastreo.
• Live-web RAG identifica fuentes mediante la Web Search API, recupera y depura las páginas en el momento de la consulta y, a continuación, respalda la respuesta con citas.
• Lo difícil no es la recuperación. Lo difícil es decidir cuándo recuperar datos en tiempo real y cuándo reutilizar un fragmento almacenado en caché, lo cual viene determinado por un tiempo de vida (TTL) de actualización específico para cada tema.
• En 2025, Gartner pronosticó que el 40 % de las aplicaciones empresariales contarían con agentes de IA específicos para cada tarea a finales de 2026, frente a menos del 5 % actual, y que dichos agentes necesitarían datos actualizados.
• El Markdown limpio es más eficaz que el HTML sin formato en la fase de ingesta, ya que reduce el coste de tokenización y elimina los elementos de navegación, los anuncios y el código repetitivo antes de dividir el contenido en fragmentos.

El RAG clásico tenía sentido cuando su corpus era una base de conocimientos de evolución lenta: documentos, políticas, tickets. Sin embargo, si se aplica a la web abierta, el modelo deja de funcionar. Los precios cambian, surgen noticias de última hora, las clasificaciones varían y un índice vectorial creado el martes pasado devuelve con total seguridad la realidad de ese mismo martes. La solución no consiste en un índice más grande ni en una programación de reindexación más rápida. En cambio, consiste en trasladar la obtención de datos al momento de la consulta para aquellos datos que realmente varían. RAG Se trata de la «generación aumentada por recuperación» (RAG): un modelo genera respuestas a partir de los documentos que usted recupera y le proporciona, y no únicamente a partir de sus pesos de entrenamiento. En esta entrada se analiza la arquitectura paso a paso y, a continuación, se aborda la lógica de actualización que distingue la versión RAG basada en la web en tiempo real de la versión clásica. Para conocer el contexto más amplio sobre cómo proporcionar datos actuales a los agentes, comience por el artículo sobre Cómo proporcionar a los agentes de IA acceso en tiempo real a la web.

¿Por qué el método RAG clásico pierde eficacia con los datos web?

El RAG clásico se queda obsoleto porque responde a partir de una instantánea. Se realiza el rastreo, se segmenta, se integra y se almacena; a continuación, cada consulta consulta esa copia congelada hasta el siguiente rastreo. Para un corpus estable, esto es suficiente. Sin embargo, en el caso de la web abierta, supone un inconveniente, y la demanda de agentes de datos actualizados va en aumento. En 2025, Gartner pronosticó que El 40 % de las aplicaciones empresariales contarán con agentes de IA específicos para cada tarea a finales de 2026, frente a menos del 5 % en 2025. Los agentes que responden a preguntas reales no pueden basarse en una instantánea desactualizada.

El problema de la obsolescencia tiene dos vertientes. En primer lugar, la cobertura: la web que indexó el mes pasado carece de páginas que aún no existían, por lo que ningún método de recuperación, por muy ingenioso que sea, puede recuperarlas. En segundo lugar, la deriva: las páginas que sí indexó han cambiado sin que usted se diera cuenta, y sus representaciones siguen apuntando al texto antiguo. Volver a rastrear con una periodicidad más ajustada reduce el margen de error, pero nunca lo elimina por completo; y, mientras tanto, consume recursos informáticos en páginas que nadie va a consultar.

RAG en tiempo real invierte el orden. En lugar de recuperar todo por adelantado y esperar que la página correcta se encuentre en el índice, se descubren y se recuperan las fuentes en el momento de la consulta. Como resultado, el coste pasa de «rastrear toda la web de forma continua» a «recuperar el puñado de páginas que necesita esta consulta». Para conocer los antecedentes sobre por qué es importante la «grounding» y cómo reduce las alucinaciones, consulte nuestra guía sobre Entrenamiento de modelos de lenguaje a gran escala (LLM) con datos web en tiempo real.

¿Cómo es una arquitectura RAG en tiempo real en la web?

Un proceso RAG en tiempo real en la web consta de siete etapas: comprensión de la consulta, descubrimiento de fuentes en tiempo real, obtención y limpieza, segmentación e incrustación, recuperación de los k resultados principales, fundamentación de la generación con citas y, por último, almacenamiento en caché con un TTL de frescura. Las seis primeras etapas generan la respuesta. La séptima etapa determina qué información se conserva, de modo que la siguiente consulta similar pueda omitir la obtención en tiempo real. Cada etapa es concreta y, en la práctica, la mayoría de los fallos se deben a un fallo en la detección de fuentes o en la obtención de datos.

A continuación se presenta el proceso en forma de lista de pasos:

1. Comprensión de la consulta -> reformular la pregunta del usuario en función de la intención de búsqueda
2. Descubrimiento de fuentes -> la API de búsqueda devuelve URL candidatas
3. Obtención + limpieza -> procesar cada URL para obtener un formato Markdown limpio
4. División en fragmentos + incrustación -> dividir el Markdown e incrustar los fragmentos en el momento de la consulta
5. Recuperación de los k mejores -> Clasificación de los fragmentos en función de la representación de la consulta
6. Fundamentación + Cita -> El modelo de lenguaje grande (LLM) responde utilizando únicamente los fragmentos recuperados, con enlaces a las fuentes
7. Almacenamiento en caché + TTL -> Almacenamiento de los fragmentos con un plazo de vigencia para su reutilización

Las etapas que se indican a continuación describen cada paso. Ninguna de ellas requiere un índice gigante creado previamente. El «almacén de vectores» al que se hace referencia aquí es pequeño y de corta duración, y a menudo se limita al ámbito de una sola consulta o sesión.

Fase 1: comprensión de la consulta

Convierta la pregunta tal cual del usuario en una intención de búsqueda antes de consultar la web. Elimine los elementos de relleno del lenguaje coloquial, desglose las abreviaturas y extraiga las entidades y la relevancia temporal. Por ejemplo, «¿Cuáles son las últimas noticias sobre la adquisición de X?» implica actualidad; una pregunta definitoria, en cambio, no. Esta etapa determina en qué medida el resto del proceso dará prioridad a los datos recientes frente a los almacenados en caché. Es un proceso económico de ejecutar y ofrece una gran mejora en la calidad.

Fase 2: detección de fuentes en tiempo real

La fase de descubrimiento es donde la mayoría de los procesos fallan de forma imperceptible, ya que el modelo no puede basarse en páginas que nunca ha encontrado. Descubrimiento de fuentes Es el paso que convierte la intención de la consulta en un conjunto de URL candidatas, normalmente a través de una API de búsqueda en lugar de adivinar dominios. En este sentido, resulta fundamental contar con un punto final de SERP con segmentación geográfica: los resultados para «lo mejor de X cerca de mí» o una consulta de precios varían según el país y la ciudad, y lo que se busca son las fuentes que el usuario vería realmente. Para consultar una comparación de las opciones, véase Web Search API para agentes.

Esta es la primera etapa en la que interviene Web Render API de Massive. El punto final de búsqueda (/search) recopila resultados de las páginas de resultados de búsqueda (SERP) de los principales motores de búsqueda y permite la segmentación geográfica por país, subdivisión o ciudad. En el caso de las consultas que se basan en lo que indica un resumen generado por IA, awaiting=ai espera hasta un minuto para obtener una visión general de la IA, y awaiting=answers Recurre a «People-Also-Ask». Se obtiene el conjunto de URL candidatas, ordenadas tal y como las vería un usuario real en esa ubicación.

Fase 3: recogida y limpieza

La recuperación de las páginas candidatas es el punto en el que el RAG en tiempo real se enfrenta a las defensas de la web moderna, y la web moderna es hostil hacia los bots. En 2025, Imperva informó de que Los bots automatizados representaron el 51 % de todo el tráfico web en 2024, la primera vez en una década que los bots superaban a los humanos, con un porcentaje de bots maliciosos del 37 %. Los sitios web responden bloqueándolos de forma agresiva, por lo que las solicitudes ingenuas procedentes de centros de datos se ven cuestionadas o se les muestra contenido engañoso.

En esta fase hay dos requisitos. En primer lugar, su solicitud debe superar la capa de protección contra bots de la página; de lo contrario, se encontrará con una página de error. Proxies residenciales Enrutar las solicitudes a través de dispositivos reales de consumidores, de modo que el tráfico proceda de direcciones IP residenciales en lugar de un rango de un centro de datos marcado como sospechoso. La herramienta Web Render API de Massive realiza consultas a través de una red real de dispositivos de consumidores que abarca más de 195 países, con aproximadamente 1,3 millones de dispositivos activos diarios. En nuestras pruebas, la tasa de éxito de las direcciones IP residenciales en sitios web protegidos suele ser mucho mayor que la de los centros de datos (rangos aproximados: residenciales ~85-99 % frente a centros de datos ~20-40 %); considere estos datos como un punto de referencia del proveedor, no como una investigación independiente.

En segundo lugar, lo que necesita es texto limpio, no código HTML sin procesar. El punto final de navegación (/browser) es compatible con format=markdown como resultado de primera clase, devolviendo código Markdown listo para modelos de lenguaje grande (LLM), sin elementos de navegación, anuncios ni texto repetitivo. Esto es importante antes de dividir el texto en fragmentos: el código Markdown reduce considerablemente el número de tokens en comparación con el HTML sin procesar, lo que disminuye el coste de la incrustación y la generación, y garantiza que sus fragmentos sigan siendo significativos en lugar de estar llenos de enlaces de menú. Los profesionales del sector han documentado el mismo efecto (dev.to, Herramientas de navegador para agentes de IA, 4.ª parte: Prescindir del navegador, 2026).

Etapa 4: agrupación y asimilación

Divida el código Markdown limpio en fragmentos e incorpórelos en el momento de la consulta. Dado que el corpus se limita a las pocas páginas que ha extraído esta consulta, el proceso resulta rápido y económico; está incorporando kilobytes, no un rastreo de toda la web. Mantenga los fragmentos alineados con la estructura de Markdown, por encabezados y párrafos, de modo que cada fragmento sea autónomo. Los encabezados de Markdown le proporcionan límites naturales que el HTML sin formato no ofrece.

Etapa 5: recuperar los k primeros

Clasifique los fragmentos recién incrustados en función de la incrustación de la consulta y conserve los k mejores. Con un corpus reducido por consulta, la recuperación resulta sencilla y puede permitirse un valor k más alto; a continuación, deje que el modelo de generación se encargue del filtrado. La clave aquí es conservar únicamente los fragmentos que superen un umbral de relevancia, de modo que una fuente de baja calidad no diluya la ventana de contexto.

Etapa 6: fundamentar la argumentación con referencias bibliográficas

Facilítele al modelo únicamente los fragmentos recuperados e indíquele que responda basándose en ellos, incluyendo un enlace a la fuente para cada afirmación. Puesta a tierra Consiste en limitar la respuesta de un modelo a la evidencia recuperada, en lugar de a su memoria paramétrica; por lo tanto, este es el principio de fundamentación: sin fragmento, no hay afirmación. Dado que cada fragmento incluye su URL de origen de la Etapa 2, las citas se proporcionan de forma automática, y un lector (o una verificación posterior) puede contrastar la respuesta con la página en tiempo real. La fundamentación en texto obtenido en este mismo instante es la razón fundamental de la publicación en tiempo real.

Etapa 7: caché con un tiempo de vida (TTL) de vigencia

Almacene los fragmentos que haya recuperado con un plazo de validez, de modo que la siguiente consulta similar pueda reutilizarlos en lugar de volver a recuperarlos. Esto es lo que hace que el RAG en tiempo real resulte asequible a gran escala. La caché convierte la segunda consulta idéntica, que de otro modo requeriría una recuperación completa en tiempo real, en una simple consulta de búsqueda, y el TTL es lo que garantiza la fiabilidad de dicha búsqueda. En la siguiente sección se explica cómo configurarlo.

¿Cómo se evitan los índices obsoletos mediante los TTL de vigencia?

Para evitar que los índices queden obsoletos, se debe asignar un tiempo de vida (TTL) a cada fragmento almacenado en caché y volver a recuperar los datos en tiempo real una vez que haya caducado. A TTL de frescura Es un tiempo de vida (TTL) por fragmento que indica durante cuánto tiempo una recuperación almacenada en caché sigue siendo fiable antes de que deba actualizarse. El TTL es específico para cada tema, no global: el precio de una acción puede ser válido durante segundos, las especificaciones de un producto durante días y una definición de la enciclopedia durante semanas. Cuando llega una consulta, se comprueba primero la caché, se sirven los fragmentos que aún se encuentran dentro de su TTL y se activa una recuperación en tiempo real para cualquier dato caducado o que falte. Ese es el término medio híbrido: rápido cuando se puede, actualizado cuando es necesario.

Configure el TTL desde la fase de análisis de la consulta. Si en la Fase 1 se ha marcado la pregunta como sensible a la actualidad, acorte o omita el TTL y fuerce una recuperación en tiempo real. Por el contrario, si se trata de una pregunta definicional estable, un TTL prolongado es adecuado y puede servirla desde la caché. Esta es la palanca que controla su latencia y su coste: un mayor número de recuperaciones en tiempo real implica respuestas más actualizadas y un mayor coste por consulta, mientras que un mayor número de aciertos en la caché implica lo contrario.

La invalidación es tan importante como la caducidad. Un TTL gestiona la obsolescencia basada en el tiempo, pero algunos eventos exigen una invalidación inmediata: una página a la que ha enlazado devuelve un error 404, una fuente en la que confía publica una corrección o una entidad conocida por su volatilidad (un marcador en directo, una noticia de última hora) aparece en la consulta. Cree una ruta de invalidación explícita para esos casos, en lugar de esperar a que se agote el tiempo. En resumen, la combinación de un TTL por tema y una invalidación basada en eventos es lo que distingue a un proceso de web en tiempo real de un índice clásico que simplemente vuelve a rastrear mediante una tarea cron.

Otra razón más por la que el contenido en tiempo real tiende a superar a un índice estático en 2025: la web abierta está restringiendo cada vez más el acceso a los rastreadores masivos. Cloudflare informó de que el El 1 de julio de 2025 comenzó a bloquear de forma predeterminada los rastreadores de IA en aproximadamente el 20 % de la web y ha puesto en marcha un mercado de pago por rastreo. Como consecuencia, el mantenimiento de un índice preelaborado de la web abierta resulta cada trimestre más difícil y costoso. La recuperación en el momento de la consulta a través de una red de dispositivos reales evita el problema del rastreo masivo, ya que se recuperan unas pocas páginas a las que un usuario real podría acceder, en lugar de toda la web según un calendario preestablecido. Si desea poner este proceso a disposición de los agentes como una herramienta a la que se puede recurrir, consulte cómo crear un MCP Server para la extracción de datos web.

¿Cuándo conviene recuperar un fragmento en tiempo real y cuándo reutilizar uno almacenado en caché?

Recupere los datos en tiempo real cuando la consulta sea sensible a la actualidad o cuando la entrada de caché correspondiente haya superado su TTL; reutilice un fragmento almacenado en caché cuando aún esté actualizado y la consulta sea estable. La decisión se toma para cada consulta, basándose en la señal de sensibilidad temporal de la Etapa 1 y en el TTL restante del fragmento. Acertar con esta regla es donde se invierte el presupuesto de latencia y coste, por lo que debe ajustarse en función del tráfico real, no de conjeturas.

Una configuración predeterminada práctica: considere la caché como la vía rápida y la recuperación en tiempo real como el respaldo de exactitud. Sirva desde la caché cuando disponga de un fragmento dentro del TTL que supere su umbral de relevancia. Sin embargo, recurra a una recuperación en tiempo real cuando la caché falle, el fragmento haya caducado, la consulta tenga como objetivo la actualidad o la fuente almacenada en caché haya sido invalidada. De este modo, las consultas comunes y repetidas resultan económicas, al tiempo que se garantiza que las volátiles estén actualizadas.

Ajuste los umbrales prestando atención a dos tipos de fallos. Las respuestas obsoletas (un TTL de caché demasiado largo para ese tema) le llevarán a optar por TTL más cortos y a realizar más recuperaciones en tiempo real. Los picos de coste y latencia (demasiadas recuperaciones en tiempo real en consultas estables) le empujan en la dirección contraria. Según lo que observamos en las cargas de trabajo de los agentes, no existe una configuración única correcta; el equilibrio adecuado depende de su combinación de tráfico y de la rapidez con la que cambian realmente sus fuentes.

Fuentes

• Gartner, Gartner prevé que, para 2026, el 40 % de las aplicaciones empresariales contarán con agentes de IA específicos para cada tarea, frente a menos del 5 % en 2025., 2025. https://www.gartner.com/en/newsroom/press-releases/26 de agosto de 2025: Gartner prevé que el 40 % de las aplicaciones empresariales contarán con agentes de IA específicos para cada tarea en 2026, frente a menos del 5 % en 2025
• Imperva, Informe sobre bots maliciosos de 2025, 2025. https://www.imperva.com/resources/resource-library/reports/2025-bad-bot-report/
• Cloudflare, Cloudflare acaba de cambiar la forma en que los rastreadores de IA recopilan información de Internet en general, 2025. https://www.cloudflare.com/press/press-releases/2025/cloudflare-just-changed-how-ai-crawlers-scrape-the-internet-at-large/
• dev.to, Herramientas de navegador para agentes de IA, 4.ª parte: Prescindir del navegador, 2026. https://dev.to/stevengonsalvez/browser-tools-for-ai-agents-part-4-skip-the-browser-save-80-on-tokens-304c