Streaming-Ablehnungen

Ab den Claude 4-Modellen geben Streaming-Antworten der Claude-API stop_reason: "refusal" zurück, wenn Streaming-Klassifikatoren eingreifen, um potenzielle Richtlinienverstöße zu behandeln. Diese Sicherheitsfunktion hilft dabei, die Einhaltung von Inhaltsrichtlinien während des Echtzeit-Streamings zu gewährleisten.



API-Antwortformat

Wenn Streaming-Klassifikatoren Inhalte erkennen, die gegen die Richtlinien von Anthropic verstoßen, gibt die API diese Antwort zurück:

{
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "Hello.."
    }
  ],
  "stop_reason": "refusal"
}



Kontext nach Ablehnung zurücksetzen

Wenn du stop_reason: refusal erhältst, musst du den Gesprächskontext zurücksetzen, bevor du fortfährst. Du kannst den Turn, der die Ablehnung ausgelöst hat, entfernen oder umformulieren, oder den Gesprächsverlauf vollständig löschen. Ein Versuch, ohne Zurücksetzen fortzufahren, führt zu weiteren Ablehnungen.



Implementierungsleitfaden

So erkennst und behandelst du Streaming-Ablehnungen in deiner Anwendung:

client = anthropic.Anthropic()
messages = []


def reset_conversation():
    """Reset conversation context after refusal"""
    global messages
    messages = []
    print("Conversation reset due to refusal")


try:
    with client.messages.stream(
        max_tokens=1024,
        messages=messages + [{"role": "user", "content": "Hello"}],
        model="claude-opus-4-8",
    ) as stream:
        for event in stream:
            # Prüfe auf Ablehnung im Message-Delta
            if event.type == "message_delta":
                if event.delta.stop_reason == "refusal":
                    reset_conversation()
                    break
except Exception as e:
    print(f"Error: {e}")



Aktuelle Ablehnungstypen

Die API behandelt Ablehnungen derzeit auf drei verschiedene Arten:



Best Practices

• Auf Ablehnungen überwachen: Integriere Prüfungen auf stop_reason: refusal in deine Fehlerbehandlung
• Automatisch zurücksetzen: Implementiere ein automatisches Zurücksetzen des Kontexts, wenn Ablehnungen erkannt werden
• Auf ein anderes Modell zurückfallen: Konfiguriere serverseitigen Fallback oder die SDK-Middleware, damit abgelehnte Anfragen mit einem anderen Claude-Modell wiederholt werden, anstatt dem Nutzer eine Ablehnung anzuzeigen
• Fallback-Credit bei manuellen Retries einlösen: Wenn du den Retry selbst implementierst, übergib das Fallback-Credit-Token der Ablehnung, damit der Retry die Prompt-Cache-Kosten nicht doppelt bezahlt
• Benutzerdefinierte Nachrichten bereitstellen: Erstelle benutzerfreundliche Nachrichten für eine bessere UX, wenn Ablehnungen auftreten
• Ablehnungsmuster verfolgen: Überwache die Häufigkeit von Ablehnungen, um potenzielle Probleme mit deinen Prompts zu identifizieren



Migrationshinweise

Wenn du die Ablehnungsbehandlung implementiert hast, als diese Funktion erstmals ausgeliefert wurde, oder wenn du sie zu einer bestehenden Integration hinzufügst, überprüfe Folgendes:

• Ablehnungen sind Antworten, keine Fehler. Eine Ablehnung kommt als erfolgreiche HTTP-200-Antwort mit stop_reason: "refusal" an, sodass ein Monitoring, das nur auf Fehlerraten basiert, sie nicht erfasst. Verfolge Ablehnungen als eigenes Signal.
• Neuere Modelle liefern mehr Details. Bei Claude Fable 5 enthält eine Ablehnung zusätzlich ein stop_details-Objekt, das die Richtlinienkategorie hinter der Ablehnung identifiziert. Siehe Ablehnungen und Fallback für die vollständige Antwortstruktur.
• Mit einem anderen Modell wiederholen. Das erneute Senden einer abgelehnten Anfrage an dasselbe Modell führt in der Regel zu einer weiteren Ablehnung. Anstatt nur den Kontext zurückzusetzen, wiederhole die Anfrage mit einem Fallback-Modell über serverseitigen Fallback, die SDK-Middleware oder einen manuellen Retry und löse Fallback-Credit ein, wenn du den Retry selbst implementierst.
• Batch-Ergebnisse auf Ablehnungen prüfen. Eine abgelehnte Anfrage in einem Message Batch wird als erfolgreiches Ergebnis mit stop_reason: "refusal" zurückgegeben, nicht als fehlerhaftes Ergebnis.
• Behandlung auf stop_reason zentralisieren. Die API konsolidiert die Ablehnungsbehandlung weiterhin rund um stop_reason: "refusal", verzweige also anhand des Stop-Reasons und nicht anhand modellspezifischen Verhaltens.



Nächste Schritte