Paramètres de l'API de LLM : des champs de requête aux champs de réponse

À quoi ressemble une requête

L'endpoint est POST https://api.apidamoxing.com/v1/chat/completions, l'en-tête d'authentification est Authorization: Bearer <key>, le corps de la requête est au format JSON et est compatible avec le format de complétion de chat d'OpenAI. Voici un exemple de requête complète utilisant les champs courants :

复制curl https://api.apidamoxing.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [
      {"role": "system", "content": "你是一位耐心的天文科普作者。"},
      {"role": "user", "content": "为什么月亮总是同一面朝向地球？"}
    ],
    "temperature": 0.7,
    "top_p": 0.9,
    "max_tokens": 400,
    "stop": ["###"]
  }'

Notez que model doit être rempli avec uncensored, car le service ne propose qu'un seul modèle sans autres options. Vous pouvez le vérifier avec GET /v1/models. Nous expliquons les champs un par un ci-dessous.

Les paramètres se classent en trois catégories : « quoi dire » (messages, tools), « comment le dire » (temperature, top_p), « dire combien et quand » (max_tokens, stop, stream).

messages : le « carnet de notes » de la conversation

messages est un tableau avec role et content. Imaginez un compte-rendu : le modèle relit tout à chaque tour. Il ne se souvient pas de lui-même ; vous devez fournir l'historique complet.

Une astuce courante : pour que le modèle continue d'écrire dans un certain ton, vous pouvez construire vous-même un message assistant à ajouter à l'historique. Notez que la somme du prompt et de la sortie ne doit pas dépasser 100,000 token ; plus l'historique est long, plus il occupe d'espace.

Prenons un exemple concret. Vous créez un assistant de service client avec le prompt system « Répondez uniquement aux questions liées aux commandes, en trois phrases maximum ». L'utilisateur demande d'abord le délai de livraison, puis demande « Et pour les retours ? » lors de la deuxième question. La deuxième requête doit inclure successivement : system, le message user de la première question, la réponse assistant du modèle pour la première question, et le message user de la deuxième question. S'il manque l'un de ces éléments, le modèle ne saura pas à quoi « les retours » fait référence.

Paramètres d'échantillonnage : ajuster la « marge de manœuvre »

Lors de la génération de chaque token, le modèle attribue d'abord une probabilité à tous les candidats, puis procède à un tirage au sort. Les deux paramètres suivants sont des boutons pour ajuster les règles de ce tirage :

Les deux contrôlent le niveau de « hasard », mais sous des angles différents. Il est difficile d'isoler l'effet de l'un ou de l'autre si vous les réglez simultanément ; il est donc conseillé de n'en modifier qu'un à la fois. Ces champs de sampling standard sont transmis tels quels ; l'interface ne les réécrit pas.

Prenons un exemple numérique : supposons que les trois candidats les plus probables aient des probabilités de 60 %, 30 % et 10 %. Baisser temperature favorise davantage le candidat à 60 %, rendant la sortie plus similaire à un choix systématique du premier candidat ; l'augmenter rapproche les probabilités, facilitant le tirage des candidats moins probables. Avec top_p à 0,9, seuls les deux premiers candidats (cumulant 90 %) sont conservés ; le troisième est éliminé. Ces chiffres sont des hypothèses illustratives, pas des probabilités réelles.

Contrôle de la longueur et des arrêts : max_tokens, stop, stream

max_tokens agit comme la taille d’une assiette : si l’assiette est trop petite, le service est interrompu avant la fin, et finish_reason vaudra length. stop fonctionne comme un signal convenu : le modèle s’arrête dès qu’il le reçoit. stream ne modifie pas le contenu, seulement le mode de livraison : au lieu d’attendre que tout soit prêt, le contenu est envoyé morceau par morceau, ce qui donne à l’utilisateur une impression de réponse plus rapide.

