OCR en 2026: pipelines clásicos, VLMs y Document AI

Viacheslav Dubrov

2026-03-04 · Actualizado 2026-08-10 · 16 min · Sistemas de recuperación y lenguaje

Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Los leaderboards de OCR no coinciden porque evalúan documentos, outputs y jueces diferentes. Una instantánea de principios de 2026 de OmniDocBench y OCR Arena produjo ordenaciones de modelos muy distintas; las puntuaciones no son intercambiables, pero el desacuerdo resulta útil. Para elegir en producción hacen falta documentos y métricas del workload real.

Los modelos vision-language (VLMs) pueden gestionar layout, escritura manuscrita, tablas e imágenes degradadas que hacen fallar un pipeline de reconocimiento de texto convencional. Los motores tradicionales siguen siendo competitivos con texto impreso limpio, especialmente cuando importan la latencia en CPU y el coste operativo. La instantánea fechada de abajo incluye PaddleOCR-VL 1.6 y dots.mocr, con distintos compromisos en hardware, privacidad y formato de salida. Comprueba cada proyecto antes de tomar una decisión actual.

Repositorio complementario: The OCR Gauntlet contiene tres notebooks. Su notebook principal compara hasta cinco motores de OCR sobre cinco muestras descargadas e informa de CER, WER, ANLS, latencia y coste estimado. La ejecución incluida en el repositorio contiene Tesseract, Docling + Tesseract, Mistral OCR v3 y una ejecución con Gemini; dots.ocr no estaba disponible. No uses la fila de Gemini para comparar modelos: el runner solicita gemini-2.5-flash, pero el notebook incluido etiqueta ese output como Gemini 3 Flash.

Esta guía está dirigida a ingenieros que eligen un pipeline de OCR o de Document AI para workloads reales en los que importan el texto, el layout, las tablas o los campos extraídos.

Después de leerla, deberías poder elegir una baseline, comparar modelos con métricas específicas de la tarea y enrutar los campos inciertos o de alto riesgo a validación o revisión.

Para consultar la versión resumida de selección de modelos, ve a Best OCR Models in 2026: Classical OCR, PaddleOCR-VL, VLMs.

OCR determina ahora la calidad de los sistemas posteriores

OCR lleva mucho tiempo impulsando archivos, sistemas postales, herramientas de accesibilidad y gestión documental. RAG y los agentes de documentos han hecho visibles sus modos de fallo para un grupo más amplio de ingenieros: un modelo posterior no puede recuperar el texto o la estructura de una tabla que la extracción haya descartado.

La calidad de retrieval de tu sistema RAG está limitada por la calidad de OCR. Si la extracción destroza una tabla, interpreta mal una fecha o elimina un párrafo, ni el chunking ni los cambios en embeddings posteriores pueden recuperar la información perdida. Estos errores pueden ocultar una cláusula contractual, cambiar el total de una factura o corromper una historia clínica.

Por tanto, OCR forma parte de la infraestructura de retrieval y de agentes, junto con el parsing, el chunking, los embeddings y la indexación. Sus errores necesitan una evaluación propia, en lugar de quedar absorbidos en una única puntuación end-to-end.

Qué significa OCR en la era de los foundation models

OCR convierte el texto de una imagen en caracteres legibles por máquinas. Document AI es el sistema más amplio que lo rodea: análisis de layout, parsing de tablas y fórmulas, extracción de campos, razonamiento semántico, provenance y validación. Algunos artículos usan «OCR-2.0» para modelos end-to-end que combinan varias de estas etapas, pero esa etiqueta no debería borrar la distinción entre reconocimiento y comprensión documental.

El pipeline de OCR tradicional tiene tres etapas principales:

1. Detección de texto: localizar las regiones que contienen texto (por ejemplo, CRAFT, DBNet).
2. Reconocimiento de texto: convertir las regiones detectadas en secuencias de caracteres (por ejemplo, CRNN).
3. Postprocesado: corrección ortográfica y mediante modelos de lenguaje.

Este enfoque funciona bien con documentos limpios, pero los errores de detección, reconocimiento y postprocesado pueden acumularse. Mide tanto la precisión a nivel de carácter como la precisión de los campos posteriores para que una página legible no oculte un total o identificador incorrectos.

OCR-2.0 agrupa una parte mayor de ese pipeline en un encoder visual y un decoder de lenguaje. Modelos como GOT-OCR 2.0 pueden emitir texto y estructura conjuntamente, mientras que los VLMs generales también pueden asignar campos a un schema solicitado. Los trade-offs dependen del workload: latencia, coste de GPU o API y riesgo de generar texto plausible que no aparece en la imagen.

