Extracción multi-etapa con LLM y procedencia restringida para catálogos heterogéneos: diseño y protocolo de benchmark

1. Formulación del problema y contribución

Un catálogo de proveedor no es solo un conjunto de strings. Sus filas codifican producto, marca, presentación, formato de venta, unidad, precio y a veces descuento o condición mayorista. El significado se reparte entre encabezados, celdas combinadas, grupos visuales, notas y abreviaturas. Las planillas exponen celdas pero pueden tener filas decorativas y registros multilínea; los PDF preservan apariencia y pierden semántica tabular. La extracción debe recuperar campos y un vínculo defendible con la fila fuente.

La implementación Cuqui separa metadata documental, reconstrucción de filas y normalización [1–3]. La idea es plausible: las etapas tempranas preservan layout e identidad; las posteriores trabajan con contexto acotado y schema estricto. Plausibilidad no es evidencia comparativa. La pregunta es si la estructura reduce omisiones, alucinaciones y revisión frente a un prompt de una pasada manteniendo constantes modelo, documentos y scoring.

• Especificar la tarea en niveles de fila, campo y procedencia.
• Auditar etapas, validaciones, retries y gates de revisión.
• Reproducir los tests deterministas en una revisión fijada.
• Diseñar una comparación controlada sin afirmar un resultado no ejecutado.
• Definir artefactos suficientes para scoring y análisis independiente.

2. Trabajo relacionado y posicionamiento

Document AI aborda documentos visuales mediante modelos multimodales con OCR y sistemas image-to-sequence sin OCR. LayoutLMv3 preentrena texto e imagen para tareas documentales [8]. Donut elimina el OCR externo y mapea imágenes a salida estructurada [7]. Nougat convierte páginas científicas a markup preservando semántica perdida en PDF [10]. Esos son modelos aprendidos; el sistema presente orquesta un modelo multimodal general mediante etapas y schemas de negocio.

DocILE es la referencia de benchmark más cercana porque separa extracción de información y reconocimiento de line items, con documentos anotados, baselines y layouts diversos [9]. Los catálogos no son facturas, pero la lección transfiere: hay que identificar line items antes de puntuar campos y reservar layouts no vistos, no mezclar filas del mismo template entre splits.

3. Definición de tarea y unidad de análisis

Sea D un documento con filas fuente ordenadas R. Una anotación gold mapea cada fila válida a cero o un producto normalizado con nombre, marca, categoría, packaging, tipo de precio, monto, unidad y decisión de revisión. Encabezados, totales y términos son no-producto. Una predicción debe identificar primero la fila y después asignar campos. Así no se premian productos plausibles sin origen rastreable.

La unidad es una fila gold anidada en documento. Se reportan macro-promedios por documento y micro-promedios por fila para que una planilla grande no domine. Los campos se puntúan después de emparejar por procedencia. Predicciones sin match son filas inventadas; gold sin match son omisiones.

4. Pipeline implementado de tres etapas

El pipeline valida y sube el archivo, espera estado activo y ejecuta dos etapas documentales antes de normalizar lotes [2]. Stage 1 y 2 usan gemini-3.1-pro; Stage 3 usa gemini-3.1-flash-lite-preview en la revisión registrada. Cada generación solicita JSON con JSON Schema, timeout de 60 s y hasta tres intentos con backoff lineal [2]. Los modelos son sensibles a versión y deben fijarse de nuevo al experimentar.

Stage 2 es la bisagra: el total aplanado debe igualar totalRowCount y cada rowId ser único. Stage 3 agrupa de a diez. Un batchId determinista incluye índice y primer/último rowId; el modelo debe devolver el mismo ID, índice, total, rowIds ordenados y páginas. Un item con sourceRowId fuera del lote rechaza el resultado [2,3].

metadata = stage1(file)
rows = stage2(file, metadata)
assert unique(rows.rowId)
assert flatten(rows).length == rows.totalRowCount
for batch in chunk(rows, 10):
    result = stage3(metadata, batch)
    assert result.context == expected_context(batch)
    assert every(result.item.sourceRowId in batch.rowIds)
    normalize_or_route_to_review(result.items)

5. Procedencia y gates de revisión humana

JSON válido es necesario pero insuficiente. La implementación agrega checks relacionales: rowIds únicos, identidad exacta del lote, pertenencia ordenada, páginas y sourceRowId [2,3]. Previenen respuestas de otro lote, filas estructuralmente válidas pero desalineadas y productos sin origen en el contexto.

