7. Sincronización de Archivos Eliminados de Google Drive (sincronización total)

Descarga el Workflow de n8n de esta lección:

En la lección anterior, dimos un paso crucial al optimizar nuestro sistema RAG (Retrieval-Augmented Generation). Configuramos nuestro flujo de trabajo para que detecte automáticamente cuándo añadimos archivos nuevos o modificamos los existentes en nuestra carpeta de Google Drive, actualizando nuestra base de datos vectorial de forma inteligente.

Sin embargo, nuestro sistema aún tiene un punto ciego: ¿qué ocurre si borramos un archivo de Google Drive?

Actualmente, aunque eliminemos un archivo, toda su información (sus vectores) permanece en nuestra base de datos. Esto «contamina» nuestro RAG, ya que podría seguir dando respuestas basadas en información que ya hemos descartado.

El objetivo de esta lección es completar la sincronización. Vamos a implementar la lógica necesaria para que nuestro sistema detecte automáticamente los archivos eliminados en Google Drive y los borre de nuestra base de datos vectorial.

El Desafío: Sincronizar Eliminaciones

Nuestro flujo de trabajo actual es excelente para añadir y actualizar información, pero ignora las eliminaciones.

Nuestra meta es que el workflow de n8n no solo verifique los archivos nuevos o modificados, sino que también compare la lista total de archivos en Google Drive con los registros de nuestra base de datos. Si detecta que un archivo existe en la base de datos pero ya no está en Drive, debe iniciar un proceso de borrado.

Revisión Rápida del Flujo de Trabajo Existente

Recordemos brevemente nuestro workflow actual en n8n:

1. Trigger (Disparador): Se activa periódicamente (por ejemplo, cada noche).
2. Google Drive: Escanea de forma recursiva toda nuestra carpeta de RAG.
3. Filtrado: Distingue entre archivos y carpetas para procesar solo los archivos.
4. Verificación (Base de datos ingestor_files): Compara cada archivo con nuestra base de datos «de memoria» (ingestor_files).
5. Lógica de Sincronización:
   • Si es nuevo: Lo procesa, vectoriza y añade a la base de datos vectorial (n8n_vector) y a la de registro (ingestor_files).
   • Si está modificado (comprobando el hash MD5): Borra los vectores antiguos y añade los nuevos.
   • Si ya existe y no ha cambiado: Lo ignora.

Ahora, vamos a añadir la lógica de borrado.

Paso 1: Agregar Todos los Archivos Actuales a un Array

Primero, necesitamos una lista completa de todos los archivos que existen actualmente en nuestra carpeta de Google Drive al momento de la ejecución.

Acción: Añade un nodo Aggregate al final de la rama que procesa los archivos (después del nodo «IF» que comprueba si el archivo ya se ha procesado).

Configuración del nodo Aggregate:

• Objetivo: Agrupar todos los file_id (el ID del archivo en Google Drive) de los archivos escaneados en un único array.
• Fields to include:
  • Field: id (o el nombre del campo que contenga el ID del archivo de Google Drive).
• Nombre del Nodo (Recomendado): «Agregar IDs de Drive»

Cuando este nodo se ejecute, su salida será un único ítem que contiene un array con todos los IDs de los archivos encontrados en Google Drive.

Paso 2: Detectar Archivos «Huérfanos» en la Base de Datos

Con la lista actualizada de archivos en Drive, es hora de compararla con nuestra base de datos de registro (ingestor_files) para encontrar archivos «huérfanos» (aquellos que borramos de Drive pero siguen registrados en la base de datos).

Acción: Añade un nodo Postgres (o el de tu base de datos) después del nodo Aggregate.

Configuración del nodo Postgres:

