Cet article a été co-rédigé avec Khaled Thabit, Meriem Boughrara et Mohamed Desouky de Property Finder.
L'équipe d'ingénierie de Property Finder, une application numérique immobilière, a découvert que 96,8 % de leurs étiquettes d'évaluation avaient été héritées directement des prédictions d'un seul modèle plutôt que vérifiées par des experts humains. Leur vérité terrain était systématiquement biaisée en faveur du modèle en place, faisant apparaître chaque alternative comme moins performante. Les étiquettes comportaient également des erreurs, mais c'est le biais qui empêchait toute comparaison objective des modèles. Ils l'ont découvert lors de la migration de leur charge de travail de vision par IA vers une option plus rentable sur Amazon Bedrock.
Property Finder traite des dizaines de milliers d'images de biens immobiliers chaque jour au Moyen-Orient et en Afrique du Nord (MENA). Leur système évalue 11 attributs de qualité par image. Ceux-ci couvrent la détection de filigranes, la classification des pièces, l'état de l'ameublement, la qualité des photos et les indicateurs de construction. Cela représente des milliers de nouvelles annonces immobilières avec en moyenne 15 images chacune. Toutes nécessitent une évaluation de qualité avant leur mise en ligne.
Property Finder avait besoin d'une option plus rentable. Mais mesuré par rapport à ces étiquettes, toute alternative était désavantagée.
La partie la plus difficile n'était pas de trouver un meilleur modèle. C'était de découvrir que leur méthodologie d'évaluation elle-même était l'obstacle.
Dans cet article, nous expliquons comment Property Finder a identifié le biais d'évaluation, construit une vérité terrain impartiale et appliqué l'optimisation évolutive de prompts pour sélectionner le bon modèle sur Amazon Bedrock, atteignant une précision supérieure à un coût inférieur de 86 %. Nous présentons la méthodologie et des exemples d'itérations, avec des leçons applicables à vos propres charges de travail.
La figure suivante illustre la boucle d'optimisation de prompts que Property Finder et l'équipe de l'AWS Generative AI Innovation Center ont utilisée pour améliorer itérativement la précision de classification sur Amazon Bedrock.
Figure 1 : Architecture de la boucle d'optimisation de prompts
Le diagramme montre le cycle itératif d'optimisation de prompts. Une image de bien immobilier est traitée par Amazon Bedrock, qui produit les attributs prédits au format JSON. Pendant l'optimisation, ces prédictions sont notées avec le Micro F1 par rapport à l'ensemble de développement de 256 images annotées par des experts. L'analyse des erreurs examine ensuite les images échouées et identifie les motifs visuels, qui orientent la version suivante du prompt. La boucle s'est déroulée de v0 à v27. Des assistants IA ont aidé à affiner les prompts, et les versions ultérieures ont utilisé une optimisation automatisée.
Votre évaluation pourrait vous mentir
Beaucoup d'équipes rencontrent ce scénario. Vous souhaitez comparer des modèles de vision, vous construisez donc un jeu de données d'évaluation. La façon la plus courante d'obtenir des étiquettes est d'exécuter votre modèle actuel et de considérer ses sorties comme vérité terrain. Le modèle tourne en production et personne ne s'est plaint, donc les étiquettes doivent être suffisamment bonnes.
Mais cela crée une évaluation circulaire où toute alternative est jugée selon sa proximité avec le comportement du modèle en place, et non selon son exactitude réelle.
Le jeu de données d'évaluation de Property Finder avait exactement ce problème. De leurs échantillons étiquetés, 96,8 % provenaient directement des prédictions du modèle de langage visuel (VLM) existant plutôt que d'une vérification humaine indépendante. Tout modèle alternatif était structurellement désavantagé avant même qu'une seule image ne soit traitée.
Des erreurs cachées ont confirmé la gravité du problème. L'extraction du texte des filigranes comportait des erreurs au niveau des caractères marquées comme correctes, incluant des noms de marques hallucinés et des caractères manquants. La classification des photos imposait des étiquettes uniques à des images contenant plusieurs types de pièces.
Dans les 3,2 % restants d'échantillons étiquetés par des humains, les annotateurs avaient introduit des catégories en dehors de la spécification originale, comme Office apparaissant là où aucune étiquette de ce type n'existait dans le prompt. Une comparaison de modèles perd sa validité quand la clé de réponses a été rédigée par le modèle que vous tentez de remplacer.
Construire une vérité terrain digne de confiance
Pour briser ce cercle, vous avez besoin d'experts humains possédant une véritable connaissance du domaine qui effectuent des annotations fraîches de manière indépendante. Aucune référence aux sorties du modèle précédent. Aucun accès à ce que le modèle en place a prédit.
Périmètre du jeu de données
L'équipe de Property Finder a annoté à la main 356 images des Émirats arabes unis et un ensemble distinct d'images d'Égypte. L'équipe les a sélectionnées parmi des annonces de production non étiquetées couvrant des segments représentatifs du secteur. Cet article présente les résultats sur les images des Émirats arabes unis. Les images d'Égypte ont servi de vérification transrégionale sur 230 images et ne sont pas présentées ici. Les 256 premières images des Émirats arabes unis à être annotées ont constitué l'ensemble de développement pour le réglage. L'ensemble d'évaluation pour la comparaison finale des modèles utilise les 356 images, en ajoutant 100 images annotées après les phases de développement. Un ensemble de 356 images est approximativement suffisant pour détecter des différences modérées entre modèles. Les classes rares au sein d'attributs individuels comptent moins d'exemples, donc des différences plus faibles sur ces attributs pourraient ne pas être détectables.
Annotation par des experts
Un expert en stratégie et analytique a annoté toutes les images. Il apportait une connaissance spécialisée des normes de qualité des annonces immobilières. L'équipe de l'AWS Generative AI Innovation Center a mené des revues de qualité systématiques par le biais de sessions de clarification dédiées. Ces revues ont tranché les cas ambigus et ont maintenu la cohérence de l'étiquetage sur l'ensemble du jeu de données.
Transition vers le multi-étiquetage
Les images immobilières montrent fréquemment plusieurs pièces à travers des portes ou présentent des caractéristiques de qualité qui se chevauchent. Le passage de la classification à étiquette unique à la classification multi-étiquettes a éliminé une source majeure d'ambiguïté artificielle.
La photo d'un couloir montrant une chambre à travers une porte est réellement les deux. Une fois que vous autorisez plusieurs étiquettes, vous mesurez ce que le modèle réussit plutôt que de le pénaliser pour des prédictions secondaires raisonnables.
Une approche hybride pourrait compléter cette méthodologie : des modèles de différentes familles font émerger des étiquettes candidates et des désaccords, et des experts humains arbitrent chaque cas, de sorte qu'aucune sortie de modèle n'est utilisée directement comme étiquette. Cela réduirait la charge d'annotation pour l'expansion future du jeu de données.
Choix des métriques
Le Micro F1 a servi de métrique principale parce qu'il pondère chaque prédiction de manière égale, ce qui correspond à l'objectif métier d'exactitude globale des étiquettes. Le Macro F1 a été rapporté en parallèle car le Micro F1 est dominé par les classes fréquentes et peut masquer de mauvaises performances sur des attributs rares. La précision et le rappel par étiquette ont aidé à identifier des modes de défaillance spécifiques. L'intersection sur union (IoU) par échantillon mesurait à quel point les étiquettes prédites de chaque image chevauchaient les étiquettes de l'expert. Les neuf attributs à étiquette unique, comme la détection de rotation ou de filigrane, ont une seule bonne réponse par image. L'équipe AWS les a également évalués avec l'exactitude en correspondance exacte, la part des images où la réponse correspond à l'étiquette de l'expert.
Optimisation des prompts comme apprentissage par renforcement
Avec une évaluation impartiale en place, vous pouvez commencer à vous améliorer. On ne peut pas améliorer ce qu'on ne peut pas mesurer correctement.
L'optimisation suit une boucle analogue à l'apprentissage par renforcement. Considérez chaque version de prompt comme un agent, le score Micro F1 comme le signal de récompense, et l'analyse des erreurs comme le gradient d'amélioration. L'idée ressemble à GEPA (évolution réflexive de prompts Genetic-Pareto), où vous mutez des composants du prompt, évaluez la fitness, sélectionnez les survivants et itérez. Dans cette mission, l'équipe AWS a affiné la plupart des versions à partir de l'analyse des erreurs, avec des assistants IA examinant les images échouées et proposant des changements.
MIPROv2, un cadre d'optimisation automatique de prompts issu de la bibliothèque DSPy , a complété ce processus manuel pour la tâche de classification des photos en v27.
Point de départ
Le premier prompt (v0) utilisait des instructions de classification génériques, simplifiées ici à titre d'illustration :
« Classez cette image dans l'une des catégories suivantes : Salon, Cuisine, Chambre, Salle de bain… »
Le modèle propriétaire A, la base de production de Property Finder, a obtenu un Micro F1 de 0.55 sur l'ensemble de développement de 256 images. Il utilisait v22, un prompt adapté à sa famille de modèles. Les scores antérieurs à v21 utilisaient la configuration antérieure à étiquette unique et ne sont pas directement comparables.
Itération après itération
L'équipe AWS a testé les premières versions sur plusieurs modèles candidats et a ajouté un formatage de sortie structuré et des définitions spécifiques aux attributs.
La correction la plus instructive est venue de l'analyse des erreurs au niveau de l'image. Dans les premières versions à étiquette unique, le modèle classait systématiquement les pièces visibles à travers des portes comme le type de la pièce secondaire. L'équipe du AWS Generative AI Innovation Center a ajouté des instructions explicites pour classer en fonction de la pièce occupant la majorité du cadre. Le passage ultérieur à la sortie multi-étiquettes a gardé la pièce principale comme étiquette et a permis aux pièces visibles à travers des portes comme étiquettes supplémentaires.
La personnalisation régionale a produit le gain suivant. Dans certaines régions, les photos d'annonces comportent des superpositions de texte arabe décoratif qui ne sont pas des filigranes. Des règles pour ce texte ont éliminé toute une catégorie de faux positifs.
Le prompt v21 est passé à une sortie multi-étiquettes pour la classification des photos et la catégorie de pièce, et est devenu le prompt de départ partagé pour chaque modèle. Avec lui, Llama 4 Maverick 17B Instruct de Meta a obtenu un Micro F1 de 0.75 sur l'ensemble de développement. À partir de là, l'équipe AWS a ajusté séparément le prompt de chaque modèle. Pour ce modèle, v24 ciblait la surestimation de la taille des pièces, la gestion multi-étiquettes et le format de sortie. Puis v25, une version automatiquement optimisée, a placé les tâches critiques en premier. En v27, MIPROv2 a restructuré la tâche de classification des photos, et le Micro F1 du modèle sur cette tâche a atteint 0.76.
Point d'arrivée
Le prompt final, v27_PF, est v27 plus des règles que Property Finder a ajoutées pour les rendus, les images avec bordures ou cadres, et les couloirs. Comme v27, il conserve les règles sur le texte arabe et les instructions de format de sortie. Une étape de normalisation après chaque appel de modèle gère les différences de format restantes.
Avec v27_PF, Llama 4 Maverick 17B Instruct a obtenu un Micro F1 de 0.80 sur l'ensemble d'évaluation de 356 images, où le modèle propriétaire A a obtenu 0.56 avec v22. L'ensemble d'évaluation comprend les 256 images de développement, et les prompts des deux modèles ont été ajustés sur ces images. Ces scores sont donc optimistes.
Le passage du modèle propriétaire A à Llama 4 Maverick 17B Instruct, chacun sur son propre prompt ajusté, a fait passer le Micro F1 de 0.55 à 0.81 sur l'ensemble de développement. C'est un gain relatif de 47 pour cent. L'ajustement du prompt seul, sur Llama 4 Maverick 17B Instruct, l'a fait passer de 0.75 avec le prompt partagé v21 à 0.81 avec v27.
Leçons des approches échouées
Tout n'a pas réussi. Le 2-bucket approche consistant à placer les attributs du filigrane et les autres attributs dans deux appels API distincts. Cela n'a apporté aucun gain de précision significatif. La détection des images encadrées a également chuté brutalement. Sans les attributs du filigrane dans le même prompt, les modèles confondaient les superpositions de filigranes avec des bordures d'image.
Les prompts génériques ont également échoué, quel que soit le modèle sur lequel vous les exécutiez. L'imagerie immobilière présente trop de spécificités de domaine pour une instruction universelle.
Résultats : coût, précision et vitesse
L'équipe de l'AWS Generative AI Innovation Center a évalué plusieurs modèles sur Amazon Bedrock avec le cadre d'évaluation impartial. Tous les modèles sont partis du prompt partagé v21 et ont ensuite été ajustés pour leur famille de modèles sur l'ensemble de développement. Le modèle propriétaire A a reçu un tour d'ajustement, v22. Llama 4 Maverick 17B Instruct en a reçu plusieurs, v24 à v27, plus les règles de cas limites de Property Finder, de sorte qu'il a bénéficié de plus d'efforts d'ajustement. La comparaison finale contre le modèle propriétaire A a utilisé l'ensemble d'évaluation de 356 images. Property Finder a sélectionné Llama 4 Maverick 17B Instruct pour leur charge de travail de production en fonction de la précision sur les 11 attributs et de l'efficacité des coûts. Pour la disponibilité des modèles par Région, reportez-vous à Modèles pris en charge par Région AWS dans Amazon Bedrock.
Le tableau suivant montre la précision en correspondance exacte que Llama 4 Maverick 17B Instruct (v27_PF) a atteinte sur chaque attribut à étiquette unique, évaluée sur l'ensemble de 356 images. Il a obtenu 90 pour cent ou plus sur six des neuf, et a égalé ou dépassé le modèle propriétaire A sur les 11 attributs. Pour la classification des photos, qui peut comporter plusieurs étiquettes par image, les deux ont obtenu le même score.
| Attribut | Précision en correspondance exacte |
| Détection de rotation | 100% |
| Détection de personnes | 97% |
| Détection d'image encadrée | 97% |
| Détection de filigrane | 94% |
| Détection de rendu | 93% |
| Statut de l'ameublement | 91% |
| Pièce en travaux | 81% |
| Taille de la pièce | 65% |
| Extraction du texte du filigrane | 55% |
Coût par 1,000 images
Property Finder évalue des dizaines de milliers d'images par jour, le coût par image compte donc. Llama 4 Maverick 17B Instruct est un modèle open-weight économique, et le pipeline obtient tous les attributs d'une image en un seul appel.
| Résultat | Valeur |
| Coût estimé par 1,000 images | $2.35 |
| Réduction des coûts par rapport à la configuration précédente de Property Finder | 86% |
Ces chiffres sont des estimations à partir de décembre 2025 dans la Région US East (Ohio). Le chiffre de Llama 4 Maverick 17B Instruct suppose 9,000 tokens d'entrée et 200 tokens de sortie par image, issus de l'analyse des coûts initiale à deux appels. Un seul appel avec le prompt de production transporte environ 7,500 à 8,000 tokens d'entrée, il s'agit donc d'une estimation haute. Les 86 pour cent le comparent à l'estimation de l'analyse des coûts pour la configuration précédente de Property Finder, qui utilisait le prompt v21. La comparaison de précision a utilisé v22, qui a été ajusté à partir de v21, son coût pourrait donc différer. Pour les tarifs actuels, reportez-vous à Tarification d'Amazon Bedrock.
Vitesse d'inférence
Property Finder exécute ce pipeline optimisé en production, traitant des dizaines de milliers d'images quotidiennement avec Llama 4 Maverick 17B Instruct sur Amazon Bedrock. Dans leur propre supervision, Property Finder a observé une réduction de 40 à 60 pour cent de la latence d'inférence par rapport à leur configuration précédente.
Appliquez ceci à vos charges de travail
Commencez par auditer vos étiquettes d'évaluation. Si elles proviennent de prédictions de modèles plutôt que d'experts humains, vous avez le même problème de biais que celui découvert par Property Finder.
Construisez une vérité terrain d'experts du domaine sur quelques centaines d'échantillons représentatifs, et conservez un ensemble de test séparé que vous n'utilisez jamais pour l'ajustement. Adoptez des métriques multi-étiquettes lorsque votre tâche de classification implique des attributs qui se chevauchent. Puis itérez sur les prompts à l'aide de l'analyse d'erreurs sur les images, en traitant chaque itération comme une génération dans une boucle d'optimisation évolutive.
Lorsque vous déployez un pipeline de ce type, ajoutez des contrôles d'IA responsable. Par exemple, vous pouvez utiliser Amazon Bedrock Guardrails pour faire respecter les politiques de contenu et filtrer les sorties inappropriées du modèle. Les prédictions d'attributs de ce pipeline ne s'accompagnent pas d'un score de confiance calibré, utilisez donc un signal pratique pour choisir les images destinées à la révision humaine. Le désaccord entre modèles est un tel signal. Lorsque deux modèles donnent des réponses différentes pour un attribut, l'image est souvent ambiguë. Un second modèle sur chaque image ajoute des coûts, vous pouvez donc commencer par un échantillon. Vérifiez la fréquence à laquelle le signal détecte de vraies erreurs sur votre ensemble de développement avant de vous y fier.
Conclusion
Dans cet article, nous avons décrit comment Property Finder a identifié le biais d'évaluation, construit une vérité terrain impartiale et appliqué l'optimisation évolutive des prompts pour obtenir une meilleure précision à moindre coût grâce à la sélection de modèles sur Amazon Bedrock.
Trois éléments devaient se réunir pour obtenir ce résultat : une évaluation impartiale pour mesurer honnêtement, la flexibilité d'évaluer et de passer d'une famille de modèles à une autre sans refonte de la plateforme, et des invites soigneusement élaborées et adaptées au domaine. Amazon Bedrock a fourni la base. Il a donné à Property Finder accès à plusieurs familles de modèles via une API unique, a hérité des contrôles de gouvernance et de sécurité d'AWS, et a permis d'adopter de nouveaux modèles dès leur disponibilité sans modifier leur infrastructure.
Pour commencer avec l'évaluation et la sélection de modèles sur Amazon Bedrock, consultez la documentation Amazon Bedrock. Si vous traitez des charges de travail de vision à grande échelle et souhaitez de l'aide pour créer un cadre d'évaluation impartial, contactez le AWS Generative AI Innovation Center.
. Partagez vos expériences en matière d'évaluation de modèles et d'optimisation d'invites dans les commentaires.
Remerciements
Parmi les autres contributeurs d'AWS figurent Yousuf Albannai, Amine Sehili, Thomas Ounnas, Aris Tsakpinis, Rafik Soliman, Nikhil Ulhas Pandit et Sneh Sharma.