Une utilisation pratique de stop : si vous demandez au modèle de respecter un format fixe « Question : … Réponse : …### », définir ### comme valeur de stop permet d’arrêter automatiquement la génération à ce séparateur. Cela économise des tokens et évite les digressions. Notez que lorsque stop est déclenché, finish_reason vaut également stop ; si vous devez distinguer les cas, vérifiez manuellement le contenu.

tools et tool_choice : permettre au modèle de « vous appeler »

Le modèle n’a pas accès aux données en temps réel. La méthode function calling consiste à lui indiquer quelles fonctions sont disponibles. Lorsqu’il en a besoin, il ne répond pas directement, mais retourne une demande « Appeler la fonction X avec les paramètres Y ». Votre programme exécute la fonction et renvoie le résultat ; le modèle l’utilise ensuite pour formuler sa réponse. Le format est compatible avec OpenAI.

复制import json
import os
from openai import OpenAI

client = OpenAI(base_url="https://api.apidamoxing.com/v1", api_key=os.environ["API_KEY"])

tools = [{
    "type": "function",
    "function": {
        "name": "get_tide_time",
        "description": "查询某港口今天的高潮时刻",
        "parameters": {
            "type": "object",
            "properties": {"port": {"type": "string", "description": "港口名称"}},
            "required": ["port"],
        },
    },
}]

messages = [{"role": "user", "content": "青岛今天几点涨潮？"}]
first = client.chat.completions.create(
    model="uncensored", messages=messages, tools=tools, tool_choice="auto"
)
msg = first.choices[0].message

if msg.tool_calls:
    call = msg.tool_calls[0]
    args = json.loads(call.function.arguments)
    result = {"port": args["port"], "high_tide": "14:20"}   # 这里换成你自己的查询
    messages.append(msg)
    messages.append({"role": "tool", "tool_call_id": call.id, "content": json.dumps(result, ensure_ascii=False)})
    final = client.chat.completions.create(model="uncensored", messages=messages, tools=tools)
    print(final.choices[0].message.content)
else:
    print(msg.content)

Le processus se fait en deux étapes : la première étape retourne tool_calls ; la deuxième étape ajoute le résultat avec role: tool à la suite, puis effectue la requête. Plus la description est précise, mieux le modèle sait quand appeler. Les paramètres sont une chaîne JSON ; utilisez json.loads pour les analyser et les valider, et ne leur faites pas aveuglément confiance.

Champs de réponse : comprendre le « reçu »

Une réponse réussie ressemble généralement à ceci, avec des champs fixes :

复制{
  "id": "chatcmpl-xxxx",
  "object": "chat.completion",
  "model": "uncensored",
  "choices": [
    {
      "index": 0,
      "message": {"role": "assistant", "content": "因为潮汐锁定……"},
      "finish_reason": "stop"
    }
  ],
  "usage": {"prompt_tokens": 38, "completion_tokens": 212, "total_tokens": 250}
}

Voyez finish_reason : length pour tronquer ou continuer ; tool_calls pour exécuter. Pour l'usage, voyez token & facturation.

Erreurs courantes sur les paramètres

• Considérez max_tokens comme une « limite de sortie ». Il ne contrôle que la sortie ; l'entrée est sous votre contrôle.
• Penser que le modèle se souvient de la requête précédente : chaque requête est indépendante ; c’est à vous de gérer l’historique.
• Définir temperature à 0 ne signifie pas que les résultats seront strictement identiques à chaque fois. Cela rendra le modèle plus stable, mais il ne faut pas supposer une concordance mot à mot.
• Lire directement choices[0].message en mode streaming : les blocs contiennent des delta ; vous devez les assembler vous-même.
• Oublier d’ajouter le message assistant contenant tool_calls après un appel tool, ce qui provoque une erreur à l’étape suivante.

Les significations des codes d'erreur et les stratégies de nouvelle tentative sont décrites dans la documentation. Pour un exemple complet intégrant ces paramètres, consultez l'article Création d'un chatbot.