Créer une requête de conversation de chat
Grands modèles de langage
Créer une requête de conversation de chat
POST
Créer une requête de conversation de chat
Génère une réponse du modèle en fonction de la conversation de chat spécifiée
En-têtes de requête
Valeurs d’énumération :
application/jsonFormat d’authentification Bearer : Bearer {{API Key}}.
Corps de la requête
Nom du modèle à utiliser.
Liste des messages qui composent la conversation actuelle.
Nombre maximal de tokens générés dans la complétion.Si votre prompt (messages précédents) plus le nombre de tokens de max_tokens dépasse la longueur de contexte du modèle, le comportement dépend de context_length_exceeded_behavior. Par défaut, max_tokens sera réduit pour s’adapter à la fenêtre de contexte, plutôt que de renvoyer une erreur.
Indique s’il faut renvoyer la progression partielle en streaming. Si ce paramètre est défini, les tokens seront envoyés sous forme d’événements serveur (SSE) réservés aux données à mesure qu’ils deviennent disponibles, et le flux se terminera par un message
data: [DONE].Options de la réponse en streaming. Définissez cet élément uniquement lorsque stream est défini sur true.
Nombre de complétions générées pour chaque prompt.Remarque : comme ce paramètre génère de nombreuses complétions, il peut consommer rapidement votre quota de tokens. Utilisez-le avec prudence et assurez-vous d’avoir des paramètres raisonnables pour max_tokens et stop.Plage requise :
1 < x < 128Si spécifié, notre système fera de son mieux pour échantillonner de manière déterministe, de sorte que des requêtes répétées avec le même seed et les mêmes paramètres devraient renvoyer le même résultat.
Les valeurs positives pénalisent les nouveaux tokens en fonction de leur fréquence existante dans le texte, réduisant la probabilité que le modèle répète mot pour mot les mêmes lignes.Si l’objectif est simplement de réduire légèrement les échantillons répétitifs, des valeurs raisonnables se situent entre 0.1 et 1. Si l’objectif est de fortement supprimer les répétitions, le coefficient peut être augmenté à 2, mais cela peut réduire sensiblement la qualité de l’échantillon. Les valeurs négatives peuvent être utilisées pour augmenter la probabilité de répétition.Voir aussi presence_penalty, utilisé pour pénaliser à un taux fixe les tokens apparaissant au moins une fois.Plage requise :
-2 < x < 2Les valeurs positives pénalisent les nouveaux tokens selon qu’ils apparaissent ou non dans le texte, augmentant la probabilité que le modèle aborde de nouveaux sujets.Si l’objectif est simplement de réduire légèrement les échantillons répétitifs, des valeurs raisonnables se situent entre 0.1 et 1. Si l’objectif est de fortement supprimer les répétitions, le coefficient peut être augmenté à 2, mais cela peut réduire sensiblement la qualité de l’échantillon. Les valeurs négatives peuvent être utilisées pour augmenter la probabilité de répétition.Voir aussi
frequency_penalty, utilisé pour pénaliser les tokens à un taux croissant en fonction de leur fréquence d’apparition.Plage requise : -2 < x < 2Applique une pénalité aux tokens répétés afin de décourager ou d’encourager la répétition. Une valeur de 1.0 signifie qu’il n’y a pas de pénalité et que la répétition est libre. Les valeurs supérieures à 1.0 pénalisent la répétition et réduisent la probabilité des tokens répétés. Les valeurs comprises entre 0.0 et 1.0 récompensent la répétition et augmentent la probabilité de tokens répétés. Pour obtenir un bon équilibre, une valeur de 1.2 est généralement recommandée. Notez que la pénalité s’applique à la sortie générée ainsi qu’au prompt dans les modèles à décodeur seul.Plage requise :
0 < x < 2Jusqu’à 4 séquences pour lesquelles l’API cessera de générer des tokens supplémentaires. Le texte renvoyé inclura la séquence d’arrêt.
Température d’échantillonnage à utiliser, comprise entre 0 et 2. Des valeurs plus élevées comme 0.8 rendent la sortie plus aléatoire, tandis que des valeurs plus faibles comme 0.2 la rendent plus ciblée et déterministe.Nous recommandons généralement de modifier ce paramètre ou
top_p, mais pas les deux en même temps.Plage requise : 0 < x < 2Une méthode alternative à la température d’échantillonnage, appelée échantillonnage par noyau, dans laquelle le modèle considère les résultats des tokens ayant une masse de probabilité top_p. Ainsi, 0.1 signifie que seuls les tokens constituant les 10 % supérieurs de la masse de probabilité sont pris en compte. Nous recommandons généralement de modifier ce paramètre ou la température, mais pas les deux en même temps.Plage requise :
0 < x <= 1L’échantillonnage Top-k est une autre méthode d’échantillonnage dans laquelle les k prochains tokens les plus probables sont filtrés, et la masse de probabilité est redistribuée uniquement entre ces k prochains tokens. La valeur de k contrôle le nombre de candidats pour le prochain token à chaque étape de la génération de texte.Plage requise :
1 < x < 128Représente la probabilité minimale pour qu’un token soit pris en compte, par rapport à la probabilité du token le plus probable.Plage requise :
0 <= x <= 1Modifie la probabilité que les tokens spécifiés apparaissent dans la complétion.Accepte un objet JSON qui mappe des tokens à des valeurs de biais associées comprises entre -100 et 100.
Mathématiquement, le biais est ajouté aux logits générés par le modèle avant l’échantillonnage. L’effet exact varie selon le modèle.Par exemple, définir
"logit_bias":{"1024": 6} augmentera la probabilité des tokens dont l’ID de token est 1024.Indique s’il faut renvoyer les probabilités logarithmiques des tokens de sortie. Si true, les probabilités logarithmiques de chaque token de sortie dans le contenu du message sont renvoyées.
Un entier compris entre 0 et 20 qui spécifie le nombre de tokens les plus probables à renvoyer à chaque position de token, chacun avec une probabilité logarithmique associée. Si ce paramètre est utilisé,
logprobs doit être défini sur true.Plage requise : 0 <= x <= 20Liste des outils que le modèle peut appeler. Actuellement, seules les fonctions sont prises en charge comme outils. Utilisez cet élément pour fournir la liste des fonctions pour lesquelles le modèle peut générer des entrées JSON.En savoir plus sur l’appel de fonctions dans le guide d’appel de fonctions.
Permet de forcer le modèle à générer un format de sortie spécifique.Définir sur
{ "type": "json_schema", "json_schema": {...} } active les sorties structurées, garantissant que le modèle correspondra au JSON schema que vous fournissez.Définir sur { "type": "json_object" } active l’ancien mode JSON, garantissant que le message généré par le modèle est un JSON valide. Pour les modèles qui le prennent en charge, il est recommandé d’utiliser json_schema.Indique s’il faut séparer le raisonnement de “content” dans le champ “reasoning_content”.Modèles pris en charge :
deepseek/deepseek-r1-turbo
Contrôle le basculement entre les modes réflexion et non-réflexion.Modèles pris en charge :
zai-org/glm-4.5
Informations de réponse
Liste des options de complétion de chat.
Heure Unix (en secondes) à laquelle la réponse a été générée.
Identifiant unique de la réponse.
Modèle utilisé pour la complétion de chat.
Type d’objet, toujours
chat.completion.Statistiques d’utilisation.Pour les réponses en streaming, le champ usage est inclus dans le dernier bloc de réponse renvoyé.