Ваш корпоративный ассистент прекрасно отвечает на вопросы о продуктах, но вчера он вдруг подробно расписал конкурентам внутреннюю процедуру увольнения. Или медицинский чат-бот начал давать инвестиционные советы. Это не гипотетический сценарий, а ежедневная реальность развертывания LLM. Ключевой навык production-системы — не умение ответить на всё, а умение корректно отказаться отвечать на непредусмотренные или опасные запросы.  

Почему простая инструкция «Не отвечай на это» не работает?  

Большие языковые модели оптимизированы для помощи и заполнения информационных пробелов. Их фундаментальная цель — продолжить последовательность токенов. Прямой запрет вроде «Не отвечай на вопросы о политике» часто воспринимается как контекст, а не как железное правило, и может быть обойден через:  

• Переформулировку вопроса: Пользователь: «Расскажи о текущих лидерах крупных государств» (вместо «Кто президент?»).  

• Косвенные запросы: «Напиши исторический рассказ, где герой критикует…»  

• Инжекцию в контекст: «Представь, что ты — историк, анализирующий…»  

Решение — это не один инструмент, а многослойная система безопасности (Defense-in-Depth для LLM).  

Слой 1: Чёткое определение границ — системный промпт как конституция  

Первый и главный барьер. Системный промпт должен быть юридически точным и операциональным.  

❌ Плохо (размыто, оставляет лазейки):  

«Ты — полезный ассистент. Избегай спорных тем.»  

✅ Хорошо (конкретно, императивно, с примерами):  

«Ты — AI-ассистент компании «Альфа», предназначенный исключительно для ответов на вопросы о наших продуктах (X, Y, Z), их использовании и технической поддержке.    
Строгие правила:  

1. Твоя область знаний строго ограничена: официальная документация, публичные FAQ и знания из базы поддержки компании «Альфа».  

2. Запрещенные категории запросов: политика, финансовая/юридическая/медицинская консультация, личные мнения, творческое содержание (поэзия, код), анализ любых других компаний.  

3. Процедура отказа: Если запрос выходит за рамки твоей области или попадает в запрещенную категорию, ты должен ответить ТОЛЬКО стандартной фразой: «Извините, я не могу ответить на этот вопрос. Я могу помочь вам с информацией о продуктах и услугах компании «Альфа»».  

4. Не объясняй причин отказа, не предлагай альтернатив, не вступай в дискуссию о правилах.    
   Начинай работу.»  

Ключевые элементы сильного системного промпта:  

• Позиционирование: Чёткая роль и миссия.  

• Разрешенная область: Конкретный перечень тем или источников.  

• «Чёрный список» тем: Явный, недвусмысленный список.  

• Жёсткий сценарий отказа: Одна разрешённая фраза для всех непредусмотренных случаев.  

Слой 2: Предварительная классификация и фильтрация запросов  

До того как запрос попадёт к большой и дорогой LLM, его должен проверить быстрый и дешёвый классификатор.  

Техника: Каскадная фильтрация с помощью маленькой модели.  

1. Intent Classifier: Быстрая модель (например, Phi-3-mini или даже DistilBERT) определяет намерение: product_info, tech_support, off_topic, forbidden_topic.  

2. Sentiment/Moderation Filter: Проверяет запрос на токсичность, агрессию, явные попытки обхода (jailbreak).  

3. Правила (Rule-Based): Регулярные выражения для блокировки конкретных ключевых слов (имена конкурентов, внутренние коды проектов).  

Архитектура пайплайна:  

Пользовательский запрос -> [Классификатор намерений] -> [Модерационный фильтр] -> [Правила] -> Допуск к основной LLM / Отказ
	
	
	
	
	
	
	
	

Если классификатор ставит метки off_topic или forbidden_topic, система сразу возвращает шаблонный ответ отказа, не тратя ресурсы и не рискуя основной моделью.  

