Перейти к основному содержанию
Если ваше приложение стримит, вам нужен один прямой ответ, прежде чем вы доверитесь контентной политике: что реально применяется на SSE-ответе. Guardrail, который инспектирует целый ответ, легко осмыслить; guardrail, который должен действовать на дельтах по мере их сброса в браузер, — нет. Эта страница — матрица покрытия стриминговых guardrail — каждое действие, по стадиям input и output, на стриминговом и нестриминговом трафике — написанная, чтобы быть точной в том, как каждая ячейка ведёт себя на живом потоке. Полный движок — каждый тип правила, поле и маршрут — см. в Guardrails. Механику того, как поток режется, см. в stream-safe правилах.

​
1. Вопрос покрытия стриминговых guardrail

Правило guardrail несёт стадию (input, output или both) и действие — одно из пяти: block, mask, flag, annotate или spotlight. Стадия решает, когда шлюз его выполняет; действие решает, что оно делает. Единственное место, где стриминг меняет форму ответа, — стадия output — потому что это единственная стадия, где шлюз пересылает байты вашему клиенту по мере их прибытия, без шанса сначала удержать всю полезную нагрузку. Так что в матрице две ячейки, где стриминг важен, и они ведут себя по-разному: output block полностью применяется на потоке (сканер его режет), но output mask применяется только на нестриминговых ответах. На стриминговом ответе сканер всё равно детектирует совпадение и может отработать решение block, но он не переписывает замаскированный текст в поток сегодня — маскирование стримингового вывода in-band в дорожной карте.
Input никогда не проблема. Правила стадии input выполняются до модели — шлюз проверяет (и, для mask, переписывает) ваш запрос, затем пересылает очищенную версию вышестоящей системе. Будет ли ответ стримить, неважно; запрос — это полная полезная нагрузка, которую шлюз держит целиком. Сканирование input полностью живое, включая маскирование, на каждом запросе.

​
2. Матрица покрытия

Читайте её сверху вниз. Каждая ячейка block жива, включая стриминг — но output + mask + стриминг — это та одна ячейка, которая не применяется в потоке: правило mask редактирует нестриминговый ответ, а на стриминговом ответе детектирует совпадение, не переписывая дельту (маскирование вывода in-stream в дорожной карте).
Стадия · действиеНестримингСтриминг
input · blockотклоняет запросотклоняет запрос
input · maskпереписывает запроспереписывает запрос
output · blockотклоняет ответрежет поток
output · maskредактирует ответдетектирует совпадение; не редактирует in-stream (дорожная карта)
любая · flagтолько записываеттолько записывает
annotate и spotlight прикрепляют заметку (или оборачивают совпавший текст), не отклоняя трафик, и на практике являются действиями стадии input, так что они не меняют ячейки output/стриминг выше; они записывают совпадение, как любое другое правило.
Правила стадии input проверяют запрос до запуска вышестоящей модели. block короткозамыкает вызов (HTTP 400 guardrail_blocked, до тарификации, так что он не стоит квоты). mask переписывает совпавшие поля в промпте на месте — очищенный текст это то, что идёт вышестоящей системе, и модель никогда не видит оригинал. Ничего из этого не зависит от того, стримится ли ответ.
На нестриминговом ответе завершение проверяется целиком до того, как вернётся — блокировка всплывает как HTTP 400 guardrail_blocked. На стриминговом ответе сканер потока наблюдает за дельтами по мере их потока; когда правило block срабатывает, оно режет поток — запечатывает сканер, выдаёт короткое уведомление-замену вместо остального и закрывает SSE-канал прежде, чем дальнейший заблокированный контент дойдёт до клиента. Поскольку заголовки SSE 200 к тому моменту уже ушли, блокировка на стриминге не может вернуть 400: она доставляет блокировку как финальную дельту in-band, а не HTTP-ошибку.
На нестриминговом ответе правило mask переписывает завершение — например, email становится [EMAIL] — и очищенный текст это то, что получает ваш клиент. На стриминговом ответе сканер потока всё равно детектирует совпадение и вычисляет маску, но он не пересылает замаскированный текст в дельту — замаскированный вывод отбрасывается, и отрабатывается только решение block. Так что правило mask не редактирует стриминговый ответ сегодня; маскирование стримингового вывода in-band в дорожной карте. Если вам нужно держать PII вне стримированного ответа прямо сейчас, создайте правило как block (сканер режет поток на совпадении) или проверяйте нестриминг.
Правило flag никогда не меняет трафик — оно записывает совпадение и пропускает байты. Стадия и поток не меняют его поведения. Используйте его, чтобы измерить частоту срабатываний правила, прежде чем продвинуть его в block.
Одна строка для запоминания: output block применяется живо на обоих транспортах — включая стриминг — и маскирование input всегда живое. Output mask редактирует только нестриминговые ответы; на потоке он детектирует совпадение, но пока не переписывает дельту (маскирование вывода in-stream в дорожной карте). Чтобы держать PII вне стримированного ответа сегодня, создайте правило как block или проверяйте нестриминг.

