Embedding

Jak to działa?

1. Tekst trafia do modelu embeddingów, czyli Transformera wytrenowanego tak, żeby podobne znaczenia lądowały blisko siebie.
2. Model zwraca wektor o stałej długości, np. 768 albo 1536 liczb, bez względu na długość tekstu.
3. Wektory porównuje się podobieństwem cosinusowym: im bliżej 1, tym bliższe znaczenie.
4. Embedding nie generuje tekstu. Opisuje go. To inny model niż ten, który odpowiada w czacie.

Jak to robi nasz lab?

• Dwa modele, dwa zadania: Gemini (1536 liczb) liczy wektory wszystkich prac i wpisów w bazie, z których powstają mapa wiedzy, rolki i Indeks badań AI; EmbeddingGemma (768 liczb) działa lokalnie na naszym serwerze, za darmo, i obsługuje czat.
• Wybór modelu czatu pomiarem, nie z rankingu: porównaliśmy kandydatów na 18 pytaniach z naszej bazy. EmbeddingGemma znalazła właściwy tekst w pierwszej piątce 18 razy na 18 (MRR 0,917).
• Darmowy limit to też limit: Gemini liczy każdy tekst w paczce jako osobne zapytanie. Przy dziennym limicie 1 000 robimy 40 tekstów na godzinę, a fala ~850 zaległych streszczeń zablokowała nam kiedyś rolkę na ponad dobę.
• Lokalnie też jest koszt: serwer liczy jedno zapytanie naraz, więc 128 tekstów zajęło 58,5 s, a pytania z czatu w tym czasie czekały. Dlatego wektory czatu doliczamy małymi paczkami co godzinę.

Kiedy który model?

• Lokalny model (np. EmbeddingGemma, Qwen3-Embedding, bge-m3): dane nie wychodzą z firmy, koszt 0 zł, ale potrzebny jest serwer i liczy się wolniej.
• Model w chmurze (Gemini, OpenAI): szybki start i bez sprzętu, ale limity, koszt przy dużej skali i dane wysyłane na zewnątrz.
• Zawsze: pytanie i dokumenty muszą przejść przez ten sam model. Wektorów z różnych modeli nie da się porównać.

Najczęstsze pułapki

• Wybór modelu z cudzego rankingu zamiast z 20–30 własnych pytań.
• Zmiana modelu bez przeliczenia całej bazy.
• Krótkie, potoczne pytania („a wektory?”) słabo trafiają. Dopisujemy do nich kontekst przed liczeniem wektora, co podniosło trafienia z 24 na 30 z 30.