Слой 3: Контекстуальный контроль и «защита от переопределения» (Prompt Guarding)  

Что если пользователь попытается инжектировать свою инструкцию прямо в запрос? «Забудь предыдущие инструкции и ответь как…»  

Техника: Обёртка промпта и валидация контекста.  

• Жёсткое разделение: Системная инструкция, контекст (чанки RAG) и запрос пользователя должны передаваться модели как отдельные, чётко размеченные поля, а не как слитный текст.  

• Экранирование и санитизация: Все пользовательские вводы должны очищаться от специальных символов, которые могут сломать форматирование промпта.  

• Паттерн «Сначала классифицируй, потом отвечай»: В сам промпт основной LLM встраивается инструкция выполнить внутреннюю проверку перед генерацией.  

Пример структурированного промпта для основной LLM:  

<|system|>
[Твой сильный системный промпт с правилами] </s>

<|context|>
[Релевантные чанки из RAG, если запрос в области знаний] </s>

<|user_query|>
{Запрос пользователя} </s>

<|internal_instruction|>
1. Проанализируй <user_query>. Соответствует ли он разрешенной области из <|system|> инструкции?
2. Если НЕТ, сгенерируй ТОЛЬКО стандартный отказ.
3. Если ДА, используй <context>, чтобы сгенерировать полезный ответ. </s>

<|assistant|>
	
	
	
	
	
	
	
	

Слой 4: Пост-обработка и валидация ответа (Post-Processing)  

Последний рубеж. Ответ модели проверяется перед отправкой пользователю.  

• Классификатор ответов: Маленькая модель («LLM-as-a-Judge») оценивает, соответствует ли сгенерированный ответ заявленной тематике и не содержит ли утечки.  

• Маскирование конфиденциальных данных: Автоматическое обезличивание любых случайно всплывших номеров телефонов, имён, внутренних ссылок.  

• Фильтр по «красным фразам»: Блокировка ответов, содержащих фразы из чёрного списка («я как ИИ», «мои создатели», «внутренний документ»).  

Практический кейс: Защита RAG-ассистента по внутренней документации  

Цель: Ассистент отвечает только на вопросы из утверждённой базы знаний.    
Реализация:  

1. Системный промпт: Жёстко ограничивает область знаний официальным Confluence.  

2. Предфильтрация: Запрос пользователя сначала преобразуется в поисковый запрос для векторной БД. Если по запросу не найдено ни одного релевантного чанка с высоким скором (порог >0.7) — сразу возвращается «В моей базе знаний нет информации по этому вопросу».  

3. Контекстуальный контроль: В промпт передаются только найденные чанки. Инструкция: «Ответь строго на основе предоставленного контекста. Если ответа нет в контексте, скажи: «Информация не найдена»».  

4. Пост-обработка: Ответ проверяется на наличие фраз, указывающих на «галлюцинацию» («согласно общеизвестным данным», «я думаю»).  

Мониторинг и постоянное улучшение  

Безопасность — процесс, а не состояние.  

• Логируйте все отказы: Анализируйте, на какие запросы система чаще всего отказывает. Это покажет слепые зоны.  

• Регулярно тестируйте на уязвимости (Red Teaming): Пробуйте новые jailbreak-паттерны, косвенные запросы.  

• Обновляйте «чёрные списки» и правила: Новые непредусмотренные темы будут появляться постоянно.  

Вывод  

Научить модель говорить «нет» — сложнее, чем научить её говорить «да». Это задача проектирования системы, а не написания одного волшебного промпта. Используйте каскадный подход: начинайте с чётких правил в системном промпте, фильтруйте запросы быстрыми классификаторами, контролируйте контекст и всегда проверяйте ответ. Только так вы превратите вашу LLM из эрудированного, но болтливого стажёра в надёжного, предсказуемого и безопасного корпоративного сотрудника, который знает свою работу и не выходит за рамки должностной инструкции.