Jak AI wybiera źródła 2026 - RAG, retrievery, rerankers

Zrozumienie tego, jak AI wybiera źródła, to kluczowy element skutecznej strategii AIO. Pod maską każda z pięciu głównych wyszukiwarek AI (ChatGPT, AI Overviews, Gemini, Perplexity, Claude) używa tego samego wzorca – RAG (Retrieval-Augmented Generation). Silnik robi retrieval (znajduje kandydatów), rerank (sortuje), generation (pisze odpowiedź z top-k fragmentów).

Ten poradnik opisuje techniczną mechanikę retrieverów (BM25, embeddings, hybrid), rolę cross-encoder rerank-u i ich konsekwencje dla twórców treści. Część naszego filaru o wyszukiwarkach AI 2026.

W skrócie

RAG to trzyetapowy proces – retrieval (znajdź kandydatów), rerank (sortuj), generation (napisz odpowiedź z top-k).
Retrieval używa hybrydy – BM25 (keyword matching) plus embeddings (wektory semantyczne). Oba sygnały muszą być spełnione równocześnie.
Rerank wybiera finalną piątkę z 100-200 kandydatów – premiuje specyficzność, świeżość, autorytet i jakość fragmentu jako samodzielnego chunka.
Chunking – LLM-y nie czytają całego artykułu, tylko fragmenty 500-2000 tokenów. Każdy chunk musi być samodzielnie zrozumiały.
Dla twórców – krótkie akapity, pierwsze zdanie sekcji z odpowiedzią, factoid density, jasna hierarchia H2.

Czym jest RAG i dlaczego jest wszędzie

RAG (Retrieval-Augmented Generation) to architektura systemów AI łączących retrieval (pobieranie dokumentów z indeksu) z generation (generowaniem odpowiedzi przez LLM). Alternatywą jest "pure LLM", gdzie model odpowiada tylko z pamięci treningu – ale to prowadzi do halucynacji i nieaktualnych danych.

RAG rozwiązuje dwa problemy – świeżość (nowe informacje po cutoff-ie treningu) i weryfikowalność (cytowania źródeł). W 2024-2026 praktycznie wszystkie konsumenckie wyszukiwarki AI przeszły na RAG.

Wikipedia ma neutralne wprowadzenie do tematu – więcej w haśle Retrieval-augmented generation. Dla bardziej aplikacyjnego opisu – przewodnik AIO.

Różne silniki używają różnych retrieverów. ChatGPT – Bing. AI Overviews – indeks Google. Gemini – indeks Google. Perplexity – własny crawler plus Bing. Claude – Brave Search API. Pełne porównanie – wyszukiwarki AI 2026.

Retrieval – jak silnik znajduje kandydatów

Retrieval to pierwszy etap RAG-a. System bierze zapytanie użytkownika i wyszukuje w indeksie 50-200 potencjalnie relewantnych fragmentów. To jest "szeroki tryb" – retrieval woli zebrać więcej kandydatów niż mniej.

Trzy techniki retrieval-u, używane w różnych kombinacjach.

BM25 – klasyczny keyword matching

BM25 to algorytm zliczający częstotliwość słów zapytania w dokumencie, ważony odwrotną częstotliwością w korpusie (IDF). Rzadkie słowo, które występuje często w jednym dokumencie, generuje wysoki score. To "string matching" – dokładne dopasowanie keyword-ów.

BM25 świetnie radzi sobie z zapytaniami zawierającymi specyficzne terminy. Słabo – z synonimami i parafrazami. "Jak przyspieszyć stronę" i "jak zwiększyć szybkość serwisu" dla BM25 to różne zapytania.

Embeddings – wektory semantyczne

Embeddings to reprezentacja tekstu jako punkt w przestrzeni wielowymiarowej (768-3072 wymiary). Dwa fragmenty o podobnym znaczeniu mają bliskie wektory. To "meaning matching" – rozumienie semantyczne.

