Komputery rozumieją liczby, nie słowa. Żeby model AI mógł porównywać znaczenie dwóch tekstów, te teksty muszą być zamienione na liczby w taki sposób, że podobne znaczeniowo teksty dają podobne liczby — a teksty o różnym znaczeniu dają liczby odległe od siebie.
To właśnie robi embedding.
Czym jest embedding
Embedding to numeryczna reprezentacja tekstu, obrazu lub innego obiektu w wielowymiarowej przestrzeni wektorowej — gdzie podobne znaczeniowo obiekty mają bliskie wektory, a różne mają dalekie — używana jako fundament wyszukiwania semantycznego, RAG i wielu innych zastosowań AI. Tekst „agent AI” i „autonomiczny system sztucznej inteligencji” będą miały bliskie embeddingi mimo że nie mają wspólnych słów.
Pojedyncza liczba w wektorze nie znaczy przy tym nic. Nie istnieje kolumna „czy to zwierzę” ani „czy to coś dużego” — nikt tych wymiarów nie zaprojektował i nie da się ich sensownie nazwać. Znaczenie siedzi wyłącznie w położeniu względem innych wektorów, więc podobieństwo znaczeniowe staje się odległością, czyli czymś, co da się policzyć.
Dwa różne embeddingi
Tym samym słowem określa się dwie rzeczy, które warto rozróżniać.
Embedding tokenu to wiersz macierzy embeddingów wewnątrz modelu językowego. Macierz ma tyle wierszy, ile pozycji liczy słownik modelu, i tyle kolumn, ile wynosi wymiar reprezentacji. Numer tokenu zwrócony przez tokenizer wskazuje konkretny wiersz — i dopiero ten wiersz jest wektorem. Macierz powstała podczas treningu i jest częścią modelu, w odróżnieniu od tokenizera, który jest zwykłym algorytmem bez wag.
Embedding tekstu to wektor całego zdania, akapitu lub dokumentu, zwracany przez osobny model embeddingowy trenowany specjalnie w tym celu. To on jest używany w RAG i w wyszukiwaniu semantycznym.
Mechanizm jest pokrewny, ale to inne modele, o innym wymiarze wektora i innym cenniku. Reszta tego hasła dotyczy głównie embeddingu tekstu.
Statyczny kontra kontekstowy
Wiersz wyciągnięty z macierzy embeddingów jest zawsze taki sam. Słowo „zamek” dostaje ten sam wektor niezależnie od tego, czy chodzi o budowlę, urządzenie w drzwiach czy suwak w kurtce. To embedding statyczny i sam z siebie nie rozstrzyga żadnej wieloznaczności.
Rozstrzygnięcie przychodzi później. Wektor przechodzi przez kolejne warstwy modelu i na każdej z nich jest aktualizowany na podstawie sąsiadów w zdaniu przez mechanizm uwagi. Po kilku warstwach „zamek” w zdaniu o zardzewiałym mechanizmie ma inne współrzędne niż „zamek” w zdaniu o murach obronnych. To są embeddingi kontekstowe i to one wykonują faktyczną pracę.
Macierz embeddingów daje więc punkt startowy, nie odpowiedź.
Jak to działa
Model embeddingowy przetwarza tekst i zwraca wektor — listę liczb zmiennoprzecinkowych, zazwyczaj od 768 do 3072 wymiarów. Ten wektor koduje znaczenie tekstu w sposób, którego model nauczył się podczas treningu.
Dwa teksty o podobnym znaczeniu będą miały wektory, których odległość cosinusowa jest mała. „Jak działa MCP?” i „Co to jest Model Context Protocol?” — bardzo bliskie embeddingi. „Jak działa MCP?” i „Przepis na sernik” — bardzo odległe.
Skąd model wie, co jest blisko czego? Nikt tego nie wpisał. Wynika to z obserwacji o języku: słowa i zdania o podobnym znaczeniu występują w podobnym towarzystwie. Model uczy się nadawać im podobne reprezentacje, bo to najprostszy sposób, by dobrze przewidywać ich otoczenie. Znaczenie w tym sensie jest w całości pochodną tekstów treningowych — ze wszystkim, co w nich było, łącznie z dysproporcją między angielszczyzną a polszczyzną.
Embedding w RAG
RAG działa przez embeddingi. Wszystkie dokumenty w bazie wiedzy są najpierw zamieniane na embeddingi i przechowywane w vector database. Gdy użytkownik zadaje pytanie, pytanie też jest zamieniane na embedding i porównywane z embeddingami dokumentów. Dokumenty z najbliższymi embeddingami są pobierane jako kontekst dla modelu.
To jest kluczowa właściwość RAG: wyszukiwanie semantyczne przez embeddingi zamiast wyszukiwania słów kluczowych. Agent, który szuka odpowiedzi na pytanie „jak agent może kupić produkt?”, znajdzie dokumenty o Instant Checkout i agentic commerce — nawet jeśli nie zawierają tych konkretnych słów.
Embeddingi dla właściciela strony
Właściciel strony, który buduje chatbota lub agenta opartego na własnej treści, musi zbudować embeddingi swojej bazy wiedzy. Każdy artykuł, każda strona FAQ, każdy dokument produktowy jest zamieniany na embedding i przechowywany w vector database.
Jakość embeddingów zależy od modelu embeddingowego i jakości tekstu. Chunking, czyli sposób dzielenia tekstu na fragmenty przed embeddingiem, ma duży wpływ na jakość retrieval. Zbyt duże chunki gubią szczegóły, zbyt małe tracą kontekst.
Czego embeddingi nie potrafią
Trzy ograniczenia, które w praktyce zaskakują najczęściej.
Przeciwieństwa leżą blisko siebie. „Dobry” i „zły” występują w niemal identycznym towarzystwie, więc mają podobne reprezentacje — wyszukiwanie semantyczne potrafi z tego powodu zwrócić dokument mówiący coś dokładnie odwrotnego niż pytanie.
Negacja bywa niewidoczna. „Umowa obejmuje szkody” i „umowa nie obejmuje szkód” są w przestrzeni wektorowej niepokojąco blisko. Przy dokumentach prawnych i technicznych to realne ryzyko.
Liczby i identyfikatory nie mają sensownego położenia. Numer faktury, kwota czy data to dla przestrzeni znaczeń szum — do wyszukiwania po nich służy zwykłe wyszukiwanie po tekście, a dobre wdrożenia łączą oba podejścia.
Koszty
Generowanie embeddingów kosztuje — zarówno obliczeniowo, jak i finansowo, jeśli używasz API. Dla typowego serwisu contentowego z kilkuset artykułami koszt jednorazowego zbudowania bazy jest niewielki, a ponowne przeliczanie przy aktualizacji treści dotyczy tylko zmienionych dokumentów. Wyjątkiem jest zmiana modelu embeddingowego, która wymusza przeliczenie całości.
[hasło zmodyfikowane 17.08.2026] – dodana definicja embedding tokenu