Corrige el sesgo de evaluación para desbloquear mejores modelos en Amazon Bedrock

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

El equipo de ingeniería de Property Finder, una aplicación digital de bienes raíces, descubrió que el 96.8 por ciento de sus etiquetas de evaluación se habían heredado directamente de las predicciones de un solo modelo en lugar de ser verificadas por expertos humanos. Su verdad fundamental estaba sistemáticamente sesgada hacia el modelo incumbente, haciendo que cada alternativa pareciera tener un rendimiento inferior. Las etiquetas también tenían errores, pero el sesgo era lo que impedía la comparación objetiva de modelos. Descubrieron esto al migrar su carga de trabajo de visión AI a una opción más rentable en Amazon Bedrock.

Property Finder procesa decenas de miles de imágenes de propiedades cada día en Medio Oriente y el norte de África (MENA). Su sistema evalúa 11 atributos de calidad por imagen. Estos abarcan la detección de marcas de agua, la clasificación de habitaciones, el estado del amueblado, la calidad de la foto y los indicadores de construcción. Son miles de nuevas propiedades listadas con un promedio de 15 imágenes cada una. Todas necesitan una evaluación de calidad antes de publicarse.

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

La parte más difícil no fue encontrar un mejor modelo. 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, construyó una verdad fundamental sin sesgos y aplicó optimización evolutiva de prompts para seleccionar el modelo adecuado en Amazon Bedrock, logrando una mayor precisión con un costo 86 por ciento menor. Repasamos la metodología y ejemplos de iteración, con lecciones que puede aplicar a sus propias cargas de trabajo.

La siguiente figura ilustra el bucle de optimización de prompts que el equipo de Property Finder y el AWS Generative AI Innovation Center utilizaron para mejorar iterativamente la precisión de clasificación en Amazon Bedrock.

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

El diagrama muestra el ciclo iterativo de optimización de prompts. Una imagen de propiedad es procesada por Amazon Bedrock, que genera los atributos predichos en formato JSON. Durante la optimización, estas predicciones se puntúan con Micro F1 contra el conjunto de desarrollo de 256 imágenes anotadas por expertos. Luego, el análisis de errores examina las imágenes fallidas e identifica patrones visuales, lo que informa la siguiente versión del prompt. El bucle se ejecutó desde la v0 hasta la v27. Los asistentes de IA ayudaron a refinar los prompts, y las versiones posteriores utilizaron optimización automatizada.

Su evaluación podría estar mintiendo

Muchos equipos se encuentran con este escenario. Quiere comparar modelos de visión, así que construye un conjunto de datos de evaluación. La forma más común de obtener etiquetas es ejecutar su modelo actual y tratar sus salidas como verdad fundamental. El modelo ha estado funcionando 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 qué tan cerca coincide con el comportamiento del incumbente, no por su 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 visual (VLM) existente en lugar de una verificación humana independiente. Cualquier modelo alternativo estaba estructuralmente en desventaja antes de procesar una sola imagen.

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

En el 3.2 por ciento restante de muestras etiquetadas por humanos, los anotadores habían introducido categorías fuera de la especificación original, como Office apareciendo donde no existía tal etiqueta en el prompt. Una comparación de modelos pierde validez cuando la clave de respuestas fue escrita por el modelo que intenta reemplazar.

Construyendo una verdad fundamental en la que pueda confiar

Para romper el ciclo, necesita expertos humanos con conocimiento real del dominio realizando anotaciones nuevas de forma independiente. Sin referencia a salidas de modelos anteriores. Sin acceso a lo que predijo el incumbente.

Alcance del conjunto de datos

El equipo de Property Finder anotó a mano 356 imágenes de EAU y un conjunto separado de imágenes de Egipto. El equipo seleccionó estas imágenes de listados de producción sin etiquetar a través de segmentos representativos de la industria. Esta publicación reporta resultados sobre las imágenes de EAU. Las imágenes de Egipto sirvieron como una verificación cruzada regional sobre 230 imágenes y no se reportan aquí. Las primeras 256 imágenes de EAU en anotarse formaron el conjunto de desarrollo para el ajuste. El conjunto de evaluación para la comparación final de modelos usa las 356, añadiendo 100 imágenes anotadas después de las ejecuciones de desarrollo. Un conjunto de 356 imágenes es aproximadamente suficiente para detectar diferencias moderadas entre modelos. Las clases raras dentro de atributos individuales tienen menos ejemplos, por lo que las diferencias más pequeñas en esos atributos podrían no ser detectables.

Anotación por expertos

