Codestral Embed 2505 est le modèle de plongement de Mistral AI spécialisé dans la recherche de code. Il reçoit du texte contenant du code source ou une requête de code en langue naturelle et renvoie des vecteurs numériques. Le fabricant le positionne pour la recherche dans les dépôts, la recherche de contexte pour les assistants de programmation, l’analyse de similarité et de doublons, ainsi que le regroupement du code selon sa fonctionnalité ou sa structure. Son identifiant de publication fixe est codestral-embed-2505.
Entrée et représentation
Une entrée de code peut être une fonction, un fragment source lié ou une autre unité porteuse de sens d’un dépôt. Une requête en langue naturelle peut décrire le comportement à trouver, plutôt que de nommer le symbole exact. Le plongement représente cette entrée pour la comparaison ; le modèle ne génère pas de nouvelle implémentation et n’exécute pas le code qu’il reçoit.
La publication officielle documente un contexte d’entrée complet de 8192 tokens. Pour la recherche, le fabricant recommande des segments d’environ 3000 caractères avec un chevauchement de 1000 caractères, en précisant que des segments plus grands peuvent nuire à la recherche. Ce sont des recommandations de préparation pour la recherche, plutôt qu’une limite en tokens de 3000 caractères. Gardez le fichier, le symbole et l’emplacement source associés à chaque élément préparé, afin que l’application puisse renvoyer le code pertinent après la recherche.
Précision de sortie et dimensions
Le guide de plongement de code documente les types de sortie float, int8, uint8, binary et ubinary. Float utilise des valeurs à simple précision de 32 bits. Int8 utilise des entiers signés de 8 bits, de -128 à 127, tandis que uint8 utilise des valeurs non signées de 8 bits, de 0 à 255. Binary et ubinary stockent des valeurs quantifiées d’un seul bit dans des éléments compactés de 8 bits, avec des conteneurs respectivement signés et non signés.
La représentation à bits compactés modifie la longueur de la liste renvoyée : le guide décrit un élément compacté pour huit dimensions logiques de plongement. Une comparaison tenant compte du format diffère donc d’un traitement des octets compactés comme des coordonnées ordinaires à virgule flottante. Préservez le type choisi avec le vecteur et utilisez la même représentation pour le code indexé et sa requête.
La documentation des paramètres donne une dimension par défaut de 1536 et un maximum de 3072. Les dimensions sont ordonnées par pertinence, et le fabricant décrit la conservation du nombre choisi de premières dimensions comme un moyen de sélectionner la taille de représentation. Choisissez la dimension de manière cohérente pour la collection stockée et les nouvelles requêtes. Une représentation plus courte ou quantifiée modifie le stockage et le comportement de comparaison ; elle n’augmente pas le contexte d’entrée et ne transforme pas le modèle en générateur de code.
Programmation augmentée par la recherche
Le premier cas d’usage de la publication est la recherche de contexte pour la complétion, la modification ou l’explication de code. Préparez des unités de code porteuses de sens et conservez la révision du dépôt et les identifiants sources. Une question sur la gestion d’une erreur particulière peut retrouver des fonctions liées, que l’application fournit ensuite à un modèle de programmation avec la demande réelle de modification.
Un résultat concret est un ensemble classé d’extraits sources comprenant les chemins de fichiers, les symboles et le contenu nécessaire à la compréhension de leur comportement. Les extraits retrouvés peuvent être ouverts par un développeur ou transmis à un assistant. Codestral Embed effectue l’étape de représentation ; un composant distinct sélectionne les résultats, et un modèle de génération rédige l’explication ou le code proposé.
Recherche sémantique et similarité
Le fabricant décrit la recherche de code au moyen de requêtes en langue naturelle ou en code. Un développeur peut demander l’implémentation d’un comportement, même lorsque le nom de la fonction diffère de la formulation de la demande. Incluez le comportement et les conditions qui distinguent l’implémentation visée ; une requête générale sur un sous-système entier peut retrouver du matériau lié sans résoudre la question précise.
La publication décrit aussi la recherche de code presque identique ou fonctionnellement similaire malgré des différences lexicales. De tels résultats peuvent aider à trouver une implémentation réutilisable ou à repérer du code nécessitant une vérification approfondie. La similarité dans l’espace de plongement est un signal invitant à examiner la source ; elle n’établit pas que deux fragments ont un comportement identique pour toutes les entrées.
Regroupement, analyse et comparaison
Les plongements de code peuvent servir à regrouper le code par fonctionnalité ou par structure et à examiner la composition d’un dépôt. Gardez les extraits d’origine et les identifiants disponibles afin qu’un groupe puisse être interprété par une personne ou par une étape ultérieure de l’application. Un groupe est un regroupement fondé sur la représentation, et non une description d’architecture vérifiée automatiquement.
Les exemples de vecteurs à virgule flottante du fabricant utilisent des plongements normalisés à une norme unitaire, pour lesquels la similarité cosinus, le produit scalaire et la distance euclidienne donnent des classements cohérents. Les sorties quantifiées et à bits compactés doivent conserver leur propre gestion de format, plutôt que d’hériter d’une hypothèse sur des coordonnées flottantes brutes. Le point d’accès publié conserve aussi les indices d’entrée, ce qui aide à préserver le lien entre chaque vecteur et son élément source.
Édition et limites pratiques
La page exacte du modèle répertorie les processus de plongement et de traitement par lots avec une indication de contexte de 8k, tandis que la publication donne la valeur de 8192 tokens. Préservez l’édition nommée 2505, la dimension de sortie et le type choisis tout au long du processus de collection et de requête. Il s’agit d’une sortie vectorielle orientée code, distincte de la complétion textuelle de Codestral et du modèle textuel Mistral Embed à dimensions fixes.
Préparez des unités de code portant le comportement pertinent, gardez leurs emplacements sources et énoncez la question à résoudre par la recherche. L’artefact utile est une représentation retrouvable liée à du code réel, qui aide l’étape suivante d’explication, de modification ou de vérification par un développeur sans effectuer elle-même cette étape.
", "aboutText": "Codestral Embed 2505 est le modèle de plongement de Mistral AI spécialisé dans la recherche de code. Il reçoit du texte contenant du code source ou une requête de code en langue naturelle et renvoie des vecteurs numériques. Le fabricant le positionne pour la recherche dans les dépôts, la recherche de contexte pour les assistants de programmation, l’analyse de similarité et de doublons, ainsi que le regroupement du code selon sa fonctionnalité ou sa structure. Son identifiant de publication fixe est codestral-embed-2505.\n\nEntrée et représentation\n\nUne entrée de code peut être une fonction, un fragment source lié ou une autre unité porteuse de sens d’un dépôt. Une requête en langue naturelle peut décrire le comportement à trouver, plutôt que de nommer le symbole exact. Le plongement représente cette entrée pour la comparaison ; le modèle ne génère pas de nouvelle implémentation et n’exécute pas le code qu’il reçoit.\n\nLa publication officielle documente un contexte d’entrée complet de 8192 tokens. Pour la recherche, le fabricant recommande des segments d’environ 3000 caractères avec un chevauchement de 1000 caractères, en précisant que des segments plus grands peuvent nuire à la recherche. Ce sont des recommandations de préparation pour la recherche, plutôt qu’une limite en tokens de 3000 caractères. Gardez le fichier, le symbole et l’emplacement source associés à chaque élément préparé, afin que l’application puisse renvoyer le code pertinent après la recherche.\n\nPrécision de sortie et dimensions\n\nLe guide de plongement de code documente les types de sortie float, int8, uint8, binary et ubinary. Float utilise des valeurs à simple précision de 32 bits. Int8 utilise des entiers signés de 8 bits, de -128 à 127, tandis que uint8 utilise des valeurs non signées de 8 bits, de 0 à 255. Binary et ubinary stockent des valeurs quantifiées d’un seul bit dans des éléments compactés de 8 bits, avec des conteneurs respectivement signés et non signés.\n\nLa représentation à bits compactés modifie la longueur de la liste renvoyée : le guide décrit un élément compacté pour huit dimensions logiques de plongement. Une comparaison tenant compte du format diffère donc d’un traitement des octets compactés comme des coordonnées ordinaires à virgule flottante. Préservez le type choisi avec le vecteur et utilisez la même représentation pour le code indexé et sa requête.\n\nLa documentation des paramètres donne une dimension par défaut de 1536 et un maximum de 3072. Les dimensions sont ordonnées par pertinence, et le fabricant décrit la conservation du nombre choisi de premières dimensions comme un moyen de sélectionner la taille de représentation. Choisissez la dimension de manière cohérente pour la collection stockée et les nouvelles requêtes. Une représentation plus courte ou quantifiée modifie le stockage et le comportement de comparaison ; elle n’augmente pas le contexte d’entrée et ne transforme pas le modèle en générateur de code.\n\nProgrammation augmentée par la recherche\n\nLe premier cas d’usage de la publication est la recherche de contexte pour la complétion, la modification ou l’explication de code. Préparez des unités de code porteuses de sens et conservez la révision du dépôt et les identifiants sources. Une question sur la gestion d’une erreur particulière peut retrouver des fonctions liées, que l’application fournit ensuite à un modèle de programmation avec la demande réelle de modification.\n\nUn résultat concret est un ensemble classé d’extraits sources comprenant les chemins de fichiers, les symboles et le contenu nécessaire à la compréhension de leur comportement. Les extraits retrouvés peuvent être ouverts par un développeur ou transmis à un assistant. Codestral Embed effectue l’étape de représentation ; un composant distinct sélectionne les résultats, et un modèle de génération rédige l’explication ou le code proposé.\n\nRecherche sémantique et similarité\n\nLe fabricant décrit la recherche de code au moyen de requêtes en langue naturelle ou en code. Un développeur peut demander l’implémentation d’un comportement, même lorsque le nom de la fonction diffère de la formulation de la demande. Incluez le comportement et les conditions qui distinguent l’implémentation visée ; une requête générale sur un sous-système entier peut retrouver du matériau lié sans résoudre la question précise.\n\nLa publication décrit aussi la recherche de code presque identique ou fonctionnellement similaire malgré des différences lexicales. De tels résultats peuvent aider à trouver une implémentation réutilisable ou à repérer du code nécessitant une vérification approfondie. La similarité dans l’espace de plongement est un signal invitant à examiner la source ; elle n’établit pas que deux fragments ont un comportement identique pour toutes les entrées.\n\nRegroupement, analyse et comparaison\n\nLes plongements de code peuvent servir à regrouper le code par fonctionnalité ou par structure et à examiner la composition d’un dépôt. Gardez les extraits d’origine et les identifiants disponibles afin qu’un groupe puisse être interprété par une personne ou par une étape ultérieure de l’application. Un groupe est un regroupement fondé sur la représentation, et non une description d’architecture vérifiée automatiquement.\n\nLes exemples de vecteurs à virgule flottante du fabricant utilisent des plongements normalisés à une norme unitaire, pour lesquels la similarité cosinus, le produit scalaire et la distance euclidienne donnent des classements cohérents. Les sorties quantifiées et à bits compactés doivent conserver leur propre gestion de format, plutôt que d’hériter d’une hypothèse sur des coordonnées flottantes brutes. Le point d’accès publié conserve aussi les indices d’entrée, ce qui aide à préserver le lien entre chaque vecteur et son élément source.\n\nÉdition et limites pratiques\n\nLa page exacte du modèle répertorie les processus de plongement et de traitement par lots avec une indication de contexte de 8k, tandis que la publication donne la valeur de 8192 tokens. Préservez l’édition nommée 2505, la dimension de sortie et le type choisis tout au long du processus de collection et de requête. Il s’agit d’une sortie vectorielle orientée code, distincte de la complétion textuelle de Codestral et du modèle textuel Mistral Embed à dimensions fixes.\n\nPréparez des unités de code portant le comportement pertinent, gardez leurs emplacements sources et énoncez la question à résoudre par la recherche. L’artefact utile est une représentation retrouvable liée à du code réel, qui aide l’étape suivante d’explication, de modification ou de vérification par un développeur sans effectuer elle-même cette étape.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "d5a52a6e4235f36aa8a677483648454fe6cad762fefbec4e059ce74ece36d991", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr", "methods": [ { "html": "mistralai/codestral-embed-2505Codestral Embed 2505 représente le code et les requêtes en langue naturelle sous forme de vecteurs pour la recherche dans les dépôts et la recherche d’information des assistants de programmation. Son fabricant documente un contexte de 8192 tokens, des dimensions configurables jusqu’à 3072 et des formats de sortie à virgule flottante, entiers ou à bits compactés.
Cette description présente les capacités du modèle. Les entrées, sorties et options disponibles dans Ailoot pour la méthode sélectionnée figurent ci-dessous.
Codestral Embed 2505 est le modèle de plongement de Mistral AI spécialisé dans la recherche de code. Il reçoit du texte contenant du code source ou une requête de code en langue naturelle et renvoie des vecteurs numériques. Le fabricant le positionne pour la recherche dans les dépôts, la recherche de contexte pour les assistants de programmation, l’analyse de similarité et de doublons, ainsi que le regroupement du code selon sa fonctionnalité ou sa structure. Son identifiant de publication fixe est codestral-embed-2505.
Entrée et représentation
Une entrée de code peut être une fonction, un fragment source lié ou une autre unité porteuse de sens d’un dépôt. Une requête en langue naturelle peut décrire le comportement à trouver, plutôt que de nommer le symbole exact. Le plongement représente cette entrée pour la comparaison ; le modèle ne génère pas de nouvelle implémentation et n’exécute pas le code qu’il reçoit.
La publication officielle documente un contexte d’entrée complet de 8192 tokens. Pour la recherche, le fabricant recommande des segments d’environ 3000 caractères avec un chevauchement de 1000 caractères, en précisant que des segments plus grands peuvent nuire à la recherche. Ce sont des recommandations de préparation pour la recherche, plutôt qu’une limite en tokens de 3000 caractères. Gardez le fichier, le symbole et l’emplacement source associés à chaque élément préparé, afin que l’application puisse renvoyer le code pertinent après la recherche.
Précision de sortie et dimensions
Le guide de plongement de code documente les types de sortie float, int8, uint8, binary et ubinary. Float utilise des valeurs à simple précision de 32 bits. Int8 utilise des entiers signés de 8 bits, de -128 à 127, tandis que uint8 utilise des valeurs non signées de 8 bits, de 0 à 255. Binary et ubinary stockent des valeurs quantifiées d’un seul bit dans des éléments compactés de 8 bits, avec des conteneurs respectivement signés et non signés.
La représentation à bits compactés modifie la longueur de la liste renvoyée : le guide décrit un élément compacté pour huit dimensions logiques de plongement. Une comparaison tenant compte du format diffère donc d’un traitement des octets compactés comme des coordonnées ordinaires à virgule flottante. Préservez le type choisi avec le vecteur et utilisez la même représentation pour le code indexé et sa requête.
La documentation des paramètres donne une dimension par défaut de 1536 et un maximum de 3072. Les dimensions sont ordonnées par pertinence, et le fabricant décrit la conservation du nombre choisi de premières dimensions comme un moyen de sélectionner la taille de représentation. Choisissez la dimension de manière cohérente pour la collection stockée et les nouvelles requêtes. Une représentation plus courte ou quantifiée modifie le stockage et le comportement de comparaison ; elle n’augmente pas le contexte d’entrée et ne transforme pas le modèle en générateur de code.
Programmation augmentée par la recherche
Le premier cas d’usage de la publication est la recherche de contexte pour la complétion, la modification ou l’explication de code. Préparez des unités de code porteuses de sens et conservez la révision du dépôt et les identifiants sources. Une question sur la gestion d’une erreur particulière peut retrouver des fonctions liées, que l’application fournit ensuite à un modèle de programmation avec la demande réelle de modification.
Un résultat concret est un ensemble classé d’extraits sources comprenant les chemins de fichiers, les symboles et le contenu nécessaire à la compréhension de leur comportement. Les extraits retrouvés peuvent être ouverts par un développeur ou transmis à un assistant. Codestral Embed effectue l’étape de représentation ; un composant distinct sélectionne les résultats, et un modèle de génération rédige l’explication ou le code proposé.
Recherche sémantique et similarité
Le fabricant décrit la recherche de code au moyen de requêtes en langue naturelle ou en code. Un développeur peut demander l’implémentation d’un comportement, même lorsque le nom de la fonction diffère de la formulation de la demande. Incluez le comportement et les conditions qui distinguent l’implémentation visée ; une requête générale sur un sous-système entier peut retrouver du matériau lié sans résoudre la question précise.
La publication décrit aussi la recherche de code presque identique ou fonctionnellement similaire malgré des différences lexicales. De tels résultats peuvent aider à trouver une implémentation réutilisable ou à repérer du code nécessitant une vérification approfondie. La similarité dans l’espace de plongement est un signal invitant à examiner la source ; elle n’établit pas que deux fragments ont un comportement identique pour toutes les entrées.
Regroupement, analyse et comparaison
Les plongements de code peuvent servir à regrouper le code par fonctionnalité ou par structure et à examiner la composition d’un dépôt. Gardez les extraits d’origine et les identifiants disponibles afin qu’un groupe puisse être interprété par une personne ou par une étape ultérieure de l’application. Un groupe est un regroupement fondé sur la représentation, et non une description d’architecture vérifiée automatiquement.
Les exemples de vecteurs à virgule flottante du fabricant utilisent des plongements normalisés à une norme unitaire, pour lesquels la similarité cosinus, le produit scalaire et la distance euclidienne donnent des classements cohérents. Les sorties quantifiées et à bits compactés doivent conserver leur propre gestion de format, plutôt que d’hériter d’une hypothèse sur des coordonnées flottantes brutes. Le point d’accès publié conserve aussi les indices d’entrée, ce qui aide à préserver le lien entre chaque vecteur et son élément source.
Édition et limites pratiques
La page exacte du modèle répertorie les processus de plongement et de traitement par lots avec une indication de contexte de 8k, tandis que la publication donne la valeur de 8192 tokens. Préservez l’édition nommée 2505, la dimension de sortie et le type choisis tout au long du processus de collection et de requête. Il s’agit d’une sortie vectorielle orientée code, distincte de la complétion textuelle de Codestral et du modèle textuel Mistral Embed à dimensions fixes.
Préparez des unités de code portant le comportement pertinent, gardez leurs emplacements sources et énoncez la question à résoudre par la recherche. L’artefact utile est une représentation retrouvable liée à du code réel, qui aide l’étape suivante d’explication, de modification ou de vérification par un développeur sans effectuer elle-même cette étape.
POST /v1/embeddingstext, token_idsembedding| Champ | Type | Exigence | Valeurs et limites | Par défaut |
|---|---|---|---|---|
Champmodel | Typestring | ExigenceObligatoire | Valeurs et limites mistralai/codestral-embed-2505 | Par défaut— |
Champinput | Typestring|string[]|integer[]|integer[][] | ExigenceObligatoire | Valeurs et limites Nombre minimal d’éléments: 1 Conditions: Lot homogène non vide. Les identifiants de jetons sont des entiers positifs ou nuls. Budget d’entrée : Maximum: 8 192 · Unité de texte: octets UTF8 · Unité de tokens: éléments du tableau de tokens | Par défaut— |
Champencoding_format | Typestring | ExigenceFacultatif | Valeurs et limites float | Par défautfloat |
Champdimensions | Typeinteger | ExigenceNon pris en charge | Valeurs et limites Minimum: 1 | Par défaut— |
Champuser | Typejson_value | ExigenceFacultatif | Valeurs et limites Conditions: Source autorise ce champ de métadonnées JSON ; sa sémantique exacte en amont dépend du modèle. | Par défaut— |
Champsession_id | Typejson_value | ExigenceFacultatif | Valeurs et limites Conditions: Source autorise ce champ de métadonnées JSON ; sa sémantique exacte en amont dépend du modèle. | Par défaut— |
Champtrace | Typejson_value | ExigenceFacultatif | Valeurs et limites Conditions: Source autorise ce champ de métadonnées JSON ; sa sémantique exacte en amont dépend du modèle. | Par défaut— |
Champprovider | Typeobject | ExigenceFacultatif | Valeurs et limites Conditions: provider.options est refusé | Par défaut— |
text_to_embedding
| Paramètre | Contrat |
|---|---|
Paramètrecontent_type | Contratapplication/json |
Paramètrerequired | Contratmodel, input |
Paramètreinput_shapes | Contratstring, string[], nonnegative_integer_token_array, nonnegative_integer_token_array[] |
Paramètreencoding_format | Contratfloat |
Paramètredimensions_override | Contratfalse |
Paramètremax_input_budget_units | Contrat8192 |
Paramètremultimodal_objects | Contratfalse |
Paramètrematerial_types | Contrattext, token_ids |
Cycle de vie : synchronous_json
Conservez tous les indices et toutes les dimensions des vecteurs.
Un nom de modèle multimodal n’autorise pas les objets image sur ce chemin précis.
Les tarifs n’ajoutent pas d’options de requête. Les paramètres pris en charge figurent dans la méthode sélectionnée.
| Configuration | Barème tarifaire | Coût |
|---|---|---|
| ConfigurationTarifs de base des tokens | Barème tarifaireTarif de base | Coût Entrée · Tokens en entrée $0.0003 / 1K tokens Sortie · Tokens en sortie $0 / 1K tokens Entrée · Lecture du cache — / 1K tokens Entrée · Écriture dans le cache — / 1K tokens Entrée · Écriture dans le cache, 1 h — / 1K tokens |
Ailoot réserve un montant estimé avant une requête. Après le résultat, le montant final est débité selon l’utilisation mesurée. Pour le streaming, le montant final à débiter est calculé à partir du relevé final d’utilisation. Fonctionnement de la réservation et du débit →
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": "mistralai/codestral-embed-2505", "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='mistralai/codestral-embed-2505',input=["First document","Second document"])\nprint(result)\nfor item in result.data:print(item.index,item.embedding)\njson
Conservez chaque réponse, fichier et partie de contenu renvoyés dans leur intégralité.
Conservez chaque vecteur avec son indice. Le nombre de vecteurs doit être égal au nombre d’entrées ; les dimensions doivent être cohérentes.
Aucun point de terminaison dédié aux tâches d’embedding n’est ajouté.
| Champ | Type |
|---|---|
Champobject | Typestring |
Champmodel | Typestring |
Champdata[].index | Typeinteger |
Champdata[].embedding | Typefinite float[] |
Champusage | Typeobject |
| Réponse | Condition | Étape suivante |
|---|---|---|
Réponse400 · invalid_request_error | ConditionChamps obligatoires, représentation des contenus ou valeur de paramètre non valides | Étape suivanteCorrigez les champs indiqués avant une nouvelle requête de création. |
Ailoot Ultra mistralai/codestral-embed-2505
Utilisez les chemins de méthode indiqués ci-dessus.