Osadzenia Google, tekst, obraz i wideo

Osadzenia Google, czyli pięć rodzajów treści w jednej przestrzeni

Google udostępnia modele osadzeń przez dwie drogi: prostsze API dla twórców oraz platformę chmurową dla wdrożeń firmowych. Modele są te same, różni się warstwa dostępu, rozliczenie i to, jakie mechanizmy zarządzania dostajesz wokół.

Wyróżnik najnowszego modelu jest tu największy w całej kategorii. Poza tekstem i obrazami przyjmuje również wideo, dźwięk i całe dokumenty, osadzając wszystko w jednej wspólnej przestrzeni. Zapytanie napisane słowami może więc odnaleźć fragment nagrania albo scenę z filmu, bez opisywania ich tekstem.

Ten tekst dotyczy wyłącznie modeli osadzeń: parametrów, kompresji i praktyki wdrożenia. Szerszy opis rodziny modeli językowych tego dostawcy znajdziesz w osobnym opracowaniu.

Typ zadania, czyli parametr, który trzeba podać

To najczęstsze źródło słabych wyników przy pierwszym użyciu i rzecz odróżniająca te modele od najprostszych rozwiązań konkurencji.

Przy każdym wywołaniu deklarujesz, do czego wektor ma służyć. Dokument trafiający do indeksu oznaczasz inaczej niż zapytanie użytkownika, a jeszcze inaczej tekst przeznaczony do klasyfikacji, grupowania albo oceny podobieństwa dwóch tekstów.

from google import genai

klient = genai.Client()

dokumenty = klient.models.embed_content(
    model="gemini-embedding-001",
    contents=fragmenty,
    config={"task_type": "RETRIEVAL_DOCUMENT", "output_dimensionality": 768},
)

pytanie = klient.models.embed_content(
    model="gemini-embedding-001",
    contents=["Jaki jest okres wypowiedzenia?"],
    config={"task_type": "RETRIEVAL_QUERY"},
)

Model traktuje oba przypadki inaczej, bo zapytanie i dokument mają odmienną naturę. Zapytanie jest krótkie i pytające, dokument długi i twierdzący, więc osadzanie ich tak samo pogarsza dopasowanie.

Najczęstszy błąd polega na użyciu tej samej wartości dla jednego i drugiego. Wyszukiwanie wtedy działa, zwraca wyniki i jest po prostu wyraźnie gorsze, więc problem bywa niezauważony przez miesiące.

Osobna wartość służy do oceny podobieństwa dwóch tekstów między sobą, na przykład przy wykrywaniu duplikatów. Użycie jej do wyszukiwania daje gorsze rezultaty niż para przeznaczona do tego celu, mimo że intuicyjnie wydaje się właściwa.

Warto też zapamiętać, którą wartość zastosowano przy budowie indeksu, i zapisać ją obok wektorów. Zmiana typu zadania przy dokładaniu nowych dokumentów daje wpisy nieporównywalne z resztą, a objawem są po prostu gorsze wyniki dla części zbioru, bez żadnego błędu i bez oczywistej przyczyny.

Jedno zastrzeżenie dotyczy nowszego modelu wielomodalnego, bo tam ten parametr nie istnieje. Zadanie deklarujesz przedrostkiem dopisanym do samej treści: zapytanie formatujesz jako task: search result | query: ..., a dokument jako title: ... | text: .... Przenosząc kod z modelu tekstowego, przepisujesz więc nie wywołanie, tylko sposób budowania tekstu. Druga różnica jest jeszcze łatwiejsza do przeoczenia: model tekstowy zwraca osobny wektor dla każdego elementu listy, a wielomodalny scala wiele wejść w jeden uśredniony wektor, więc do osadzenia wielu fragmentów naraz służy tryb wsadowy, a nie lista w jednym wywołaniu.

Model wielomodalny

Model gemini-embedding-2 wprowadził rzecz, której konkurencja nie oferuje w takim zakresie: jedną przestrzeń dla pięciu rodzajów treści. Wersja zapoznawcza ruszyła 10 marca 2026 roku, a ogólna dostępność 22 kwietnia 2026 roku.

Tekst, obraz, wideo, dźwięk i dokumenty trafiają do wspólnej przestrzeni przez tę samą architekturę. To znaczy, że jeden indeks obsługuje wszystko, a porównanie zapytania tekstowego z fragmentem nagrania jest zwykłym obliczeniem odległości, bez tłumaczenia czegokolwiek na tekst pośredni.

