Esta publicación fue coautoria con Khaled Thabit, Meriem Boughrara y Mohamed Desouky de Property Finder.

El equipo de ingeniería de Property Finder, una aplicación de bienes raíces digitales, descubrió que el 96,8 por ciento de sus etiquetas de evaluación habían sido heredadas directamente de las predicciones de un solo modelo en lugar de ser verificadas por expertos humanos. Su verdad fundamental estaba sesgada sistemáticamente hacia el modelo vigente, lo que hizo que todas las alternativas parecieran tener un rendimiento inferior. Las etiquetas también tenían errores, pero el sesgo era lo que bloqueaba la comparación objetiva de los modelos. Descubrieron esto al migrar su carga de trabajo de visión de IA a una opción más rentable en Amazon Bedrock.

Property Finder procesa decenas de miles de imágenes de propiedades todos los días en Oriente Medio y África del Norte (MENA). Su sistema evalúa 11 atributos de calidad por imagen. Estos cubren la detección de marcas de agua, la clasificación de habitaciones, el estado de amueblamiento, la calidad de la foto y los indicadores de construcción. Eso es miles de nuevas listas de propiedades con un promedio de 15 imágenes cada una. Todas necesitan una evaluación de calidad antes de estar en vivo.

Property Finder necesitaba una opción más rentable. Pero medido contra esas etiquetas, cualquier alternativa estaba en desventaja.

La parte más difícil no fue encontrar un modelo mejor. Fue descubrir que su propia metodología de evaluación era el obstáculo.

En esta publicación, compartimos cómo Property Finder identificó el sesgo de evaluación, creó una verdad fundamental imparcial y aplicó la optimización evolutiva de instrucciones para seleccionar el modelo correcto en Amazon Bedrock, logrando una mayor precisión a un costo 86 por ciento menor. Pasamos por la metodología y los ejemplos de iteración, con lecciones que puedes aplicar a tus propias cargas de trabajo.

La siguiente figura ilustra el bucle de optimización de instrucciones que Property Finder y el equipo de Innovación de IA Generativa de AWS utilizaron para mejorar iterativamente la precisión de clasificación en Amazon Bedrock.

Figura 1: Arquitectura del bucle de optimización de instrucciones

El diagrama muestra el ciclo de optimización de la solicitud iterativa. Una imagen de propiedad es procesada por Amazon Bedrock, que produce los atributos predichos en formato JSON. Durante la optimización, estas predicciones se califican con Micro F1 contra el conjunto de desarrollo de 256 imágenes anotadas por expertos. El análisis de errores inspecciona entonces las imágenes fallidas e identifica patrones visuales, que informan la próxima versión de la solicitud. El bucle se ejecutó desde la v0 hasta la v27. Los asistentes de IA ayudaron a refinar las solicitudes, y las versiones posteriores utilizaron la optimización automatizada.

Tu evaluación podría estar mintiendo

Muchos equipos se encuentran con este escenario. Quieres comparar modelos de visión, así que creas un conjunto de datos de evaluación. La forma más común de obtener etiquetas es ejecutar tu modelo actual y tratar sus salidas como verdad fundamental. El modelo ha estado ejecutándose en producción y nadie se quejó, así que las etiquetas deben ser lo suficientemente buenas.

Pero esto crea una evaluación circular donde cualquier alternativa se juzga por lo cerca que se ajusta al comportamiento del titular, no por la corrección real.

El conjunto de datos de evaluación de Property Finder tenía exactamente este problema. De sus muestras etiquetadas, el 96,8 por ciento provenía directamente de las predicciones del modelo de lenguaje de visión existente (VLM) en lugar de la verificación humana independiente. Cualquier modelo alternativo estaba estructuralmente desfavorecido antes de que se procesara una sola imagen.

Los errores ocultos confirmaron la gravedad. La extracción de texto de agua tenía errores a nivel de carácter marcados como correctos, incluyendo nombres de marcas alucinados y caracteres faltantes. La clasificación de fotos forzó etiquetas únicas en imágenes que contenían varios tipos de habitaciones.

En el 3,2 por ciento restante de las muestras etiquetadas por humanos, los anotadores habían introducido categorías fuera de la especificación original, como Oficina que aparecía donde no existía tal etiqueta en la solicitud. Una comparación de modelos pierde validez cuando la clave de respuesta fue escrita por el modelo que estás tratando de reemplazar.

Construyendo una verdad fundamental en la que puedes confiar

Para romper el ciclo, necesitas expertos humanos con conocimientos reales del dominio que realicen anotaciones frescas de forma independiente. Sin referencia a las salidas de modelos anteriores. Sin acceso a lo que el titular predijo.

