Перейти к основному содержанию
Правила стадии input проверяют то, что вы отправляете модели. Правила стадии output проверяют то, что приходит обратно. Когда вас заботит ответ модели — утёкший секрет в завершении, PII, которую модель вытащила из контекста, ответ, отклоняющийся от извлечённых источников — вам нужно правило, чья стадия — output. Шлюз выполняет его после ответа вышестоящей модели и до того, как хоть один байт дойдёт до вашего клиента. Эта страница покрывает стадию output конкретно: как проверяется завершение, что стоит блокировка и как block и mask ведут себя на стриминговых ответах. Полный движок — каждый тип правила, поле и маршрут — см. в Guardrails.

​
1. За чем команды тянутся к output-guardrails llm

Модель — недоверенная часть цикла. Она может повторить секрет из промпта, вытащить email клиента из RAG-контекста или галлюцинировать утверждение, которого ваши источники никогда не делали. Ничего из этого не видно на стадии input, потому что ничего из этого не существует, пока модель не ответила. Guardrail на стадии output — это проверка самого завершения. Правило выполняется на стадии output, когда его stage — output (или both). Шлюз оценивает текст ответа модели относительно политики, записывает любое совпадение, а затем либо пропускает его, редактирует или отклоняет — ровно те же действия block / mask / flag, что вы используете на input, лишь применённые к ответу.
Правила output — это надстройка, а не замена. Большинство политик проверяют input, чтобы держать данные вне промпта, и output, чтобы ловить то, что возвращает модель. Стадия both привязывает одно правило к обоим концам.

​
2. Один конкретный пример — заблокировать секрет в ответе

Создайте guardrail в консоли (/console/guardrails), добавьте одно правило и привяжите его к ключу:
  • Тип: Secrets / regex-детектор
  • Стадия: output
  • Действие: block
Теперь вызовите шлюз ровно как раньше — relay-ключ только для трафика /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 — клиент никогда не видит утёкший контент. Если он чист, ответ проходит нетронутым.
Создание — это действие консоли / management-API на вашей сессии, шлюзованное до Developer+. Relay-ключ sk-orca-... лишь отправляет трафик; он никогда не редактирует политику.

​
3. Что стоит блокировка output

В отличие от блокировки input — которая срабатывает до тарификации запроса — блокировка output происходит после того, как вышестоящая модель уже отработала. Шлюз ведёт учёт за вас:
  • Заблокированное завершение всё равно возвращает HTTP 400 guardrail_blocked с сообщением, называющим guardrail и сработавшее правило.
  • Квота не списывается. Блокировка output возвращает предварительно списанную квоту после отклонения ответа, так что неудавшийся вызов для вас бесплатен, даже если модель произвела токены.
  • Запрос помечается skip-retry — повторный прогон того же промпта просто снова заблокировался бы, так что шлюз не будет сжигать повтор на другом канале.
Это ключевое отличие от стадии input. Блокировка input бесплатна, потому что тарификация не начиналась; блокировка output бесплатна, потому что предварительно списанная квота возвращается после отклонения ответа. В любом случае вызывающий не платит ничего. См. ошибку guardrail_blocked.

​
4. Стриминг — block против mask

