Gemini Embedding 2 er Googles multimodale embeddingmodel til numerisk repræsentation af tekst, billeder, video, lyd og PDF. Den afbilder de forskellige medietyper i et fælles rum, så en applikation kan sammenligne betydning på tværs af dem. Resultatet er en vektor af tal, der er nyttig til semantisk søgning, dokumenthentning, anbefalinger, klassifikation eller klyngedannelse; det er hverken et skriftligt svar eller en genereret mediefil. Google dokumenterer semantisk dækning på mere end 100 sprog.
Til en vidensbase oprettes vektorer for kildepassagerne, brugerens forespørgsel sammenlignes med dem, og det relevante materiale hentes. En separat tekstmodel kan derefter sammensætte et svar ud fra disse kilder. Til en mediesamling kan en tekstbeskrivelse søge efter relevante billeder eller videoer; et billede kan også bruges som forespørgsel. Bevar hver vektors forbindelse til originalindholdet, herunder en side- eller klipreference, så det fundne resultat kan undersøges og vises i sin oprindelige sammenhæng.
Den samlede inputgrænse er 8.192 tokens. Den stabile models vejledning tillader op til seks PNG- eller JPEG-billeder, op til 180 sekunders MP3- eller WAV-lyd og op til 120 sekunders MP4- eller MOV-video. De dokumenterede videocodecs er H264, H265, AV1 og VP9. Videobehandlingen bruger højst 32 frames: klip på op til 32 sekunder udtages med én frame pr. sekund, mens der fra længere klip udtages 32 frames jævnt fordelt over klippet. En videos lydspor behandles ikke som en del af dette videoinput; opret en separat embedding af lyden, når den er relevant for søgningen.
PDF-input accepterer én fil på højst seks sider. Google anbefaler én side pr. PDF for den bedste kvalitet. Opdel en større kilde i meningsfulde sider eller afsnit, og bevar deres forbindelse til originaldokumentet. Vælg et udsnit, der repræsenterer det, som skal kunne findes, frem for at kombinere uvedkommende materialer, blot fordi de kan være inden for grænsen. Den fælles tokengrænse gælder stadig for en forespørgsel med blandede medier. Hver PDF-side bruger 258 visuelle tokens ud over tokens fra den udtrukne tekst. I Googles dokumenterede arbejdsforløb afkortes indhold, der overskrider den fælles grænse på 8.192 tokens, uden en fejl.
Outputdimensionen kan vælges fra 128 til 3.072, med 3.072 som standard og 768, 1.536 og 3.072 som anbefalede størrelser. Modellen bruger Matryoshka Representation Learning, så vektorens præfikser fortsat er nyttige ved mindre dimensioner. Vejledningen dokumenterer automatisk normalisering af både standardvektorer og forkortede vektorer. Vælg en ensartet dimension til de poster og forespørgsler, som applikationen sammenligner; den ønskede størrelse ændrer den numeriske repræsentation, ikke selve kildeindholdet.
Til opgaver udelukkende med tekst angives formålet i teksten frem for i det ældre task_type-felt. Google skelner mellem asymmetrisk søgning og symmetrisk sammenligning. En søgeforespørgsel bruger “task: search result | query: {content}”, mens et kildedokument bruger “title: {title} | text: {content}”; brug “title: none”, hvis det ikke har en titel. Spørgsmål og svar, faktatjek og kodesøgning har deres egne forespørgselspræfikser. Til klassifikation, klyngedannelse eller sætningslighed bruges det samme opgaveformat konsekvent på begge sider. Vejledningen fraråder generelt at tilføje et opgavepræfiks til tekstdelen af en kombineret multimodal repræsentation.
Inputstrukturen afgør, om resultatet repræsenterer ét samlet objekt eller separate elementer. Flere dele, der leveres sammen, skaber en samlet embedding; separate Content-objekter skaber separate embeddings for hver post. Til et opslag med tekst og billede kan en kombineret repræsentation indfange deres sammenhæng. Poster, der skal kunne findes hver for sig, holdes adskilt. Dette valg påvirker søgningens detaljeringsgrad: én vektor for et helt opslag er forskellig fra én for hver passage eller hvert billede.
Vejledningen angiver, at vektorer fra Gemini Embedding 001 og Gemini Embedding 2 ligger i inkompatible rum og ikke kan sammenlignes direkte. En samling, der migreres fra den ældre model, skal have oprettet embeddings på ny til det nye rum. Hold modelvalg og dimensioner ensartede for de vektorer, der sammenlignes, og opbevar originaltekst og medier adskilt fra det numeriske indeks. Lighed mellem embeddings er et søgesignal frem for en faktuel forklaring på, hvorfor et dokument besvarer brugerens spørgsmål.
Til et praktisk katalog oprettes en embedding af et produktfotografi sammen med dets godkendte beskrivelse, når parret skal kunne findes som ét objekt. Til en dokumentsamling oprettes embeddings af afgrænsede passager, som sammenlignes med en forespørgsel formateret efter formålet; vis derefter kildepassagerne sammen med søgeresultatet. Til lyd eller video vælges den episode, der beskriver den hændelse, som skal kunne findes, og dens oprindelige tidsinterval bevares. Det nyttige resultat er en numerisk repræsentation knyttet til kildebelæg for applikationens næste søge- eller analysetrin.
", "aboutText": "Gemini Embedding 2 er Googles multimodale embeddingmodel til numerisk repræsentation af tekst, billeder, video, lyd og PDF. Den afbilder de forskellige medietyper i et fælles rum, så en applikation kan sammenligne betydning på tværs af dem. Resultatet er en vektor af tal, der er nyttig til semantisk søgning, dokumenthentning, anbefalinger, klassifikation eller klyngedannelse; det er hverken et skriftligt svar eller en genereret mediefil. Google dokumenterer semantisk dækning på mere end 100 sprog.\n\nTil en vidensbase oprettes vektorer for kildepassagerne, brugerens forespørgsel sammenlignes med dem, og det relevante materiale hentes. En separat tekstmodel kan derefter sammensætte et svar ud fra disse kilder. Til en mediesamling kan en tekstbeskrivelse søge efter relevante billeder eller videoer; et billede kan også bruges som forespørgsel. Bevar hver vektors forbindelse til originalindholdet, herunder en side- eller klipreference, så det fundne resultat kan undersøges og vises i sin oprindelige sammenhæng.\n\nDen samlede inputgrænse er 8.192 tokens. Den stabile models vejledning tillader op til seks PNG- eller JPEG-billeder, op til 180 sekunders MP3- eller WAV-lyd og op til 120 sekunders MP4- eller MOV-video. De dokumenterede videocodecs er H264, H265, AV1 og VP9. Videobehandlingen bruger højst 32 frames: klip på op til 32 sekunder udtages med én frame pr. sekund, mens der fra længere klip udtages 32 frames jævnt fordelt over klippet. En videos lydspor behandles ikke som en del af dette videoinput; opret en separat embedding af lyden, når den er relevant for søgningen.\n\nPDF-input accepterer én fil på højst seks sider. Google anbefaler én side pr. PDF for den bedste kvalitet. Opdel en større kilde i meningsfulde sider eller afsnit, og bevar deres forbindelse til originaldokumentet. Vælg et udsnit, der repræsenterer det, som skal kunne findes, frem for at kombinere uvedkommende materialer, blot fordi de kan være inden for grænsen. Den fælles tokengrænse gælder stadig for en forespørgsel med blandede medier. Hver PDF-side bruger 258 visuelle tokens ud over tokens fra den udtrukne tekst. I Googles dokumenterede arbejdsforløb afkortes indhold, der overskrider den fælles grænse på 8.192 tokens, uden en fejl.\n\nOutputdimensionen kan vælges fra 128 til 3.072, med 3.072 som standard og 768, 1.536 og 3.072 som anbefalede størrelser. Modellen bruger Matryoshka Representation Learning, så vektorens præfikser fortsat er nyttige ved mindre dimensioner. Vejledningen dokumenterer automatisk normalisering af både standardvektorer og forkortede vektorer. Vælg en ensartet dimension til de poster og forespørgsler, som applikationen sammenligner; den ønskede størrelse ændrer den numeriske repræsentation, ikke selve kildeindholdet.\n\nTil opgaver udelukkende med tekst angives formålet i teksten frem for i det ældre task_type-felt. Google skelner mellem asymmetrisk søgning og symmetrisk sammenligning. En søgeforespørgsel bruger “task: search result | query: {content}”, mens et kildedokument bruger “title: {title} | text: {content}”; brug “title: none”, hvis det ikke har en titel. Spørgsmål og svar, faktatjek og kodesøgning har deres egne forespørgselspræfikser. Til klassifikation, klyngedannelse eller sætningslighed bruges det samme opgaveformat konsekvent på begge sider. Vejledningen fraråder generelt at tilføje et opgavepræfiks til tekstdelen af en kombineret multimodal repræsentation.\n\nInputstrukturen afgør, om resultatet repræsenterer ét samlet objekt eller separate elementer. Flere dele, der leveres sammen, skaber en samlet embedding; separate Content-objekter skaber separate embeddings for hver post. Til et opslag med tekst og billede kan en kombineret repræsentation indfange deres sammenhæng. Poster, der skal kunne findes hver for sig, holdes adskilt. Dette valg påvirker søgningens detaljeringsgrad: én vektor for et helt opslag er forskellig fra én for hver passage eller hvert billede.\n\nVejledningen angiver, at vektorer fra Gemini Embedding 001 og Gemini Embedding 2 ligger i inkompatible rum og ikke kan sammenlignes direkte. En samling, der migreres fra den ældre model, skal have oprettet embeddings på ny til det nye rum. Hold modelvalg og dimensioner ensartede for de vektorer, der sammenlignes, og opbevar originaltekst og medier adskilt fra det numeriske indeks. Lighed mellem embeddings er et søgesignal frem for en faktuel forklaring på, hvorfor et dokument besvarer brugerens spørgsmål.\n\nTil et praktisk katalog oprettes en embedding af et produktfotografi sammen med dets godkendte beskrivelse, når parret skal kunne findes som ét objekt. Til en dokumentsamling oprettes embeddings af afgrænsede passager, som sammenlignes med en forespørgsel formateret efter formålet; vis derefter kildepassagerne sammen med søgeresultatet. Til lyd eller video vælges den episode, der beskriver den hændelse, som skal kunne findes, og dens oprindelige tidsinterval bevares. Det nyttige resultat er en numerisk repræsentation knyttet til kildebelæg for applikationens næste søge- eller analysetrin.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "2ca51a1fbf9216e6e4b5d1e650cd2704c5422f1f0a810421d155ddbb320038f4", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "da", "methods": [ { "html": "google/gemini-embedding-2Gemini Embedding 2 afbilder tekst, billeder, lyd, video og PDF i et fælles numerisk rum. Vektorerne understøtter søgning på tværs af modaliteter, informationssøgning, klassifikation og klyngedannelse med fleksible dimensioner og en inputgrænse på 8.192 tokens.
Denne beskrivelse dækker modellens funktioner. Tilgængelige input, output og indstillinger i Ailoot står nedenfor for den valgte metode.
Gemini Embedding 2 er Googles multimodale embeddingmodel til numerisk repræsentation af tekst, billeder, video, lyd og PDF. Den afbilder de forskellige medietyper i et fælles rum, så en applikation kan sammenligne betydning på tværs af dem. Resultatet er en vektor af tal, der er nyttig til semantisk søgning, dokumenthentning, anbefalinger, klassifikation eller klyngedannelse; det er hverken et skriftligt svar eller en genereret mediefil. Google dokumenterer semantisk dækning på mere end 100 sprog.
Til en vidensbase oprettes vektorer for kildepassagerne, brugerens forespørgsel sammenlignes med dem, og det relevante materiale hentes. En separat tekstmodel kan derefter sammensætte et svar ud fra disse kilder. Til en mediesamling kan en tekstbeskrivelse søge efter relevante billeder eller videoer; et billede kan også bruges som forespørgsel. Bevar hver vektors forbindelse til originalindholdet, herunder en side- eller klipreference, så det fundne resultat kan undersøges og vises i sin oprindelige sammenhæng.
Den samlede inputgrænse er 8.192 tokens. Den stabile models vejledning tillader op til seks PNG- eller JPEG-billeder, op til 180 sekunders MP3- eller WAV-lyd og op til 120 sekunders MP4- eller MOV-video. De dokumenterede videocodecs er H264, H265, AV1 og VP9. Videobehandlingen bruger højst 32 frames: klip på op til 32 sekunder udtages med én frame pr. sekund, mens der fra længere klip udtages 32 frames jævnt fordelt over klippet. En videos lydspor behandles ikke som en del af dette videoinput; opret en separat embedding af lyden, når den er relevant for søgningen.
PDF-input accepterer én fil på højst seks sider. Google anbefaler én side pr. PDF for den bedste kvalitet. Opdel en større kilde i meningsfulde sider eller afsnit, og bevar deres forbindelse til originaldokumentet. Vælg et udsnit, der repræsenterer det, som skal kunne findes, frem for at kombinere uvedkommende materialer, blot fordi de kan være inden for grænsen. Den fælles tokengrænse gælder stadig for en forespørgsel med blandede medier. Hver PDF-side bruger 258 visuelle tokens ud over tokens fra den udtrukne tekst. I Googles dokumenterede arbejdsforløb afkortes indhold, der overskrider den fælles grænse på 8.192 tokens, uden en fejl.
Outputdimensionen kan vælges fra 128 til 3.072, med 3.072 som standard og 768, 1.536 og 3.072 som anbefalede størrelser. Modellen bruger Matryoshka Representation Learning, så vektorens præfikser fortsat er nyttige ved mindre dimensioner. Vejledningen dokumenterer automatisk normalisering af både standardvektorer og forkortede vektorer. Vælg en ensartet dimension til de poster og forespørgsler, som applikationen sammenligner; den ønskede størrelse ændrer den numeriske repræsentation, ikke selve kildeindholdet.
Til opgaver udelukkende med tekst angives formålet i teksten frem for i det ældre task_type-felt. Google skelner mellem asymmetrisk søgning og symmetrisk sammenligning. En søgeforespørgsel bruger “task: search result | query: {content}”, mens et kildedokument bruger “title: {title} | text: {content}”; brug “title: none”, hvis det ikke har en titel. Spørgsmål og svar, faktatjek og kodesøgning har deres egne forespørgselspræfikser. Til klassifikation, klyngedannelse eller sætningslighed bruges det samme opgaveformat konsekvent på begge sider. Vejledningen fraråder generelt at tilføje et opgavepræfiks til tekstdelen af en kombineret multimodal repræsentation.
Inputstrukturen afgør, om resultatet repræsenterer ét samlet objekt eller separate elementer. Flere dele, der leveres sammen, skaber en samlet embedding; separate Content-objekter skaber separate embeddings for hver post. Til et opslag med tekst og billede kan en kombineret repræsentation indfange deres sammenhæng. Poster, der skal kunne findes hver for sig, holdes adskilt. Dette valg påvirker søgningens detaljeringsgrad: én vektor for et helt opslag er forskellig fra én for hver passage eller hvert billede.
Vejledningen angiver, at vektorer fra Gemini Embedding 001 og Gemini Embedding 2 ligger i inkompatible rum og ikke kan sammenlignes direkte. En samling, der migreres fra den ældre model, skal have oprettet embeddings på ny til det nye rum. Hold modelvalg og dimensioner ensartede for de vektorer, der sammenlignes, og opbevar originaltekst og medier adskilt fra det numeriske indeks. Lighed mellem embeddings er et søgesignal frem for en faktuel forklaring på, hvorfor et dokument besvarer brugerens spørgsmål.
Til et praktisk katalog oprettes en embedding af et produktfotografi sammen med dets godkendte beskrivelse, når parret skal kunne findes som ét objekt. Til en dokumentsamling oprettes embeddings af afgrænsede passager, som sammenlignes med en forespørgsel formateret efter formålet; vis derefter kildepassagerne sammen med søgeresultatet. Til lyd eller video vælges den episode, der beskriver den hændelse, som skal kunne findes, og dens oprindelige tidsinterval bevares. Det nyttige resultat er en numerisk repræsentation knyttet til kildebelæg for applikationens næste søge- eller analysetrin.
POST /v1/embeddingstext, token_idsembedding| Felt | Type | Krav | Værdier og grænser | Standard |
|---|---|---|---|---|
Feltmodel | Typestring | KravPåkrævet | Værdier og grænser google/gemini-embedding-2 | Standard— |
Feltinput | Typestring|string[]|integer[]|integer[][] | KravPåkrævet | Værdier og grænser Minimumsantal elementer: 1 Betingelser: Ikke-tom batch med ensartede elementer. Token-ID’er er ikke-negative heltal. Inputbudget: Maksimum: 8.192 · Tekstenhed: UTF8-bytes · Tokenenhed: elementer i et tokenarray | Standard— |
Feltencoding_format | Typestring | KravValgfrit | Værdier og grænser float | Standardfloat |
Feltdimensions | Typeinteger | KravIkke understøttet | Værdier og grænser Minimum: 1 | Standard— |
Feltuser | Typejson_value | KravValgfrit | Værdier og grænser Betingelser: Kilden tillader dette JSON-metadatafelt; den præcise betydning hos den bagvedliggende udbyder afhænger af modellen. | Standard— |
Feltsession_id | Typejson_value | KravValgfrit | Værdier og grænser Betingelser: Kilden tillader dette JSON-metadatafelt; den præcise betydning hos den bagvedliggende udbyder afhænger af modellen. | Standard— |
Felttrace | Typejson_value | KravValgfrit | Værdier og grænser Betingelser: Kilden tillader dette JSON-metadatafelt; den præcise betydning hos den bagvedliggende udbyder afhænger af modellen. | Standard— |
Feltprovider | Typeobject | KravValgfrit | Værdier og grænser Betingelser: provider.options afvist | Standard— |
text_to_embedding
| Parameter | Kontrakt |
|---|---|
Parametercontent_type | Kontraktapplication/json |
Parameterrequired | Kontraktmodel, input |
Parameterinput_shapes | Kontraktstring, string[], nonnegative_integer_token_array, nonnegative_integer_token_array[] |
Parameterencoding_format | Kontraktfloat |
Parameterdimensions_override | Kontraktfalse |
Parametermax_input_budget_units | Kontrakt8192 |
Parametermultimodal_objects | Kontraktfalse |
Parametermaterial_types | Kontrakttext, token_ids |
Livscyklus: synchronous_json
Gem hver vektors indeks og dimension.
Et multimodalt modelnavn giver ikke adgang til at bruge billedobjekter på denne præcise sti.
Tarifoplysninger tilføjer ikke anmodningsmuligheder. Understøttede parametre står ved den valgte metode.
| Konfiguration | Takstplan | Beløb |
|---|---|---|
| KonfigurationGrundtakster for tokens | TakstplanGrundtakst | Beløb Input · Inputtokens $0.0004 / 1K tokens Output · Outputtokens $0 / 1K tokens Input · Cachelæsning — / 1K tokens Input · Cacheskrivning — / 1K tokens Input · Cacheskrivning, 1 time — / 1K tokens |
Ailoot reserverer et estimeret beløb før en anmodning. Efter resultatet afregnes det endelige beløb ud fra det målte forbrug. Ved streaming bruges den endelige forbrugsregistrering til afregningen. Sådan fungerer reservation og afregning →
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
Gem hvert fuldstændigt returneret svar, hver fil og hver indholdsdel.
Gem hver vektor med dens indeks. Antallet af vektorer skal svare til antallet af input; dimensionerne skal være ensartede.
Der indføres intet endpoint til embedding-job.
| Felt | Type |
|---|---|
Feltobject | Typestring |
Feltmodel | Typestring |
Feltdata[].index | Typeinteger |
Feltdata[].embedding | Typefinite float[] |
Feltusage | Typeobject |
| Svar | Betingelse | Næste trin |
|---|---|---|
Svar400 · invalid_request_error | BetingelseUgyldige obligatoriske felter, materialerepræsentation eller parameterværdi | Næste trinRet de angivne felter før en ny oprettelsesanmodning. |
Ailoot Ultra google/gemini-embedding-2
Brug metodestierne vist ovenfor.