Alcance del conjunto de datos

El equipo de Property Finder anotó manualmente 356 imágenes de los Emiratos Árabes Unidos y un conjunto separado de imágenes de Egipto. El equipo seleccionó estas imágenes de listados de producción no etiquetados en segmentos de la industria representativos. Este artículo informa los resultados sobre las imágenes de los Emiratos Árabes Unidos. Las imágenes de Egipto sirvieron como una verificación transregional de 230 imágenes y no se informan aquí. Las primeras 256 imágenes de los Emiratos Árabes Unidos que se anotaron formaron el conjunto de desarrollo para la afinación. El conjunto de evaluación para la comparación final del modelo utiliza las 356 imágenes, agregando 100 imágenes anotadas después de las corridas de desarrollo. Un conjunto de 356 imágenes es aproximadamente suficiente para detectar diferencias moderadas entre modelos. Las clases raras dentro de los atributos individuales tienen menos ejemplos, por lo que las diferencias más pequeñas en esos atributos pueden no ser detectables.

Anotación de expertos

Un experto en estrategia y análisis anotó todas las imágenes. Trajo conocimientos especializados sobre los estándares de calidad de los listados de bienes raíces. El equipo del AWS Generative AI Innovation Center realizó revisiones de calidad sistemáticas a través de sesiones de aclaración dedicadas. Esas revisiones resolvieron casos ambiguos y mantuvieron la etiquetación coherente en todo el conjunto de datos.

Transición a multi-etiqueta

Las imágenes de bienes raíces frecuentemente muestran varias habitaciones a través de puertas o muestran características de calidad superpuestas. El cambio de clasificación de una sola etiqueta a multi-etiqueta mitigó una gran fuente de ambigüedad artificial.

Una foto de un pasillo que muestra un dormitorio a través de una puerta es genuinamente ambos. Después de permitir varias etiquetas, se mide lo que el modelo acierta en lugar de penalizarlo por predicciones secundarias razonables.

Un enfoque híbrido podría complementar esta metodología: modelos de diferentes familias generan etiquetas candidatas y desacuerdos, y expertos humanos resuelven cada caso, por lo que no se utiliza directamente la salida del modelo como etiqueta. Esto reduciría la carga de anotación para la expansión futura del conjunto de datos.

Selección de métricas

Micro F1 sirvió como la métrica principal porque pondera cada predicción de manera igualitaria, lo que coincide con el objetivo empresarial de corrección general de etiquetas. Macro F1 se informó junto con ella porque Micro F1 está dominada por clases frecuentes y puede ocultar un rendimiento débil en atributos raros. La precisión y el recuerdo por etiqueta ayudaron a identificar modos de fallo específicos. La intersección sobre la unión (IoU) por muestra midió cuán estrechamente las etiquetas predichas de cada imagen se superponían con las etiquetas del experto. Los nueve atributos de una sola etiqueta, como la detección de rotación o de marcas de agua, tienen una respuesta correcta por imagen. El equipo de AWS también los puntuó con precisión de coincidencia exacta, la participación de imágenes donde la respuesta coincide con la etiqueta del experto.

Optimización de la invitación como aprendizaje de refuerzo

Con una evaluación imparcial en su lugar, puede comenzar a mejorar. No puede mejorar lo que no puede medir correctamente.

La optimización sigue un bucle análogo al aprendizaje por refuerzo. Piensa en cada versión de la solicitud como un agente, la puntuación Micro F1 como la señal de recompensa y el análisis de errores como el gradiente para la mejora. La idea se asemeja a GEPA (evolución reflexiva de solicitudes genéticas-pareto), donde mutas componentes de la solicitud, evalúas la idoneidad, seleccionas supervivientes e iteras. En este compromiso, el equipo de AWS refinó la mayoría de las versiones a partir del análisis de errores, con asistentes de IA que revisaban imágenes fallidas y proponían cambios.

MIPROv2, un marco de optimización de solicitudes automatizado de la biblioteca DSPy, complementó este proceso manual para la tarea de clasificación de fotos en v27.

Donde empezó

La primera solicitud (v0) utilizó instrucciones de clasificación genéricas, simplificadas aquí para ilustrar:

“Clasifica esta imagen en una de las siguientes categorías: Sala de estar, Cocina, Dormitorio, Baño…”

El modelo propietario A, la línea de base de producción de Property Finder, obtuvo una puntuación Micro F1 de 0,55 en el conjunto de desarrollo de 256 imágenes. Utilizó v22, una solicitud ajustada para su familia de modelos. Las puntuaciones antes de v21 utilizaron la configuración de etiqueta única anterior y no son directamente comparables.

