Перейти к основному содержанию
Проверки безопасности важны только тогда, когда они реально выполняются — но не стоит жертвовать пропускной способностью ради безопасности. Эта страница отвечает на вопрос, который разработчики задают чаще всего: замедлит ли применение моего агента и насколько? Краткий ответ: встроенные правила не стоят ничего измеримого. Продвинутые правила стоят максимум один ограниченный, конкурентный, fail-open вызов модели. Вот почему и как это контролировать.

​
1. Два класса проверок

Каждое правило guardrail и каждая оценка firewall относятся к одному из двух классов.

​
Встроенные / детерминированные проверки

Правила guardrail типа keyword denylist (keyword), регулярное выражение (regex), детектирование PII (pii) и максимальная длина (max_chars) — это чистые локальные строковые операции и операции с regex — никакого вызова модели, никакого сетевого перехода, ничего, что может зависнуть. Оценка правил firewall (сопоставление глобов имён инструментов, предикаты аргументов, область egress) — то же самое: детерминированная и локальная. На практике эти проверки добавляют пренебрежимую задержку вашему запросу. Они безопасны для выполнения на горячем пути и именно из них состоят встроенные шаблоны guardrail.

​
Продвинутые / семантические проверки

Правила llm_judge, grounding и вендора external делегируют проверку модели или вендору. Они стоят сетевой передачи. Три свойства ограничивают эту стоимость:
  1. Конкурентная диспетчеризация. Если ваша политика имеет несколько продвинутых правил, они диспетчеризуются параллельно — одна медленная проверка никогда не сериализуется за другой.
  2. Таймаут на правило. Каждое продвинутое правило имеет таймаут (judge_timeout_ms / grounding_timeout_ms / timeout_ms). Проверка grounding по умолчанию ~3 000 мс; judge использует настраиваемое значение (0 → дефолт движка). Правило ограничено — оно не может зависнуть бесконечно.
  3. Fail-open по умолчанию. Когда правило таймаутит или его вендор возвращает ошибку, событие записывается, но запрос продолжается. Установите judge_fail_open: false (judge) или fail_open: false (external) для перехода к fail-closed вместо этого.
Таким образом, худший случай для любого количества продвинутых правил — это наибольший одиночный таймаут, а не сумма всех таймаутов.

​
2. Краткая сводка

Тип проверкиДобавляет задержку?Как ограничена
Denylist keywordПренебрежимо — локальное строковое сканированиеНет сети; таймаут не нужен
regexПренебрежимо — локальное совпадение RE2Нет сети; таймаут не нужен
Детектирование piiПренебрежимо — локальное сканирование regex/сущностейНет сети; таймаут не нужен
max_charsПренебрежимо — подсчёт символовНет сети; таймаут не нужен
Оценка правил firewallПренебрежимо — сопоставление glob + предикатаНет сети; таймаут не нужен
llm_judgeОдин ограниченный вызов моделиjudge_timeout_ms; fail-open по умолчанию
groundingОдин ограниченный вызов моделиgrounding_timeout_ms (по умолчанию ~3 000 мс); fail-open по умолчанию
Вендор externalОдин ограниченный вызов вендораtimeout_ms; fail_open по умолчанию
Несколько продвинутых правилОдин ограниченный цикл (конкурентная диспетчеризация)Худший случай = макс. одиночный таймаут, не сумма

​
3. Где в жизненном цикле запроса выполняются проверки

Применение происходит не одновременно. Проверка входа и выхода добавляет время в разных местах: 
Клиент
  │
  ▼
[Проверка входных guardrail]     ← добавляет время ЗДЕСЬ, до вышестоящего
  │
  ▼
Вызов вышестоящей модели
  │
  ▼
[Проверка выходных guardrail]    ← добавляет время ЗДЕСЬ, после ответа модели
  │
  ▼
