Volver al caso de estudio

Arquitectura del sistema

Descripción técnica de la infraestructura que impulsa el ecosistema Casa Islamica, conectando la ingeniería de datos con las aplicaciones del usuario final.

Sistema en producción

Motor de IA conversacional (v3.1)

Pipeline de Retrieval-Augmented Generation (RAG) multi-paso con routing semántico, fallback de precisión a fuente primaria y reranking con Cohere.

1. Ingesta y routing
  • ◆ Recibe la consulta del usuario vía Webhook e inicia la gestión de sesión.
  • ◆ El Query Rewriter con LLM traduce y expande los términos de búsqueda.
  • ◆ Detector de coincidencia exacta vía regex activa el routing especializado.
2. Recuperación vectorial
  • ◆ Aplica filtros de dimensión dinámicos (ej. Marco legal, Teología, Filosofía).
  • ◆ Búsqueda paralela en Pinecone y consulta directa al índice de manuscritos primarios.
  • ◆ El Reranker de Cohere optimiza los Top K resultados para mayor precisión contextual.
3. Síntesis
  • ◆ Formatea el contexto recuperado aplicando jerarquía de fuentes por tier.
  • ◆ Inyecta el buffer de memoria de LangChain para contexto de conversaciones multi-turno.
  • ◆ GPT-4o genera la respuesta respetando guardrails estrictos por dominio temático.
4. Telemetría y output
  • ◆ Retorna el payload a la interfaz de usuario.
  • ◆ Registra métricas de recuperación (F1, Precisión) en Google Sheets.
  • ◆ Envía datos de interacción a Supabase y dispara notificaciones en Slack.
Pipeline de ingeniería de datos

Clasificación automática del corpus (v3)

Sistema de procesamiento por lotes para ingestar PDFs sin estructura, extraer texto y aplicar etiquetado de metadatos con LLM para vectorización.

1. Extracción

Itera sobre los PDFs en Google Drive. Descarga los archivos y ejecuta OCR/extracción de texto para generar los payloads de texto crudo.

2. Análisis con IA

Gemini 2.5 Flash analiza los textos completos para determinar la estrategia de chunking, el tier de fuente, las etiquetas de categoría y los patrones regex estructurales.

3. Formateo estructurado

Parsea el output JSON, lo formatea en un schema estandarizado, agrega los metadatos al repositorio central y envía alertas de finalización.

QA y pipeline de ML

Sistema de observabilidad y evaluación

Arquitectura de 4 capas construida para IA con alta exigencia de precisión. Separa la infraestructura transaccional del chat de la telemetría analítica, convirtiendo las revisiones de expertos en un dataset de entrenamiento RLHF.

1. Telemetría automatizada

N8N escribe el contexto completo de recuperación (18+ campos, incluyendo scores de reranking y snippets) en una tabla OLAP, permitiendo diagnóstico de causa raíz entre fallos de generación y de recuperación.

2. Señal de usuario

El frontend React captura feedback estructurado. La distinción estricta entre 'no útil' (fallo de UX) y 'error' (desinformación teológica) envía los casos de alta severidad a una cola prioritaria.

3. Revisión experta

Panel de administración con scoring aislado por administrador. Utiliza un rubric de 4 categorías donde un score ternario de 'Corrección' controla automáticamente el veredicto final, evitando etiquetas de entrenamiento contradictorias.

4. Exportación RLHF

Agrega los logs revisados en un dataset de 30 campos. Preserva los metadatos de recuperación, la identidad del anotador y los detalles completos del rubric para entrenar futuros reward models.

Bajo el capó

Lógica de orquestación

Ejecución a nivel de nodo, mapeada directamente desde las capas de orquestación n8n. Organizada por etapa arquitectural para destacar los gates de decisión, la gestión de restricciones y la mutación de datos.

Pipeline 1: RAG Chatbot (v3.1)

33 nodos · Síncrono + Asíncrono
Etapa 1: Preprocesamiento
Webhook Trigger

Recibe la consulta en español y el UUID de sesión. Desacopla N8N de las edge functions del frontend.

Query Rewriter (GPT-4o-mini)

Traduce del español al inglés y expande semánticamente la consulta para mejorar el recall vectorial.

Decisión: GPT-4o-mini en lugar de GPT-4o. La traducción es una tarea de bajo riesgo; ahorra costo y latencia antes de la recuperación intensiva.
Etapa 2: Recuperación
Filtro de dimensión y router

Extrae etiquetas temáticas (ej. Rulings legales, Teología) para acotar el espacio de búsqueda. Detecta solicitudes explícitas de texto primario y las redirige a un índice autoritativo dedicado.

