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.

Métrica PP-OCRv5 (anterior) PP-OCRv6 medium + box_thresh 0.5 (actual)
Recuperación de palabras (foto de cámara) 0.670 0.865 (+29 %)
Recuperación de diacríticos polacos (foto de cámara) 0.562 0.775 (+38 %)
Precisión de palabras (foto de cámara) 0.986 0.955
Recuperación numérica (recibo) 0.818 1.000 (+22 %)
Factura impresa densa (recuperación/precisión de palabras) 1.000 / 1.000 1.000 / 1.000
Latencia GPU en caliente (RTX 3090, página densa) ~0.55 s ~1.13 s

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.

Métrica Sin preprocesamiento (referencia) Con enderezamiento (cargas de cámara)
Recuperación de palabras (foto de cámara) 0.865 0.921 (+6.6 %)
Recuperación de diacríticos polacos (foto de cámara) 0.775 0.854 (+10.2 %)
Precisión de palabras (foto de cámara) 0.955 0.961
Recuperación de palabras. Página densa impresa 1.000 0.635 (regresión, solo para fotos por diseño)

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.

Condición Precisión de límites Recuperación de límites F1 Documentos evaluados
Texto limpio (sin ruido OCR) 1.000 1.000 1.000 660
Ruido OCR a nivel de caracteres: 2 % - - 0.969 660

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

Preguntas sobre la metodología o los resultados: hello@synairo.com