Przejdź do głównej treści
Guardrail na etapie wejścia sprawdza żądanie wywołującego zanim dotrze do modelu. To najtańsze miejsce na egzekwowanie polityki treści: brama inspekcjonuje prompt na wejściu, a jeśli reguła zablokuje, żądanie jest odrzucane przed pomiarem — nie płacisz nic za wywołanie. To tutaj zatrzymujesz wyciekły sekret, pole PII lub próbę injection, zanim w ogóle trafi do modelu nadrzędnego. Pełny silnik — każdy typ reguły, pole i trasę — znajdziesz w referencji Guardrails. Ta strona to skupione ujęcie etapu wejścia: co biegnie przed modelem i dlaczego blokada tutaj nie kosztuje kwoty.

​
1. Guardrails wejścia dla aplikacji LLM, przed modelem

Każda reguła guardrail niesie etap — input, output lub both. Reguła input biegnie wobec tekstu żądania w chwili, gdy przybywa, w drodze do modelu nadrzędnego: 
caller → [ input guardrail ] → metering → model → [ output guardrail ] → caller
Ta kolejność jest sednem. Reguła wejścia widzi prompt, zanim brama wstępnie pobierze jakąkolwiek kwotę, więc blokada na tym etapie jest darmowa — żądanie nigdy nie dociera do modelu i nigdy nie nalicza. Porównaj etap wyjścia, który sprawdza odpowiedź modelu po jej powrocie (blokada wyjścia zamiast tego zwraca wstępnie pobraną kwotę).
Reguły wejścia sprawdzają żądanie wywołującego. Jeśli używasz też promptów z rejestru, wstrzyknięta wiadomość systemowa jest dodawana później w routingu — więc reguły wejścia widzą wiadomości, które wysłała twoja aplikacja, nie wstrzyknięty prompt. Reguły wyjścia sprawdzają odpowiedź w obu przypadkach.

​
2. Co możesz uruchomić na etapie wejścia

Każdy typ reguły może biec na input. Najczęstsze powody, by bramkować żądanie przed modelem:

Maskuj PII w prompcie

Reguła pii z akcją mask przepisuje encje na typowane tagi (jane@acme.com → [EMAIL]), więc model nadrzędny nigdy nie widzi surowej wartości. Zobacz PII Shield.

Blokuj sekrety, zanim wyciekną

Żądanie niosące klucz API lub poświadczenie chmurowe jest odrzucane już u progu — przed pomiarem, bez wywołania w górę. Zobacz Blokuj sekrety.

Zatrzymaj próby injection

Preset podstaw Prompt-Injection łączy detektory keyword/regex z regułą llm_judge dla intencji injection. Zobacz Prompt injection.

Ogranicz rozmiar promptu

Reguła max_chars odrzuca zbyt duży prompt, zanim naliczy jakiekolwiek tokeny. Zobacz Guardrails kosztów.
Siedem typów reguł — keyword, regex, pii, max_chars, external, llm_judge, grounding — i pięć akcji block, mask, flag, annotate oraz spotlight stosuje się tutaj. (spotlight owija dopasowany niezaufany tekst w ograniczniki, by model traktował go jako dane, nie instrukcje — obrona przed prompt-injection na etapie wejścia; annotate dokleja notatkę bez zmiany ruchu.) Jeden wyjątek wart poznania: grounding mierzy odpowiedź wobec pobranych źródeł, więc jest z natury sprawdzeniem na etapie wyjścia. Wszystko inne naturalnie pasuje do etapu wejścia.
Maskowanie na etapie wejścia działa już dziś — streaming lub nie. Brama przepisuje żądanie, zanim model je zobaczy, na każdej ścieżce. Mask na wyjściu redaguje wyłącznie odpowiedzi nie-streamingowe; przepisywanie wyjścia w locie jest w planach, więc reguła mask nie redaguje jeszcze odpowiedzi streamingowej. Block na wyjściu, dla kontrastu, jest egzekwowany w obie strony — streaming i nie-streaming (zobacz Pokrycie streamingu).

​
3. Jeden konkretny przykład

