Passer au contenu principal
Si votre application streame, vous avez besoin d’une réponse claire avant de faire confiance à une politique de contenu : ce qui est réellement appliqué sur une réponse SSE. Un guardrail qui inspecte une réponse entière est facile à raisonner ; un guardrail qui doit agir sur les deltas à mesure qu’ils sont émis vers le navigateur ne l’est pas. Cette page est la matrice de couverture du streaming des guardrails — chaque action, à travers les étapes input et output, sur le trafic streaming et non-streaming — écrite pour être précise sur la façon dont chaque cellule se comporte sur un flux en direct. Pour le moteur complet — chaque type de règle, champ et route — voir Guardrails. Pour la mécanique de comment un flux est coupé, voir règles stream-safe.

​
1. La question de la couverture du streaming des guardrails

Une règle de guardrail porte une étape (input, output, ou both) et une action — l’une de cinq : block, mask, flag, annotate, ou spotlight. L’étape décide quand la passerelle l’exécute ; l’action décide ce qu’elle fait. Le seul endroit où le streaming change la forme de la réponse est l’étape output — parce que c’est la seule étape où la passerelle transmet des octets à votre client à mesure qu’ils arrivent, sans chance de détenir le payload entier d’abord. Donc la matrice a deux cellules où le streaming compte, et elles se comportent différemment : le block de sortie est pleinement appliqué sur un flux (le scanner le coupe), mais le mask de sortie n’est appliqué que sur les réponses non-streaming. Sur une réponse streaming, le scanner détecte toujours la correspondance et peut agir sur une décision de block, mais il ne réécrit pas le texte masqué dans le flux aujourd’hui — le masquage de sortie streaming in-band est sur la feuille de route.
L’entrée n’est jamais le problème. Les règles à l’étape input s’exécutent avant le modèle — la passerelle filtre (et, pour mask, réécrit) votre requête, puis transmet la version assainie en amont. Le fait que la réponse streame est sans importance ; la requête est un payload complet que la passerelle détient en entier. Le filtrage d’entrée est pleinement actif, masquage compris, à chaque requête.

​
2. La matrice de couverture

Lisez ceci de haut en bas. Chaque cellule de block est active, streaming compris — mais output + mask + streaming est la seule cellule qui n’est pas encore appliquée dans le flux : une règle mask redacte une réponse non-streaming, et sur une réponse streaming, elle détecte la correspondance sans réécrire le delta (le masquage de sortie in-stream est sur la feuille de route).
Étape · actionNon-streamingStreaming
input · blockrejette la requêterejette la requête
input · maskréécrit la requêteréécrit la requête
output · blockrejette la réponsecoupe le flux
output · maskredacte la réponsedétecte la correspondance ; ne redacte pas in-stream (feuille de route)
toute · flagenregistre seulementenregistre seulement
annotate et spotlight attachent une note (ou encadrent le texte correspondant) sans rejeter le trafic et sont en pratique des actions à l’étape input, donc elles ne changent pas les cellules output/streaming ci-dessus ; elles enregistrent une correspondance comme toute autre règle.
Les règles à l’étape input filtrent la requête avant que le modèle en amont ne tourne. Un block court-circuite l’appel (HTTP 400 guardrail_blocked, avant la mesure, donc il ne coûte aucun quota). Un mask réécrit les champs correspondants dans le prompt en place — le texte assaini est ce qui part en amont, et le modèle ne voit jamais l’original. Rien de cela ne dépend du fait que la réponse streame.
Sur une réponse non-streaming, la complétion est filtrée en entier avant son retour — un block apparaît comme une HTTP 400 guardrail_blocked. Sur une réponse streaming, un scanner de flux observe les deltas à mesure qu’ils circulent ; quand une règle de block se déclenche, il coupe le flux — scelle le scanner, émet un court avis de remplacement à la place du reste, et ferme le canal SSE avant que tout contenu bloqué supplémentaire n’atteigne le client. Parce que les en-têtes SSE 200 sont déjà partis à ce moment-là, un block en streaming ne peut pas renvoyer un 400 : il livre le block comme un delta in-band final plutôt qu’une erreur HTTP.
Sur une réponse non-streaming, une règle mask réécrit la complétion — par exemple un email devient [EMAIL] — et le texte assaini est ce que votre client obtient. Sur une réponse streaming, le scanner de flux détecte toujours la correspondance et calcule le masque, mais il ne transmet pas le texte masqué dans le delta — la sortie masquée est rejetée et seule une décision de block est agie. Donc une règle mask ne redacte pas une réponse streaming aujourd’hui ; le masquage de sortie streaming in-band est sur la feuille de route. Si vous avez besoin de garder la PII hors d’une réponse streamée dès maintenant, rédigez la règle en block (le scanner coupe le flux sur correspondance) ou filtrez en non-streaming.
Une règle flag n’altère jamais le trafic — elle enregistre une correspondance et laisse passer les octets. L’étape et le flux ne changent pas son comportement. Utilisez-la pour mesurer le taux de déclenchement d’une règle avant de la promouvoir en block.
La seule ligne à retenir : le block de sortie est appliqué en direct sur les deux transports — streaming compris — et le masquage d’entrée est toujours actif. Le mask de sortie redacte les réponses non-streaming uniquement ; sur un flux, il détecte la correspondance mais ne réécrit pas encore le delta (le masquage de sortie in-stream est sur la feuille de route). Pour garder la PII hors d’une réponse streamée aujourd’hui, rédigez la règle en block ou filtrez en non-streaming.

