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

Un canal 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 contrapartida es directa: 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 se queda obsoleto. La mayoría de los sistemas de producción que vemos se sitúan en un término medio híbrido, obteniendo datos en tiempo real para consultas urgentes y reutilizando fragmentos almacenados en caché bajo un TTL de vigencia.

Puntos clave

• El sistema RAG clásico ofrece respuestas a partir de un índice estático, por lo que la fecha límite de actualización es la de su último rastreo.
• Live-web RAG identifica fuentes mediante una API de búsqueda, 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 de datos. Lo difícil es decidir cuándo recuperar datos en tiempo real y cuándo reutilizar un fragmento almacenado en caché, lo cual se rige 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 la segmentación.

El RAG clásico tenía sentido cuando el corpus consistía en 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 del martes pasado. La solución no consiste en un índice más grande ni en un programa de reindexación más rápido. En cambio, consiste en trasladar la obtención de datos al momento de la consulta para aquellos datos que realmente cambian. RAG es la generación aumentada por la recuperación: un modelo genera respuestas a partir de los documentos que usted recupera y le proporciona, y no solo a partir de sus pesos de entrenamiento. En esta entrada se describe la arquitectura paso a paso y, a continuación, se aborda la lógica de actualización que distingue al RAG de 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 modelo RAG clásico deja de ser eficaz con los datos web?

El RAG clásico se queda obsoleto porque responde a partir de una instantánea. Se rastrea, se fragmenta, se integra y se almacena; después, cada consulta consulta esa copia congelada hasta el siguiente rastreo. Para un corpus estable, eso está bien. Sin embargo, para la web abierta, supone un inconveniente, y la demanda de agentes de datos actualizados va en aumento. En 2025, Gartner pronosticó que Para finales de 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. Los agentes que responden a preguntas reales no pueden basarse en una imagen obsoleta.

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 incrustaciones siguen apuntando al texto antiguo. Volver a rastrear con una periodicidad más ajustada reduce la ventana, pero nunca la cierra, y mientras tanto consume recursos de computación en páginas que nadie va a consultar.

