Saltar al contenido principal
← Blog Comprobantes de pago móvil

V2: un extractor de 258M y las razones para conservar V1

Probamos un modelo completo de 258M para clasificación y extracción. Su consumo fue pequeño, pero perdió precisión y rechazó pagos válidos. Resultados por conjunto y decisiones de esta ronda.

Serie: Comprobantes de pago móvil · Versión V2

Después de V1 probamos Granite Docling 258M, una base más pequeña. En esta ronda se ajustó el modelo completo para identificar imágenes de pago y extraer los mismos cuatro campos.

Comparación de extracción frente a V1

Las comparaciones siguientes utilizan las mismas imágenes dentro de cada grupo. Un caso exacto exige referencia, monto, moneda y fecha correctos.

  • 200 casos automáticos: V1 logró 200/200; V2 obtuvo 194/200.
  • 14 comprobaciones visuales originales: ambas versiones obtuvieron 11/14.
  • 5 comprobaciones visuales adicionales: V1 logró 5/5 y V2 obtuvo 3/5.

Clasificar una imagen fue una prueba distinta

  • V2 rechazó correctamente 225/225 fotos y documentos públicos que no eran comprobantes.
  • En 120 negativos sintéticos cercanos a un pago, rechazó 113 y aceptó incorrectamente 7.
  • De 60 comprobantes sintéticos válidos, reconoció 27 como pagos y rechazó 33.
  • Solo 16/60 de esos positivos sintéticos quedaron aceptados con los cuatro datos exactos.

Rechazar fotos ajenas fue insuficiente: también había que conservar los comprobantes legítimos. Los 33 rechazos de positivos sintéticos mostraron una limitación que el resultado de las fotos públicas, por sí solo, habría ocultado.

Decisión de esta ronda

V2 quedó como experimento y no sustituyó a V1 como extractor. Reducir el tamaño y ajustar todos los pesos no aseguró mejores datos. La comparación motivó volver a la base de V1 y separar clasificación y extracción en V1.1.

Los grupos visuales son pequeños y los sintéticos no equivalen a toda la distribución de documentos reales. El ensayo compara estas versiones; no establece un ranking general entre familias de modelos.

¿Por qué IA y no solo OCR?

OCR también es una tecnología de IA. Los modelos multimodales de esta serie combinan visión y lenguaje: seguimos leyendo texto, pero especializamos la tarea de asignarlo a referencia, monto, moneda y fecha.

Un número puede ser una referencia, un teléfono o un identificador; una operación puede estar realizada, pendiente o cancelada. Un OCR con reglas puede resolverlo muy bien si los formatos son estables. Es una alternativa que debe medirse, no descartarse de antemano.

No hicimos una comparación directa contra un sistema OCR con reglas. Además, OCR participó en el etiquetado automático y en el filtrado de casos legibles. El resultado de ese conjunto no demuestra superioridad frente a OCR clásico.

¿Por qué no usar GPT-6 Luna o Claude Haiku?

Son alternativas válidas. La documentación de OpenAI incluye GPT-6 Luna entre sus modelos con entrada de imágenes; la de Anthropic también contempla visión y extracción en Claude Haiku. Las salidas estructuradas ayudan a cumplir un esquema, aunque el contenido todavía puede contener errores.

Aquí investigamos un componente acotado, ejecutable en un entorno propio, con una tarea repetida y un formato de salida verificable. Eso permite controlar versiones y el recorrido de las imágenes durante la inferencia local. También exige preparar datos, mantener el software y asumir el hardware.

No evaluamos Luna ni Haiku con estas mismas imágenes y no calculamos un costo total comparable. Por tanto, no afirmamos que sean más caros, lentos o menos precisos. Para un prototipo o poco volumen, una API puede ser el camino más directo: el PC del usuario no necesita ejecutar el modelo. La elección debe considerar precisión por campo, rechazo de imágenes ajenas, latencia, costos totales y condiciones de uso de los datos.

Qué PC y cuánta RAM hacen falta para usarlo

En esta versión se midió inferencia secuencial en un entorno de memoria unificada: aproximadamente 0,98 GiB asignados por PyTorch, 1,38 GiB reservados y 3,52 GiB de RSS del proceso. El RSS y la memoria GPU pueden solaparse; no deben sumarse. Tampoco incluyen todos los recursos del sistema y del controlador.

No se midió V2 solo en CPU. Las cifras de la prueba CPU de V1 y V1.1 no son mediciones de este modelo distinto. Por ello no publicamos un mínimo de RAM ni un tiempo CPU para V2. Un PC de prueba con 16 GB de RAM y GPU compatible con CUDA/BF16 de 8 GB ofrece una referencia con margen, no una certificación de mínimos.

El menor consumo observado es interesante, pero en este experimento vino acompañado de peor extracción. Una solución eficiente debe cumplir también el nivel de error que exige la tarea.

Alcance de la publicación

Publicamos resultados agregados y conceptos generales del método. Los comprobantes originales, los datos de titulares, las referencias de operaciones y los archivos internos permanecen fuera de estos artículos.

Identificar una imagen de comprobante no verifica el abono bancario, su autenticidad ni si la captura se ha reutilizado. Los resultados de una muestra no son una garantía para todos los bancos, formatos o fotografías.

Punto de partida de esta serie

V1: especializar GLM-OCR para leer comprobantes de pago móvil.

← Volver al blog Okanet Solutions · Caracas, VE

El blog de Okanet

Notas de ingeniería.

Experiencias y notas del equipo sobre desarrollo de software, automatización, investigación y tecnología.

Valoramos tu privacidad

Usamos cookies para mantener el sitio en funcionamiento, entender cómo se utiliza y apoyar nuestro marketing. Puedes aceptar todas las cookies, rechazar las no esenciales o elegir cuáles permitir. Política de Cookies