← Todos los artículos
Caso de uso 6 min de lectura

El problema del recrawl: cómo mantener frescos los pipelines RAG

Tu base de conocimientos RAG queda obsoleta la misma semana que la lanzas. Así es como los equipos hacen recrawl de cientos de fuentes verticales sin agotar su presupuesto de ingeniería.

ragai-trainingdata-collectionvertical-aiuse-case

El desafío

Las startups de IA vertical chocan contra la misma pared alrededor del segundo mes. Lanzan un copilot de soporte, un asistente de investigación legal o un bot de cumplimiento normativo. La primera demo gana clientes. Luego, los datos quedan obsoletos y las respuestas comienzan a alejarse de la realidad.

Hemos visto a equipos construir la parte de IA de forma impecable y la parte de datos como una ocurrencia tardía. El pipeline de ingesta es un único script de Python que se ejecuta en la laptop de alguien. Hace scraping de 200 URL de origen una vez, vuelca Markdown limpio en un vector store y todos celebran. Seis semanas después, la mitad de las respuestas citan páginas eliminadas, API obsoletas o características de producto que se lanzaron en marzo y se volvieron a lanzar en mayo.

La solución parece simple: hacer recrawl de cada fuente semanalmente. La realidad es más fea. Para 2026, alrededor del 60% de los sitios de confianza bloquean los crawlers de IA (frente al 23% a finales de 2023), y las protecciones ya no son simples comprobaciones de User-Agent. Analizan el comportamiento de la sesión, el ritmo de las request y las señales a nivel de handshake. Un script ingenuo que funcionaba en enero devuelve silenciosamente páginas vacías en marzo.

Peor aún, algunos sitios ahora sirven contenido tipo tarpit (texto sin sentido generado por cadenas de Markov que parece prosa real) hasta que envenena tus embeddings. Así, tus ingenieros pasan la mitad de la semana parcheando el scraper en lugar de lanzar producto. La calidad de la recuperación disminuye, los clientes lo notan y el equipo que contrataste para construir IA se convierte en un taller de mantenimiento de scrapers.

El enfoque

El problema del recrawl se divide en tres decisiones concretas que deben tomarse en cada request:

  1. ¿Renderizar o no? La mayoría de los portales de documentación sirven HTML limpio. Una parte creciente (cualquier cosa construida sobre Next.js, cualquier cosa con renderizado del lado del cliente) necesita un renderizado de navegador completo para devolver contenido útil.
  2. ¿Qué proxy? Residencial, datacenter, móvil, geolocalizado, específico de ISP. La elección correcta cambia según el objetivo.
  3. ¿Realmente funcionó? Un 200 con un cuerpo vacío, o una página HTML de CAPTCHA, es una request HTTP exitosa pero un crawl fallido.

Una plataforma como FourA maneja cada uno de estos aspectos como una prioridad de primer nivel.

Para la decisión de renderizado, llamas a Single para el caso rápido y económico, y a Browser para objetivos con mucho JS. El cuerpo de la llamada tiene la misma estructura, por lo que tu código de ingesta se bifurca una sola vez mediante un flag por fuente, en lugar de arrastrar un centenar de particularidades específicas de cada sitio.

Para la selección de proxy, Proxy Finder se ejecuta como parte de cada llamada a Single, Browser y Auto. La plataforma elige una salida funcional por request, devuelve su ID opaco en el meta.proxy de la response, y tú reutilizas ese ID en las llamadas de seguimiento cuando necesitas mantenerte en la misma salida. Tu crawler no necesita un algoritmo propio de clasificación de proxies. (Escribimos sobre por qué el tamaño del pool ha dejado de ser el factor diferenciador en Por qué el tamaño del pool de proxies dejó de importar en 2026.)

Y para la pregunta de «¿realmente funcionó?», cada request admite un bloque validate. Declaras lo que cuenta como éxito: códigos de estado aceptados, valores de header requeridos, cadenas en el cuerpo que deben o no aparecer. FourA devuelve uno de siete resultados, y solo success es facturable. Un 200 que no cumple con tus reglas de contenido se marca como application_fail y nunca ingresa a tu conjunto de datos.

Así es como se ve una llamada de recrawl para un portal de documentación que necesita renderizado de JS. Dejamos que Auto lo orqueste, ya que elige el producto adecuado (Single, Proxy o Browser), maneja las defensas contra bots y devuelve la terna de sesión para que el próximo recrawl pueda mantenerse en la misma salida:

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "url": "https://docs.example.com/changelog",
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ["<article"], "fail": ["captcha", "Just a moment"]},
        },
    },
).json()

# r["data"]    — rendered body
# r["meta"]    — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["meta"]["proxy"] back as `ignoreProxies: [<id>]` to avoid
# the same exit, or via /api/single with `proxy: <id>` to stick to it.

Si el objetivo lanza un intersticial de Cloudflare, la regla validate.data.fail lo detecta. El resultado registrado en tu uso es application_fail. No pagas por ello, y tu código de ingesta sabe que debe reintentar con un proxy diferente en lugar de alimentar los embeddings con una página de «Just a moment...».

Para el corpus más amplio, envuelves este mismo patrón en tu cola de tareas existente. Los equipos con los que hemos hablado ejecutan diffs nocturnos contra el crawl anterior, vuelven a generar embeddings solo para los documentos que realmente cambiaron y actualizan un corpus de 500 fuentes en un par de horas de tiempo real. La cola de tareas sigue siendo tuya. La rotación de proxies, la decisión de renderizado y el veredicto de éxito son nuestros.

Resultados

Cómo se ve el bucle de actualización una vez que la infraestructura deja de ser el cuello de botella (escenario ilustrativo basado en los patrones que vemos en los equipos de IA vertical):

  • 500 URL de origen con recrawl semanal, en lugar de un único intento de 200 URL en el lanzamiento
  • Tiempo de ingeniería dedicado al scraper: menos de 2 horas por semana, en comparación con los 1 o 2 días anteriores
  • Ventana de obsolescencia de recuperación: de 5 a 7 días, en lugar de ser ilimitada
  • Tasa de basura en el vector store cercana a cero, porque los intersticiales de Cloudflare y las páginas tarpit se rechazan en la capa de validate antes de llegar a tu modelo de embeddings
  • Costo predecible por fuente, porque los crawls fallidos no aparecen en la facturación

El punto no es que nada de esto sea mágico. El punto es que es aburrido. Y lo aburrido es lo que necesita la IA en producción. (Para saber más sobre dónde deja de funcionar la matemática con la extracción mediante LLM alojados, consulta Cuándo la extracción con LLM deja de ser rentable a escala.)

Conclusión clave

La mayoría de los equipos que construyen IA vertical piensan que la ventaja competitiva es el prompt, la elección del modelo o el algoritmo de recuperación. No lo es. La ventaja competitiva es el bucle de actualización: la infraestructura poco glamorosa que mantiene la base de conocimientos fiel semana tras semana.

Los equipos que ganen en la IA vertical de aquí a 2026 no serán los que tengan los prompts más ingeniosos. Serán aquellos cuyos usuarios nunca noten que los datos están actualizados, porque siempre lo están.