Una salvedad práctica: no dejes que la etiqueta «end-to-end» te engañe. En producción, OCR-2.0 unifica la inferencia del modelo, no todo el pipeline documental. Sigues necesitando rasterización de PDF para producir imágenes, normalización de imagen (deskew, ajuste de DPI) para mantener una calidad coherente y parsing del output para extraer campos estructurados del texto del modelo. El pipeline se ha acortado, no ha desaparecido.

Qué miden y qué omiten los benchmarks de OCR

Los siguientes datasets muestran cómo las tareas de OCR producen métricas diferentes. Los tamaños y las métricas describen la versión indicada de cada dataset; utiliza el leaderboard actual de cada proyecto para consultar las puntuaciones de los modelos.

La brecha entre «benchmark» y «arena»

Las clasificaciones de benchmarks automatizados pueden entrar en conflicto con la preferencia humana porque la distribución de entradas y los criterios de evaluación son diferentes.

En OCR Arena, los usuarios votan a ciegas entre outputs enfrentados. El 2026-08-09, su ordenación en directo situaba Gemini 3 Flash por encima de GLM-OCR y DeepSeek-OCR, mientras que la tabla versionada de OmniDocBench que aparece más adelante en este artículo clasificaba los modelos especializados de documentos por encima de Gemini 3 Flash. Los valores de la arena cambian después de nuevas batallas, por lo que la ordenación es evidencia direccional, no una instantánea reproducible de benchmark. Los dos leaderboards no deben combinarse en una única puntuación porque uno usa métricas de dataset y el otro votos de preferencia.

Entre los factores determinantes probablemente están la mezcla de documentos, el formato de salida, la cobertura lingüística y los criterios del juez. Las cifras publicadas son útiles para hacer un primer filtro, pero la selección final necesita un conjunto retenido del workload objetivo.

Motores de OCR tradicionales: siguen siendo relevantes

Si los motores tradicionales son peores con datos complejos, ¿por qué utilizarlos? Porque son rápidos y baratos con datos estructurados y limpios.

Los motores tradicionales son baselines útiles porque pueden ejecutarse localmente en CPU. Su latencia y precisión dependen del modelo elegido, la resolución de la página, el idioma, el preprocessing y el hardware, así que debes evaluarlos con las mismas páginas etiquetadas que uses para evaluar los VLMs.

Tesseract para texto impreso limpio

Tesseract (v5.5.x, Apache 2.0) es un motor maduro que funciona únicamente en CPU y dispone de más de 100 paquetes de idiomas. La precisión con texto impreso limpio puede ser alta tras una rasterización y un preprocessing adecuados, pero la escritura manuscrita, el texto en escenas y los layouts complejos requieren pruebas específicas. Su principal ventaja es un despliegue local pequeño en CPU, no una superioridad universal en precisión.

EasyOCR

EasyOCR combina un detector CRAFT con un reconocedor CRNN. Con aceleración completa de GPU mediante PyTorch, es una opción rápida para prototipos ágiles y texto en escenas.

El fragmento requiere pip install easyocr, PyTorch, los pesos del modelo de EasyOCR descargados y un receipt.jpg local. Se ha comprobado sintácticamente, pero el runner de Markdown del repositorio no lo ejecuta.

import easyocr

# Three lines for complete OCR
reader = easyocr.Reader(["en"])
result = reader.readtext("receipt.jpg")
# Returns: [(bbox, text, confidence), ...]

PaddleOCR 3

PaddleOCR 3 agrupa pipelines mantenidos de OCR, parsing documental y despliegue. El quick start actual utiliza la API predict() y ajustes explícitos de orientación. Fija el paquete paddleocr y el pipeline seleccionado, porque los ejemplos de 2.x que usan .ocr(..., cls=True) no coinciden con la API de 3.x.

El fragmento requiere pip install "paddleocr>=3,<4", un runtime de PaddlePaddle compatible, los pesos del modelo descargados y un receipt.jpg local. Se ha comprobado sintácticamente, pero el runner de Markdown del repositorio no lo ejecuta.

from paddleocr import PaddleOCR

ocr = PaddleOCR(
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_textline_orientation=False,
)

for result in ocr.predict("receipt.jpg"):
    result.print()
    result.save_to_json("output")

Opciones VLM especializadas y generales

Los recibos torcidos, las etiquetas de productos inclinadas, la escritura manuscrita y los layouts densos son los casos en los que merece la pena probar VLMs especializados o generales frente a motores tradicionales.

