Zum Hauptinhalt springen

Sicherheit, Verweigerungen & Fallbacks

Fortgeschritten

In der Produktion muss dein Code den Fall behandeln, in dem Claude nicht so antwortet, wie erwartet — oder es nicht kann. Gut gemacht ist das für Nutzer unsichtbar; schlecht gemacht ist es ein Absturz oder eine verwirrende Antwort.

Zwei verschiedene Dinge​

  • Eine Modellverweigerung — Claude lehnt eine Anfrage ab (z. B. weil es sie als schädlich einstuft). Die Antwort signalisiert dies (üblicherweise über einen stop_reason/Inhalt einer Verweigerung). Behandle dies als normales Ergebnis, nicht als Fehler.
  • Eine Classifier-/Sicherheitsblockade — eine separate Sicherheitsschicht kann Inhalte blockieren. Dies kann anders aussehen als eine Modellverweigerung.

Zu wissen, welches du erhalten hast, ermöglicht es dir, angemessen zu reagieren, statt blind zu wiederholen.

Behandle es elegant​

resp = client.messages.create(...)
if getattr(resp, "stop_reason", None) == "refusal":
    # Don't show a raw/empty result. Offer a safe fallback or a clarifying ask.
    show_user("I can't help with that as asked. Here's what I can do instead…")
else:
    render(resp)

Unerwünschte Verweigerungen reduzieren​

  • Füge legitimen Kontext hinzu. Eine Anfrage kann auf etwas Sensibles passen, obwohl die Absicht harmlos ist; den echten, legitimen Zweck zu nennen, hilft.
  • Sei spezifisch. Vage oder grenzwertige Formulierungen laden zu Vorsicht ein.
  • Kämpfe nicht dagegen an. Wenn eine Anfrage tatsächlich unzulässig ist, ist eine Verweigerung korrekt — gestalte einen eleganten Weg, versuche kein Jailbreaking.

Fallback-Muster​

  • Eine Rückfrage statt einer Sackgasse.
  • Eine sichere Alternative („Ich kann stattdessen die öffentlichen Informationen zusammenfassen").
  • Bei Pipelines: an einen Menschen weiterleiten, wenn Konfidenz/Berechtigung niedrig sind.

Weiter​