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

Viacheslav Dubrov

2026-03-04 · Actualizado 2026-09-06 · 19 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.

Actualización del artículo

Publicado originalmente el 4 de marzo de 2026. Revisado y actualizado el 6 de septiembre de 2026. La actualización añade candidatos más recientes de OCR y modelos de visión, referencias a benchmarks y orientación para interpretar los resultados de extracción documental.

Los leaderboards de OCR no coinciden porque prueban documentos, salidas y jueces diferentes. La tabla versionada del benchmark OmniDocBench y los votos de preferencia en directo de OCR Arena pueden producir ordenaciones distintas; sus puntuaciones no son intercambiables, pero la discrepancia resulta útil. Una decisión para producción necesita documentos y métricas de la carga de trabajo real.

Los modelos de visión y lenguaje (VLMs) pueden gestionar layout, escritura manuscrita, tablas e imágenes degradadas que hacen fallar una pipeline sencilla de reconocimiento de texto. 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 que aparece a continuación incluye PaddleOCR-VL 1.6 y dots.mocr, con distintas compensaciones 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 didácticos y cinco muestras descargadas. Es una demo de smoke testing, no un ranking validado de motores. En la revisión inspeccionada, las etiquetas de Docling no seleccionan de forma fiable la pipeline anunciada, las referencias de reconocimiento de recibos incluyen claves de anotación, los fallos desaparecen de las medias y la petición a Gemini usa gemini-2.5-flash mientras que el notebook la etiqueta como Gemini 3 Flash. Sus métricas ANLS de página completa y sus escenarios de coste también requieren una interpretación separada. Estos defectos de implementación deben corregirse antes de utilizar sus puntuaciones para elegir un modelo.

Para consultar una versión compacta centrada en la selección de modelos, véase Los mejores modelos de OCR en 2026: OCR clásico, PaddleOCR-VL y VLMs.

OCR determina ahora la calidad aguas abajo

OCR lleva mucho tiempo impulsando archivos, sistemas postales, herramientas de accesibilidad y gestión documental. RAG y los agentes documentales 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 tabla que la extracción ha descartado.

La calidad de recuperación de tu sistema RAG está limitada por la calidad de OCR. Si la extracción estropea una tabla, interpreta mal una fecha o elimina un párrafo, los cambios posteriores en chunking y embedding no pueden recuperar la información perdida. Esos 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 recuperación y de agentes, junto con el parsing, el chunking, el embedding y la indexación. Sus errores requieren 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áquina. 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, procedencia y validación. Algunos artículos utilizan «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.

La pipeline tradicional de OCR 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 corrección mediante modelos de lenguaje.

Funciona bien con documentos limpios, pero los errores de detección, reconocimiento y postprocesado pueden acumularse. Mide tanto la precisión de caracteres como la precisión de los campos aguas abajo, para que una página legible no oculte un total o identificador incorrecto.

Algunas rutas VLM end-to-end agrupan una mayor parte de esta 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 esquema solicitado. Las compensaciones dependen de la carga de trabajo: latencia, coste de GPU o API y riesgo de producir texto plausible que no aparece en la imagen.

Advertencia práctica: un modelo que solo recibe imágenes necesita páginas rasterizadas, mientras que un servicio que acepta PDF puede gestionar internamente la conversión. El deskewing, el reescalado y la limpieza son experimentos específicos de la pipeline, no mejoras obligatorias. AWS Textract recomienda conservar las entradas compatibles en lugar de convertirlas o reducir su resolución indiscriminadamente. El parsing y la validación de la salida siguen correspondiendo a la aplicación.

Qué miden y qué omiten los benchmarks de OCR

Los siguientes datasets ilustran cómo las tareas de OCR producen métricas distintas. 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.

El número de líneas de IAM depende del split de escritores elegido y del protocolo de reconocimiento; aquí no se presupone un único número de líneas de test.

La brecha entre «benchmark» y «arena»