Iteración por iteración

El equipo de AWS probó versiones tempranas en varios modelos candidatos y agregó formato de salida estructurado y definiciones específicas de atributos.

El arreglo más instructivo provino del análisis de errores a nivel de imagen. En las versiones tempranas de etiqueta única, el modelo clasificó consistentemente las habitaciones visibles a través de puertas como el tipo de habitación secundaria. El equipo de Innovación de IA Generativa de AWS agregó instrucciones explícitas para clasificar según la habitación que ocupa la mayoría del marco. El posterior cambio a salida de etiqueta múltiple mantuvo la habitación principal como etiqueta y permitió habitaciones visibles a través de puertas como etiquetas adicionales.

La personalización regional produjo la siguiente ganancia. En algunas regiones, las fotos de listados llevan sobrepuestas decorativas textos árabes que no son filigranas. Las reglas para ese texto eliminaron toda una categoría de falsos positivos.

La invitación v21 cambió la clasificación de fotos y la categoría de habitaciones a salida de varias etiquetas y se convirtió en la invitación de inicio compartida para cada modelo. Con ella, Llama 4 Maverick 17B Instruct de Meta obtuvo un Micro F1 de 0,75 en el conjunto de desarrollo. A partir de ahí, el equipo de AWS ajustó la invitación de cada modelo por separado. Para este modelo, v24 se centró en la sobreestimación del tamaño de la habitación, el manejo de varias etiquetas y el formato de salida. Luego, v25, una versión optimizada automáticamente, movió las tareas críticas al principio. En v27, MIPROv2 reestructuró la tarea de clasificación de fotos, y el Micro F1 del modelo en esa tarea alcanzó 0,76.

Donde terminó

La invitación final, v27_PF, es v27 más las reglas que Property Finder agregó para renders, imágenes con bordes o marcos y corredores. Al igual que v27, mantiene las reglas de texto en árabe y las instrucciones de formato de salida. Un paso de normalización después de cada llamada al modelo maneja las diferencias de formato restantes.

Con v27_PF, Llama 4 Maverick 17B Instruct obtuvo un Micro F1 de 0,80 en el conjunto de evaluación de 356 imágenes, donde el modelo propietario A obtuvo 0,56 con v22. El conjunto de evaluación incluye las 256 imágenes de desarrollo, y las invitaciones de ambos modelos se ajustaron en esas imágenes. Por lo tanto, estas puntuaciones son optimistas.

El cambio del modelo propietario A a Llama 4 Maverick 17B Instruct, cada uno con su propia invitación ajustada, elevó el Micro F1 de 0,55 a 0,81 en el conjunto de desarrollo. Eso es una ganancia relativa del 47 por ciento. El ajuste de la invitación solo, en Llama 4 Maverick 17B Instruct, lo elevó de 0,75 con la invitación compartida v21 a 0,81 con v27.

Lecciones de enfoques fallidos

No todo funcionó. El enfoque de 2-bucket puso los atributos de marca de agua y los demás atributos en dos llamadas a la API separadas. No trajo ninguna ganancia de precisión significativa. La detección de imágenes enmarcadas también disminuyó bruscamente. Sin los atributos de marca de agua en la misma invitación, los modelos confundieron las superposiciones de marca de agua con bordes de imagen.

Las invitaciones genéricas también fallaron independientemente del modelo que se ejecutara en ellas. La imaginería inmobiliaria tiene demasiada especificidad de dominio para una instrucción de un tamaño que se adapte a todos.

Resultados: Costo, precisión y velocidad

El equipo del Centro de Innovación de Inteligencia Artificial Generativa de AWS evaluó múltiples modelos en Amazon Bedrock con el marco de evaluación imparcial. Todos los modelos comenzaron con la llamada compartida v21 y luego se ajustaron para su familia de modelos en el conjunto de desarrollo. El modelo propietario A obtuvo una ronda de ajuste, v22. Llama 4 Maverick 17B Instruct obtuvo varias, v24 a v27, además de las reglas de casos de borde de Property Finder, por lo que tenía más esfuerzo de ajuste detrás de él. La comparación final con el modelo propietario A utilizó el conjunto de evaluación de 356 imágenes. Property Finder seleccionó Llama 4 Maverick 17B Instruct para su carga de trabajo de producción en función de la precisión en todos los 11 atributos y la eficiencia de costo. Para obtener la disponibilidad de modelos por región, consulte Modelos compatibles por región de AWS en Amazon Bedrock.