Embeddings radzą sobie z synonimami i parafrazami. Słabiej – z jednoznacznymi terminami technicznymi, gdzie dokładne dopasowanie jest krytyczne.

Hybrid retrieval

Kombinacja BM25 i embeddings przez scoring fusion (typowo Reciprocal Rank Fusion lub alpha-weighted). Dostaje najlepsze wyniki, bo łączy siłę obu technik.

Praktyczna konsekwencja – autor musi pisać jednocześnie pod BM25 (dokładne frazy z zapytań użytkowników) i pod embeddings (bogaty klaster pojęć semantycznych). Pełen opis konsekwencji – AIO przewodnik.

Rerank – cross-encoder decyduje o finalnych cytowaniach

Rerank to drugi etap. Bierze 100-200 kandydatów z retrievalu i wybiera top-3 do top-10 do cytowania. Używa cross-encoder – modelu, który analizuje parę (zapytanie, dokument) i zwraca score "czy dokument odpowiada na zapytanie".

Cross-encoder jest wolniejszy niż retrieval (nie skaluje na cały indeks), ale precyzyjniejszy. Typowo to model transformer rozmiaru 300M-1B parametrów, przetrenowany na parach (zapytanie, dokument).

Rerank premiuje kilka cech. Specyficzność – konkretne odpowiedzi nad ogólnymi. Świeżość – nowsze artykuły. Autorytet – domeny z wyższym DR. Brak duplikacji – nie cytuje tego samego faktu z różnych źródeł. Czytelność – fragment musi być samodzielnie zrozumiały.

Dla twórcy – rerank jest bramą do cytowań. Możecie być w retrievalu top-100, ale rerank wybiera top-5 – czyli z prawdopodobieństwem 5%. Podnoszenie sygnałów premiowanych przez rerank (specyficzność, autorytet) zwiększa tę szansę.

Chunking – jak LLM czyta artykuł

Kluczowy szczegół, który większość optymalizatorów pomija. LLM nie ładuje całego artykułu do kontekstu generation-u. Pobiera fragmenty ("chunks") 500-2000 tokenów (z grubsza 400-1500 słów).

Chunking algorytm dzieli dokument na fragmenty na podstawie struktury HTML – H2, H3, akapity. Każdy chunk dostaje własny embedding i własny score rerank-u. Finalna odpowiedź to synteza top-5 chunków.

Konsekwencja dla autora – każdy chunk musi być samodzielnie zrozumiały. Jeśli pierwszy akapit sekcji H2 mówi "dzięki temu" (referencyjnie, bez kontekstu z poprzedniej sekcji), chunk traci punkty za czytelność. Rerank go odrzuci.

Strategia – pisanie "modularne". Każda sekcja H2 ma swój własny wstęp, który zapewnia kontekst. Nie polegać na tym, że czytelnik czytał poprzednie sekcje. To jest kluczowa różnica między "esejowym" stylem SEO a "chunk-aware" stylem AIO.

Jak embeddings generują "bliskość semantyczną"

Embeddings modele (text-embedding-3-large OpenAI, Gecko Google, Cohere) tworzą wektory semantyczne. Dwa teksty o podobnym znaczeniu mają bliskie wektory – mierzone przez cosine similarity (stosunek od -1 do 1).

Dla zapytania "jak przyspieszyć WordPress" i artykułu "optymalizacja szybkości w WordPress" – cosine similarity będzie wysoka (0,85-0,95). Dla zapytania "jak przyspieszyć WordPress" i artykułu "co to jest SEO" – niska (0,3-0,5).

Dla autora to znaczy – bogaty klaster pojęć pokrewnych w artykule podnosi embeddings-score dla wielu wariantów zapytań. Warto pisać o "szybkości", "wydajności", "optymalizacji", "cache", "Core Web Vitals" w jednym artykule – nie trzeba osobnych.

Pełny opis semantycznego modelu klastrów – SEO zaawansowane.

Dlaczego rerank premiuje specyficzność

