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.
", "aboutText": "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.\n\nTil 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.\n\nDen 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.\n\nPDF-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.\n\nUtdatadimensjonen 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.\n\nFor 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.\n\nInndatastrukturen 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.\n\nVeiledningen 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.\n\nTil 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.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "5a5da644c7f8aaf1e7188d765d2a4a2228bf0971f83242a28e5c4d01ee62f8f8", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "nb", "methods": [ { "html": "google/gemini-embedding-2Gemini Embedding 2 plasserer tekst, bilder, lyd, video og PDF i et felles numerisk rom. Vektorene støtter søk på tvers av modaliteter, informasjonsgjenfinning, klassifisering og klyngedannelse, med fleksible dimensjoner og en inndatagrense på 8 192 tokener.
Denne beskrivelsen dekker modellens funksjoner. Tilgjengelige inndata, utdata og alternativer i Ailoot er oppført nedenfor for den valgte metoden.
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.
POST /v1/embeddingstext, token_idsembedding| Felt | Type | Krav | Verdier & grenser | Standard |
|---|---|---|---|---|
Feltmodel | Typestring | KravPåkrevd | Verdier & grenser google/gemini-embedding-2 | Standard— |
Feltinput | Typestring|string[]|integer[]|integer[][] | KravPåkrevd | Verdier & grenser Minste antall elementer: 1 Vilkår: Ikke-tom batch med ensartede elementer. Token-ID-er er ikke-negative heltall. Inndatabudsjett: Maksimum: 8 192 · Tekstenhet: UTF8-byte · Tokenenhet: elementer i token-arrayet | Standard— |
Feltencoding_format | Typestring | KravValgfritt | Verdier & grenser float | Standardfloat |
Feltdimensions | Typeinteger | KravStøttes ikke | Verdier & grenser Minimum: 1 | Standard— |
Feltuser | Typejson_value | KravValgfritt | Verdier & grenser Vilkår: Kilden tillater dette JSON-metadatafeltet; den nøyaktige semantikken hos den underliggende leverandøren er modellavhengig. | Standard— |
Feltsession_id | Typejson_value | KravValgfritt | Verdier & grenser Vilkår: Kilden tillater dette JSON-metadatafeltet; den nøyaktige semantikken hos den underliggende leverandøren er modellavhengig. | Standard— |
Felttrace | Typejson_value | KravValgfritt | Verdier & grenser Vilkår: Kilden tillater dette JSON-metadatafeltet; den nøyaktige semantikken hos den underliggende leverandøren er modellavhengig. | Standard— |
Feltprovider | Typeobject | KravValgfritt | Verdier & grenser Vilkår: provider.options avvises | Standard— |
text_to_embedding
| Parameter | Avtale |
|---|---|
Parametercontent_type | Avtaleapplication/json |
Parameterrequired | Avtalemodel, input |
Parameterinput_shapes | Avtalestring, string[], nonnegative_integer_token_array, nonnegative_integer_token_array[] |
Parameterencoding_format | Avtalefloat |
Parameterdimensions_override | Avtalefalse |
Parametermax_input_budget_units | Avtale8192 |
Parametermultimodal_objects | Avtalefalse |
Parametermaterial_types | Avtaletext, token_ids |
Livssyklus: synchronous_json
Bevar hver vektors indeks og dimensjon.
Et multimodalt modellnavn innebærer ikke at bildeobjekter er tillatt på denne nøyaktige stien.
Tariffopplysninger legger ikke til forespørselsvalg. Støttede parametere står ved den valgte metoden.
| Konfigurasjon | Prisplan | Kostnad |
|---|---|---|
| KonfigurasjonGrunnpriser for tokener | PrisplanGrunnsats | Kostnad Inndata · Inngående tokener $0.0004 / 1K tokener Utdata · Utgående tokener $0 / 1K tokener Inndata · Lesing fra hurtigbuffer — / 1K tokener Inndata · Skriving til hurtigbuffer — / 1K tokener Inndata · Skriving til hurtigbuffer, 1 time — / 1K tokener |
Ailoot reserverer et estimert beløp før en forespørsel. Etter resultatet gjøres det endelige beløpet opp basert på målt forbruk. Oppgjør for strømming bruker den endelige forbruksposten. Slik fungerer reservasjon og oppgjør →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "google/gemini-embedding-2", "input": ["First document", "Second document"]}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/embeddings \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("data",[]): print(json.dumps({"index":x.get("index"),"embedding":x.get("embedding")}))\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.embeddings.create(model='google/gemini-embedding-2',input=["First document","Second document"])\nprint(result)\nfor item in result.data:print(item.index,item.embedding)\njson
Behold alle fullstendige returnerte svar, filer og innholdsdeler.
Bevar hver vektor sammen med indeksen. Antall vektorer må være lik antall inndata; dimensjonene må være konsistente.
Det innføres ikke noe endepunkt for embedding-jobber.
| Felt | Type |
|---|---|
Feltobject | Typestring |
Feltmodel | Typestring |
Feltdata[].index | Typeinteger |
Feltdata[].embedding | Typefinite float[] |
Feltusage | Typeobject |
| Svar | Vilkår | Neste trinn |
|---|---|---|
Svar400 · invalid_request_error | VilkårUgyldige påkrevde felter, materialrepresentasjon eller parameterverdi | Neste trinnKorriger de angitte feltene før en ny opprettelsesforespørsel. |
Ailoot Ultra google/gemini-embedding-2
Bruk metodestiene som vises ovenfor.