Dans l’évaluation de Property Finder, 96,8 % des anciennes étiquettes provenaient des prédictions du modèle en place, selon AWS. En prenant ces prédictions comme référence, le benchmark comparait surtout les autres modèles au comportement de celui qu’ils devaient remplacer. AWS a publié ce cas d’étude le 27 octobre 2026.
Quand le modèle en place devient sa propre référence
Une étiquette de référence indique la bonne réponse attendue pour une image. Si elle reprend la prédiction du modèle évalué, une alternative peut être pénalisée même lorsqu’elle repère correctement un élément que le premier modèle a manqué : le benchmark mesure alors sa proximité avec le modèle en place, pas sa justesse face à une annotation indépendante.
Les 3,2 % d’étiquettes précédentes attribuées à des humains n’étaient pas non plus exemptes de problèmes. AWS signale notamment des erreurs de lecture de filigranes considérées comme correctes et des règles de classification trop rigides pour des images montrant plusieurs types de pièces.
Comment Property Finder a reconstruit ses étiquettes
Une personne experte a annoté 356 images immobilières des Émirats arabes unis sans consulter les prédictions précédentes. L’équipe de l’AWS Generative AI Innovation Center a ensuite vérifié les étiquettes et clarifié les cas ambigus.
Les 256 premières images ont servi au développement des prompts. Cent autres, annotées après les premiers essais, ont rejoint l’évaluation finale. Pour classer les pièces et les photos susceptibles de contenir plusieurs catégories, l’équipe est passée d’une seule étiquette à plusieurs étiquettes par image.
Ce que montrent les scores Micro F1 rapportés
Le Micro F1, un indicateur qui combine précision et rappel en agrégeant les résultats des différentes étiquettes, s’établissait à 0,80 pour Llama 4 Maverick 17B Instruct et à 0,56 pour proprietary model A sur le jeu de 356 images des Émirats arabes unis, selon AWS.
| Modèle | Version du prompt | Micro F1 sur 356 images des Émirats arabes unis |
| Llama 4 Maverick 17B Instruct | v27_PF | 0,80 |
| proprietary model A | v22 | 0,56 |
Ces valeurs ne proviennent pas d’un test final entièrement séparé du développement : les 256 images utilisées pour ajuster les prompts figurent aussi dans les 356 images évaluées. Llama a en outre bénéficié de plusieurs cycles d’ajustement et de règles supplémentaires propres à Property Finder, contre un seul cycle pour proprietary model A. AWS qualifie donc les scores d’optimistes. Ils décrivent cette tâche d’analyse d’images immobilières aux Émirats arabes unis, et non une comparaison générale entre modèles.
Les prompts ont évolué avec les erreurs observées
L’équipe a fait évoluer les prompts de v0 à v27. La version v27_PF ajoutait des consignes sur les rendus, les bordures ou cadres et les couloirs. Pour la classification des photos dans v27, AWS indique que l’équipe a utilisé MIPROv2 afin d’optimiser le prompt.
Une approche à deux appels, qui séparait les attributs liés aux filigranes des autres catégories, n’a pas apporté de gain notable. La détection des images encadrées a même reculé : sans les consignes sur les filigranes dans le même prompt, certains filigranes superposés étaient pris pour des bordures. Le pipeline de production décrit par AWS rassemble les attributs d’une image en un seul appel.
Coût et latence rapportés
AWS estimait le coût de Llama à 2,35 $US pour 1 000 images, selon des hypothèses datées de décembre 2025 pour la région US East (Ohio). Le calcul initial supposait 9 000 jetons en entrée et 200 en sortie par image. AWS présente ce montant comme une estimation haute : le prompt de production à un seul appel utilise environ 7 500 à 8 000 jetons en entrée.
La réduction de coût annoncée de 86 % compare cette estimation à celle de l’ancien dispositif avec le prompt v21. La comparaison de Micro F1, elle, porte sur proprietary model A avec le prompt v22. Property Finder a par ailleurs indiqué que sa propre surveillance en production avait relevé une baisse de 40 à 60 % de la latence d’inférence par rapport à son système précédent.