Cross-encoder trenowany jest na parach (zapytanie, dokument) z label-ami "relevant" lub "not relevant". Typowe dane treningowe pochodzą z kliknięć użytkowników w klasycznych SERP-ach – użytkownik kliknął w link, który rozwiązał jego problem.

W tych danych specyficzne artykuły (konkretna odpowiedź na konkretne pytanie) mają wyższy CTR niż ogólne ("wszystko o X"). Rerank dziedziczy tę preferencję.

Praktyka – artykuł "jak optymalizować Core Web Vitals w WooCommerce z 10 konkretnymi krokami" jest oceniany wyżej niż "wszystko o SEO 2026", nawet jeśli drugi ma więcej słów i szerszy keyword coverage. Dla twórcy to zachęta do pisania specyficznych supporting-ów zamiast uniwersalnych pillarów bez głębi.

Jak dane strukturalne wpływają na retrieval

Schema.org (Article, FAQPage, HowTo, Product) daje retrieverowi dodatkowe sygnały klasyfikacji. Artykuł z poprawnym schema jest bardziej zrozumiały dla systemu – wie, że to Article, że ma autora, że datePublished to 2026, że articleSection to "SEO".

Silniki ważą schema różnie – Gemini i AI Overviews (oba Google) najsilniej, ChatGPT i Perplexity średnio, Claude słabiej. Pełne porównanie – Google AI Overviews 2026.

Praktyczna konsekwencja – schema nie robi retrievalu "magicznym", ale podnosi ranking w rerank-u. Dla Gemini bez schema tracicie 30-50% widoczności.

Ranking – jak rerank liczy finalny score

Cross-encoder nie używa pojedynczego sygnału, tylko wielu. Typowe wejścia do rerank-u w wyszukiwarkach AI w 2026.

Embedding similarity (zapytanie vs fragment).
BM25 score.
Autorytet domeny (DR lub własny equivalent).
Świeżość (datePublished, dateModified).
Sygnały EEAT (autor, Organization, transparentność).
Jakość strukturalna (schema, heading hierarchy).
User engagement (CTR, dwell time – głównie dla Google).
Deduplication score (czy ten sam fakt pochodzi z innych źródeł).
Freshness penalty dla starych treści.
Length quality (sweet spot długości artykułu).

Każdy sygnał ma wagę, która różni się między silnikami. To dlatego ten sam artykuł może być cytowany przez ChatGPT i pomijany przez Claude – wagi rerank-u są różne.

Dlaczego długie artykuły często wygrywają

Z perspektywy retrievera – dłuższy artykuł oferuje więcej "chunków" potencjalnie relewantnych. Artykuł 4000 słów ma ~8-10 chunków. Artykuł 1500 słów – 3-4 chunki. Szansa trafienia w rerank-u jest proporcjonalna do liczby chunków.

Równocześnie – długie artykuły z bogatą strukturą semantyczną pokrywają więcej wariantów zapytań przez embeddings. Jeden długi artykuł ma szansę cytowania dla 10-30 różnych zapytań, krótki – dla 2-5.

Ale długość nie zastępuje jakości. Artykuł 5000 słów z rozwlekłością jest oceniany gorzej niż 3000 słów z factoid density. Długość to warunek konieczny dla szerokiego pokrycia, nie wystarczający.

Sweet spot dla supporting – 3500-5500 słów. Dla pillar – 8000-10000 słów. Więcej – często redundantne, rerank obniża score.

Jak testować chunking własnych artykułów

Symulacja chunkingu – podzielenie artykułu na fragmenty 500-800 słów każdy (odpowiadające typowym chunk-om AI). Zadanie sobie pytania – czy każdy chunk jest samodzielnie zrozumiały dla czytelnika, który nie widział poprzednich sekcji.

Jeśli chunk zaczyna się od "wracając do poprzedniego punktu" lub "dzięki temu", nie ma kontekstu. Trzeba przepisać pierwszy akapit sekcji, żeby zawierał samodzielny kontekst.

