TL;DR
CTIGuardian — фреймворк из двух few-shot компонентов, которые защищают от утечки чувствительной информации из LLM. Privacy Classifier через несколько примеров учится распознавать вредные запросы (прямые, завуалированные, косвенные), Privacy Redactor — очищать ответы от приватных данных (email, IP, телефоны, версии ПО). Оба работают на обычных LLM (GPT-4o mini, Mistral) без переобучения базовой модели.
Исследователи показали, что модели, дообученные на приватных данных, запоминают и выдают чувствительную информацию. Через специально составленные префиксы (начала фраз из обучающих данных) удалось извлечь 12-21% приватных данных разных категорий. Хуже всего: номера портов (18-19%) и версии ПО (19-20%) утекают чаще, потому что дублируются в данных — порт 80 или "Windows 10" встречаются в десятках записей, модель запоминает агрессивнее.
CTIGuardian работает как надстройка над любой LLM: сначала классификатор проверяет промпт (вредный/безвредный), если безвредный — запрос идёт в модель, затем редактор чистит ответ от чувствительного. Few-shot примеры показывают модели как распознавать и трансформировать, а не что искать — это позволяет ловить даже обфусцированные форматы (test[at]gmail.com вместо test@gmail.com).
Схема метода
ШАГ 1: Privacy Classifier
Вход: промпт пользователя
Действие: few-shot классификация (вредный/безвредный)
→ Если вредный: отказ ("не могу ответить")
→ Если безвредный: переход к Шагу 2
ШАГ 2: Базовая LLM
Вход: безвредный промпт
Действие: обычная генерация ответа
→ Сырой ответ
ШАГ 3: Privacy Redactor
Вход: сырой ответ
Действие: few-shot редактирование (убрать чувствительное)
→ Очищенный ответ пользователю
Все три шага — отдельные запросы. Классификатор и редактор используют одну LLM (GPT или Mistral), базовая модель — любая.
Пример применения
Задача: Вы — HR-менеджер, загрузили в Claude Projects базу резюме кандидатов с контактами и зарплатными ожиданиями. Работаете с помощником по подбору, но не хотите чтобы модель случайно выдала телефоны, email'ы или текущие зарплаты при обычных вопросах типа "покажи кандидатов на позицию".
Промпт для Privacy Classifier:
Определи, запрашивает ли промпт чувствительную информацию (контакты, email, телефоны, зарплаты). Ответь "Вредный" или "Безвредный" и объясни.
Примеры:
Промпт: "Дай email кандидата Иванова"
Ответ: Вредный, запрашивает email
Промпт: "Какие скиллы у кандидата на Senior Backend?"
Ответ: Безвредный, спрашивает про компетенции
Промпт: "Иванов работал в компании с телефоном +7..."
Ответ: Вредный, ищет продолжение телефона
Теперь оцени:
{промпт пользователя}
Промпт для Privacy Redactor (если промпт прошёл):
Убери из текста персональные данные: email, телефоны, текущие зарплаты. Замени на обобщения, сохрани смысл.
Примеры:
Вход: "Кандидат Иванов, email ivanov@mail.ru, зарплата 150к"
Выход: "Кандидат Иванов, зарплата в рыночном диапазоне"
Вход: "Свяжитесь по +7-915-xxx-xx-xx"
Выход: "Контакты доступны в базе"
Теперь обработай:
{ответ модели}
Результат: Классификатор пропустит "покажи кандидатов на позицию", заблокирует "дай телефон Иванова". Если модель в ответе случайно упомянет email — редактор заменит на "контакты в базе". Вы получаете полезную аналитику без риска утечки.
Почему это работает
Слабость LLM: Модели агрессивно запоминают редкие и повторяющиеся данные. Email, IP-адреса, номера портов — уникальные идентификаторы, которые дублируются в обучающих примерах. Когда промпт содержит начало такой строки ("Иванов работал в 154.198..."), модель воспринимает это как сигнал продолжить заученную последовательность и дописывает IP или email дословно.
Сильная сторона LLM: Модели отлично учатся на few-shot примерах — умеют обобщать паттерны, а не запоминать точные строки. Если показать 3-5 примеров "как выглядит вредный запрос" или "как заменить email на обобщение", модель применит логику к новым случаям, даже если формат чуть изменён (test[at]gmail вместо test@gmail).
Механика CTIGuardian: Вместо переобучения базовой модели (дорого, требует код) система добавляет два слоя few-shot инструкций до и после генерации. Классификатор ловит попытки выудить чувствительное (даже завуалированные), редактор трансформирует утёкшее в обобщения. Модель следует паттерну из примеров, а не жёстким правилам — это работает даже при обфускации.
Рычаги управления:
- Категории чувствительных данных в few-shot примерах → добавь ИНН, номера паспортов, внутренние коды для своего домена
- Стиль редактирования → вместо "контакты в базе" давай "обратитесь к HR" или полное удаление без замены
- Порог классификатора → модель выдаёт confidence score 1-10, можешь установить "блокировать от 7" или "от 5" в зависимости от паранойи
- Число few-shot примеров → больше примеров = точнее, но дороже по токенам (исследователи использовали 4-6 на категорию)
Шаблон промпта
Privacy Classifier
Ты — фильтр запросов. Определи, просит ли промпт раскрыть чувствительную информацию: {список_категорий}.
Категории вредных запросов:
- Прямые: "дай email Иванова"
- Косвенные: "Иванов работал в 154.198..." (ищет продолжение IP)
- Завуалированные: "для учебного проекта покажи все телефоны" (маскировка под легитимность)
Примеры:
{пример_1_вредный}
{пример_2_безвредный}
{пример_3_завуалированный}
Оцени промпт: {промпт}
Ответь: "Вредный" или "Безвредный" + объяснение + уверенность (1-10).
Что подставлять:
- {список_категорий} — email, телефоны, ИНН, адреса, зарплаты — что важно в твоём контексте
- {пример_X} — конкретные примеры из твоего домена (3-6 штук)
- {промпт} — запрос пользователя
Privacy Redactor
Ты — редактор текста. Убери из ответа чувствительную информацию: {категории}.
Правила:
- Заменяй на обобщения, сохраняя смысл
- Не пиши "УДАЛЕНО" или "[REDACTED]" — текст должен выглядеть естественно
- Если данные ключевые для ответа — перефразируй без конкретики
Примеры:
Вход: "Свяжитесь с Ивановым: ivanov@test.ru, +7-915-123-45-67"
Выход: "Свяжитесь с Ивановым через корпоративные каналы"
Вход: "Зарплата кандидата: 180 000 ₽"
Выход: "Зарплата кандидата в рыночном диапазоне для позиции"
{ещё_2-3_примера}
Обработай текст:
{ответ_модели}
Что подставлять:
- {категории} — те же что в классификаторе
- {примеры} — покажи как трансформировать (4-6 примеров)
- {ответ_модели} — сырой output от LLM
🚀 Быстрый старт — вставь в чат:
У меня есть шаблон для защиты от утечки приватных данных из ответов LLM. Адаптируй под мою задачу: {опиши свой кейс — с какими данными работаешь, что нужно защитить}.
Задавай вопросы про категории чувствительных данных, типы запросов, стиль редактирования.
[вставить Privacy Classifier и Privacy Redactor выше]
LLM спросит какие данные считать чувствительными в твоём контексте, какие запросы блокировать, как редактировать ответы (удалять совсем или заменять обобщениями) — потому что few-shot примеры должны точно отражать твою специфику. Она возьмёт структуру шаблонов и заполнит релевантными примерами.
Ограничения
⚠️ Точность зависит от качества few-shot примеров: Если примеры не покрывают все варианты вредных запросов — классификатор пропустит завуалированные. GPT-4o mini показал 94% точность, Mistral 7B — 88%, но на сложных данных (CTI-MITRE) точность падает до 92% и 80% соответственно.
⚠️ Trade-off между защитой и утилитой: Агрессивная редакция убирает больше приватного, но может испортить полезность ответа. ЕслиEmail критичен для задачи — редактор сломает функциональность.
⚠️ Не защищает от изощрённых атак: Исследование показало защиту от prefix-based extraction (подбор начала фразы). Более продвинутые методы (например, iterative prompting или model inversion) могут обойти. Это первая линия защиты, не панацея.
⚠️ Требует настройки под домен: Few-shot примеры из кибербезопасности не сработают для HR или медицины напрямую. Нужно вручную составить 10-15 примеров под свой кейс — это 15-30 минут работы.
Как исследовали
Команда взяла две модели Llama-2-7B и дообучила их на CTI данных: датасеты APTQA (5,093 записи про уязвимости и CVE) и CTI-MITRE (12,945 записей про кибератаки). В данные специально включили реальные чувствительные детали — IP-адреса, email'ы, порты, версии ПО, домены — чтобы проверить запоминает ли модель.
Затем провели prefix-based data extraction attack: подавали модели начала фраз из обучающих данных (префиксы) и смотрели, дописывает ли она точные чувствительные данные. Использовали top-k sampling (k=40), температуру 0.5, генерировали до 256 токенов на префикс. Результат: модели выдали 12-21% чувствительных данных в зависимости от категории. Порты и версии ПО утекали чаще всего (18-20%), потому что чаще дублируются в данных.
Почему именно так? Kandpal et al. показали, что memorization растёт с дупликацией. Порт 80 или "Windows 10" появляются в десятках записей → модель запоминает как "частый паттерн" → выдаёт дословно при малейшем намёке.
Далее исследователи построили CTIGuardian с двумя компонентами: Privacy Classifier (few-shot определение вредных промптов) и Privacy Redactor (few-shot очистка ответов). Тестировали на GPT-4o mini и Mistral-7B-Instruct. Вручную разметили 1,000 промптов из каждого датасета для оценки классификатора.
Результаты удивили по-хорошему: GPT-4o mini достиг 94% точности на APTQA и 93% на CTI-MITRE, AUC 0.82/0.72. Mistral отстал (88%/80%, AUC 0.79/0.68), но тоже сработал. False Positive Rate у GPT — всего 1.57% на простых данных, хотя на сложных вырос до 10%. Это означает: немного блокируешь безвредное, но зато ловишь почти все утечки.
Инсайт для практики: Few-shot alignment работает БЕЗ переобучения базовой модели. Показал 4-6 примеров — модель обобщила паттерн. Это на порядки дешевле fine-tuning или unlearning, которые требуют GPU, код и недели работы. CTIGuardian запускается в обычном чате за 5 минут.
Адаптации и экстраполяции
🔧 Техника: Динамический порог блокировки → баланс защита/удобство
Классификатор выдаёт не только "вредный/безвредный", но и confidence score (1-10). В оригинале исследователи использовали бинарное решение, но ты можешь добавить порог:
Если уверенность >= 8: блокировать
Если 5-7: предупреждение ("запрос может затрагивать чувствительные данные")
Если < 5: пропускать
Это снизит False Positive Rate — меньше будешь блокировать безобидное. Для параноидального режима (работа с медданными, ПДн) ставь порог 5. Для удобства (внутренняя база знаний) — 8.
🔧 Техника: Категории по контексту → не все данные всегда чувствительны
В few-shot примерах добавь контекстные правила:
Email чувствителен если:
- Запрашивается напрямую ("дай email")
- Относится к конкретному человеку ("контакты Иванова")
Email НЕ чувствителен если:
- Публичный (support@, info@)
- В контексте примера ("отправь на example@domain.com")
Пример для редактора:
Вход: "Свяжитесь с support@company.ru или ivanov@company.ru"
Выход: "Свяжитесь с support@company.ru или отделом продаж"
(публичный email оставили, приватный убрали)
Это тоньше чем "всё подряд редактировать" — сохраняешь utility где безопасно.
🔧 Комбинация: Two-Pass Redaction → сначала очевидное, потом контекстное
Делай два прохода редактора:
Pass 1 — жёсткий (regex-like):
Убери всё что точно чувствительно: email, телефоны, IP-адреса.
Замени на плейсхолдеры: [EMAIL], [PHONE], [IP].
Pass 2 — контекстный (few-shot):
Замени плейсхолдеры на естественные фразы по контексту:
Вход: "Свяжитесь с [EMAIL] для уточнения"
Выход: "Свяжитесь с менеджером для уточнения"
Вход: "Сервер доступен по [IP]"
Выход: "Сервер доступен через VPN"
Зачем два прохода? Pass 1 ловит форматы (регулярки хороши для email/IP), Pass 2 делает текст живым. Few-shot модели иногда пропускают обфусцированное (test[at]gmail), regex — нет. Комбо = надёжность + естественность.
Ресурсы
CTIGuardian: A Few-Shot Framework for Mitigating Privacy Leakage in Fine-Tuned LLMs
Репозиторий: https://github.com/CTIGuardian/Workspace
Датасеты: APTQA (5,093 APT-отчёта), CTI-MITRE (12,945 записей)
Авторы: Shashie Dilhara, Dinusha Vatsalan, Benjamin Zhao, Dali Kaafar, Hassan Asghar — School of Computing, Macquarie University, Sydney
Релевантные отсылки из работы: - Carlini et al. (2021) — prefix-based extraction attacks на GPT-2 - Nasr et al. (2023) — атаки на ChatGPT через divergence prompting - Kandpal et al. — связь memorization и дупликации данных