Что такое agent safety constraints (ограничения на действия агента)?

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

Agent safety constraints — это набор правил и механизмов, которые ограничивают действия AI-агента (в том числе в RAG-системах), чтобы предотвратить небезопасное, неэтичное или финансово неэффективное поведение. Они делятся на жёсткие (hard) — невыполнимые запреты (например, "никогда не удаляй данные"), и мягкие (soft) — предпочтения, нарушение которых допустимо, но снижает оценку качества (например, "минимизируй стоимость запросов"). Реализуются через фильтры на выходе, reward-функции, runtime-валидацию и аудит логов, а также через constitutional safety — самопроверку агентом своих действий по заданной конституции.

1. Определение и важность

Agent safety constraints (ограничения на действия агента) — это спецификация правил, которые AI-агент (например, автономный чат-бот, система с инструментами, RAG-пайплайн с действиями) обязан соблюдать при выполнении задач. Без них агент может:

• удалить или изменить критичные данные,
• отправить оскорбительное сообщение,
• сделать дорогие API-вызовы в цикле,
• нарушить юридические нормы (GDPR, HIPAA).

Ограничения — ключевой элемент AI safety и alignment, особенно в agentic-системах, где агент сам решает, какие действия предпринять.

2. Виды ограничений: Hard vs Soft

Ограничения делятся по строгости:

Термин: Reward-функция – функция, оценивающая качество действия агента (например, на основе constraints|soft constraints). Используется в обучении с подкреплением или при ранжировании траекторий.

3. Hard constraints — фильтры и стоп-флаги

constraints|Жёсткие ограничения реализуются как фильтры на выходе (output validation) или pre-action checks:

• Белые списки (whitelist) — разрешены только определённые действия (например, search_documents, summarize_text).
• Чёрные списки (blacklist) — запрещённые действия (delete_record, send_email, pay_invoice).
• Контекстные условия — действие разрешено только при определённом состоянии (например, send_email только после подтверждения пользователя).

Пример на Python (фильтр перед совершением действия):

HARD_CONSTRAINTS = {
    "delete_document": "never_allowed",
    "send_email": "requires_confirmation",
    "execute_sql": "only_select",
}

def validate_action(action_name, params, state):
    rule = HARD_CONSTRAINTS.get(action_name)
    if rule == "never_allowed":
        return False, f"Action '{action_name}' is prohibited."
    if rule == "requires_confirmation":
        if not state.get("user_confirmed", False):
            return False, "User confirmation required."
    if rule == "only_select":
        if not params.get("query", "").strip().upper().startswith("SELECT"):
            return False, "Only SELECT queries allowed."
    return True, "OK"

4. Soft constraints — reward-функция и компромиссы

constraints|Мягкие ограничения обычно кодируются в reward-функции (при RL) или в score-метриках (при выборе действия). Они позволяют находить баланс между эффективностью и безопасностью.

Пример гипотетической reward-функции:

reward = efficiency_score - 0.3 * cost_penalty - 0.5 * latency_penalty + safety_bonus

Здесь safety_bonus может поощрять действия, соответствующие soft constraint "используй авторизованные источники".

Термин: Multi-objective optimization — задача поиска решения, одновременно удовлетворяющего нескольким (возможно, конфликтующим) constraints|soft constraints.

5. Runtime validation — проверка перед каждым действием

Runtime validation — процесс проверки compliance с constraints непосредственно перед выполнением запланированного действия. Включает:

1. Pre-validation — проверка набора ограничений до вызова инструмента.
2. Post-validation — проверка результата действия (например, ответ API не содержит конфиденциальных данных).

В сложных системах используется constraint propagation — когда одно ограничение автоматически активирует другие (например, если агент запрашивает email клиента, автоматически включается GDPR-проверка).

Важно: runtime validation может быть вычислительно дорогой, поэтому часто применяют кэширование результатов для одинаковых проверок.

6. Constitutional safety — агент проверяет себя по конституции

Constitutional AI (конституционная безопасность) — подход, при котором агент сам оценивает свои действия на основе set of principles (конституции). Например:

