En un caso publicado el 27 de octubre de 2026, AWS y Property Finder atribuyeron el sesgo de una evaluación de visión al origen de sus etiquetas: el 96,8 % procedía de predicciones del modelo incumbente. Así, las alternativas se comparaban con las respuestas del sistema que querían sustituir, en lugar de hacerlo con etiquetas creadas de forma independiente.
Cómo el modelo incumbente se convirtió en la referencia
Property Finder usaba el sistema anterior para generar casi todas las etiquetas de evaluación. Cuando las respuestas de un modelo pasan a ser la referencia, otro sistema puede perder puntos por diferir de ellas aunque esa diferencia no implique un error. La comparación termina midiendo cuánto se parece al modelo incumbente, no solo si identifica correctamente lo que aparece en una imagen.
El 3,2 % restante tenía etiquetas humanas, pero también aparecieron errores. Algunas lecturas incorrectas de marcas de agua se aceptaron como válidas y la clasificación de habitaciones permitía una sola categoría incluso cuando una imagen mostraba varios tipos de estancia. AWS también señaló un problema de especificación: se utilizó la categoría «Office», que no figuraba en el prompt.
La tarea de Property Finder consistía en evaluar 11 atributos de calidad en imágenes inmobiliarias, desde marcas de agua y tipo de habitación hasta mobiliario y calidad fotográfica. El flujo procesaba decenas de miles de imágenes al día en Oriente Medio y el Norte de África; cada anuncio tenía una media de 15 imágenes.
Cómo se reconstruyó el conjunto de referencia
Una persona experta anotó de forma independiente 356 imágenes de Emiratos Árabes Unidos. El AWS Generative AI Innovation Center revisó las etiquetas y aclaró los casos ambiguos. Las primeras 256 imágenes formaron el conjunto de desarrollo; las 100 anotadas después se añadieron a la evaluación final, que reunió las 356.
El equipo permitió asignar varias etiquetas cuando una imagen podía contener habitaciones o características fotográficas superpuestas. AWS también menciona una comprobación regional aparte con 230 imágenes de Egipto; las puntuaciones presentadas corresponden a las imágenes de Emiratos Árabes Unidos.
Qué muestran las puntuaciones Micro F1
AWS comunicó los siguientes resultados de Micro F1, una métrica que agrega el rendimiento entre las distintas etiquetas, para el conjunto de 356 imágenes:
| Modelo | Versión del prompt | Micro F1 en 356 imágenes de Emiratos Árabes Unidos |
| Llama 4 Maverick 17B Instruct | v27_PF | 0,80 |
| proprietary model A | v22 | 0,56 |
La comparación tiene dos condiciones importantes: el conjunto final reutilizó las 256 imágenes de desarrollo que se habían usado para ajustar los prompts, y Llama recibió varias rondas de ajuste y reglas específicas de Property Finder, frente a una ronda para proprietary model A. AWS calificó las puntuaciones de optimistas. El resultado describe esta tarea inmobiliaria y este proceso de ajuste, no una ventaja general de un modelo en otras tareas o regiones.
AWS también presentó exact-match accuracy, que mide la coincidencia exacta por atributo: informó un 100 % para la detección de rotación y un 55 % para la extracción de texto de marcas de agua. Son resultados por atributo y no la misma métrica agregada que Micro F1.
Qué cambió en los prompts y qué enfoque falló
El equipo iteró los prompts desde v0 hasta v27. La versión v27_PF incorporó reglas de Property Finder para renders, bordes o marcos y pasillos; MIPROv2 se utilizó para optimizar la clasificación de fotografías. Las instrucciones también abordaron casos como habitaciones visibles a través de puertas y textos decorativos en árabe que podían confundirse con marcas de agua.
Un enfoque de dos llamadas separaba los atributos de marcas de agua del resto. AWS informó que no mejoró de forma significativa la precisión y que redujo la detección de imágenes enmarcadas: al no recibir los atributos de marca de agua en la misma llamada, el modelo confundía algunas superposiciones con bordes.
Qué significan las cifras de coste y latencia
AWS estimó en diciembre de 2025 un coste de 2,35 dólares estadounidenses por cada 1.000 imágenes para Llama 4 Maverick 17B Instruct en US East (Ohio). El cálculo suponía 9.000 tokens de entrada y 200 de salida por imagen. AWS lo describió como una estimación superior: el prompt de producción procesaba cada imagen en una sola llamada y usaba entre 7.500 y 8.000 tokens de entrada.
La reducción estimada del 86 % frente al sistema anterior se calculó a partir del coste de ese sistema con v21. La comparación de Micro F1, en cambio, enfrentó Llama con proprietary model A usando v22, cuyo coste podía ser distinto.
Property Finder atribuyó a su propia monitorización una reducción del 40 % al 60 % en la latencia de inferencia frente a su configuración anterior.
