Jak etykiety modelu zniekształciły ocenę w Amazon Bedrock

Według AWS 96,8% wcześniejszych etykiet w ewaluacji Property Finder pochodziło z predykcji dotychczasowego modelu wizyjnego. Gdy odpowiedzi modelu stają się wzorcem, porównanie alternatyw mierzy ich zgodność z tym modelem, a nie niezależnie ustaloną poprawność. Studium AWS i Property Finder opublikowane 27 października 2026 r. opisuje, jak zespół przebudował zbiór i jakie wyniki uzyskał dla zdjęć nieruchomości ze Zjednoczonych Emiratów Arabskich.

Gdy model staje się własnym punktem odniesienia

Wcześniejszy benchmark Property Finder był w dużej mierze oparty na odpowiedziach modelu, który miał służyć jako punkt porównania. Pozostałe 3,2% etykiet przygotowali ludzie, ale także w tej części występowały błędy. Przykładowo zaakceptowano nieprawidłowe odczyty tekstu ze znaków wodnych, a pojedyncza etykieta pomieszczenia nie oddawała zdjęć, na których widać kilka jego typów. Wśród błędów specyfikacji znalazła się też kategoria „Office”, której nie było w prompcie.

Taka pętla może premiować model za powtarzanie własnych wcześniejszych odpowiedzi, nawet jeśli są błędne. W rezultacie lepsza zgodność z dotychczasowym modelem nie musi oznaczać trafniejszej oceny zdjęcia.

Jak Property Finder przygotowało nowe etykiety

Ekspert dziedzinowy niezależnie oznaczył 356 zdjęć ze Zjednoczonych Emiratów Arabskich, nie korzystając z wcześniejszych wyników modelu. Zespół AWS Generative AI Innovation Center przeglądał etykiety i wyjaśniał niejednoznaczne przypadki. Pierwsze 256 zdjęć posłużyło do prac rozwojowych, a do końcowego zbioru dodano 100 oznaczonych później. AWS wspomniało też o osobnym sprawdzianie regionalnym na 230 zdjęciach z Egiptu.

Zespół zmienił klasyfikację pomieszczeń i zdjęć z jednoetykietowej na wieloetykietową, aby można było opisać kilka nakładających się treści na jednym obrazie. Zadanie obejmowało 11 cech jakości zdjęć, między innymi wykrywanie znaków wodnych, rodzaj pomieszczenia, umeblowanie i jakość fotografii. W opisywanym procesie analizowano dziesiątki tysięcy zdjęć dziennie, a przeciętne ogłoszenie zawierało 15 zdjęć.

Co pokazują wyniki Micro F1

Na końcowym zbiorze 356 zdjęć AWS podało wynik Micro F1 równy 0,80 dla Llama 4 Maverick 17B Instruct z promptem v27_PF oraz 0,56 dla proprietary model A z v22. Micro F1 łączy precyzję i czułość, licząc wyniki łącznie dla wszystkich etykiet.

Wynik Llama wymaga ważnego kontekstu: końcowy zbiór zawierał 256 zdjęć wykorzystanych wcześniej do dostrajania promptów, a Llama otrzymała więcej rund dostrajania i dodatkowe reguły Property Finder. AWS określiło wyniki jako optymistyczne. To porównanie opisuje konkretną pracę nad zdjęciami nieruchomości z ZEA, nie ogólną przewagę jednego modelu w zadaniach wizyjnych.

Micro F1 nie pokazuje też samodzielnie, jak model radził sobie z każdym atrybutem. W dokładności exact-match dla Llama odnotowano 100% dla wykrywania obrotu obrazu i 55% dla odczytu tekstu ze znaków wodnych. Te wyniki dotyczą różnych zadań składowych, dlatego nie należy ich utożsamiać z wynikiem Micro F1.

Jak zmieniano prompty i co nie zadziałało

Zespół iterował prompty od v0 do v27. Wersja v27_PF zawierała reguły Property Finder dotyczące renderów, obramowań i korytarzy. Wcześniejsze poprawki obejmowały między innymi pomieszczenia widoczne przez drzwi, dekoracyjne napisy po arabsku oraz wybór pomieszczenia zajmującego największą część kadru. Do optymalizacji promptu dla klasyfikacji zdjęć w v27 użyto MIPROv2.

Nie sprawdził się wariant „2-bucket”, w którym atrybuty znaków wodnych rozdzielono od pozostałych i analizowano w dwóch wywołaniach. Według AWS nie przyniósł znaczącej poprawy trafności, a wykrywanie zdjęć w ramkach pogorszyło się, gdy model nie otrzymywał jednocześnie informacji o znakach wodnych. Nakładka ze znakiem wodnym mogła wtedy zostać uznana za obramowanie.

Szacunki kosztu i opóźnienia

AWS oszacowało koszt przetworzenia 1 000 zdjęć przez Llama na 2,35 USD, przy założeniach z grudnia 2025 r. dla regionu US East (Ohio). Pierwotne wyliczenie zakładało 9 000 tokenów wejściowych i 200 wyjściowych na zdjęcie. AWS opisało tę kwotę jako górny szacunek, ponieważ produkcyjny prompt używał około 7 500–8 000 tokenów wejściowych w jednym wywołaniu.

AWS podało również szacowany spadek kosztu o 86% względem wcześniejszej konfiguracji. To porównanie kosztowe korzystało z szacunku dla v21, natomiast porównanie wyników Micro F1 dotyczyło proprietary model A z v22. Property Finder przypisało własnemu monitoringowi produkcyjnemu spadek opóźnienia inferencji o 40–60% względem poprzedniej konfiguracji.