Embeddings — po co są i jak działają w praktyce?

Problem: komputer nie wie, że „wolne” to „urlop”#

Klasyczne wyszukiwanie dopasowuje słowa. Zapytanie „ile mam wolnego” nie znajdzie dokumentu „wymiar urlopu wypoczynkowego”, bo nie dzielą ani jednego wyrazu. Ludzie widzą, że to to samo — maszyna potrzebuje sposobu, żeby „to samo” policzyć.

Tym sposobem są embeddingi: funkcja, która zamienia tekst na wektor kilkuset-kilku tysięcy liczb tak, że teksty o podobnym znaczeniu dostają podobne wektory. „Urlop” i „wolne od pracy” lądują blisko siebie; „urlop” i „faktura VAT” — daleko.

Jak mierzy się „bliskość”?#

Standardem jest podobieństwo kosinusowe — kąt między wektorami. Wartość 1 oznacza identyczny kierunek (to samo znaczenie), okolice zera — brak związku. W SQL z pgvector wygląda to tak:

-- operator <=> zwraca odleglosc kosinusowa (mniejsza = blizej)
select tresc
from dokumenty
order by embedding <=> $zapytanie
limit 5;

Cała „magia” wyszukiwania semantycznego to dosłownie ta jedna operacja — wykonywana błyskawicznie na milionach rekordów dzięki indeksom (HNSW, IVF).

Nie tylko RAG#

RAG rozsławił embeddingi, ale pracują one w wielu miejscach:

• deduplikacja — dwa zgłoszenia o tym samym problemie mają bliskie wektory, nawet gdy są napisane innymi słowami,
• routing — nowe zgłoszenie trafia do kategorii, której przykłady są mu najbliższe,
• rekomendacje — „podobne artykuły” liczone ze znaczenia, nie z tagów,
• wykrywanie anomalii — wiadomość daleka od wszystkich znanych klastrów to sygnał czegoś nowego.

Ile to kosztuje i ile waży#

Dwie liczby, które warto oszacować przed wyborem architektury.

Koszt policzenia wektorów jest jednorazowy i zwykle mały: modele embeddingów są o rząd wielkości tańsze od modeli generujących tekst, a fragment dokumentu to kilkaset tokenów. Baza wiedzy licząca kilkanaście tysięcy fragmentów kosztuje w przeliczeniu tyle, co jeden dzień pracy asystenta na produkcji. Doliczyć trzeba jednak przeliczenia: każda zmiana modelu albo sposobu cięcia oznacza policzenie wszystkiego od nowa.

Rozmiar bywa zaskoczeniem w drugą stronę. Wektor o 1536 wymiarach w liczbach zmiennoprzecinkowych to około 6 kB — czyli często więcej niż sam fragment tekstu, z którego powstał. Przy milionie fragmentów mówimy o kilku gigabajtach samych wektorów, zanim doliczy się indeks. Stąd popularność wektorów o mniejszej liczbie wymiarów i kwantyzacji tam, gdzie skala zaczyna mieć znaczenie.

Jak sprawdzić, czy to w ogóle działa#

Wyszukiwanie semantyczne ma nieprzyjemną właściwość: zawsze coś zwróci. Nie ma stanu „nie znalazłem” — jest tylko ranking, w którym na pierwszym miejscu stoi coś, co może być kompletnie nie na temat.

Dlatego jedyny sensowny sposób oceny to zestaw pytań z oczekiwanymi fragmentami. Trzydzieści realnych zapytań, przy każdym zapisane, który fragment jest poprawną odpowiedzią, i dwie liczby: jak często właściwy fragment jest w pierwszej piątce oraz jak często jest na pierwszym miejscu. Te dwie liczby porównuje się przy każdej zmianie — modelu, cięcia, rerankingu. Bez nich „poprawiliśmy wyszukiwanie” znaczy dokładnie tyle, co „zmieniliśmy wyszukiwanie”.

Warto też ustawić próg odcięcia: jeśli najlepszy wynik jest dalej niż ustalona granica, lepiej odpowiedzieć „nie mam tego w dokumentach” niż podać najbliższy przypadkowy fragment.

Trzy rzeczy, o które rozbijają się wdrożenia#

1. Mieszanie modeli. Wektor z modelu A i wektor z modelu B to dwa różne języki — porównywanie ich daje szum. Jeden model na całą bazę; zmiana modelu = przeliczenie wszystkiego.
2. Embedding całych dokumentów. Wektor 40-stronicowej umowy uśrednia jej sens do mdłej papki. Embedduje się fragmenty — o cięciu pisaliśmy przy okazji RAG.
3. Ślepa wiara w ranking. Najbliższy fragment nie zawsze jest właściwy. Systemy produkcyjne dokładają reranking albo filtry metadanych — i mierzą trafność na realnych zapytaniach, zamiast zakładać, że „wektor wie”.