Data ExtractionDocument AILLM API

Extracción de datos con LLM: de PDFs a JSON estructurado (2026)

1 min de lectura

El pipeline de facturas consumió 40,000 documentos el trimestre pasado. El reporte de conciliación se veía perfecto —hasta que alguien notó que el 3% de los campos de proveedor estaban silenciosamente mal: un número de factura transpuesto, una línea de impuesto pegada a la fila equivocada, un símbolo de moneda perdido. Nadie se dio cuenta, porque la extracción no falló. Tuvo éxito, con la respuesta equivocada.

Ese es el horror específico de la extracción de documentos: las fallas son silenciosas. No hay un error 500 cuando un campo del schema vuelve vacío-pero-validado, no hay excepción cuando una columna de tabla se desplaza. La extracción de datos con LLMs es una de las cargas de mayor valor de los LLMs en 2026 —facturas, contratos, formularios, reclamos— y una de las más engañosas en los benchmarks, porque los benchmarks de los proveedores los escriben los proveedores, sobre documentos que favorecen a sus parsers.

Esta guía cubre el pipeline de extracción de punta a punta —parse, schema, extracción, validación— con la pregunta honesta del benchmark (solo-LLM vs proveedores de parsing vs open source, sobre tus documentos), el diseño de schema que previene la corrupción silenciosa, el manejo de PII que lo mantiene legal y el modelo de costo por 1,000 documentos.

Qué implica realmente la extracción de documentos

En resumen: la extracción es una cadena de cinco etapas —parsing, comprensión, esquematización, extracción, validación— y cualquier etapa puede fallar en silencio.

PDF → 1. Parse (layout, tables, OCR) → 2. Understand (vision or text)
        → 3. Schema (what fields, what types) → 4. Extract (LLM)
        → 5. Validate (types, required, confidence) → JSON

La cadena es tan fuerte como su etapa más débil, y las etapas fallan de forma distinta: el parsing se rompe en diseños escaneados y multi-columna, la comprensión se rompe con contenido rotado o con marcas de agua, el schema se rompe cuando faltan campos y nadie lo nota, y la validación se rompe cuando directamente no se implementa. El trabajo del pipeline es hacer que cada falla sea ruidosa en lugar de silenciosa.

Por qué falla la extracción en producción

En resumen: tres clases de falla —errores de parsing, deriva de schema y validación ausente— y solo una de ellas aparece en los logs.

  1. Fallos de parsing. Documentos escaneados sin OCR, tablas leídas como sopa de texto, diseños multi-columna aplanados en un orden basura. El parser determina el techo; el LLM no puede extraer lo que el parser destruyó.
  2. Deriva de schema. Los documentos cambian —aparece un campo nuevo, un proveedor cambia su plantilla— y el schema se queda fijo. Las extracciones devuelven silenciosamente campos faltantes que pasan la validación porque “faltante” no era una regla.
  3. Validación ausente. Sin chequeos de tipo, sin reglas de campos requeridos, sin puntaje de confianza. El pipeline devuelve JSON, y un JSON que se ve bien pero no lo está es peor que ningún JSON: alimenta los sistemas río abajo con mentiras plausibles.

Las propias comparaciones de la industria —como el duelo de parsers 2026 de pdfmux— muestran de forma consistente que la elección del parser mueve la precisión más que la elección del modelo. Esa es la primera lección: haz el benchmark del parser sobre tus documentos antes de hacer el del modelo.

La prueba neutral: solo-LLM vs parsers vs open source

En resumen: corre la prueba a tres bandas sobre tu propio corpus —documentos simples de texto, escaneos desordenados y tablas— porque el ranking se invierte según el tipo de documento.

El panorama de 2026 tiene tres familias:

  • Solo-LLM —alimenta el documento (texto o imagen) directo a un modelo multimodal. Funciona en PDFs digitales limpios; se degrada con la complejidad del diseño.
  • Proveedores de parsing —LlamaParse, Unstructured y similares, que normalizan el diseño antes del LLM. Los líderes de los benchmarks en documentos complejos, a un costo por página.
  • Open source —Docling, Marker y los modelos más nuevos especializados en extracción como NuExtract3 (un modelo visión-lenguaje abierto de 4B construido para extracción estructurada, auto-hospedable según la estructura de precios de NuExtract). Control y techo de costo, al precio de las operaciones.

