Zum Hauptinhalt springen
Input-Stage-Regeln prüfen, was Sie dem Modell senden. Output-Stage-Regeln prüfen, was zurückkommt. Wenn Ihr Anliegen die Antwort des Modells ist — ein geleaktes Secret in der Completion, PII, das das Modell aus dem Kontext zutage gefördert hat, eine Antwort, die von ihren abgerufenen Quellen abweicht — wollen Sie eine Regel, deren Stage output ist. Das Gateway führt sie aus, nachdem das Upstream-Modell geantwortet hat und bevor ein einziges Byte Ihren Client erreicht. Diese Seite behandelt speziell die Output-Stage: wie eine Completion geprüft wird, was ein Block kostet und wie sich block und mask jeweils bei streamenden Responses verhalten. Für die vollständige Engine — jeder Regeltyp, jedes Feld, jede Route — siehe Guardrails.

​
1. Warum Teams zu Output-Guardrails für LLMs greifen

Das Modell ist der nicht vertrauenswürdige Teil der Schleife. Es kann ein Secret aus dem Prompt wiederholen, die E-Mail eines Kunden aus dem RAG-Kontext ziehen oder eine Behauptung halluzinieren, die Ihre Quellen nie gemacht haben. Nichts davon ist an der Input-Stage sichtbar, weil nichts davon existiert, bis das Modell geantwortet hat. Ein Output-Stage-Guardrail ist die Prüfung auf der Completion selbst. Eine Regel läuft an der Output-Stage, wenn ihre stage output (oder both) ist. Das Gateway evaluiert den Antworttext des Modells gegen die Policy, zeichnet jeden Match auf und lässt ihn dann entweder durch, redigiert ihn oder lehnt ihn ab — exakt dieselben block- / mask- / flag-Actions, die Sie auf Input verwenden, nur angewendet auf die Antwort.
Output-Regeln sind ein Superset-Anliegen, kein Ersatz. Die meisten Policies prüfen input, um Daten aus dem Prompt herauszuhalten, und output, um abzufangen, was das Modell zurückgibt. Stage both hängt eine Regel an beide Enden.

​
2. Ein konkretes Beispiel — ein Secret in der Antwort blockieren

Erstellen Sie ein Guardrail in der Konsole (/console/guardrails), fügen Sie eine Regel hinzu und hängen Sie es an einen Key an:
  • Type: Secrets / Regex-Detektor
  • Stage: output
  • Action: block