Búsqueda vectorial Pinecone

Consulta 64 800 vectores. Recupera Top-K=30. Estrictamente limitado a fuentes Tier 1 (Práctico) y Tier 2 (Comentario).

Etapa 3: Reranking
Cohere Rerank API v2

Request HTTP directo omitiendo el wrapper del SDK para control total de parámetros. Usa cross-encoder para reordenar Top 30 a Top 7. Descarta scores por debajo de 0.3.

Post-Rerank processing

Aplica boost al Tier 1 para priorizar guías prácticas. Limita la diversidad de fuentes (máx. 2 chunks por libro). Fusiona chunks adyacentes para restaurar el contexto.

Etapa 4: Generación
Ensamblaje de contexto

Formatea los chunks por tier. Inyecta el buffer de memoria persistente respaldado en Supabase para contexto de conversación multi-turno.

Síntesis con GPT-4o

Lee las fuentes en inglés para generar output localizado. Aplica guardrails estrictos por dominio y citas inline. Instruido para reconocer incertidumbre si las fuentes no tienen contexto suficiente.

Etapa 5: Output y observabilidad
Ejecución paralela

Retorna JSON al Webhook de forma síncrona para renderizado inmediato en UI, mientras registra telemetría de forma asíncrona.

Métricas registradas
Reranker F1 & Precision E2E Latency (ms) Source Tier Spread Context Diversity
Separación de datos: Escribe el historial de sesión en Supabase (agregaciones analíticas OLAP) y en Google Sheets (QA humana inmediata), manteniendo las consultas analíticas fuera de la base de datos de producción.

Pipeline 2: Clasificación batch del corpus (v3)

10 nodos · Procesamiento por lotes
Etapa 1: Control de lote
Drive Discovery

Escanea la carpeta de ingesta en busca de PDFs crudos. Alimenta el array de archivos al controlador de iteración.

Loop Controller

Procesa exactamente un libro a la vez para evitar el agotamiento del rate limit de la API y el desbordamiento de memoria.

Etapa 2: Ingesta
Extracción binaria

Descarga el PDF y extrae el payload de texto crudo. La baja fidelidad en la extracción de texto es aceptable aquí, ya que el LLM solo necesita comprensión temática.

Etapa 3: Análisis con IA
Gemini 2.5 Flash

Aprovecha la ventana de contexto de 1M tokens para ingestar el libro completo. Clasifica el tier de fuente, genera 22 campos JSON distintos y determina la estrategia de chunking vectorial (ej. temático vs. episódico).

Etapa 4: Entrega de datos
Append a Sheets

Escribe el output procesado en Google Sheets, que funciona como gate obligatorio de revisión humana antes de generar los vectores.

Buffer de rate limit

Aplica una espera estricta de 10 segundos antes de pasar al siguiente libro para proteger las cuotas de la API de Gemini.

Pipeline 3: Arquitectura de observabilidad y evaluaciones

4 capas · Escrituras paralelas en DB
Capa 1: Telemetría (N8N)
chatbot_queries_logs

Captura el contexto completo de recuperación — no solo la respuesta. Permite diagnosticar si un fallo se origina en una mala recuperación de chunks o en la generación del LLM.

OLAP Table
Capa 2: Señal de usuario (React)
chatbot_message_feedback

Rutas de feedback estructurado. Distinción estricta aplicada: 'error' ≠ 'no útil'. Los errores apuntan a posible desinformación teológica que requiere revisión inmediata.

OLTP Table
Separación intencional del schema
Capa 3: Revisión administrativa
Motor de rubric ternario

Puntuúa en 4 dimensiones. Corrección admite estados parciales (0, 0.5, 1) porque la precisión teológica tiene gradaciones significativas. Claridad/Eficiencia son binarias.

Veredicto autocalculado
  • IF correctness = 0 → BAD
  • IF correctness = 0.5 OR completeness = 0 → BAD
  • IF correctness = 1 AND completeness = 1 → GOOD

Calculado automáticamente, no fijado manualmente — previene contradicciones entre rubric y veredicto en los datos de entrenamiento.

Capa 4: Exportación Super Admin
Dataset listo para RLHF

Exportación CSV/XLSX masiva que combina metadatos de recuperación, identidad del anotador, valoraciones de usuarios y detalles completos del rubric.

¿Por qué 30 campos?
Los reward models necesitan señales más ricas que un simple "bueno/malo". Exportar el contexto completo permite entrenar modelos que mejoren simultáneamente la recuperación y la generación.