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 → 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 — 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 → 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, 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 — se comunica 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 — el throughput crece con la tasa de subida a GCS.