Un experto en estrategia y analítica anotó todas las imágenes. Aportó conocimiento especializado en los estándares de calidad de listados de bienes raíces. El equipo del AWS Generative AI Innovation Center realizó revisiones de calidad sistemáticas a través de sesiones dedicadas de aclaración. Esas revisiones resolvieron los casos ambiguos y mantuvieron el etiquetado consistente en todo el conjunto de datos.

Transición a etiquetas múltiples

Las imágenes de bienes raíces frecuentemente muestran varias habitaciones a través de puertas o presentan cualidades de calidad superpuestas. El cambio de clasificación de una sola etiqueta a clasificación multietiqueta alivió una fuente importante de ambigüedad artificial.

Una foto de un pasillo que muestra un dormitorio a través de una puerta es genuinamente ambas cosas. Cuando permites múltiples etiquetas, mides lo que el modelo acierta en lugar de penalizarlo por predicciones secundarias razonables.

Un enfoque híbrido podría complementar esta metodología: los modelos de diferentes familias identifican etiquetas candidatas y desacuerdos, y expertos humanos adjudican cada caso, de modo que ninguna salida de modelo se use directamente como etiqueta. Esto reduciría la carga de anotación para futuras expansiones del conjunto de datos.

Selección de métricas

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

Optimización de prompts como aprendizaje por refuerzo

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

La optimización sigue un bucle análogo al aprendizaje por refuerzo. Piensa en cada versión del prompt como un agente, en la puntuación de Micro F1 como la señal de recompensa, y en el análisis de errores como el gradiente para la mejora. La idea se parece a GEPA (evolución reflexiva de prompts genética-Pareto), donde mutas componentes del prompt, evalúas la aptitud, seleccionas los supervivientes e iteras. En este encargo, el equipo de AWS refinó la mayoría de las versiones a partir del análisis de errores, con asistentes de IA revisando las imágenes fallidas y proponiendo cambios.

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

Dónde empezó

El primer prompt (v0) usaba instrucciones de clasificación genéricas, simplificadas aquí a modo de ilustración:

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

El modelo propietario A, la línea base de producción de Property Finder, obtuvo un Micro F1 de 0.55 en el conjunto de desarrollo de 256 imágenes. Usaba la v22, un prompt ajustado para su familia de modelos. Las puntuaciones anteriores a la v21 usaban la configuración anterior de una sola etiqueta y no son directamente comparables.

Iteración a iteración

El equipo de AWS probó las primeras versiones en varios modelos candidatos y añadió formato de salida estructurado y definiciones específicas por atributo.

La corrección más ilustrativa vino del análisis de errores a nivel de imagen. En las primeras versiones de una sola etiqueta, el modelo clasificaba consistentemente las habitaciones visibles a través de las puertas como el tipo de habitación secundario. El equipo del AWS Generative AI Innovation Center añadió instrucciones explícitas para clasificar según la habitación que ocupara la mayoría del encuadre. El posterior cambio a salida multietiqueta mantuvo la habitación principal como etiqueta y permitió que las habitaciones visibles a través de puertas fueran etiquetas adicionales.

La personalización regional produjo la siguiente ganancia. En algunas regiones, las fotos de los anuncios llevan superposiciones decorativas de texto en árabe que no son marcas de agua. Las reglas para ese texto eliminaron toda una categoría de falsos positivos.

El prompt v21 cambió la clasificación de fotos y la categoría de habitación a salida multietiqueta y se convirtió en el prompt inicial compartido para todos los modelos. Con él, 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ó el prompt de cada modelo por separado. Para este modelo, la v24 se centró en la sobreestimación del tamaño de las habitaciones, el manejo multietiqueta y el formato de salida. Luego la v25, una versión optimizada automáticamente, movió las tareas críticas al principio. En la v27, MIPROv2 reestructuró la tarea de clasificación de fotos, y el Micro F1 del modelo en esa tarea llegó a 0.76.

Dónde terminó

El prompt final, v27_PF, es la v27 más las reglas que Property Finder añadió para renders, imágenes con bordes o marcos, y pasillos. Como la v27, conserva las reglas del texto en árabe y las instrucciones de formato de salida. Un paso de normalización después de cada llamada al modelo gestiona las diferencias de formato restantes.

Con la 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 la v22. El conjunto de evaluación incluye las 256 imágenes de desarrollo, y los prompts de ambos modelos se ajustaron sobre esas imágenes. Estas puntuaciones son, por lo tanto, optimistas.

