Un minuto por foto, miles de fotos al mes
La facturación de gas LP a edificios residenciales depende de un dato aparentemente trivial: la lectura del medidor. Cada mes, un operador de campo recorre los inmuebles, fotografía cada medidor, y esas fotografías deben convertirse en dos cosas distintas. Primero, una imagen limpia y bien encuadrada del medidor que se incluye en el recibo de consumo como evidencia para el residente. Segundo, el número de la lectura, que alimenta el cálculo de consumo del periodo. En el proceso heredado, ambas tareas eran completamente manuales.
El trabajo consistía en abrir cada fotografía una por una, recortarla para que el medidor quedara centrado y legible eliminando el fondo irrelevante —tuberías, paredes, sombras, el pulgar ocasional del fotógrafo—, leer manualmente el número del display, y transcribirlo a la base de datos relacionándolo con el cliente correspondiente. El tiempo promedio documentado por fotografía era de aproximadamente un minuto. Con una cartera que supera los tres mil clientes, eso se traduce en decenas de horas de trabajo mensual dedicadas exclusivamente a una tarea mecánica de recorte y transcripción.
El problema no era solo el tiempo: era la naturaleza del error. La lectura manual de medidores es sorprendentemente propensa a la equivocación. Los displays analógicos de tipo odómetro presentan dígitos parcialmente girados entre dos números; los displays digitales sufren reflejos y sobreexposición; la fatiga acumulada tras revisar cien fotografías degrada la precisión justo cuando más fotografías quedan por procesar. Cada lectura incorrecta se propaga directamente al recibo del cliente, generando disputas, reprocesos y erosión de confianza en la facturación.
Cuatro modelos, una decisión cada uno
El núcleo técnico de Argos es una pipeline de cuatro modelos de visión encadenados, donde cada modelo resuelve un único problema bien definido y entrega su salida como entrada del siguiente. Esta arquitectura en cascada es una decisión deliberada frente a la alternativa de un modelo único de extremo a extremo. Un solo modelo que intentara ir de la fotografía cruda a la lectura final tendría que aprender simultáneamente a ignorar fondos, localizar el medidor, encontrar el display, distinguir su tipo y leer dígitos de morfología variable. Dividir el problema en etapas especializadas produce cada componente más simple, más preciso, y —fundamentalmente— más fácil de diagnosticar cuando algo falla.
Etapa 1 — Encuadre del medidor (YOLO)
La primera etapa es un detector YOLO entrenado para una única clase: el medidor completo. Las fotografías de campo llegan con encuadres impredecibles —el medidor puede estar en cualquier región de la imagen, a distintas distancias, rodeado de elementos irrelevantes. El modelo de encuadre localiza el medidor con su caja de mayor confianza, y el sistema recorta la imagen alrededor de esa detección con un margen del 3% para garantizar que toda la información destacada quede contenida. El resultado es una imagen normalizada: el medidor centrado, ocupando la mayor parte del cuadro, con el ruido de fondo eliminado. Esta es la imagen que se incluye en el recibo del residente.
Etapa 2 — Localización y clasificación del display (YOLO)
Sobre el recorte del medidor opera el segundo detector YOLO, cuya tarea es doble: localizar la región específica del display numérico dentro del medidor, y clasificar de qué tipo de display se trata. Esta clasificación es la bifurcación más importante de toda la pipeline. Los medidores de la cartera incluyen dos tecnologías de visualización radicalmente distintas: displays digitales —dígitos de siete segmentos, LED o LCD— y displays analógicos de tipo odómetro mecánico, donde los números están impresos en ruedas giratorias. El modelo recorta el display con un margen del 2% y devuelve su clase, determinando qué modelo de OCR debe procesar la lectura a continuación.
Etapa 3 — Reconocimiento de la lectura (CRNN dual)
La extracción del número es responsabilidad de dos modelos CRNN independientes —uno especializado en displays digitales, otro en analógicos— seleccionados dinámicamente según la clasificación de la etapa anterior. La decisión de mantener dos modelos separados en lugar de uno general responde a la diferencia morfológica fundamental entre ambos tipos: un dígito de siete segmentos y un dígito impreso en una rueda mecánica parcialmente girada son problemas visuales tan distintos que un modelo único comprometería la precisión en ambos. La especialización permite que cada CRNN aprenda exactamente las particularidades de su dominio: el modelo analógico, por ejemplo, aprende a interpretar el dígito dominante cuando la rueda está en transición entre dos números.
La arquitectura CRNN combina tres componentes en secuencia. Una red convolucional profunda —seis bloques de convolución con normalización por lotes y activación ReLU, escalando de 64 a 512 canales— extrae características visuales del recorte del display. El pooling final asimétrico preserva la dimensión horizontal, convirtiendo el mapa de características en una secuencia ordenada de izquierda a derecha. Esa secuencia alimenta un LSTM bidireccional de dos capas que modela el contexto: la identidad de cada dígito depende de sus vecinos, y la bidireccionalidad permite que el modelo considere tanto los dígitos anteriores como los posteriores al decidir. Finalmente, una capa lineal proyecta cada paso de la secuencia sobre el vocabulario de caracteres posibles.
La pieza que conecta todo es la decodificación CTC (Connectionist Temporal Classification). El reto central del OCR de secuencias es que no existe una correspondencia uno a uno entre las columnas de píxeles del display y los dígitos de la lectura: un dígito puede ocupar varias columnas, y los espacios entre dígitos varían. CTC resuelve este problema de alineamiento sin requerir segmentación manual de cada dígito, permitiendo entrenar el modelo con solo la imagen y su transcripción de texto, sin anotar la posición de cada carácter. La decodificación greedy sobre la salida del modelo produce la lectura final, que un paso de postprocesamiento formatea según las convenciones de cada tipo de medidor.
De un minuto a un segundo y medio
El indicador central del proyecto fue el tiempo de procesamiento por fotografía, y la mejora es del orden de magnitud. El proceso manual promediaba aproximadamente sesenta segundos por imagen entre recorte, lectura y transcripción. La pipeline Argos en producción procesa la misma fotografía —encuadre, recorte de display, clasificación y extracción de lectura— en alrededor de un segundo y medio de inferencia de extremo a extremo. La fotografía recortada y la lectura estructurada aparecen automáticamente al operador, que pasa de transcribir a únicamente verificar.
La reducción de 40x en tiempo de procesamiento transformó la economía de la operación: lo que antes ocupaba a una persona durante días enteros del ciclo de facturación se resuelve ahora en una sesión de revisión de unas pocas horas, donde el operador valida las lecturas de baja confianza en lugar de procesar manualmente la totalidad de las imágenes. El sistema expone el nivel de confianza de cada etapa de la pipeline —encuadre, display y OCR— permitiendo al operador concentrar su atención únicamente en las fotografías donde algún modelo reportó incertidumbre.
El diseño de la pipeline incluye un mecanismo de degradación explícita: cuando una etapa no alcanza el umbral de confianza configurado —un medidor no detectado, un display no localizado— el sistema no inventa un resultado, sino que marca la fotografía con un estado específico ('no_medidor', 'no_display') y la deriva a revisión manual. Esta honestidad del sistema sobre sus propios límites es lo que permite confiar en las lecturas que sí produce automáticamente, y fue clave para la adopción del proceso por parte del equipo de facturación.
Una herramienta sobre una pipeline
Argos es, en realidad, dos cosas: una pipeline de inferencia y una herramienta que la hace usable. La pipeline —los cuatro modelos y la lógica de orquestación entre ellos— resuelve el problema técnico. Pero una pipeline por sí sola no es un producto; es un script que requiere un ingeniero para ejecutarse. El valor para el cliente está en la capa de aplicación que envuelve esa pipeline y la convierte en un flujo de trabajo que el equipo de facturación puede operar sin conocimiento de machine learning.
El flujo de trabajo se estructura en cuatro funcionalidades secuenciales. La carga masiva permite subir mediante un único archivo ZIP la totalidad de fotografías de un ciclo de facturación, que el sistema descomprime y encola para procesamiento. El procesamiento individual ejecuta la pipeline sobre cada fotografía cargada y presenta al operador la imagen recortada junto a la lectura extraída, lista para verificación. El ajuste de identificación permite relacionar cada fotografía con su cliente correspondiente, completando el vínculo entre la imagen y el registro de facturación. Y la exportación produce un archivo ZIP con todas las imágenes recortadas por la pipeline, listas para incorporarse a los recibos de consumo.
El backend en .NET orquesta el flujo de la aplicación, gestiona la cola de procesamiento, y persiste el estado de cada fotografía a lo largo de su ciclo de vida: cargada, procesada, identificada, exportada. La pipeline de visión vive en un servicio Python independiente, invocado por el backend para cada fotografía. Esta separación es arquitectónicamente natural: el ecosistema de Python es el hábitat nativo de PyTorch, Ultralytics YOLO y el resto del stack de visión, mientras que .NET aporta la robustez transaccional y la integración con el resto de los sistemas internos de la empresa que el backend necesita.
El servicio de inferencia mantiene los cuatro modelos cargados en memoria de forma persistente —dos detectores YOLO y dos CRNN— evitando el costo de inicialización en cada petición. La inferencia se ejecuta bajo torch.no_grad para eliminar la sobrecarga de cálculo de gradientes, y cada etapa registra su tiempo de ejecución y nivel de confianza, exponiendo a la capa de aplicación una traza completa de cómo se produjo cada lectura. Cuando está habilitado, el sistema guarda los recortes intermedios de cada etapa, proporcionando material para auditar errores y para reentrenar los modelos con casos difíciles del mundo real.
El frontend en Vue presenta cada funcionalidad como una vista dedicada, con la pantalla de procesamiento individual como centro de la experiencia: la fotografía original, el recorte resultante de la pipeline, la lectura extraída, y los indicadores de confianza de cada etapa, todo en una sola vista que el operador recorre fotografía por fotografía hasta completar el ciclo. El estado de procesamiento se mantiene en el servidor, permitiendo pausar y retomar el trabajo de un ciclo de facturación completo sin pérdida de progreso.
Cada lenguaje en su dominio
La distribución del stack en Argos sigue un principio simple: cada lenguaje hace aquello para lo que es mejor. Python posee el ecosistema de visión por computadora más maduro y completo que existe, y forzar ese trabajo en otra plataforma habría significado reimplementar o adaptar herramientas que en Python funcionan de manera nativa. .NET aporta la solidez transaccional, el manejo de estado y la integración con la infraestructura interna que la capa de aplicación requiere. Vue ofrece la velocidad de desarrollo de interfaz que un producto de uso interno con flujos bien definidos necesita.
La pipeline de visión se construye sobre PyTorch como motor de inferencia, con Ultralytics YOLO para las dos etapas de detección y una implementación propia de CRNN con decodificación CTC para el OCR. El preprocesamiento y manipulación de imágenes se maneja con OpenCV, que gestiona la decodificación de las fotografías cargadas, los recortes entre etapas, y la normalización de los tensores de entrada para cada modelo. Los pesos de los cuatro modelos se distribuyen como archivos independientes organizados por función, permitiendo actualizar o reentrenar cualquier etapa sin afectar al resto de la cascada.
La decisión de entrenar modelos propios en lugar de utilizar OCR de propósito general fue determinante para el resultado. Los servicios de OCR comerciales fallan sistemáticamente con displays de medidores: no están entrenados para dígitos de siete segmentos ni para las ruedas parcialmente giradas de los medidores analógicos, y su precisión en este dominio específico es inaceptablemente baja. Entrenar dos CRNN especializados sobre fotografías reales de los medidores de la cartera del cliente produjo modelos que entienden exactamente la morfología que van a encontrar en producción.