Перейти к основному содержанию
У вас есть список терминов, которые никогда не должны дойти до модели или вернуться от неё — имя конкурента, внутреннее кодовое имя, запрещённое оскорбление, ещё не анонсированный продукт. Самый быстрый контроль для этого — keyword-denylist: список литеральных терминов, которые шлюз сканирует на каждом вызове и затем блокирует, маскирует или флагирует. Это сфокусированная посадочная страница для сценария запрещённых терминов. Полный движок guardrail — каждый тип правила, поле и маршрут — см. в справочнике Guardrails.

​
1. Сценарий фильтра чувствительных слов ai

Правило keyword — простейшее правило в движке: вы даёте ему список терминов, и шлюз сопоставляет любой из них с текстом на стадии. Сопоставление — подстрока без учёта регистра — BadWord, badword и BADWORD все совпадают, и термин совпадает, даже когда он встроен в более длинное слово (так что class также совпадает с classic). Каждый термин трактуется как литеральная строка, а не паттерн; вы не экранируете regex-метасимволы. Сохраните правило один раз в консоли, привяжите guardrail к любому API-ключу (или сделайте его default’ом рабочего пространства), и каждый вызов на этом ключе проверяется без изменения SDK и без передеплоя. Политика живёт в шлюзе, а не в вашем приложении — ваше приложение продолжает вызывать /v1/chat/completions ровно как раньше.
Тянитесь к правилу keyword, когда ваш denylist — конечный набор литеральных терминов. Когда вам нужны wildcard’ы, границы слов или структура (формат SKU, форма номера заказа), используйте вместо этого regex-детектор.

​
2. Создайте правило в консоли