El RAG en tiempo real invierte el orden. En lugar de precargar todo 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 contextualización y cómo reduce las alucinaciones, consulte nuestra guía sobre Entrenamiento de modelos de lenguaje grandes (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, detección de fuentes en tiempo real, obtención y limpieza, fragmentación e incrustación, recuperación de los k resultados principales, validación de la generación mediante citas y, por último, almacenamiento en caché con un tiempo de vida (TTL) basado en la actualidad. Las seis primeras etapas generan la respuesta. La séptima decide qué se conserva, de modo que la siguiente consulta similar pueda saltarse la obtención en tiempo real. Cada etapa es concreta y, en la práctica, la mayoría de los fallos se remontan a un paso deficiente de descubrimiento de fuentes o de obtención.

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. Búsqueda de fuentes -> la API de búsqueda devuelve URL candidatas
3. Obtención + limpieza -> procesar cada URL para obtener un formato Markdown limpio
4. Segmentación + incrustación -> dividir el Markdown e incrustar los fragmentos en el momento de la consulta
5. Recuperación de los k mejores -> Clasificar los fragmentos en función de la incrustació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 -> Almacenar los fragmentos con un plazo de vigencia para su reutilización

Las etapas que se describen a continuación detallan cada paso. Ninguna de ellas requiere un índice precompilado de gran tamaño. El «almacén vectorial» al que se hace referencia aquí es pequeño y de corta duración, y suele limitarse a una sola consulta o sesión.

Fase 1: comprensión de la consulta

Convierta la pregunta original del usuario en una intención de búsqueda antes de consultar la web. Elimine los rellenos conversacionales, desglose las abreviaturas y extraiga las entidades y la urgencia temporal. Por ejemplo, «¿Cuáles son las últimas noticias sobre la adquisición de X?» implica actualidad; una pregunta definitoria no lo hace. Esta etapa determina en qué medida el resto del proceso da prioridad a los datos recientes frente a los fragmentos almacenados en caché. Es económico de ejecutar y ofrece una gran recompensa en términos de calidad.

Fase 2: detección de fuentes en tiempo real

Es en la fase de descubrimiento donde la mayoría de los procesos fallan de forma silenciosa, ya que el modelo no puede basarse en páginas que nunca ha encontrado. Identificación 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 caso, es importante contar con un punto final de SERP con geolocalización: 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 una comparación de las opciones, consulte API de búsqueda web para agentes.

Esta es la primera fase en la que entra en acción la API Web Render de Massive. El punto final de búsqueda (/buscar) 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, provincia o ciudad. Para las consultas que se basan en lo que indica un resumen generado por IA, en espera=ai espera hasta un minuto para obtener una visión general de la IA, y a la espera de respuestas Recurre a «People-Also-Ask». De este modo, 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 37 % de bots maliciosos. Los sitios web responden bloqueándolos de forma agresiva, por lo que las solicitudes ingenuas procedentes de centros de datos se ven cuestionadas o reciben contenido engañoso.

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

En segundo lugar, lo que necesita es texto sin formato, no código HTML sin procesar. El punto final de navegación (/navegador) 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 contenido en fragmentos: el formato 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 los fragmentos sigan siendo significativos en lugar de estar repletos de enlaces de menú. Los profesionales del sector han documentado el mismo efecto (dev.to, Herramientas de navegador para agentes de IA. Parte 4: Prescindir del navegador(2026).

Etapa 4: fragmentar e integrar

Divida el código Markdown depurado 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 es rápido y económico; se están incorporando kilobytes, no un rastreo de toda la web. Mantenga los fragmentos alineados con la estructura del Markdown, por encabezados y párrafos, de modo que cada fragmento sea autónomo. Los encabezados del 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 se puede optar por 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 citas

Proporcione 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 Se trata de la práctica de 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: si no hay fragmento, no hay afirmación. Dado que cada fragmento incluye su URL de origen desde la Fase 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 el texto recuperado en este mismo instante es la razón de ser de la publicación en tiempo real.

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

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 sea viable a gran escala. La caché convierte la segunda consulta idéntica de 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 recuperarlo en tiempo real una vez que haya caducado. A Vigencia Es un tiempo de vida (TTL) por fragmento que indica cuánto tiempo se puede confiar en una recuperación almacenada en caché 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, primero se comprueba 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 consulta como sensible a la actualidad, acorte o omita el TTL y fuerce una recuperación en tiempo real. Si, por el contrario, se trata de una pregunta definicional estable, un TTL largo 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 de confianza 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 del TTL por tema y la invalidación basada en eventos es lo que distingue a un canal de web en tiempo real de un índice clásico que simplemente vuelve a rastrear mediante una tarea programada.

Otra razón por la que el contenido en tiempo real tiende a superar a un índice estático en 2025: la web abierta está cerrando progresivamente 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 lanzó un mercado de pago por rastreo. Como consecuencia, el mantenimiento de un índice predefinido de la web abierta resulta cada trimestre más difícil y costoso. La recuperación en tiempo de consulta a través de una red de dispositivos reales elude 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. Si desea exponer este proceso a los agentes como una herramienta invocable, consulte cómo crear un servidor MCP 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 este siga estando 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 invierte su presupuesto de latencia y coste, por lo que debe ajustarla en función del tráfico real, no de una suposición.

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 precisión. 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 una intención de actualidad o la fuente almacenada en caché haya sido invalidada. Esto mantiene las consultas comunes y repetidas a un coste reducido, al tiempo que garantiza que las volátiles estén actualizadas.

Ajuste los umbrales prestando atención a dos tipos de fallos. Las respuestas obsoletas (un tiempo de vida de la caché (TTL) demasiado largo para ese tema) le llevarán a establecer 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. Por 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 especializados en tareas específicas, 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. Parte 4: Prescindir del navegador, 2026. https://dev.to/stevengonsalvez/browser-tools-for-ai-agents-part-4-skip-the-browser-save-80-on-tokens-304c