Zapytaj AI o tę samą rzecz trzy razy, a dostaniesz trzy różne odpowiedzi. Każda brzmi płynnie. Każda cytuje źródła. Ale która jest najlepsza? Reranking wariantów odpowiedzi to proces oceny i porządkowania kilku wersji odpowiedzi na to samo pytanie, zanim jakakolwiek trafi do użytkownika. W naszym case study wygenerowaliśmy po 3 warianty odpowiedzi na 30 pytań z GSC i oceniliśmy je w ślepym teście z dwoma niezależnymi recenzentami. Proces ten nawiązuje do koncepcji selekcji źródeł przez AI – zanim model odpowie, musi wybrać i uporządkować fragmenty, z których buduje odpowiedź.
Google wspiera znaczniki wariantów produktowych w structured data. Dokumentacja Product Variants wprowadza typ ProductGroup z właściwościami hasVariant, variesBy i productGroupID. Dzięki temu Google może zrozumieć, że czerwona i niebieska koszulka to warianty tego samego produktu, a nie dwa odrębne produkty konkurujące o te same zapytania.
Dlaczego generowanie jednego wariantu jest słabym eksperymentem?
Jeden wariant odpowiedzi to jeden los. Nie wiemy, czy to najlepsza możliwa odpowiedź, czy jedna z wielu równie dobrych, czy może wyjątkowo słaba. Bez porównania nie ma punktu odniesienia. To jakby pisać jeden draft tekstu i nigdy go nie poprawiać – wynik może być akceptowalny, ale nie wiemy, ile zostawiliśmy na stole.
Generowanie trzech wariantów z tego samego zestawu źródeł (source pack) pozwala mierzyć: czy wynik jest stabilny (wszystkie trzy warianty mówią to samo, różnią się stylem), czy jest niestabilny (warianty zawierają różne fakty z tych samych źródeł), czy jeden wariant jest wyraźnie lepszy (co sugeruje, że domyślny reranking nie jest optymalny). Ocena extractability każdego wariantu – czyli tego, czy AI jest w stanie wyodrębnić konkretną odpowiedź z treści – stanowi jeden z kluczowych wymiarów porównania.
Co ocenia reranker?
Reranker w GSCGA MCP ocenia każdy wariant odpowiedzi na pięciu wymiarach. Koncepcyjnie mechanizm ten nawiązuje do patentów opisujących scoring pasaży i korekty wyniku przez kontekst – w szczególności US20090024606A1 (identyfikacja i łączenie podobnych pasaży w korpusie tekstowym) oraz US9940367B1 (answer passage scoring):
Intent coverage. Czy odpowiedź pokrywa intencję zapytania? Pytanie „jak wybrać rozmiar ramy rowerowej” ma intencję instrukcji wyboru. Odpowiedź, która opisuje tylko rozmiary dostępne w ofercie, nie pokrywa intencji.
Support. Czy każde twierdzenie w odpowiedzi ma potwierdzenie w source pack? Wariant, który dodaje informacje spoza źródeł (nawet jeśli prawdziwe), ma niższy support score.
Extractability. Czy odpowiedź może być wyodrębniona z kontekstu i pozostać zrozumiała? Wariant rozpoczynający się od „Jak wspomniano powyżej” traci zrozumiałość po wyodrębnieniu – problem powiązany z koncepcją nagłówka jako adresu odpowiedzi. Więcej o tym wymiarze w artykule o extractability w kontekście AI.
Neighbor consistency. Czy odpowiedź jest spójna z innymi odpowiedziami w tym samym kontekście? Jeśli sąsiednie pytania dotyczą tego samego tematu, odpowiedzi nie powinny sobie przeczyć.
Quality risk. Czy odpowiedź zawiera elementy obniżające jakość: halucynacje, powtórzenia, sprzeczności wewnętrzne, niekompletne zdania? Problem jakości obejmuje też multimodalną spójność tekst-obraz. Ten wymiar jest powiązany z oceną confidence – wiarygodności audytu AI.
Merchant Listing i Product Snippet to dwa różne konteksty, w których warianty mogą się wyświetlać. Google rekomenduje podawanie danych zarówno przez structured data, jak i feed w Merchant Center – podwójna ścieżka maksymalizuje szanse na poprawną prezentację wariantów w SERP.
Jak zbudowaliśmy ślepy test?
Wybraliśmy 30 pytań z GSC (zapytania informacyjne z minimum 5 wyświetleniami) – metodą selekcji opisaną w artykule o pytaniach z treści strony vs zapytaniach GSC. Dla każdego pytania wygenerowaliśmy 3 warianty odpowiedzi z identycznego source pack (te same 5 fragmentów źródłowych). Warianty różniły się parametrami generowania (temperatura, instrukcja systemowa), ale miały dostęp do tych samych źródeł.
| Parametr | Wartość |
|---|---|
| Liczba pytań | 30 (zapytania informacyjne, min. 5 wyświetleń w GSC) |
| Warianty na pytanie | 3 |
| Źródła na wariant | 5 fragmentów z identycznego source pack |
| Typ testu | Blind test – losowa kolejność, brak etykiet wariantów |
| Recenzenci | 2 niezależnych audytorów |
| Skala oceny | Wybór najlepszego + ocena 1-5 pozostałych |
Ocena ślepa: dwóch niezależnych recenzentów otrzymało 30 zestawów po 3 warianty. Kolejność wariantów w każdym zestawie była losowa. Recenzenci nie wiedzieli, który wariant jest „domyślny” (wygenerowany z ustawieniami produkcyjnymi). Każdy recenzent wskazywał najlepszy wariant i oceniał pozostałe na skali 1-5.
Rozbieżności: w 7 z 30 zestawów (23%) recenzenci wybrali różne warianty jako najlepsze. Te przypadki rozstrzygane były dyskusją z jawnym uzasadnieniem.
Przykład: trzy warianty odpowiedzi na jedno pytanie
Pytanie z GSC: „Jak sprawdzić, czy strona jest zoptymalizowana pod AI Search?” (12 wyświetleń/miesiąc, pozycja średnia 14,2). Poniżej trzy warianty odpowiedzi wygenerowane z tego samego source pack (5 fragmentów z artykułów Semgence). Kolejność losowa – recenzenci nie wiedzieli, który wariant jest „domyślny”.
Wariant A: „Aby sprawdzić gotowość strony do AI Search, należy przeanalizować kilka kluczowych elementów. Przede wszystkim warto zadbać o odpowiednią strukturę treści i upewnić się, że strona jest dobrze zoptymalizowana. Ważne jest również, aby treść była wartościowa i odpowiadała na pytania użytkowników.”
Wariant B: „Gotowość strony do AI Search można ocenić w 5 wymiarach: (1) rendering readiness – czy crawler AI widzi pełną treść po renderowaniu JS, (2) extractability – czy AI może wyodrębnić konkretną odpowiedź z akapitu, (3) schema coverage – czy dane strukturalne pokrywają kluczowe encje, (4) authority signals – czy strona ma sygnały wiarygodności (autor, źródła, daty), (5) passage answerability – czy fragmenty tekstu samodzielnie odpowiadają na pytania. Audyt tych 5 wymiarów za pomocą narzędzia GSCGA MCP daje wynik 0-100 z rozbiciem na każdy wymiar.”
Wariant C: „Sprawdzenie optymalizacji strony pod AI Search wymaga audytu technicznego i treściowego. Technicznie: czy JS renderuje się poprawnie dla crawlerów AI, czy schema markup jest kompletny. Treściowo: czy odpowiedzi na pytania są wyodrębniane z kontekstu (extractability), czy fakty mają źródła. W naszym audycie 47 stron e-commerce średni wynik rendering readiness wyniósł 62/100, a extractability 41/100 – co oznacza, że większość stron nie jest gotowa na cytowanie przez AI.”
| Wymiar | Wariant A | Wariant B | Wariant C |
|---|---|---|---|
| Intent coverage | 0,4 | 0,9 | 0,7 |
| Support | 0,3 | 0,95 | 0,8 |
| Extractability | 0,5 | 0,85 | 0,75 |
| Neighbor consistency | 0,6 | 0,7 | 0,8 |
| Quality risk | 0,2 (wysoki) | 0,05 | 0,1 |
| Wynik końcowy | 0,40 | 0,89 | 0,73 |
Wynik: Obaj recenzenci wybrali wariant B. Wariant A przegrał, mimo że jest „najbardziej płynny” – bo nie zawiera żadnych konkretnych wartości ani nazw narzędzi. Support score 0,3 oznacza, że 70% twierdzeń nie ma potwierdzenia w source pack. Wariant C był solidny, ale wariant B wygrał dzięki wyższemu intent coverage (lista 5 wymiarów dokładnie pokrywa intencję pytania) i prawie idealnemu support (każde twierdzenie potwierdzone w źródłach).
To typowy wzorzec z naszego testu: warianty ogólnikowe (jak A) przegrywały niezależnie od płynności tekstu. Warianty z konkretnymi wartościami, nazwami i strukturą (jak B) wygrywały nawet gdy ich proza była mniej elegancka.
Kiedy najbardziej płynny tekst przegrywa?
Jedno z najciekawszych odkryć: w 8 z 30 zestawów (27%) wariant oceniony jako „najlepiej napisany” (najbardziej płynna proza) nie wygrał rankingu. Przegrywał z wariantem mniej eleganckim, ale bardziej precyzyjnym. Typowy scenariusz: płynny wariant parafrazuje źródło w naturalny sposób, ale w parafrazie gubi konkretną wartość (cenę, wymiar, procentowy wynik). Wariant mniej elegancki cytuje wartość dosłownie – i wygrywa, bo support score jest wyższy.
To potwierdza, że reranking odpowiedzi nie powinien opierać się wyłącznie na „jakości tekstu” (fluency). Support i intent coverage są ważniejsze niż styl. Pięknie napisana odpowiedź bez potwierdzenia w źródle jest gorsza niż niezgrabna odpowiedź z pełnym wsparciem dowodowym. Budowanie sygnałów autorytetu dla AI wymaga właśnie tego: treści precyzyjnych, zweryfikowanych i popartych dowodami.
Wyniki precision@1 i agreement
| Metryka | Wartość | Interpretacja |
|---|---|---|
| Precision@1 | 63% | Automatyczny reranker zgodny z recenzentami w 63% przypadków |
| Pairwise agreement | 77% | Zgoda między dwoma recenzentami |
| Cohen’s kappa | 0,61 | Substantial agreement (skala Landis-Koch) |
| Support rate (wybrane warianty) | 89% | Twierdzenia potwierdzone w źródłach |
| Support rate (odrzucone warianty) | 71% | Niższe wsparcie dowodowe |
| Contradiction rate (wybrane) | 2% | Minimalna sprzeczność ze źródłami |
| Contradiction rate (odrzucone) | 8% | Czterokrotnie wyższy wskaźnik sprzeczności |
Precision@1 (czy reranker automatyczny wybrał ten sam wariant co recenzenci) wyniosło 63%. Oznacza to, że w 37% przypadków automatyczny reranker i ludzie wybrali różne warianty. Pairwise agreement między dwoma recenzentami wyniósł 77% (Cohen’s kappa 0,61 – substantial agreement).
Support rate (odsetek twierdzeń z potwierdzeniem w źródle) był najwyższy w wariantach wybranych przez recenzentów (89%) i niższy w wariantach odrzuconych (71%). Contradiction rate (sprzeczność ze źródłem) wyniósł 2% w wybranych wariantach i 8% w odrzuconych.
Te wyniki mają ograniczenia: 30 pytań to mała próba, dwóch recenzentów z tej samej organizacji to potencjalny bias, a ocena dotyczy pytań informacyjnych z jednej domeny (SEO). Nie generalizujemy tych wyników na inne branże czy typy zapytań. Metodyka oceny confidence w audytach AI pozwala określić, na ile możemy ufać tym liczbom.
Który wymiar najlepiej przewiduje ludzki wybór?
Przeanalizowaliśmy, jak poszczególne wymiary scoringu korelowały z wyborem recenzentów. Dla każdego z 30 zestawów sprawdziliśmy, czy wariant z najwyższym wynikiem w danym wymiarze pokrywał się z wariantem wybranym przez recenzentów.
| Wymiar | Zgodność z wyborem recenzentów | Siła predykcji | Uwagi |
|---|---|---|---|
| Support | 83% | Najsilniejsza | Wariant z najwyższym support prawie zawsze wygrywał |
| Intent coverage | 73% | Silna | Kluczowy przy pytaniach wieloaspektowych |
| Extractability | 67% | Umiarkowana | Ważniejszy w pytaniach definicyjnych niż porównawczych |
| Quality risk (odwrócony) | 60% | Umiarkowana | Niski quality risk koreluje z wyborem, ale nie wystarczy sam |
| Neighbor consistency | 47% | Słaba | Prawie losowy – recenzenci nie oceniali spójności z sąsiednimi odpowiedziami |
Wniosek: Support (potwierdzenie twierdzeń w źródłach) to najsilniejszy predyktor ludzkiego wyboru – co koresponduje z wynikami badania consensus score w weryfikacji faktów AI. W 25 z 30 zestawów wariant z najwyższym support score wygrał lub zajął drugą pozycję. Intent coverage był drugi – szczególnie istotny przy pytaniach wieloaspektowych, gdzie warianty różniły się liczbą pokrytych aspektów.
Neighbor consistency okazał się prawie bezużyteczny jako predyktor – recenzenci oceniali każdy zestaw w izolacji i nie sprawdzali spójności z innymi odpowiedziami. To sugeruje, że w shadow mode można obniżyć wagę tego wymiaru (z domyślnych 15% do 5%) i przenieść ją na support.
Kiedy reranker się myli? Analiza 11 przypadków rozbieżności
W 11 z 30 zestawów (37%) automatyczny reranker wybrał inny wariant niż recenzenci. Przeanalizowaliśmy te przypadki, szukając wzorców.
| Typ błędu | Liczba przypadków | Przykład | Przyczyna |
|---|---|---|---|
| Bias długości | 4/11 | Reranker wybrał wariant z 280 słów zamiast 140 słów | Dłuższy tekst miał wyższy intent coverage (więcej aspektów), ale recenzenci preferowali zwięzłość |
| Fałszywy support | 3/11 | Wariant parafrazował źródło poprawnie, ale reranker nie rozpoznał parafrazy | Support score kara za brak dosłownego cytatu, choć sens był zachowany |
| Kontekst biznesowy | 2/11 | Reranker wybrał wariant neutralny, recenzenci – wariant wspierający ofertę | Reranker nie ocenia dopasowania do strategii marki |
| Subtelna halucynacja | 2/11 | Wariant z poprawnym scoringiem zawierał jeden wymyślony fakt | Quality risk nie wykrył halucynacji, bo twierdzenie brzmiało wiarygodnie – problem opisany szerzej w kontekście human-in-the-loop fact-checking |
Wzorzec 1: bias długości. W 4 przypadkach reranker faworyzował dłuższe odpowiedzi. Mechanizm: dłuższy wariant pokrywał więcej aspektów pytania (wyższy intent coverage), ale recenzenci uznali, że dodatkowe aspekty były nieistotne lub rozwadniały główną odpowiedź. Przykład: pytanie „czym jest extractability?” – reranker wybrał wariant opisujący extractability, historię koncepcji i 3 powiązane metryki (280 słów). Recenzenci wybrali wariant z samą definicją i jednym przykładem (140 słów), bo lepiej odpowiadał na pytanie definicyjne.
Wzorzec 2: fałszywy support. Reranker ocenia support jako dopasowanie tekstu do source pack. Parafrazy (poprawne merytorycznie, ale odległe leksykalnie od źródła) dostawały niższy support score niż dosłowne cytaty. W 3 przypadkach recenzenci preferowali sparafrazowany wariant, bo brzmiał naturalniej.
Wzorzec 3: kontekst biznesowy. To systemowe ograniczenie rerankera – nie ocenia on, czy odpowiedź wspiera cele biznesowe. W jednym przypadku reranker wybrał wariant opisujący ogólne podejście do audytu SEO, podczas gdy recenzenci wybrali wariant, który naturalnie prowadził do oferty Semgence (np. konsultacji SEO). To argument za shadow mode: ostateczna decyzja musi uwzględniać kontekst, którego reranker nie zna.
Dlaczego shadow mode jest konieczny?
Shadow mode oznacza: generuj warianty, oceniaj je, zapisuj wyniki – ale nie publikuj automatycznie zwycięzcy. Reranking pracuje w tle, a decyzja o publikacji należy do człowieka. Dlaczego?
Reranker może mieć systematyczny bias, którego nie widać na 30 przykładach (np. faworyzowanie dłuższych odpowiedzi). Reranker nie ocenia kontekstu biznesowego (czy ta odpowiedź wspiera naszą ofertę, czy odpowiada na pytanie, na które nie chcemy odpowiadać). Reranker nie łapie subtelnych błędów merytorycznych, których nie ma w source pack (odpowiedź jest spójna ze źródłem, ale źródło jest przestarzałe).
| Etap workflow | Shadow mode | Auto-publish |
|---|---|---|
| Generowanie wariantów | Automatyczne | Automatyczne |
| Scoring wariantów | Automatyczny (5 wymiarów) | Automatyczny (5 wymiarów) |
| Wybór zwycięzcy | Automatyczny + ludzka weryfikacja | Automatyczny |
| Publikacja | Ręczna decyzja | Automatyczna |
| Bramki bezpieczeństwa | Zawsze aktywne | support < 0,7 lub contradiction > 0 → blokada |
| Kalibracja | Ciągła (każda ocena poprawia model) | Jednorazowa (przed uruchomieniem) |
Shadow mode pozwala kalibrować reranker na danych produkcyjnych bez ryzyka publikacji nieoptymalnego wariantu. Po zebraniu 100+ ocen można rozważyć automatyzację – ale z zachowaniem bramek bezpieczeństwa (odmowa publikacji, gdy support < 0,7 lub contradiction > 0). Kluczowe jest tu sprawdzenie, czy AI w ogóle widzi treść strony – bez pozytywnego rendering readiness cały pipeline rerankingu traci sens.
Shadow mode w praktyce: timeline kalibracji
Poniżej dane z naszego wdrożenia shadow mode na 200 zestawach wariantów (okres: 6 tygodni, domena SEO/content marketing).
| Etap | Liczba ocen | Precision@1 | Co się zmieniło |
|---|---|---|---|
| Start | 0-30 | 63% | Bazowy reranker z domyślnymi wagami wymiarów |
| Tydzień 2 | 30-70 | 71% | Obniżono wagę neighbor consistency z 15% do 5%, podwyższono support z 25% do 35% |
| Tydzień 4 | 70-120 | 78% | Dodano karę za odpowiedzi >250 słów (bias długości), wykryto problem z parafrazami |
| Tydzień 6 | 120-200 | 82% | Skorygowano próg support (parafrazy akceptowane przy cosine >0,7), dodano filtr halucynacji oparty na weryfikacji danych z wielu źródeł |
Kluczowe obserwacje z kalibracji: Największy skok precision (z 63% do 71%) nastąpił po prostej korekcie wag – obniżeniu neighbor consistency i podwyższeniu support. Wymiar, który prawie nie korelował z ludzkim wyborem, miał domyślną wagę 15%. Drugi skok (z 71% do 78%) wymagał rozwiązania problemu bias długości – reranker faworyzował dłuższe odpowiedzi, bo miały wyższy intent coverage. Wprowadzenie kary za długość powyżej 250 słów usunęło ten bias.
Kiedy automatyzować? Przy precision@1 powyżej 80% i bramkach bezpieczeństwa (support < 0,7 → blokada, contradiction > 0 → blokada) automatyzacja jest uzasadniona dla pytań informacyjnych. Dla pytań transakcyjnych i YMYL rekomendujemy utrzymanie ludzkiej weryfikacji niezależnie od wyniku precision – błąd w takim kontekście ma wyższy koszt niż oszczędność czasu.
Całkowity koszt kalibracji: ~40 godzin pracy recenzentów (200 zestawów × 3 warianty × ~4 minuty na zestaw). To inwestycja jednorazowa – po kalibracji reranker działa autonomicznie z okazjonalną kontrolą jakości (próbka 10% nowych ocen co miesiąc).
Jak używać wyniku w procesie contentowym?
Reranking nie zastępuje pisania treści. Pokazuje, które cechy odpowiedzi cenią recenzenci: precyzyjne wartości ponad płynną prozę, pełne pokrycie intencji ponad wyczerpujące tło, samodzielność fragmentu ponad narracyjną ciągłość. Te preferencje powinny trafić do briefów contentowych jako wymagania wobec autorów – analogicznie do podejścia opisanego w artykule o kalibracji scoringu SEO na danych GSC. Zamiast „napisz akapit o rozmiarach” – „napisz akapit zawierający konkretne wartości rozmiarów z podaniem źródła, zrozumiały bez czytania reszty artykułu”. Ocena gotowości marki do AI Search obejmuje właśnie ten wymiar: czy treść jest napisana tak, by AI mogło ją precyzyjnie zacytować.
Reranking wariantów w e-commerce: gdy AI musi wybrać między 8 URL-ami tego samego produktu
Reranking odpowiedzi AI nie dotyczy tylko treści blogowych. Gdy użytkownik pyta asystenta AI „jaki laptop do gier do 5000 zł?”, system retrieval znajduje dziesiątki stron produktowych – i musi je przefiltrować do jednej odpowiedzi. Mechanizm ten opisujemy szerzej w badaniu retrieval w AI Search. Problem: jeśli te strony to warianty tego samego produktu bez jawnej relacji schema, reranker traktuje każdy wariant jako niezależny dokument. Przykład z neonet.pl (sierpień 2026):
Przykład: HP VICTUS 15 pojawia się w dwóch wariantach (różne konfiguracje RAM/dysk), każdy z osobnym URL-em i H3. DELL 15 i5-1334U również występuje w dwóch wariantach. Apple MacBook Air ma 8 różnych wariantów (różne procesory, rozmiary ekranu, pojemności dysku). Z perspektywy użytkownika to czytelne porównanie. Z perspektywy retrieval AI – to 8 osobnych dokumentów odpowiadających na to samo zapytanie „MacBook Air cena”.
Brak ProductGroup w schema: JSON-LD Product na stronach neonet.pl nie wykorzystuje ProductGroup (isVariantOf/hasVariant) opisanego w dokumentacji Google. Każdy wariant to izolowany Product bez powiązania z innymi wariantami. System AI nie wie, że ASUS TUF Gaming A16 z 16GB RAM i ten z 32GB to warianty tego samego modelu – traktuje je jako dwa różne produkty.
Problem rerankingu: gdy użytkownik pyta „jaki laptop do gier do 5000 zł?”, retrieval znajduje 8+ stron z wariantami MacBooka Air, 2 warianty HP VICTUS i 2 DELL – ale nie potrafi ich zgrupować. Reranking semantyczny może wybrać wariant z najlepszym dopasowaniem cenowym, ale nie wie, że istnieją tańsze warianty tego samego modelu. Bez ProductGroup retrieval traci kontekst wariantowości i może cytować wariant za 7999 zł zamiast identycznego za 4999 zł.
Case study cross-industry: CCC brand variants + zooplus product variants
Problem wariantów bez jawnej relacji schema powtarza się w każdej branży e-commerce – tylko forma wariantowości jest inna. W elektronice to konfiguracje (RAM/dysk), w obuwiu marki (CCC /marki/crocs vs /marki/deezee), w zoologii rozmiary (FURminator S/M/L). W każdym przypadku reranker AI staje przed tym samym pytaniem: który z N dokumentów opisujących warianty tego samego produktu/kategorii zacytować? Dane z Ahrefs (sierpień 2026).
CCC: brand variants jako osobne strony. ccc.eu ma w top 10 stron osobne URL-e per brand: /marki/deezee (30,5 tys. sesji), /marki/crocs (26,3 tys. sesji). Każdy brand to de facto wariant kategorii „buty damskie” – problem strukturalny opisany w analizie architektury kategorii e-commerce – ale z perspektywy AI retrieval to osobne strony z osobnymi szansami na cytowanie. CCC ma 2 370 cytowań ChatGPT rozłożonych na 1 899 stron. Pytanie: gdy użytkownik pyta AI „jakie buty damskie kupić?”, czy system powinien cytować /damskie/buty (kategorię generyczną) czy /marki/crocs (konkretny brand)? To klasyczny problem rerankingu wariantów.
zooplus: ItemList z 17 wariantami FURminator. Na stronie kolekcji FURminator zooplus.pl umieszcza JSON-LD CollectionPage z ItemList zawierającą 17 osobnych obiektów Product – różne rozmiary (S/M/L), długości sierści (krótka/długa), gatunki (pies/kot). Każdy wariant ma własne gtin13, sku, offers i aggregateRating. AI retrieval widzi 17 „konkurujących” produktów na jednej stronie. Bez sygnału ProductGroup lub hasVariant reranker nie wie, że to warianty jednego produktu – i może wybrać wariant ze starą ceną lub niskim ratingiem.
hebe.pl: single product dominuje. Odwrotny wzorzec: hebe.pl ma w top 10 konkretną stronę produktową missha-krem-bb (16,1 tys. sesji). Zamiast wielu wariantów, jedna PDP dominuje – co eliminuje problem rerankingu, ale ogranicza coverage (AI cytuje tylko ten jeden produkt, nie całą kategorię BB kremów). Hebe ma 3 058 cytowań ChatGPT, ale aż 3 403 unikalne cytowane strony – więcej cytowanych stron niż cytowań, co sugeruje szerokie, ale płytkie cytowanie.
Wniosek dla rerankingu: te same zasady, które rządzą rerankingiem wariantów odpowiedzi (support, intent coverage, extractability), działają w rerankingu wariantów produktowych – ale z dodatkowym wymiarem. Reranker pasaży odpowiedzi porównuje 3 teksty wygenerowane z tych samych źródeł. Reranker wariantów produktowych porównuje N stron produktowych opisujących warianty tego samego produktu. W obu przypadkach bez jawnej relacji (w tekście: source pack, w schema: ProductGroup/hasVariant) reranker nie wie, że porównuje warianty – i traktuje je jako niezależne dokumenty. Rozwiązanie jest analogiczne: tak jak passage reranker potrzebuje source pack, by wiedzieć jakie źródła są wspólne, tak product reranker potrzebuje ProductGroup, by wiedzieć jakie warianty są powiązane.
Źródła i narzędzia
Analiza rerankingu wariantów odpowiedzi bazowała na narzędziu GSCGA MCP – w szczególności na modułach semantic_rerank_candidates, passage_score_answerability oraz answer_enrichment_pack. Wymiary oceny (intent coverage, support, extractability, neighbor consistency, quality risk) zostały zdefiniowane w oparciu o koncepcje opisane w patentach: US20090024606A1 (identyfikacja i łączenie podobnych pasaży w korpusie tekstowym), US9940367B1 (answer passage scoring), US10783156B1 (scoring kandydatów pasaży odpowiedzi) oraz WO2024226082A1 (odpowiedź na zapytanie z wykorzystaniem niestandardowego korpusu). Dane źródłowe pochodziły z Google Search Console.
Zastrzeżenie dotyczące patentów
Patenty przywołane w tym artykule – US20090024606A1, US9940367B1, US10783156B1, WO2024226082A1, US20250348728A1, US10783156B1, US20170011116A1 oraz US11409748B1 – opisują mechanizmy scoringu pasaży, oceny kandydatów odpowiedzi, rerankingu wyników i korekty wyniku przez kontekst. Sam fakt istnienia patentu nie stanowi dowodu na to, że dany mechanizm jest obecnie aktywnie wykorzystywany w produkcyjnych systemach wyszukiwania lub generowania odpowiedzi. Patenty analizowane są tutaj wyłącznie jako źródło koncepcyjne i punkt odniesienia dla projektowania audytów – a nie jako potwierdzona specyfikacja działającego algorytmu. Nie twierdzimy, że Google, Microsoft ani żaden inny podmiot stosuje opisane mechanizmy w konkretnej formie. GSCGA MCP nie odtwarza modelu jakości Google.
Czym różni się reranking od rankingu?
Ranking porządkuje dokumenty od najlepszego do najgorszego na podstawie dopasowania do zapytania. Reranking porządkuje warianty odpowiedzi wygenerowane z tych samych źródeł – nie dokumenty, lecz różne wersje odpowiedzi na to samo pytanie. Ranking operuje na dużym zbiorze (tysiące stron), reranking na małym (2-5 wariantów). Ranking jest częścią pipeline’u retrieval, reranking jest częścią pipeline’u generowania.
Ile wariantów odpowiedzi generować?
Rekomendujemy 3 warianty. Dwa to za mało (brak punktu odniesienia – mamy tylko „lepszy” i „gorszy”). Więcej niż 5 to za dużo (koszt generowania rośnie liniowo, a marginalny zysk jakości maleje). Trzy warianty pozwalają na sensowne porównanie i identyfikację stabilnych wzorców bez nadmiernego kosztu.
Czy reranking może być w pełni automatyczny?
W teorii tak, w praktyce nie zalecamy tego na początek. Automatyczny reranker w naszym teście miał precision@1 wynoszącą 63% – w 37% przypadków wybrałby inny wariant niż ludzie. Rekomendujemy shadow mode: automatyczny reranking z ludzką weryfikacją. Po zebraniu minimum 100 ocen i osiągnięciu precision@1 powyżej 80% można rozważyć automatyzację z bramkami bezpieczeństwa.
