Passer au contenu principal
Les règles à l’étape input filtrent ce que vous envoyez au modèle. Les règles à l’étape output filtrent ce qui revient. Quand votre préoccupation est la réponse du modèle — un secret fuité dans la complétion, de la PII que le modèle a fait remonter du contexte, une réponse qui s’écarte de ses sources récupérées — vous voulez une règle dont l’étape est output. La passerelle l’exécute après que le modèle en amont a répondu et avant qu’un seul octet n’atteigne votre client. Cette page couvre spécifiquement l’étape output : comment une complétion est filtrée, ce que coûte un block, et comment block et mask se comportent chacun sur les réponses streaming. Pour le moteur complet — chaque type de règle, champ et route — voir Guardrails.

​
1. Pourquoi les équipes recourent aux guardrails de sortie llm

Le modèle est la partie non fiable de la boucle. Il peut renvoyer en écho un secret du prompt, extraire l’email d’un client depuis un contexte RAG, ou halluciner une affirmation que vos sources n’ont jamais faite. Rien de tout cela n’est visible à l’étape input, parce que rien de cela n’existe tant que le modèle n’a pas répondu. Un guardrail à l’étape output est le filtre sur la complétion elle-même. Une règle s’exécute à l’étape output lorsque son stage est output (ou both). La passerelle évalue le texte de réponse du modèle par rapport à la politique, enregistre toute correspondance, puis le laisse passer, le redacte ou le rejette — exactement les mêmes actions block / mask / flag que vous utilisez sur l’entrée, juste appliquées à la réponse.
Les règles de sortie sont une préoccupation surensemble, pas un remplacement. La plupart des politiques filtrent input pour garder les données hors du prompt et output pour attraper ce que le modèle renvoie. L’étape both attache une règle aux deux extrémités.

​
2. Un exemple concret — bloquer un secret dans la réponse

Créez un guardrail dans la console (/console/guardrails), ajoutez une règle, et attachez-la à une clé :
  • Type : Secrets / détecteur regex
  • Étape : output
  • Action : block
Maintenant, appelez la passerelle exactement comme avant — la clé de relais ne sert qu’au trafic /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"}
    ]
  }'
Si la complétion du modèle contient une correspondance, la passerelle rejette toute la réponse avec une HTTP 400 guardrail_blocked — le client ne voit jamais le contenu fuité. Si elle est propre, la réponse passe intacte.
La rédaction est une action de console / API de gestion sur votre session, soumise à Developer+. La clé de relais sk-orca-... n’envoie que du trafic ; elle ne modifie jamais la politique.

​
3. Ce que coûte un block de sortie

Contrairement à un block d’entrée — qui se déclenche avant que la requête ne soit mesurée — un block de sortie se produit après que le modèle en amont a déjà tourné. La passerelle gère la comptabilité pour vous :
  • Une complétion bloquée renvoie toujours une HTTP 400 guardrail_blocked avec un message nommant le guardrail et la règle qui s’est déclenchée.
  • Aucun quota n’est facturé. Le block de sortie rembourse le quota pré-consommé après le rejet de la réponse, donc l’appel échoué est gratuit pour vous même si le modèle a produit des tokens.
  • La requête est marquée skip-retry — ré-exécuter le même prompt ne ferait que bloquer à nouveau, donc la passerelle ne brûlera pas un retry sur un autre canal.
C’est la différence clé avec l’étape input. Un block input est gratuit parce que la mesure n’a pas commencé ; un block output est gratuit parce que le quota pré-consommé est remboursé une fois la réponse rejetée. Dans les deux cas, l’appelant ne paie rien. Voir l’erreur guardrail_blocked.

​
4. Streaming — block vs. mask