Zastosowania, w których różnica jest największa, są konkretne. Archiwum nagrań ze spotkań, gdzie pytanie o decyzję odnajduje moment, w którym zapadła. Biblioteka materiałów wideo, gdzie szukasz sceny, a nie pliku. Zbiór dokumentów, których treść siedzi w układzie graficznym: prezentacje, formularze, schematy.

Przy tym ostatnim warto docenić, ile kroków to pomija. Klasyczna droga wymaga rozpoznania tekstu z obrazu, odtworzenia struktury i osadzenia wyniku, a każdy z tych etapów gubi część informacji. Osadzenie strony jako obrazu pomija cały ten łańcuch.

Model przyjmuje też czterokrotnie dłuższe wejście niż poprzednia generacja, osiem tysięcy sto dziewięćdziesiąt dwa tokeny zamiast dwóch tysięcy czterdziestu ośmiu, co przy dokumentach, których nie da się sensownie podzielić, oszczędza pracę. Nie jest to jednak zachęta do osadzania całych dokumentów, bo wektor uśrednia treść, więc dokument o dwunastu tematach przestaje trafiać w cokolwiek.

Ograniczenia poszczególnych rodzajów treści są przy tym twarde i warto je znać przed zaprojektowaniem indeksu: dźwięk do stu osiemdziesięciu sekund, wideo do stu dwudziestu sekund i najwyżej trzydziestu dwóch klatek, dokument PDF do sześciu stron i jeden plik na żądanie. Do tego pułapka wprost z dokumentacji: ścieżka dźwiękowa pliku wideo nie jest przetwarzana, więc nagranie ze spotkania trzeba podać osobno jako obraz i osobno jako dźwięk.

Skracanie wymiarów

Domyślnie wektor ma trzy tysiące siedemdziesiąt dwa wymiary, a model pozwala zażądać krótszego, aż do stu dwudziestu ośmiu, bez przeliczania go od nowa.

Kluczowa informacja jest taka, że cena za tokeny nie zależy od liczby wymiarów. Oszczędność leży wyłącznie po stronie przechowywania i wyszukiwania, za to jest tam znacząca.

Rachunek przekonuje. Wektor trzytysięcznowymiarowy zajmuje dwanaście kilobajtów, ten sam skrócony do siedmiuset sześćdziesięciu ośmiu wymiarów trzy kilobajty. Przy pięciu milionach fragmentów to różnica między sześćdziesięcioma a piętnastoma gigabajtami w bazie wektorowej, plus czterokrotnie szybsze porównywanie.

Strata trafności przy skróceniu do siedmiuset kilkudziesięciu wymiarów jest w większości zastosowań niezauważalna bez pomiaru. Warto natomiast ten pomiar wykonać, bo zależy od zbioru: pięćdziesiąt realnych pytań z oczekiwanymi odpowiedziami, ten sam zbiór zaindeksowany dwoma wariantami i porównanie, ile razy właściwy dokument trafił do pierwszej piątki.

Zastrzeżenie techniczne: skrócone wektory trzeba znormalizować, bo obcięcie zaburza ich długość. W modelu tekstowym robisz to sam, dla każdej liczby wymiarów innej niż pełne trzy tysiące siedemdziesiąt dwa. Model wielomodalny normalizuje wektory skrócone samodzielnie, więc przy przenoszeniu kodu ten krok trzeba usunąć, a nie skopiować.

Ceny i dwie drogi dostępu

Rozliczenie idzie za tokeny wejściowe, a stawka mieści się w środku stawek rynkowych: wyraźnie wyżej niż u najtańszych dostawców tekstowych i poniżej modeli wyspecjalizowanych.

Tryb wsadowy zbija cenę o połowę w zamian za wynik dostarczany z opóźnieniem. Przy jednorazowym zaindeksowaniu całego archiwum to oczywisty wybór, przy indeksowaniu dokumentów na bieżąco zupełnie bezużyteczny.

Wybór między prostszym API a platformą chmurową zależy od tego, czego potrzebujesz wokół samego modelu. Prostsze API daje klucz i wywołanie, co wystarcza do prototypu i do niedużej aplikacji. Platforma dodaje zarządzanie uprawnieniami, rozliczenie w ramach projektu chmurowego, wybór regionu przechowywania danych oraz umowy dotyczące przetwarzania, co przy wdrożeniu firmowym bywa warunkiem wejścia.