La prueba que lo resuelve: tres conjuntos de documentos —digital limpio, escaneado, con muchas tablas— por las tres familias, medidos en precisión a nivel de campo (no coincidencia de “se parece”), costo por 1,000 documentos y tasa de falla. La predicción honesta: solo-LLM gana el conjunto limpio, los proveedores ganan el escaneado y el open source gana la columna de costo a volumen —y tu corpus decide qué columna importa.

Cómo ensamblar el pipeline: Parse → Schema → Extract → Validate

En resumen: el diseño del schema es la etapa de mayor apalancamiento —un schema estricto con validación convierte la extracción de una esperanza en un contrato.

El bucle central, agnóstico de proveedor —sobre un endpoint de chat unificado:

import json
from openai import OpenAI

client = OpenAI()  # unified endpoint

SCHEMA = {  # the contract: required fields fail loudly
    "type": "object",
    "required": ["invoice_number", "vendor", "total"],
    "properties": {
        "invoice_number": {"type": "string"},
        "vendor": {"type": "string"},
        "total": {"type": "number"},
        "currency": {"type": "string", "enum": ["USD", "EUR", "GBP"]},
    },
}

def extract(page_text: str) -> dict:
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        response_format={"type": "json_schema", "json_schema": {"name": "invoice", "schema": SCHEMA}},
        messages=[{"role": "user", "content": f"Extract the invoice data as JSON:\n{page_text}"}],
    )
    return json.loads(resp.choices[0].message.content)

def validate(doc: dict) -> tuple[bool, list[str]]:
    errors = []
    for field in SCHEMA["required"]:
        if field not in doc or doc[field] in (None, ""):
            errors.append(f"missing required field: {field}")
    if not isinstance(doc.get("total"), (int, float)):
        errors.append("total is not a number")
    return (not errors, errors)

Cuatro reglas que lo hacen de nivel producción:

  1. El schema es un contrato. Campos requeridos, enums y tipos —aplicados por el modo de salida estructurada de tu modelo (el patrón documentado en esta serie)— para que “faltante” sea un error en lugar de una clave ausente.
  2. Parsea antes de hacer el prompt. Los PDFs digitales van directo al LLM; los documentos escaneados pasan por OCR o por un modelo multimodal. El catálogo de modelos te dice qué modelos aceptan imágenes; la regla de decisión es “¿puede el parser ver el texto?”.
  3. Confianza y colas. Cada extracción recibe un puntaje de confianza; las filas de baja confianza van a una cola de revisión humana en lugar de a la base de datos. La cola es lo que hace ruidosa la “falla silenciosa” —y las fallas reintentables se mapean a la referencia de códigos de error.
  4. PII en ambos extremos. Redacta antes de extraer cuando sea posible, escanea después —el manejo de datos personales es un requisito de cumplimiento, no un lujo del pipeline, y aplica el checklist estándar de privacidad de datos.

Cómo escalar y reducir costos

En resumen: el costo por 1,000 documentos es un número de diseño —el tiering por complejidad del documento y el batching por volumen suelen recortarlo a la mitad o más.

El modelo de costos: costo por 1,000 documentos = costo de parsing (si lo hay) + tokens del modelo × tarifa del modelo. Las palancas:

  1. Haz tiering por complejidad del documento. Los documentos digitales limpios corren en modelos económicos; los escaneados o con muchas tablas corren por el camino caro. La mayoría de los pipelines son 70-80% limpios, lo que significa que 70-80% del volumen paga tarifas económicas —el routing personalizado hace mecánica la decisión por documento.
  2. Haz batching del backlog. Los dumps históricos de documentos son la carga batch perfecta —toleran retrasos, son de alto volumen y el patrón de descuento por batch de esta serie aplica el 50% de descuento sin cambios.
  3. Cachea la plantilla. Mismo proveedor, misma plantilla = mismo prefijo de prompt. Los prefijos estables alcanzan el precio de caché, lo que importa más en extracción que en casi cualquier otra cosa, porque las plantillas se repiten miles de veces.
  4. Construir vs comprar el parser. Los proveedores cobran por página; el open source cobra por hora de GPU. El análisis de TCO de esta serie muestra la forma: lo administrado gana por debajo de los umbrales de volumen, el open source gana por encima, y el umbral depende de tu apetito por operaciones.

