Przeprowadziliśmy 168 testów na kontrolowanym katalogu, w którym dokładnie wiadomo, który produkt spełnia wymagania klienta. Wynik pierwszy: asystent AI ani razu nie polecił produktu, który nie spełniał wymagań. Ani razu, w żadnym z siedmiu badanych układów.
Wynik drugi jest kosztowniejszy dla sklepu. Model nie poleca produktu, który sklep ma na stanie i który spełnia wszystkie warunki – a odsetek takich straconych ofert rośnie z 4,8% na 33,3%, gdy te same dane docierają do niego w kawałkach zamiast w jednym miejscu.
Ten tekst jest opisem badania, nie poradnikiem. Metodykę podajemy w całości, a katalog testowy, scenariusze, macierz prawdy i surowe odpowiedzi wszystkich silników udostępniamy na życzenie, żeby dało się to powtórzyć i podważyć.
Co dokładnie zmierzyliśmy
Problem z badaniem rekomendacji zakupowych polega na tym, że rzadko wiadomo, jaka odpowiedź była poprawna. Dlatego zbudowaliśmy katalog syntetyczny: dwanaście zasilaczy awaryjnych UPS, wszystkie parametry liczbowe i jednoznaczne. Kategoria nie jest przypadkowa – w UPS-ach słowo „musi” jest naturalne, a wymagania da się sprawdzić rachunkiem, nie opinią.
Na tym katalogu ułożyliśmy 21 scenariuszy zakupowych, w sumie 67 warunków twardych, w pięciu klasach:
| Klasa scenariusza | Ile | Poprawna odpowiedź |
|---|---|---|
| dokładnie jeden pasujący produkt | 10 | wskazać ten jeden |
| kilka pasujących produktów | 4 | wskazać któryś z pasujących |
| żaden produkt nie spełnia warunków | 5 | powiedzieć wprost, że nie ma |
| warunki wykluczają się wzajemnie | 2 | powiedzieć wprost, że nie ma |
| z katalogu usunięto dane potrzebne do oceny | 21 | powiedzieć, że brakuje danych |
Kluczowa rzecz: macierz prawdy jest liczona programowo z katalogu, nie oceniana ręcznie. Dla każdego scenariusza wiadomo z góry, które SKU spełniają wszystkie warunki naraz – i to zostało zweryfikowane asercjami, żeby żaden scenariusz nie trafił do badania z błędną etykietą.
Mierzyliśmy dwie metryki podstawowe, obie opisane w przeglądzie badań nad odmową odpowiedzi modeli językowych. False Recommendation Rate to odsetek przypadków, w których model polecił produkt niespełniający warunków – dziedzinowy odpowiednik tego, co w literaturze nazywa się odsetkiem błędnych odpowiedzi. False Abstention Rate to odsetek przypadków, w których model odmówił, choć pasujący produkt istniał. Ta druga metryka jest w rozmowach o SEO praktycznie nieobecna, a to ona okazała się kosztowna.
Siedem układów, trzy silniki
| Układ | Co sprawdza |
|---|---|
| Google AI Mode, katalog w jednym kontekście | realna powierzchnia produktowa, cały katalog naraz |
| Google AI Mode, to samo, powtórzone drugi raz | ile w wynikach jest szumu, a ile sygnału |
| Google AI Mode, katalog z usuniętymi danymi | czy model przyzna, że nie da się rozstrzygnąć |
| Google AI Mode, bez pozwolenia na odmowę | czy zerowy odsetek błędnych rekomendacji to nie artefakt promptu |
| gemini-2.5-pro przez API, katalog w jednym kontekście | surowy model, kontrola dla powierzchni produktowej |
| gemini-2.5-pro, katalog pocięty na dziesięć części | ten sam model i ten sam tekst, ale dane rozproszone |
| gpt-4.1, katalog pocięty na dziesięć części | czy efekt rozproszenia dotyczy też innego silnika |
Google AI Mode odpytywaliśmy przez SearchApi.io, gdzie limit zapytania to 8193 znaki – nasz prompt ma około 5400, więc katalog wchodzi w całości. Wariant pocięty wymusiła inna droga dostępu, w której limit pojedynczego pola to 500 znaków. Ta różnica techniczna okazała się najciekawszą częścią badania.
AI nie wciska produktów. Sprawdziliśmy to trzy razy
W żadnym ze 168 przebiegów model nie polecił produktu, który nie spełniał wszystkich warunków twardych. Spodziewaliśmy się czegoś przeciwnego: założenie, od którego zaczynaliśmy, brzmiało, że skoro sklepy optymalizują katalog tak, żeby zawsze coś zwrócić, to model też zawsze coś poleci. To założenie się nie potwierdziło.
Dotyczy to wszystkich trzech silników i wszystkich siedmiu układów. W scenariuszach bez dopasowania i w tych ze sprzecznymi wymaganiami modele odpowiadały wprost, że takiego produktu nie ma – zamiast podsuwać najbliższy zamiennik.
Pierwsze podejrzenie było takie, że to artefakt naszego promptu. Mówiliśmy modelowi, że katalog jest pełny i że jeśli nic nie pasuje, ma to powiedzieć – czyli sami licencjonowaliśmy odmowę. Prawdziwy asystent tego nie dostaje i jest trenowany na pomocność.
Sprawdziliśmy więc wariant neutralny: usunęliśmy informację, że katalog jest kompletny, oraz obie instrukcje pozwalające powiedzieć „nie mam” i „nie wiem”. Model nie wiedział, że katalog jest zamknięty, i nie dostał żadnej zachęty do odmowy. Wynik się nie zmienił – zero błędnych rekomendacji, poprawna odmowa we wszystkich siedmiu scenariuszach bez dopasowania.
To pozwala postawić tezę mocniej, niż zakładaliśmy: model, który dostaje komplet danych w jednym miejscu, nie wciska produktu niespełniającego wymagań. Nie dlatego, że mu pozwolono odmówić – po prostu liczy poprawnie.
Kosztowny jest błąd w drugą stronę
Skoro AI nie poleca produktów nieodpowiednich, to gdzie sklep traci pieniądze? Na odpowiedziach „nie mamy takiego produktu”, udzielanych wtedy, gdy produkt jest na stanie i spełnia wszystkie warunki.
W naszym badaniu wszystkie zaobserwowane błędy były tego rodzaju. Żaden nie polegał na poleceniu czegoś złego; każdy polegał na niepoleceniu czegoś dobrego.
| Silnik i sposób podania katalogu | Poprawne | Błędne rekomendacje | Niepotrzebne odmowy |
|---|---|---|---|
| Google AI Mode, jeden kontekst | 20/21 | 0% | 4,8% |
| Google AI Mode, jeden kontekst, powtórzenie | 21/21 | 0% | 0,0% |
| gemini-2.5-pro, jeden kontekst | 19/21 | 0% | 4,8% |
| gpt-4.1, katalog pocięty | 17/21 | 0% | 19,0% |
| gemini-2.5-pro, katalog pocięty | 14/21 | 0% | 33,3% |
Dla sklepu ta różnica jest policzalna. Jeśli co trzecie zapytanie z twardymi wymaganiami kończy się odpowiedzią „nie mamy”, mimo że produkt jest w ofercie, to nie jest problem widoczności ani rankingu. To zapytanie, które dotarło do samego końca ścieżki i przepadło na ostatnim kroku.
Rozproszenie danych mnoży odmowy siedmiokrotnie
Najmocniejsze porównanie w całym badaniu jest wewnątrz jednego modelu. Ten sam gemini-2.5-pro, ten sam katalog, ten sam tekst co do znaku – różnica polega wyłącznie na tym, czy przyszedł w jednym kawałku, czy w dziesięciu.
Ponieważ porównujemy model sam ze sobą, różnicy nie da się wytłumaczyć tym, że „inny silnik gorzej liczy”. Dodatkowo wszystkie pięć scenariuszy, które model przestaje rozwiązywać po pocięciu, należy do klasy dokładnie jednego pasującego produktu – czyli traci zdolność znalezienia jedynej trafnej oferty, jaką sklep ma.
Kierunek nie jest przy tym cechą jednego silnika. gpt-4.1 w tym samym, pociętym układzie wypada lepiej (19,0% wobec 33,3%), ale wciąż wyraźnie gorzej niż którykolwiek model z katalogiem w jednym miejscu. Wrażliwość na rozproszenie różni się między modelami; sam efekt występuje w obu.
Mechanizm: to nie jest gubienie danych, to błąd rachunkowy
Model nie gubi danych po pocięciu katalogu – on je znajduje i źle porównuje. Przeczytaliśmy surowe odpowiedzi z pięciu scenariuszy, które po pocięciu przestały wychodzić: w czterech z pięciu model znalazł właściwy produkt i odrzucił go na błędnym porównaniu liczb, a nie dlatego, że go nie znalazł albo że brakowało danych.
| Scenariusz | Co jest w katalogu | Co napisał model |
|---|---|---|
| S03 | moc czynna 540 W, wymagane 500 W | „moc czynna (540 W) jest za niska” |
| S04 | moc czynna 1800 W, wymagane 1300 W | „UPS-B2 jest najbliższy, ale ma za małą moc czynną” |
| S06 | podtrzymanie 48 minut, wymagane 40 | „zapewnia krótszy czas podtrzymania” |
| S09 | moc czynna 720 W, wymagane 700 W | „moc czynna jest nieznacznie niższa (720 W vs wymagane 700 W)” |
Ostatni wiersz jest najbardziej wymowny. Model zacytował obie liczby poprawnie – 720 i 700 – i wyciągnął z nich wniosek odwrotny do prawdziwego. To nie halucynacja i nie brak danych. To błąd porównania na danych, które model miał przed sobą i poprawnie odczytał.
Ma to bezpośrednią konsekwencję dla sposobu, w jaki sklepy publikują specyfikacje. Powszechna rada „umieść parametr na stronie” jest niewystarczająca. Z tego badania wynika coś ostrzejszego: liczba musi stać obok liczb, z którymi jest porównywana. Tabela specyfikacji rozbita na zakładki, akordeony i załączniki PDF nie jest problemem indeksowania – jest problemem arytmetyki.
Drugi mechanizm: model dopisuje warunek, którego nie było
Jedyny błąd Google AI Mode w pierwszej serii ma inną naturę i wart jest osobnej uwagi. Scenariusz wymagał obudowy tower, minimum ośmiu gniazd IEC C13 i mocy czynnej minimum 850 W. Pasował dokładnie jeden produkt. Model potwierdził wszystkie trzy warunki:
„posiada obudowę tower oraz odpowiednią moc czynną (900 W) i 8 gniazd IEC C13, jednak dodatkowo wyposażony jest w 2 gniazda Schuko”
Klient nigdy nie wykluczył gniazd Schuko. Model potraktował dodatkową cechę jako dyskwalifikującą i odrzucił jedyną trafną ofertę. To lustrzane odbicie błędu z wariantu pociętego: tam warunek ginął albo był źle policzony, tu został dopisany. Skutek dla sklepu identyczny.
Odpowiedź, która przeczy własnej konkluzji
Co dwudziesta ósma odpowiedź asystenta mówi klientowi coś innego niż jej własna konkluzja. Tego nie planowaliśmy mierzyć – zauważyliśmy przy powtórzeniu serii, gdy jeden ze scenariuszy dał poprawne wskazanie produktu, ale narracja przed nim zaczynała się od zdania: „Żaden produkt z naszego katalogu nie spełnia jednocześnie wszystkich trzech wymagań”.
Klient czyta zdanie, nie ostatnią linijkę. Sprawdziliśmy więc systematycznie wszystkie 84 przebiegi na AI Mode: 3,6% odpowiedzi jest wewnętrznie sprzecznych – proza odmawia, a konkluzja wskazuje właściwy produkt.
To znaczy, że nasza własna metryka zawyża jakość. Odpowiedź policzona jako trafienie działa na kupującego jak odmowa. Prawdziwy koszt niepotrzebnych odmów jest więc wyższy niż zmierzony, a do wskaźnika trzeba dodać drugi wymiar: nie tylko czy model wskazał właściwy produkt, ale czy powiedział to jednoznacznie.
Gdzie to się osadza w badaniach
Metryki odmowy nie są naszym wynalazkiem i uczciwie trzeba to powiedzieć. W przeglądzie badań nad odmową odpowiedzi modeli językowych odmowa modelu jest opisana jako osobna zdolność, z ustalonym zestawem miar – w tym parą wskaźników odpowiadających dokładnie temu, co mierzymy: odsetkowi błędnych odpowiedzi i odsetkowi błędnych odmów. Autorzy rekomendują raportowanie obu naraz, bo optymalizacja jednego psuje drugi.
Istnieją też benchmarki zakupowe. WebShop zbudował symulowane środowisko sklepu z ponad milionem produktów, a ShoppingComp testuje między innymi zapytania z wieloma ograniczeniami i decyzje krytyczne dla bezpieczeństwa. Czego nie ma: żadnego benchmarku na polskim katalogu, w języku polskim i na polskich danych produktowych. To jest luka, w którą wchodzi to badanie.
Ramę ryzyka daje OWASP LLM09: Misinformation, gdzie osobno wymieniono nadmierne zaufanie użytkownika do odpowiedzi modelu. Warto zwrócić uwagę na jedno zdanie z tego dokumentu: awaria bezpieczeństwa nie wymaga atakującego, wystarczy niedostateczna kontrola nad wiarygodnością systemu. W handlu wygląda to prozaicznie – jako oferta, która nie została pokazana.
Co z tego wynika dla sklepu
Cztery wnioski, uszeregowane od najtańszego do najdroższego we wdrożeniu.
- Trzymaj parametry porównywalne w jednym bloku. Wszystkie wartości, po których klient filtruje, powinny stać w jednej tabeli specyfikacji w HTML – nie w zakładkach, nie w akordeonie ładowanym skryptem, nie w PDF-ie. To wynika wprost z siedmiokrotnej różnicy między katalogiem w jednym kontekście a pociętym.
- Podawaj jednostkę przy każdej liczbie i nie mieszaj podobnych. W naszym katalogu każdy produkt ma moc pozorną w VA i czynną w W. Jeden z błędów polegał dokładnie na pomyleniu tych dwóch. Jeśli klient filtruje po jednej z nich, druga powinna być wyraźnie oznaczona albo nieobecna w tabeli filtrowania.
- Opisuj, czego produkt nie ma, jeśli to bywa wymaganiem. Model dopisał warunek wykluczający gniazda Schuko, którego klient nie postawił. Jawne „to jest cechą dodatkową, nie ograniczeniem” jest tańsze niż stracona sprzedaż.
- Zbieraj zapytania, na które katalog nie odpowiada. Lista wymagań bez dopasowania to gotowa informacja zakupowa dla działu handlowego – pokazuje realny popyt na poziomie konkretnych parametrów, nie ogólnych kategorii. To argument, który sprzedaje projekt poza działem marketingu.
Warstwa wcześniejsza – czy model w ogóle rozłoży zapytanie klienta na warunki – to temat osobny, opisany przy wyszukiwaniu na wymagania. To, czy Twoje dane w ogóle dają się porównać z ofertą konkurencji, rozstrzyga Product Comparability Score. A jeśli błąd wynika z nieaktualności danych, a nie z ich rozproszenia, mechanizm jest inny i opisaliśmy go przy rekomendowaniu produktu, którego nie ma.
Czego to badanie nie mówi
Publikujemy je jako pilotaż z pełną metodyką, nie jako pomiar rynku. Pięć ograniczeń, o których czytelnik powinien wiedzieć, zanim zacznie cytować liczby.
- Katalog jest syntetyczny i podany w treści zapytania. Mierzymy spełnianie warunków na danych, które model na pewno widział – nie wyszukiwanie w sieci. Prawdziwe specyfikacje bywają brudniejsze, więc realny odsetek odmów jest raczej wyższy niż nasz.
- Wariant pocięty jest artefaktem limitu API, nie symulacją realnego rozproszenia. Katalog jest tam dzielony w środku wyrazów, co jest ostrzejsze niż to, co dzieje się na prawdziwej stronie. Kierunek efektu uważamy za wiarygodny, jego wielkości – nie.
- Testujemy modele i jedną powierzchnię produktową, nie wszystkie produkty. Google AI Mode to realny produkt, ale gemini-2.5-pro i gpt-4.1 odpytywaliśmy przez API. To nie to samo, co ChatGPT czy Perplexity, których używa klient.
- Próba jest mała. 21 scenariuszy, jedna kategoria produktowa, dwa powtórzenia tylko dla jednego układu. Powtórzenie pokazało, że jeden scenariusz potrafi zmienić wynik o 4,8 punktu procentowego – więc różnic tego rzędu nie należy interpretować. Efekt rozproszenia jest od tej niestabilności siedem razy większy i dlatego się broni.
- Wymusiliśmy format odpowiedzi. Prosiliśmy o konkluzję w ustalonej postaci, co praktycznie odcięło modelowi możliwość zadania pytania doprecyzowującego. Odsetka takich pytań ten projekt nie mierzy i nie należy z niego wyciągać wniosku, że modele ich nie zadają.
Wszystkie dane surowe – katalog, scenariusze, macierz prawdy i pełne odpowiedzi wszystkich silników – mamy zapisane i udostępniamy na życzenie, żeby dało się to powtórzyć albo podważyć.
Od czego zacząć u siebie
Metoda do powtórzenia w każdym sklepie w ciągu tygodnia, bez żadnych narzędzi poza asystentem, z którego korzystają Twoi klienci.
- Wypisz dziesięć realnych zapytań z twardymi wymaganiami, jakie dostajesz od klientów. Nie ogólnych („polecacie coś dobrego”), tylko warunkowych („musi mieć X, zmieścić się w Y, wytrzymać Z”).
- Dla każdego ustal sam, patrząc w swój katalog, które produkty spełniają wszystkie warunki naraz. To jest Twoja macierz prawdy i bez niej cały test nie ma sensu.
- Zadaj te pytania asystentowi, wskazując swój sklep. Policz dwie rzeczy: ile razy polecił coś, co warunków nie spełnia, i ile razy powiedział „nie ma”, choć produkt masz.
- Przy każdej odmowie sprawdź w odpowiedzi, na którym warunku się potknął – i gdzie ten parametr leży na Twojej stronie. Jeśli w innej zakładce niż reszta, masz pierwszą poprawkę.
Czwarty krok zwykle daje najwięcej. Ta sama metoda, prowadzona regularnie, jest podstawą monitoringu promptów, a szerszy obraz tego, co asystenci mówią o ofercie, opisaliśmy przy tym, co AI mówi o Twojej marce.
Zakres i wycenę uporządkowania danych produktowych pod takie zapytania zebraliśmy w cenniku SEO dla e-commerce. Czy Twoje dane są dziś w ogóle czytelne dla modeli, sprawdzamy w audycie widoczności w AI, a jakość samych opisów w audycie treści; całość prowadzimy jako element pozycjonowania sklepu internetowego. Poprawność rachunku kosztu to osobna warstwa, opisana przy poprawnym liczeniu kosztu produktu, a wiarygodność sprzedawcy przy ocenie wiarygodności sklepu. Przy ofertach jednostkowych dochodzi jeszcze warstwa opisana przy opisywaniu stanu konkretnego egzemplarza. Ten temat jest jedną z dziesięciu warstw SEO w e-commerce – całość, wraz z patentami stojącymi za każdą warstwą, zebraliśmy w mapie 10 warstw SEO w e-commerce.
Najczęściej zadawane pytania
Czy asystent AI poleca produkty, które nie spełniają wymagań klienta?
W naszym badaniu ani razu. W 168 przebiegach na kontrolowanym katalogu żaden z trzech testowanych silników nie wskazał produktu niespełniającego wszystkich warunków twardych. Dotyczy to również wariantu, w którym model nie dostał informacji, że katalog jest pełny, ani pozwolenia na odmowę.
Na czym więc traci sklep?
Na odpowiedziach „nie mamy takiego produktu”, udzielanych mimo że produkt jest na stanie i spełnia wszystkie warunki. Wszystkie błędy zaobserwowane w badaniu były tego rodzaju. Przy katalogu podanym w jednym miejscu było to około 5% zapytań, przy danych rozproszonych ponad 33%.
Dlaczego rozproszenie danych ma znaczenie, skoro model i tak je przeczytał?
Bo błąd nie polega na nieprzeczytaniu danych, tylko na ich porównaniu. W czterech z pięciu przeanalizowanych przypadków model znalazł właściwy produkt i odrzucił go, myląc się w porównaniu liczb – w jednym zacytował poprawnie 720 W i 700 W, po czym uznał 720 za wartość niższą.
Co to znaczy w praktyce dla karty produktu?
Że nie wystarczy umieścić parametr na stronie. Wartości, po których klient filtruje, powinny stać obok siebie w jednej tabeli specyfikacji w HTML, a nie być rozrzucone po zakładkach, akordeonach ładowanych skryptem i załącznikach PDF.
Czy to znaczy, że jeden silnik jest lepszy od drugiego?
Nie należy tak tego czytać. Mierzyliśmy wrażliwość na sposób podania danych, a nie ogólną jakość silników. Przy tej wielkości próby pojedynczy scenariusz zmienia wynik o blisko pięć punktów procentowych, więc różnic jednocyfrowych między silnikami nie da się obronić.
Czy model potrafi powiedzieć, że brakuje danych?
Tak, i robi to dobrze. W układzie, w którym z katalogu usunięto informacje potrzebne do oceny warunku, modele w każdym takim przypadku odpowiadały, że nie da się tego rozstrzygnąć, i nazywały konkretne brakujące pole. Nie zdarzyło się, żeby model przyznał brak danych i mimo to polecił produkt.
Czym różni się ten pomiar od sprawdzania, czy AI w ogóle widzi mój sklep?
To dwie różne warstwy. Widoczność odpowiada na pytanie, czy model dotrze do Twojej oferty. Ten pomiar zakłada, że już do niej dotarł, i sprawdza, czy poprawnie zestawi ją z wymaganiami klienta. Można być doskonale widocznym i tracić sprzedaż na drugim kroku.
Czy wyniki da się powtórzyć?
Tak i po to je publikujemy. Katalog testowy, wszystkie 21 scenariuszy, macierz prawdy liczona programowo oraz surowe odpowiedzi wszystkich silników są zapisane i udostępniamy je na życzenie.
Jak duża była próba?
168 przebiegów: 21 scenariuszy w siedmiu układach, plus powtórzenie jednego z nich. To pilotaż z pełną metodyką, nie pomiar rynku – jedna kategoria produktowa i jeden język.
