Hemos construido un pipeline de ingesta dinámico, pero nos enfrentamos al siguiente desafío: ¿qué ocurre cuando un documento existente se actualiza? En esta lección, abordaremos este problema y construiremos la lógica para que nuestro sistema pueda manejar no solo nuevos documentos, sino también las versiones actualizadas de los existentes.
Paso 1: Manejando Múltiples Documentos Nuevos
Primero, vamos a asegurar que nuestro sistema puede procesar varios archivos a la vez si se suben juntos.
- Añadir un Nodo de Bucle (
Loop): Justo después de nuestroGoogle Drive Trigger, añadimos un nodoLoop Over Items. Esto asegura que si el activador detecta varios archivos nuevos a la vez, cada uno será procesado de forma individual, uno tras otro. - Enriquecer los Metadatos: Al cargar los datos en el nodo de Supabase, añadimos un metadato adicional:
file_name. Esto nos permitirá identificar los documentos por su nombre, además de por sufile_id. - Prueba de Carga Múltiple: Al ejecutar el flujo con nuestras dos actas de reunión en la carpeta, vemos que ambas se cargan correctamente en Supabase, cada una dividida en sus respectivos chunks y etiquetada con su
file_nameyfile_id.
Ahora, nuestro agente puede distinguir entre documentos. Si le preguntamos: «¿A qué archivos tienes acceso?», usará los metadatos para responder correctamente: «Tengo acceso a: ‘acta_reunion_03_abril.docx’ y ‘acta_reunion_10_abril.docx’.»
Paso 2: El Problema de la Actualización – La Duplicidad de Datos
Aquí viene el problema clave. Imaginemos que editamos el documento del 3 de abril directamente en Google Docs para eliminar a un asistente de la lista.
Si nuestro sistema simplemente re-ingesta el archivo actualizado, no reemplazará la versión antigua. En su lugar, añadirá la nueva versión como un conjunto completamente nuevo de chunks. El resultado es un desastre:
- Nuestra base de datos contendrá dos versiones del mismo documento con información contradictoria.
- Cuando el agente reciba una pregunta, podría recuperar chunks de la versión antigua, de la nueva, o de ambas, dando respuestas incorrectas y confusas.
Paso 3: La Solución – El Patrón «Borrar y Añadir» (Delete-Then-Add)
La estrategia correcta y robusta para manejar actualizaciones se conoce como el patrón «Borrar y Añadir». La lógica es simple: antes de añadir la nueva versión de un documento, primero borramos por completo cualquier versión antigua que exista en nuestra base de datos.
Para implementar esto en n8n:
- Añadir un Nodo de Borrado: Justo después del inicio del bucle (
Loop), añadimos un nodoSupabasecon la acciónDelete a Row(s). - Configurar el Filtro de Borrado: Le decimos a este nodo que borre filas de la tabla
documents. La condición de borrado es la clave: usamos un filtro que busca en la columna de metadatos.- Filtro:
metadata->file_id->eq->{{ $json.ID }} - Traducción: «Busca en la columna
metadatael campofile_id. Si su valor es igual al ID del archivo que ha activado este flujo de trabajo, borra todas las filas que cumplan esa condición.»
- Filtro:
[Image showing the Supabase Delete node configured with a metadata filter.]
El Flujo de Trabajo Completo
Con este nuevo paso, nuestro pipeline ahora funciona así para cada archivo detectado:
- Activador: Se detecta un archivo nuevo o actualizado en Google Drive.
- Borrado Preventivo: El sistema intenta borrar de Supabase cualquier chunk que ya exista con el
file_idde ese archivo. Si no existe ninguno (porque es un archivo nuevo), simplemente no hace nada y continúa. - Ingesta: El sistema procede a descargar, procesar e ingerir la nueva versión del archivo como lo hacía antes.
De esta manera, nos aseguramos de que siempre haya una única y actualizada versión de cada documento en nuestra base de conocimiento.
¡Felicidades! Ya no solo tienes un pipeline de ingesta, sino un sistema de gestión del ciclo de vida del conocimiento. Tu agente ahora puede no solo aprender nueva información, sino también olvidar la antigua y actualizarse con la nueva, de forma totalmente automática.