Test praktyczny – weźcie przypadkowy chunk z waszego artykułu i wkleijcie do ChatGPT z pytaniem "o czym jest ten fragment?". Jeśli ChatGPT odpowiada zasadnie i precyzyjnie, chunk jest dobrze zbudowany. Jeśli halucynuje lub pisze ogólnie, chunk nie jest samodzielny.

Retrieval w 2026 a przyszłość – multimodalny RAG

Kierunek 2026-2027 – multimodalny RAG. Retrieval nie tylko tekstu, ale też obrazów, wideo, audio. Użytkownik może zadać pytanie ze zdjęciem ("co to za produkt?") i silnik retrieval-uje z bazy obrazów plus tekst.

Dla twórców – obrazy z dobrym alt text i schema ImageObject zaczynają być indeksowane jako osobne chunki. Wideo z transkrypcją – tak samo. Audio z transkrypcją – coraz częściej.

Strategia – multimodalna obecność. Artykuł plus hero image z schema plus wideo na YouTube z dobrą transkrypcją plus podcast z transkrypcją na stronie. Wszystko z jednego tematu, wzajemnie linkujące.

Jak RAG wpływa na halucynacje

Klasyczny LLM bez RAG halucynuje – generuje informacje wyglądające prawdziwie, ale nieoparte na faktach. RAG zmniejsza halucynacje, bo LLM pisze odpowiedź z konkretnych cytowanych fragmentów.

Ale halucynacje nie znikają całkowicie. LLM może źle zinterpretować chunk, pomieszać fakty z różnych źródeł, lub wymyślić detal, który nie ma w źródle. Dla twórców – jasna struktura artykułu (jedna zasada per akapit, wyraźne liczby z kontekstem) zmniejsza ryzyko mis-quotation.

Co dalej – integracja z agentami

Kolejny krok po RAG – agent-based retrieval. Agent LLM-a wykonuje wieloetapowy research (kilka retrievalów, iteracyjne uściślanie zapytań) i generuje długą, wieloodcinkową odpowiedź.

Agentowe retrieval wymaga specyficznej optymalizacji – content pokrywający nie tylko "jak", ale też "dlaczego", "kiedy", "dla kogo". Długie supporting-i z wieloma wątkami wchodzą do agentowych cytowań częściej niż krótkie.

Pełna dyskusja o trendach – strategie AIO i SEO plus aktualności SEO i AI 2026.

Implikacje dla strategii contentowej

Podsumowując mechanikę RAG – dla twórcy kilka praktycznych wniosków.

Krótkie akapity (2-4 zdania) – lepsze chunki.
Pierwsze zdanie sekcji = samodzielna odpowiedź.
Bogaty klaster pojęć semantycznych w jednym artykule.
Dokładne frazy użytkowników (dla BM25) plus synonimy (dla embeddings).
Schema.org dla sygnału strukturalnego.
Świeżość (aktualizacja dat, realne zmiany contentu).
Autorytet domeny (backlinki, EEAT).
Modularny styl – każda sekcja samodzielna.
Długość dopasowana do typu (supporting 4500, pillar 8000+).
Konkretne liczby, nazwy własne, daty w pierwszym zdaniu.

Jak LLM-y wybierają finalny fragment do cytowania

Po rerank-u silnik ma top-5 do top-10 chunków. Generation LLM pisze odpowiedź, wybierając, które chunki zacytować. Ten wybór nie jest arbitralny – istnieje druga warstwa selekcji w samym modelu.

Model premiuje chunki – samodzielnie zrozumiałe (niezależne od innych), konkretne (z liczbami lub nazwami własnymi), zwięzłe (łatwe do zacytowania w 1-2 zdaniach odpowiedzi), spójne stylistycznie (nie wymagają parafrazy).

