Taxonomista documental multi-agente

• Inducción de esquema vía agente LLM: propone y refina automáticamente un esquema de extracción desde documentos de ejemplo.
• Arquitectura cloud-native: FastAPI (Cloud Run) + workers por eventos (Cloud Functions Gen2) + estado en Firestore.
• Diseño idempotente: locks por archivo en Firestore, backoff exponencial, fallback dual de LLM (Gemini a OpenAI).
• Agnóstico de dominio: aplícalo a cualquier corpus de documentos (legal, financiero, médico) induciendo un nuevo esquema.

• Inducción de esquema vía agentes LLM: auto-diseño de plantillas de extracción desde documentos de ejemplo, sin mapeo manual.
• Workers idempotentes por eventos: locks de Firestore por archivo previenen doble procesamiento en reintentos concurrentes.
• Fallback dual de LLM: si falla el proveedor principal (Gemini), el sistema pasa automáticamente al backup (OpenAI).
• Map/reduce sobre chunks de PDF: extracción LLM en paralelo por chunk, reduce agrega con procedencia del fragmento.
• SDKs auto-generados desde spec OpenAPI: clientes tipados JS y Python; los consumidores nunca importan internals del backend.

Los PDFs no estructurados están en todas partes (expedientes judiciales, reportes financieros, documentos de licitación), pero extraer datos estructurados de ellos requiere escribir un parser por cada formato.

Objetivo: construir una plataforma donde el esquema de extracción se induzca automáticamente desde ejemplos, y el pipeline de procesamiento escale a miles de documentos sin intervención manual.

La plataforma es agnóstica de dominio: se ha aplicado a recursos judiciales (proyecto TARCJA) y está diseñada para funcionar en cualquier corpus de documentos con mínima configuración.

• Inducción de esquema vía agentes LLM: un agente SchemaDesigner propone nombres de campos, tipos, reglas y sinónimos analizando una muestra de documentos, sin requerir definición manual del esquema.
• Cloud Functions Gen2 con eventos de GCS (Eventarc): cada PDF subido activa un worker independiente, con paralelismo natural sin cola explícita.
• Firestore para estado idempotente: registros por archivo en transacciones atómicas, seguros para reintentar o reproducir cualquier job.
• Fallback dual de LLM (Gemini, luego OpenAI): si falla el proveedor, el sistema cambia automáticamente vía un adaptador compartido, configurable con una variable de entorno.
• Monorepo con paquete core compartido: backend y worker instalan multiagent-core (editable), sin duplicación de lógica ni imports cruzados.
• SDKs auto-generados desde spec OpenAPI: clientes tipados JS y Python permiten a los consumidores (frontend, scripts CLI) interactuar sin importar internals del backend.

• FastAPI (Cloud Run) gestiona orquestación de jobs, URLs firmadas de GCS, endpoints de inducción de esquema y health checks.
• Cloud Function Gen2 se activa en eventos de finalización de GCS (Eventarc): una invocación por PDF subido.
• Firestore registra el estado por archivo atómicamente, previniendo doble procesamiento en reintentos concurrentes.
• Paquete core compartido (multiagent-core): modelos de dominio, adaptadores LLM, lógica de chunking y servicios de storage, instalado en backend y worker.
• Frontend React (Vite): UI para inducción de esquemas, subida de documentos, monitor de jobs y visor de resultados, comunicada exclusivamente vía el SDK JS generado.

• Aplicado a más de 5200 recursos judiciales (proyecto TARCJA): 95–100% de cobertura en campos core, latencia media 16.8s por documento.
• La inducción de esquema reduce el setup de dominio de horas de mapeo manual a minutos de refinamiento guiado por agente.
• Procesamiento idempotente: cualquier job fallido o parcial puede reintentarse o reproducirse sin riesgo de registros duplicados.
• La arquitectura escala horizontalmente: cada PDF es una invocación independiente de Cloud Function, y el throughput crece con la tasa de subida a GCS.