Embeddingi w analizie treści: jak sprawdzić dopasowanie do tematu

Embedding to lista liczb, którą model językowy przypisuje fragmentowi tekstu. Dwa teksty o podobnym znaczeniu dostają podobne listy, więc odległość między nimi da się policzyć. Dla redakcji oznacza to jedno: zamiast zgadywać, czy wpis odpowiada na zapytanie, można to zmierzyć liczbą od mniej więcej 0 do 1. W tym tekście pokazujemy, jak zrobić taką analizę treści na własnym blogu, ile to kosztuje i w którym miejscu liczby przestają cokolwiek mówić.

Od razu zastrzeżenie: nie publikujemy tu wyników własnego pomiaru na seotrade.pl. Opisujemy procedurę, ceny z cenników dostawców (stan na 11 listopada 2026) i progi, które warto przetestować na swoich danych. Szerszy kontekst narzędzi, w które taka analiza się wpisuje, znajdziesz w przeglądzie stacku narzędzi do AIO.

Czym jest embedding w praktyce redakcyjnej

Model embeddingowy zamienia tekst na wektor o stałej długości. W modelu text-embedding-3-small od OpenAI wektor ma domyślnie 1536 liczb, w text-embedding-3-large 3072 (tak podaje dokumentacja embeddingów OpenAI). Pojedyncza liczba nic nie znaczy. Znaczenie ma położenie całego wektora względem innych.

Redaktor nie musi rozumieć, jak model się uczył. Wystarczy przyjąć trzy praktyczne zasady:

• teksty o tym samym temacie leżą blisko siebie, nawet jeśli używają innych słów (synonimy, odmiana, parafraza);
• teksty, które tylko powtarzają frazę kluczową, a mówią o czymś innym, leżą dalej, niż sugerowałby licznik słów kluczowych;
• odległość mierzy się zwykle podobieństwem kosinusowym, czyli kątem między wektorami, a nie ich długością.

To ta sama mechanika, której wyszukiwarki AI używają na etapie wyszukiwania fragmentów do odpowiedzi. Dlatego analiza embeddingowa jest bliżej tego, jak system RAG ocenia stronę, niż klasyczna gęstość słów kluczowych. Więcej o samym dzieleniu tekstu na kawałki piszemy w poradniku o chunkingu tekstu pod LLM.

Jakie dane trzeba przygotować przed analizą

Większość błędów w takich analizach bierze się nie z modelu, tylko z brudnych danych wejściowych. Przed wysłaniem czegokolwiek do API przygotuj arkusz z kolumnami: URL, tytuł, czysta treść, główne zapytanie, kategoria.

Czysta treść, nie cała strona

Embedding liczony z pełnego HTML strony łapie menu, stopkę, sidebar i listę powiązanych wpisów. Na blogu z rozbudowanym szablonem te elementy są identyczne na każdej podstronie i sztucznie zbliżają wszystkie wpisy do siebie. Wyciągaj wyłącznie treść artykułu: w WordPressie najprościej przez REST API (pole content.rendered) albo przez ekstrakcję z kontenera .entry-content w crawlerze. Jak ustawić taką ekstrakcję w crawlerze, opisujemy w tekście o konfiguracji Screaming Froga do audytu pod AI.

Długość i podział

Modele OpenAI przyjmują do 8192 tokenów na jedno wejście. Tekst po polsku zużywa więcej tokenów niż angielski, więc długi poradnik może przekroczyć limit. Są dwie drogi: liczyć jeden wektor dla całego wpisu (wystarcza do mapy tematycznej) albo dzielić wpis na sekcje według H2 i liczyć wektor dla każdej (lepsze do sprawdzania, czy konkretny fragment odpowiada na pytanie). Na start polecamy oba poziomy: wektor wpisu i wektory sekcji.

Zapytania

