Property Finder détecte un biais dans ses annotations et réduit de 86% le coût de son VLM

Property Finder, plateforme numérique de l'immobilier, traite chaque jour des dizaines de milliers de photos dans toute la région MENA. Chaque image est vérifiée selon 11 attributs, et chaque annonce compte en moyenne 15 images. L'équipe voulait abandonner un modèle de vision propriétaire coûteux au profit d'une alternative moins chère sur Amazon Bedrock. Elle s'est heurtée à un problème inattendu : 96,8% des labels de référence ne résultaient pas d'une vérification manuelle, mais copiaient les prédictions du modèle qu'elle comptait remplacer. Avec l'AWS Generative AI Innovation Center, elle a donc reconstruit son évaluation, ajusté ses prompts et basculé sur Llama 4 Maverick 17B Instruct : Micro F1 de 0,80 contre 0,56 pour l'ancien modèle, et 86% d'économies.

Des réponses écrites par le modèle à remplacer

Le schéma est courant. On a besoin d'un jeu de données pour comparer des modèles, on dispose d'un système en production que personne ne critique, et on prend donc sa sortie comme ground truth. Cela crée un cercle vicieux : le candidat est jugé sur sa proximité avec le modèle en place, et non sur l'exactitude de ses réponses. Toute alternative est structurellement perdante avant même la première requête.

Les données de Property Finder contenaient aussi des erreurs flagrantes. Dans l'extraction du texte des filigranes, des inexactitudes au caractère près étaient validées comme correctes, y compris des noms de marques inventés et des symboles omis. La classification des photos imposait un seul label, alors que plusieurs types de pièces apparaissent sur un même cliché. Parmi les 3,2% de labels restants, établis par des humains, les annotateurs avaient ajouté des catégories hors spécification, par exemple Office.

Comment l'équipe a construit son référentiel et testé 27 versions du prompt

Des experts ont annoté manuellement 356 images des Émirats arabes unis, de façon indépendante et sans accès aux sorties de l'ancien modèle. Les 256 premières ont servi de jeu de développement pour le réglage, 100 autres ont été ajoutées plus tard, et les 356 ont toutes été utilisées pour la comparaison finale. Un jeu distinct de 230 images d'Égypte a servi de contrôle inter-régional ; il ne figure pas dans le rapport. L'annotation a été réalisée par un analyste connaissant les standards de qualité des annonces, et les cas litigieux ont été examinés lors de sessions avec l'équipe d'AWS.

La décision clé : passer d'un label unique à un système multilabel. La photo d'un couloir avec une chambre dans l'embrasure d'une porte contient bel et bien les deux pièces. Les métriques ont été choisies en fonction de la tâche : Micro F1 comme métrique principale, Macro F1 pour les classes rares, precision/recall par label, IoU au niveau de l'échantillon et, pour les neuf attributs à label unique, l'exact-match accuracy.

Les auteurs décrivent l'optimisation par analogie avec l'apprentissage par renforcement : la version du prompt joue le rôle de l'agent, le Micro F1 sert de récompense et l'analyse des erreurs remplace le gradient. L'idée est proche de GEPA. La plupart des versions sont nées de l'analyse des images mal classées avec l'aide d'assistants IA, et la v27 a fait intervenir MIPROv2 de DSPy pour la classification des photos.

Ce qui a fonctionné, étape par étape :

• v0 : prompt générique avec classification à partir d'une liste de pièces • sortie structurée et définitions des attributs • règle de classification selon la pièce qui occupe la plus grande partie du cadre • règles régionales : une inscription arabe décorative n'est pas un filigrane, ce qui a supprimé toute une classe de faux positifs • v21 : multilabel pour la photo et la catégorie de pièce, point de départ commun à tous les modèles ; Llama 4 Maverick obtient un Micro F1 de 0,75 sur le jeu de développement • v24 : correction de la surestimation de la taille des pièces, multilabel, format de sortie • v25 : version auto-optimisée, tâches critiques placées en tête • v27 : MIPROv2 a reconstruit la classification des photos, avec un Micro F1 de 0,76 sur cette tâche • v27_PF : ajout des règles Property Finder pour les rendus, les cadres et les couloirs, puis normalisation du format après chaque appel

Les échecs ont aussi été instructifs. Séparer le traitement en deux appels, l'un pour les filigranes et l'autre pour le reste, n'a pas apporté de gain notable, et la détection des images avec cadre s'est nettement dégradée : sans le contexte des filigranes, les modèles prenaient les surimpressions pour des bordures. Les prompts universels n'ont fonctionné sur aucun modèle.

Chiffres, réserves et coût

Sur 356 images, Llama 4 Maverick 17B Instruct avec v27_PF atteint un Micro F1 de 0,80, contre 0,56 pour le modèle propriétaire A avec v22. Sur le jeu de développement, le passage d'un modèle à l'autre, chacun avec ses prompts réglés, a fait passer la métrique de 0,55 à 0,81, soit +47% en relatif. Le seul réglage du prompt sur Llama a fait grimper le score de 0,75 à 0,81. Les auteurs préviennent : le jeu d'évaluation inclut des images de développement, ce qui rend les chiffres optimistes. De plus, Llama a bénéficié de davantage de réglages (v24–v27 plus les règles du client), alors que le modèle A n'a eu qu'un seul tour, v22.

Exact-match sur les attributs à label unique, sur 356 images :

• détection de la rotation : 100% • personnes dans le cadre : 97% • image avec cadre : 97% • filigranes : 94% • rendus : 93% • statut d'ameublement : 91% • pièce en cours de construction : 81% • taille de la pièce : 65% • extraction du texte des filigranes : 55%

Le modèle atteint 90% ou plus sur six des neuf attributs. Il égale ou dépasse le modèle A sur les 11 attributs, et obtient le même résultat en classification des photos. Les points faibles sont évidents : la taille des pièces et l'OCR des filigranes.

Le coût est estimé à $2,35 pour 1000 images (US East, Ohio, décembre 2025), soit 86% de moins que le dispositif précédent. Le calcul repose sur 9000 tokens d'entrée et 200 tokens de sortie par image pour une analyse en deux appels. Le prompt de production réel, en un seul appel, occupe 7500–8000 tokens d'entrée : ce chiffre est donc une borne haute. La comparaison s'appuie sur l'estimation de l'ancienne configuration avec v21 et non v22, de sorte que son coût peut différer. Selon le monitoring interne de Property Finder, la latence d'inférence a baissé de 40 à 60%.

Que vérifier chez vous

Commencez par un audit des labels : s'ils sont issus des prédictions d'un modèle, vous avez le même problème. Il faut quelques centaines d'échantillons représentatifs avec une annotation experte indépendante, et un split de test distinct qui ne participe jamais au réglage. Pour les attributs qui se recoupent, utilisez des métriques multilabel et regardez le Macro F1 à côté du Micro. Corrigez les prompts à partir de l'analyse d'images précises mal traitées, et conservez un candidat par famille de modèles. Pour étendre le jeu de données, les auteurs proposent une approche hybride : des modèles de familles différentes suggèrent des labels et repèrent les divergences, puis des humains tranchent chaque cas.