Wyszukiwanie produktu ze zdjęcia: podobny nie znaczy ten sam

Klient fotografuje uchwyt do szafki. Wyszukiwarka znajduje niemal identyczny: ten sam kolor, podobna linia, nawet śrubki patrzą znajomo. Różni się rozstaw otworów. Na ekranie wszystko pasuje, na froncie mebla już mniej. Wiertarka nie jest dobrym sposobem na domknięcie obietnicy wyszukiwania wizualnego.

Podobieństwo obrazu może świetnie zawęzić katalog, a jednocześnie nie wystarczać do rozpoznania konkretnego modelu. Audyt takiej funkcji powinien ustalić, jakie zadanie naprawdę wykonuje: szuka inspiracji, proponuje kandydatów czy potwierdza tożsamość produktu. Każde z tych zadań wymaga innego dowodu poprawności.

Najbardziej użyteczne pytanie brzmi więc: co klient może zrobić z otrzymanym wynikiem? Jeśli ma od razu zamówić część zamienną, pomyłka oznacza coś innego niż przy szukaniu lampy w podobnym stylu. Zanim porównasz modele AI, określ tę różnicę i zobacz, czy interfejs ją komunikuje.

Jedno zdjęcie, trzy możliwe odpowiedzi

Dla fikcyjnego sklepu z wyposażeniem wnętrz przyjmijmy trzy scenariusze. W pierwszym klient szuka podobnej stylistycznie lampy. W drugim chce odtworzyć zakup konkretnego modelu krzesła. W trzecim potrzebuje uchwytu o określonym rozstawie. Zdjęcie jest wygodnym początkiem każdego z nich, lecz nie daje tego samego zestawu informacji.

Przy inspiracji akceptowalne mogą być różnice w materiale, jeżeli wynik wyraźnie je pokazuje. Przy odtworzeniu zakupu liczy się tożsamość modelu i wariantu. Przy części zamiennej decyduje zgodność cechy, której fotografia często nie ujawnia. Nazwanie wszystkich wyników „dopasowaniem” zaciera te granice.

Dokumentacja Google Product Search opisuje wyszukiwanie wizualnie podobnych produktów w indeksowanym zbiorze. To wąsko określone zadanie. Z samego podobieństwa nie wynika potwierdzenie wymiaru, wersji ani przydatności do konkretnego zastosowania.

W audycie zapisz oddzielnie: kandydat podobny wizualnie, właściwy model, właściwy wariant i zgodność wymaganego parametru. Te odpowiedzi mogą być różne dla jednej pozycji. Taki zapis szybko ujawnia, czy zespół ocenia użyteczność wyników, czy tylko ich atrakcyjny wygląd.

To ten sam rodzaj rozróżnienia, który pojawia się przy łączeniu rekordów wspomaganym AI. Podobny zapis pomaga znaleźć kandydata, ale decyzja o utożsamieniu dwóch obiektów potrzebuje osobnej podstawy. W sklepie tę podstawę mogą tworzyć identyfikator modelu, oznaczenie wariantu i potwierdzone dane katalogowe.

Ułóż małą próbę, w której wynik może się pomylić

Nie zaczynaj od losowych zdjęć najlepiej wyglądających produktów. Wybierz rodziny podobne do siebie, a w każdej kilka różnic istotnych dla zakupu. Mogą to być dwa rozstawy uchwytu, różne długości przewodu, wersja prawa i lewa albo zestaw z dodatkiem i bez niego. Wszystkie przykłady powinny mieć ustalony status w katalogu.

Przygotuj dla każdego zapytania krótką kartę oczekiwania. Zapisz, czy właściwy produkt znajduje się w indeksie, jakie inne wyniki można uznać za użyteczne i jakiej cechy nie wolno potwierdzić na podstawie samego zdjęcia. Dzięki temu oceniający nie zmienia kryteriów dopiero po zobaczeniu efektownej listy.

Dodaj produkt spoza katalogu. System powinien mieć okazję pokazać, jak zachowuje się bez prawidłowej odpowiedzi. Jeśli zawsze wskazuje jedną pozycję jako pewną, test na samych obecnych modelach tego nie ujawni. Przy braku właściwego uchwytu przydatne może być „podobne produkty”, ale nie komunikat „znaleźliśmy dokładnie ten model”.

Sprawdź również brak oczekiwanego wariantu przy obecności jego bliskiego sąsiada. Katalog może zawierać serię lamp, a nie zawierać wersji ze zdjęcia. Ogólne trafienie w rodzinę produktów nie kończy wtedy zadania. Osoba oceniająca powinna oznaczyć, co rzeczywiście znaleziono, zanim wynik trafi do zbiorczego zestawienia.