Rufen Sie nun das Gateway genau wie zuvor auf — der Relay-Key ist nur für /v1/*-Traffic: 
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"}
    ]
  }'
Wenn die Completion des Modells einen Match enthält, lehnt das Gateway die gesamte Antwort mit HTTP 400 guardrail_blocked ab — der Client sieht den geleakten Inhalt nie. Wenn sie sauber ist, geht die Antwort unangetastet durch.
Das Verfassen ist eine Konsolen-/Management-API-Aktion auf Ihrer Session, gegated auf Developer+. Der sk-orca-...-Relay-Key sendet nur Traffic; er bearbeitet nie Policy.

​
3. Was ein Output-Block kostet

Anders als ein Input-Block — der vor der Messung der Anfrage feuert — passiert ein Output-Block, nachdem das Upstream-Modell bereits gelaufen ist. Das Gateway übernimmt die Verbuchung für Sie:
  • Eine blockierte Completion gibt weiterhin HTTP 400 guardrail_blocked mit einer Nachricht zurück, die das Guardrail und die ausgelöste Regel benennt.
  • Kein Kontingent wird berechnet. Der Output-Block erstattet das vorab verbrauchte Kontingent zurück, nachdem die Antwort abgelehnt wurde, sodass der fehlgeschlagene Aufruf für Sie kostenlos ist, obwohl das Modell Tokens produziert hat.
  • Die Anfrage wird als skip-retry markiert — das erneute Ausführen desselben Prompts würde einfach wieder blockieren, sodass das Gateway keinen Retry an einem anderen Channel verbrennt.
Das ist der wesentliche Unterschied zur Input-Stage. Ein Input-Block ist kostenlos, weil die Messung noch nicht begonnen hat; ein Output-Block ist kostenlos, weil das vorab verbrauchte Kontingent zurückerstattet wird, sobald die Antwort abgelehnt ist. In beiden Fällen zahlt der Aufrufer nichts. Siehe den guardrail_blocked-Fehler.

​
4. Streaming — block vs. mask

Block wird bei streamenden Responses durchgesetzt; Output-Mask noch nicht. Hier ist, wie sich jeweils verhält:
Bei einer nicht-streamenden Response wird die Completion vollständig geprüft, bevor sie zurückkehrt. Bei einer streamenden Response beobachtet ein Scanner die Deltas, während sie fließen; wenn eine Block-Regel mittendrin feuert, kappt er den Stream — der Scanner versiegelt, gibt eine kurze Ersatznachricht anstelle des Rests aus, und der SSE-Channel schließt sich, bevor blockierter Inhalt den Client erreicht.Bereits geflushte Bytes können nicht zurückgezogen werden, daher ist ein Block best-effort auf dem, was bereits gestreamt hat, stoppt aber zuverlässig alles nach dem Match. Für eine harte Garantie, dass nie ein anstößiges Byte gesendet wird, verwenden Sie einen nicht-streamenden Request.
Bei einer nicht-streamenden Response schreibt eine Mask-Regel die Completion um — z. B. wird aus einer E-Mail in der Antwort [EMAIL] — und der bereinigte Text ist das, was Ihr Client empfängt.Bei einer streamenden Response redigiert eine Output-Mask-Regel die Antwort heute nicht. Der Scanner evaluiert weiterhin jedes Delta und handelt auf eine block-Entscheidung, aber der maskierte Text, den er berechnet, wird nicht weitergeleitet — die rohen Deltas fließen unverändert durch. In-Band-Streaming-Output-Rewriting ist auf der Roadmap. Bis es ausgeliefert wird, senden Sie die Anfrage nicht-streamend, wenn Sie möchten, dass eine Output-Mask die Antwort tatsächlich redigiert.
Beim Streaming agiert block vom Match an — Bytes, die bereits vor dem Match geflusht wurden, können nicht zurückgezogen werden, daher prüfen Sie für eine harte Garantie über die gesamte Antwort nicht-streamend. Output-Mask redigiert eine streamende Antwort heute nicht (In-Stream-Output-Masking ist auf der Roadmap) — senden Sie die Anfrage nicht-streamend, wenn Sie die Antwort redigiert brauchen. Siehe Streaming-Abdeckung und stream-sichere Regeln.
Action auf outputNicht-streamendStreamend
blocklehnt die Antwort abkappt den Stream
maskredigiert die Antwortnoch nicht redigiert (Roadmap)
flagnur aufgezeichnetnur aufgezeichnet

​
5. Grounding — eine Treue-Prüfung an der Output-Stage

Eine erweiterte Regel ist von Natur aus output-förmig: Contextual Grounding. Eine grounding-Regel bewertet die Antwort des Modells gegen die auf der Anfrage abgerufenen Quellen (Ihren RAG-Kontext) und feuert, wenn die Treue unter einen Schwellenwert fällt (Standard 0.7). Paaren Sie sie mit block, um untreue Antworten abzulehnen, oder mit flag, um die Abweichung zu messen, bevor Sie durchsetzen. Sie rechnet als Judge-Sub-Zeile ab, wie jede modellgestützte Regel. Die vollständigen Felder leben in Guardrails.

​
6. PII Shield an der Output-Stage

Das PII Shield-Preset ist eine einzelne pii-Regel, Action mask, Stage both. An der input-Stage ist es vollständig live — es schreibt die Anfrage vor dem Modell um, streamend wie nicht-streamend. An der output-Stage maskiert es nicht-streamende Completions, wie in §4; bei einer streamenden Response redigiert die Output-Mask die Antwort heute nicht (In-Stream-Output-Masking ist auf der Roadmap). An der Output-Stage rufen Sie also nicht-streamend auf, wenn Sie möchten, dass PII Shield die Antwort tatsächlich redigiert. Siehe PII Shield und Masking-Formate.

​
7. Sehen, was gefeuert hat

Jede Output-Regel, die feuert, zeichnet einen Match auf — ihren Regeltyp, Action, Stage (output) und einen Detail-String — im Workspace-Matches-Feed (GET /api/guardrail/match, offen für jedes Member). Der gematchte Teilstring wird nur aufgezeichnet, wenn der Log raw content-Toggle des Guardrails an ist; er ist standardmäßig aus (die datenschutzfreundliche Haltung), sodass Sie standardmäßig sehen, dass eine Output-Regel gefeuert hat, nicht den sensiblen Text, den sie abgefangen hat. Ein Fehlalarm wird mit POST /api/guardrail/match/:id/mark-fp (Admin) markiert — behandeln Sie ihn als Tuning-Signal, nicht als Grund, die Regel zu deaktivieren.
Beweisen Sie eine Output-Regel, bevor Sie sie ausliefern. Der Test-Tab des Editors evaluiert die aktuelle Policy über Beispieltext an der output-Stage, ohne Ihr Workspace-Kontingent zu belasten, und der Eval-Tab bewertet sie gegen mitgelieferte oder benutzerdefinierte Korpora. (Eine modellgestützte Regel — llm_judge oder grounding — gibt weiterhin ihren eigenen Judge-Aufruf ab, wenn Sie die Sandbox ausführen.) Das Verfassen und Ausführen der Sandbox sind Developer+-Aktionen. Siehe Testing & Eval und Fehlalarme tunen.

​
8. Wohin als Nächstes

Input-Stage

Das Spiegelbild — die Anfrage prüfen, bevor das Modell sie sieht. Input-Masking ist vollständig live, einschließlich Streaming.

Actions

block, mask und flag im Detail — wann jede die richtige Wahl ist.

Streaming-Abdeckung

Die vollständige Matrix dessen, was bei streamend vs. nicht-streamend durchgesetzt wird.

guardrail_blocked-Fehler

Die HTTP 400, die Kontingent-Rückerstattung und das skip-retry-Verhalten.
Guardrails — jeder Regeltyp, jedes Feld, jede Route, einschließlich Grounding und der LLM-Judge.