메인 콘텐츠로 건너뛰기
입력 스테이지 규칙은 당신이 모델에 보내는 것을 검사합니다. 출력 스테이지 규칙은 돌아오는 것을 검사합니다. 당신의 관심사가 모델의 응답일 때 — 완성에서 유출된 시크릿, 모델이 컨텍스트에서 드러낸 PII, 검색된 소스에서 벗어난 답변 — stage가 output인 규칙을 원합니다. 게이트웨이는 업스트림 모델이 응답한 후, 단 한 바이트도 클라이언트에 도달하기 전에 그것을 실행합니다. 이 페이지는 출력 스테이지를 구체적으로 다룹니다: 완성이 어떻게 검사되는지, 차단이 무엇을 소모하는지, 그리고 block과 mask가 각각 스트리밍 응답에서 어떻게 동작하는지. 전체 엔진 — 모든 규칙 타입, 필드, 라우트 — 은 Guardrails를 참조하세요.

​
1. 출력 guardrails llm 팀이 찾는 이유

모델은 루프에서 신뢰할 수 없는 부분입니다. 프롬프트의 시크릿을 되울리거나, RAG 컨텍스트에서 고객의 이메일을 끌어내거나, 당신의 소스가 한 적 없는 주장을 환각할 수 있습니다. 그 어느 것도 입력 스테이지에서는 보이지 않습니다. 모델이 응답하기 전까지 그 어느 것도 존재하지 않기 때문입니다. 출력 스테이지 guardrail은 완성 자체에 대한 검사입니다. 규칙은 stage가 output(또는 both)일 때 출력 스테이지에서 실행됩니다. 게이트웨이는 모델의 응답 텍스트를 정책에 대해 평가하고, 매치를 기록한 뒤, 그것을 통과시키거나, 마스킹하거나, 거부합니다 — 입력에서 사용하는 것과 정확히 동일한 block / mask / flag 액션을, 단지 응답에 적용할 뿐입니다.
출력 규칙은 대체가 아니라 상위 집합 관심사입니다. 대부분의 정책은 데이터를 프롬프트에서 차단하기 위해 input을 그리고 모델이 반환하는 것을 잡기 위해 output을 검사합니다. 스테이지 both는 하나의 규칙을 양쪽 끝에 연결합니다.

​
2. 하나의 구체적인 예 — 응답에서 시크릿 차단

콘솔(/console/guardrails)에서 guardrail을 생성하고, 규칙을 하나 추가한 뒤, 키에 연결합니다:
  • Type: Secrets / regex 탐지기
  • Stage: output
  • Action: block
이제 이전과 정확히 동일하게 게이트웨이를 호출합니다 — 릴레이 키는 /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"}
    ]
  }'
모델의 완성이 매치를 담고 있으면, 게이트웨이는 전체 응답을 **HTTP 400 guardrail_blocked**로 거부합니다 — 클라이언트는 유출된 콘텐츠를 결코 보지 못합니다. 깨끗하면, 응답은 그대로 통과합니다.
작성은 당신의 세션에 대한 콘솔 / 관리 API 액션이며 **Developer+**로 게이팅됩니다. sk-orca-... 릴레이 키는 트래픽만 보냅니다; 정책을 결코 편집하지 않습니다.

​
3. 출력 차단이 소모하는 것

요청이 계량되기 전에 발동하는 입력 차단과 달리, 출력 차단은 업스트림 모델이 이미 실행된 후에 일어납니다. 게이트웨이가 회계를 대신 처리합니다:
  • 차단된 완성도 여전히 **HTTP 400 guardrail_blocked**를 반환하며, 발동한 guardrail과 규칙을 명시하는 메시지를 담습니다.
  • 쿼터가 청구되지 않습니다. 출력 차단은 응답이 거부된 후 사전 소모된 쿼터를 환불하므로, 모델이 토큰을 생성했더라도 실패한 호출은 당신에게 무료입니다.
  • 요청은 skip-retry로 표시됩니다 — 동일한 프롬프트를 다시 실행해도 그저 다시 차단될 뿐이므로, 게이트웨이는 다른 채널에서 재시도를 태우지 않습니다.
이것이 입력 스테이지와의 핵심 차이입니다. 입력 차단은 계량이 시작되지 않았으므로 무료이고; 출력 차단은 응답이 거부되면 사전 소모된 쿼터가 환불되므로 무료입니다. 어느 쪽이든 호출자는 아무것도 지불하지 않습니다. guardrail_blocked 오류를 참조하세요.

​
4. 스트리밍 — block vs. mask

