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

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

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

ragai-trainingdata-collectionvertical-aiuse-case

El desafío

Todas las startups de IA vertical chocan contra el mismo muro hacia el segundo mes. Lanzan un copilot de soporte, un asistente de investigación legal o un bot de compliance. La primera demo gana clientes. Luego los datos envejecen y las respuestas empiezan a alejarse de la realidad.

Hemos visto equipos construir la parte de IA de forma limpia y dejar la parte de datos como algo secundario. El pipeline de ingestión es un script de Python ejecutándose en el portátil de alguien. Hace scraping de 200 URLs de origen una vez, vuelca Markdown limpio en un vector store y todos lo celebran. Seis semanas después, la mitad de las respuestas citan páginas eliminadas, APIs deprecadas o características de producto que se lanzaron en marzo y de nuevo en mayo.

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

Peor aún, algunos sitios ahora sirven contenido trampa (texto sin sentido generado por cadenas de Markov que parece prosa real) hasta que envenenan tus embeddings. Así que tus ingenieros pasan la mitad de la semana parcheando el scraper en lugar de lanzar producto. La calidad del retrieval cae, los clientes se dan cuenta 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 cada vez mayor (cualquier cosa construida en Next.js, cualquier cosa con renderizado del lado del cliente) necesita renderizado completo de navegador para devolver contenido útil.
  2. ¿Qué proxy? Residencial, de centro de datos, móvil, anclado a un geo, específico de un ISP. La elección correcta cambia según el objetivo.
  3. ¿Realmente funcionó? Un 200 con un body vacío, o una página HTML de CAPTCHA, es un request HTTP exitoso y un crawl fallido.

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

Para la decisión de renderizado, llamas a Single para el caso barato y rápido, y a Browser para objetivos pesados en JS. El body de la llamada tiene la misma estructura, por lo que tu código de ingestión se ramifica una sola vez en un flag por fuente en lugar de arrastrar cien peculiaridades 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 la response (en el nivel superior r.proxy en Single/Browser, o r.session.proxy en Auto), y reutilizas ese id en llamadas posteriores cuando necesitas mantener la misma salida. Tu crawler no necesita su propio algoritmo de clasificación de proxies. (Escribimos sobre por qué el tamaño del pool ha dejado de ser el diferenciador en Why Proxy Pool Size Stopped Mattering in 2026.)

Y para la pregunta de si realmente funcionó, cada request soporta un bloque validate. Declaras qué cuenta como éxito: códigos de estado aceptados, valores de header requeridos, cadenas en el body que deben o no deben aparecer. FourA devuelve uno de siete resultados, y solo success es facturable. Un 200 que no pasa tus reglas de contenido se marca como application_fail y nunca entra en tu dataset.

Así es como se ve una llamada de recrawl para un portal de docs que necesita renderizado de JS. Dejamos que Auto orqueste (elige el producto correcto entre Single, Proxy o Browser, maneja las defensas contra bots y devuelve la tripleta 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"] or r["body"]   — rendered content (Auto runs the right sub-product per host;
#                            Single populates "data", Browser populates "body")
# r["session"]              — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["session"]["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 atrapa. El resultado registrado contra tu uso es application_fail. No pagas por ello y tu código de ingestión sabe que debe reintentar con un proxy diferente en lugar de alimentar tus embeddings con una página de validación.

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

Resultados

Así es como se ve el ciclo de frescura una vez que la infraestructura deja de ser el cuello de botella (escenario ilustrativo basado en patrones que vemos en equipos de IA vertical):

  • 500 URLs de origen recrawleadas semanalmente, en lugar de una ejecución única de 200 URLs en el lanzamiento
  • Tiempo de ingeniería en el scraper: menos de 2 horas por semana, bajando desde 1 o 2 días
  • Ventana de obsolescencia en el retrieval: 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 trampa son rechazados en la capa 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 magia. El punto es que es aburrido. Y aburrido es lo que necesita la IA en producción. (Para más sobre cuándo los números dejan de cuadrar con la extracción de LLM alojados, ver When LLM Extraction Stops Paying for Itself.)

Conclusión clave

La mayoría de los equipos que construyen IA vertical piensan que su foso defensivo es el prompt, la elección del modelo o el algoritmo de retrieval. No lo es. El foso es el ciclo de frescura: la infraestructura poco glamorosa que mantiene la base de conocimientos honesta semana tras semana.

Los equipos que ganen en IA vertical hasta 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.