Block применяется на стриминговых ответах; output mask пока нет. Вот как ведёт себя каждое:
На нестриминговом ответе завершение проверяется целиком до того, как вернётся. На стриминговом ответе сканер наблюдает за дельтами по мере их потока; когда правило block срабатывает посреди потока, оно режет поток — сканер запечатывается, выдаёт короткое уведомление-замену вместо остального, и SSE-канал закрывается прежде, чем заблокированный контент дойдёт до клиента.Уже сброшенные байты нельзя отозвать, так что блокировка работает по мере возможностей над тем, что уже отстримилось, но надёжно останавливает всё после совпадения. Для жёсткой гарантии, что ни один нарушающий байт никогда не отправляется, используйте нестриминговый запрос.
На нестриминговом ответе правило mask переписывает завершение — например, email в ответе становится [EMAIL] — и очищенный текст — это то, что получает ваш клиент.На стриминговом ответе правило mask на output сегодня не редактирует ответ. Сканер всё равно оценивает каждую дельту и отработает решение block, но замаскированный текст, который он вычисляет, не пересылается — сырые дельты проходят без изменений. Переписывание стримингового вывода in-band в дорожной карте. Пока оно не зашипится, отправляйте запрос нестриминговым, если вам нужно, чтобы output mask реально редактировал ответ.
На стриминге block действует от совпадения и далее — байты, уже сброшенные до совпадения, нельзя отозвать, так что для жёсткой гарантии по всему ответу проверяйте нестриминг. Output mask сегодня не редактирует стриминговый ответ (маскирование вывода in-stream в дорожной карте) — отправляйте запрос нестриминговым, если вам нужен отредактированный ответ. См. покрытие стриминга и stream-safe правила.
Действие на outputНестримингСтриминг
blockотклоняет ответрежет поток
maskредактирует ответпока не редактируется (дорожная карта)
flagтолько записываеттолько записывает

​
5. Grounding — проверка достоверности на стадии output

Одно продвинутое правило по природе имеет форму output: контекстная заземлённость. Правило grounding оценивает ответ модели относительно источников, извлечённых на запросе (ваш RAG-контекст), и срабатывает, когда достоверность падает ниже порога (по умолчанию 0.7). Сочетайте его с block, чтобы отказывать в недостоверных ответах, или с flag, чтобы измерять отклонение перед применением. Оно тарифицируется как под-строка judge, как любое правило с моделью. Полные поля живут в Guardrails.

​
6. PII Shield на стадии output

Пресет PII Shield — это единственное правило pii, действие mask, стадия both. На стадии input оно полностью живое — оно переписывает запрос до модели, на стриминге и нестриминге одинаково. На стадии output оно маскирует нестриминговые завершения, как в §4; на стриминговом ответе output mask сегодня не редактирует ответ (маскирование вывода in-stream в дорожной карте). Так что на стадии output вызывайте нестриминг, если вам нужно, чтобы PII Shield реально редактировал ответ. См. PII Shield и форматы маскирования.

​
7. Просмотр того, что сработало

Каждое сработавшее правило output записывает совпадение — его тип правила, действие, стадию (output) и строку-деталь — в ленте Matches рабочего пространства (GET /api/guardrail/match, открыта любому Member). Совпавшая подстрока записывается только, когда у guardrail включён переключатель Log raw content; он по умолчанию выключен (консервативная по приватности позиция), так что по умолчанию вы видите то, что правило output сработало, а не чувствительный текст, который оно поймало. Ложное срабатывание помечается через POST /api/guardrail/match/:id/mark-fp (Admin) — трактуйте его как сигнал к настройке, а не как причину отключить правило.
Докажите правило output перед шипом. Вкладка Test редактора оценивает текущую политику по образцу текста на стадии output, не списывая квоту рабочего пространства, а вкладка Eval оценивает его относительно поставляемых или пользовательских корпусов. (Правило с моделью — llm_judge или grounding — всё равно делает собственный вызов judge, когда вы запускаете песочницу.) Создание и запуск песочницы — действия Developer+. См. тестирование и eval и настройку ложных срабатываний.

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

Стадия input

Зеркальное отражение — проверьте запрос до того, как модель его увидит. Маскирование input полностью живое, включая стриминг.

Действия

block, mask и flag в деталях — когда каждое из них правильный выбор.

Покрытие стриминга

Полная матрица того, что применяется на стриминге против нестриминга.

Ошибка guardrail_blocked

HTTP 400, возврат квоты и поведение skip-retry.
Guardrails — каждый тип правила, поле и маршрут, включая grounding и LLM judge.