block은 스트리밍 응답에서 강제됩니다; 출력 mask는 아직 아닙니다. 각각이 어떻게 동작하는지는 다음과 같습니다:
비스트리밍 응답에서, 완성은 반환되기 전에 전부 검사됩니다. 스트리밍 응답에서, 스캐너는 델타가 흐를 때 그것을 지켜봅니다; block 규칙이 스트림 도중에 발동하면 스트림을 끊습니다 — 스캐너가 봉인하고, 나머지 대신 짧은 대체 알림을 내보내고, 차단된 콘텐츠가 클라이언트에 도달하기 전에 SSE 채널이 닫힙니다.이미 플러시된 바이트는 회수할 수 없으므로, 차단은 이미 스트리밍된 것에 대해서는 최선 노력이지만 매치 이후의 모든 것을 안정적으로 중단합니다. 어떤 위반 바이트도 결코 전송되지 않는다는 하드 보장을 위해서는 비스트리밍 요청을 사용하세요.
비스트리밍 응답에서, mask 규칙은 완성을 재작성합니다 — 예: 응답의 이메일이 [EMAIL]이 됩니다 — 그리고 정화된 텍스트가 클라이언트가 받는 것입니다.스트리밍 응답에서, 출력 mask 규칙은 오늘날 응답을 마스킹하지 않습니다. 스캐너는 여전히 각 델타를 평가하고 block 결정에 대해 행동하지만, 계산한 마스킹된 텍스트는 전달되지 않습니다 — 원시 델타가 변경 없이 통과합니다. 인밴드 스트리밍 출력 재작성은 로드맵에 있습니다. 그것이 출시되기 전까지, 출력 mask가 실제로 응답을 마스킹하기를 원한다면 요청을 비스트리밍으로 보내세요.
스트리밍에서 block은 매치 시점부터 작동합니다 — 매치 전에 이미 플러시된 바이트는 회수할 수 없으므로, 전체 응답에 걸친 하드 보장을 위해서는 비스트리밍으로 검사하세요. 출력 mask는 오늘날 스트리밍 응답을 마스킹하지 않습니다(스트림 내 출력 마스킹은 로드맵에 있습니다) — 응답이 마스킹되기를 원한다면 요청을 비스트리밍으로 보내세요. 스트리밍 커버리지와 스트림 안전 규칙을 참조하세요.
output에서의 액션비스트리밍스트리밍
block응답을 거부스트림을 끊음
mask응답을 마스킹아직 마스킹 안 됨(로드맵)
flag기록만기록만

​
5. Grounding — 출력 스테이지 충실도 검사

한 고급 규칙은 본질적으로 출력 형태입니다: contextual grounding. grounding 규칙은 요청에서 검색된 소스(당신의 RAG 컨텍스트)에 대해 모델의 답변을 채점하고 충실도가 임계값(기본 0.7) 아래로 떨어질 때 발동합니다. 충실하지 않은 답변을 거부하려면 block과, 강제하기 전에 드리프트를 측정하려면 flag와 짝지으세요. 다른 모델 기반 규칙처럼 judge 서브 라인으로 청구됩니다. 전체 필드는 Guardrails에 있습니다.

​
6. 출력 스테이지의 PII Shield

PII Shield 프리셋은 단일 pii 규칙, 액션 mask, 스테이지 both 입니다. 입력 스테이지에서는 완전히 라이브입니다 — 스트리밍과 비스트리밍 모두에서 모델 앞에서 요청을 재작성합니다. 출력 스테이지에서는 §4에서처럼 비스트리밍 완성을 마스킹합니다; 스트리밍 응답에서 출력 mask는 오늘날 응답을 마스킹하지 않습니다(스트림 내 출력 마스킹은 로드맵에 있습니다). 따라서 출력 스테이지에서, PII Shield가 실제로 응답을 마스킹하기를 원한다면 비스트리밍으로 호출하세요. PII Shield와 마스킹 형식을 참조하세요.

​
7. 무엇이 발동했는지 보기

발동하는 모든 출력 규칙은 워크스페이스 Matches 피드에 match를 기록합니다 — 그 규칙 타입, 액션, 스테이지(output), 그리고 상세 문자열(GET /api/guardrail/match, 모든 Member에게 개방). 매치된 부분 문자열은 guardrail의 Log raw content 토글이 켜져 있을 때 만 기록됩니다; 기본적으로 꺼져 있으므로(프라이버시 보수적 자세), 기본적으로 출력 규칙이 발동했다는 것은 보지만 잡아낸 민감한 텍스트는 보지 못합니다. 거짓 양성은 POST /api/guardrail/match/:id/mark-fp(Admin)로 표시합니다 — 그것을 규칙을 비활성화할 이유가 아니라 튜닝 신호로 취급하세요.
출력 규칙을 출시하기 전에 증명하세요. 에디터의 Test 탭은 워크스페이스 쿼터를 청구하지 않고 output 스테이지에서 샘플 텍스트에 대해 현재 정책을 평가하고, Eval 탭은 번들 또는 커스텀 코퍼스에 대해 그것을 채점합니다. (모델 기반 규칙 — llm_judge 또는 grounding — 은 샌드박스를 실행할 때 여전히 자체 judge 호출을 발행합니다.) 작성과 샌드박스 실행은 Developer+ 액션입니다. 테스트 및 평가와 거짓 양성 튜닝을 참조하세요.

​
8. 다음으로 갈 곳

입력 스테이지

거울 이미지 — 모델이 보기 전에 요청을 검사합니다. 입력 마스킹은 스트리밍을 포함하여 완전히 라이브입니다.

액션

block, mask, flag를 심층적으로 — 각각이 올바른 선택일 때.

스트리밍 커버리지

스트리밍 vs. 비스트리밍에서 무엇이 강제되는지의 전체 매트릭스.

guardrail_blocked 오류

HTTP 400, 쿼터 환불, 그리고 skip-retry 동작.
Guardrails — grounding과 LLM judge를 포함한 모든 규칙 타입, 필드, 라우트.