W pilotażu AI z ustalonymi kryteriami taka próba pozwala porównać warianty rozwiązania na tych samych przypadkach. Oddziel grupę inspiracyjną od grupy wymagającej zgodności. Średnia z obu może ukryć słabość dokładnie tam, gdzie klient oczekuje pewnego rozpoznania.

Nie wypełniaj całej próby wyjątkami. Potrzebujesz zwykłych zdjęć klientów i celowo trudnych par. Wynik dla każdej grupy pokaż osobno. Dziesięć pomyłek w dziesięciu wymagających przypadkach mówi coś innego niż dziesięć pomyłek rozrzuconych po zwykłych zapytaniach. Oba wyniki pomagają podjąć decyzję, jeśli ich kontekst pozostaje widoczny.

Kadr potrafi zmienić pytanie

Zrób kilka wersji jednego zapytania: cały przedmiot, detal, obiekt z tłem oraz zdjęcie z dwiema rzeczami. Sprawdź, którego fragmentu dotyczy zwrócona lista. Na fotografii lampy stojącej na stole wyszukiwarka może wybrać stół. Jeżeli interfejs nie pozwala zauważyć tego wyboru, klient interpretuje odpowiedź na inne pytanie niż zadane.

Przetestuj kadrowanie przez użytkownika, jeżeli funkcja je oferuje. Czy po zmianie zaznaczenia lista rzeczywiście się odświeża? Czy stary wynik nie wygląda jak odpowiedź na nowy kadr? Zapisz obraz wejściowy i obszar użyty do wyszukania, żeby odtworzyć sytuację bez zgadywania, co znalazło się pod palcem.

Dołóż odbicie, cień i częściowe zasłonięcie. Nie chodzi o widowiskowy konkurs na najgorsze zdjęcie, lecz o warunki typowe dla użycia: przedmiot w mieszkaniu, uchwyt nadal przykręcony do szafki, etykieta widoczna pod kątem. Wybór przykładów powinien wynikać z zadania klientów, a nie z chęci zaskoczenia narzędzia.

Sprawdź również dwie fotografie tego samego przedmiotu wykonane niezależnie. Jeżeli każda prowadzi do innej rodziny produktów, porównaj cechy zdjęć i pokaż oba przebiegi w raporcie. Nie wybieraj po fakcie lepiej wyglądającej odpowiedzi jako reprezentacji całego przypadku. Zmienność jest informacją o warunkach, w których klient może skorzystać z funkcji.

Przy zdjęciu z czytelnym oznaczeniem produktu sprawdź, czy wynik pozwala je porównać. Jeżeli kolejnym krokiem jest odczyt parametrów z dokumentacji, potrzebujesz także kontroli aktualności źródeł odpowiedzi AI. Dobry kandydat wizualny i nieaktualna karta techniczna mogą razem stworzyć błędne potwierdzenie zgodności. Jeśli narzędzie korzysta także z tekstu, opisz to jako osobny element procesu. Użytkownik powinien wiedzieć, czy dostał podobny obraz, czy kandydata potwierdzonego dodatkowym oznaczeniem. W raporcie zachowaj tę samą precyzję.

W kontroli pochodzenia obrazów AI istotny jest status samego materiału. Tutaj sprawdź dodatkowo źródło obrazów katalogowych: czy pokazują faktyczny wariant, koncepcję czy wspólną ilustrację rodziny. Powtarzanie jednej wizualizacji przy wielu modelach może sprawić, że podobieństwo obrazu nie pomoże ich odróżnić.

Wynik podobieństwa nie jest gotowym komunikatem pewności

Microsoft opisuje wynik image retrieval jako podobieństwo reprezentacji zapytania i obrazu. Dokumentacja ostrzega przed bezpośrednim porównywaniem takich wyników między różnymi zapytaniami oraz prostym przeliczaniem ich na poziom pewności. Ta granica ma znaczenie przy projektowaniu etykiet.

Jeżeli interfejs pokazuje „pewność 94%”, zapytaj, skąd pochodzi ten procent i co ma oznaczać. Nie wystarczy, że wewnętrzna odpowiedź zawiera liczbę. Dla własnego rozwiązania potrzebujesz uzasadnienia komunikatu na odrębnej, ocenionej próbie. Bez niego lepiej pokazać rolę wyniku i cechy do sprawdzenia niż efektowną obietnicę precyzji.

