17. Puesta a Prueba del Sistema de Actualización de Datos

Hemos diseñado nuestro pipeline para que borre y reemplace documentos, pero la teoría es una cosa y la práctica es otra. En esta lección, vamos a poner a prueba nuestro sistema de actualización, depurar los errores que surjan y ver cómo se comporta en un escenario del mundo real.

El Experimento: Actualizando un Documento en Vivo

1. Consulta Inicial: Primero, consultamos a nuestro agente por un dato específico del documento: «¿Cuál fue el propósito de la reunión?».
   • Respuesta del Agente: «El propósito fue celebrar una sesión técnica semanal para la comunidad de Scrapes.ai.» ✅ Correcto.
2. La Actualización: Ahora, vamos directamente al archivo en Google Docs y cambiamos esa línea.
   • Nuevo Propósito: «El propósito fue retar a todos a un duelo.»
3. Ejecución del Flujo de Actualización: Activamos nuestro flujo de trabajo de n8n de nuevo. La expectativa es que detecte el archivo actualizado, borre la versión antigua de Supabase y cargue la nueva.
4. Segunda Consulta y… ¡Error!
   • Pregunta: «¿Cuál es el propósito de la reunión ahora?»
   • Respuesta del Agente: (Devuelve la información antigua). ❌ Fallo. El sistema no ha actualizado la información.

Depuración en Tiempo Real: Encontrando la Falla

Este es un momento de aprendizaje crucial. ¿Por qué ha fallado el sistema?

Al revisar nuestro flujo de n8n, descubrimos el error:

• El Problema: En el nodo Supabase (Delete a Row(s)), el filtro que debía buscar el file_id estaba mal configurado. No estaba apuntando a la variable correcta.
• La Solución: Corregimos la expresión en el filtro para que apunte correctamente al file_id del archivo que está siendo procesado.

Este tipo de errores son comunes en el desarrollo. La clave es saber cómo diagnosticar el problema revisando el flujo de datos paso a paso.

Segundo Intento: Verificando la Solución

1. Limpieza: Vaciamos nuestra tabla en Supabase para empezar de cero y asegurar un entorno limpio.
2. Re-ingesta: Volvemos a ejecutar el flujo para cargar la versión actualizada del documento, ahora con la corrección en el nodo de borrado.
3. Verificación Final:
   • Abrimos la ventana de chat y preguntamos de nuevo: «¿Cuál es el propósito de la reunión?»
   • Respuesta del Agente: «El propósito ha cambiado.» ✅ ¡Éxito! El agente ahora reconoce la última versión del documento.

Hemos demostrado que nuestro patrón «Borrar y Añadir» funciona a la perfección una vez que está correctamente configurado.

---

Lección 16: Manejando Nuevos Documentos y la Lógica del Bucle

En esta lección, nos aseguraremos de que nuestro sistema no solo pueda actualizar archivos, sino también manejar la ingesta de múltiples documentos nuevos de manera robusta, utilizando una lógica de bucle.

El Desafío: Procesar Múltiples Archivos a la Vez

Imagina que subes dos o tres documentos nuevos a tu carpeta de Google Drive al mismo tiempo. Nuestro activador los detectará, pero ¿cómo nos aseguramos de que cada uno sea procesado correctamente, uno por uno?

La Solución: El Nodo Loop Over Items

1. Implementación del Bucle: Justo después de nuestro activador de Google Drive, insertamos un nodo Loop Over Items.
2. Funcionamiento: Este nodo toma la lista de archivos detectados y ejecuta el resto del flujo de trabajo una vez por cada archivo. Esto evita errores y asegura que cada documento sea procesado de forma individual y secuencial.
3. Conexión Final: La salida del nodo Supabase (Add Documents) se conecta de nuevo al Loop, señalando que ha terminado con un archivo y está listo para el siguiente.

[Imagen de un flujo de n8n mostrando el nodo Loop Over Items después del Google Drive Trigger]

