Gemini Embedding 2 é o modelo de embeddings multimodais da Google para representação numérica de texto, imagens, vídeo, áudio e PDF. Converte os diferentes tipos de conteúdos multimédia num espaço partilhado, para que uma aplicação possa comparar o significado entre eles. O resultado é um vetor de números, útil para pesquisa semântica, recuperação documental, recomendação, classificação ou agrupamento; não é uma resposta escrita nem um ficheiro multimédia gerado. A Google documenta cobertura semântica em mais de 100 línguas.
Numa base de conhecimento, crie vetores para as passagens de origem, compare uma consulta do utilizador com eles e recupere o material relevante. Um modelo textual separado pode depois compor uma resposta utilizando essas fontes. Numa coleção multimédia, uma descrição textual pode pesquisar imagens ou vídeos relacionados; uma imagem também pode fornecer a consulta. Preserve a ligação de cada vetor ao conteúdo original, incluindo uma referência de página ou excerto, para que o resultado recuperado possa ser examinado e mostrado no seu contexto original.
O limite global de entrada é de 8192 tokens. O guia do modelo estável permite até seis imagens PNG ou JPEG, até 180 segundos de áudio MP3 ou WAV e até 120 segundos de vídeo MP4 ou MOV. Os codecs de vídeo documentados são H264, H265, AV1 e VP9. O processamento de vídeo utiliza no máximo 32 fotogramas: excertos de até 32 segundos são amostrados a um fotograma por segundo, enquanto excertos mais longos são amostrados uniformemente até 32 fotogramas. A faixa de áudio de um vídeo não é processada nessa entrada de vídeo; gere o embedding do som separadamente quando importar para a recuperação.
A entrada PDF aceita um ficheiro com no máximo seis páginas. A Google recomenda uma página por PDF para obter a melhor qualidade. Divida uma fonte maior em páginas ou secções significativas e conserve a sua relação com o documento original. Escolha um excerto que represente o que deve ser recuperável, em vez de combinar materiais sem relação apenas porque cabem no limite. O limite partilhado de tokens continua a aplicar-se a um pedido com conteúdos multimédia mistos. Cada página PDF consome 258 tokens visuais, além dos tokens do seu texto extraído. No fluxo documentado da Google, o conteúdo que excede o limite partilhado de 8192 tokens é truncado sem erro.
A dimensionalidade de saída é flexível de 128 a 3072, com 3072 como predefinição e 768, 1536 e 3072 como tamanhos recomendados. O modelo utiliza Matryoshka Representation Learning, pelo que os prefixos do vetor continuam úteis em dimensões menores. O seu guia documenta normalização automática tanto para os vetores predefinidos como para os encurtados. Escolha uma dimensão consistente para os registos e consultas que a sua aplicação compara; o tamanho pedido altera a representação numérica, não o próprio conteúdo de origem.
Para tarefas apenas textuais, inclua o propósito no texto em vez de utilizar o campo mais antigo task_type. A Google distingue recuperação assimétrica de comparação simétrica. Uma consulta de pesquisa utiliza «task: search result | query: {content}», enquanto um documento de origem utiliza «title: {title} | text: {content}»; utilize «title: none» se não tiver título. As tarefas de pergunta-resposta, verificação de factos e recuperação de código têm os seus próprios prefixos de consulta. Para classificação, agrupamento ou similaridade entre frases, utilize o mesmo formato de tarefa de forma consistente nos dois lados. O guia geralmente desaconselha acrescentar um prefixo de tarefa à parte textual de uma representação multimodal combinada.
A estrutura da entrada determina se o resultado representa um objeto combinado ou elementos separados. Várias partes fornecidas em conjunto criam um embedding agregado; objetos Content separados criam embeddings separados para cada entrada. Numa publicação com texto e imagem, uma representação combinada pode captar a sua relação. Para registos pesquisáveis de forma independente, mantenha-os separados. Esta escolha afeta a granularidade de recuperação: um vetor para uma publicação inteira é diferente de um para cada passagem ou imagem.
O guia indica que os vetores de Gemini Embedding 001 e Gemini Embedding 2 ocupam espaços incompatíveis e não podem ser comparados diretamente. Uma coleção migrada do modelo anterior precisa de novos embeddings para o novo espaço. Mantenha a escolha de modelo e as dimensões consistentes com os vetores comparados e conserve o texto e os conteúdos multimédia originais separadamente do índice numérico. A similaridade de um embedding é um sinal de recuperação, em vez de uma explicação factual de por que razão um documento responde à pergunta do utilizador.
Num catálogo prático, gere um embedding combinado da fotografia de um produto e da sua descrição aprovada quando o par deve ser recuperado como um objeto. Numa coleção documental, gere embeddings de passagens focadas e compare-os com uma consulta formatada segundo o propósito; depois apresente as passagens de origem juntamente com o resultado de pesquisa. Para áudio ou vídeo, escolha o episódio que descreve o evento pesquisável e conserve o seu intervalo temporal original. O entregável útil é uma representação numérica ligada a evidência de origem para a próxima etapa de pesquisa ou análise da aplicação.
", "aboutText": "Gemini Embedding 2 é o modelo de embeddings multimodais da Google para representação numérica de texto, imagens, vídeo, áudio e PDF. Converte os diferentes tipos de conteúdos multimédia num espaço partilhado, para que uma aplicação possa comparar o significado entre eles. O resultado é um vetor de números, útil para pesquisa semântica, recuperação documental, recomendação, classificação ou agrupamento; não é uma resposta escrita nem um ficheiro multimédia gerado. A Google documenta cobertura semântica em mais de 100 línguas.\n\nNuma base de conhecimento, crie vetores para as passagens de origem, compare uma consulta do utilizador com eles e recupere o material relevante. Um modelo textual separado pode depois compor uma resposta utilizando essas fontes. Numa coleção multimédia, uma descrição textual pode pesquisar imagens ou vídeos relacionados; uma imagem também pode fornecer a consulta. Preserve a ligação de cada vetor ao conteúdo original, incluindo uma referência de página ou excerto, para que o resultado recuperado possa ser examinado e mostrado no seu contexto original.\n\nO limite global de entrada é de 8192 tokens. O guia do modelo estável permite até seis imagens PNG ou JPEG, até 180 segundos de áudio MP3 ou WAV e até 120 segundos de vídeo MP4 ou MOV. Os codecs de vídeo documentados são H264, H265, AV1 e VP9. O processamento de vídeo utiliza no máximo 32 fotogramas: excertos de até 32 segundos são amostrados a um fotograma por segundo, enquanto excertos mais longos são amostrados uniformemente até 32 fotogramas. A faixa de áudio de um vídeo não é processada nessa entrada de vídeo; gere o embedding do som separadamente quando importar para a recuperação.\n\nA entrada PDF aceita um ficheiro com no máximo seis páginas. A Google recomenda uma página por PDF para obter a melhor qualidade. Divida uma fonte maior em páginas ou secções significativas e conserve a sua relação com o documento original. Escolha um excerto que represente o que deve ser recuperável, em vez de combinar materiais sem relação apenas porque cabem no limite. O limite partilhado de tokens continua a aplicar-se a um pedido com conteúdos multimédia mistos. Cada página PDF consome 258 tokens visuais, além dos tokens do seu texto extraído. No fluxo documentado da Google, o conteúdo que excede o limite partilhado de 8192 tokens é truncado sem erro.\n\nA dimensionalidade de saída é flexível de 128 a 3072, com 3072 como predefinição e 768, 1536 e 3072 como tamanhos recomendados. O modelo utiliza Matryoshka Representation Learning, pelo que os prefixos do vetor continuam úteis em dimensões menores. O seu guia documenta normalização automática tanto para os vetores predefinidos como para os encurtados. Escolha uma dimensão consistente para os registos e consultas que a sua aplicação compara; o tamanho pedido altera a representação numérica, não o próprio conteúdo de origem.\n\nPara tarefas apenas textuais, inclua o propósito no texto em vez de utilizar o campo mais antigo task_type. A Google distingue recuperação assimétrica de comparação simétrica. Uma consulta de pesquisa utiliza «task: search result | query: {content}», enquanto um documento de origem utiliza «title: {title} | text: {content}»; utilize «title: none» se não tiver título. As tarefas de pergunta-resposta, verificação de factos e recuperação de código têm os seus próprios prefixos de consulta. Para classificação, agrupamento ou similaridade entre frases, utilize o mesmo formato de tarefa de forma consistente nos dois lados. O guia geralmente desaconselha acrescentar um prefixo de tarefa à parte textual de uma representação multimodal combinada.\n\nA estrutura da entrada determina se o resultado representa um objeto combinado ou elementos separados. Várias partes fornecidas em conjunto criam um embedding agregado; objetos Content separados criam embeddings separados para cada entrada. Numa publicação com texto e imagem, uma representação combinada pode captar a sua relação. Para registos pesquisáveis de forma independente, mantenha-os separados. Esta escolha afeta a granularidade de recuperação: um vetor para uma publicação inteira é diferente de um para cada passagem ou imagem.\n\nO guia indica que os vetores de Gemini Embedding 001 e Gemini Embedding 2 ocupam espaços incompatíveis e não podem ser comparados diretamente. Uma coleção migrada do modelo anterior precisa de novos embeddings para o novo espaço. Mantenha a escolha de modelo e as dimensões consistentes com os vetores comparados e conserve o texto e os conteúdos multimédia originais separadamente do índice numérico. A similaridade de um embedding é um sinal de recuperação, em vez de uma explicação factual de por que razão um documento responde à pergunta do utilizador.\n\nNum catálogo prático, gere um embedding combinado da fotografia de um produto e da sua descrição aprovada quando o par deve ser recuperado como um objeto. Numa coleção documental, gere embeddings de passagens focadas e compare-os com uma consulta formatada segundo o propósito; depois apresente as passagens de origem juntamente com o resultado de pesquisa. Para áudio ou vídeo, escolha o episódio que descreve o evento pesquisável e conserve o seu intervalo temporal original. O entregável útil é uma representação numérica ligada a evidência de origem para a próxima etapa de pesquisa ou análise da aplicação.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "f59d763b7b1bed1382605e984be6f0f78c169f977f512e52c49652e6165acd99", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "pt-pt", "methods": [ { "html": "google/gemini-embedding-2Gemini Embedding 2 converte texto, imagens, áudio, vídeo e PDF num espaço numérico partilhado. Os seus vetores suportam pesquisa entre modalidades, recuperação, classificação e agrupamento, com dimensões flexíveis e um limite de entrada de 8192 tokens.
Esta descrição apresenta as capacidades do modelo. As entradas, saídas e opções disponíveis no Ailoot para o método selecionado estão indicadas abaixo.
Gemini Embedding 2 é o modelo de embeddings multimodais da Google para representação numérica de texto, imagens, vídeo, áudio e PDF. Converte os diferentes tipos de conteúdos multimédia num espaço partilhado, para que uma aplicação possa comparar o significado entre eles. O resultado é um vetor de números, útil para pesquisa semântica, recuperação documental, recomendação, classificação ou agrupamento; não é uma resposta escrita nem um ficheiro multimédia gerado. A Google documenta cobertura semântica em mais de 100 línguas.
Numa base de conhecimento, crie vetores para as passagens de origem, compare uma consulta do utilizador com eles e recupere o material relevante. Um modelo textual separado pode depois compor uma resposta utilizando essas fontes. Numa coleção multimédia, uma descrição textual pode pesquisar imagens ou vídeos relacionados; uma imagem também pode fornecer a consulta. Preserve a ligação de cada vetor ao conteúdo original, incluindo uma referência de página ou excerto, para que o resultado recuperado possa ser examinado e mostrado no seu contexto original.
O limite global de entrada é de 8192 tokens. O guia do modelo estável permite até seis imagens PNG ou JPEG, até 180 segundos de áudio MP3 ou WAV e até 120 segundos de vídeo MP4 ou MOV. Os codecs de vídeo documentados são H264, H265, AV1 e VP9. O processamento de vídeo utiliza no máximo 32 fotogramas: excertos de até 32 segundos são amostrados a um fotograma por segundo, enquanto excertos mais longos são amostrados uniformemente até 32 fotogramas. A faixa de áudio de um vídeo não é processada nessa entrada de vídeo; gere o embedding do som separadamente quando importar para a recuperação.
A entrada PDF aceita um ficheiro com no máximo seis páginas. A Google recomenda uma página por PDF para obter a melhor qualidade. Divida uma fonte maior em páginas ou secções significativas e conserve a sua relação com o documento original. Escolha um excerto que represente o que deve ser recuperável, em vez de combinar materiais sem relação apenas porque cabem no limite. O limite partilhado de tokens continua a aplicar-se a um pedido com conteúdos multimédia mistos. Cada página PDF consome 258 tokens visuais, além dos tokens do seu texto extraído. No fluxo documentado da Google, o conteúdo que excede o limite partilhado de 8192 tokens é truncado sem erro.
A dimensionalidade de saída é flexível de 128 a 3072, com 3072 como predefinição e 768, 1536 e 3072 como tamanhos recomendados. O modelo utiliza Matryoshka Representation Learning, pelo que os prefixos do vetor continuam úteis em dimensões menores. O seu guia documenta normalização automática tanto para os vetores predefinidos como para os encurtados. Escolha uma dimensão consistente para os registos e consultas que a sua aplicação compara; o tamanho pedido altera a representação numérica, não o próprio conteúdo de origem.
Para tarefas apenas textuais, inclua o propósito no texto em vez de utilizar o campo mais antigo task_type. A Google distingue recuperação assimétrica de comparação simétrica. Uma consulta de pesquisa utiliza «task: search result | query: {content}», enquanto um documento de origem utiliza «title: {title} | text: {content}»; utilize «title: none» se não tiver título. As tarefas de pergunta-resposta, verificação de factos e recuperação de código têm os seus próprios prefixos de consulta. Para classificação, agrupamento ou similaridade entre frases, utilize o mesmo formato de tarefa de forma consistente nos dois lados. O guia geralmente desaconselha acrescentar um prefixo de tarefa à parte textual de uma representação multimodal combinada.
A estrutura da entrada determina se o resultado representa um objeto combinado ou elementos separados. Várias partes fornecidas em conjunto criam um embedding agregado; objetos Content separados criam embeddings separados para cada entrada. Numa publicação com texto e imagem, uma representação combinada pode captar a sua relação. Para registos pesquisáveis de forma independente, mantenha-os separados. Esta escolha afeta a granularidade de recuperação: um vetor para uma publicação inteira é diferente de um para cada passagem ou imagem.
O guia indica que os vetores de Gemini Embedding 001 e Gemini Embedding 2 ocupam espaços incompatíveis e não podem ser comparados diretamente. Uma coleção migrada do modelo anterior precisa de novos embeddings para o novo espaço. Mantenha a escolha de modelo e as dimensões consistentes com os vetores comparados e conserve o texto e os conteúdos multimédia originais separadamente do índice numérico. A similaridade de um embedding é um sinal de recuperação, em vez de uma explicação factual de por que razão um documento responde à pergunta do utilizador.
Num catálogo prático, gere um embedding combinado da fotografia de um produto e da sua descrição aprovada quando o par deve ser recuperado como um objeto. Numa coleção documental, gere embeddings de passagens focadas e compare-os com uma consulta formatada segundo o propósito; depois apresente as passagens de origem juntamente com o resultado de pesquisa. Para áudio ou vídeo, escolha o episódio que descreve o evento pesquisável e conserve o seu intervalo temporal original. O entregável útil é uma representação numérica ligada a evidência de origem para a próxima etapa de pesquisa ou análise da aplicação.
POST /v1/embeddingstext, token_idsembedding| Campo | Tipo | Requisito | Valores e limites | Predefinição |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObrigatório | Valores e limites google/gemini-embedding-2 | Predefinição— |
Campoinput | Tipostring|string[]|integer[]|integer[][] | RequisitoObrigatório | Valores e limites Número mínimo de elementos: 1 Condições: Lote homogéneo não vazio. Os IDs de tokens são números inteiros não negativos. Orçamento de entrada: Máximo: 8192 · Unidade de texto: bytes UTF8 · Unidade de tokens: elementos do array de tokens | Predefinição— |
Campoencoding_format | Tipostring | RequisitoOpcional | Valores e limites float | Predefiniçãofloat |
Campodimensions | Tipointeger | RequisitoNão suportado | Valores e limites Mínimo: 1 | Predefinição— |
Campouser | Tipojson_value | RequisitoOpcional | Valores e limites Condições: A fonte permite este campo de metadados JSON; a semântica exata a montante depende do modelo. | Predefinição— |
Camposession_id | Tipojson_value | RequisitoOpcional | Valores e limites Condições: A fonte permite este campo de metadados JSON; a semântica exata a montante depende do modelo. | Predefinição— |
Campotrace | Tipojson_value | RequisitoOpcional | Valores e limites Condições: A fonte permite este campo de metadados JSON; a semântica exata a montante depende do modelo. | Predefinição— |
Campoprovider | Tipoobject | RequisitoOpcional | Valores e limites Condições: provider.options rejeitado | Predefinição— |
text_to_embedding
| Parâmetro | Contrato |
|---|---|
Parâmetrocontent_type | Contratoapplication/json |
Parâmetrorequired | Contratomodel, input |
Parâmetroinput_shapes | Contratostring, string[], nonnegative_integer_token_array, nonnegative_integer_token_array[] |
Parâmetroencoding_format | Contratofloat |
Parâmetrodimensions_override | Contratofalse |
Parâmetromax_input_budget_units | Contrato8192 |
Parâmetromultimodal_objects | Contratofalse |
Parâmetromaterial_types | Contratotext, token_ids |
Ciclo de vida: synchronous_json
Guarde o índice e a dimensão de cada vetor.
O nome do modelo multimodal não permite objetos de imagem neste caminho exato.
As referências tarifárias não acrescentam opções ao pedido. Os parâmetros suportados constam do método selecionado.
| Configuração | Tabela de tarifas | Custo |
|---|---|---|
| ConfiguraçãoTarifas base dos tokens | Tabela de tarifasTarifa base | Custo Entrada · Tokens de entrada $0.0004 / 1K tokens Saída · Tokens de saída $0 / 1K tokens Entrada · Leitura da cache — / 1K tokens Entrada · Escrita na cache — / 1K tokens Entrada · Escrita na cache, 1 hora — / 1K tokens |
O Ailoot reserva um montante estimado antes de um pedido. Após o resultado, liquida o custo final com base na utilização medida. No streaming, a liquidação usa o registo final de utilização. Como funcionam a reserva e a liquidação →
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
Guarde cada resposta, ficheiro e parte de conteúdo devolvidos na íntegra.
Guarde cada vetor com o respetivo índice. O número de vetores tem de ser igual ao número de entradas; as dimensões têm de ser consistentes.
Não é introduzido nenhum endpoint de tarefas de embeddings.
| Campo | Tipo |
|---|---|
Campoobject | Tipostring |
Campomodel | Tipostring |
Campodata[].index | Tipointeger |
Campodata[].embedding | Tipofinite float[] |
Campousage | Tipoobject |
| Resposta | Condição | Passo seguinte |
|---|---|---|
Resposta400 · invalid_request_error | CondiçãoCampos obrigatórios, representação do material ou valor do parâmetro inválidos | Passo seguinteCorrija os campos indicados antes de um novo pedido de criação. |
Ailoot Ultra google/gemini-embedding-2
Use os caminhos dos métodos indicados acima.