Что такое Safety & Guardrails как слой Harness? Чем runtime guardrails отличаются от тестирования?

Краткий тезис

Safety & Guardrails — это пятый (защитный) слой эталонной архитектуры AI-системы (Harness), отвечающий за безопасность и контроль поведения модели. Runtime guardrails работают в реальном времени как «firewall»: фильтруют входящие промпты (на jailbreak, prompt injection) и исходящие ответы (на PII, токсичность), при сомнении блокируя запрос (fail-closed). Тестирование безопасности (например, с Garak) — это статический анализ и red teaming до деплоя, который выявляет уязвимости, но не защищает в рантайме. Разница: runtime — активная защита, тестирование — пассивный аудит.

1. Что такое Safety & Guardrails в AI-системах?

Safety & Guardrails — это набор методов, правил и инструментов, которые ограничивают поведение LLM, предотвращают вредоносные или нежелательные выходы и защищают пользователя и систему. В отличие от простого контроля качества, guardrails работают на уровне безопасности (security) и соответствия нормам (compliance).

Основные угрозы, которые закрывают guardrails:

• Prompt injection — внедрение вредоносных инструкций в промпт.
• Jailbreak — попытка обойти системные ограничения модели.
• Утечка PII (Personally Identifiable Information) — генерация личных данных (телефоны, адреса, паспортные данные).
• Токсичный контент — оскорбления, ненавистническая речь, опасные советы.
• Hallucination в ответе — выдача ложной информации как факта.

2. Слой Harness и место Guardrails в эталонной архитектуре

Harness (упряжка) — это эталонная архитектура для построения production-ready AI-систем, обычно включающая 5 слоёв:

1. Orchestration — управление потоком запросов.
2. Retrieval — поиск релевантных документов.
3. Generation — вызов LLM.
4. Observability — мониторинг и логирование.
5. Safety & Guardrails — безопасность на всех этапах.

Слой 5 является сквозным: он может анализировать как входящий запрос (pre-guard), так и сгенерированный ответ (post-guard), а также метаданные контекстного поиска. Примеры интеграции: NeMo Guardrails, Guardrails AI, Llama Guard.

3. Runtime Guardrails — активная защита в реальном времени

Runtime guardrails — это компоненты, которые работают синхронно с каждым запросом пользователя, до отправки в LLM и после получения ответа.

Основные принципы:

• Fail-closed: при любой неопределённости (например, модель не может классифицировать промпт как безопасный) запрос блокируется или возвращается стандартный отказ.
• Низкая задержка: guardrails должны обрабатывать запрос за миллисекунды, иначе пользовательский опыт страдает.
• Каскад проверок: обычно несколько моделей/правил работают последовательно (regex → классификатор → LLM-as-judge).

Пример с фреймворком NeMo Guardrails (NVIDIA):

from nemoguardrails import RailsConfig, LLMRails

config = RailsConfig.from_path("config.yml")
rails = LLMRails(config)

# Предварительная проверка промпта
response = rails.generate(messages=[{"role": "user", "content": "Как взломать банк?"}])
# Если промпт запрещён, ответ будет "Извините, я не могу ответить на этот вопрос."

Типовые проверки в runtime:

• Input guardrails: детекция prompt injection (через модели типа Guardrails AI или Azure Content Safety).
• Output guardrails: фильтрация PII (используя Presidio или spaCy), проверка на токсичность (через Detoxify или OpenAI Moderation API).

4. Тестирование безопасности (статический анализ и Red Teaming)

Тестирование безопасности — это набор методов, которые применяются до деплоя системы, чтобы выявить слабые места. Главная цель — найти уязвимости, которые потом могут быть закрыты runtime guardrails или изменением модели.

Ключевые инструменты:

• Garak — фреймворк для автоматического red teaming LLM. Позволяет генерировать тысячи тестовых атак (prompt injection, jailbreak, вредные запросы) и оценивать поведение модели.
• PyRIT (Microsoft) — библиотека для автоматизированного поиска уязвимостей.
• Manual red teaming — команда специалистов вручную проверяет систему на критичные сценарии.

Пример запуска Garak:

garak --model_type huggingface --model_name meta-llama/Llama-2-7b-chat-hf --probes promptinject

Результат тестирования — отчёт о проценте успешных атак, типы уязвимостей, примеры пробитых guardrails.

5. Сравнение Runtime Guardrails и тестирования

6. Дополнительные классы Guardrails: Pre и Post, Policy-based

В runtime guardrails выделяют два основных типа:

• Pre-guardrails — проверка входящего промпта.
• Post-guardrails — проверка сгенерированного ответа.

Также существуют policy-based guardrails — набор правил, определённых через конфигурацию (YAML, JSON). Пример:

# config.yml
rails:
  input:
    flows:
      - detect_jailbreak
  output:
    flows:
      - detect_pii
      - check_toxicity
models:
  - type: main
    engine: openai
    model: gpt-4

7. Инструменты и фреймворки

8. Best Practices: как комбинировать runtime guardrails и тестирование

1. Тестирование → доработка → запуск
   • На этапе разработки используй Garak для поиска дыр.
   • Настрой runtime guardrails на основе найденных уязвимостей.
2. Fail-closed с мониторингом
   • Все блокировки логируй. Если false positive слишком частые — ослабляй guardrails.
3. Многослойная защита
   • Используй несколько guardrails разного типа (rule-based + ML-модель + LLM-as-judge).
4. Регулярное тестирование после обновлений
   • Каждый редеплой модели или смены промптов запускай Garak заново.
5. A/B тестирование guardrails
   • Запускай двухканальную систему: один канал с guardrails, другой без (для части трафика) — сравнивай safety и UX.

9. Проблемы и ограничения

• False positives — частая проблема: легитимные вопросы по медицине или образованию могут быть заблокированы.
• Latency — сложные guardrails (например, LLM-as-judge) могут сильно замедлять ответ.
• Стоимость — каждый вызов guardrails добавляет затраты на API или инференс.
• Обход guardrails — злоумышленники могут адаптировать атаки под конкретные guardrails (adversarial examples).
• Сложность настройки — правил много, их нужно поддерживать в актуальном состоянии.

Пет-проект для закрепления

Задача Создать простую RAG-систему для поиска по документам компании с безопасностью: реализовать runtime guardrails на входе (детекция jailbreak) и на выходе (удаление PII), а также написать тестовый скрипт с Garak для автоматической проверки.

Инструменты

• Python + FastAPI (веб-сервис)
• LangChain (RAG)
• HuggingFace Transformers (модель для LLM)
• NeMo Guardrails (или Guardrails AI)
• Garak (тестирование)
• Presidio (детекция PII)

Шаги:

1. Разверни простой RAG с FAISS и GPT-2 (учебная цель).
2. Подключи NeMo Guardrails: добавь поток для детекции prompt injection (используй встроенный detect_jailbreak).
3. Реализуй output guardrail на Presidio: найди и замени номера телефонов на [REDACTED].
4. Создай Docker-образ с сервисом.
5. Напиши скрипт с Garak: выбери probe promptinject и запусти тестирование на сервисе.
6. Зафиксируй метрики (сколько атак прошло, сколько заблокировано).

Ожидаемый результат

• Работающий API, который блокирует явные jailbreak-запросы и скрывает PII в ответах.
• Отчёт Garak с процентом успешных атак (должен быть < 5% после настройки guardrails).

Связь с другими вопросами

Навигация

• Предыдущий: 745
• Следующий: 747
• Индекс: 00. Индекс разборов