Property Finder detectó un sesgo en el etiquetado y redujo el coste de su VLM un 86%

Property Finder, plataforma digital inmobiliaria, procesa decenas de miles de fotografías al día en toda la región MENA. Cada imagen se revisa según 11 atributos, y cada anuncio tiene de media 15 fotos. El equipo quería abandonar un costoso modelo de visión propietario y pasar a otro más barato en Amazon Bedrock, pero se topó con un problema inesperado: el 96,8% de las etiquetas de referencia no procedía de una revisión manual, sino que eran copias de las predicciones del mismo modelo que pensaban sustituir.

Con el AWS Generative AI Innovation Center, el equipo rehízo la evaluación, ajustó los prompts y se pasó a Llama 4 Maverick 17B Instruct: Micro F1 de 0,80 frente a 0,56 del modelo anterior y un 86% de ahorro.

Respuestas escritas por el modelo que se quiere sustituir

El esquema le resulta familiar a mucha gente. Hace falta un dataset para comparar modelos, hay un sistema en producción que funciona y nadie critica, así que se toma su salida como ground truth. El resultado es un círculo vicioso: el candidato se evalúa por su cercanía al incumbente, no por su corrección. Cualquier alternativa pierde estructuralmente antes de recibir la primera consulta.

En los datos de Property Finder aparecieron también errores directos. En la extracción de texto de marcas de agua, las inexactitudes letra a letra figuraban como correctas, incluidos nombres de marcas inventados y caracteres omitidos. La clasificación de fotos obligaba a asignar una sola etiqueta, aunque en la imagen se vieran varios tipos de habitación. En el 3,2% restante de etiquetas, hechas por personas, los anotadores añadieron categorías fuera de la especificación, como Office.

Cómo se construyó el estándar de referencia y se probaron 27 versiones

del prompt

Los expertos etiquetaron a mano 356 imágenes de los Emiratos Árabes Unidos de forma independiente, sin acceso a las salidas del modelo anterior. Las primeras 256 se usaron como conjunto de desarrollo para el ajuste, se añadieron 100 más después y las 356 entraron en la comparación final. Un conjunto aparte de 230 imágenes de Egipto sirvió como verificación entre regiones y no se incluyó en el informe. El etiquetado lo hizo un analista con conocimiento de los estándares de calidad de los listados, y los casos dudosos se resolvieron en sesiones con el equipo de AWS.

La decisión clave fue pasar de una sola etiqueta a multilabel. Una foto de un pasillo con un dormitorio en el umbral de la puerta contiene, en efecto, ambas habitaciones. Las métricas se eligieron según la tarea: Micro F1 como principal, Macro F1 para las clases poco frecuentes, precision/recall por etiqueta, IoU a nivel de muestra y, para los nueve atributos de etiqueta única, también exact-match accuracy.

Los autores describen la optimización por analogía con el aprendizaje por refuerzo: la versión del prompt actúa como agente, el Micro F1 como recompensa y el análisis de errores sustituye al gradiente. La idea se parece a GEPA. La mayoría de las versiones surgió del análisis de imágenes erróneas con ayuda de asistentes de IA, y en la v27 se incorporó MIPROv2 de DSPy para clasificar fotos.

Qué funcionó, paso a paso:

• v0: prompt genérico con clasificación a partir de una lista de habitaciones • salida estructurada y definiciones de los atributos • regla de clasificar según la habitación que ocupa la mayor parte del encuadre • reglas regionales: una inscripción decorativa en árabe no cuenta como marca de agua, lo que eliminó toda una clase de falsos positivos • v21: multilabel para la foto y la categoría de habitación, punto de partida común para todos los modelos; Llama 4 Maverick obtuvo un Micro F1 de 0,75 en el conjunto de desarrollo • v24: corrección de la sobreestimación del tamaño de las habitaciones, multilabel, formato de salida • v25: versión autooptimizada, con las tareas críticas movidas al principio • v27: MIPROv2 reconstruyó la clasificación de fotos, con un Micro F1 de 0,76 en esa tarea • v27_PF: además, reglas de Property Finder para renders, marcos y pasillos, y normalización del formato tras cada llamada

Los fracasos también resultaron útiles. Separar el análisis en dos llamadas, una para las marcas de agua y otra para el resto, no aportó una mejora apreciable, y la detección de imágenes con marco empeoró mucho: sin el contexto de las marcas de agua, los modelos confundían los overlays con bordes. Los prompts universales no funcionaron con ningún modelo.

Cifras, salvedades y coste

Sobre las 356 imágenes, Llama 4 Maverick 17B Instruct con v27_PF obtuvo un Micro F1 de 0,80, y el modelo propietario A con v22, 0,56. En el conjunto de desarrollo, el cambio de modelo con sus prompts ajustados elevó la métrica de 0,55 a 0,81, es decir, un 47% en términos relativos. Solo el ajuste del prompt en Llama la subió de 0,75 a 0,81. Los autores advierten con honestidad de que el conjunto de evaluación incluye imágenes de desarrollo, por lo que las cifras son optimistas. Además, Llama recibió más ajuste (de v24 a v27, más las reglas del cliente), mientras que el modelo A tuvo una sola ronda, la v22.

Exact-match en los atributos de etiqueta única sobre las 356 imágenes:

• detección de rotación: 100% • personas en el encuadre: 97% • imagen con marco: 97% • marcas de agua: 94% • renders: 93% • estado del mobiliario: 91% • habitación en fase de construcción: 81% • tamaño de la habitación: 65% • extracción del texto de marcas de agua: 55%

El modelo alcanzó el 90% o más en seis de los nueve atributos e igualó o superó al modelo A en los 11, mientras que en la clasificación de fotos el resultado es idéntico. Los puntos débiles son evidentes: el tamaño de la habitación y el OCR de marcas de agua.

El coste se estima en $2,35 por 1000 imágenes (US East, Ohio, diciembre de 2025), un 86% menos que con el esquema anterior. El cálculo parte de 9000 tokens de entrada y 200 de salida por imagen en un análisis de dos llamadas. El prompt real de producción en una sola llamada ocupa entre 7500 y 8000 tokens de entrada, de modo que la cifra es un tope superior. La comparación se hace con la estimación de la configuración anterior en v21, no en v22, por lo que su coste puede variar. La latencia de inferencia, según la monitorización propia de Property Finder, bajó entre un 40% y un 60%.

Qué conviene comprobar en tu equipo

Empieza por auditar las etiquetas: si proceden de predicciones de un modelo, tienes el mismo problema. Hacen falta varios cientos de muestras representativas con etiquetado experto independiente y una partición de prueba aparte que nunca participe en el ajuste. Para atributos que se solapan, usa métricas multilabel y mira el Macro F1 junto al Micro. Corrige los prompts a partir del análisis de imágenes erróneas concretas y mantén un candidato por familia de modelos. Para ampliar el dataset, los autores proponen un enfoque híbrido: modelos de distintas familias sugieren etiquetas y detectan discrepancias, y las personas emiten el veredicto en cada caso.