Do każdego wpisu przypisz 1–3 zapytania, na które ma odpowiadać. Najlepiej z Google Search Console (zapytania z wyświetleniami), a nie z założeń w planie treści. Jeśli prowadzisz już monitoring widoczności AI w Google Sheets, ten sam arkusz z promptami nadaje się jako źródło zapytań konwersacyjnych.

Liczenie podobieństwa między wpisem a zapytaniem

Procedura jest krótka:

1. Wyślij do API treść wpisu (lub sekcji) i zapisz zwrócony wektor.
2. Wyślij zapytanie tym samym modelem i zapisz jego wektor. Mieszanie modeli nie działa: wektory z różnych modeli są nieporównywalne.
3. Policz podobieństwo kosinusowe: iloczyn skalarny podzielony przez iloczyn długości obu wektorów. W arkuszu wystarczy SUMA.ILOCZYNÓW podzielona przez iloczyn pierwiastków z SUMA.KWADRATÓW.
4. Zapisz wynik przy wpisie i powtórz dla każdego zapytania.

Część modeli rozróżnia rolę tekstu. W Gemini API ustawia się typ zadania, osobno dla dokumentu i osobno dla zapytania wyszukiwawczego; opis znajdziesz w dokumentacji embeddingów Gemini. Jeśli model to oferuje, korzystaj z tego, bo zapytanie i odpowiedź z natury wyglądają inaczej.

Bezwzględna wartość podobieństwa zależy od modelu, dlatego nie ma uniwersalnego progu typu „0,8 to dobrze”. Sensowniej jest porównywać względnie: który wpis w serwisie ma najwyższy wynik dla danego zapytania i czy to ten, który chcesz pozycjonować. Jeśli dla zapytania „audyt treści pod AI” najbliżej leży przypadkowy wpis newsowy, a nie poradnik, masz konkretny sygnał do poprawy.

Rozjazd tematyczny wewnątrz wpisu

Wektory sekcji pozwalają wykryć rozjazd tematyczny. Policz podobieństwo każdej sekcji H2 do głównego zapytania wpisu. Sekcje, które wyraźnie odstają od reszty w dół, to zwykle dygresje, rozbudowane wstępy o historii tematu albo bloki dopisane „pod inne słowo”. Nie trzeba ich od razu usuwać, ale warto zapytać, czy nie powinny być osobnym tekstem.

Wykrywanie wpisów, które konkurują o ten sam temat

Drugie zastosowanie to szukanie par wpisów zbyt do siebie podobnych. Licz podobieństwo każdego wpisu z każdym (dla stu wpisów to 4950 par, co arkusz lub kilka linii skryptu policzy w sekundę) i posortuj malejąco.

Na górze listy znajdą się trzy rodzaje par:

• prawdziwe duplikaty intencji: dwa wpisy odpowiadają na to samo pytanie, często napisane w odstępie roku przez różne osoby;
• filar i jego wpis pomocniczy: wysokie podobieństwo jest tu naturalne i nie wymaga działania, o ile oba teksty mają różne zapytania główne;
• wpisy z tego samego szablonu: podobne, bo powtarzają strukturę i bloki tekstu, a nie temat.

Embedding wskazuje kandydatów, ale decyzję podejmuje dane z Search Console. Para jest problemem dopiero wtedy, gdy oba adresy pojawiają się na te same zapytania i zamieniają się pozycjami. Cały proces łączenia takich wpisów opisaliśmy w tekście o wykrywaniu i łączeniu kanibalizacji słów kluczowych.

Mapa tematyczna serwisu na podstawie podobieństwa

Mając wektory wszystkich wpisów, można je pogrupować algorytmem klastrowania (np. k-means albo klastrowanie hierarchiczne) i zobaczyć, jak serwis wygląda „oczami modelu”. Wynik porównuje się z kategoriami w WordPressie.

Typowe odkrycia z takiego porównania:

