← 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

Las startups de IA vertical chocan contra el mismo muro alrededor del segundo mes. Lanzan un copiloto de soporte, un asistente de investigación jurídica o un bot de cumplimiento. La primera demo convence a los clientes. Luego, los datos envejecen y las respuestas empiezan a alejarse de la realidad.

Hemos visto a equipos construir la parte de IA de forma impecable y dejar la parte de datos como algo secundario. El pipeline de ingesta es un único script de Python ejecutándose en la laptop de alguien. Hace scraping de 200 URL de origen una sola 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, API obsoletas o funciones del producto que se lanzaron en marzo y se modificaron de nuevo en mayo.

La solución parece simple: reindexar cada fuente semanalmente. La realidad es más compleja. Para 2026, alrededor del 60% de los sitios de buena reputación 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 peticiones y las señales a nivel de handshake. Un script básico que funcionaba en enero devuelve silenciosamente páginas vacías en marzo.

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

El enfoque

El problema de la reindexación 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 con Next.js o con renderizado del lado del cliente) necesita un renderizado completo en navegador para devolver contenido útil.
  2. ¿Qué proxy usar? Residencial, datacenter, móvil, geolocalizado o específico de ISP. La elección correcta varía según el objetivo.
  3. ¿Realmente funcionó? Un código 200 con un body vacío o una página de verificación es un request HTTP exitoso pero un crawl fallido.

Una plataforma como FourA gestiona cada uno de estos puntos como una prioridad fundamental.

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

Para la selección de proxy, Proxy Finder se ejecuta como parte de cada llamada Single, Browser y Auto. La plataforma elige una salida funcional por request, devuelve su id opaco en la response (en r.proxy al nivel superior en Single/Browser, o en r.session.proxy en Auto), y reutilizas ese id en las llamadas posteriores cuando necesitas mantener la misma salida. Tu crawler no necesita implementar su propio algoritmo de clasificación de proxies. (Escribimos sobre por qué el tamaño del pool dejó 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. Tú defines qué cuenta como éxito: códigos de estado aceptados, valores de header obligatorios, 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 cumple con tus reglas de contenido se marca como application_fail y nunca entra en tu conjunto de datos.

Así es como se ve una llamada de recrawl para un portal de documentación que necesita renderizado JS. Dejamos que Auto se encargue de la orquestación: elige el producto adecuado (Single, Proxy o Browser), gestiona las defensas antibot y devuelve la tupla de sesión para que el siguiente recrawl pueda mantener 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 muestra un interstitial de Cloudflare, la regla validate.data.fail lo intercepta. 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 enviar una página de "Just a moment..." a los embeddings.

Para el corpus más amplio, integras el mismo patrón en tu cola de tareas existente. Los equipos con los que hemos hablado ejecutan diffs nocturnos contra el rastreo anterior, vuelven a generar embeddings solo para los documentos que realmente cambiaron y actualizan corpus de 500 fuentes en un par de horas de tiempo de reloj. 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 ciclo de actualización una vez que la infraestructura deja de ser el cuello de botella (escenario ilustrativo basado en patrones que observamos en equipos de vertical AI):

  • 500 URL de origen rastreadas semanalmente, en lugar de una extracción única de 200 URL en el lanzamiento
  • Tiempo de ingeniería en el scraper: menos de 2 horas por semana, frente a 1-2 días
  • Ventana de desactualización de recuperación: 5-7 días, en lugar de indefinida
  • Tasa de datos no deseados en el vector store cercana a cero, porque los interstitials 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 rastreos fallidos no se reflejan en la facturación

El punto no es que nada de esto sea mágico. El punto es que es predecible y rutinario. Y eso es exactamente lo que la IA en producción necesita. (Para más detalles sobre cuándo los números dejan de cuadrar con la extracción mediante LLM alojados, consulta When LLM Extraction Stops Paying for Itself.)

Conclusión clave

La mayoría de los equipos que desarrollan vertical AI creen que la ventaja competitiva está en el prompt, la elección del modelo o el algoritmo de recuperación. No es así. La ventaja es el ciclo de actualización: la infraestructura técnica que mantiene la base de conocimiento al día semana tras semana.

Los equipos que lideren en vertical AI 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.