Leer una boleta: de una foto a puntos

Sobre 51 boletas chilenas reales, el sistema lee los tres campos del núcleo de acreditación —local, fecha y total, los tres a la vez— en el 73 % de los casos. Los montos salen casi sin error: el total en el 98 % y el subtotal en el 100 %.

Lo que más falla es el nombre del local, con un 79 %, y falla por errores de lectura visual que no se corrigen entrenando más: duplicar los parámetros del adaptador no movió esa cifra ni un punto.

Con 51 boletas, una tasa del 73 % trae un intervalo de ±12 puntos. Para apretarlo a cinco harían falta unas trescientas. Eso no invalida la cifra: la enmarca.

La conclusión operativa es un sistema de dos vías: las boletas en las que el modelo va seguro se acreditan solas y el resto va a una cola de revisión. Dónde se pone esa raya lo decide el costo de un error, y no la calidad del modelo.

El conjunto real. 52 fotografías de precuentas chilenas tomadas con teléfono en condiciones auténticas, que corresponden a 51 documentos distintos. Cada una pasó por el mismo proceso: enderezar, tapar los datos personales conforme a la ley 21.719, y anotar a mano el contenido correcto. Esa anotación es la verdad de referencia.

Se descartaron fotos bajadas de internet, porque su procedencia no era clara. Es preferible medir sobre menos boletas legítimas que sobre más de origen dudoso.

El generador. Como no existe un conjunto grande de boletas chilenas anotadas, se construyó un programa que las fabrica. Arma el texto de una boleta y a la vez guarda la respuesta correcta —así la anotación sale gratis—, lo dibuja como lo imprimiría una térmica y después lo degrada: fondo de mesa, pliegues, arrugas, iluminación despareja, perspectiva, ruido y compresión.

La variación es deliberada: unas boletas dicen TOTAL, otras MONTO A PAGAR, otras NETO, para que el modelo aprenda el significado del campo y no una palabra. Con semilla fija: el mismo comando produce exactamente el mismo conjunto.

El problema —pasar de una foto a datos ordenados— se puede atacar de cuatro maneras distintas: reconocimiento óptico clásico seguido de reglas, reconocimiento óptico combinado con la posición del texto, modelos que van de la imagen a la estructura sin paso intermedio, y modelos multimodales generales.

Se compararon cinco candidatos concretos bajo un criterio fijado de antemano, con la licencia como filtro eliminatorio. Y ahí apareció el hallazgo más útil de la etapa: varios de los modelos más obvios no sirven para uso comercial.

YOLO se distribuye bajo una licencia que obliga a liberar el código del producto que lo use. LayoutLMv3 tiene los pesos bajo licencia no comercial. Incluso una versión de Donut afinada para boletas es no comercial. Como el encargo prohíbe entrenar con material que no permita uso comercial, esos quedaron fuera o sólo como referencia.

Los dos finalistas fueron Donut, hecho para ir de la imagen al JSON directamente, y Qwen2.5-VL de 3.000 millones de parámetros, multimodal general, con licencia comercial y buen desempeño en español. Donut no se pudo instalar por incompatibilidad con las versiones actuales de las librerías, que en sí es un dato sobre la madurez de su ecosistema —uno de los criterios de selección. El trabajo siguió con Qwen.

El segundo número que hay que entender es desde qué confianza conviene acreditar sola una boleta. Eso no lo fija la calidad del modelo: lo fija el costo de equivocarse.

Si el modelo entrega una boleta con probabilidad p de estar correcta, conviene automatizar mientras el costo esperado de un error sea menor que el de revisarla a mano.

Con supuestos declarados —un revisor pagado al ingreso mínimo, unos 43 pesos por boleta revisada— el umbral va del 91 % si un error es barato al 99,8 % si es caro. Los costos reales los tiene la empresa, no el proyecto: el cálculo está hecho de forma que sólo hay que reemplazar dos números para actualizarlo.

