Przeprowadziliśmy 147 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 w badaniu?
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.
Czy AI faworyzuje droższe produkty?
W żadnym że 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 że 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.
Dlaczego 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.
Dlaczego 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 że 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.
Jaki mechanizm stoi za fałszywymi odmowami?
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.
Kiedy odpowiedź AI 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 że 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.
Jak te wyniki odnoszą się do istniejących badań?
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. Temat ten rozwijamy w artykule poświęconym jak AI wybiera źródła. Szerzej omawiamy to w artykule o data freshness w AI.
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 te wyniki oznaczają dla sklepu internetowego?
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.
Jak przebiegała replikacja badania?
Po opublikowaniu pierwszej rundy przeprowadziliśmy kontrolowaną replikację, żeby oddzielić wpływ układu danych od pozostałych zmiennych. Jeden silnik (Gemini-2.5-pro), jeden prompt, temperatura zero, ten sam katalog dwunastu zasilaczy UPS – jedyną zmienną był sposób ułożenia danych w treści zapytania.
Trzy warunki eksperymentalne:
- A – spójny: dane pogrupowane po produkcie, każdy parametr pod swoim SKU. To odpowiednik dobrze zbudowanej karty produktowej.
- B – rozproszony: te same linie, ale pogrupowane po atrybucie – najpierw wszystkie moce, potem wszystkie ceny, potem wszystkie obudowy. Dane są identyczne, tylko trzeba je samodzielnie złożyć w całość.
- C – uszkodzony: układ A pocięty na fragmenty w środku wyrazów, symulujący tekst, który dotarł do modelu niepełny lub źle wyekstrahowany.
Osiem scenariuszy z czterech klas, każdy powtórzony pięciokrotnie w każdym warunku. Razem 120 wywołań API z deterministyczną odpowiedzią (temperature=0).
| Warunek | Opis układu | Poprawne | Błędne rekomendacje | Niepotrzebne odmowy |
|---|---|---|---|---|
| A – spójny | dane pod produktem | 40/40 | 0% | 0% |
| B – rozproszony | dane pod atrybutem | 40/40 | 0% | 0% |
| C – uszkodzony | tekst pocięty w środku wyrazów | 40/40 | 0% | 0% |
Wynik: 100% poprawnych odpowiedzi we wszystkich trzech warunkach. Ani jednej niepotrzebnej odmowy, ani jednej błędnej rekomendacji – niezależnie od tego, czy dane były ułożone wzorowo, przemieszane po atrybutach, czy fizycznie uszkodzone.
To znacząco różni się od pierwszej rundy, w której ten sam model przy pociętym katalogu miał 33,3% odmów. Kluczowa różnica: w pierwszej rundzie katalog był dzielony na osobne wiadomości API (message chain), co wymusza wielokontekstowe przetwarzanie. W replikacji cały katalog – nawet uszkodzony – trafiał w jednym prompcie. Model radzi sobie z bałaganem w danych, o ile widzi je naraz. Problem zaczyna się, gdy musi je składać z osobnych fragmentów kontekstu.
Dla karty produktowej wniosek jest konkretny: nie chodzi o to, czy parametry stoją w ładnej tabeli. Chodzi o to, czy wszystkie parametry potrzebne do porównania trafiają do modelu w jednym załadowaniu strony, bez konieczności klikania zakładek, rozwijania akordeonów czy pobierania załączników.
Jakie są ograniczenia tego badania?
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 w pierwszej rundzie jest artefaktem limitu API. Katalog był tam dzielony na osobne wiadomości, nie w obrębie jednej. Replikacja (120 testów, trzy układy w jednym prompcie) dała 100% poprawnych odpowiedzi nawet przy tekście pociętym w środku wyrazów – co sugeruje, że problem leży w multi-message chain, nie w samym rozproszeniu treści.
- 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, choć rośnie. Pierwsza runda: 168 przebiegów (21 scenariuszy, siedem układów). Replikacja: 120 przebiegów (8 scenariuszy, trzy warunki, pięć powtórzeń). Razem 288 wywołań, ale wciąż jedna kategoria produktowa i jeden język.
- 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ąć diagnostykę we własnym sklepie?
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 Twoją 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.
Opisany tu przypadek nie ma atakującego – model myli się sam, na niekompletnych albo rozproszonych danych. Wariant, w którym ktoś celowo umieszcza instrukcję w treści produktowej, opisujemy osobno przy prompt injection w treściach produktowych.
Najczęściej zadawane pytania
Przed wdrożeniem zmian w sklepie warto przeprowadzić audyt SEO, który zidentyfikuje krytyczne problemy techniczne i contentowe. Skuteczny content marketing w e-commerce buduje widoczność na zapytania informacyjne, które poprzedzają decyzję zakupową.
Więcej na ten temat w artykule Polityka zwrotów jako dane strukturalne. Więcej na ten temat w artykule Cyfrowy paszport produktu a widoczność w AI. Więcej na ten temat w artykule Czy AI rozumie warianty produktu? Schema, feed i dane str….
Ramka metodologiczna. Wnioski oparte na danych z Google Search Console, Google Analytics 4 oraz autorskiej metodyce diagnostycznej Semgence (zgłoszenie patentowe P.448274). Próbki obejmują projekty e-commerce w polskim rynku. Wyniki stanowią obserwacje z ograniczonej próby i nie powinny być traktowane jako uniwersalne prawidłowości. Dane z narzędzi zewnętrznych (Ahrefs, Screaming Frog, PageSpeed Insights) służą jako uzupełnienie diagnostyki, nie jako jedyne źródło rekomendacji.
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 już je powtórzyliśmy. Po publikacji pierwszej rundy przeprowadziliśmy kontrolowaną replikację: 120 wywołań gemini-2.5-pro z temperature=0, trzy układy danych (spójny, rozproszony po atrybutach, uszkodzony), pięć powtórzeń na scenariusz. Wynik: 100% poprawnych odpowiedzi we wszystkich warunkach. Katalog testowy, scenariusze, macierz prawdy i surowe odpowiedzi obu rund udostępniamy na życzenie.
Jak duża była próba?
Łącznie 288 przebiegów w dwóch rundach. Pierwsza: 168 (21 scenariuszy, siedem układów, trzy silniki). Druga – kontrolowana replikacja: 120 (8 scenariuszy, trzy warunki eksperymentalne, pięć powtórzeń, jeden silnik z temperature=0). To wciąż pilotaż z pełną metodyką, nie pomiar rynku – jedna kategoria produktowa i jeden język.