Errores comunes que corrompen datos en silencio

En resumen: cuatro patrones de corrupción silenciosa —cada uno produce datos incorrectos que parecen plausibles.

  1. Schema sin validación. Un schema es una descripción, no una puerta. Sin chequeos de tipo ni reglas de campos requeridos, la extracción “ligada al schema” sigue devolviendo campos vacíos que pasan como datos.
  2. Saltarse el OCR en documentos escaneados. Sopa de texto adentro, JSON basura afuera —el fallo del parser está río arriba del modelo, y ningún prompt lo arregla.
  3. Sin seguimiento de versión del modelo. Los upgrades de modelo cambian el comportamiento de extracción; sin versiones fijadas y un corpus de regresión, “el modelo mejoró” se convierte silenciosamente en “los campos se desplazaron”. Versiona el string del modelo y el schema juntos.
  4. Todo-frontera, todo el tiempo. Documentos limpios en el modelo insignia es la forma más cara de no mejorar la precisión —haz tiering por complejidad y gasta el ahorro en la cola de revisión.

FAQ

¿Puedo extraer de PDFs solo con un LLM?

PDFs digitales limpios, sí. Los documentos escaneados y los diseños complejos necesitan OCR o un modelo multimodal primero —el parser determina el techo, y el LLM extrae dentro de él.

¿Cómo mido la precisión de extracción con honestidad?

Coincidencia a nivel de campo (campo exacto, tipo exacto, valor exacto) contra una muestra etiquetada a mano, por tipo de documento —más los errores de validación de tipos y campos requeridos como métrica separada. La coincidencia de “se parece” produce el problema del 3% incorrecto en silencio que esta guía existe para prevenir.

¿Cuánto cuesta la extracción por 1,000 documentos?

Costo de parsing (si lo hay) más los tokens del modelo a tu nivel —los modelos económicos sobre documentos limpios corren muy por debajo de los modelos insignia sobre escaneados. Haz tiering por complejidad y el promedio colapsa; haz batching del backlog y se reduce a la mitad otra vez.

¿Cómo debería diseñar el schema?

Campos requeridos, enums y tipos —aplicados a través de la salida estructurada, tratando el campo requerido faltante como un error. El schema es el contrato entre los documentos y tu base de datos, y merece la misma revisión que ambos.

¿Necesito un proveedor de parsing, o el open source es suficiente?

Corre la prueba a tres bandas sobre tu corpus. Los proveedores lideran en diseños complejos; el open source (Docling, Marker, modelos especializados en extracción como NuExtract3) gana en costo y control a volumen. El umbral de TCO es real y medible.

¿Cómo manejo el PII en la extracción?

Redacta antes de extraer cuando sea posible, escanea la salida después y mantén la retención mínima —los requisitos estándar de privacidad de datos aplican a los datos extraídos exactamente como aplican a los documentos fuente.

Resumen

La extracción de datos con LLMs es una disciplina de pipeline, no una propiedad del modelo: parsea deliberadamente, define el schema como contrato, extrae dentro de él y valida todo para que las fallas sean ruidosas. Haz el benchmark del parser sobre tus documentos antes que el del modelo, haz tiering por complejidad del documento, haz batching del backlog y trata la cola de revisión como una funcionalidad. Bien hecha, la extracción es la carga de alto volumen más confiable del stack de LLMs; mal hecha, son datos incorrectos plausibles alimentando tu base de datos.

Corre 100 páginas por el pipeline antes de discutir con el benchmark. Obtén tu API key de TokSpan —$5 en créditos gratis para correr la muestra (quickstart)— y mira los costos por documento sobre tus propias facturas.