• kategoria, której wpisy rozpadają się na dwa odległe skupiska, to sygnał, że w jednej szufladzie są dwa tematy;
• wpis, który ląduje w klastrze innej kategorii, jest źle przypisany albo ma mylący tytuł;
• skupisko kilku wpisów bez wspólnego filaru to gotowy kandydat na nowy tekst nadrzędny;
• pary bliskich wpisów bez linku między sobą to lista brakujących linków wewnętrznych.

Ostatni punkt jest najbardziej praktyczny. Dla każdego wpisu weź pięciu najbliższych sąsiadów i sprawdź, czy któryś z nich już do niego linkuje. Jeśli nie, masz uzasadnioną propozycję linku, dużo trafniejszą niż dopasowanie po słowach kluczowych.

Interpretacja wyników: gdzie kończy się przydatność liczb

Podobieństwo kosinusowe mierzy zbieżność znaczenia. Nie mierzy jakości, aktualności ani wiarygodności. Wpis pełen ogólników może mieć wysoki wynik dla zapytania, bo dotyka wszystkich jego pojęć, a mimo to nie odpowiadać na nie konkretnie.

Kilka granic, o których trzeba pamiętać:

• Model nie widzi faktów. Tekst z błędną ceną i tekst z poprawną ceną dostaną niemal ten sam wektor.
• Wynik zależy od modelu. Zmiana modelu w połowie projektu unieważnia wszystkie wcześniejsze liczby; trzeba przeliczyć całość.
• Długość wpływa na wektor. Bardzo długi wpis jest „uśredniony” i bywa mniej podobny do wąskiego zapytania niż jego najlepsza sekcja. Dlatego warto liczyć też sekcje.
• Ranking to nie tylko dopasowanie. Google i wyszukiwarki AI biorą pod uwagę linki, autorytet domeny i sygnały zachowań. Wpis idealnie dopasowany semantycznie może przegrywać z gorzej dopasowanym, ale silniejszym adresem.

Rozsądne podejście: embedding traktujemy jako filtr, który zawęża listę wpisów do ręcznego przeglądu, a nie jako wyrocznię. O tym, jak pojęcia, encje i powiązania tematyczne układają się w szerszą strategię, piszemy w tekście o semantic SEO: encjach, ontologiach i embeddingach.

Koszt i czas takiej analizy dla stu wpisów

Sama analiza jest tania. Policzmy szacunkowo dla stu wpisów po około 1500 słów. Polski tekst zużywa w tokenizatorach OpenAI zwykle 2–3 tokeny na słowo, więc przyjmujemy ok. 4000 tokenów na wpis, czyli 400 tys. tokenów dla całego zbioru. Liczenie sekcji osobno mniej więcej podwaja tę liczbę, bo treść przechodzi przez model drugi raz.

Ceny pochodzą z cenników OpenAI i Google AI z 11 listopada 2026; kwoty dla stu wpisów to nasze wyliczenie, nie faktura. Google oferuje też darmowy poziom API, z którego dane mogą jednak służyć do ulepszania produktów Google, więc do treści przed publikacją lepiej użyć płatnego. Zapytania kosztują ułamek tej kwoty, bo są krótkie.

Prawdziwym kosztem jest czas człowieka. Orientacyjnie:

• eksport i czyszczenie treści: 1–2 godziny przy pierwszym podejściu, potem minuty;
• przypisanie zapytań z Search Console: 2–3 godziny dla stu wpisów;
• wywołania API i obliczenia: kilka minut, jeśli masz gotowy skrypt lub arkusz z dodatkiem;
• ręczny przegląd 20–30 najbardziej podejrzanych par i wpisów: 3–4 godziny.

Łącznie to jeden dzień pracy, z czego większość to analiza wyników, a nie technika. Przy powtórce co kwartał (nowe wpisy, zmiany w Search Console) czas spada do kilku godzin, bo wektory starych, niezmienionych wpisów można trzymać w arkuszu i nie liczyć ich ponownie. Ten sam proces pomaga też sprawdzić, czy treść o marce jest spójna z tym, jak opisują ją odpowiedzi AI cytujące marki.

FAQ