El cambio del modelo propietario A a Llama 4 Maverick 17B Instruct, cada uno con su propio prompt ajustado, elevó el Micro F1 de 0.55 a 0.81 en el conjunto de desarrollo. Eso es una ganancia relativa del 47 por ciento. Solo el ajuste del prompt, en Llama 4 Maverick 17B Instruct, lo elevó de 0.75 con el prompt compartido v21 a 0.81 con la v27.

Lecciones de enfoques fallidos

No todo tuvo éxito. El 2-bucket enfoque consistía en poner los atributos de la marca de agua y los otros atributos en dos llamadas API separadas. No aportó ninguna mejora significativa en la precisión. La detección de imágenes enmarcadas también cayó bruscamente. Sin los atributos de la marca de agua en el mismo prompt, los modelos confundían las superposiciones de marca de agua con bordes de imagen.

Los prompts genéricos también fallaron independientemente del modelo con el que se ejecutaran. Las imágenes inmobiliarias tienen demasiada especificidad de dominio para una instrucción única que sirva para todo.

Resultados: costo, precisión y velocidad

El equipo del AWS Generative AI Innovation Center evaluó varios modelos en Amazon Bedrock con el marco de evaluación imparcial. Todos los modelos partieron del prompt compartido v21 y luego se ajustaron para su familia de modelos en el conjunto de desarrollo. El modelo propietario A recibió una ronda de ajuste, v22. Llama 4 Maverick 17B Instruct recibió varias, de la v24 a la v27, además de las reglas de casos límite de Property Finder, por lo que tuvo más esfuerzo de ajuste detrás. La comparación final contra 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 los 11 atributos y la eficiencia de costos. Para conocer la disponibilidad de modelos por Región, consulte Modelos admitidos 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 el 90 por ciento o más en seis de los nueve, e igualó o superó al modelo propietario A en los 11 atributos. En la clasificación de fotos, que puede tener varias etiquetas por imagen, ambos obtuvieron la misma puntuación.

Costo por 1,000 imágenes

Property Finder puntúa decenas de miles de imágenes al día, por lo que el costo por imagen importa. Llama 4 Maverick 17B Instruct es un modelo de pesos abiertos rentable, y el pipeline obtiene todos los atributos de una imagen en una sola llamada.

Estas cifras son estimaciones a diciembre de 2025 en la Región US East (Ohio). La cifra 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 costos original de dos llamadas. Una sola llamada con el prompt de producción conlleva unos 7,500–8,000 tokens de entrada, por lo que esta es una estimación por encima. El 86 por ciento lo compara con la estimación del análisis de costos para la configuración anterior de Property Finder, que usaba el prompt v21. La comparación de precisión usó la v22, que se ajustó a partir de la v21, por lo que su costo podría diferir. Para conocer los precios actuales, consulte Precios de Amazon Bedrock.

Velocidad de inferencia

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

Aplique 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 Property Finder encontró.

Cree una verdad de terreno de expertos de dominio para unos pocos cientos de muestras representativas, y mantenga una división de prueba separada que nunca use para el ajuste. Adopte métricas multietiqueta donde su tarea de clasificación involucre atributos superpuestos. Luego itere en los prompts usando análisis de errores de imagen, tratando cada iteración como una generación en un bucle de optimización evolutiva.

Cuando implemente un pipeline como este, agregue controles de IA responsable. Por ejemplo, puede usar Amazon Bedrock Guardrails para aplicar políticas de contenido y filtrar salidas inapropiadas del modelo. Las predicciones de atributos en este pipeline no vienen con una puntuación de confianza calibrada, así que use una señal práctica para elegir imágenes para revisión humana. El desacuerdo entre modelos es una de esas señales. Cuando dos modelos dan respuestas diferentes para un atributo, la imagen a menudo es ambigua. Un segundo modelo en cada imagen agrega costo, por lo que puede comenzar con una muestra. Verifique con qué frecuencia la señal detecta errores reales en su conjunto de desarrollo antes de confiar en ella.

Conclusión

En esta publicación, recorrimos cómo Property Finder identificó el sesgo de evaluación, construyó una verdad de terreno imparcial y aplicó la optimización evolutiva de prompts para lograr una mejor precisión a un menor costo mediante la selección de modelos en Amazon Bedrock.

Para este resultado debían concurrir tres elementos: una evaluación imparcial para medir con honestidad, la flexibilidad de evaluar y cambiar entre familias de modelos sin replataformar, y prompts cuidadosamente evolucionados y adaptados al dominio. Amazon Bedrock proporcionó la base. Dio a Property Finder acceso a múltiples familias de modelos a través de una única 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 comenzar con la evaluación y selección de 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, contacte con el AWS Generative AI Innovation Center.

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

Agradecimientos

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

Sobre los autores