Dla autora praktycznie – pisać tak, żeby fragmenty 50-80 słów z artykułu były "cytowalne" bez modyfikacji. Uniknij wszystkich "jak wcześniej wspomnieliśmy", "zobaczymy dalej", "szczegóły poniżej". Każdy fragment samodzielny.

Optymalizacja prędkości retrieval-u

Silniki AI optymalizują latencję. Dla użytkownika odpowiedź powinna pojawić się w 1-3 sekundy. Dla twórców oznacza to, że wolno ładujące się strony (LCP powyżej 3 sekund) są rzadziej retrieval-owane – silnik woli szybsze alternatywy.

Core Web Vitals – LCP poniżej 2,5s, INP poniżej 200ms, CLS poniżej 0,1. To wymagania, które pokrywają się z klasycznym SEO, ale w AIO są szczególnie ważne dla Google i Gemini.

Drugi aspekt – HTTP response code. Strony zwracające 200 szybko są preferowane. Strony z 301/302 redirect chain, 404 errors, 5xx errors są pomijane.

Dane treningowe a retrieval – różnica

Ważne rozróżnienie. Dane treningowe LLM-a to zbiór tekstów użytych do nauki modelu – ma cutoff (np. styczeń 2026). Retrieval to pobieranie aktualnych dokumentów w czasie zapytania. To dwa różne pipeline-y.

Dla twórców – obecność w danych treningowych = model "zna" waszą markę abstrakcyjnie, ale bez cytowań. Obecność w retrieval = aktualne cytowania z klikalnym linkiem.

Obydwie formy widoczności są cenne, ale o różnych naturach. Trening buduje "brand recognition" w modelu. Retrieval generuje ruch i linki.

Najczęstsze błędy w optymalizacji pod retrieval

Długie akapity (6+ zdań) – chunki są zbyt duże, tracą spójność.
Transitional pierwsze zdania – brak kontekstu w samodzielnym chunku.
Tylko keyword bez synonimów – embeddings nie mają bogatego wzorca.
Brak schema – utrata sygnału rerank-u szczególnie dla Gemini.
Stare daty bez aktualizacji – świeżość penalty.
Brak autora – EEAT penalty dla Claude, Gemini, AI Overviews.
Słaba domena bez backlinków – autorytet penalty dla Perplexity.

Retrievery wielomodalne – obrazy i wideo

Multimodalne retrievery (Gemini, CLIP) potrafią matchować obrazy do tekstu i odwrotnie. Dla zapytania "jak wygląda infografika o SEO 2026" silnik może znaleźć obraz z waszej strony, jeśli ma schema ImageObject z opisem.

Praktyka – obrazy w artykułach z wyraźnym alt text (skoncentrowanym na focus keyword), captionami i schema ImageObject są retrieval-owane osobno od tekstu. Wideo z transkrypcją – podobnie.

Dla twórców multimodalny content jest kolejną warstwą widoczności. Infografiki, diagramy, screenshoty z alt text – wszystko buduje ekspozycję.

Graf wiedzy a retrieval

Niektóre silniki (szczególnie Google) używają grafu wiedzy (Knowledge Graph) jako osobnej warstwy retrieval-u. Graf zawiera encje (osoby, firmy, produkty, miejsca) i ich relacje. Dla zapytań typu "kto jest CEO firmy X" silnik pobiera odpowiedź z grafu, nie z retrievalu dokumentów.

Dla twórców – obecność w grafie wiedzy to osobny kanał widoczności. Jeśli wasza firma ma wpis w Wikipedii, wpis w Wikidata, obecność w Google Business Profile – graf może cytować was bezpośrednio.

Strategia – budowa obecności encji. Wikipedia (jeśli kryteria notability spełnione), Wikidata (bezpośrednio tworzy wpis), LinkedIn z pełnym profilem firmy, Crunchbase, Muck Rack dla dziennikarzy, ORCID dla naukowców.

Dlaczego BM25 wraca do łask