Los rankings de benchmarks automatizados pueden entrar en conflicto con las preferencias humanas porque la distribución de entradas y los criterios de evaluación son distintos.

En OCR Arena, los usuarios votan a ciegas entre salidas enfrentadas. Su ordenación en directo cambia a medida que llegan nuevos enfrentamientos, por lo que no es una instantánea histórica reproducible de un benchmark. La tabla versionada de OmniDocBench que aparece más adelante responde a otra pregunta mediante métricas del dataset. No combines ambos leaderboards en una única puntuación.

Entre los factores probables 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 una primera criba, pero la selección final necesita un conjunto reservado de la carga de trabajo objetivo.

Los motores tradicionales de OCR siguen siendo relevantes

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

Los motores tradicionales son buenas baselines porque pueden ejecutarse localmente en CPU. Su latencia y precisión dependen del modelo seleccionado, la resolución de la página, el idioma, el preprocesado y el hardware, así que debes hacer benchmark con las mismas páginas etiquetadas que utilices para evaluar los VLMs.

Tesseract para texto impreso limpio

Tesseract (v5.5.x, Apache 2.0) es un motor maduro, principalmente orientado a CPU, con más de 100 paquetes de idiomas. La precisión con texto impreso limpio puede ser alta tras una rasterización y un preprocesado adecuados, pero la escritura manuscrita, el texto en escenas y los layouts complejos requieren pruebas independientes. Su principal ventaja es un despliegue local pequeño en CPU. El soporte experimental de OpenCL no demuestra una ventaja general de rendimiento.

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 iniciales y texto en escenas.

El fragmento requiere pip install easyocr, PyTorch, los pesos de modelo descargados de EasyOCR y un receipt.jpg local. Tiene la sintaxis comprobada, pero el runner 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 empaqueta pipelines mantenidas de OCR, parsing documental y despliegue. El quick start actual utiliza la API predict() y configuraciones explícitas de orientación. Fija el paquete paddleocr y la pipeline seleccionada, porque los ejemplos de 2.x que utilizan .ocr(..., cls=True) no coinciden con la API de 3.x.

El fragmento requiere pip install "paddleocr>=3,<4", un runtime de PaddlePaddle compatible, pesos de modelo descargados y un receipt.jpg local. Tiene la sintaxis comprobada, pero el runner 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 de VLMs especializados 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 los motores tradicionales.

La nueva generación de OCR especializado

La lista de modelos de esta sección se comprobó el 6 de septiembre de 2026. No es un ranking actual. Entre los modelos especializados de parsing documental publicados entre 2024 y 2026 se incluyen:

• PaddleOCR-VL 1.6: Una pipeline de dos etapas que realiza primero el análisis de layout y después utiliza un componente VLM de 0,9B sobre las regiones detectadas. PaddleOCR indica 109 idiomas y una puntuación de 96,3 en OmniDocBench v1.6; mantén ese resultado del proveedor asociado a la pipeline y a la versión concreta del benchmark.
• dots.mocr (3B): El renombrado de 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 independiente de 2025.
• GOT-OCR 2.0: Un modelo unificado de 580M de parámetros que emite texto plano y formatos estructurados 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 salida 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.1 (mistral-ocr-4-1): Su model card fecha el lanzamiento el 16 de julio de 2026; el changelog registra la disponibilidad general el 31 de agosto. Añade confianza por bloque junto con cajas de párrafo y etiquetas estructurales. Calibra la confianza frente a la corrección de los campos antes de aceptar resultados automáticamente. El identificador OCR 3 del artículo complementario corresponde al contexto histórico de ejecución, no al candidato ni al precio actuales. Fija una versión explícita para las comparaciones; un alias latest puede cambiar.
• Granite-Docling 258M: Emite DocTags que pueden convertirse en un DoclingDocument estructurado. La pipeline VLM de Docling debe seleccionarse explícitamente; que un converter predeterminado exista no demuestra que se haya ejecutado este modelo.
• MinerU y olmOCR: Candidatos para conversión estructurada y linearización documental, respectivamente. Inspecciona sus pipelines completas y las licencias de los modelos seleccionados. Los términos de los modelos de MinerU añaden condiciones a una base Apache 2.0, por lo que la licencia de la librería por sí sola no determina los derechos de despliegue.

