Benchmarks de precisión

Actualización del motor OCR: PP-OCRv5 → PP-OCRv6

Medido el 2026-07-09 en una GPU RTX 3090 local que ejecuta la imagen de producción (paddleocr==3.7.0, CUDA 12.9). Material evaluado: un documento HEIC real de 24 MP tomado con cámara (texto en polaco, referencia transcrita por una persona) y los PDF de factura y recibo de ejemplo del repositorio (referencia de pdftotext). La puntuación usa recuperación y precisión de multiconjuntos sin tener en cuenta el orden.

La configuración desplegada es PP-OCRv6 medium con text_det_box_thresh=0.5. El umbral inferior de cuadros recupera líneas tenues de zonas con brillo o perspectiva en fotos de cámara (+20 puntos de recuperación de palabras), sin regresión en páginas limpias renderizadas.

La recuperación de palabras en páginas impresas renderizadas (PDF de facturas y recibos) es 1.000 en ambas versiones del motor — la mejora se concentra en fotos de cámara, donde la perspectiva, el brillo y la compresión exigen más al detector. La recuperación numérica (importes, fechas e identificadores) es el indicador más próximo de la precisión de extracción de campos, ya que los campos se emparejan a partir de esos tokens.

Motor fotográfico: preprocesamiento de documentos de cámara

Medido el 2026-07-09 (mismo hardware e imagen que la prueba del motor OCR). El motor fotográfico aplica corrección geométrica y clasificación de orientación a las cargas de cámara antes del OCR. Se decidió habilitarlo solo para cargas IMAGE — aplicarlo a páginas renderizadas que ya son planas reduce la recuperación de palabras de 1.000 a 0.635 al distorsionar píxeles alineados.

La mejora de la corrección geométrica es real, pero requiere que el servicio OCR devuelva la imagen de página transformada para que los cuadros delimitadores se dibujen en el espacio de coordenadas correcto (transformado). La restricción a fotos evita la regresión en páginas densas. La función está controlada por la variable de entorno OCR_PHOTO_TRANSFORMS_ENABLED.

Detección de separación de PDF con múltiples facturas

Medido el 2026-07-21 mediante el conjunto de evaluación sintético y etiquetado generado por scripts/gen_split_eval.py y puntuado por scripts/eval_doc_split.py. El detector usa la capa de texto incrustada (pdftotext) para encontrar señales de límite de página (cabeceras de factura, patrones de etiquetas de fecha y palabras clave de tipo de documento) antes de cualquier llamada a OCR o LLM, de modo que la detección de límites no tiene coste.

The eval set mixes multi-invoice PDFs with single-invoice negatives. Precision and recall are computed on exact page-index boundary matches. The 2 %% OCR noise model applies per-character confusion, dropping, and swapping (including colon loss, which breaks label regexes). At that noise level the detector achieves F1 0.969, which motivated the suggest-and-confirm UX: boundaries are offered to the user for review rather than applied silently.

Notas metodológicas

• Todos los números proceden de artefactos de evaluación confirmados en el repositorio (docs/ocr-calibration/*.json, docs/OCR_IMAGE_CALIBRATION.md). Los resultados de detección de separación están en docs/ocr-calibration/split_detection_results.json. No se estima ni extrapola ningún número.
• La puntuación de OCR usa recuperación y precisión de multiconjuntos sin tener en cuenta el orden: la métrica cuenta si cada token de palabra de la referencia aparece en la salida de OCR (recuperación) y si cada token de la salida de OCR aparece en la referencia (precisión), sin penalizar las diferencias en el orden de lectura. Es un indicador mejor de la precisión de extracción de campos que las métricas de similitud de secuencias, que son sensibles a los cambios de segmentación de línea que no afectan al contenido de los tokens.
• La referencia de las fotos de cámara es una transcripción humana del documento de prueba (docs/IMG_2375.HEIC). La referencia de las páginas impresas procede de pdftotext, la misma herramienta utilizada en la vía rápida para PDF digitales.
• La precisión y la recuperación de detección de separación miden coincidencias exactas por índice de página en PDF de varias facturas generados sintéticamente con límites conocidos. El conjunto de evaluación cubre distintos tipos de factura, formatos de fecha y nombres de proveedores.
• Las nuevas ejecuciones de las pruebas tras cualquier cambio de motor se pueden activar con los scripts de scripts/. Los resultados nuevos se guardan en dev-artifacts/ (ignorado por Git) y se confirman tras la revisión.

Preguntas sobre la metodología o los resultados: [email protected]

Aún no medido

Dos cifras que un comprador pedirá están deliberadamente ausentes de esta página, porque ninguna evaluación las respalda:

• Precisión de extracción a nivel de campo (precisión, exhaustividad, F1 o coincidencia exacta por campo, como número de factura, total o NIF). Las cifras de OCR anteriores miden si las palabras se leen, no si el valor correcto llega al campo correcto. Se está preparando un conjunto de evaluación etiquetado; hasta que exista, no se publica ningún porcentaje.
• Latencia de extremo a extremo (p50 y p95 desde la subida hasta el resultado). Los tiempos por etapa se registran como métricas, pero no se ha publicado ninguna línea base.

Donde se sabe que DocSolved rinde peor: fotos de páginas brillantes o curvadas (exhaustividad de palabras 0,865 frente a 1,000 en una página impresa limpia), los números en esa misma foto (recuperación numérica 0,000, sin cambios respecto al motor anterior, mientras que un umbral de detección que no distribuimos alcanza 1,000 en ella), diacríticos polacos en fotos (0,775) y el enderezado de fotos aplicado a una página ya plana (0,635, por eso solo se ejecuta en fotos de cámara). Estos casos se pueden revisar en lugar de darlos por buenos: en un documento escaneado, un campo extraído lleva el anclaje que el emparejamiento pudo establecer — el texto de origen emparejado, un estado de coincidencia y una ubicación en la página cuando el valor queda anclado — y puede llevar una puntuación de confianza. Los campos de facturas electrónicas estructuradas no pasan por OCR en absoluto; proceden de los datos de origen y no necesitan esas señales.

Cifras legibles por máquina: docs/benchmarks/results.json en el repositorio, derivadas de los artefactos versionados, y la metodología en docs/benchmarks/METHODOLOGY.md.