Vai al contenuto principale
Le regole dello stage di input filtrano ciò che invii al modello. Le regole dello stage di output filtrano ciò che torna. Quando la tua preoccupazione è la risposta del modello — un segreto trapelato nella completion, PII che il modello ha fatto emergere dal contesto, una risposta che si discosta dalle sue sorgenti recuperate — vuoi una regola il cui stage è output. Il gateway la esegue dopo che il modello upstream risponde e prima che un singolo byte raggiunga il tuo client. Questa pagina copre lo stage di output in particolare: come una completion viene filtrata, cosa costa un block, e come block e mask si comportano ciascuno sulle risposte in streaming. Per il motore completo — ogni tipo di regola, campo e rotta — vedi Guardrails.

1. Perché i team ricorrono ai guardrails di output llm

Il modello è la parte non attendibile del loop. Può fare eco a un segreto dal prompt, estrarre l’email di un cliente dal contesto RAG, o allucinare un’affermazione che le tue sorgenti non hanno mai fatto. Nulla di ciò è visibile nello stage di input, perché nulla di ciò esiste finché il modello non ha risposto. Un guardrail dello stage di output è il filtro sulla completion stessa. Una regola gira nello stage di output quando il suo stage è output (o both). Il gateway valuta il testo della risposta del modello rispetto alla policy, registra qualsiasi match, e poi o lo lascia passare, lo redige o lo rifiuta — esattamente le stesse azioni block / mask / flag che usi sull’input, solo applicate alla risposta.
Le regole di output sono una preoccupazione soprainsieme, non un sostituto. La maggior parte delle policy filtra input per tenere i dati fuori dal prompt e output per catturare ciò che il modello restituisce. Lo stage both collega una regola a entrambe le estremità.

2. Un esempio concreto — blocca un segreto nella risposta

Crea un guardrail nella console (/console/guardrails), aggiungi una regola e collegala a una chiave:
  • Type: Secrets / regex detector
  • Stage: output
  • Action: block