Przy szacowaniu budżetu policz osobno indeksowanie i wyszukiwanie. Zaindeksowanie miliona fragmentów po pięćset tokenów to pięćset milionów tokenów, czyli koszt jednorazowy rzędu kilkudziesięciu dolarów. Zapytania kosztują znacznie mniej, bo mają po kilkanaście tokenów, więc to indeksowanie dominuje rachunek, a nie ruch użytkowników.

Z tego wynika wskazówka, którą łatwo przeoczyć: zbuduj pamięć podręczną na wektory od pierwszego dnia. Ten sam fragment przetworzony dwa razy daje ten sam wynik, więc zapisanie skrótu treści razem z wektorem pozwala pominąć wszystko, co się nie zmieniło. Przy archiwum aktualizowanym przyrostowo to zamienia kosztowne przeliczanie całości w tanie uzupełnienie różnicy, a przy pierwszym nieudanym przebiegu indeksowania oszczędza powtórzenia całego rachunku.

Wyszukiwanie po nagraniach w praktyce

Skoro obsługa wideo i dźwięku jest tu głównym wyróżnikiem, warto pokazać, jak wygląda cały przepływ, bo decyzje są inne niż przy tekście.

Pierwsza dotyczy jednostki. Przy tekście fragment odpowiada sekcji albo akapitowi, przy nagraniu trzeba wybrać długość odcinka. Zbyt krótki nie niesie kontekstu, zbyt długi rozmywa znaczenie, bo w pięciu minutach rozmowy mieści się kilka tematów. Odcinki rzędu kilkudziesięciu sekund z niewielkim zachodzeniem na siebie sprawdzają się jako punkt wyjścia.

Druga dotyczy tego, co zachować obok wektora. Znacznik czasu jest tu obowiązkowy, bo bez niego wynik wyszukiwania wskazuje plik, a nie moment. Użytkownik chce przejść do właściwej minuty nagrania, a nie otworzyć godzinny materiał i szukać samodzielnie.

Trzecia dotyczy kosztu. Nagrania są rozliczane inaczej niż tekst i różnica nie jest kosmetyczna: dźwięk nalicza się od sekundy, wideo od klatki, a w przeliczeniu na milion tokenów dźwięk wypada kilkudziesięciokrotnie drożej od tekstu, wideo zaś jeszcze drożej. Godzina dźwięku to rząd kilkudziesięciu centów, więc archiwum liczone w setkach godzin materiału wymaga policzenia budżetu przed rozpoczęciem. Przy nagraniach ze spotkań warto rozważyć wariant mieszany: transkrypcja tekstowa jako podstawa wyszukiwania i osadzenie dźwięku wyłącznie tam, gdzie liczy się ton albo treść niewerbalna.

Czwarta, najczęściej pomijana, dotyczy zgód. Nagranie zawiera głosy konkretnych osób, więc jego przetwarzanie i przechowywanie podlega innym regułom niż dokument tekstowy. Warto rozstrzygnąć to przed zbudowaniem indeksu, a nie po pierwszym pytaniu ze strony działu prawnego.

Wyszukiwanie hybrydowe i granice osadzeń

Osadzenia mają jedną słabość wspólną dla wszystkich dostawców i warto ją znać, zanim zbudujesz na nich całą warstwę wyszukiwania.

Wyszukiwanie po znaczeniu gubi dokładne dopasowania. Zapytanie o numer faktury, kod błędu, nazwę własną albo identyfikator produktu może nie trafić w dokument zawierający dokładnie tę wartość, bo ciąg znaków w rodzaju kodu produktu nie ma dla modelu żadnego znaczenia.

Rozwiązaniem jest połączenie dwóch sposobów wyszukiwania: klasycznego, opartego na dopasowaniu słów, oraz semantycznego. Wyniki obu łączy się w jedną listę, przy czym najprościej robić to po pozycjach, a nie po wartościach, bo skale obu są nieporównywalne.

Druga granica dotyczy tego, co osadzenia w ogóle potrafią. Znajdują dokumenty podobne znaczeniowo do pytania, a nie odpowiadają na pytanie. Jeśli odpowiedź wymaga zestawienia informacji z trzech dokumentów albo policzenia czegoś, żaden model osadzeń tego nie zrobi, bo to zadanie dla warstwy generującej odpowiedź.

Trzecia dotyczy aktualności. Wektory odzwierciedlają stan dokumentu z chwili indeksowania, więc materiał zmieniony albo wycofany musi zostać przetworzony ponownie lub usunięty z indeksu. Bez tego wyszukiwanie zwraca treści, których już nie ma, a to jest błąd trudniejszy do zauważenia niż brak wyników.

