Experimento 02 · Lector de pruebas de velocidad · v1

Cuando alguien reporta que su internet va lento, lo primero que se pide es una prueba de velocidad. Las respuestas llegan como capturas de pantalla de apps y webs muy distintas: Speedtest, fast.com, nPerf y otras, en móvil, en el navegador o como foto de otra pantalla. Especializamos GLM-OCR (~0,9B) con LoRA para que, ante cualquier imagen, diga si es una prueba de velocidad y lea la bajada, la subida y el ping.

Un caso es correcto cuando coinciden todos los campos: si es o no una prueba de velocidad, bajada y subida en Mbps y ping en ms. Cada comparación usa las mismas imágenes y el mismo prompt antes y después del ajuste.

¿Por qué un modelo de IA y no solo OCR? ¿Y por qué no un LLM grande?

OCR con reglas no alcanza. Lo comprobamos de primera mano, porque las etiquetas de este experimento salieron justamente de OCR con reglas escritas para cada diseño de pantalla:

• Cada app, y cada versión de la misma app, coloca los datos de otra forma: columnas, recuadros, diales, filas de latencia, tarjetas para compartir o fotos de otra pantalla. Cada rediseño obliga a escribir reglas nuevas.
• Hay trampas que un OCR no entiende: iconos leídos como dígitos, la velocidad de datos de la barra de estado del teléfono, anuncios con números grandes, el valor medio junto al principal o la latencia con carga junto al ping en reposo.
• Saber si la imagen es o no una prueba de velocidad tampoco es trivial: un chat que menciona «500 Mbps», la caja de un router o la página de configuración del módem usan las mismas palabras.
• Aun con todo ese trabajo, las reglas dejaron como dudosas más de 2.200 de las 9.580 imágenes. En la revisión visual hubo 18 imágenes sin respuesta segura de las reglas: el modelo ajustado acertó todos los campos en 16 de ellas, y el modelo base en 5.

El modelo aprende qué significa cada número por su contexto visual, en lugar de depender de coordenadas y palabras clave.

¿Y un LLM grande, como GPT Luna o Claude Haiku? Podría leer muchas de estas capturas, pero elegimos un modelo pequeño propio por estas razones:

• Privacidad: las capturas son de clientes y muestran datos como su IP. El modelo corre en nuestro propio hardware, así que las imágenes no se envían a terceros para leerlas.
• Costo y escala: una API cobra por cada imagen; este modelo procesa una captura en uno o dos segundos en una sola GPU, sin costo por llamada ni límites de uso.
• Respuesta estable: siempre devuelve el mismo JSON con definiciones fijas (ping en reposo y no con carga, valor principal y no el medio) sin depender de cómo se redacte el prompt.
• Precisión en los dígitos: contrastamos nuestras etiquetas con lecturas que un LLM general había hecho de las mismas conversaciones. En la mayoría de los desacuerdos que revisamos a ojo, o el LLM había leído mal (4,2 como 42, 27,92 como 2,92, 8,41 como 0,41) o se refería a otra imagen. En uno, el que se equivocaba era nuestro etiquetador, y lo corregimos.

No evaluamos GPT Luna ni Claude Haiku sobre este conjunto, así que no afirmamos que rindan peor: la decisión es de privacidad, costo y control. Además, ambos enfoques se complementan: un LLM puede conversar con el cliente y razonar sobre el problema usando como dato el JSON que devuelve este modelo.

Prueba automática

300 imágenes reservadas: la mitad son pruebas de velocidad y la otra mitad no (comprobantes de pago, fotos de equipos, capturas de ajustes de WiFi). Con todos los campos correctos: base 49,3% y ajustado 97,0%.

Las tasas de bajada, subida y ping se miden sobre las 150 pruebas de velocidad.

Revisión visual independiente

95 imágenes leídas una a una, sin mirar antes la etiqueta automática: 57 pruebas de velocidad y 38 imágenes que no lo son. 16 son casos difíciles a propósito: pruebas en curso, pantallas de error, velocidades en Kbps o una prueba hecha desde una consola de videojuegos.

De dónde salen las etiquetas

No había etiquetas previas. Las generamos con OCR clásico y reglas específicas para cada diseño de pantalla (columnas de Speedtest, la versión ligera de su web, fast.com y las variantes de nPerf). Seguimos tres reglas:

• Un dato solo queda vacío si su rótulo no aparece en la pantalla.
• Si el rótulo aparece pero el valor no se puede leer con seguridad, la imagen sale del entrenamiento.
• Las pruebas en curso, los diálogos superpuestos y los diseños desconocidos también quedan fuera.

Antes de entrenar comparamos esas etiquetas con la revisión visual: coincidieron en todos los campos en 50 de 51 pruebas de velocidad y en 26 de 26 imágenes que no lo son. El único fallo fue una foto borrosa donde el OCR no vio el rótulo de subida.

Datos y entrenamiento

Las imágenes se separaron por conversación y por huella SHA-256, así que ninguna conversación ni imagen repetida aparece a la vez en entrenamiento y evaluación. La parte visual del modelo quedó congelada y solo se ajustó la parte que genera el texto.

0,78 s base / 1,37 s ajustado

Promedio por imagen en la prueba automática, procesando una imagen tras otra. Son tiempos observados, no una prueba de carga.

¿Qué PC hace falta para usarlo?

El modelo tiene unos 900 millones de parámetros: los pesos del modelo base ocupan 2,5 GB y el adaptador entrenado, 9 MB. No hace falta un centro de datos. Medimos el consumo procesando una captura a la vez:

Las mediciones de GB10 y CPU se hicieron con la v2, que usa la misma base y un adaptador del mismo tamaño; la v1 da respuestas más cortas, así que tarda algo menos. * La de la RTX 3060 viene de nuestro experimento de comprobantes de pago, también con la misma base.

• Recomendado: una PC con una GPU NVIDIA de 6 GB o más (por ejemplo una RTX 3060), de 8 a 16 GB de RAM y unos 10 GB libres en disco para el modelo y el entorno de Python. A uno o dos segundos por captura, son del orden de 2.000 a 3.000 capturas por hora.
• Sin tarjeta gráfica: también funciona en una PC común con un procesador de 6 núcleos y 16 GB de RAM, a unos 30 segundos por captura (unas 120 por hora). Alcanza para volúmenes bajos.
• Para comparar: GPT Luna o Claude Haiku no se pueden instalar en un equipo propio; solo se usan a través de su API, pagando por cada imagen.

La prueba en CPU se hizo con capturas sintéticas del mismo tamaño que las reales, sin datos de clientes, y el modelo leyó bien las tres. Son mediciones de una imagen a la vez y no una prueba de carga: con varias peticiones simultáneas los números cambian.

Alcance y errores pendientes

• Al revisar a ojo los 9 fallos de la prueba automática, 3 eran errores de la etiqueta y el modelo había acertado.
• Kbps: cuando fast.com muestra la velocidad en Kbps, el modelo devuelve el número sin convertirlo a Mbps. Lo corregimos en la v2.
• Errores aislados: tomar la latencia con carga en vez del ping en reposo, o el valor medio de nPerf en vez del principal.
• No se entrenó con pruebas en curso ni pantallas de error, y las métricas describen este histórico concreto. Nuevas apps o formatos requieren validarse de nuevo.
• El texto bruto del modelo puede venir envuelto en Markdown o etiquetas vacías; el script extrae y normaliza el objeto JSON.