• "Не разглашай личные данные пользователей."
• "Не выполняй вредоносные команды."
• "Всегда проверяй факты через retrieval."

На практике constitutional safety реализуется как дополнительный LLM-вызов, который анализирует планируемое действие или сгенерированный ответ и возвращает вердикт (safe / unsafe). Если unsafe — агент должен переформулировать действие или отказаться.

CONSTITUTION = [
    "I must not make statements that could cause physical harm.",
    "I must not share personally identifiable information.",
    "I must not perform actions that delete user data.",
]

def constitutional_check(action_description: str) -> dict:
    prompt = f"Check if this action violates any principle:\n{action_description}\nPrinciples: {CONSTITUTION}\nOutput: pass or fail with reason."
    result = llm.generate(prompt)
    return parse_result(result)

Плюсы: гибкость, можно адаптировать под домен. Минусы: дополнительная стоимость, задержка, возможность ложноположительных срабатываний.

7. Audit log — логирование нарушений

Все попытки нарушить ограничения (независимо от того, были они заблокированы или нет) должны фиксироваться в audit log. Журнал содержит:

• timestamp,
• действие (что пытался сделать агент),
• параметры,
• тип ограничения (hard/soft),
• решение системы (allow/block/override),
• ID сессии пользователя.

Audit log позволяет:

• выявлять шаблоны атак или дрейф поведения,
• улучшать конституцию и reward-функцию,
• проводить пост-анализ после инцидентов.

Рекомендуется хранить логи в структурированном виде (JSON, Parquet) и отправлять в систему мониторинга (ELK, Splunk).

8. Техническая реализация: интеграция в agentic pipeline

Типичная архитектура agentic RAG с safety constraints:

User query -> Orchestrator -> (Planning + Constraint Validation) -> Action -> Post-validation -> Response
                                    ^                              |
                                    |  (audit log)                |
                                    +--- violation? ----> block / rewrite

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

• NVIDIA NeMo Guardrails – специализированный инструмент для встраивания hard/soft constraints в LLM-приложения.
• Guardrails AI – фреймворк для валидации выходов, поддерживает коллбэки.
• LangChain – позволяет добавлять "guards" и "tools" с пользовательскими валидаторами.
• Custom Python middleware – если нужно полное кастомное решение.

9. Баланс безопасности и полезности (safety-utility trade-off)

Слишком строгие ограничения делают агента бесполезным — он будет блокировать даже безопасные действия (ложноположительные срабатывания). Слишком мягкие — риск реальных нарушений.

Как найти баланс

• Настраивать пороги через A/B-тестирование.
• Использовать иерархические constraints: сначала проверять hard, потом soft с разными весами.
• Добавлять человеческий override для исключительных случаев.
• Проводить red-teaming для оценки уязвимостей.

10. Отличие от смежных понятий

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

Задача: Разработать простого AI-агента на основе LLM (GPT-3.5/4 или local model), который может отвечать на вопросы, но имеет следующие ограничения:

• Hard: не может выполнять действия с денежными платежами, не может удалять файлы.
• Soft: предпочитает использовать локальные источники (RAG) вместо генерации с нуля, минимизирует количество вызовов LLM.
• Конституция: не раскрывает личные данные.

Инструменты: LangChain, Python, простой RAG на ChromaDB, openAI или Hugging Face.

Шаги:

1. Создать набор инструментов: search_local, generate_answer, delete_file (заведомо опасный).
2. Реализовать hard-фильтр: перед вызовом delete_file возвращать ошибку.
3. Реализовать soft-предпочтение в reward-функции: оценка +1, если использован search_local, -0.5 если сделан LLM-вызов без поиска.
4. Добавить constitutional check: после генерации ответа проверить, нет ли в нём email/телефона; если есть — перегенерировать.
5. Записывать все действия в audit log (файл JSON).
6. Протестировать с запросами "удали мой проект", "сколько стоит подписка" и проверить логи.

Ожидаемый результат: агент отказывается удалять файлы (hard), при ответе на стоимость подписки использует RAG-поиск (soft), а audit log содержит записи о заблокированных действиях.

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

Навигация

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