Desarrollo de Automatizaciones N8n para Integración con Api Rest Local de Obsidian Cliente enterprise

Automatización n8n con RAG en Supabase y sincronización con Obsidian
Contexto general del proyecto
Se requiere desarrollar una automatización en n8n compuesta por dos flujos independientes pero conectados a un mismo RAG (Retrieval Augmented Generation) basado en Supabase con pgvector. Posteriormente, estos dos flujos deberán explicarse en dos vídeos independientes.
El sistema debe permitir:
Consultar conocimiento personal desde WhatsApp mediante un agente.
Alimentar y mantener actualizado ese conocimiento a partir de notas locales de Obsidian usando su API local.
El objetivo es que ambos flujos sean atómicos, reutilizables y desacoplados, confluyendo únicamente en el RAG.
Arquitectura general
Orquestador: n8n (self-hosted o cloud).
Vector store: Supabase con pgvector.
Canal de entrada de consultas: WhatsApp (WhatsApp Business Cloud API o proveedor equivalente).
Fuente de conocimiento: Obsidian local vía Local rest api expuesta mediante túnel seguro.
Modelo LLM: compatible con generación de embeddings y texto.
Un único esquema de RAG compartido por ambos flujos.
Flujo 1: flujo de lectura
Consulta al RAG desde WhatsApp.
Objetivo del flujo 1
Permitir al usuario enviar preguntas desde WhatsApp y recibir respuestas generadas a partir del conocimiento almacenado en el RAG.
Descripción funcional del flujo 1
El usuario envía un mensaje de texto por WhatsApp.
El mensaje llega a n8n mediante webhook del proveedor de WhatsApp.
N8n transforma la pregunta en un embedding.
Se consulta Supabase para recuperar los chunks más relevantes mediante búsqueda vectorial.
Se construye un prompt de contexto con los resultados recuperados.
El LLM genera una respuesta basada exclusivamente en ese contexto.
La respuesta se devuelve al usuario por WhatsApp.
Requisitos técnicos del flujo 1
Implementar búsqueda vectorial con parámetro top_k configurable.
Valor inicial recomendado: top_k = 8.
Aplicar filtros por metadatos en la recuperación:
tipo_nota
ruta o carpeta de origen
etiquetas, si existen
Evitar duplicados en el contexto final.
Controlar el tamaño máximo del contexto para no degradar la respuesta.
Manejar errores de forma explícita:
Sin resultados relevantes.
Fallo del LLM.
Fallo de conexión con Supabase o WhatsApp.
Entradas del flujo 1
Texto libre enviado por WhatsApp.
Salidas del flujo 1
Respuesta en texto enviada por WhatsApp.
Logs de ejecución en n8n con:
top_k usado
número de chunks recuperados
tiempo de respuesta aproximado
Flujo 2: flujo de escritura
Sincronización Obsidian → RAG.
Objetivo del flujo 2
Alimentar y mantener actualizado el RAG a partir de notas locales de Obsidian, evitando duplicados y reindexaciones innecesarias.
Descripción funcional del flujo 2
El flujo se activa manualmente o de forma programada.
Antes de empezar, se comprueba la disponibilidad de la API local de Obsidian mediante una llamada de verificación.
Si la API está disponible:
Se listan las notas que cumplan al menos una de estas condiciones:
Contener la etiqueta sincronizar.
Estar dentro de una carpeta configurada.
Para cada nota:
Se obtiene el contenido en markdown.
Se obtiene el nombre del fichero y su id único, si lo tiene.
Se normaliza el texto.
Se calcula un hash de integridad del fichero.
Se compara con el último hash almacenado en Supabase.
Si el hash no ha cambiado, la nota se omite.
Si el hash ha cambiado o no existe:
Se trocea el contenido en chunks.
Se generan embeddings.
Se hace upsert en Supabase con control de duplicados.
El flujo finaliza con un resumen de la sincronización.