El umbral 0,5 es política, no probabilidad calibrada. La autoconfianza del modelo puede derivar. El benchmark debe medir exactitud selectiva: entre ítems auto-aprobados, cuántos son correctos y qué proporción se difiere. Así el gate se vuelve regla evaluada.

6. Reanudación, duplicados y estado operativo

La action valida magic bytes y tamaño, calcula SHA-256 y rechaza duplicados recientes por proveedor [2]. Guarda identidad del archivo, JSON intermedio, progreso, lotes, errores y resultados. Stage 3 puede reanudar desde el primer lote cuyas filas no existen. Los temporales se borran en finally. Estos controles añaden variables experimentales: retries, resumes y duplicados deben aparecer en metadata.

7. Evidencia de software reproducida

Se clonó el repositorio y fijó a5d3aadbfa049f4f6d77a2f144f557fa9bf7cffb. Con Node 24.14.0 y npm 11.9.0, npm ci completó y npm test salió cero. Vitest reportó 20 archivos y 569 tests aprobados en 1,06 s, con 693 ms de tests. El conteo reemplaza para esta revisión la cifra 409 del README [1,5].

git checkout --detach a5d3aadbfa049f4f6d77a2f144f557fa9bf7cffb
npm ci
npm test

El archivo de performance también aprobó cinco tests. Genera 10.000 mocks y empuja IDs a un array, imitando spread de objetos [6]. No llama Convex, red, Gemini ni persiste. Por eso no se usa la interpretación de millones de productos por segundo del documento de decisiones [4]. Solo se sostiene que la simulación y assertions completaron.

8. Diseño del benchmark controlado

El piloto propuesto usa al menos 60 catálogos autorizados: 20 PDF, 20 XLS y 20 XLSX. Se estratifica por layout, filas, multilínea, ambigüedad de packs, unidades mixtas, descuentos y escaneos. Documentos del mismo template quedan en un mismo split. Desarrollo se usa para iterar prompts; test se abre una sola vez.

Cada par documento-condición corre al menos tres veces. La comparación es pareada por documento. Se archivan modelos, prompts, schemas, temperatura, retries y precios. Una falla después de retries cuenta como documento fallido; excluirla sesgaría exactitud y latencia.

1. Definir guía y etiquetar antes de ver outputs.
2. Etiquetar por duplicado al menos 20% y adjudicar.
3. Congelar splits, prompts, schemas, modelos y scorer.
4. Ejecutar condiciones idénticas y registrar retries.
5. Publicar gold redactado, predicciones, matches, agregados y fallas.

9. Métricas y análisis estadístico

Se reportan medias macro por documento con intervalos bootstrap 95%. Para outcomes binarios pareados puede usarse McNemar; para medidas continuas, diferencias bootstrap pareadas. Los campos forman una familia y deben interpretarse con tamaños de efecto, no seleccionando p-values. Los ejemplos se muestrean con taxonomía predeclarada.

10. Taxonomía de error, validez y ética

• Constructo: JSON válido y cantidad de tests no equivalen a exactitud.
• Interna: las etapas usan modelos distintos; una mejora no se atribuye solo a descomposición.
• Externa: catálogos argentinos de alimentos no representan otros sectores.
• Temporal: modelos preview y precios pueden cambiar.
• Anotación: límites de fila y packaging requieren adjudicación documentada.

Los catálogos pueden contener identidades, precios negociados, contactos o términos comerciales. Publicar requiere permiso o redacción irreversible. Hashes, archivos, uploads, logs y ejemplos necesitan política de retención y acceso. Los anotadores deben ver solo lo necesario y el corpus no debe permitir reconstruir combinaciones confidenciales.

11. Conclusión

El sistema contiene una arquitectura razonada: etapas explícitas, generación con schema, identidades de fila y lote, checks de procedencia, reglas de review, retries y estado reanudable. La suite completa es reproducible con 569 tests aprobados. Son resultados legítimos de ingeniería.

La afirmación de research sigue abierta. No hay corpus etiquetado ni comparación de una pasada; no se demostró mejor exactitud. Este protocolo define el experimento faltante y evita sustituir calidad de modelo por volumen de tests o throughput en memoria. Ejecutarlo y liberar resultados es el próximo paso.