Agentes de IA
Hugging Face: el archivo ya está subido, pero tu agente todavía no lo ve
Una lista guardada en caché puede dejar fuera archivos nuevos. Así funciona live_follow en los Buckets de Hugging Face y cuándo tiene sentido activarlo.
Un listado antiguo puede parecer un archivo que falta
La herramienta de un agente consulta una carpeta y guarda su listado en caché. Después, otro proceso sube un archivo. Si la siguiente consulta reutiliza aquella lista, el agente puede concluir que el archivo aún no existe. El problema está en la información que recibe de su herramienta.
Hugging Face ha explicado una opción para este caso en su repaso del 26 de octubre. HfFileSystem puede seguir los cambios de un Storage Bucket y retirar de la caché los listados afectados. La función se llama live_follow y llegó con huggingface_hub 2.3.0, publicada el 22 de octubre.
Qué cambia cuando activas live_follow
HfFileSystem permite trabajar con archivos del Hub mediante una interfaz parecida a la de un sistema de archivos. Con live_follow=True, al listar un Bucket abre una conexión en segundo plano para recibir sus cambios. Cuando llega uno, invalida los listados correspondientes. La siguiente consulta puede obtener la información renovada.
La opción está desactivada por defecto porque mantiene una conexión por cada Bucket seguido. Se limita a listados y metadatos, como las consultas de nombres, existencia o información de un archivo. No vuelve a ejecutar por sí sola el agente ni procesa los archivos que aparecen.
Un lote de imágenes que llega después de empezar
Imagina un sistema que prepara una evaluación de clasificación de imágenes. Al arrancar encuentra lote-01.csv en un Bucket. Una persona termina de revisar otro lote y sube lote-02.csv mientras el proceso sigue abierto.
Si el sistema conserva el primer listado, podría evaluar solo el lote inicial y presentar un informe incompleto. Seguir los cambios ayuda a que una nueva consulta descubra el segundo archivo. Es un ejemplo hipotético de uso, no una prueba realizada con el servicio.
A partir de ahí todavía hay decisiones propias de la aplicación. Debe comprobar qué lotes están preparados, cuáles ha procesado y si el informe debe incorporar archivos que lleguen durante la ejecución. Releer toda la carpeta después de cada aviso podría repetir trabajo. Una opción sería registrar los lotes aceptados y fijar cuáles pertenecen a cada evaluación.
El alcance cambia según dónde guardes los datos
Este seguimiento es para Storage Buckets. No tiene efecto en los repositorios de modelos, datasets o Spaces. Para observar un commit nuevo en esos repositorios, las notas de la versión indican el uso de refresh=True. Conviene identificar primero qué clase de recurso está leyendo la herramienta.
Además, refrescar un listado y leer el contenido son operaciones diferentes. La versión documenta que la lectura del archivo obtiene su contenido del Hub. live_follow actúa sobre la información usada para localizarlo y consultar sus metadatos.
HfFileSystem aporta compatibilidad con fsspec y bibliotecas que esperan esa interfaz. También añade una capa de trabajo. La documentación recomienda los métodos de HfApi cuando encajan mejor, por rendimiento y fiabilidad. No hace falta trasladar toda una aplicación a HfFileSystem para beneficiarse de esta idea.
Antes de cambiar el modelo, revisa lo que ha podido consultar
Cuando un agente dice que falta un documento, comprobaría la ruta, los permisos y la antigüedad del listado que recibió. Un modelo distinto puede seguir fallando si la herramienta le entrega la misma información desactualizada.
El seguimiento de cambios merece la pena en procesos abiertos durante bastante tiempo y con otros escritores activos. Para una ejecución corta con una entrada fija, un listado renovado al empezar puede ser suficiente. La elección depende de cuándo deben entrar los datos nuevos en el trabajo, no de tener siempre una conexión abierta.