VLMs frontier

Los VLMs generales son otra opción cuando la tarea combina extracción con razonamiento visual o semántico. Estos candidatos se comprobaron el 6 de septiembre de 2026 y se utilizan en el ejemplo del gateway que aparece más abajo. Son un punto de partida, no un ranking de OCR:

• Gemini 3.8 Flash (Google): Un modelo multimodal disponible de forma general, con entrada de imagen y structured outputs. Utiliza su ID estable al iniciar una comparación nueva, en lugar del ejemplo antiguo de Gemini 3 Flash Preview.
• Claude Sonnet 5 (Anthropic): Una generación Sonnet más reciente para una comparación alojada. Prueba la fidelidad de transcripción y la extracción de campos con tus propios documentos; las mejoras generales de razonamiento no demuestran precisión de OCR.
• Qwen3.8-27B (Alibaba): Un modelo de visión y lenguaje con pesos abiertos que puede probarse mediante un gateway o autoalojarse. Su tamaño de 27B lo convierte en una opción de despliegue distinta de Qwen3-VL 8B, que sigue siendo una baseline más pequeña útil cuando la memoria está limitada.

Un lanzamiento más reciente merece entrar en el conjunto de pruebas, no ascender automáticamente a producción. Compara la corrección de campos, la abstención, la latencia y el coste por documento aceptado con el mismo protocolo.

Mide la latencia por niveles

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 de salida. Incluye el preprocesado 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 coincida con el tipo de salida:

• 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.
• Field exact match y Field F1 para formularios y recibos. Exact match es binario para un campo; su tasa es la fracción de campos evaluados que superan la prueba. Informa por separado de la corrección de todos los campos a nivel de documento. Para Field F1, define la coincidencia de clave/valor, la normalización, los campos duplicados y ausentes y la agregación; un importe correcto asignado a la fila equivocada es un error.
• 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.
• Comparación del orden de lectura cuando el consumidor necesita una única secuencia lineal. Compara directamente los bloques o spans ordenados, o utiliza una métrica consciente del orden; OmniDocBench evalúa el orden de lectura por separado. Tener caracteres y celdas de tabla correctos no establece el orden de una página con varias columnas.
• ANLS para document VQA. Average Normalized Levenshtein Similarity puntúa las respuestas frente a referencias aceptadas. La definición original de ST-VQA asigna 1 − normalized_distance solo cuando la distancia es estrictamente inferior a 0,5; en caso contrario, asigna cero. Toma la mejor puntuación entre las referencias aceptadas y calcula la media entre preguntas. DocVQA adopta ANLS. Fija la normalización de mayúsculas, espacios y distancia del evaluador al reproducir una puntuación. El artículo complementario puntúa cadenas de página completa e incluye el límite 0,5, por lo que su variante no es el protocolo del benchmark.

CER/WER cuentan sustituciones, eliminaciones e inserciones divididas por los caracteres o palabras de referencia. Pueden superar uno cuando predominan las inserciones. Indica si la agregación suma los errores y las longitudes de referencia del corpus o calcula la media de las puntuaciones documentales. Conserva la página, el bloque, la bounding box, el texto original y el historial de normalización para poder rastrear un campo incorrecto hasta la imagen.

Para las implementaciones: jiwer gestiona CER/WER de serie, y las implementaciones de TEDS están en el repo de OmniDocBench.

Probar VLMs con OpenRouter

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