Каждый шаг здесь — действие консоли под вашей собственной сессией. Создание и редактирование guardrails требует Developer+ в рабочем пространстве. Только финальный вызов /v1/* использует relay-ключ sk-orca-....
1

Создайте guardrail

В консоли откройте Guardrails и нажмите New guardrail. Назовите его (≤ 64 символов), например banned-terms.
2

Добавьте правило keyword

Добавьте одно правило:
  • Тип: Keyword denylist (keyword)
  • Стадия: Both (запрос и ответ)
  • Действие: Block
  • Keywords: ваши запрещённые термины, по одному на строку
Сохраните.
3

Протестируйте

Откройте вкладку Test, вставьте образец, содержащий запрещённый термин, выберите стадию и прогоните политику локально — без вышестоящего вызова, без квоты (см. §5).
4

Привяжите ключ

Отредактируйте API-ключ и выберите banned-terms из выпадающего списка Guardrail (устанавливает guardrail_id на ключе) или пометьте guardrail default’ом рабочего пространства. См. Привязка к ключу и Default аккаунта.
JSON правила — ровно то, что вы ожидаете: 
{
  "type": "keyword",
  "stage": "both",
  "action": "block",
  "keywords": ["project-orca", "competitor-name", "unannounced-sku"]
}

​
3. Выберите действие

Правило keyword выбирает одно действие на правило:
Любое совпадение отклоняет запрос с HTTP 400 guardrail_blocked. Заблокированный запрос не стоит квоты — блокировка на стадии input срабатывает до тарификации; блокировка на стадии output возвращает предварительно списанную квоту — и помечается skip-retry. Используйте для терминов, которые никогда не должны пройти ни в одном направлении. См. ошибку guardrail_blocked.
Каждое совпадение заменяется на месте тегом редактирования, и запрос продолжается с очищенным текстом — вышестоящая модель никогда не видит исходный термин. См. Действия.
Записывает совпадение и ничего не меняет в трафике. Используйте, чтобы измерить, как часто термин появляется, прежде чем переключиться на применение.
Оборачивает совпавший текст в разделители (например, ⟦UNTRUSTED⟧…⟦/UNTRUSTED⟧), чтобы модель трактовала его как данные, не инструкции — защита от prompt-инъекции на стадии input. Текст всё равно доходит до модели, лишь огороженный. См. Действия.
Стадия важна. input сканирует запрос вызывающей стороны, output сканирует ответ модели, both сканирует каждую сторону независимо. Запрещённый термин, который печатают ваши пользователи, и тот, который может выдать модель — разные проблемы — выбирайте подходящую стадию(и). См. Правила стадии input и Правила стадии output.

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

Действие, которое вы выбираете, взаимодействует с тем, стримится ли ответ:
ДействиеНестримингСтриминг
block (output)ПрименяетсяПрименяется — сканер режет поток
mask (output)ПрименяетсяПока нет — решение block соблюдается, замаскированный текст не пересылается (дорожная карта)
Правила стадии input выполняются до вышестоящего вызова, так что не затронуты стримингом — input mask очищает запрос независимо от того, стримится ли ответ. Block запрещённого термина получает полное покрытие в любом случае. Output mask, однако, сегодня редактирует только на нестриминговых ответах: на стриминговом ответе сканер всё равно отрабатывает решение block, но переписывание стримированного текста in-band в дорожной карте, не живо. См. Покрытие стриминга.

​
5. Протестируйте перед привязкой

Докажите, что правило делает то, что вы ожидаете, прежде чем на него укажет любой ключ. Откройте вкладку Test внутри редактора, вставьте образец, выберите стадию и запустите: 
Tell me about Project-Orca and our competitor-name
Песочница оценивает текущую политику локально и возвращает вердикт — ничего не отправляется вышестоящей системе, ничего не тарифицируется. С действием block образец отклоняется; с mask отрендеренный текст возвращается с каждым отредактированным термином. Для A/B-сетки против корпуса — чтобы подтвердить, что denylist ловит то, что должен, не флагируя безобидный трафик — eval-харнесс живёт одной вкладкой дальше.

​
6. Отправьте запрос

Используя ключ, привязанный к banned-terms, вызовите OrcaRouter ровно как раньше — без новых заголовков, без изменения SDK: 
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": "Summarize Project-Orca for me"}
    ]
  }'
С действием block вызов отклоняется с HTTP 400 guardrail_blocked до того, как он вообще дойдёт до модели. Смените действие на mask, и термин вместо этого редактируется на месте перед пересылкой.

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

Каждое сработавшее правило записывает совпадение — тип правила, действие, стадию и строку-деталь (для правил keyword — сколько терминов совпало) — всплывающее в ленте Matches рабочего пространства.
Сам совпавший термин записывается только, когда включён Log raw content, который по умолчанию выключен — консервативная по приватности позиция. С ним выключенным вы всё равно видите, что правило keyword сработало и как часто, лишь не литеральный термин. Включайте его для каждого guardrail, когда нужна подстрока для сортировки; настройка не ретроактивна. См. Ленту Matches и Логирование и приватность.
Если безобидный термин продолжает совпадать (запись denylist, которая является подстрокой распространённого слова), пометьте его ложным срабатыванием из ленты Matches и ужесточите запись. См. Настройку ложных срабатываний.

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

Regex-детекторы

Сопоставляйте структурированные паттерны — SKU, номера заказов, форматы — когда литерального denylist недостаточно.

Защита бренда

Пресеты ненормативной лексики, упоминаний конкурентов и детской безопасности, построенные на правилах keyword.

Действия

Чем block, mask и flag отличаются и когда использовать каждое.

Справочник Guardrails

Полный движок — каждый тип правила, поле и маршрут.
Keyword-denylist управляет содержимым. Чтобы управлять вызовами инструментов агента — запрещать деструктивные действия, редактировать аргументы вызовов инструментов, требовать подтверждения — используйте Firewall. Для нечётких политик, которые не может выразить ни один литеральный список (токсичность, оффтопик, намерение инъекции), правило llm_judge выполняет семантическую проверку моделью рабочего пространства.