La siguiente tabla muestra la precisión de coincidencia exacta que Llama 4 Maverick 17B Instruct (v27_PF) alcanzó en cada atributo de etiqueta única, puntuado en el conjunto de evaluación de 356 imágenes. Obtuvo un 90 por ciento o más en seis de los nueve, y coincidió o superó al modelo propietario A en todos los 11 atributos. En la clasificación de fotos, que puede tener varias etiquetas por imagen, los dos obtuvieron la misma puntuación.

Costo por 1,000 imágenes

Property Finder puntuación de decenas de miles de imágenes al día, por lo que el costo por imagen es importante. Llama 4 Maverick 17B Instruct es un modelo de peso abierto rentable, y el pipeline obtiene todos los atributos para una imagen en una sola llamada.

Estas cifras son estimaciones a partir de diciembre de 2025 en la región US East (Ohio). La figura de Llama 4 Maverick 17B Instruct supone 9,000 tokens de entrada y 200 tokens de salida por imagen, según el análisis de costo original de dos llamadas. Una sola llamada con el prompt de producción lleva alrededor de 7,500–8,000 tokens de entrada, por lo que esta es una estimación superior. El 86 por ciento la compara con la estimación del análisis de costo para la configuración anterior de Property Finder, que utilizó el prompt v21. La comparación de precisión utilizó v22, que se ajustó desde v21, por lo que su costo puede ser diferente. Para obtener los precios actuales, consulte los precios de Amazon Bedrock.

Velocidad de inferencia

Property Finder ejecuta esta pipeline optimizada en producción, procesando decenas de miles de imágenes diarias con Llama 4 Maverick 17B Instruct en Amazon Bedrock. En su propia supervisión, Property Finder observó una reducción del 40–60 por ciento en la latencia de inferencia en comparación con su configuración anterior.

Aplicar esto a sus cargas de trabajo

Comience auditando sus etiquetas de evaluación. Si provienen de predicciones de modelos en lugar de expertos humanos, tiene el mismo problema de sesgo que encontró Property Finder.

Construya una verdad fundamental de expertos en el dominio para unos pocos cientos de muestras representativas y mantenga una división de prueba separada que nunca utilice para ajuste. Adopte métricas de multi-etiqueta donde su tarea de clasificación involucra atributos superpuestos. Luego, itere sobre los prompts utilizando el análisis de errores de imagen, tratando cada iteración como una generación en un bucle de optimización evolutiva.

Cuando despliegue una pipeline como esta, agregue controles de AI responsables. Por ejemplo, puede utilizar Amazon Bedrock Guardrails para hacer cumplir las políticas de contenido y filtrar salidas de modelo inapropiadas. Las predicciones de atributos en esta pipeline no vienen con una puntuación de confianza calibrada, por lo que utilice una señal de alerta práctica para elegir imágenes para revisión humana. La discrepancia del modelo es una señal de alerta de este tipo. Cuando dos modelos dan respuestas diferentes para un atributo, la imagen es a menudo ambigua. Un segundo modelo en cada imagen agrega costo, por lo que puede comenzar con una muestra. Verifique con qué frecuencia la señal de alerta detecta errores reales en su conjunto de desarrollo antes de confiar en ella.

Conclusión

En esta publicación, pasamos por cómo Property Finder identificó el sesgo de evaluación, construyó una verdad fundamental sin sesgo y aplicó la optimización evolutiva de prompts para lograr una mejor precisión a un costo más bajo a través de la selección de modelo en Amazon Bedrock.

Tres elementos necesitaban unirse para lograr este resultado: una evaluación imparcial para medir honestamente, la flexibilidad para evaluar y cambiar entre familias de modelos sin volver a plataforma, y instrucciones cuidadosamente evolucionadas adaptadas al dominio. Amazon Bedrock proporcionó la base. Proporcionó a Property Finder acceso a varias familias de modelos a través de una sola API, heredó los controles de gobernanza y seguridad de AWS y la capacidad de adoptar nuevos modelos a medida que estén disponibles sin cambiar su infraestructura.

Para empezar a evaluar y seleccionar modelos en Amazon Bedrock, visite la documentación de Amazon Bedrock. Si procesa cargas de trabajo de visión a gran escala y desea ayuda para crear un marco de evaluación imparcial, comuníquese con el Centro de Innovación de Inteligencia Artificial Generativa de AWS.

Comparta sus experiencias con la evaluación de modelos y la optimización de instrucciones en los comentarios.

Reconocimientos

Contribuyentes adicionales de AWS incluyen a Yousuf Albannai, Amine Sehili, Thomas Ounnas, Aris Tsakpinis, Rafik Soliman, Nikhil Ulhas Pandit y Sneh Sharma.

Acerca de los autores