​
3. Один конкретный пример — держите PII вне стримированного ответа

Скажем, модель может вытащить email клиента из RAG-контекста, и ваше приложение стримит. Output mask не редактирует в потоке сегодня (маскирование вывода in-stream в дорожной карте) — так что чтобы держать PII вне стримированного ответа, создайте правило output как block: сканер убивает поток в тот миг, когда появляется совпадение. (Output mask редактирует на нестриминговом ответе.) Редактирование политики — действие управления на вашей сессии консоли (шлюзовано до Developer+); relay-ключ sk-orca-... только отправляет трафик /v1/* и никогда не редактирует политику.
  • Откройте /console/guardrails, New guardrail, назовите его stream-pii-out.
  • Добавьте одно правило:
    • Тип: PII detection
    • Стадия: output
    • Действие: block ← режет поток на совпадении; на потоке mask только детектирует (он редактирует нестриминговые ответы)
  • Сохраните, затем привяжите его на /console/token через выпадающий список Guardrail ключа.
Теперь вызовите шлюз с stream: true, ровно как раньше: 
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"}
    ]
  }'
Если дельта совпадает, сканер режет поток, выдаёт уведомление-замену и закрывает канал — клиент никогда не получает остального. Если ответ чист, каждая дельта стримится нетронутой.
Блокировка на стриминге останавливает всё после совпадения, но не может отправить обратно байты, уже сброшенные до того, как совпадение пришло. Если ваша политика требует, чтобы ни один нарушающий байт никогда не дошёл до клиента, проверяйте запрос нестриминговым, где всё завершение удерживается, пока политика его не очистит.

​
4. PII Shield по матрице

Пресет PII Shield — это единственное правило pii, действие mask, стадия both. Отобразите его на матрицу, и покрытие ровно то, что вы ожидали бы из §2:
  • Стадия input — полностью живо, со стримингом или без. Запрос маскируется до того, как модель его увидит (заголовочная ценность маскирования input).
  • Стадия output, нестриминг — завершение маскируется до того, как вернётся.
  • Стадия output, стриминг — сканер потока детектирует совпадение, но не переписывает дельту сегодня, так что замаскированная форма не доходит до стримированного клиента (маскирование вывода in-stream в дорожной карте).
Так что пресет mask не покрывает PII вне стримированного ответа сам по себе. Чтобы держать PII вне стримированного ответа, создайте то правило как block (или вызывайте нестриминг), чтобы поток резался на совпадении. См. PII Shield и форматы маскирования.

​
5. Что стоит блокировка на стриминге

Блокировка на стриминге несёт тот же учёт, что и любая блокировка output — модель уже отработала, так что шлюз ведёт возврат за вас:
  • На нестриминговом ответе вызов возвращает HTTP 400 guardrail_blocked, называя guardrail и сработавшее правило. На стриминговом ответе заголовки SSE 200 уже на проводе, так что блокировка приходит как финальная дельта-замена in-band и чистое закрытие канала вместо 400.
  • Квота не списывается. Блокировка input срабатывает до тарификации; блокировка output (стриминг или нет) возвращает предварительно списанную квоту после отклонения ответа. В любом случае вызывающий не платит ничего.
  • Запрос помечается skip-retry — повторный прогон того же промпта просто снова заблокировался бы, так что шлюз не будет сжигать повтор на другом канале.
Каждое сработавшее правило output также записывает совпадение в ленте Matches рабочего пространства (GET /api/guardrail/match, открыта любому Member); совпавшая подстрока захватывается только когда у guardrail включён переключатель Log raw content (по умолчанию выключен). Полная деталь живёт в ошибке guardrail_blocked и ленте matches.

​
6. Докажите вашу комбинацию стадии/действия перед шипом

Не угадывайте, какая ячейка матрицы применяется к вашей политике — проверьте её. Оба инструмента выполняются на вашей сессии консоли через management API:

Вкладка Test

У каждого редактора guardrail есть вкладка Test: вставьте образец, выберите стадию и прогоните текущую политику без вышестоящего вызова и без квоты. Увидьте вердикт и, для правил mask, отрендеренный текст. Песочница Test шлюзована до Developer+ (она может запускать платные вызовы judge/grounding и исходящие запросы интеграций).

Вкладка Eval

Вкладка Eval оценивает guardrail против поставляемых или пользовательских JSONL-корпусов — полезно, чтобы подтвердить, что правило block ловит известную утечку, прежде чем привязать ключ. Запуск eval требует только доступа на чтение (viewer+).
См. тестирование и eval и настройку ложных срабатываний за глубиной.

​
7. Куда двигаться дальше

Stream-safe правила

Как сканер режет SSE-поток на лету и как создать политику, которая держится на стриминговом трафике.

Стадия output

Проверка ответа модели — block против mask, возврат квоты и grounding.

Стадия input

Проверка запроса до модели — включая маскирование, со стримингом или без.

Действия

block, mask, flag, annotate и spotlight в деталях — когда каждое правильный выбор.
Guardrails — каждый тип правила, поле и маршрут, включая grounding и LLM judge.