Streszczenie AI
Google DeepMind wypuściło otwartoźródłowy, sub‑1B model EmbeddingGemma 2, który wjednocza tekst, kod, grafikę, wideo i dźwięk w jedną 768‑wymiarową przestrzeń i nadaje się do uruchamiania na urządzeniach mobilnych i edge bez przesyłania danych do chmury. Model oparty na modularnej architekturze Gemma 4 pozwala ładować tylko potrzebne enkodery (tekst 270 M, obraz 170 M, audio 300 M), a technika MRL umożliwia redukcję rozmiaru wektorów do 256 / 128 d w celu oszczędności dyskowego z nieznacznym spadkiem jakości. Embeddings można bezpiecznie wykorzystać w systemach AI dzięki wsparciu dla bfloat16/float32, licencjonowaniu Apache 2.0 i integracji z popularnymi frameworkami takimi jak Transformers, Sentence‑Transformers czy llama.cpp.
Spis treści:
Google DeepMind zaprezentowało otwartoźródłowy model EmbeddingGemma 2, który przenosi zadania wektoryzacji tekstu, kodu, grafiki, wideo oraz dźwięku do wspólnej przestrzeni matematycznej. Jest to kompaktowe rozwiązanie klasy sub-1B (łącznie 740 milionów parametrów) udostępnione na liberalnej licencji Apache 2.0. Zostało zaprojektowane z myślą o uruchamianiu lokalnym na urządzeniach mobilnych, laptopach i w środowiskach edge, bez konieczności transferu wrażliwych danych do zewnętrznych chmur obliczeniowych.
Architektura modułowa i optymalizacja pamięciowa
Kluczowym wyróżnikiem architektury bazującej na rodzinie Gemma 4 jest jej modułowość. Zamiast wymuszać ładowanie monolitycznego bloku wag, EmbeddingGemma 2 rozbija poszczególne zmysły na niezależne kodery, które programista może ładować selektywnie w zależności od potrzeb aplikacji. Rdzeniem systemu jest moduł tekstowo-kodowy o wielkości 270M parametrów (130M parametrów sieci bazowej typu Transformer oraz 140M parametrów warstwy embeddera). Gdy zadanie wymaga analizy wizualnej lub dźwiękowej, aplikacja dołącza odpowiednio koder obrazu (170M) bądź koder audio (300M).
W praktyce oznacza to ogromne oszczędności pamięci operacyjnej (RAM/VRAM), co ma krytyczne znaczenie dla stabilności systemów wbudowanych i urządzeń z systemem Android lub iOS. Na urządzeniach klasy Google Pixel 11 Pro skwantyzowany wariant modelu alokuje około 191 MB aktywnej pamięci RAM w trybie przetwarzania samego tekstu oraz około 567 MB przy załadowaniu wszystkich koderów multimodalnych.
Moduł / Konfiguracja | Liczba parametrów | Przybliżony narzut RAM (skwantyzowany) | Obsługiwane typy danych |
|---|---|---|---|
| Tekstowy kręgosłup (Backbone + Embedder) | 270M | ~191 MB | Tekst (100+ języków), kod źródłowy |
| Koder wizyjny (Vision Encoder) | +170M (łącznie 440M) | ~340 MB | Statyczne obrazy, klatki wideo |
| Koder dźwiękowy (Audio Encoder) | +300M (łącznie 570M) | ~420 MB | Mowa (mono, 16 kHz), sygnały audio |
| Pełny system multimodalny | 740M | ~567 MB | Tekst, kod, obrazy, wideo, dźwięk |
Unifikacja reprezentacji i elastyczne wektory MRL
Model mapuje wszystkie typy danych wejściowych do wspólnej 768-wymiarowej przestrzeni wektorowej. Oznacza to, że wektor zapytania tekstowego, transkrypcji audio czy wyciętej klatki wideo znajduje się w tej samej relacji geometrycznej, umożliwiając obliczanie podobieństwa cosinusowego wprost pomiędzy odmiennymi modalnościami bez konieczności stosowania wieloetapowych potoków z modelami OCR, Speech-to-Text czy generowania podpisów.
Do zarządzania rozmiarem indeksów wektorowych zaimplementowano technikę Matryoshka Representation Learning (MRL). Umożliwia ona obcinanie bazowego wektora 768-wymiarowego do rozmiarów 512, 256, a nawet 128 wymiarów. Skrócenie wektora do 256 wymiarów pozwala na niemal trzykrotną redukcję zapotrzebowania na pamięć dyskową i pamięć bazy wektorowej przy pomijalnym spadku jakości wyszukiwania. Wymiar 128d zapewnia aż 6-krotną kompresję, choć Google rekomenduje stosowanie go głównie w scenariuszach czysto tekstowych, gdyż w zadaniach multimodalnych spadek precyzji staje się zauważalny.
Wektor obcięty za pomocą techniki MRL traci swoją jednostkową długość euklidesową. Przed obliczeniem podobieństwa cosinusowego lub indeksowaniem wektor należy obowiązkowo znormalizować (L2 normalization), w przeciwnym razie scoring rankingowy ulegnie degradacji bez zgłaszania błędów przez bibliotekę.
Kolejnym usprawnieniem jest rozszerzenie okna kontekstowego do 8 192 tokenów, czyli czterokrotnie więcej niż w pierwotnym EmbeddingGemma. Budżet ten jest współdzielony przez wszystkie media w ramach jednego wejścia. Pojedynczy token tekstu zajmuje 1 token, domyślna reprezentacja obrazu pobiera 280 tokenów, ramka wideo 140 tokenów, natomiast sekunda nagrania audio mono (16 kHz) pochłania 25 tokenów. Pozwala to na jednoczesne wektoryzowanie dokumentów zawierających przeplatany tekst, wykresy i krótkie pliki audio o długości do 5,5 minuty w ramach jednego wywołania.
Wymagania precyzji numerycznej i sterowanie prefiksami zadań
Podczas wdrożenia modelu w środowiskach produkcyjnych kluczowe jest zachowanie rygoru w zakresie formatów zmiennoprzecinkowych. Z uwagi na szeroki zakres dynamiczny aktywacji, EmbeddingGemma 2 nie może być uruchamiany w formacie float16 – taka konfiguracja prowadzi do pojawiania się wartości NaN lub cichej utraty precyzji wag bez generowania wyjątku runtime. Na sprzęcie wspierającym nowoczesne instrukcje akceleracji należy domyślnie stosować bfloat16, a w przypadku braku wsparcia sprzętowego (np. na starszych procesorach CPU) – pełny format float32.
Wydajność modelu w zadaniach tekstowych opiera się na wstępnym definiowaniu prefiksów instrukcji (task instruction prefixes). Google wytrenowało model w rozróżnianiu zadań asymetrycznych (takich jak klasyczne wyszukiwanie dokumentów, Question Answering czy weryfikacja faktów) oraz symetrycznych (klasyfikacja, grupowanie, analiza podobieństwa zdań). W zadaniach wyszukiwania zapytań tekst używa prefiksu task: search result | query: {treść}, podczas gdy indeksowany dokument przyjmuje strukturę title: {tytuł} | text: {treść}. W przypadku braku tytułu stosowana jest flaga title: none. Dla danych binarnych (audio, wideo, obraz) prefiksów się nie stosuje.
Wyniki w testach porównawczych
Nowa iteracja zanotowała wyraźny skok parametrów jakościowych, w szczególności w domenach technicznych. W wielojęzycznym benchmarku MTEB Text (v2) model osiągnął 61.36 punktu, utrzymując stabilną pozycję swojego poprzednika, natomiast w wyszukiwaniu kodu źródłowego (MTEB Code v1) wynik wzrósł z 68.76 do 78.68 punktu (skok o niemal 10 punktów bazowych).
Modalność | Benchmark referencyjny | Metryka | EmbeddingGemma 2 (768d) | EmbeddingGemma 1 |
|---|---|---|---|---|
| Kod źródłowy | MTEB Code (v1) | NDCG@10 | 78.68 | 68.76 |
| Wielojęzyczny tekst | MTEB Multilingual (v2) | Średnia zadań | 61.36 | 61.15 |
| Obraz statyczny | MIEB Lite | Średnia typów | 64.64 | brak (brak mod.) |
| Dokumenty wizualne | MMEB v2 (VisDoc) | NDCG@5 | 67.84 | brak |
| Wideo | MMEB v2 (Video) | Hit@1 | 50.67 | brak |
| Dźwięk / Audio | MSEB Retrieval | MRR@10 | 69.54 | brak |
Praktyczne zastosowania w architekturze systemów AI
Kompaktowy profil pamięciowy oraz otwarta licencja pozwalają na wykorzystanie EmbeddingGemma 2 w kilku kluczowych wzorcach architektonicznych:
- Prywatne, multimodalne potoki On-Device RAG: Połączenie EmbeddingGemma 2 z lokalnym małym modelem językowym (np. Gemma 4 w wersji skwantyzowanej) pozwala na realizację pełnego potoku Retrieval-Augmented Generation na telefonie lub stacji roboczej. System może przeszukiwać prywatne pliki PDF, zrzuty ekranu, notatki głosowe i kod bez wysyłania jakichkolwiek bajtów do API dostawców zewnętrznych.
- Błyskawiczny routing intencji (Zero-Shot Intent Classification): Zamiast utrzymywać osobny klasyfikator zapytań użytkownika, można dokonać wektoryzacji etykiet systemowych oraz przychodzącego promptu. Dzięki niskim opóźnieniom rzędu milisekund model sprawdza się jako silnik decyzyjny kierujący zapytania do wyspecjalizowanych narzędzi w ramach architektur agentowych.
- Wyszukiwarki multimediów w aplikacjach mobilnych: Aplikacje galerii czy dyktafonów mogą indeksować metadane i sygnały wizualno-dźwiękowe w lokalnej bazie wektorowej (np. z wykorzystaniem biblioteki SQLite-vec, Qdrant Edge lub llama.cpp), dając użytkownikowi możliwość odnalezienia fragmentu wideo na podstawie zapytania głosowego lub opisu tekstowego.
- Optymalizacja kosztów pamięci wektorowej (MRL): W środowiskach o ograniczonej pojemności pamięci RAM korpusy danych mogą być przechowywane w 256 wymiarach, redukując rozmiar indeksów HNSW o ponad 60%, przy jednoczesnym zachowaniu możliwości precyzyjnego rerankingu na pełnych wektorach 768d.
Model jest już w pełni zintegrowany z ekosystemem open source, obejmującym frameworki Transformers, Sentence-Transformers, LiteRT, MediaPipe, llama.cpp, Ollama oraz Unsloth, co pozwala na natychmiastowe testowanie i deployment w docelowych środowiskach runtime.
embeddinggemma-2
Ollama LibraryEmbeddingGemma 2 is a multimodal embedding model from Google built on the Gemma 4 architecture.
ollama run embeddinggemma-2
