Event Scout

Una página de eventos es un mal formato de datos. El mismo dato aparece una vez como tabla, otra en el texto de un boletín, otra en un calendario que solo carga al desplazarse. Una expresión regular fracasa ahí; un modelo de lenguaje no. Justo ahí, y solo ahí, se sitúa por tanto el modelo: lee las páginas descargadas, decide qué es un evento presencial futuro al alcance y rellena para cada uno los campos de un esquema fijo.

Todo lo anterior y lo posterior es código corriente. Qué fuentes tocan hoy, cómo se descargan, cuándo dos entradas son el mismo evento, qué sale del registro al cabo de un año y qué aspecto tiene el panel están escritos en el código, no en una instrucción al modelo. El modelo tampoco escribe él mismo en el registro. Entrega un archivo, y un script lo incorpora a events.json según reglas fijas.

Ese archivo es el contrato. Tiene un esquema definido, es la única fuente de verdad y todas las vistas se generan a partir de él. No hay base de datos, ni servidor, ni suscripción. De ello se deriva la ventaja práctica más importante: cuando algo parece incorrecto, se puede abrir el archivo y ver si el error está en la lectura o en las reglas.

Que las reglas sean código no las hace correctas. La primera versión de la deduplicación consideraba dos entradas el mismo evento en cuanto llevaban el mismo enlace. Pero muchos organizadores publican todas las fechas de una serie bajo una única página de resumen, y así, en una sola ejecución, 23 fechas nuevas desaparecieron dentro de sus predecesoras más antiguas. Se detectó porque el fallo dejó un rastro comprobable: eventos pasados marcados como encontrados de nuevo ese mismo día. Desde entonces, un enlace igual solo cuenta como coincidencia si las fechas de inicio distan tres días como máximo.

Un modelo de lenguaje sabe leer bien una página desordenada. Llevar un registro no es una tarea de ese tipo.

Una fuente consultada cada semana con la misma minuciosidad cuesta tiempo aunque lleve meses sin aportar nada útil. Por eso cada fuente lleva un breve historial de rendimiento: cuántos eventos conservó el modelo de ella en las últimas cinco ejecuciones. La media la sitúa en una de tres bandas. El juicio del modelo solo guía la planificación a través de un número contado.

La banda A se consulta en cada ejecución. Incluye fuentes con una media de al menos tres eventos conservados y fuentes calificadas como especialmente importantes, incluso tras una ejecución vacía. La banda B contiene fuentes con algo de rendimiento o todavía sin historial; vuelven a tocar a los siete días, como máximo ocho por ejecución, las más antiguas primero. La banda C reúne fuentes que no aportan nada de forma repetida. Pausan siete, luego catorce, luego veintiocho días, treinta como máximo, y después se vuelven a probar, como máximo tres por ejecución.

Una página que carga pero no muestra eventos solo retrocede en el orden. Una fuente se considera rota únicamente cuando no se pudo descargar tres veces seguidas. Las fuentes nuevas proceden, entre otros sitios, de un registro de redes públicas, aceleradoras, institutos de investigación y clústeres de la región: si una organización tiene allí una página de eventos que aún no está en la base de datos de fuentes, puede añadirse. El registro en sí nunca se lee como fuente de eventos, para que nada cuente dos veces.