La oleada de OCR especializado

La lista de modelos de esta sección corresponde a la instantánea comprobada el 2026-08-09. No es una clasificación actual. Entre los modelos especializados de parsing documental publicados entre 2024 y 2026 se incluyen:

• PaddleOCR-VL 1.6: un pipeline en dos etapas que realiza primero el análisis de layout y después utiliza un componente VLM de 0,9B en las regiones detectadas. PaddleOCR informa de 109 idiomas y una puntuación de 96,3 en OmniDocBench v1.6; conserva ese resultado del proveedor asociado al pipeline y a la versión de benchmark indicados.
• dots.mocr (3B): el sucesor, publicado en marzo de 2026, de dots.ocr-1.5 analiza texto y gráficos estructurados, incluida una variante orientada a SVG. El dots.ocr original sigue siendo un modelo diferente de 2025.
• GOT-OCR 2.0: un modelo unificado de 580M de parámetros que emite texto plano y outputs formateados como Markdown y LaTeX. Su repositorio oficial no publica una cifra mínima de VRAM, así que mide la memoria máxima con el runtime, la precisión, el tamaño de imagen y el límite de output elegidos.
• DeepSeek-OCR2: el checkpoint documentado en el repositorio oficial en la fecha de la instantánea, sucesor del modelo original DeepSeek-OCR de clase 3B que introdujo la «compresión óptica contextual». Trata las cifras de throughput de cualquiera de las dos generaciones como específicas del hardware y del dataset.
• Mistral OCR 4.0 (mistral-ocr-4-0), instantánea de 2026-08-09: el servicio propietario de extracción de texto y estructura documentado por Mistral. OCR 3 (mistral-ocr-2512) sigue disponible para integraciones existentes y es la versión utilizada por el notebook complementario. El complemento utiliza OCR 3 deliberadamente por reproducibilidad, no porque OCR 3 sea más reciente. Los precios y las cifras de benchmark cambian, así que consulta la model card actual y las condiciones del proveedor al compararlos.

VLMs frontier

Los VLMs generales son otra opción cuando la tarea combina extracción con razonamiento visual o semántico. Los ejemplos siguientes reflejan la instantánea del artículo de principios de 2026, no una clasificación actual:

• Qwen3-VL (Alibaba): una familia de VLMs con pesos abiertos, varios tamaños y variantes de contexto largo.
• Gemini 3 Flash (Google): un modelo multimodal alojado que obtuvo una clasificación alta en la instantánea citada de OCR Arena.
• Claude Opus 4.6 (Anthropic): un VLM general alojado con soporte para structured outputs.
• GPT-5.2 (OpenAI): un VLM general alojado para entradas visuales y textuales combinadas.

Mide la latencia por nivel

Mide la latencia por página con la resolución real, el tamaño de batch, el hardware o la región del proveedor y la longitud del output. Incluye el preprocessing y los reintentos en el total; medir solo el modelo no permite calcular el coste de una página procesada correctamente.

Métricas: medir lo que importa

Elige una métrica que corresponda al tipo de output:

• CER y WER para texto plano. Character Error Rate y Word Error Rate dependen de decisiones de normalización como mayúsculas, espacios y puntuación, así que fija el protocolo de comparación antes de comparar modelos.
• EMR y Field F1 para formularios y recibos. Exact Match Rate es binario, que es justo lo que necesitas para identificadores fiscales y totales. Field F1 equilibra precisión y recall por tipo de campo.
• TEDS para tablas. Tree-Edit-Distance-based Similarity compara los árboles HTML predichos y de referencia, y detecta errores estructurales y de contenido de celdas que CER oculta.
• ANLS para document VQA. Average Normalized Levenshtein Similarity concede crédito parcial a respuestas con errores menores de OCR.

Para las implementaciones: jiwer gestiona CER/WER de forma inmediata, y las implementaciones de TEDS se encuentran en el repositorio de OmniDocBench.

Probar VLMs con OpenRouter

OpenRouter proporciona un gateway compatible con OpenAI para modelos de varios proveedores. Los IDs de modelo y las funcionalidades de request compatibles cambian, así que verifícalos en el catálogo actual del gateway antes de ejecutar el ejemplo.

El fragmento requiere pip install openai, una OPENROUTER_API_KEY, acceso a red, un receipt.jpg local y IDs de modelos que OpenRouter siga admitiendo. Se ha comprobado sintácticamente, pero el runner de Markdown del repositorio no lo ejecuta.