• Operation: Execute Query.
• Query (Consulta):SQLSELECT "fileId" FROM "ingestor_files" WHERE "fileId" != ALL($1::text[]);
• Explicación de la Consulta:
  • SELECT "fileId" FROM "ingestor_files": Selecciona todos los IDs de archivo que tenemos registrados en nuestra tabla de memoria.
  • WHERE "fileId" != ALL($1::text[]): Compara cada fileId de la tabla con el array de IDs que recibimos del nodo Aggregate. El $1 es el parámetro que le pasaremos, y ::text[] lo convierte en un array de texto que SQL puede entender.
  • Resultado: Esta consulta devolverá únicamente los fileId que existen en ingestor_files pero que ya NO están en el array de Google Drive (es decir, los archivos borrados).
• Parameters (Parámetros):
  • Parameter 1: Aquí pasaremos el array de IDs del nodo anterior. La expresión en n8n sería: {{ $json.data.map(obj => obj.id) }} (Esta expresión toma la salida del nodo Aggregate, mapea el array para extraer solo los id y los entrega como parámetro a la consulta).
• Configuración Crítica (Pestaña «Settings»):
  • Activa la opción «Always Output Data» (Siempre Devolver Datos).
  • Por qué es vital: Si no se ha borrado ningún archivo, esta consulta no devolverá nada y, por defecto, n8n detendrá el flujo de trabajo aquí. Al activar esta opción, el workflow continuará con un resultado vacío, permitiendo que el resto de la automatización siga funcionando.

Paso 3: Eliminar los Vectores del Archivo Borrado

Si el «Paso 2» encontró archivos huérfanos, su fileId pasará a este nuevo nodo. Ahora, debemos usar ese ID para borrar los vectores asociados de nuestra base de datos vectorial.

Acción: Añade un nodo Postgres después del nodo de consulta SQL (Paso 2).

Configuración del nodo Postgres (Borrar Vectores):

• Operation: DELETE.
• Schema: public (o el que estés usando).
• Table: n8n_vector (o el nombre de tu tabla de vectores).
• Conditions (Condiciones WHERE):
  • Column: fileId (o el nombre de la columna que usas para vincular el vector al archivo).
  • Value: {{ $json.fileId }} (esto tomará el fileId de cada ítem que venga del nodo anterior).
• Configuración (Settings): Activa «Always Output Data».

Paso 4: Eliminar el Registro del Archivo Borrado

Finalmente, para completar la limpieza, borramos el archivo de nuestra tabla «de memoria» (ingestor_files).

Acción: Añade un nodo Postgres después del nodo de borrado de vectores (Paso 3).

Configuración del nodo Postgres (Borrar Registro):

• Operation: DELETE.
• Schema: public.
• Table: ingestor_files.
• Conditions (Condiciones WHERE):
  • Column: fileId.
  • Value: {{ $json.fileId }}.
• Configuración (Settings): Activa «Always Output Data».

Paso 5: Automatizar la Sincronización Completa

¡Nuestro flujo de trabajo ya está completo! Ahora es capaz de gestionar adiciones, modificaciones y, lo más importante, eliminaciones, manteniendo nuestro Google Drive y nuestra base de datos vectorial en perfecta sincronía.

El último paso es automatizar su ejecución.

Acción: Reemplaza el disparador (Trigger) manual de tu workflow por un nodo Cron.

Ejemplo de configuración Cron:

• 0 0 * * *: Se ejecutará todos los días a medianoche. Esta es una configuración recomendada para producción, ya que no sobrecarga el sistema.
• */5 * * * *: Se ejecutará cada 5 minutos. Úsalo solo para pruebas, ya que consume más recursos.

Conclusión de la Lección

¡Felicidades! Has construido un sistema de ingesta de datos para tu RAG que es completamente automatizado, robusto y eficiente.

En esta lección, hemos implementado la lógica crucial para detectar archivos eliminados en Google Drive y purgarlos automáticamente de nuestra base de datos vectorial y de nuestra tabla de registros.

Con esto, cerramos el ciclo de sincronización de documentos. En las próximas lecciones, empezaremos a explorar… (Aquí puedes enlazar con tu siguiente módulo).

¡Nos vemos en el próximo vídeo!