W 2019-2022 BM25 był uważany za przestarzały – "pure embeddings" miały go zastąpić. Ale w 2023-2024 branża odkryła, że embeddings mają słabości (nie radzą sobie z numeric matching, specyficznymi terminami, kodem) i BM25 w hybrydzie daje lepsze wyniki.

Dla twórców – dokładne frazy z zapytań użytkowników dalej się liczą. Klasyczny keyword research (GSC, Ahrefs) daje insights, które frazy warto włączyć do artykułu dla BM25. Nie jest to "keyword stuffing" – chodzi o naturalne włączenie wariantów zapytań w kontekst.

Przykład – artykuł "jak zoptymalizować Core Web Vitals". Warianty zapytań – "jak poprawić Core Web Vitals", "optymalizacja CWV", "Core Web Vitals krok po kroku". Wszystkie można naturalnie ująć w różnych sekcjach artykułu.

Jak retrieval radzi sobie z językami

Embeddings nowoczesnych silników są multijęzyczne – trenowane na danych z wielu języków naraz. Oznacza to, że semantyczne dopasowanie działa międzyjęzykowo. Zapytanie po polsku "jak zoptymalizować stronę" może matchować artykuł po angielsku "how to optimize a website".

Jednak silniki dodają tę warstwę "language preference" – preferują źródła w tym samym języku co zapytanie. Dla polskiego zapytania polskie źródła są promowane, angielskie wyświetlane rzadziej (chyba że brak polskich alternatyw).

Praktyka dla polskich firm – polski content dla polskiego rynku. Angielski content dla międzynarodowego. Hreflang dla wersji wielojęzycznych.

Tabela – zestawienie sygnałów rerank per silnik

Sygnał	ChatGPT	AI Overviews	Gemini	Perplexity	Claude
Embedding similarity	Wysoki	Wysoki	Wysoki	Wysoki	Wysoki
BM25 score	Wysoki	Wysoki	Wysoki	Wysoki	Średni
Autorytet domeny	Średni	Wysoki	Wysoki	Bardzo wysoki	Wysoki
Świeżość	Wysoka	Średnia	Średnia	Wysoka	Średnia
EEAT	Średni	Wysoki	Wysoki	Wysoki	Bardzo wysoki
Schema	Średni	Wysoki	Bardzo wysoki	Średni	Niski

Tabela pokazuje, że nie ma "uniwersalnej optymalizacji". Trzeba zdecydować, który silnik jest priorytetem, i dopasować sygnały.

Modele embeddings używane przez silniki

Każdy silnik używa swojego modelu embeddings. OpenAI – text-embedding-3-large (3072 wymiary). Google – Gecko / text-embedding-004 (768 wymiary). Cohere – embed-multilingual (768 wymiary). Anthropic – nieudostępniona nazwa modelu. To oznacza, że ten sam tekst jest reprezentowany jako różne wektory w różnych silnikach.

Praktyczna konsekwencja – nie ma "uniwersalnej optymalizacji embeddings". To, co dobrze wygląda w OpenAI, może mieć inny score w Google. Dlatego strategie "optymalizuj pod vector" (stosowane przez niektóre narzędzia SEO 2025) są niepewne.

Co działa ogólnie – bogaty klaster pojęciowy, różnorodność synonimów, konkretne nazwy własne, semantic consistency w całym artykule. To sygnały, które wszystkie modele embeddings łapią.

Wpływ długości kontekstu na retrieval

Claude ma największy context window (do 1M tokenów). GPT-4 – 128K. Gemini – 2M (w Deep Research mode). Im większy context, tym więcej chunków silnik może brać pod uwagę w generacji odpowiedzi.

Dla twórców – w silnikach z dużym context window (Claude, Gemini Deep Research) pełne długie artykuły są dostępne. W silnikach z małym context window artykuł jest drastycznie chunkowany.

Strategia – dla Claude i Gemini Deep Research pisanie długich, kompletnych pillar-ów. Dla ChatGPT i AI Overviews – modularne supporting-i z samodzielnymi sekcjami.

Jak testować retrieval dla swojej strony