Клиент
Входные guardrails выполняются до вызова вышестоящей модели. Встроенное входное правило добавляет пренебрежимые накладные расходы заранее. Продвинутое входное правило (например, llm_judge, проверяющий на intent prompt injection) добавляет ограниченный вызов модели перед запуском основного вызова модели. Выходные guardrails выполняются после ответа модели. Встроенное выходное правило добавляет пренебрежимые накладные расходы в хвосте. Продвинутое выходное правило (например, grounding, проверяющее достоверность RAG) добавляет ограниченный вызов после того, как у вас уже есть ответ модели. Оценка правил Firewall детерминирована и происходит inline при маршрутизации вызовов инструментов — пренебрежимо, как отмечено выше.
Заблокированный запрос не стоит токенов модели и не добавляет задержки вышестоящего сервиса для блоков на входной стадии. Входной блок срабатывает до тарификации и до вышестоящего вызова, так что вы не платите ни квотой, ни временем вышестоящего перехода. Блок на выходной стадии возвращает предварительно списанную квоту после отклонения ответа.

​
4. Как таймауты и fail-open ограничивают худший случай

Продвинутые правила имеют два регулятора: Таймаут — максимальное реальное время, которое разрешено для проверки. Запрос ждёт не более этого времени для этого правила. Конкурентная диспетчеризация означает, что это ограничение применяется на правило, а не на политику. Если у вас три правила llm_judge каждое с таймаутом 2 000 мс, все три работают одновременно и общее ожидание составляет ~2 000 мс, а не ~6 000 мс. Fail-open vs fail-closed — что делать, когда правило не завершается вовремя (или вендор возвращает ошибку):
НастройкаПоведение при таймауте / ошибке
fail_open: true (по умолчанию)Записать событие; дать запросу продолжиться, как если бы проверка прошла
fail_open: falseТрактовать таймаут / ошибку как блокировку; вернуть HTTP 400 guardrail_blocked
Fail-open сохраняет доступность ценой пропущенной проверки. Fail-closed сохраняет гарантию политики ценой доступности, если judge медленный или недоступен. Выбирайте исходя из того, что важнее для вашего случая использования.

​
5. Практические рекомендации

Держите горячие правила встроенными. Если ваша основная задача — PII, утечка учётных данных, длина промпта или keyword denylist — всё это встроенные правила. Они не добавляют измеримой задержки и должны быть вашим выбором по умолчанию для любой проверки, с которой может справиться сопоставление текста. Используйте llm_judge и grounding там, где нужна семантика. Токсичность, харассмент, детектирование оффтопика, intent prompt-инъекции и достоверность RAG — это настоящие нечёткие понятия, которые надёжно не уловит ни один regex. Это правильные случаи для продвинутого правила. Примите, что каждое добавляет ограниченный дополнительный вызов модели. Настройте таймауты под свой бюджет задержки. Если ваш сквозной целевой показатель 1 000 мс, установите judge_timeout_ms: 800 (или меньше), чтобы judge не мог потребить весь ваш бюджет. Дефолтный таймаут движка — безопасная отправная точка; уменьшите его, если у вас жёсткие требования. Для выходного grounding вызов модели уже сделан. Проверка grounding выполняется после ответа вышестоящей модели — дополнительная задержка только в хвосте, а не на критическом пути до первого токена. Это делает её малорисковым местом для добавления семантического применения. Несколько продвинутых правил? Распределите работу. Поскольку продвинутые правила работают конкурентно, накладывание трёх правил llm_judge стоит примерно столько же, как одно — наибольший индивидуальный таймаут определяет реальное время, а не их количество. Используйте это для наслоения семантических проверок без аддитивной стоимости.

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

Fail-open vs fail-closed — полный справочник для настройки поведения вашей политики при таймаутах и условиях ошибок.

Guardrails

Типы правил, поля judge, пороги grounding и полный справочник конфигурации guardrail.
Встроенные правила пренебрежимы на каждом пути; продвинутые правила стоят один ограниченный, конкурентный, fail-open вызов — настройте таймаут и режим сбоя, и применение не добавляет неконтролируемой задержки вашим агентам.