​
3. Un exemple concret — garder la PII hors d’une réponse streamée

Disons que le modèle peut faire remonter un email de client depuis un contexte RAG, et que votre application streame. Le mask de sortie ne redacte pas dans le flux aujourd’hui (le masquage de sortie in-stream est sur la feuille de route) — donc pour garder la PII hors d’une réponse streamée, rédigez la règle de sortie en block : le scanner tue le flux au moment où une correspondance apparaît. (Le mask de sortie redacte bien sur une réponse non-streaming.) L’édition de politique est une action de gestion sur votre session de console (contrôlée à Developer+) ; la clé de relais sk-orca-... n’envoie que le trafic /v1/* et ne modifie jamais la politique.
  • Ouvrez /console/guardrails, New guardrail, nommez-le stream-pii-out.
  • Ajoutez une règle :
    • Type : PII detection
    • Étape : output
    • Action : block ← coupe le flux sur correspondance ; sur un flux, mask ne fait que détecter (il redacte les réponses non-streaming)
  • Enregistrez, puis attachez-le sur /console/token via la liste déroulante Guardrail de la clé.
Maintenant, appelez la passerelle avec stream: true, exactement comme avant : 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "stream": true,
    "messages": [
      {"role": "user", "content": "Email the customer from the record above"}
    ]
  }'
Si un delta correspond, le scanner coupe le flux, émet un avis de remplacement, et ferme le canal — le client ne reçoit jamais le reste. Si la réponse est propre, chaque delta est streamé intact.
Un block en streaming arrête tout ce qui est après la correspondance, mais il ne peut pas dé-envoyer les octets déjà émis avant que la correspondance n’atterrisse. Si votre politique exige que pas un seul octet fautif n’atteigne jamais le client, filtrez la requête en non-streaming, où la complétion entière est détenue jusqu’à ce que la politique la valide.

​
4. PII Shield à travers la matrice

Le preset PII Shield est une seule règle pii, action mask, étape both. Mappez-le sur la matrice et la couverture est exactement ce à quoi vous vous attendriez d’après §2 :
  • Étape input — pleinement active, streaming ou non. La requête est masquée avant que le modèle ne la voie (la valeur phare du masquage d’entrée).
  • Étape output, non-streaming — la complétion est masquée avant son retour.
  • Étape output, streaming — le scanner de flux détecte la correspondance mais ne réécrit pas le delta aujourd’hui, donc la forme masquée n’atteint pas un client streamé (le masquage de sortie in-stream est sur la feuille de route).
Donc le preset mask ne couvre pas la PII hors d’une réponse streamée à lui seul. Pour garder la PII hors d’une réponse streamée, rédigez cette règle en block (ou appelez en non-streaming) afin que le flux soit coupé sur correspondance. Voir PII Shield et formats de masquage.

​
5. Ce que coûte un block en streaming

Un block en streaming porte la même comptabilité que tout block de sortie — le modèle a déjà tourné, donc la passerelle gère le remboursement pour vous :
  • Sur une réponse non-streaming, l’appel renvoie une HTTP 400 guardrail_blocked nommant le guardrail et la règle qui s’est déclenchée. Sur une réponse streaming, les en-têtes SSE 200 sont déjà sur le fil, donc le block arrive comme un delta de remplacement in-band final et une fermeture propre du canal au lieu d’un 400.
  • Aucun quota n’est facturé. Un block d’entrée se déclenche avant la mesure ; un block de sortie (streaming ou non) rembourse le quota pré-consommé une fois la réponse rejetée. Dans les deux cas, l’appelant ne paie rien.
  • 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.
Chaque règle de sortie qui se déclenche enregistre aussi une correspondance dans le flux Matches de l’espace de travail (GET /api/guardrail/match, ouvert à tout Member) ; la sous-chaîne correspondante n’est capturée que lorsque le toggle Log raw content du guardrail est activé (désactivé par défaut). Le détail complet vit dans l’erreur guardrail_blocked et le flux des correspondances.

​
6. Prouvez votre combinaison étape/action avant de livrer

Ne devinez pas quelle cellule de la matrice s’applique à votre politique — vérifiez-la. Les deux outils s’exécutent sur votre session de console via l’API de gestion :

Onglet Test

Chaque éditeur de guardrail a un onglet Test : collez un échantillon, choisissez l’étape, et exécutez la politique actuelle sans appel en amont et sans quota. Voyez le verdict et, pour les règles mask, le texte rendu. Le sandbox Test est contrôlé à Developer+ (il peut déclencher des appels de juge/ancrage payants et des requêtes d’intégration sortantes).

Onglet Eval

L’onglet Eval score un guardrail contre des corpus JSONL fournis ou personnalisés — utile pour confirmer qu’une règle de block attrape une fuite connue avant d’attacher une clé. Exécuter une éval ne nécessite qu’un accès en lecture (viewer+).
Voir test & éval et ajuster les faux positifs pour la profondeur.

​
7. Où aller ensuite

Règles stream-safe

Comment le scanner coupe un flux SSE en plein vol, et comment rédiger une politique qui tient sur le trafic streaming.

Étape output

Filtrer la réponse du modèle — block vs. mask, le remboursement de quota, et l’ancrage.

Étape input

Filtrer la requête avant le modèle — masquage compris, streaming ou non.

Actions

block, mask, flag, annotate et spotlight en profondeur — quand chacun est le bon choix.
Guardrails — chaque type de règle, champ et route, y compris l’ancrage et le juge LLM.