Narzędzia pozwalające "zajrzeć" do retrievalu. Perplexity API – dostępne publicznie, zwraca listę cytowanych URL-i per zapytanie. Google Search Console – nie pokazuje AI Overviews, ale spadek CTR na pozycji 1-3 dla zapytań informacyjnych jest sygnałem.

AthenaHQ i Peec AI – dashboard-y pokazujące, w których zapytaniach wasza domena jest retrieval-owana (i w których miejscach). Dla dokładnej mechaniki rerank-u silniki nie udostępniają dokumentacji – trzeba eksperymentalnie testować.

Prosta metodologia eksperymentalna – dla 20-30 zapytań sprawdźcie regularnie 5 silników przez 4-6 tygodni, rejestrujcie pozycje i zmiany. Po 4-6 tygodniach widzicie wzorce – gdzie jesteście cytowani stabilnie, gdzie niestabilnie, gdzie wcale.

Siostrzane silniki – jak różnią się retrievery

Każda z pięciu głównych wyszukiwarek używa RAG, ale z innym retrieverem i rerank-em. Różnice w wagach sygnałów powodują, że optymalizacja per silnik jest nieco inna. Pełne porównanie – ChatGPT, AI Overviews, Gemini, Perplexity, Claude.

Praktyczny eksperyment – testowanie chunkingu

Prosta metoda testowania jakości chunkingu własnych artykułów. Krok 1 – skopiujcie przypadkową sekcję H2 (z pierwszym akapitem i trzema kolejnymi). Krok 2 – wkleijcie do ChatGPT z pytaniem "co mówi ten fragment?". Krok 3 – oceńcie odpowiedź.

Jeśli ChatGPT precyzyjnie streszcza zawartość, chunk jest dobrze zbudowany. Jeśli halucynuje lub pisze ogólnie "ten fragment omawia temat X" bez szczegółów, chunk nie jest samodzielny – brakuje mu konkretu w pierwszym zdaniu.

Typowy problem – pierwsze zdanie odwołuje się do "poprzedniego rozdziału" lub "omawianego wcześniej zagadnienia". Fix – przepisać pierwszy akapit tak, żeby zawierał samodzielną tezę i kluczowe terminy.

Druga metoda – Perplexity API. Wprowadźcie zapytanie i sprawdźcie, które chunki waszej strony silnik pobrał. Jeśli rerank zwrócił "końcowy akapit" zamiast "pierwszego akapitu sekcji", oznacza to, że pierwszy akapit nie był czytelny jako chunk.

Rola ostatniego akapitu sekcji

Rerank cross-encoder patrzy nie tylko na pierwsze zdanie, ale też ostatnie. Sekcja kończąca się "wnioskiem" lub "podsumowaniem" ma wyższy score niż sekcja urywająca się w trakcie myśli.

Strategia – każda sekcja H2 ma mini-podsumowanie w ostatnim akapicie. To nie jest rekapitulacja – raczej "praktyczny wniosek" lub "co to znaczy dla czytelnika". Taki zamknięty chunk jest cenniejszy.

Przykład – sekcja o embeddings. Pierwszy akapit – definicja. Środkowe – szczegóły techniczne. Ostatni – "Praktyczna konsekwencja dla autora – bogaty klaster pojęć w artykule podnosi score dla wielu wariantów zapytań." Kompletny, samodzielny chunk.

Ekonomia retrievalu – koszt per zapytanie

Dla silników AI retrieval jest relatywnie tani (0,0001-0,001 USD per zapytanie), ale skala utrudnia. 100 milionów zapytań dziennie to 10-100 tysięcy USD dziennie tylko na retrieval – bez generowania odpowiedzi.

Konsekwencje dla twórców – silniki optymalizują koszt retrievalu przez ograniczenie liczby kandydatów. Nie retrieval-ują 10000 dokumentów per zapytanie, tylko 100-200. To zwiększa wagę sygnałów klasyfikacji wstępnej (schema, autorytet, świeżość).

