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.

What you'll learn
  • Distinguere un rifiuto del modello da un blocco di un classificatore/della sicurezza — e perché conta
  • Gestire un rifiuto come un esito normale invece di andare in crash o mostrare una risposta vuota
  • Ridurre i rifiuti che non volevi, senza provare ad aggirare con un jailbreak quelli che volevi
  • Scegliere un fallback: domanda di chiarimento, alternativa sicura o passaggio a un umano

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.

Metti il contesto legittimo all'inizio

I am a security engineer at [company] reviewing our own authentication code
before a release. Below is a function we wrote and own.

Identify weaknesses in it and explain how an attacker would exploit each one,
so we can fix them before we ship.

[code]

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.
Guided walkthrough1 of 4
  1. Ispeziona la risposta cercando un segnale di rifiuto prima di mostrarla. Non mandare mai una risposta non verificata dritta nella tua UI — è così che gli utenti si ritrovano una casella vuota o un oggetto grezzo.

Mettiti alla prova

0/3
  1. Il tuo codice riceve un rifiuto da Claude. Qual è il modo giusto di trattarlo?
  2. Una richiesta benevola continua a essere rifiutata. Qual è la prima cosa da provare?
  3. Perché conta sapere se hai ricevuto un rifiuto del modello o un blocco di un classificatore/della sicurezza?
Key takeaways
  • Un rifiuto è un esito, non un errore — rilevalo sempre prima di mostrare la risposta.
  • Rifiuto del modello e blocco di un classificatore sono cose diverse; identifica quale hai ricevuto.
  • I rifiuti indesiderati di solito diminuiscono quando aggiungi contesto legittimo e diventi specifico.
  • Se una richiesta è davvero non consentita, il rifiuto è corretto — costruisci un percorso elegante, non fare jailbreak.
  • Fallback in ordine: domanda di chiarimento, alternativa sicura, passaggio a un umano.

Avanti​