La Importancia de los Metadatos Dinámicos

Para que este sistema funcione, es crucial que los metadatos que añadimos (file_id, file_name, created_time) se extraigan dinámicamente del archivo que está siendo procesado en cada iteración del bucle.

• Depuración Común: Un error frecuente es que el nodo que añade los metadatos esté apuntando a una variable estática o al resultado de una prueba anterior.
• Solución: Asegúrate siempre de que las expresiones para los metadatos apunten a los datos del nodo de entrada actual dentro del bucle. Esto garantiza que cada chunk se etiquete con la «matrícula» correcta del documento al que pertenece.

Prueba del Sistema Completo

1. Carga: Subimos nuestras dos actas de reunión a la carpeta de Google Drive.
2. Ejecución: El flujo se activa y el bucle procesa el primer documento, y luego el segundo.
3. Verificación:
   • En Supabase, vemos que los chunks de ambos documentos han sido cargados correctamente, cada uno con sus respectivos metadatos (file_id y file_name).
   • En el chat del agente, preguntamos: «Resume la reunión del 3 de abril y dime quién asistió.»
   • Respuesta del Agente: (Proporciona un resumen preciso y la lista de asistentes correcta, demostrando que puede encontrar y utilizar la información de un documento específico de entre varios). ✅ Éxito total.

---

Lección 17: Resumen y la Transición a Cache-Augmented Generation (CAG)

¡Felicidades por llegar hasta aquí! Hemos recorrido un largo camino.

Resumen de Nuestro Viaje con RAG

1. Construimos un RAG Básico: Vimos su potencial, pero también sus limitaciones, especialmente la «amnesia contextual» al recuperar listas largas.
2. Implementamos RAG Contextual: Resolvimos esa limitación enriqueciendo cada chunk, pero descubrimos que este proceso era muy lento.
3. Construimos un Pipeline Dinámico: Creamos un sistema robusto capaz de manejar nuevos archivos y actualizaciones mediante el patrón «Borrar y Añadir».

Hemos creado un sistema RAG completo y profesional. Sin embargo, el problema de la lentitud de la ingesta contextual nos lleva a preguntarnos: ¿hay una forma más simple y rápida?

El Regreso de CAG (Cache-Augmented Generation)

Aquí es donde CAG vuelve a entrar en escena, y ahora entendemos perfectamente por qué.

• El Pasado: RAG se hizo popular porque los modelos como GPT-3.5 tenían ventanas de contexto diminutas (4,000 tokens). Era la única forma de trabajar con grandes documentos.
• El Presente (2025): Hoy, modelos como Gemini 2.0 y Claude 3.5 ofrecen ventanas de contexto gigantescas (hasta 1 millón de tokens) a precios muy bajos. Además, han introducido el cacheo de tokens, lo que significa que solo pagas por procesar los datos la primera vez en una sesión.

Esta revolución tecnológica ha hecho que CAG, la idea de cargar todo un documento en la «memoria» del LLM una sola vez, sea una alternativa increíblemente atractiva.

RAG vs. CAG: ¿Cuándo Usar Cada Uno?

• Usa RAG (nuestra solución actual) si:
  • Tu base de conocimiento es enorme y crece constantemente (como un repositorio de todas las reuniones de la empresa durante años). RAG es más escalable a largo plazo.
  • Necesitas que las actualizaciones sean granulares y frecuentes.
• Usa CAG si:
  • Estás trabajando con documentos grandes pero finitos que no se actualizan con demasiada frecuencia (como un informe anual, un libro o el manual de un proyecto).
  • La velocidad de respuesta es absolutamente crítica, ya que elimina el paso de búsqueda en la base de datos.
  • La simplicidad de configuración es una prioridad.

En la próxima sección, cerraremos el círculo y te mostraremos cómo implementar un sistema CAG en n8n. Verás lo sorprendentemente fácil que es y entenderás cuándo puede ser la mejor opción para tus proyectos.