El modelo se afinó con LoRA, que en vez de reentrenar los 3.758 millones de parámetros entrena unas matrices pequeñas añadidas al costado: unos pocos millones, menos del 0,1 % del total. Eso permite entrenar un modelo grande en una tarjeta gráfica modesta. Corrió en local, en una RTX 4060 Ti, porque las plataformas gratuitas con GPU cortan las sesiones por límite de tiempo.

Una corrida fallida que vale documentar. Entrenar en un formato numérico de 16 bits llamado fp16 volvió inestable el proceso: la medida de error se disparó y el modelo quedó dañado, al punto de producir un error al generar texto. Se corrigió pasando a bf16, bajando el ritmo de aprendizaje y limitando cuánto puede cambiar el modelo por paso.

El error sistemático del total. El modelo entrenado leía casi todo bien, pero al total le sumaba la propina: ponía el «total con propina» impreso en vez del consumo. Reforzar la instrucción no lo corrigió.

Se resolvió con post-procesamiento: como el contrato define el total como el subtotal menos el descuento, y el modelo lee bien el subtotal, el total se calcula en vez de confiar en el número que el modelo eligió. Eso no inventa datos: aplica una regla del contrato sobre campos que el modelo sí lee bien, que es exactamente lo que haría una capa de reglas de negocio en producción. Se reportan las dos cifras, en bruto y con post-procesamiento.

La arquitectura recomendada es Qwen2.5-VL de 3.000 millones de parámetros afinado con LoRA de tamaño 16. Da el mejor desempeño de lo probado, lee los montos casi sin error y su licencia permite uso comercial.

El sistema no debe acreditar todo de forma automática. Con un núcleo del 73 %, una de cada cuatro boletas tiene algún campo del núcleo mal, y acreditar esas cuesta plata. Cuánto cae de cada lado depende del umbral que la empresa elija, y ese umbral depende de cuánto le cuesta un error.

Para acreditar el total de forma confiable conviene mantener el post-procesamiento que lo calcula como subtotal menos descuento. El modelo lee el subtotal casi perfecto, así que el total calculado es más confiable que el total que el modelo elige leer.

La mejora que más rinde no es entrenar más. La medida de error del entrenamiento se estancó pronto, lo que sugiere que el modelo llegó al límite de lo que esta configuración puede sacar de los datos disponibles. Lo que rinde es conseguir más boletas reales y atacar la lectura del nombre del local.

El nombre del local. Se lee bien en el 79 % de los casos, y los fallos que quedan son errores de lectura reales. El riesgo es que el sistema acredite por nombre de local y un local mal leído acredite al local equivocado. La mitigación es cruzar el nombre con el RUT o con un catálogo de locales de la red, en vez de confiar sólo en el texto leído.

La brecha entre lo sintético y lo real. El entrenamiento se hizo con boletas generadas. El modelo funciona sobre las reales, pero esa brecha no está caracterizada más allá de esta muestra: boletas de formatos que el generador no cubrió pueden leerse peor de lo que la cifra sugiere.

El umbral económico. Se calculó con supuestos declarados, no con cifras de la empresa. Si los costos reales son distintos, el umbral cambia. Está hecho de forma que sólo hay que reemplazar dos números.

La confianza no está calibrada. Cuando el modelo dice estar 90 % seguro, no necesariamente acierta el 90 % de las veces. El sistema de dos vías necesita esa confianza calibrada para decidir qué acreditar solo: aplicar el umbral sobre una confianza que no significa lo que parece es el riesgo, y calibrarla es un paso pendiente.

El proyecto se reproduce con los scripts del repositorio: generar los datos sintéticos, validar las anotaciones, particionar sin fuga, entrenar, evaluar sobre las boletas reales, post-procesar y medir. Las imágenes y el modelo entrenado no se versionan por peso y por confidencialidad, pero se regeneran con los mismos comandos. Cada afirmación de desempeño del informe se reproduce corriendo el script de medición sobre las predicciones guardadas.

Las siete figuras de esta página calculan lo que muestran: la curva de p⁴⁰⁰, el umbral económico, el intervalo de Wilson, el efecto de la fuga y la comparación campo por campo salen de un módulo puro que veintiséis controles comprueban contra las cifras del informe antes de publicar. Ninguna figura es un video ni un dibujo.