El fragmento requiere pip install openai, un OPENROUTER_API_KEY, acceso a la red, un receipt.jpg local y model IDs que OpenRouter siga admitiendo. Tiene la sintaxis comprobada, pero el runner 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,
    )
    choice = response.choices[0]
    if choice.finish_reason != "stop":
        raise RuntimeError(f"{model} did not finish: {choice.finish_reason}")
    if not choice.message.content:
        raise RuntimeError(f"{model} returned no text (finish_reason={choice.finish_reason})")
    return choice.message.content

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

El catálogo de modelos de OpenRouter incluía google/gemini-3.8-flash, anthropic/claude-sonnet-5 y qwen/qwen3.8-27b con entrada de imagen y parámetros de structured outputs el 6 de septiembre de 2026. La compatibilidad del catálogo no demuestra que esta petición exacta funcione en todos los endpoints a los que se enrute; no se ejecutó ninguna inferencia de pago para esta actualización.

Para la 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. Con OpenRouter, provider.require_parameters hace que la petición falle cuando ningún endpoint enrutado admite todos los parámetros solicitados, en lugar de recurrir a un endpoint que no pueda respetar el esquema. El siguiente bloque repite su configuración para que pueda leerse de forma independiente. Sigue requiriendo pip install openai, un OPENROUTER_API_KEY, acceso a la red, un receipt.jpg local y un modelo compatible con JSON Schema; el runner del repositorio solo comprueba su 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.8-flash",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Extract only visible receipt fields. Copy amounts as source strings. Use null for absent or unreadable values; do not infer them. Use null for an unreadable item list, and [] only when no items are present."},
            {"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", "null"]},
                    "date": {"type": ["string", "null"]},
                    "items": {
                        "type": ["array", "null"],
                        "items": {
                            "type": "object",
                            "properties": {
                                "description": {"type": ["string", "null"]},
                                "amount": {"type": ["string", "null"]},
                            },
                            "required": ["description", "amount"],
                            "additionalProperties": False,
                        },
                    },
                    "total": {"type": ["string", "null"]},
                },
                "required": ["vendor", "date", "items", "total"],
                "additionalProperties": False,
            },
        },
    },
    extra_body={"provider": {"require_parameters": True}},
)

def completed_text(response, label: str) -> str:
    choice = response.choices[0]
    if choice.finish_reason != "stop":
        raise RuntimeError(f"{label} did not finish: {choice.finish_reason}")
    if not choice.message.content:
        raise RuntimeError(
            f"{label} returned no text (finish_reason={choice.finish_reason})"
        )
    return choice.message.content

receipt = json.loads(completed_text(response, "receipt extraction"))

Conserva las cadenas originales de importes junto a los valores normalizados. Analiza el dinero aguas abajo mediante aritmética decimal o de unidades menores enteras, con una divisa y una configuración regional explícitas; la validez del esquema no valida un total de pago. Deriva a revisión los campos críticos nulos.

Resultados de benchmark: qué muestran realmente las cifras

La tabla siguiente es una instantánea versionada: OmniDocBench v1.6_full, README oficial en el commit 09ba2b606662695b16aafe5f5e36b7ef020e11a8, publicado el 10 de abril de 2026 y consultado el 9 de agosto de 2026. 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. OmniDocBench registró posteriormente la versión v1.7 y la integración con EvalScope. Los cambios en la correspondencia entre predicciones y referencias pueden cambiar las puntuaciones incluso con una salida idéntica del modelo. Conserva las filas históricas anteriores y compara las nuevas ejecuciones únicamente con un evaluador fijado. La métrica compuesta incluye distancia de edición de texto, TEDS de tablas y CDM de fórmulas; el orden de lectura necesita su propio resultado.

El artículo complementario calcula métricas ilustrativas sobre cinco muestras. Corrige la identidad de la pipeline, las referencias de reconocimiento, la contabilización de fallos, los nombres de modelo, el protocolo de métricas y las hipótesis de coste antes de interpretar cualquier fila como evidencia comparativa.

Desplegar OCR en producción