Le block est appliqué sur les réponses streaming ; le mask de sortie ne l’est pas encore. Voici comment chacun se comporte :
Sur une réponse non-streaming, la complétion est filtrée en entier avant son retour. Sur une réponse streaming, un scanner observe les deltas à mesure qu’ils circulent ; lorsqu’une règle de block se déclenche en plein flux, il coupe le flux — le scanner scelle, émet un court avis de remplacement à la place du reste, et le canal SSE se ferme avant que tout contenu bloqué n’atteigne le client.Les octets déjà émis ne peuvent pas être rétractés, donc un block est au mieux sur ce qui a déjà été streamé mais arrête de façon fiable tout ce qui suit la correspondance. Pour une garantie dure qu’aucun octet fautif n’est jamais envoyé, utilisez une requête non-streaming.
Sur une réponse non-streaming, une règle mask réécrit la complétion — par exemple un email dans la réponse devient [EMAIL] — et le texte assaini est ce que votre client reçoit.Sur une réponse streaming, une règle mask de sortie ne redacte pas la réponse aujourd’hui. Le scanner évalue toujours chaque delta et agira sur une décision block, mais le texte masqué qu’il calcule n’est pas transmis — les deltas bruts circulent inchangés. La réécriture de sortie streaming in-band est sur la feuille de route. Jusqu’à sa livraison, envoyez la requête en non-streaming si vous avez besoin qu’un mask de sortie redacte réellement la réponse.
En streaming, block agit à partir de la correspondance — les octets déjà émis avant la correspondance ne peuvent pas être rétractés, donc pour une garantie dure sur la réponse entière, filtrez en non-streaming. Le mask de sortie ne redacte pas une réponse streaming aujourd’hui (le masquage de sortie in-stream est sur la feuille de route) — envoyez la requête en non-streaming si vous avez besoin que la réponse soit redactée. Voir couverture du streaming et règles stream-safe.
Action sur outputNon-streamingStreaming
blockrejette la réponsecoupe le flux
maskredacte la réponsepas encore redacté (feuille de route)
flagenregistre seulementenregistre seulement

​
5. Ancrage — une vérification de fidélité à l’étape output

Une règle avancée est de forme output par nature : l’ancrage contextuel. Une règle grounding score la réponse du modèle par rapport aux sources récupérées sur la requête (votre contexte RAG) et se déclenche lorsque la fidélité tombe sous un seuil (par défaut 0.7). Associez-la à block pour refuser les réponses infidèles, ou à flag pour mesurer la dérive avant de l’appliquer. Elle facture comme une sous-ligne de juge, comme toute règle adossée à un modèle. Les champs complets vivent dans Guardrails.

​
6. PII Shield à l’étape output

Le preset PII Shield est une seule règle pii, action mask, étape both. À l’étape input, il est pleinement actif — il réécrit la requête avant le modèle, en streaming comme en non-streaming. À l’étape output, il masque les complétions non-streaming, comme en §4 ; sur une réponse streaming, le mask de sortie ne redacte pas la réponse aujourd’hui (le masquage de sortie in-stream est sur la feuille de route). Donc à l’étape output, appelez en non-streaming si vous avez besoin que PII Shield redacte réellement la réponse. Voir PII Shield et formats de masquage.

​
7. Voir ce qui s’est déclenché

Chaque règle de sortie qui se déclenche enregistre une correspondance — son type de règle, son action, son étape (output), et une chaîne de détail — dans le flux Matches de l’espace de travail (GET /api/guardrail/match, ouvert à tout Member). La sous-chaîne correspondante n’est enregistrée que lorsque le toggle Log raw content du guardrail est activé ; il est désactivé par défaut (la posture conservatrice en matière de confidentialité), donc par défaut vous voyez *qu’*une règle de sortie s’est déclenchée, pas le texte sensible qu’elle a attrapé. Un faux positif est marqué avec POST /api/guardrail/match/:id/mark-fp (Admin) — traitez-le comme un signal d’ajustement, pas une raison de désactiver la règle.
Prouvez une règle de sortie avant de la livrer. L’onglet Test de l’éditeur évalue la politique actuelle sur un texte d’échantillon à l’étape output sans facturer le quota de votre espace de travail, et l’onglet Eval la score contre des corpus fournis ou personnalisés. (Une règle adossée à un modèle — llm_judge ou grounding — émet toujours son propre appel de juge lorsque vous exécutez le sandbox.) Rédiger et exécuter le sandbox sont des actions Developer+. Voir test & éval et ajuster les faux positifs.

​
8. Où aller ensuite

Étape input

L’image miroir — filtrez la requête avant que le modèle ne la voie. Le masquage d’entrée est pleinement actif, y compris en streaming.

Actions

block, mask et flag en profondeur — quand chacun est le bon choix.

Couverture du streaming

La matrice complète de ce qui est appliqué en streaming vs. non-streaming.

Erreur guardrail_blocked

La HTTP 400, le remboursement de quota, et le comportement skip-retry.
Guardrails — chaque type de règle, champ et route, y compris l’ancrage et le juge LLM.