Passa al contenuto principale

Sicurezza, rifiuti e fallback

Intermedio

In produzione, il tuo codice deve gestire il caso in cui Claude non vuole (o non può) rispondere come previsto. Fatto bene, questo è invisibile agli utenti; fatto male, è un crash o una risposta confusa.

Due cose diverse​

  • Un rifiuto del modello — Claude declina una richiesta (ad esempio perché la giudica dannosa). La risposta lo segnala (di solito tramite uno stop_reason/contenuto di rifiuto). Trattalo come un esito normale, non come un errore.
  • Un blocco di un classificatore/della sicurezza — un livello di sicurezza separato può bloccare il contenuto. Questo può apparire diverso da un rifiuto del modello.

Sapere quale dei due hai ricevuto ti permette di rispondere in modo appropriato invece di riprovare alla cieca.

Gestiscilo con eleganza​

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)

Ridurre i rifiuti indesiderati​

  • Aggiungi un contesto legittimo. Una richiesta può sembrare qualcosa di sensibile anche quando l'intento è benevolo; esplicitare lo scopo reale e legittimo aiuta.
  • Sii specifico. Una formulazione vaga o ambigua invita alla cautela.
  • Non combatterlo. Se una richiesta è davvero non consentita, il rifiuto è corretto — progetta un percorso elegante, non cercare di aggirarlo con un jailbreak.

Pattern di fallback​

  • Una domanda di chiarimento invece di un vicolo cieco.
  • Un'alternativa sicura ("posso invece riassumere le informazioni pubbliche").
  • Per le pipeline, indirizza a un umano quando la confidenza/l'idoneità è bassa.

Avanti​