Detaillierte API-Parameter für LLMs: Von Anfrage- zu Antwortfeldern

Wie sieht eine Anfrage aus

Die Endpunkt-URL ist POST https://api.apidamoxing.com/v1/chat/completions, der Auth-Header ist Authorization: Bearer <key>. Der Request-Body ist JSON und OpenAI-kompatibel. Siehe hier eine vollständige Anfrage mit allen wichtigen Feldern:

复制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": ["###"]
  }'

Achte darauf, dass model nur uncensored sein darf, da es nur dieses Modell gibt. Bestätige dies über GET /v1/models. Im Folgenden erklären wir die Felder einzeln.

Du wirst feststellen, dass sich die Parameter in drei Kategorien einteilen lassen: „Was gesagt wird“ (messages, tools), „Wie es gesagt wird“ (temperature, top_p) und „Wie viel und wann gestoppt wird“ (max_tokens, stop, stream). Nutze diese Einteilung, um auch unbekannte Felder schnell einordnen zu können.

messages: Das Protokoll dieses Chats

messages ist ein Array mit Elementen, die role und content enthalten. Stell dir das als ein Protokollbuch vor, das das Modell bei jeder Antwort neu liest und fort schreibt. Es merkt sich nichts, daher musst du den gesamten Verlauf bei mehrstufigen Dialogen selbst mitschicken.

Ein gängiger Trick: Wenn du das Modell in einem bestimmten Stil weiterschreiben lassen willst, füge eine assistant-Nachricht in den Verlauf ein. Achte darauf, dass die Summe aus Prompt und Ausgabe 100.000 Token nicht überschreitet; je länger der Verlauf, desto mehr Platz belegt er.

Ein konkretes Beispiel: Du baust einen Kundenservice-Assistenten und schreibst in das system-Feld: „Beantworte nur Fragen zu Bestellungen, maximal drei Sätze.“ Der Nutzer fragt in Runde 1 nach der Lieferzeit und in Runde 2: „Und die Rückgabe?“ Die messages in der zweiten Anfrage müssen nacheinander enthalten: system, user aus Runde 1, assistant-Antwort des Modells aus Runde 1, user aus Runde 2. Fehlt eine, weiß das Modell nicht, worauf sich „Und“ bezieht.

Sampling-Parameter: Den Spielraum steuern

Das Modell weist jedem Kandidatenbuchstaben vor der Auswahl eine Punktzahl zu. Die folgenden zwei Parameter sind die Regler zur Anpassung dieser Auswahl:

Beide steuern die „Zufälligkeit“, nur aus unterschiedlichen Perspektiven. Es ist schwer, den Effekt zu isolieren, wenn du beide gleichzeitig änderst, also ändere immer nur einen. Diese Standard-Sampling-Felder werden unverändert an die API weitergegeben.

Ein anschauliches Zahlenbeispiel: Nehmen wir an, die drei wahrscheinlichsten nächsten Wörter des Modells haben die Wahrscheinlichkeiten 60 %, 30 % und 10 %. Ein niedrigeres temperature lässt das Wort mit 60 % noch dominanter erscheinen; die Ausgabe ähnelt dann immer stärker dem ständigen Auswählen des ersten Wortes. Ein höheres temperature gleicht die Wahrscheinlichkeiten an, sodass auch seltene Wörter wahrscheinlicher gezogen werden. Bei einem top_p von 0,9 bleiben nur die ersten beiden Wörter, deren kumulative Wahrscheinlichkeit 90 % erreicht, das dritte Wort fällt weg. Diese Zahlen dienen nur der Veranschaulichung des Prinzips und entsprechen nicht echten Wahrscheinlichkeiten.

Länge und Stopp steuern: max_tokens, stop, stream

max_tokens ist wie die Größe eines Tellers: Ist der Teller zu klein, wird das Essen abgehoben, bevor es vollständig serviert ist; finish_reason lautet dann length. stop funktioniert wie ein verabredetes Signal: Der Koch hört auf, sobald er das Signal hört. stream ändert nicht den Inhalt, sondern nur die Art der Zustellung: Statt „Alles fertig servieren“ wird „Ein Bissen nach dem anderen“ geliefert, was für den Nutzer schneller wirkt.

stop hat eine sehr praktische Anwendung: Wenn du das Modell in einem festen Format wie „Frage: … Antwort: …###“ ausgeben lässt, kannst du ### als stop-Parameter setzen. Die Generierung stoppt automatisch am Trennzeichen, spart Token und verhindert unnötigen Plapper. Beachte: Bei einem Treffer ist finish_reason ebenfalls „stop“. Wenn du unterscheiden musst, prüfe den Inhalt selbst.

tools und tool_choice: Das Modell „ruft an“, um Sie zu fragen

Das Modell hat keinen Zugriff auf Echtzeitdaten. Bei Function Calling geben Sie dem Modell zunächst bekannt, welche Funktionen verfügbar sind. Wenn das Modell eine Funktion benötigt, antwortet es nicht direkt, sondern gibt eine Aufforderung zurück, eine bestimmte Funktion mit bestimmten Parametern aufzurufen. Ihr Programm führt die Funktion aus und übergibt das Ergebnis zurück an das Modell, das daraufhin die Antwort formuliert. Das Format ist mit OpenAI kompatibel.

复制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)

Der Ablauf erfolgt in zwei Schritten: Im ersten Schritt erhalten Sie tool_calls. Im zweiten Schritt hängen Sie die Antwort mit der role tool an und senden die Anfrage erneut. Je genauer die Beschreibung ist, desto besser weiß das Modell, wann es die Funktion aufrufen soll. Die Parameter sind JSON-Strings; verwenden Sie unbedingt json.loads zur Analyse und Validierung und vertrauen Sie den Daten nicht blind.

Antwortfelder: Verstehen Sie die „Quittung“ der Antwort

Eine erfolgreiche Antwort sieht in etwa so aus; die Felder sind fest definiert:

复制{
  "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}
}

Im Code prüfst du zuerst finish_reason: Bei length weist du den Nutzer auf die Abschneidung hin oder schreibst automatisch fort; bei tool_calls folgst du dem Zweig für die Funktionsausführung. Die Rolle von usage wird im Artikel Token und Abrechnung mit einer detaillierteren Budgetmethode erläutert.

Die häufigsten Fallstricke bei den Parametern

• Stell dir max_tokens als „Obergrenze für die Ausgabe“ vor. Es betrifft nur die Ausgabe, den Input steuerst du selbst.
• Glauben, das Modell erinnere sich an die vorherige Anfrage. Jede Anfrage ist unabhängig; der Kontext muss selbst mitgegeben werden.
• Ein Temperaturwert von 0 sorgt dafür, dass das Ergebnis jedes Mal identisch ist. Das ist stabiler, aber es ist nicht anzunehmen, dass jedes Zeichen immer exakt übereinstimmt.
• Lies im Streaming-Modus direkt choices[0].message. Die Blöcke im Stream enthalten das Feld delta, das du selbst zusammenfügen musst.
• Nach einem Tool-Aufruf vergessen, die assistant-Nachricht mit tool_calls anzuhängen, was im zweiten Schritt zu Fehlern führt.

Bedeutung von Fehlercodes und Wiederholungsstrategien findest du in der Dokumentation. Ein Beispiel findest du im Chatbot-Tutorial.