Drugi aspekt – rerank jest znacznie droższy niż retrieval (wymaga uruchomienia cross-encoder dla każdej pary zapytanie-dokument). Dlatego rerank obejmuje tylko top-50-100 kandydatów z retrievalu. Jeśli wasz artykuł nie trafił do retrievalu top-100, nie ma szansy na cytowanie – niezależnie od jakości.

Co to są "cross-domain signals" w RAG

Niektóre silniki (szczególnie Perplexity i Google) używają "cross-domain signals" – sygnałów, które wskazują, że dany dokument jest cytowany lub linkowany z innych autorytatywnych domen. To odpowiednik klasycznego PageRank w nowym wcieleniu.

Praktyka – artykuł cytowany w Wikipedii, w branżowym newsletter, w GitHub README ma w rerank-u znacząco wyższy score. Strategia – budowanie obecności w ekosystemie branżowym, nie tylko własnym blogu. Więcej – budowa autorytetu.

FAQ

Co to jest RAG w kontekście AI?

RAG (Retrieval-Augmented Generation) to architektura systemów AI, w której model językowy generuje odpowiedź, ale wspierając się dokumentami wyszukanymi z indeksu w czasie rzeczywistym. Alternatywa to "pure LLM" – odpowiedź tylko z pamięci treningu. RAG rozwiązuje problem halucynacji i nieaktualnych danych.

Czym różni się BM25 od embeddings?

BM25 to klasyczny algorytm oparty na częstotliwości keyword-ów. Embeddings to wektorowe reprezentacje znaczenia. BM25 jest szybki i dobry w dokładnym dopasowaniu, embeddings są lepsze w rozumieniu synonimów i parafraz. Nowoczesne retrievery używają hybrydy obu technik.

Co to jest chunking?

Chunking to dzielenie dokumentu na fragmenty 500-2000 tokenów (400-1500 słów), które są osobno indeksowane i rerank-owane. LLM nie czyta całego artykułu – tylko top-k chunków. Każdy chunk musi być samodzielnie zrozumiały, żeby trafić do cytowań.

Dlaczego rerank jest ważniejszy niż retrieval?

Retrieval zwraca 50-200 kandydatów, rerank wybiera finalną piątkę. Możecie być w retrievalu top-100, ale jeśli rerank was nie wybierze, nie ma cytowań. Rerank premiuje specyficzność, świeżość, autorytet – czyli sygnały jakościowe ponad ilościowe.

Czy RAG halucynuje?

RAG znacząco zmniejsza halucynacje, bo LLM pisze odpowiedź z konkretnych fragmentów. Ale halucynacje nie znikają – LLM może źle zinterpretować chunk, pomieszać fakty, lub wymyślić detal. Dla twórców jasna struktura artykułu zmniejsza ryzyko mis-quotation.

Jak sprawdzić czy mój content jest dobrze chunkowany?

Podzielcie artykuł na fragmenty 500-800 słów. Weźcie przypadkowy chunk i zadajcie AI pytanie "o czym jest ten fragment?". Jeśli AI odpowiada zasadnie, chunk jest samodzielny. Jeśli halucynuje, pierwszy akapit sekcji potrzebuje kontekstu.

Czy wszystkie silniki używają tej samej mechaniki RAG?

Tak, ogólna struktura (retrieval + rerank + generation) jest wspólna. Różnice – indeks bazowy (Google, Bing, Brave, własny crawler), wagi sygnałów rerank-u, konkretne modele embeddings i cross-encoder. Dlatego ten sam artykuł może być cytowany w jednym silniku i pomijany w innym.

Ile fragmentów mojego artykułu jest cytowanych?

Typowo 1-2 chunki per cytowanie. LLM wybiera z top-5 chunków najbardziej relewantny i generuje odpowiedź cytującą 1-2 z nich. Artykuł z 10 dobrze skonstruowanych chunków ma szansę cytowania dla wielu różnych zapytań.