Porównaj wynik także z decyzją osoby oceniającej. Niech najpierw, bez podglądu propozycji systemu, przypisze zapytaniu dopuszczalne modele na podstawie danych katalogowych. Dopiero potem otwórz listę. Tak przygotowany punkt odniesienia ogranicza pokusę uznania pierwszej przekonującej miniatury za odpowiedź, której od początku szukaliśmy.

Jeżeli dwie osoby różnią się w ocenie, zapisz przyczynę. Być może jedna traktuje zadanie jako inspirację, a druga jako dobór części. Być może brakuje danych o wymiarze. Takiego sporu nie rozwiąże głosowanie nad urodą obrazka. Trzeba doprecyzować zadanie albo uzupełnić katalog, a następnie ponownie ocenić przypadek.

Oceń całą listę, także kolejność. Właściwy model na dalekiej pozycji może formalnie znajdować się w odpowiedzi, a praktycznie nie pomagać. Zapisz, ile propozycji klient musi przejrzeć oraz które mylące odpowiedniki widzi wcześniej. Ustal zakres widoku ocenianego w teście, zamiast po fakcie zaliczać każde trafienie ukryte głęboko w wynikach.

Przy każdej karcie pokaż dane potrzebne do dalszej decyzji: model, wariant i istotny parametr. W naszym uchwycie to rozstaw, nie kolejny kadr tego samego połysku. Możliwość przejścia do szczegółów powinna zachowywać właściwy wariant. Trafny kandydat traci sens, jeśli kliknięcie otwiera domyślną wersję o innych wymiarach. Kandydatów można następnie zestawić w porównaniu wybranych modeli z właściwymi jednostkami i jawnymi brakami, zanim klient uzna podobny obraz za zgodną część.

Prześledź też drogę do koszyka. Czy osoba po wybraniu wyniku może sprawdzić wymaganą cechę przed zamówieniem? Czy komunikat nadal sugeruje automatyczne potwierdzenie zgodności? Test obejmujący jedynie listę miniatur kończy się o jeden krok za wcześnie, gdy funkcja ma wspierać konkretny zakup.

Do operacyjnego przeglądu w ramach Aeneia Audit przygotuj przykładowe zapytania, odpowiadające im rekordy katalogu i widok otrzymanej listy. Te trzy elementy pozwalają przejść od ogólnego „znajduje podobne” do oceny użytecznej dla konkretnego sklepu.

Po zmianie katalogu sprawdź te same pomyłki

Przechowuj próbę razem z wersją katalogu i obrazami użytymi do zapytań. Dodanie nowego wariantu może zmienić listę, nawet jeżeli nie zmieniono samego interfejsu. Raport powinien pozwalać ustalić, czy różnica wynika z konfiguracji, składu indeksu czy sposobu pokazania rezultatów.

Włącz trudne pary do testów regresji odpowiedzi AI. Nie musisz śledzić każdej zmiany pozycji jako błędu. Sprawdzaj ustalone zadania: czy właściwy kandydat pozostaje widoczny, czy błędny wariant nie dostaje nieuprawnionej etykiety i czy brak odpowiednika nadal jest obsługiwany uczciwie.

W odbiorze funkcji sprawdź jeszcze zmianę zapytania podczas oczekiwania. Użytkownik wysyła zdjęcie uchwytu, po chwili wybiera lampę, a wcześniejsza odpowiedź przychodzi później. Widok musi pozwalać rozpoznać, do którego obrazu należy lista. Zapisz ten przebieg jako osobny przypadek, bo dobry zestaw produktów przypisany do złego zdjęcia nadal wprowadza w błąd.

Uwzględnij pustą odpowiedź oraz błąd przetwarzania pliku. To dwa różne stany: „nie znaleziono kandydatów” i „nie wykonano wyszukiwania”. W pierwszym klient może zmienić kategorię lub przejść do filtrów. W drugim potrzebuje ponownej próby albo wskazania obsługiwanego pliku. Nie powinien wnioskować z awarii, że sklep nie ma danego produktu.

Pomocne bywa porównanie z prostszą drogą: wyborem kategorii i jednego parametru. Jeśli zdjęcie szybko znajduje rodzinę, a filtr rozstawu kończy wyszukiwanie, jest to sensowny podział pracy. Nie trzeba wymagać od jednej funkcji rozpoznania cechy, której użytkownik nie sfotografował i której katalogowy obraz nie rozróżnia.

Decyzja po audycie może więc brzmieć: wyszukiwanie zostaje jako propozycja podobnych modeli, a zakup wymaga sprawdzenia wymiaru. Tak ustalony zakres funkcji można pokazać w interfejsie i sprawdzić przy kolejnej aktualizacji katalogu. Klient nadal oszczędza czas, a mebel zachowuje dotychczasową liczbę otworów.