LFM2.5-Embedding-350M es el bi-encoder denso de LiquidAI para recuperación multilingüe y entre idiomas. Produce un vector de 1024 dimensiones para cada texto y se dirige a búsqueda de contexto corto en once idiomas. La familia de modelos con nombre 350M utiliza una adaptación bidireccional de LFM2.5-350M-Base; la tabla detallada del modelo da aproximadamente 354 millones de parámetros para esta edición de embeddings.
El fabricante adapta la arquitectura base para que la atención y las convoluciones locales puedan utilizar contexto en ambos lados de un token. El pooling de tipo CLS convierte el texto procesado en un vector denso. Su tabla del modelo describe diecisiete capas: diez bloques de convolución, seis bloques de atención y una etapa de pooling. Este es un codificador de recuperación, con su propia preparación y salida, en lugar de la tarea de generación de texto del modelo base.
El modelo con nombre separado LFM2.5-ColBERT-350M conserva vectores por token para interacción tardía. Esa representación exige un índice y método de comparación diferentes. El modelo Embedding de esta entrada aporta un vector por documento o consulta, con similaridad del coseno como comparación documentada.
Prepara las consultas de búsqueda con «query:» y los pasajes de origen con «document:». El fabricante guarda estos prompts en su configuración y su flujo de referencia aplica el nombre de prompt correspondiente. Recomienda expresamente utilizar el rol correspondiente en cada lado porque el modelo se entrenó con esos prefijos. Este prefijo documental es distinto de la convención «passage:» de los modelos E5.
Una colección práctica de búsqueda de productos puede contener descripciones en los idiomas compatibles. Prepara la formulación de búsqueda del usuario como consulta y cada descripción de producto como documento. Guarda el texto original, el identificador de producto y el idioma junto con el vector, para que un resultado de búsqueda pueda devolver el registro correspondiente. Para una colección de soporte, conserva la política o instrucción pertinente para la pregunta, en lugar de sustituirla por una etiqueta corta sin relación.
El conjunto de idiomas documentado es inglés, español, alemán, francés, italiano, portugués, árabe, sueco, noruego, japonés y coreano. El fabricante se dirige expresamente tanto a recuperación dentro de un idioma como a recuperación entre idiomas. Prepara preguntas reales del público previsto y examina el texto de los documentos devueltos en esos idiomas.
La especificación de longitud documental es de 512 tokens. Divide una fuente larga en pasajes coherentes que conserven el encabezado, las definiciones y las condiciones necesarias para un resultado recuperado. El prefijo de rol y el contexto añadido forman parte de la entrada preparada. Una respuesta de preguntas frecuentes, una explicación de producto o una sección específica de un documento técnico es una unidad más adecuada que un manual entero demasiado grande.
El fabricante describe tres etapas de entrenamiento: preentrenamiento contrastivo en inglés, destilación multilingüe y entre idiomas y después ajuste con negativos difíciles obtenidos mediante minería. El modelo resultante está destinado a catálogos de productos, colecciones de preguntas frecuentes y soporte, búsqueda de archivos o notas y recuperación de conocimiento empresarial. Esas son tareas de las representaciones textuales, no afirmaciones sobre el despliegue de una aplicación particular.
El ejemplo del productor normaliza los vectores de consulta y documento y los ordena con un producto escalar, equivalente a la similaridad del coseno. Precalcula las representaciones del corpus cuando esté preparado el material de origen y después genera el embedding de una consulta de búsqueda y devuelve documentos candidatos con sus textos e identificadores. Mantén el modelo seleccionado y la convención de roles junto al índice, para que la comparación numérica utilice representaciones compatibles.
El resultado útil es un índice denso compacto de búsqueda o un vector de consulta que recupera material de origen entre los idiomas documentados. Esta edición exacta LFM2.5 Embedding sigue siendo distinta de su acompañante ColBERT, los recuperadores LFM2 anteriores y las implementaciones cuantizadas externamente. El texto del pasaje seleccionado es la evidencia que utiliza un lector o una etapa posterior de respuesta RAG.
", "aboutText": "LFM2.5-Embedding-350M es el bi-encoder denso de LiquidAI para recuperación multilingüe y entre idiomas. Produce un vector de 1024 dimensiones para cada texto y se dirige a búsqueda de contexto corto en once idiomas. La familia de modelos con nombre 350M utiliza una adaptación bidireccional de LFM2.5-350M-Base; la tabla detallada del modelo da aproximadamente 354 millones de parámetros para esta edición de embeddings.\n\n### Una representación bidireccional de recuperación\n\nEl fabricante adapta la arquitectura base para que la atención y las convoluciones locales puedan utilizar contexto en ambos lados de un token. El pooling de tipo CLS convierte el texto procesado en un vector denso. Su tabla del modelo describe diecisiete capas: diez bloques de convolución, seis bloques de atención y una etapa de pooling. Este es un codificador de recuperación, con su propia preparación y salida, en lugar de la tarea de generación de texto del modelo base.\n\nEl modelo con nombre separado LFM2.5-ColBERT-350M conserva vectores por token para interacción tardía. Esa representación exige un índice y método de comparación diferentes. El modelo Embedding de esta entrada aporta un vector por documento o consulta, con similaridad del coseno como comparación documentada.\n\n### Utiliza los prompts asimétricos correctos\n\nPrepara las consultas de búsqueda con «query:» y los pasajes de origen con «document:». El fabricante guarda estos prompts en su configuración y su flujo de referencia aplica el nombre de prompt correspondiente. Recomienda expresamente utilizar el rol correspondiente en cada lado porque el modelo se entrenó con esos prefijos. Este prefijo documental es distinto de la convención «passage:» de los modelos E5.\n\nUna colección práctica de búsqueda de productos puede contener descripciones en los idiomas compatibles. Prepara la formulación de búsqueda del usuario como consulta y cada descripción de producto como documento. Guarda el texto original, el identificador de producto y el idioma junto con el vector, para que un resultado de búsqueda pueda devolver el registro correspondiente. Para una colección de soporte, conserva la política o instrucción pertinente para la pregunta, en lugar de sustituirla por una etiqueta corta sin relación.\n\n### Idiomas y tamaño de los pasajes\n\nEl conjunto de idiomas documentado es inglés, español, alemán, francés, italiano, portugués, árabe, sueco, noruego, japonés y coreano. El fabricante se dirige expresamente tanto a recuperación dentro de un idioma como a recuperación entre idiomas. Prepara preguntas reales del público previsto y examina el texto de los documentos devueltos en esos idiomas.\n\nLa especificación de longitud documental es de 512 tokens. Divide una fuente larga en pasajes coherentes que conserven el encabezado, las definiciones y las condiciones necesarias para un resultado recuperado. El prefijo de rol y el contexto añadido forman parte de la entrada preparada. Una respuesta de preguntas frecuentes, una explicación de producto o una sección específica de un documento técnico es una unidad más adecuada que un manual entero demasiado grande.\n\n### Entrenamiento y correspondencia\n\nEl fabricante describe tres etapas de entrenamiento: preentrenamiento contrastivo en inglés, destilación multilingüe y entre idiomas y después ajuste con negativos difíciles obtenidos mediante minería. El modelo resultante está destinado a catálogos de productos, colecciones de preguntas frecuentes y soporte, búsqueda de archivos o notas y recuperación de conocimiento empresarial. Esas son tareas de las representaciones textuales, no afirmaciones sobre el despliegue de una aplicación particular.\n\nEl ejemplo del productor normaliza los vectores de consulta y documento y los ordena con un producto escalar, equivalente a la similaridad del coseno. Precalcula las representaciones del corpus cuando esté preparado el material de origen y después genera el embedding de una consulta de búsqueda y devuelve documentos candidatos con sus textos e identificadores. Mantén el modelo seleccionado y la convención de roles junto al índice, para que la comparación numérica utilice representaciones compatibles.\n\nEl resultado útil es un índice denso compacto de búsqueda o un vector de consulta que recupera material de origen entre los idiomas documentados. Esta edición exacta LFM2.5 Embedding sigue siendo distinta de su acompañante ColBERT, los recuperadores LFM2 anteriores y las implementaciones cuantizadas externamente. El texto del pasaje seleccionado es la evidencia que utiliza un lector o una etapa posterior de respuesta RAG.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "83ce5c9db09e650775fcc4c86a6b698941586bd5ae88cfd266777da699ca8d04", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "es-mx", "methods": [ { "html": "liquid/lfm-2.5-embedding-350m:freeLiquidAI LFM2.5-Embedding-350M produce un vector de 1024 dimensiones por texto para recuperación multilingüe y entre idiomas. Se orienta a 11 idiomas y entradas breves de 512 tokens, con prefijos distintos para consultas y documentos.
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.
LFM2.5-Embedding-350M es el bi-encoder denso de LiquidAI para recuperación multilingüe y entre idiomas. Produce un vector de 1024 dimensiones para cada texto y se dirige a búsqueda de contexto corto en once idiomas. La familia de modelos con nombre 350M utiliza una adaptación bidireccional de LFM2.5-350M-Base; la tabla detallada del modelo da aproximadamente 354 millones de parámetros para esta edición de embeddings.
El fabricante adapta la arquitectura base para que la atención y las convoluciones locales puedan utilizar contexto en ambos lados de un token. El pooling de tipo CLS convierte el texto procesado en un vector denso. Su tabla del modelo describe diecisiete capas: diez bloques de convolución, seis bloques de atención y una etapa de pooling. Este es un codificador de recuperación, con su propia preparación y salida, en lugar de la tarea de generación de texto del modelo base.
El modelo con nombre separado LFM2.5-ColBERT-350M conserva vectores por token para interacción tardía. Esa representación exige un índice y método de comparación diferentes. El modelo Embedding de esta entrada aporta un vector por documento o consulta, con similaridad del coseno como comparación documentada.
Prepara las consultas de búsqueda con «query:» y los pasajes de origen con «document:». El fabricante guarda estos prompts en su configuración y su flujo de referencia aplica el nombre de prompt correspondiente. Recomienda expresamente utilizar el rol correspondiente en cada lado porque el modelo se entrenó con esos prefijos. Este prefijo documental es distinto de la convención «passage:» de los modelos E5.
Una colección práctica de búsqueda de productos puede contener descripciones en los idiomas compatibles. Prepara la formulación de búsqueda del usuario como consulta y cada descripción de producto como documento. Guarda el texto original, el identificador de producto y el idioma junto con el vector, para que un resultado de búsqueda pueda devolver el registro correspondiente. Para una colección de soporte, conserva la política o instrucción pertinente para la pregunta, en lugar de sustituirla por una etiqueta corta sin relación.
El conjunto de idiomas documentado es inglés, español, alemán, francés, italiano, portugués, árabe, sueco, noruego, japonés y coreano. El fabricante se dirige expresamente tanto a recuperación dentro de un idioma como a recuperación entre idiomas. Prepara preguntas reales del público previsto y examina el texto de los documentos devueltos en esos idiomas.
La especificación de longitud documental es de 512 tokens. Divide una fuente larga en pasajes coherentes que conserven el encabezado, las definiciones y las condiciones necesarias para un resultado recuperado. El prefijo de rol y el contexto añadido forman parte de la entrada preparada. Una respuesta de preguntas frecuentes, una explicación de producto o una sección específica de un documento técnico es una unidad más adecuada que un manual entero demasiado grande.
El fabricante describe tres etapas de entrenamiento: preentrenamiento contrastivo en inglés, destilación multilingüe y entre idiomas y después ajuste con negativos difíciles obtenidos mediante minería. El modelo resultante está destinado a catálogos de productos, colecciones de preguntas frecuentes y soporte, búsqueda de archivos o notas y recuperación de conocimiento empresarial. Esas son tareas de las representaciones textuales, no afirmaciones sobre el despliegue de una aplicación particular.
El ejemplo del productor normaliza los vectores de consulta y documento y los ordena con un producto escalar, equivalente a la similaridad del coseno. Precalcula las representaciones del corpus cuando esté preparado el material de origen y después genera el embedding de una consulta de búsqueda y devuelve documentos candidatos con sus textos e identificadores. Mantén el modelo seleccionado y la convención de roles junto al índice, para que la comparación numérica utilice representaciones compatibles.
El resultado útil es un índice denso compacto de búsqueda o un vector de consulta que recupera material de origen entre los idiomas documentados. Esta edición exacta LFM2.5 Embedding sigue siendo distinta de su acompañante ColBERT, los recuperadores LFM2 anteriores y las implementaciones cuantizadas externamente. El texto del pasaje seleccionado es la evidencia que utiliza un lector o una etapa posterior de respuesta RAG.
POST /v1/embeddingstext, token_idsembedding| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites liquid/lfm-2.5-embedding-350m:free | 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: 512 · 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 | Contrato512 |
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 / 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": "liquid/lfm-2.5-embedding-350m:free", "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='liquid/lfm-2.5-embedding-350m:free',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 liquid/lfm-2.5-embedding-350m:free
Usa las rutas de método indicadas arriba.