Перейти к основному содержанию
Слишком ретивый guardrail хуже, чем никакого guardrail — ваша команда учится игнорировать ленту Matches, или вы ослабляете правило и теряете ловлю, которую реально хотели. OrcaRouter даёт вам точный средний путь: пометьте одно совпадение как ложное срабатывание, и движок запомнит эту находку и пропустит её на будущих запросах — не трогая правило, не ослабляя паттерн и не шипя изменение SDK. Это сфокусированная посадочная страница для рабочего процесса ложных срабатываний. Полный движок guardrail — каждый тип правила, поле и маршрут — см. в справочнике Guardrails.
Каждый шаг здесь — действие консоли на хостед-шлюзе (api.orcarouter.ai). Вы сортируете совпадения под собственной сессией; только финальный вызов /v1/* использует relay-ключ sk-orca-.... Пометка совпадения как ложного срабатывания требует роли Admin рабочего пространства; чтение ленты Matches и результирующего списка подавлений открыто каждому участнику.

​
1. Снижайте ложные срабатывания guardrail, не ослабляя правило

Инстинкт, когда правило слишком срабатывает, — ослабить его: расширить regex-исключение, убрать сущность, переключить block на flag. Это меняет одно ложное срабатывание на дыру в политике. Подавление через mark-false-positive — хирургическая альтернатива:

Подавите одну находку

Заглушите ровно то совпадение, которое дало осечку — конкретную подстроку под конкретным правилом — а не всё правило. Следующее подлинно чувствительное попадание всё равно срабатывает.

Без редактирования правила, без передеплоя

Подавление живёт в шлюзе как память рабочего пространства. Правило остаётся ровно как написано; ваше приложение продолжает вызывать /v1/* неизменным.

Память на всё рабочее пространство

Один Admin помечает его один раз; подавление дедуплицируется по рабочему пространству, так что трафик каждого участника выигрывает — без раскладки по ключам.

Обратимо

Снимите пометку с совпадения (или удалите подавление), и находка снова срабатывает на следующем запросе. Ничего не уничтожается.
Подавление — для находки, которую вы сочли безобидной. Если целое правило откалибровано неверно — неправильная форма, неправильная стадия — исправьте правило и докажите это в eval-харнессе вместо заглушения совпадения за совпадением.

​
2. Как совпадение становится подавлением

Каждое сработавшее правило записывает совпадение в ленте Matches рабочего пространства — тип правила, действие, стадия и строка-деталь. Когда вы помечаете одно из этих совпадений как ложное срабатывание, шлюз выводит стабильный отпечаток для находки и пишет его в список подавлений рабочего пространства. На каждом будущем запросе движок сверяет отпечаток каждой находки с этим списком и пропускает подавленную прежде, чем она сможет заблокировать, замаскировать или флагировать. Два вида находок производят отпечаток:
Находка CVE / SBOM уже поставляется со стабильной идентичностью — идентичность уведомления или компонента путешествует с находкой. Подавление одной заглушает ровно тот CVE/компонент, и только его. Это нативный случай, для которого хранилище подавлений было построено.
Keyword, regex, PII и другие детерминированные типы правил не несут собственной идентичности, так что шлюз синтезирует её из данных, идентичных на стороне записи (ваш клик mark-FP) и стороне применения (следующий запрос): guardrail, идентичность сопоставления правила и — когда сырой захват включён — сами совпавшие подстроки.
Точность синтетического отпечатка зависит от Log raw content, который по умолчанию выключен. С захватом включённым отпечаток ориентируется на точную совпавшую подстроку, так что подавление ORD-48291507 заглушает этот номер заказа и ничего больше. С захватом выключенным нет подстроки для ориентации, так что подавление откатывается к заглушению на уровне правила — оно заглушает то одно правило (на той стадии) для рабочего пространства. Откат никогда не дотягивается за правило, из которого он пришёл. См. Логирование и приватность.

​
3. Один конкретный пример

Скажем, вы прогоняете правило regex, которое маскирует внутренние номера заказов в форме ORD- плюс восемь цифр. Тикет поддержки законно цитирует ORD-48291507 способом, который вы решили нормально пропустить. Вы не хотите ослаблять правило — вы лишь хотите, чтобы этот один номер перестал срабатывать.
1

Откройте ленту Matches

В консоли откройте Guardrails → Matches. Отфильтруйте по guardrail и типу правила, чтобы найти строку для попадания ORD-48291507. (Чтобы видеть литеральную подстроку, Log raw content guardrail должен был быть включён, когда совпадение записывалось — он по умолчанию выключен.)
2

Пометьте его ложным срабатыванием

Откройте деталь совпадения и выберите Mark as false positive. Как Admin рабочего пространства, это штампует совпадение и зеркалит подавление рабочего пространства, ориентированное на отпечаток находки.
3

Подтвердите, что оно подавлено

Откройте список Suppressions — новая запись появляется, помеченная guardrail и правилом, из которых она пришла, и причиной «Marked as false positive from Matches». Каждый участник рабочего пространства может читать этот список.
4

Отправьте тот же запрос снова

Используя ваш relay-ключ, вызовите 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": "Status of order ORD-48291507?"}
    ]
  }'
Подавленная находка пропускается — ORD-48291507 проходит — тогда как любой другой номер заказа всё равно совпадает и маскируется как раньше.

​
4. Подавление против альтернатив

Подавление — один из четырёх способов утихомирить шумное правило. Выбирайте самый узкий, который подходит:
ПодходЧто меняетКогда тянуться к нему
Mark FPОдну находку (или одно правило, захват выкл)Конкретное безобидное попадание; правило в остальном верно
Редактировать правилоСамо сопоставлениеНеправильная форма/стадия — исправьте, затем re-eval
Действие flagТолько наблюдение, без блокировкиНовое правило, которому вы пока не доверяете
Eval-харнессНичего живого — измеряетДоказательство точности перед шипом
Не замазывайте систематически неправильное правило, помечая FP за FP. Если вы подавляете ту же форму многократно, правило откалибровано неверно — заякорите regex, сузьте список keyword или выберите более строгую сущность PII и проверьте eval-прогоном.

​
5. Отмена подавления

Ничего здесь не в одну сторону:
  • Снимите пометку с совпадения — то же действие Admin, обращённое, убирает FP-штамп совпадения и (когда никакое другое FP-помеченное совпадение всё ещё не отображается на него) сбрасывает подавление. Находка снова срабатывает на следующем запросе.
  • Удалите подавление напрямую — из списка Suppressions действие Developer+ убирает запись. Тот же эффект: находка снова жива.
Поскольку подавления — память рабочего пространства, отмена одной восстанавливает ловлю для трафика каждого участника сразу — так же, как пометка подавила её для всех.

​
6. Поверхность API

Это маршруты консоли, аутентифицируемые вашей сессией — не relay-ключами. Шлюзуйте по роли каждое действие: пометка совпадения FP — Admin; чтения подавлений — Member; записи подавлений — Developer+.
Метод и путьРольНазначение
GET /api/guardrail/matchMemberПеречислить совпадения для сортировки.
POST /api/guardrail/match/:id/mark-fpAdminПометить совпадение как ложное срабатывание (зеркалит подавление).
DELETE /api/guardrail/match/:id/mark-fpAdminСнять пометку — восстановить находку.
GET /api/guardrail/suppressionsMemberПеречислить активные подавления рабочего пространства.
POST /api/guardrail/suppressionsDeveloper+Добавить подавление напрямую.
DELETE /api/guardrail/suppressions/:idDeveloper+Убрать подавление.
Эндпоинты mark-FP rate-limited — это намеренное, низкообъёмное действие сортировки, а не bulk-API. Тянитесь к eval-харнессу, а не к циклу вызовов mark-FP, когда настраиваете целую политику.

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

Лента Matches

Где попадает каждое сработавшее правило — место, откуда вы сортируете, прежде чем что-либо помечать.

Тестирование и eval

Докажите точность правила против корпуса перед шипом — систематическое исправление, когда подавление лечит симптом.

Логирование и приватность

Как Log raw content контролирует, ориентируется ли подавление на точную подстроку или откатывается к заглушению на уровне правила.

Справочник Guardrails

Полный движок — каждый тип правила, действие и маршрут.
Подавление управляет контентными находками. Чтобы утихомирить шумное правило agent firewall — совпадение инструмента, которое вы сочли безопасным — это отдельная поверхность; см. Firewall и его ленту аномалий. Чтобы понять, где разделяются guardrails и firewall, прочтите Guardrails vs Firewall.