import base64
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

def extract_text(image_path: str, model: str) -> str:
    with open(image_path, "rb") as f:
        image_b64 = base64.b64encode(f.read()).decode()

    response = client.chat.completions.create(
        model=model,
        messages=[{
            "role": "user",
            "content": [
                {"type": "text", "text": "Extract all text from this image, preserving layout as markdown."},
                {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}},
            ],
        }],
        max_tokens=4096,
    )
    return response.choices[0].message.content

# Compare models by changing one string
models = [
    "google/gemini-3-flash-preview",
    "anthropic/claude-sonnet-4.5",
    "qwen/qwen3-vl-8b-instruct",
]
for model in models:
    print(f"\n--- {model} ---\n{extract_text('receipt.jpg', model)[:200]}...")

Estos IDs de modelo se comprobaron en el catálogo de OpenRouter el 2026-08-09. Vuelve a consultar el catálogo antes de ejecutar el ejemplo.

Para extracción estructurada, utiliza response_format con un JSON Schema cuando el modelo y el gateway seleccionados lo admitan. Esto puede hacer que la respuesta sea parseable; no valida los valores extraídos frente a la imagen. El bloque siguiente repite su configuración para que pueda leerse de forma independiente. También requiere pip install openai, una OPENROUTER_API_KEY, acceso a red, un receipt.jpg local y un modelo compatible con JSON Schema; el runner del repositorio solo comprueba la sintaxis.

import base64
import json
import os
from openai import OpenAI

with open("receipt.jpg", "rb") as f:
    image_b64 = base64.b64encode(f.read()).decode()

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

response = client.chat.completions.create(
    model="google/gemini-3-flash-preview",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Extract the receipt fields from this image."},
            {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}},
        ],
    }],
    max_tokens=4096,
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "receipt",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "vendor": {"type": "string"},
                    "date": {"type": "string"},
                    "items": {
                        "type": "array",
                        "items": {
                            "type": "object",
                            "properties": {
                                "description": {"type": "string"},
                                "amount": {"type": "number"},
                            },
                            "required": ["description", "amount"],
                            "additionalProperties": False,
                        },
                    },
                    "total": {"type": "number"},
                },
                "required": ["vendor", "date", "items", "total"],
                "additionalProperties": False,
            },
        },
    },
)
receipt = json.loads(response.choices[0].message.content)

Resultados del benchmark: qué muestran realmente las cifras

La tabla siguiente es una instantánea versionada: OmniDocBench v1.6_full, README oficial en el commit 09ba2b606662695b16aafe5f5e36b7ef020e11a8, publicada el 2026-04-10 y consultada el 2026-08-09. Las cuatro filas proceden de esa tabla fijada. La tabla no mezcla valores de tablas de artículos anteriores ni de otros leaderboards.

La conclusión se limita a esta versión de OmniDocBench: el tamaño del modelo, por sí solo, no predice la puntuación de parsing documental.

El notebook complementario calcula CER, WER, ANLS, latencia y coste estimado sobre sus cinco muestras descargadas. Excluye su fila de Gemini etiquetada incorrectamente, salvo que se corrija la identidad del modelo y se vuelvan a ejecutar las muestras.

Desplegar OCR en producción

!!! byte «Byte dice»

Confié en la capa de texto embebida de un lote de PDFs. Todos los caracteres eran correctos, pero estaban en el orden equivocado, así que todas las tablas se convirtieron en un sinsentido.

Una arquitectura por niveles puede separar el preprocessing en CPU de la inferencia en GPU o API y reservar las rutas costosas para los documentos que las necesiten.

Nota sobre la orquestación: Herramientas como Docling pueden coordinar la conversión y el procesamiento por lotes. La política de reintentos sigue correspondiendo a la aplicación o servicio circundante, y el routing sigue necesitando sus propias etiquetas y umbrales de calidad.

Patrón de fallback por niveles

Empieza por la ruta más barata que alcance el objetivo de calidad y calibra después el routing con páginas etiquetadas:

0. Comprueba si hay texto embebido (nivel 0). En PDFs, inspecciona la capa de texto con PyMuPDF o pdfplumber antes de rasterizar, pero valida que la capa esté completa y correctamente ordenada.
1. Intenta el procesamiento con un modelo rápido. Utiliza un motor tradicional para las clases de documentos en las que alcance el objetivo.
2. Evalúa la confianza calibrada. Combina la confianza del modelo con la clase de documento, la criticidad del campo y las reglas de validación.
3. Escala a un modelo más potente. Enruta las páginas inciertas a un VLM especializado o general.
4. Escala los fallos de alto riesgo a una persona. La revisión humana es un nivel independiente para valores cuyo coste de error supere el beneficio de la automatización.