Autorzuj regułę w konsoli (pod twoją własną sesją — konfiguracja guardrail wymaga Developer+), nie kluczem relay. Dodaj jedną regułę input do guardrail o nazwie secrets-shield: 
{
  "type": "regex",
  "stage": "input",
  "action": "block",
  "pattern": "sk-[A-Za-z0-9]{20,}"
}
Powiąż guardrail z kluczem (ustaw guardrail_id lub oznacz go jako domyślny przestrzeni roboczej — zobacz Powiąż z kluczem), potem wywołaj bramę tym kluczem relay sk-orca-...: 
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": "Debug this: OPENAI_API_KEY=sk-abcdefghij1234567890"}
    ]
  }'
Żądanie dopasowuje się na etapie wejścia i jest odrzucane z HTTP 400 guardrail_blocked, zanim brama prześle cokolwiek w górę: 
{
  "error": {
    "type": "guardrail_blocked",
    "message": "request blocked by guardrail \"secrets-shield\": regex(...)"
  }
}
Zobacz błąd guardrail_blocked po pełny kształt odpowiedzi.

​
4. Dlaczego blokada wejścia nie kosztuje kwoty

To strukturalna przewaga wychwytywania rzeczy na wejściu. Blokada na etapie wejścia siedzi przed wstępnym pobraniem, więc:
WłaściwośćBlokada na etapie wejścia
Status HTTP400 guardrail_blocked
Naliczona kwotaŻadna — działa przed pomiarem
Wywołanie w góręNigdy nie wykonane
PonowienieOznaczone skip-retry — ponowne uruchomienie znów blokuje
Ponieważ żądanie nigdy nie dociera do kanału, blokada wejścia jest oznaczona jako skip-retry: ponowne uruchomienie tego samego promptu na innym kanale po prostu znów by zablokowało i zmarnowało wysiłek. Etap wyjścia różni się — blokada tam zwraca kwotę, którą brama już wstępnie pobrała. To samo 400, inna księgowość.

​
5. Rozwiązywanie i fallback

Reguła na etapie wejścia biegnie tylko, jeśli guardrail faktycznie rozwiąże się na żądaniu. Rozwiązywanie jest jawne:
  1. Jawny guardrail_id klucza, jeśli istnieje i jest włączony.
  2. W przeciwnym razie domyślny guardrail przestrzeni roboczej.
  3. W przeciwnym razie żaden — żądanie jest bajt-identyczne z przestrzenią roboczą bez polityki.
Jawne powiązanie nigdy po cichu nie wraca. Wyłączenie powiązanego guardrail to przełącznik off — nie spada do domyślnego przestrzeni roboczej. (Polityki firewalla zachowują się tu inaczej; zobacz Guardrails vs. firewall.)

​
6. Udowodnij to, zanim wyślesz

Nie wiąż blokującej reguły wejścia z żywym ruchem na wiarę. Dwa sposoby, by najpierw zwalidować:
Otwórz zakładkę Test w edytorze guardrail, wklej próbkę, wybierz etap input i uruchom. Piaskownica ewaluuje bieżącą politykę lokalnie — bez wywołania w górę, bez kwoty — i zwraca werdykt oraz (dla reguł mask) wyrenderowany tekst. Zobacz Testowanie i eval.
Ustaw akcję najpierw na flag. Flag nie zmienia nic w ruchu — tylko rejestruje dopasowanie — więc możesz zmierzyć, jak często reguła by zadziałała na rzeczywistym wejściu, zanim przełączysz ją na block. Zobacz Strojenie fałszywie pozytywnych.
Każda reguła, która zadziała, rejestruje dopasowanie — typ, akcję, etap i łańcuch szczegółów. Dopasowany podłańcuch jest rejestrowany tylko, gdy Log raw content jest włączone (domyślnie wyłączone). Zobacz Strumień dopasowań i Logowanie i prywatność.

​
7. Dokąd dalej

Etap wejścia zatrzymuje złe wejście przed dotarciem do modelu. Aby bramkować odpowiedź modelu, sparuj go z etapem wyjścia; aby rządzić wywołaniami narzędzi agenta, użyj firewalla. Przeczytaj referencję Guardrails po kompletny silnik albo szybki start bezpieczeństwa, aby spiąć guardrails wejścia i firewall razem dla bazy agenta.