Фильтры безопасности контента для AI-систем
Контент-фильтрация — это не «запрещать всё подозрительное». Это точная настройка баланса между безопасностью и полезностью. Слишком агрессивные фильтры убивают UX: медицинский ассистент, который отказывается обсуждать симптомы депрессии «из соображений безопасности», бесполезен. Слишком мягкие — открывают дорогу реальному вреду.
Таксономия небезопасного контента
Для продуктовой системы нужна чёткая таксономия — что именно мы фильтруем и с каким уровнем строгости:
| Категория | Примеры | Рекомендуемый подход |
|---|---|---|
| Насилие (explicit) | Инструкции по причинению вреда | Hard block |
| Насилие (общее) | Обсуждение военных конфликтов | Context-dependent |
| CSAM | Любой контент | Hard block, zero tolerance |
| Hate speech | Дискриминация по признакам | Classifier + threshold |
| Личная угроза | «Я убью тебя» | Classifier + escalation |
| PII утечка | Данные других пользователей | NER-detection + block |
| Дезинформация | Фактические ошибки | Fact-check pipeline |
| Jailbreak попытки | Обход системных инструкций | Injection detection |
| Off-topic | Вне scope приложения | Soft redirect |
Технический стек для content safety
OpenAI Moderation API. Быстрый и дешёвый первый слой. 11 категорий, latency ~100ms, стоимость практически нулевая. Хорошо ловит очевидные нарушения, но плохо работает на русском языке и специфических контекстах.
Azure Content Safety. Мультиязычная поддержка, включая русский. 4 основные категории (Hate, Violence, Sexual, SelfHarm) с severity levels 0–7. REST API или SDK:
from azure.ai.contentsafety import ContentSafetyClient
from azure.ai.contentsafety.models import AnalyzeTextOptions
client = ContentSafetyClient(endpoint, credential)
response = client.analyze_text(AnalyzeTextOptions(
text=user_input,
categories=["Hate", "Violence", "Sexual", "SelfHarm"],
output_type="FourSeverityLevels"
))
for result in response.categories_analysis:
if result.severity >= 4: # порог настраивается
raise ContentPolicyViolation(result.category)
LlamaGuard 3. Локальная модель — ключевое преимущество для privacy-sensitive продуктов. Не нужно отправлять пользовательский контент на внешние серверы. Классификация по MLCommons hazard taxonomy. Работает на GPU от 8GB VRAM в INT4 квантизации через llama.cpp.
Кастомные классификаторы. Для доменно-специфичных правил (финтех не обсуждает схемы уклонения от налогов, медицинский сервис не даёт конкретных диагнозов) обучаем дообученные дистиллированные модели на примерах из конкретной предметной области. BERT-base с LoRA fine-tuning на 500–2000 примерах даёт precision 0.92+ для узких категорий.
Архитектура многоуровневой фильтрации
Принцип: быстрые и дешёвые фильтры — первыми. Дорогие LLM-based проверки — только то, что прошло первый слой.
User Input
↓
[Layer 1: Rule-based] — regex, keyword lists, <5ms
↓ (если не заблокировано)
[Layer 2: Fast classifier] — BERT/DistilBERT, 20-50ms
↓ (если score > 0.3)
[Layer 3: LLM classifier] — LlamaGuard / GPT-4o mini, 150-400ms
↓
Decision: Allow / Block / Rewrite / Escalate
На слой 3 доходит только ~5–15% трафика — это даёт разумный баланс между стоимостью и точностью.
Практический кейс: образовательная платформа
Платформа онлайн-обучения для школьников, AI-тьютор. Требования жёсткие: никакого контента для взрослых, никакого насилия, но при этом нормальное обсуждение исторических событий, включая войны.
Проблема первой версии: агрессивный фильтр блокировал 23% запросов, включая обсуждение Второй мировой войны, темы школьного буллинга в контексте психологической помощи, медицинских вопросов.
Что сделали:
- Ввели context-awareness: тот же запрос в контексте истории vs. в контексте «как навредить кому-то» — разные решения
- Настроили topic-specific пороги: для исторического контекста порог по «violence» повышен
- Добавили intent classification: вопрос «почему дети дерутся в школе» → academic/help-seeking, не угроза
- Ложноположительные срабатывания снизились с 23% до 2.8%, recall по реальным нарушениям вырос с 0.71 до 0.94
Мониторинг и итерация
Фильтры деградируют: пользователи находят обходные пути, язык меняется, новые угрозы появляются. Необходим:
- Дашборд по rate заблокированных запросов с разбивкой по категориям
- Выборочный human review заблокированного контента (5–10% sample)
- Periodic retraining классификаторов на новых примерах
- A/B тесты при изменении порогов
Сроки: 2–4 недели для базовой фильтрации, 8–12 недель для многоуровневой системы с кастомными классификаторами и мониторингом.