Experimento 02 · Lector de pruebas de velocidad · v3 experimental

Continuamos la LoRA de la v2 para corregir etiquetas y enseñar al modelo a distinguir resultados completos de pruebas en curso. El candidato elegido mejora ligeramente el acierto completo: de 286 a 288 imágenes de prueba y de 92 a 93 en la revisión visual. También introduce errores: rechaza resultados válidos y aumenta las IP no sustentadas en la prueba histórica.

Por eso conservamos v2 como referencia recomendada. La v3 queda como candidato de investigación, sin sustitución automática. Las diferencias son pequeñas, sus intervalos incluyen cero y todavía falta una evaluación con capturas recientes e independientes.

Qué intentamos mejorar

La v2 ya devuelve bajada, subida y ping con sus unidades, más la IP cuando aparece. Quedaban pantallas de carga tomadas por resultados, confusiones entre latencia en reposo y con carga, y números de identificación copiados como IP. Probamos una continuación corta del mismo modelo, con el mismo prompt y procesamiento posterior, para aislar el efecto de los datos y los pesos.

El contrato se mantiene. Ejemplo ficticio con una IP reservada para documentación:

{"es_prueba_velocidad": true, "descarga": {"valor": 280, "unidad": "Kbps"}, "subida": {"valor": 31, "unidad": "Mbps"}, "ping": {"valor": 44, "unidad": "ms"}, "ip": "203.0.113.25"}

El modelo copia valor y unidad; el código convierte después a Mbps y valida el formato IPv4. Una IP con formato válido puede seguir siendo inventada. La salida debe pasar por el extractor del objeto JSON y su normalización: el texto bruto incluye prefijos de control y no cumple por sí solo JSON estricto.

Primero revisamos las etiquetas

Revisamos visualmente las 289 imágenes originales de validación y corregimos tres etiquetas: dos subidas omitidas y lecturas de ping equivocadas. Excluimos antes de generar predicciones una captura en MB/s, porque el esquema actual solo representa Kbps, Mbps y Gbps. Quedaron 288 imágenes originales revisadas; añadimos seis pantallas incompletas de otro origen para formar una validación de 294 imágenes: 123 positivas y 171 negativas.

En entrenamiento revisamos 20 positivos, corregimos dos pings y añadimos diez negativos de pruebas incompletas o pantallas de error. No revisamos manualmente todo el entrenamiento. Los ejemplos corregidos y los nuevos negativos se repitieron ocho veces cada uno, manteniendo la repetición previa de unidades raras. El conjunto suma 2.652 imágenes distintas y 2.772 filas; durante los 80 pasos se procesaron 1.280 ejemplos, menos de una época.

Corregir etiquetas cambia la evaluación, no los pesos. En las mismas 288 imágenes originales, v2 obtiene 279 aciertos con las etiquetas antiguas y 281 con las revisadas; el candidato obtiene 281 y 283, respectivamente. No atribuimos esa diferencia entre etiquetas al entrenamiento.

Cómo elegimos el candidato

Antes de entrenar fijamos los datos, sus hashes, la semilla y el criterio: al menos dos aciertos completos netos más que v2 en validación, sin aumentar falsos positivos ni IP inventadas y sin perder aciertos en las 288 imágenes originales. Comparamos los pasos 40 y 80 de una única continuación. Prueba, oro y archivo reservado no intervinieron en la elección.

El paso 80 cumple el criterio: cuatro ganancias y una pérdida frente a v2. El paso 40 no lo cumple. Esta selección identifica el mejor candidato bajo el criterio fijado; no demuestra una mejora general. Tras elegirlo congelamos los pesos y no reabrimos la búsqueda al conocer los resultados finales.

Resultados sobre las mismas imágenes

Generamos de nuevo las respuestas del modelo base, v2 y el candidato con el mismo orden, etiquetas, prompt y procesamiento. Las respuestas brutas de base y v2 reprodujeron exactamente las 300 imágenes de prueba y las 95 de oro de sus evaluaciones anteriores. Cada acierto completo exige detección y todos los campos correctos, con valor y unidad e IP exacta.

Frente a v2, el candidato gana cuatro imágenes y pierde dos en prueba; gana dos y pierde una en oro. Los intervalos pareados del cambio, calculados con 5.000 remuestreos por componentes de origen, son de −0,9 a +2,4 puntos porcentuales en prueba y de −2,1 a +4,2 en oro. Ambos incluyen cero. No sumamos los conjuntos para anunciar una única mejora.

Qué mejora y qué empeora

El candidato corrige la pantalla de carga conocida del oro, pero rechaza una prueba de consola terminada. En otra tarjeta nPerf cruza subida y latencia y lee la pérdida de paquetes como ping. La revisión posterior confirmó estos errores sin cambiar etiquetas, puntuaciones ni pesos. Una IP parcialmente recortada mantiene incertidumbre de lectura: conservamos su etiqueta histórica y no presentamos ese caso como una corrección visual concluyente.

Los dos incompletos del archivo reservado siguen fallando en v2 y en el candidato. Tampoco mejora la cantidad de IP inventadas de validación: permanece en cuatro. El avance global no resuelve todavía los problemas que motivaron toda la ronda.

Qué tan independientes son los datos

Comprobamos las huellas de las 9.580 imágenes del archivo y agrupamos por conversación, contenido idéntico y un filtro de similitud visual. Bajo esos filtros no aparecen componentes compartidos entre entrenamiento y evaluación, ni entre validación y los conjuntos finales. Los filtros pueden perder recortes o fotografías y no garantizan detectar cualquier duplicado.

Prueba y oro comparten un componente de origen: no son imágenes evaluadas idénticas, pero sus resultados no son evidencia independiente. Sus etiquetas históricas permanecen intactas, incluidos errores conocidos de las etiquetas automáticas; ambos conjuntos ya se habían inspeccionado y no son una nueva prueba a ciegas.

Las 12 imágenes reservadas recibieron etiquetas visuales antes de consultar las respuestas de los modelos para ese lote. Proceden del archivo histórico y contienen solo dos positivos: son etiquetas nuevas, no capturas recién recogidas. No tenemos en esta ronda una prueba externa reciente.

Entrenamiento y consumo medido

La inferencia se midió sobre 12 imágenes de desarrollo después de una de calentamiento, una captura cada vez. El RSS durante esa medición fue de 2,10 GiB; el máximo de 4,13 GiB pertenece al proceso completo, que también cargó otros modelos. En memoria unificada no se suman GPU y RSS como consumos físicos independientes. No medimos concurrencia ni repetimos una prueba de CPU o de otra GPU para este adaptador.

La siguiente mejora necesita datos nuevos

La v3 experimental muestra un avance pequeño en acierto completo, acompañado de regresiones en detección y lecturas no sustentadas. Conservamos los pesos v2 y el candidato para comparar, y mantenemos v2 como referencia recomendada. La siguiente ronda debe aportar capturas recientes revisadas, más variedad de pantallas incompletas y diseños poco frecuentes, con criterios explícitos para evitar rechazar resultados válidos.

Seguimos sin garantizar IPv6, MB/s, IP parcialmente ocultas o tarjetas diminutas. Publicamos el balance completo porque un porcentaje algo mayor no basta para justificar un reemplazo.