Una arquitectura por niveles puede separar el preprocesado 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 envolvente, y el enrutado también necesita sus propias etiquetas y umbrales de calidad.

El patrón de fallback por niveles

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

0. Comprueba si hay texto incrustado (nivel 0). En PDF, inspecciona la capa de texto con PyMuPDF o pdfplumber antes de rasterizar, pero valida que esté completa y correctamente ordenada.
1. Intenta primero con un modelo rápido. Utiliza un motor tradicional para las clases documentales en las que alcance el objetivo.
2. Evalúa la confianza calibrada. Combina la confianza del modelo con la clase documental, la criticidad del campo y las reglas de validación.
3. Escala a un modelo más potente. Deriva 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 supera el beneficio de la automatización.

Nota sobre la confianza: Las probabilidades de caracteres sin procesar no están calibradas automáticamente respecto a 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 total incorrecto.

def area_weighted_confidence(page):
    """Compute area-weighted confidence from one 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"]
    ):
        width = int(x_max) - int(x_min)
        height = int(y_max) - int(y_min)
        area = width * height
        weighted_sum += score * area
        total_area += area
    return weighted_sum / total_area if total_area > 0 else 0

assert area_weighted_confidence({
    "rec_boxes": [[0, 0, 300, 300]], "rec_scores": [0.5]
}) == 0.5

Para cada par motor/documento previsto, conserva un resultado con estado correcto, erróneo u omitido. Las salidas fallidas, vacías y truncadas siguen formando parte del denominador de documentos intentados, junto con el coste incurrido. Informa de la tasa de finalización, los errores de campos críticos entre las aceptaciones automáticas, la fracción de revisión, la latencia end-to-end p50/p95 y el coste por documento procesado correctamente. Reutiliza los objetos converter para obtener tiempos en caliente y registra la inicialización por separado.

Análisis de costes a escala

No existe un punto de equilibrio universal por volumen de páginas entre una API y el autoalojamiento. Construye la comparación con la misma carga de trabajo:

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, tabla y campos en ambas rutas. Los precios de proveedores y los alquileres de GPUs cambian demasiado deprisa como para incluirlos como una estimación de compras duradera.

Gestión de errores: el problema de las alucinaciones

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

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

Algunas mitigaciones prácticas:

• Conciliación aritmética. Cuando el esquema los exponga, verifica subtotal + tax + fees + shipping - discounts, dentro de la tolerancia de redondeo de la divisa, frente al total indicado. Deriva a revisión los componentes ausentes o las discrepancias.
• Comprobaciones de coherencia con regex para fechas (sin mes 13), números de teléfono (número correcto de dígitos) y formatos de divisa.
• Verificación con varios modelos. Pasa los campos críticos por 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. La coincidencia 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 documental etiquetada. Los motores tradicionales pueden bastar 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 incomparables. Las métricas de OmniDocBench y las preferencias de OCR Arena responden a preguntas distintas.
3. Calibra el enrutado. Los umbrales de confianza, las clases documentales, la criticidad de los campos y la política de revisión humana deben formar parte de una única evaluación.
4. Valida las salidas plausibles. La conformidad con el esquema y la aritmética interna no pueden demostrar que un valor aparezca en la imagen.
5. Calcula el precio por página procesada correctamente. Incluye reintentos, revisión, operaciones fijas y comprobaciones de calidad al comparar APIs con autoalojamiento.

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

Referencias

• OCR Arena Leaderboard - Enfrentamientos de modelos uno contra uno mediante crowdsourcing
• Repositorio de The OCR Gauntlet - Notebooks ejecutables para comparar motores de OCR, inspeccionar la salida de Docling y estimar costes
• OmniDocBench - Evaluación end-to-end de parsing documental
• dots.ocr - Aproximadamente 3B de parámetros totales, incluido un modelo de lenguaje de 1,7B
• PaddleOCR - Toolkit y modelos de OCR tradicional
• OpenRouter - Gateway de acceso unificado para pruebas A/B de modelos