Mistral: Codestral Embed 2505
Codestral Embed 2505 representa código y consultas en lenguaje natural como vectores para búsqueda en repositorios y recuperación para asistentes de programación. El fabricante documenta un contexto de 8192 tokens, dimensiones configurables de hasta 3072 y formatos de salida de coma flotante, enteros o bits empaquetados.
Sobre el modelo
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.
Codestral Embed 2505 es el modelo de embeddings de Mistral AI especializado en recuperación de código. Recibe texto que contiene código fuente o una consulta sobre código en lenguaje natural y devuelve vectores numéricos. El fabricante lo posiciona para búsqueda en repositorios, recuperación de contexto para asistentes de programación, análisis de similaridad y duplicados y agrupación de código por su funcionalidad o estructura. Su identificador fijo de edición es codestral-embed-2505.
Entrada y representación
Una entrada de código puede ser una función, un fragmento relacionado de código fuente u otra unidad significativa de un repositorio. Una consulta en lenguaje natural puede describir el comportamiento que se quiere localizar, en lugar de nombrar el símbolo exacto. El embedding representa esa entrada para la comparación; el modelo no genera una implementación nueva ni ejecuta el código que recibe.
La publicación oficial documenta un contexto completo de entrada de 8192 tokens. Para recuperación, el fabricante recomienda fragmentos de aproximadamente 3000 caracteres con un solapamiento de 1000 caracteres y señala que los fragmentos más grandes pueden perjudicar la recuperación. Son recomendaciones de preparación para recuperación, no un límite de tokens de 3000 caracteres. Mantén el archivo, símbolo y ubicación de origen asociados a cada elemento preparado para que la aplicación pueda devolver el código pertinente después de la búsqueda.
Precisión y dimensiones de salida
La guía de embeddings de código documenta los tipos de salida float, int8, uint8, binary y ubinary. Float utiliza valores de coma flotante de precisión simple de 32 bits. Int8 utiliza enteros de 8 bits con signo de -128 a 127, mientras que uint8 utiliza valores de 8 bits sin signo de 0 a 255. Binary y ubinary guardan valores cuantizados de un bit en elementos empaquetados de 8 bits, utilizando contenedores con o sin signo, respectivamente.
La representación de bits empaquetados cambia la longitud de la lista devuelta: la guía describe un elemento empaquetado por cada ocho dimensiones lógicas del embedding. Por tanto, una comparación que tenga en cuenta el formato es distinta de tratar los bytes empaquetados como coordenadas ordinarias de coma flotante. Conserva el tipo elegido junto con el vector y utiliza la misma representación para el código indexado y su consulta.
La documentación de parámetros da una dimensión predeterminada de 1536 y un máximo de 3072. Las dimensiones están ordenadas por relevancia y el fabricante describe conservar las primeras dimensiones hasta la cantidad elegida como una forma de seleccionar el tamaño de representación. Elige la dimensión de forma coherente para la colección almacenada y las consultas nuevas. Una representación más corta o cuantizada cambia el comportamiento de almacenamiento y comparación; no aumenta el contexto de entrada ni convierte el modelo en un generador de código.
Programación aumentada por recuperación
El primer caso de uso de la publicación es recuperar contexto para completar, editar o explicar código. Prepara unidades de código significativas y conserva la revisión del repositorio y los identificadores de origen. Una pregunta sobre cómo se gestiona un error particular puede recuperar funciones relacionadas, que la aplicación proporciona después a un modelo de programación junto con la solicitud real de cambio.
Un resultado práctico es un conjunto ordenado de fragmentos de código fuente con rutas de archivo, símbolos y el contenido necesario para entender su comportamiento. Un desarrollador puede abrir los fragmentos recuperados o pasarlos a un asistente. Codestral Embed realiza el paso de representación; un componente separado selecciona los resultados y un modelo de generación escribe la explicación o el código propuesto.
Búsqueda semántica y similaridad
El fabricante describe búsqueda de código con consultas en lenguaje natural o código. Un desarrollador puede pedir la implementación de un comportamiento incluso cuando el nombre de la función difiera de la formulación de la solicitud. Incluye el comportamiento y las condiciones que distinguen la implementación prevista; una consulta general sobre un subsistema entero puede recuperar material relacionado sin resolver la pregunta específica.
La publicación también describe cómo encontrar código casi duplicado o funcionalmente similar pese a diferencias léxicas. Esos resultados pueden ayudar a localizar una implementación reutilizable o identificar código que necesita una revisión posterior. La similaridad en el espacio de embeddings es una señal para examinar la fuente; no establece que dos fragmentos tengan un comportamiento idéntico para todas las entradas.
Agrupación, análisis y comparación
Los embeddings de código pueden utilizarse para agrupar código por funcionalidad o estructura y examinar la composición de un repositorio. Mantén disponibles los fragmentos originales y los identificadores para que una persona o una etapa posterior de la aplicación pueda interpretar un grupo. Un grupo es una agrupación basada en representaciones, no una descripción de arquitectura verificada automáticamente.
Los ejemplos de vectores de coma flotante del fabricante utilizan embeddings normalizados a longitud unitaria, para los que la similaridad del coseno, el producto escalar y la distancia euclídea dan ordenaciones coherentes. La salida cuantizada y de bits empaquetados debe conservar su propio tratamiento de formato, en lugar de heredar una suposición sobre coordenadas en bruto de coma flotante. El endpoint publicado también conserva índices de entrada, lo que ayuda a mantener la conexión entre cada vector y su elemento de origen.
Edición y límites prácticos
La página exacta del modelo enumera flujos de embeddings y lotes con una etiqueta de contexto de 8k, mientras que la publicación proporciona el valor de 8192 tokens. Conserva la edición con nombre 2505 y la dimensión y el tipo de salida elegidos durante todo el flujo de colección y consulta. Esta es una salida vectorial orientada a código, distinta de la compleción de texto de Codestral y del modelo textual de dimensión fija Mistral Embed.
Prepara unidades de código que contengan el comportamiento pertinente, conserva sus ubicaciones de origen y formula la pregunta que permita localizarlas. El artefacto útil es una representación recuperable vinculada a código real, que permite el siguiente paso de explicación, edición o revisión por un desarrollador sin realizar ese paso por sí misma.
Ailoot Ultra · Representaciones vectoriales POST /v1/embeddings mistralai/codestral-embed-2505
mistralai/codestral-embed-2505
mistralai/codestral-embed-2505Primeros pasos
Codestral Embed 2505 representa código y consultas en lenguaje natural como vectores para búsqueda en repositorios y recuperación para asistentes de programación. El fabricante documenta un contexto de 8192 tokens, dimensiones configurables de hasta 3072 y formatos de salida de coma flotante, enteros o bits empaquetados.
- Entradas aceptadas
- Texto · token_ids
- Resultados
- embedding
Disponible en Ailoot · entradas y métodos
Ailoot Ultra · Representaciones vectoriales POST /v1/embeddings
- Tipos de entrada
text,token_ids- Tipos de salida
embedding- Contexto
- 8192 tokens
- Formato de salida
- json
| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites mistralai/codestral-embed-2505 | 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: 8192 · Unidad de texto: bytes UTF8 · Unidad de tokens: elementos de un array 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: Source permite este campo de metadatos JSON; su semántica exacta en el proveedor depende de cada modelo. | Predeterminado— |
Camposession_id | Tipojson_value | RequisitoOpcional | Valores y límites Condiciones: Source permite este campo de metadatos JSON; su semántica exacta en el proveedor depende de cada modelo. | Predeterminado— |
Campotrace | Tipojson_value | RequisitoOpcional | Valores y límites Condiciones: Source permite este campo de metadatos JSON; su semántica exacta en el proveedor depende de cada modelo. | Predeterminado— |
Campoprovider | Tipoobject | RequisitoOpcional | Valores y límites Condiciones: provider.options se rechaza | Predeterminado— |
Combinaciones de materiales de entrada
text_to_embedding
Parámetros del método y ciclo de vida
| 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.
Que el modelo tenga un nombre multimodal no permite enviar objetos de imagen por esta ruta concreta.
Planes
Las referencias tarifarias no añaden opciones a la solicitud. Los parámetros admitidos se indican en el método seleccionado.
- Modo rápido
- Tarifa estándar Cuando se selecciona el modo rápido
- Modo flex
- Tarifa estándar Cuando se selecciona el modo flex
- Esfuerzo máximo de razonamiento
- Tarifa estándar Cuando el esfuerzo máximo de razonamiento utiliza el ajuste predeterminado (default)
Tarifas de Ailoot
Precios por configuración
| Configuración | Tabla de tarifas | Cargo |
|---|---|---|
| ConfiguraciónTarifas base por token | Tabla de tarifasTarifa base | Cargo Entrada · Tokens de entrada $0.0003 / 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 importe 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 →
Solicitudes de ejemplo
Ailoot Ultra · Representaciones vectoriales
set -eu
: "${AILOOT_API_KEY:?Set your Ailoot API key}"
python3 - <<'PY_REQUEST'
import json,os
from pathlib import Path
p=json.loads('{"model": "mistralai/codestral-embed-2505", "input": ["First document", "Second document"]}')
Path("request.json").write_text(json.dumps(p,ensure_ascii=False))
PY_REQUEST
curl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/embeddings \
-H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \
--data-binary @request.json -D response-headers.txt -o result.json
python3 - <<'PY_RESULT'
import json
from pathlib import Path
r=json.loads(Path("result.json").read_text())
for x in r.get("data",[]): print(json.dumps({"index":x.get("index"),"embedding":x.get("embedding")}))
PY_RESULT
from openai import OpenAI
import os
client=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)
result=client.embeddings.create(model='mistralai/codestral-embed-2505',input=["First document","Second document"])
print(result)
for item in result.data:print(item.index,item.embedding)
Recibir y guardar resultados
Ailoot Ultra · Representaciones vectoriales
json
Conserva todos los resultados completados
Conserva todas las respuestas, archivos y partes de contenido completos recibidos.
Conserva cada vector con su índice. El número de vectores debe coincidir con el número de entradas; las dimensiones deben ser coherentes.
Si es necesario revisar la respuesta original
No se introduce ningún endpoint de trabajos de embeddings.
Campos de respuesta
| Campo | Tipo |
|---|---|
Campoobject | Tipostring |
Campomodel | Tipostring |
Campodata[].index | Tipointeger |
Campodata[].embedding | Tipofinite float[] |
Campousage | Tipoobject |
Errores y siguientes pasos
| 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. |
Alias
Alias del modelo
Ailoot Ultra mistralai/codestral-embed-2505
Alias de rutas de métodos
Usa las rutas de método indicadas arriba.
ID de modelo relacionados
FAQ · Mistral: Codestral Embed 2505
- ¿Qué entradas y resultados están disponibles?
POST /v1/embeddings·mistralai/codestral-embed-2505:text,token_ids→embedding- ¿Qué campos utiliza la solicitud?
POST /v1/embeddings·mistralai/codestral-embed-2505:model,input,encoding_format,provider- ¿Qué límites se aplican?
POST /v1/embeddings·mistralai/codestral-embed-2505:ctx:8192;input.budget.maximum:8192(bytes UTF8);input.min_items:1