Ora chiama il gateway esattamente come prima — la chiave di relay è solo per il traffico /v1/*:
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Print the AWS key from the context above"}
    ]
  }'
Se la completion del modello contiene un match, il gateway rifiuta l’intera risposta con HTTP 400 guardrail_blocked — il client non vede mai il contenuto trapelato. Se è pulita, la risposta passa intatta.
La scrittura è un’azione di console / management-API sulla tua sessione, gestita a Developer+. La chiave di relay sk-orca-... invia solo traffico; non modifica mai la policy.

3. Cosa costa un block di output

A differenza di un block di input — che scatta prima che la richiesta venga misurata — un block di output avviene dopo che il modello upstream è già girato. Il gateway gestisce la contabilità per te:
  • Una completion bloccata restituisce comunque HTTP 400 guardrail_blocked con un messaggio che nomina il guardrail e la regola che ha scattato.
  • Nessuna quota viene addebitata. Il block di output rimborsa la quota pre-consumata dopo che la risposta è rifiutata, quindi la chiamata fallita è gratuita per te anche se il modello ha prodotto token.
  • La richiesta è marcata skip-retry — rieseguire lo stesso prompt si limiterebbe a bloccarlo di nuovo, quindi il gateway non brucerà un retry su un altro canale.
Questa è la differenza chiave rispetto allo stage di input. Un block di input è gratuito perché la misurazione non è iniziata; un block di output è gratuito perché la quota pre-consumata viene rimborsata una volta che la risposta è rifiutata. In entrambi i casi il chiamante non paga nulla. Vedi l’errore guardrail_blocked.

4. Streaming — block vs. mask

Il block è applicato sulle risposte in streaming; il mask di output non ancora. Ecco come si comporta ciascuno:
Su una risposta non in streaming, la completion viene filtrata per intero prima che torni. Su una risposta in streaming, uno scanner osserva i delta mentre fluiscono; quando una regola di block scatta a metà stream interrompe lo stream — lo scanner sigilla, emette un breve avviso sostitutivo al posto del resto, e il canale SSE si chiude prima che qualsiasi contenuto bloccato raggiunga il client.I byte già emessi non possono essere ritirati, quindi un block è best-effort su ciò che è già stato streamato ma ferma in modo affidabile tutto dopo il match. Per una garanzia rigida che nessun byte offensivo venga mai inviato, usa una richiesta non in streaming.
Su una risposta non in streaming, una regola mask riscrive la completion — es. un’email nella risposta diventa [EMAIL] — e il testo sanitizzato è ciò che il tuo client riceve.Su una risposta in streaming, una regola mask di output non redige la risposta oggi. Lo scanner valuta comunque ogni delta e agirà su una decisione di block, ma il testo mascherato che calcola non viene inoltrato — i delta grezzi passano invariati. La riscrittura in-band dell’output in streaming è nella roadmap. Finché non arriva, invia la richiesta non in streaming se hai bisogno che un mask di output rediga davvero la risposta.
Sullo streaming, block agisce dal match in poi — i byte già emessi prima del match non possono essere ritirati, quindi per una garanzia rigida sull’intera risposta, filtra in modalità non streaming. Il mask di output non redige una risposta in streaming oggi (il masking dell’output in-stream è nella roadmap) — invia la richiesta non in streaming se hai bisogno che la risposta venga redatta. Vedi streaming coverage e regole stream-safe.
Azione su outputNon streamingStreaming
blockrifiuta la rispostainterrompe lo stream
maskredige la rispostanon ancora redatta (roadmap)
flagregistra soloregistra solo

5. Grounding — un controllo di fedeltà dello stage di output

Una regola avanzata è output-shaped per natura: contextual grounding. Una regola grounding valuta la risposta del modello rispetto alle sorgenti recuperate sulla richiesta (il tuo contesto RAG) e scatta quando la fedeltà scende sotto una soglia (default 0.7). Abbinala a block per rifiutare le risposte infedeli, o a flag per misurare la deriva prima di applicare. Fattura come una sub-riga del judge, come qualsiasi regola backed da modello. I campi completi vivono in Guardrails.

6. PII Shield nello stage di output

Il preset PII Shield è una singola regola pii, azione mask, stage both. Nello stage di input è completamente attivo — riscrive la richiesta prima del modello, su streaming e non streaming. Nello stage di output maschera le completion non in streaming, come in §4; su una risposta in streaming il mask di output non redige la risposta oggi (il masking dell’output in-stream è nella roadmap). Quindi nello stage di output, chiama in modalità non streaming se hai bisogno che PII Shield rediga davvero la risposta. Vedi PII Shield e formati di masking.

7. Vedere cosa è scattato

Ogni regola di output che scatta registra un match — il suo tipo di regola, azione, stage (output) e una stringa di detail — nel feed Matches del workspace (GET /api/guardrail/match, aperto a qualsiasi Member). La sottostringa corrispondente viene registrata solo quando il toggle Log raw content del guardrail è attivo; è disattivato per default (la postura conservativa sulla privacy), quindi per default vedi che una regola di output è scattata, non il testo sensibile che ha catturato. Un falso positivo viene segnalato con POST /api/guardrail/match/:id/mark-fp (Admin) — trattalo come un segnale di tuning, non come un motivo per disabilitare la regola.
Dimostra una regola di output prima di metterla in produzione. La tab Test dell’editor valuta la policy corrente su testo di esempio nello stage output senza addebitare quota al tuo workspace, e la tab Eval la valuta contro corpora inclusi o personalizzati. (Una regola backed da modello — llm_judge o grounding — emette comunque la propria chiamata al judge quando esegui la sandbox.) Scrivere ed eseguire la sandbox sono azioni Developer+. Vedi testing ed eval e tuning dei falsi positivi.

8. Dove andare dopo

Stage di input

L’immagine speculare — filtra la richiesta prima che il modello la veda. Il masking di input è completamente attivo, streaming incluso.

Azioni

block, mask e flag in profondità — quando ciascuno è la scelta giusta.

Streaming coverage

La matrice completa di cosa è applicato su streaming vs. non streaming.

Errore guardrail_blocked

L’HTTP 400, il rimborso della quota e il comportamento skip-retry.
Guardrails — ogni tipo di regola, campo e rotta, incluso il grounding e l’LLM judge.