Hopp til hovedinnhold

Onsdag 7. oktober

 Tilbake Google 3 min 04.12

EmbeddingGemma 2 legger tekst, kode, bilder og lyd i ett vektorrom med 740 millioner parametere

onsdag 7. oktober · KI-generert · Kilde: Google Blog

Innholdet er KI-generert og kan inneholde feil. Sjekk originalkilden.

Prøv EmbeddingGemma 2 hvis du vil ha lokalt søk på tvers av tekst, kode, bilder og lyd, men ikke regn med bedre rent tekstsøk enn forgjengeren gir.

Google lanserte 6. oktober EmbeddingGemma 2, en åpen embedding-modell bygget på Gemma 4-arkitekturen og lisensiert under Apache 2.0. Modellen har 740 millioner parametere og legger tekst, kode, bilder, video og lyd i ett felles vektorrom på 768 dimensjoner. Forgjengeren, som bare håndterte tekst, har passert 20 millioner nedlastinger, ifølge Google.

Det nye er at modellen er modulær. Tekstdelen er på 270M parametere (en transformer på 130M pluss en embedder på 140M), mens bildekoderen (170M) og lydkoderen (300M) bare lastes hvis du trenger dem, står det i modellkortet på Hugging Face. Kontekstvinduet er 8 192 tokens, fire ganger større enn i forrige versjon, og budsjettet deles mellom modalitetene: et bilde koster 280 tokens, en videoramme 140 og ett sekund lyd 25. Det gir plass til rundt 29 bilder, 58 videorammer eller 327 sekunder lyd per input.

«Den kan hjelpe deg å finne et bestemt videoklipp ut fra et talenotat, eller søke gjennom timevis med lydopptak ut fra en tekstforespørsel, alt behandlet av én enkelt, nativt multimodal modell.» — Google, i lanseringsbloggen

Gevinsten er ujevnt fordelt. På MTEB Code går modellen fra 68,76 til 78,68, mens flerspråklig MTEB nesten står stille på 61,36 mot 61,15. Bruker du dagens EmbeddingGemma til ren tekst-RAG, er det lite å hente. Bygger du kodesøk for en agent, eller vil ha bilder og lydopptak i samme indeks som dokumentene, er det her oppgraderingen ligger.

Modellkortet har tre fallgruver som er lette å gå i. Modellen tåler ikke float16: aktiveringene sprenger formatets rekkevidde, og du får NaN eller stille forringede vektorer uten feilmelding. Kutter du vektorene med Matryoshka-støtten (768 ned til 512, 256 eller 128 dimensjoner, opptil seks ganger mindre lagring), må du normalisere dem på nytt. Og tekst skal ha korte oppgaveprefikser, for eksempel task: search result | query: for søk og title: ... | text: for dokumenter. Kvaliteten holder seg nesten intakt ned til 256 dimensjoner, men ved 128 faller multimodal MMEB fra 59,01 til 45,65.

«For embedding-modeller spesielt mener jeg ikke det gir mening å bruke en lukket, proprietær modell som bare finnes som hostet tjeneste. … Hvis modellen din er proprietær, kommer leverandøren sannsynligvis en dag til å slutte å tilby den.» — Simon Willison, på Hacker News

Samme tråd gir et første ytelsesinntrykk. HN-brukeren minimaxir målte på en M3 Pro 78 embeddinger i sekundet for korte tekster, 4 for bilder og 6 for lydbiter på 30 sekunder.

Nøkkeltall
378 MB
embeddinggemma-2:270m i Ollama, bare tekst
714 MB
440m, tekst og bilde
990 MB
570m, tekst og lyd
1,3 GB
740m, alle modalitetene

Hva bør du gjøre?

  1. Kjør ollama pull embeddinggemma-2:270m hvis du bare trenger tekst og kode, og ta full modell (embeddinggemma-2) først når du skal indeksere bilder eller lyd.
  2. Sett torch_dtype til bfloat16 eller float32 i sentence-transformers, og bruk prompt_name (SearchQuery, Document, CodeRetrieval) så prefiksene blir riktige.
  3. Bruk truncate_dim=256 sammen med normalize_embeddings=True hvis lagring er flaskehalsen, og test på egne data før du går ned til 128 dimensjoner.

Pulsen · norske KI-nyheter for deg som bygger. Sakene er KI-generert fra originalkilden, som alltid lenkes.