Osadzenia Google kontra alternatywy

Rozstrzygnięcie sprowadza się do jednego pytania: co jest w Twoim zbiorze. Przy notatkach, dokumentacji i korespondencji tańsza opcja tekstowa wystarczy i różnicy nie zauważysz. Przy nagraniach, materiałach wideo albo dokumentach, których treść siedzi w układzie graficznym, pierwszy wiersz robi rzeczy, których pozostałe nie robią wcale.

Drugie kryterium to infrastruktura. Zespół pracujący już w chmurze tego dostawcy dostaje rozliczenie w ramach istniejącego projektu, wspólne zarządzanie uprawnieniami i wybór regionu przechowywania danych, co upraszcza sprawy zgodności wyraźnie bardziej, niż sugeruje sama różnica w cenie za tokeny.

Typowe błędy

Pierwszy to pominięcie typu zadania albo użycie tej samej wartości dla dokumentów i zapytań. Wyszukiwanie działa i jest wyraźnie gorsze, więc problem długo pozostaje niezauważony.

Drugi to przechowywanie pełnych wektorów przy dużym zbiorze. Skrócenie do siedmiuset kilkudziesięciu wymiarów daje czterokrotnie mniejszą bazę bez zmiany ceny za tokeny.

Trzeci to kierowanie wszystkich treści do wariantu wielomodalnego. Zwykły tekst nic na tym nie zyskuje, a kosztuje więcej niż osadzenie tekstowe.

Czwarty to osadzanie całych dokumentów, bo model przyjmuje długie wejście. Wektor uśrednia treść, więc dokument o wielu tematach przestaje trafiać w cokolwiek.

Piąty to mieszanie wektorów z różnych modeli albo z różnych ustawień wymiarów w jednym indeksie. Są nieporównywalne, a objawem są gorsze wyniki bez żadnego komunikatu o błędzie.

Szósty to szacowanie kosztu wyłącznie po zapytaniach. Przy typowym wdrożeniu rachunek jest zdominowany przez jednorazowe indeksowanie, a nie przez ruch użytkowników.

Siódmy to brak znacznika czasu przy osadzaniu nagrań. Wynik wyszukiwania wskazuje wtedy plik zamiast momentu, a użytkownik dostaje godzinny materiał i zadanie odszukania właściwej minuty samodzielnie.

FAQ

Jaki typ zadania ustawić?

Dla dokumentów trafiających do indeksu wartość przeznaczoną dla dokumentów, dla zapytań użytkownika wartość przeznaczoną dla zapytań. Osobne wartości istnieją dla klasyfikacji, grupowania i oceny podobieństwa dwóch tekstów. Pomylenie ich wyraźnie pogarsza trafność. W modelu wielomodalnym tego parametru nie ma wcale, a zadanie deklarujesz przedrostkiem wpisanym w treść.

Co daje model wielomodalny?

Osadza tekst, obrazy, wideo, dźwięk i dokumenty w jednej wspólnej przestrzeni, więc jeden indeks obsługuje wszystko, a zapytanie tekstowe porównuje się bezpośrednio z fragmentem nagrania. Przy archiwum wyłącznie tekstowym nie daje nic ponad model tekstowy i kosztuje więcej.

Czy skracanie wymiarów obniża cenę wywołania?

Nie, cena za tokeny jest ta sama niezależnie od liczby wymiarów. Oszczędność dotyczy przechowywania i szybkości wyszukiwania, i przy dużym zbiorze jest znacząca: skrócenie do siedmiuset kilkudziesięciu wymiarów daje czterokrotnie mniejszą bazę.

Prostsze API czy platforma chmurowa?

Prostsze API wystarcza do prototypu i niedużej aplikacji. Platforma dodaje zarządzanie uprawnieniami, wybór regionu przechowywania danych i rozliczenie w ramach projektu chmurowego, co przy wdrożeniu firmowym bywa warunkiem wejścia.

Gdzie trzymać policzone wektory?

W dowolnej bazie wektorowej, na przykład opisanej w tekście o Qdrancie. Dostawca ma też własne rozwiązanie do wyszukiwania wektorowego, wygodne przy pracy w tej samej chmurze i wiążące Cię z nią mocniej niż baza uruchamiana samodzielnie.

Dokumentacja modeli stoi na stronie Google Cloud, a typy zadań opisuje osobna strona dokumentacji.