Перейти к основному содержанию
Каждое правило guardrail отвечает на три вопроса — что искать (тип), где искать (стадия) и что с этим делать (действие). Эта страница — про третий выбор. Действие правила — самое значимое поле в нём: оно решает, останавливает ли совпадение запрос, тихо переписывает его или лишь оставляет хлебную крошку. Конструктор правил предлагает пять действий всего — block, mask, flag, annotate и spotlight. Эта страница покрывает три варианта применения, к которым тянутся первыми: block, mask и flag. Выберите одно на правило (или, для правила PII, направьте разные сущности к разным действиям; см. §5). Два других — действия формирования промпта, не блокирующие: annotate внедряет заметку безопасности вышестоящей системе (см. безопасность кода), а spotlight оборачивает совпавший недоверенный ввод в разделители, чтобы модель трактовала его как данные, а не инструкции. Полный реестр живёт в обзоре Guardrails. Более широкий движок — типы правил, стадии, привязка политики к ключу — начните с обзора Guardrails или полного справочника Guardrails.

​
1. Решение block mask flag в одну строку

block

Отклонить вызов с HTTP 400 guardrail_blocked. Модель никогда не запускается (стадия input) или её ответ никогда не возвращается (стадия output).

mask

Отредактировать каждое совпадение — например, jane@acme.com → [EMAIL] — и пропустить очищенный текст дальше. Запрос продолжается.

flag

