Gemini Embedding 2 es el modelo de embeddings multimodales de Google para representar numéricamente texto, imágenes, video, audio y PDF. Asigna los distintos tipos de medios a un espacio compartido para que una aplicación pueda comparar su significado. El resultado es un vector de números, útil para búsqueda semántica, recuperación documental, recomendaciones, clasificación o agrupación; no es una respuesta escrita ni un archivo multimedia generado. Google documenta cobertura semántica en más de 100 idiomas.
Para una base de conocimiento, crea vectores de los pasajes de origen, compara una consulta del usuario con ellos y recupera el material pertinente. Un modelo textual separado puede redactar después una respuesta utilizando esas fuentes. Para una colección multimedia, una descripción textual puede buscar imágenes o videos relacionados; una imagen también puede aportar la consulta. Conserva la conexión de cada vector con el contenido original, incluida una referencia de página o clip, para que el resultado recuperado pueda examinarse y mostrarse en su contexto original.
El límite global de entrada es de 8192 tokens. La guía del modelo estable permite hasta seis imágenes PNG o JPEG, hasta 180 segundos de audio MP3 o WAV y hasta 120 segundos de video MP4 o MOV. Los códecs de video documentados son H264, H265, AV1 y VP9. El procesamiento de video utiliza como máximo 32 fotogramas: los clips de hasta 32 segundos se muestrean a un fotograma por segundo, mientras que los clips más largos se muestrean uniformemente hasta obtener 32 fotogramas. La pista de audio de un video no se procesa en esa entrada de video; genera el embedding de su sonido por separado cuando importe para la recuperación.
La entrada PDF acepta un archivo con un máximo de seis páginas. Google recomienda una página por PDF para la mejor calidad. Divide una fuente más grande en páginas o secciones significativas y conserva su relación con el documento original. Elige un extracto que represente lo que debe poder recuperarse, en lugar de combinar materiales sin relación solo porque quepan en el límite. El límite compartido de tokens sigue aplicándose a una solicitud de medios mixtos. Cada página PDF consume 258 tokens visuales además de los tokens de su texto extraído. En el flujo documentado de Google, el contenido que supera el límite compartido de 8192 tokens se trunca sin error.
La dimensionalidad de salida es flexible entre 128 y 3072, con 3072 como valor predeterminado y 768, 1536 y 3072 como tamaños recomendados. El modelo utiliza Matryoshka Representation Learning, por lo que los prefijos del vector siguen siendo útiles con dimensiones menores. Su guía documenta normalización automática tanto para los vectores predeterminados como para los acortados. Elige una dimensión coherente para los registros y consultas que compare tu aplicación; el tamaño solicitado cambia la representación numérica, no el propio contenido de origen.
Para tareas exclusivamente textuales, incluye el propósito en el texto, en lugar de utilizar el campo antiguo task_type. Google distingue la recuperación asimétrica de la comparación simétrica. Una consulta de búsqueda utiliza «task: search result | query: {content}», mientras que un documento de origen utiliza «title: {title} | text: {content}»; utiliza «title: none» si no tiene título. Las tareas de pregunta-respuesta, verificación de hechos y recuperación de código tienen sus propios prefijos de consulta. Para clasificación, agrupación o similaridad entre frases, utiliza el mismo formato de tarea de forma coherente en ambos lados. La guía desaconseja en general añadir un prefijo de tarea a la parte textual de una representación multimodal combinada.
La estructura de entrada determina si el resultado representa un objeto combinado o elementos separados. Varias partes proporcionadas juntas crean un embedding agregado; objetos Content separados crean embeddings separados para cada entrada. Para una publicación con texto e imagen, una representación combinada puede captar su relación. Para registros que deban buscarse de forma independiente, mantenlos separados. Esta elección afecta a la granularidad de recuperación: un vector para una publicación entera es distinto de uno para cada pasaje o imagen.
La guía afirma que los vectores de Gemini Embedding 001 y Gemini Embedding 2 ocupan espacios incompatibles y no pueden compararse directamente. Una colección migrada del modelo anterior necesita nuevos embeddings para el espacio nuevo. Mantén la elección de modelo y las dimensiones coherentes con los vectores que se comparan y conserva el texto y los medios originales por separado del índice numérico. La similaridad de un embedding es una señal de recuperación, en lugar de una explicación factual de por qué un documento responde a la pregunta del usuario.
Para un catálogo práctico, genera un embedding combinado de una fotografía de producto y su descripción aprobada cuando el par deba recuperarse como un objeto. Para una colección documental, genera embeddings de pasajes específicos y compáralos con una consulta formateada según su propósito, y después presenta los pasajes de origen junto al resultado de búsqueda. Para audio o video, elige el episodio que describe el evento que se quiere buscar y conserva su intervalo temporal original. El entregable útil es una representación numérica vinculada a evidencia de origen para el siguiente paso de búsqueda o análisis de la aplicación.
", "aboutText": "Gemini Embedding 2 es el modelo de embeddings multimodales de Google para representar numéricamente texto, imágenes, video, audio y PDF. Asigna los distintos tipos de medios a un espacio compartido para que una aplicación pueda comparar su significado. El resultado es un vector de números, útil para búsqueda semántica, recuperación documental, recomendaciones, clasificación o agrupación; no es una respuesta escrita ni un archivo multimedia generado. Google documenta cobertura semántica en más de 100 idiomas.\n\nPara una base de conocimiento, crea vectores de los pasajes de origen, compara una consulta del usuario con ellos y recupera el material pertinente. Un modelo textual separado puede redactar después una respuesta utilizando esas fuentes. Para una colección multimedia, una descripción textual puede buscar imágenes o videos relacionados; una imagen también puede aportar la consulta. Conserva la conexión de cada vector con el contenido original, incluida una referencia de página o clip, para que el resultado recuperado pueda examinarse y mostrarse en su contexto original.\n\nEl límite global de entrada es de 8192 tokens. La guía del modelo estable permite hasta seis imágenes PNG o JPEG, hasta 180 segundos de audio MP3 o WAV y hasta 120 segundos de video MP4 o MOV. Los códecs de video documentados son H264, H265, AV1 y VP9. El procesamiento de video utiliza como máximo 32 fotogramas: los clips de hasta 32 segundos se muestrean a un fotograma por segundo, mientras que los clips más largos se muestrean uniformemente hasta obtener 32 fotogramas. La pista de audio de un video no se procesa en esa entrada de video; genera el embedding de su sonido por separado cuando importe para la recuperación.\n\nLa entrada PDF acepta un archivo con un máximo de seis páginas. Google recomienda una página por PDF para la mejor calidad. Divide una fuente más grande en páginas o secciones significativas y conserva su relación con el documento original. Elige un extracto que represente lo que debe poder recuperarse, en lugar de combinar materiales sin relación solo porque quepan en el límite. El límite compartido de tokens sigue aplicándose a una solicitud de medios mixtos. Cada página PDF consume 258 tokens visuales además de los tokens de su texto extraído. En el flujo documentado de Google, el contenido que supera el límite compartido de 8192 tokens se trunca sin error.\n\nLa dimensionalidad de salida es flexible entre 128 y 3072, con 3072 como valor predeterminado y 768, 1536 y 3072 como tamaños recomendados. El modelo utiliza Matryoshka Representation Learning, por lo que los prefijos del vector siguen siendo útiles con dimensiones menores. Su guía documenta normalización automática tanto para los vectores predeterminados como para los acortados. Elige una dimensión coherente para los registros y consultas que compare tu aplicación; el tamaño solicitado cambia la representación numérica, no el propio contenido de origen.\n\nPara tareas exclusivamente textuales, incluye el propósito en el texto, en lugar de utilizar el campo antiguo task_type. Google distingue la recuperación asimétrica de la comparación simétrica. Una consulta de búsqueda utiliza «task: search result | query: {content}», mientras que un documento de origen utiliza «title: {title} | text: {content}»; utiliza «title: none» si no tiene título. Las tareas de pregunta-respuesta, verificación de hechos y recuperación de código tienen sus propios prefijos de consulta. Para clasificación, agrupación o similaridad entre frases, utiliza el mismo formato de tarea de forma coherente en ambos lados. La guía desaconseja en general añadir un prefijo de tarea a la parte textual de una representación multimodal combinada.\n\nLa estructura de entrada determina si el resultado representa un objeto combinado o elementos separados. Varias partes proporcionadas juntas crean un embedding agregado; objetos Content separados crean embeddings separados para cada entrada. Para una publicación con texto e imagen, una representación combinada puede captar su relación. Para registros que deban buscarse de forma independiente, mantenlos separados. Esta elección afecta a la granularidad de recuperación: un vector para una publicación entera es distinto de uno para cada pasaje o imagen.\n\nLa guía afirma que los vectores de Gemini Embedding 001 y Gemini Embedding 2 ocupan espacios incompatibles y no pueden compararse directamente. Una colección migrada del modelo anterior necesita nuevos embeddings para el espacio nuevo. Mantén la elección de modelo y las dimensiones coherentes con los vectores que se comparan y conserva el texto y los medios originales por separado del índice numérico. La similaridad de un embedding es una señal de recuperación, en lugar de una explicación factual de por qué un documento responde a la pregunta del usuario.\n\nPara un catálogo práctico, genera un embedding combinado de una fotografía de producto y su descripción aprobada cuando el par deba recuperarse como un objeto. Para una colección documental, genera embeddings de pasajes específicos y compáralos con una consulta formateada según su propósito, y después presenta los pasajes de origen junto al resultado de búsqueda. Para audio o video, elige el episodio que describe el evento que se quiere buscar y conserva su intervalo temporal original. El entregable útil es una representación numérica vinculada a evidencia de origen para el siguiente paso de búsqueda o análisis de la aplicación.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "a44eea66e8317e3a3ce42f7c951f703ccdcbb4bcf47d4f7e4fe3288f47c515ce", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "es-mx", "methods": [ { "html": "google/gemini-embedding-2Gemini Embedding 2 asigna texto, imágenes, audio, video y PDF a un espacio numérico compartido. Sus vectores permiten búsqueda entre modalidades, recuperación, clasificación y agrupación, con dimensiones flexibles y un límite de entrada de 8192 tokens.
Esta descripción cubre las capacidades del modelo. Las entradas, salidas y opciones disponibles en Ailoot se indican a continuación para el método seleccionado.
Gemini Embedding 2 es el modelo de embeddings multimodales de Google para representar numéricamente texto, imágenes, video, audio y PDF. Asigna los distintos tipos de medios a un espacio compartido para que una aplicación pueda comparar su significado. El resultado es un vector de números, útil para búsqueda semántica, recuperación documental, recomendaciones, clasificación o agrupación; no es una respuesta escrita ni un archivo multimedia generado. Google documenta cobertura semántica en más de 100 idiomas.
Para una base de conocimiento, crea vectores de los pasajes de origen, compara una consulta del usuario con ellos y recupera el material pertinente. Un modelo textual separado puede redactar después una respuesta utilizando esas fuentes. Para una colección multimedia, una descripción textual puede buscar imágenes o videos relacionados; una imagen también puede aportar la consulta. Conserva la conexión de cada vector con el contenido original, incluida una referencia de página o clip, para que el resultado recuperado pueda examinarse y mostrarse en su contexto original.
El límite global de entrada es de 8192 tokens. La guía del modelo estable permite hasta seis imágenes PNG o JPEG, hasta 180 segundos de audio MP3 o WAV y hasta 120 segundos de video MP4 o MOV. Los códecs de video documentados son H264, H265, AV1 y VP9. El procesamiento de video utiliza como máximo 32 fotogramas: los clips de hasta 32 segundos se muestrean a un fotograma por segundo, mientras que los clips más largos se muestrean uniformemente hasta obtener 32 fotogramas. La pista de audio de un video no se procesa en esa entrada de video; genera el embedding de su sonido por separado cuando importe para la recuperación.
La entrada PDF acepta un archivo con un máximo de seis páginas. Google recomienda una página por PDF para la mejor calidad. Divide una fuente más grande en páginas o secciones significativas y conserva su relación con el documento original. Elige un extracto que represente lo que debe poder recuperarse, en lugar de combinar materiales sin relación solo porque quepan en el límite. El límite compartido de tokens sigue aplicándose a una solicitud de medios mixtos. Cada página PDF consume 258 tokens visuales además de los tokens de su texto extraído. En el flujo documentado de Google, el contenido que supera el límite compartido de 8192 tokens se trunca sin error.
La dimensionalidad de salida es flexible entre 128 y 3072, con 3072 como valor predeterminado y 768, 1536 y 3072 como tamaños recomendados. El modelo utiliza Matryoshka Representation Learning, por lo que los prefijos del vector siguen siendo útiles con dimensiones menores. Su guía documenta normalización automática tanto para los vectores predeterminados como para los acortados. Elige una dimensión coherente para los registros y consultas que compare tu aplicación; el tamaño solicitado cambia la representación numérica, no el propio contenido de origen.
Para tareas exclusivamente textuales, incluye el propósito en el texto, en lugar de utilizar el campo antiguo task_type. Google distingue la recuperación asimétrica de la comparación simétrica. Una consulta de búsqueda utiliza «task: search result | query: {content}», mientras que un documento de origen utiliza «title: {title} | text: {content}»; utiliza «title: none» si no tiene título. Las tareas de pregunta-respuesta, verificación de hechos y recuperación de código tienen sus propios prefijos de consulta. Para clasificación, agrupación o similaridad entre frases, utiliza el mismo formato de tarea de forma coherente en ambos lados. La guía desaconseja en general añadir un prefijo de tarea a la parte textual de una representación multimodal combinada.
La estructura de entrada determina si el resultado representa un objeto combinado o elementos separados. Varias partes proporcionadas juntas crean un embedding agregado; objetos Content separados crean embeddings separados para cada entrada. Para una publicación con texto e imagen, una representación combinada puede captar su relación. Para registros que deban buscarse de forma independiente, mantenlos separados. Esta elección afecta a la granularidad de recuperación: un vector para una publicación entera es distinto de uno para cada pasaje o imagen.
La guía afirma que los vectores de Gemini Embedding 001 y Gemini Embedding 2 ocupan espacios incompatibles y no pueden compararse directamente. Una colección migrada del modelo anterior necesita nuevos embeddings para el espacio nuevo. Mantén la elección de modelo y las dimensiones coherentes con los vectores que se comparan y conserva el texto y los medios originales por separado del índice numérico. La similaridad de un embedding es una señal de recuperación, en lugar de una explicación factual de por qué un documento responde a la pregunta del usuario.
Para un catálogo práctico, genera un embedding combinado de una fotografía de producto y su descripción aprobada cuando el par deba recuperarse como un objeto. Para una colección documental, genera embeddings de pasajes específicos y compáralos con una consulta formateada según su propósito, y después presenta los pasajes de origen junto al resultado de búsqueda. Para audio o video, elige el episodio que describe el evento que se quiere buscar y conserva su intervalo temporal original. El entregable útil es una representación numérica vinculada a evidencia de origen para el siguiente paso de búsqueda o análisis de la aplicación.
POST /v1/embeddingstext, token_idsembedding| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites google/gemini-embedding-2 | Predeterminado— |
Campoinput | Tipostring|string[]|integer[]|integer[][] | RequisitoObligatorio | Valores y límites Número mínimo de elementos: 1 Condiciones: Lote homogéneo no vacío. Los ID de tokens son números enteros no negativos. Presupuesto de entrada: Máximo: 8,192 · Unidad de texto: bytes UTF8 · Unidad de tokens: elementos de un arreglo de tokens | Predeterminado— |
Campoencoding_format | Tipostring | RequisitoOpcional | Valores y límites float | Predeterminadofloat |
Campodimensions | Tipointeger | RequisitoNo compatible | Valores y límites Mínimo: 1 | Predeterminado— |
Campouser | Tipojson_value | RequisitoOpcional | Valores y límites Condiciones: La fuente permite este campo metadata de JSON; la semántica exacta en el sistema de origen depende del modelo. | Predeterminado— |
Camposession_id | Tipojson_value | RequisitoOpcional | Valores y límites Condiciones: La fuente permite este campo metadata de JSON; la semántica exacta en el sistema de origen depende del modelo. | Predeterminado— |
Campotrace | Tipojson_value | RequisitoOpcional | Valores y límites Condiciones: La fuente permite este campo metadata de JSON; la semántica exacta en el sistema de origen depende del modelo. | Predeterminado— |
Campoprovider | Tipoobject | RequisitoOpcional | Valores y límites Condiciones: provider.options rechazado | Predeterminado— |
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
Conserva todos los índices y dimensiones de los vectores.
El nombre de un modelo multimodal no habilita objetos de imagen en esta ruta exacta.
Las referencias tarifarias no añaden opciones a la solicitud. Los parámetros admitidos se indican en el método seleccionado.
| Configuración | Tabla de tarifas | Cargo |
|---|---|---|
| ConfiguraciónTarifas base por token | Tabla de tarifasTarifa base | Cargo Entrada · Tokens de entrada $0.0004 / 1K tokens Salida · Tokens de salida $0 / 1K tokens Entrada · Lectura de caché — / 1K tokens Entrada · Escritura en caché — / 1K tokens Entrada · Escritura en caché, 1 hora — / 1K tokens |
Ailoot reserva un monto estimado antes de la solicitud. Tras obtener el resultado, liquida el cargo definitivo según el uso medido. En las respuestas en flujo, la liquidación usa el registro de uso final. Cómo funcionan la reserva y la liquidación →
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
Conserva todas las respuestas, archivos y partes de contenido completos recibidos.
Conserva cada vector con su índice. La cantidad de vectores debe ser igual a la cantidad de entradas; las dimensiones deben ser consistentes.
No se incorpora ningún endpoint de tareas de embeddings.
| Campo | Tipo |
|---|---|
Campoobject | Tipostring |
Campomodel | Tipostring |
Campodata[].index | Tipointeger |
Campodata[].embedding | Tipofinite float[] |
Campousage | Tipoobject |
| Respuesta | Condición | Siguiente paso |
|---|---|---|
Respuesta400 · invalid_request_error | CondiciónCampos obligatorios, representación del material o valor del parámetro no válidos | Siguiente pasoCorrige los campos indicados antes de una nueva solicitud de creación. |
Ailoot Ultra google/gemini-embedding-2
Usa las rutas de método indicadas arriba.