Nota sobre la confianza: Las probabilidades de carácter sin más no están calibradas automáticamente para la corrección de los campos. La función ponderada por área siguiente es una baseline para la agregación a nivel de página, no un router universal. Calíbrala con páginas etiquetadas y asigna reglas propias a los campos críticos, porque una media de página puede ocultar un ID o un total incorrectos.

def area_weighted_confidence(page):
    """Compute area-weighted confidence from a PaddleOCR 3.x result."""
    total_area, weighted_sum = 0, 0
    for (x_min, y_min, x_max, y_max), score in zip(
        page["rec_boxes"], page["rec_scores"]
    ):
        area = (x_max - x_min) * (y_max - y_min)
        weighted_sum += score * area
        total_area += area
    return weighted_sum / total_area if total_area > 0 else 0

Análisis de costes a escala

No existe un punto de equilibrio universal, en volumen de páginas, entre una API y el self-hosting. Construye la comparación a partir del mismo workload:

Utiliza una fórmula común: monthly pages × cost per successful page + review cost + fixed operating cost. Una «página procesada correctamente» debe cumplir los mismos criterios de texto, tablas y campos en ambas rutas. Los precios de los proveedores y el alquiler de GPUs cambian demasiado rápido como para incluirlos en una estimación de compras duradera.

Gestión de errores: el problema de las alucinaciones

Los errores de los VLMs pueden ser plausibles en su contexto y, aun así, fácticamente incorrectos. Un total de recibo de «$42.50» podría convertirse en «$45.20»: es sintácticamente válido, pero invisible para un corrector ortográfico.

Ejemplo de fallo sintético: un VLM extrae tres líneas de artículos de un recibo y un total declarado que son coherentes entre sí, pero uno de los dígitos difiere de la imagen. La aritmética interna pasa, aunque la extracción sea incorrecta. Por eso la validación necesita etiquetas fundamentadas en la imagen o una ruta de revisión independiente, no solo comprobaciones de consistencia.

Algunas medidas prácticas:

• Reconciliación aritmética. Cuando el schema los exponga, verifica subtotal + tax + fees + shipping - discounts, dentro de la tolerancia de redondeo de la divisa, frente al total declarado. Enruta a revisión los componentes que falten o las discrepancias.
• Comprobaciones de sensatez con regex para fechas (sin mes 13), números de teléfono (número correcto de dígitos) y formatos de divisa.
• Verificación entre modelos. Procesa los campos críticos con dos modelos diferentes y marca las discrepancias.
• Comprobación cruzada con OCR independiente. Ejecuta una segunda ruta de extracción sobre las cifras críticas y marca las discrepancias. El acuerdo aumenta la confianza solo cuando ambas rutas tienen modos de fallo suficientemente distintos; no demuestra que el resultado sea correcto.

Conclusiones clave

1. Ajusta el nivel del modelo a una clase de documentos etiquetada. Los motores tradicionales pueden ser suficientes para texto limpio; los VLMs especializados y generales deben justificar su coste adicional en las páginas más difíciles.
2. No mezcles leaderboards que no son comparables. Las métricas de OmniDocBench y las preferencias de OCR Arena responden a preguntas diferentes.
3. Calibra el routing. Los umbrales de confianza, las clases de documentos, la criticidad de los campos y la política de revisión humana deben formar parte de una misma evaluación.
4. Valida los outputs plausibles. La conformidad con el schema y la aritmética interna no pueden demostrar que un valor aparezca en la imagen.
5. Calcula el coste por página procesada correctamente. Incluye reintentos, revisión, operaciones fijas y quality gates al comparar APIs con self-hosting.

El preprocessing y la detección siguen siendo importantes, pero el OCR en producción también requiere routing, evaluación específica de la tarea y defensas contra errores de extracción plausibles.

Referencias

• OCR Arena Leaderboard - Batallas de modelos crowdsourced y uno contra uno
• The OCR Gauntlet repo - Notebooks ejecutables para comparar motores de OCR, inspeccionar el output de Docling y estimar costes
• OmniDocBench - Evaluación end-to-end de parsing documental
• dots.ocr - Aproximadamente 3B parámetros en total, incluido un modelo de lenguaje de 1,7B
• PaddleOCR - Toolkit y modelos de OCR tradicional
• OpenRouter - Gateway de acceso unificado para hacer A/B testing de modelos