Ничего не менять в трафике. Записать совпадение в ленту и двигаться дальше. Только наблюдение.
Это три действия применения. Какое бы вы ни установили, оно соблюдается везде, где выполняется правило — конструктор правил в консоли, песочница Test и боевой путь ретрансляции /v1/* читают одно и то же значение block / mask / flag.

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

Вот один guardrail, чьи три правила каждое выбирают разное действие. Вы создаёте его в консоли (/console/guardrails) на своей сессии — relay-ключ sk-orca-... только для вызовов /v1/*, никогда для редактирования политики. Создание или редактирование guardrail требует роли Developer+. 
{
  "rules": [
    { "type": "keyword", "stage": "input",  "action": "block",
      "keywords": ["internal-only", "do-not-share"] },
    { "type": "pii",     "stage": "input",  "action": "mask",
      "entities": ["email", "phone"] },
    { "type": "regex",   "stage": "output", "action": "flag",
      "pattern": "(?i)acme\\s+confidential" }
  ]
}
Что делает каждое правило на запросе:
  • Правило block отклоняет любой промпт, содержащий один из этих литеральных терминов — HTTP 400, модель никогда не запускается.
  • Правило mask переписывает emails и номера телефонов в [EMAIL] / [PHONE] в промпте до того, как модель его увидит.
  • Правило flag наблюдает за выводом модели на предмет конфиденциального маркера и записывает совпадение, не меняя ответ — так что вы можете измерить, как часто он появляется, прежде чем решить применять.
Движок выполняет каждое применимое правило и сворачивает результаты в один вердикт. Если любое правило блокирует, запрос блокируется.

​
3. block — отклонить с HTTP 400

Действие block отклоняет весь вызов. Вызывающий получает HTTP 400 с кодом ошибки guardrail_blocked и сообщением, называющим guardrail и сработавшее правило.
Блокировка на стадии input срабатывает до тарификации, так что ничего не потребляется. Блокировка на стадии output возвращает предварительно списанную квоту после отклонения ответа. В любом случае вызывающий не платит за заблокированный вызов ничего.
Результат guardrail_blocked помечен skip-retry — повторный прогон того же промпта по другому каналу просто снова заблокировался бы, так что шлюз не тратит повтор. См. ошибку guardrail_blocked.
На нестриминговом ответе ответ проверяется до того, как вернётся. На стриминговом ответе сканер режет поток на лету и выдаёт сообщение-замену прежде, чем заблокированный контент дойдёт до клиента. См. покрытие стриминга.
Тянитесь к block, когда совпадение означает, что запрос не должен продолжаться — секреты в промпте, попытка jailbreak, жёсткая линия комплаенса.

​
4. mask — отредактировать и продолжить

Действие mask редактирует каждое совпадение и пропускает запрос дальше с очищенным текстом. Вышестоящая модель никогда не видит оригинал. На правиле PII каждое совпадение заменяется типизированным тегом, выведенным из сущности — email становится [EMAIL], SSN становится [SSN], кредитная карта [CREDIT_CARD] и так далее. (Вы можете переопределить строку замены для каждой пользовательской сущности; см. форматы маскирования.)
Маскирование на стадии input живо на каждом потоке. Оно переписывает запрос до того, как модель запустится, со стримингом или без. Маскирование на стадии output применяется только к нестриминговым ответам — замаскированный текст пересылается после того, как полный ответ проверен. На стриминговом ответе шлюз вычисляет маску, но пока не пересылает отредактированный текст, так что правило mask сегодня не редактирует стриминговый ответ; маскирование вывода in-stream в дорожной карте. (Output block всё равно режет поток на лету — см. §3.) Сначала докажите вашу конкретную комбинацию стадии/потока в песочнице. См. покрытие стриминга.
Тянитесь к mask, когда содержимое в порядке, но подстрока не должна дойти до модели — редактирование PII каноничный случай. Готовая отправная точка — пресет PII Shield; см. PII Shield.

​
5. flag — только лог, ничего не меняет

Действие flag — только наблюдение: запрос побайтно идентичен тому, что без правила вообще, за исключением того, что совпадение записывается в ленту Matches. Ничего не блокируется, ничего не редактируется.
flag — это то, как вы измеряете правило перед его применением. Зашипите новое keyword или regex как flag, понаблюдайте за лентой Matches несколько дней, чтобы увидеть его реальную частоту истинных и ложных срабатываний на боевом трафике, затем продвиньте его в mask или block, как только начнёте ему доверять. Настройка шумного паттерна с flag бьёт обнаружение ложных срабатываний в проде с block. См. настройку ложных срабатываний.
Флагированное совпадение записывает тип правила, действие, стадию и строку-деталь — а совпавшую подстроку только если Log raw content включён для этого guardrail (по умолчанию выключен, консервативная по приватности позиция). См. логирование и приватность.

​
6. Переопределения действия по сущности

Одно правило PII может направлять разные сущности к разным действиям через entity_actions, вместо стопки перекрывающихся правил. Каждое значение переопределения должно быть одним из block / mask / flag / annotate и должно ссылаться на сущность, которую правило уже объявляет — валидатор отклоняет всё остальное. 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
Это одно правило маскирует emails, phones и IP, но блокирует запрос целиком на номере карты или SSN. См. пользовательские сущности PII для наслаивания собственных детекторов под той же моделью переопределения.

​
7. Выбор правильного действия

Если вы хотите…ИспользуйтеЭффект
Остановить запрос целикомblockHTTP 400, нет квоты, skip-retry
Убрать подстроку, сохранить вызовmaskОтредактированный текст переслан
Наблюдать, не трогая трафикflagТолько записано совпадение
Действия компонуются со стадиями. То же действие ведёт себя немного по-разному на input против output — блокировка input экономит квоту заранее; блокировка output её возвращает; маскирование output применяется только к нестриминговым ответам, тогда как блокировка output режет стриминговые и нестриминговые ответы одинаково. Прочтите стадию input и стадию output рядом с этой страницей.

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

Ошибка guardrail_blocked

Как выглядит 400, почему он не стоит квоты и как работает skip-retry.

Форматы маскирования

Типизированные теги, пользовательские строки замены и как замаскированный промпт читается модели.

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

Точно какие комбинации действие × стадия × поток применяются сегодня.

Режимы применения

Как block / mask / flag отображаются на более широкую модель применения шлюза, включая audit-вердикт firewall.
У firewall свой словарь вердиктов (allow, audit, deny, sanitize и другие) для политики инструментов — отдельный от этих контентных действий. См. guardrails vs. firewall.