Google: Gemini Embedding 2

Gemini Embedding 2 er Googles multimodale embeddingmodell for numerisk representasjon av tekst, bilder, video, lyd og PDF. Den plasserer de ulike medietypene i et felles rom slik at en applikasjon kan sammenligne betydning på tvers av dem. Resultatet er en vektor av tall, nyttig til semantisk søk, dokumentgjenfinning, anbefalinger, klassifisering eller klyngedannelse; det er ikke et skriftlig svar eller en generert mediefil. Google dokumenterer semantisk dekning på mer enn 100 språk.

Til en kunnskapsbase opprettes vektorer for kildepassasjene, brukerens forespørsel sammenlignes med dem, og det relevante materialet hentes. En separat tekstmodell kan deretter utforme et svar ved hjelp av disse kildene. Til en mediesamling kan en tekstbeskrivelse søke etter relaterte bilder eller videoer; et bilde kan også være forespørselen. Bevar hver vektors forbindelse til originalinnholdet, inkludert en side- eller klippreferanse, slik at det hentede resultatet kan undersøkes og vises i sin opprinnelige sammenheng.

Den samlede inndatagrensen er 8 192 tokener. Veiledningen for den stabile modellen tillater opptil seks PNG- eller JPEG-bilder, opptil 180 sekunder MP3- eller WAV-lyd og opptil 120 sekunder MP4- eller MOV-video. Dokumenterte videokodeker er H264, H265, AV1 og VP9. Videobehandlingen bruker høyst 32 videobilder: fra klipp på opptil 32 sekunder hentes ett bilde per sekund, mens det fra lengre klipp hentes 32 bilder jevnt fordelt over klippet. Videoens lydspor behandles ikke som en del av dette videoinndataelementet; beregn en separat embedding av lyden når den er relevant for gjenfinningen.

PDF-inndata godtar én fil med høyst seks sider. Google anbefaler én side per PDF for best kvalitet. Del en større kilde i meningsfulle sider eller seksjoner, og bevar forbindelsen til originaldokumentet. Velg et utdrag som representerer det som skal kunne finnes, fremfor å kombinere materiale uten innbyrdes forbindelse bare fordi det passer innenfor grensen. Den felles tokengrensen gjelder også for en forespørsel med blandede medier. Hver PDF-side bruker 258 visuelle tokener i tillegg til tokener fra den uthentede teksten. I Googles dokumenterte arbeidsflyt avkortes innhold som overskrider den felles grensen på 8 192 tokener, uten en feil.

Utdatadimensjonen kan velges fra 128 til 3 072, med 3 072 som standard og 768, 1 536 og 3 072 som anbefalte størrelser. Modellen bruker Matryoshka Representation Learning, slik at innledende deler av vektoren fortsatt er nyttige ved mindre dimensjoner. Veiledningen dokumenterer automatisk normalisering av både standardvektorer og forkortede vektorer. Velg en konsekvent dimensjon for postene og forespørslene som applikasjonen sammenligner; den forespurte størrelsen endrer den numeriske representasjonen, ikke selve kildeinnholdet.

For oppgaver med bare tekst angis formålet i teksten i stedet for i det eldre task_type-feltet. Google skiller asymmetrisk gjenfinning fra symmetrisk sammenligning. En søkeforespørsel bruker “task: search result | query: {content}”, mens et kildedokument bruker “title: {title} | text: {content}”; bruk “title: none” hvis det ikke har noen tittel. Spørsmål–svar-, faktasjekk- og kodegjenfinningsoppgaver har egne forespørselsprefikser. For klassifisering, klyngedannelse eller setningslikhet brukes samme oppgaveformat konsekvent på begge sider. Veiledningen fraråder generelt å legge et oppgaveprefiks til tekstdelen av en kombinert multimodal representasjon.

Inndatastrukturen avgjør om resultatet representerer ett kombinert objekt eller separate elementer. Flere deler levert sammen gir én samlet embedding; separate Content-objekter gir separate embeddingvektorer for hver post. For et innlegg med tekst og bilde kan en kombinert representasjon fange forholdet mellom dem. Poster som skal kunne finnes uavhengig av hverandre, holdes atskilt. Dette valget påvirker hvor finmasket søket er: én vektor for et helt innlegg er forskjellig fra én for hver passasje eller hvert bilde.

Veiledningen sier at vektorer fra Gemini Embedding 001 og Gemini Embedding 2 ligger i inkompatible rom og ikke kan sammenlignes direkte. En samling som migreres fra den eldre modellen, må få beregnet embeddingvektorene på nytt for det nye rommet. Hold modellvalg og dimensjoner konsekvente for vektorene som sammenlignes, og oppbevar originaltekst og medier separat fra den numeriske indeksen. Likhet mellom embeddingvektorer er et gjenfinningssignal, ikke en faktabasert forklaring på hvorfor et dokument besvarer brukerens spørsmål.

Til en praktisk katalog beregnes en embedding av et produktfotografi sammen med den godkjente beskrivelsen når paret skal finnes som ett objekt. Til en dokumentsamling beregnes embeddingvektorer for avgrensede passasjer, som sammenlignes med en forespørsel formatert etter formålet; vis deretter kildepassasjene sammen med søkeresultatet. For lyd eller video velges episoden som beskriver den søkbare hendelsen, og det opprinnelige tidsintervallet bevares. Den nyttige leveransen er en numerisk representasjon knyttet til kildebelegg for applikasjonens neste søke- eller analysetrinn.