Cómo funciona la monitorización
Page Deltas ejecuta sus monitorizaciones según un calendario adaptativo, obtiene cada página con el método más ligero que funcione y utiliza un filtro LLM para que solo reciba las alertas que importan.
El ciclo de vida de una comprobación
- Planificación. Un planificador central selecciona las monitorizaciones cuya fecha de
next_check_atha vencido y encola tareas en una cola de Postgres. - Obtención. Un worker toma la tarea y obtiene la página (HTTP simple, luego un navegador headless a través de un proxy de centro de datos, y después a través de un proxy residencial; véase más abajo).
- Extracción. El HTML se reduce a su contenido de texto principal. Los elementos repetitivos (navegación, pie de página, anuncios) se eliminan.
- Hash y comparación. Se compara un hash normalizado con la última comprobación. Si es idéntico, la ejecución termina aquí, sin llamada al LLM.
- Filtro LLM. Si el hash cambió, la comparación de cambios y su descripción se envían a un LLM que decide si el cambio es significativo.
- Alerta. Los cambios significativos se escriben en
monitor_changesy se encolan para su envío a cada canal asociado a la monitorización.
Planificación adaptativa
Usted no establece una frecuencia de comprobación. El planificador observa con qué frecuencia cambia realmente una página y ajusta next_check_at en consecuencia: más rápido cuando se producen cambios, más lento cuando la página está inactiva. Su plan también influye en la cadencia: los planes superiores obtienen mayor prioridad de planificación. Así, su uso se mantiene proporcional al valor que obtiene.
Escalado del obtenedor
Cada comprobación empieza de forma económica y solo escala si es necesario:
- HTTP simple. Sin JavaScript, sin navegador. Rápido y económico. Funciona para la mayoría de las páginas renderizadas en servidor y los endpoints JSON.
- Navegador headless mediante proxy de centro de datos. Se utiliza cuando la página se renderiza en el cliente o cuando la obtención simple está bloqueada. Renderizamos con Camoufox, un Firefox con parches de sigilo que elude la mayoría de las técnicas de fingerprinting, enrutado a través de un proxy de centro de datos de Oxylabs.
- Navegador headless mediante proxy residencial. Se utiliza cuando la obtención a través del proxy de centro de datos sigue bloqueada. Enruta la misma petición del navegador a través de IP residenciales de Oxylabs.
Los bytes enrutados a través del proxy residencial se contabilizan por organización como medida de control de costes.
El filtro LLM
Cuando el hash del texto de la página cambia, no alertamos de inmediato. Primero enviamos la comparación de cambios y la descripción de su monitorización a un LLM con una sola pregunta: dada esta descripción, ¿es este cambio significativo?
Qué detecta
- Cambios de precios en la página de precios de un competidor.
- Lanzamientos de nuevos productos en una hoja de ruta o un changelog.
- Cambios en las ofertas de empleo de una página de empleo que esté vigilando.
Qué ignora
Los espacios en blanco y los elementos repetitivos (navegación, pie de página, anuncios) se eliminan antes de calcular el hash, por lo que nunca llegan al LLM. Además, el clasificador tiene instrucciones de tratar lo siguiente como no significativo:
- Testimonios rotativos, anuncios, marcas de tiempo del tipo «añadido hace 3 días» y recuentos de visitas.
- Reordenaciones sin cambio semántico.
- Hashes de compilación e identificadores de sesión.