15. Manejo de Datos Dinámicos en RAG: Creando un Pipeline de Actualización

En la lección anterior, construimos un sistema RAG contextual que resolvía el problema de la «amnesia» entre chunks. Sin embargo, para que nuestro sistema sea verdaderamente profesional, nos enfrentamos a dos desafíos finales:

1. Los Datos son Estáticos: Nuestro sistema actual carga los datos una sola vez. ¿Cómo manejamos información que necesita ser actualizada constantemente, como notas de reuniones o procedimientos de la empresa?
2. La Ingesta Contextual es Lenta: El proceso de enriquecimiento, aunque potente, añade una latencia considerable.

En esta lección, nos centraremos en resolver el primer desafío: transformaremos nuestro pipeline de ingesta estático en uno dinámico y automatizado, preparado para manejar actualizaciones.

El Nuevo Caso de Uso: De Informes Anuales a Actas de Reunión

Los informes anuales son estáticos. Un caso de uso mucho más realista para las actualizaciones son las actas de reunión, que pueden ser editadas o complementadas después del evento. Para este ejemplo, usaremos dos documentos de Google Docs con las actas de nuestras reuniones semanales y los subiremos a la misma carpeta de Google Drive que nuestro sistema está monitorizando.

Paso 1: Simplificando el Flujo para Enfocarnos en la Actualización

Para esta tarea, la velocidad y la eficiencia de la ingesta son más importantes que el contexto profundo. Por lo tanto, eliminaremos el complejo (y lento) sub-flujo de enriquecimiento contextual y volveremos a un pipeline más simple y directo, similar al de nuestras primeras lecciones.

Paso 2: Refactorizando el Pipeline para la Flexibilidad

1. Adaptándonos a Nuevos Formatos (Google Docs):
   • Nuestro Switch Node actual está configurado para PDFs y CSVs. Necesitamos añadir una nueva ruta para manejar Google Docs.
   • Nota de Campo: Al inspeccionar los datos, descubrimos que los archivos de Google Docs no usan la propiedad fileType, sino mimeType. Actualizamos nuestro Switch Node para que use mimeType en todas sus rutas, haciéndolo más robusto. La condición para Google Docs será mimeType es igual a application/vnd.google-apps.document.
2. La Conversión Mágica de Google Drive:
   • Extraer texto directamente de un archivo .docx puede ser complicado. Afortunadamente, el nodo de Google Drive de n8n tiene una función increíblemente útil.
   • Dentro del nodo Google Drive, en la opción «Google File Conversion», podemos decirle que convierta automáticamente cualquier Google Doc a texto plano (text/plain) al descargarlo. Esto nos simplifica enormemente el resto del flujo.

Paso 3: La Clave para las Actualizaciones – Metadatos con ID Único

Este es el paso más importante de esta lección. Para poder actualizar o borrar un documento en el futuro, necesitamos una forma de identificar de manera única todos los chunks que pertenecen a él.

Dentro de nuestro nodo Supabase Vector Store, en la sección Options > Metadata, vamos a añadir dos campos cruciales:

1. file_id: Como valor, usaremos una expresión para extraer el ID único del archivo desde el nodo de Google Drive. Este ID será nuestra «matrícula» para cada documento.
2. created_time: También extraeremos la fecha de creación del archivo. Esto nos podría permitir en el futuro hacer operaciones como «actualiza todos los documentos modificados después de esta fecha».

Al hacer esto, cada chunk que se cargue en Supabase llevará consigo la «matrícula» del documento al que pertenece.

[Image showing the metadata configuration in the n8n Supabase node with file_id and created_time fields.]

Conclusión: Un Sistema Preparado para el Cambio

Hemos transformado con éxito nuestro pipeline. Ahora tenemos un sistema automatizado que:

• Se activa solo cuando se añade un nuevo archivo a una carpeta.
• Puede manejar diferentes formatos de archivo de forma inteligente.
• Y lo más importante, etiqueta cada fragmento de datos con un identificador único del documento original.

Hemos sentado las bases. Nuestro sistema ahora está preparado para la manipulación de datos. En la próxima lección, veremos cómo usar esta «matrícula» (file_id) para buscar, borrar y reemplazar datos de manera eficiente, completando así el ciclo de vida de la gestión de datos en RAG.