Trust & Safety в дипломе: метрики модерации и защита несовершеннолетних
Присяжные в Нью-Мексико признали, что Meta умышленно вводила пользователей в заблуждение относительно безопасности своих продуктов и вела «недобросовестную торговую практику». Штраф — 375 млн долларов: суд взял максимальные 5 000 долларов за каждое из 37 500 нарушений по двум эпизодам. Штат требовал около 2 млрд, но и без этого вердикт стал знаковым: он вынесен уже на следующий день после прений. Для выпускника ИТ это не «новость про юристов», а готовый полигон для ВКР. Здесь есть всё, что любит госкомиссия: измеримые метрики, угрозы, регуляторные требования и честная инженерная задача — сделать систему, которую нельзя обвинить в имитации безопасности.
Частые вопросы до старта
Мне точно хватит материала на 60–80 страниц?
Хватит, если не распыляться. Один процесс (например, «возрастной гейт + эскалация жалобы на контент с несовершеннолетним») даёт полноценную главу анализа, главу проектирования и главу эксперимента с метриками. Кейс Meta добавляет юридический контекст — это законная часть первой главы.
Где брать данные, если у меня нет доступа к реальной соцсети?
Три законных пути: синтетический датасет (генерируете сами, описываете генератор в приложении), публичные наборы для модерации (например, разметка токсичности в открытых исследовательских репозиториях), собственный размеченный корпус из 300–500 примеров, собранный вручную по этическому чек-листу. Главное — показать в главе 3, что разметка воспроизводима, а метрики считаются по формуле, а не «на глаз».
Обязательно ли писать ML-классификатор?
Нет. Сильная ВКР получается и на правилах (rule-based) плюс ручной эскалации, если вы честно сравниваете два подхода: правила дают высокий recall и много ложных срабатываний, модель — баланс, но требует разметки. Сравнение подходов в главе 3 выглядит убедительнее, чем один «сырой» классификатор.
Что реально спрашивают на защите по таким темам?
Три вопроса почти гарантированы: как вы измеряли эффективность, почему выбрали именно эти пороги и что будет при отказе внешнего сервиса проверки возраста. Ответ готовьте в виде чисел и схемы деградации, а не пересказа теории.
Темы ВКР: четыре рабочие связки
-
1. Сервис возрастной верификации (age assurance) для платформы пользовательского контента
Актуальность: в деле против Meta ключевым был тезис о том, что компания вводила в заблуждение относительно безопасности продуктов, включая риски для детей. Значит, возрастной гейт — это не «формальность», а элемент доверия к продукту.
Цель: разработать подсистему подтверждения возраста, устойчивую к обходу и не собирающую лишние персональные данные.
Задачи: 1) обзор подходов (документальная проверка, оценка по поведенческим признакам, внешний провайдер); 2) модель угроз по STRIDE; 3) реализация с минимизацией данных; 4) оценка false positive / false negative по возрастным группам.
Структура: Глава 1 — регуляторный и технический анализ; Глава 2 — архитектура (C4) и схема БД; Глава 3 — тестирование на синтетическом наборе и расчёт метрик.
-
2. Конвейер модерации контента с аудитом и метрикой time-to-takedown
Актуальность: вердикт строился вокруг «систематического» введения в заблуждение — то есть вокруг процессов, а не единичных сбоев. Конвейер с журналом решений и SLA на снятие контента — прямой ответ на этот упрёк.
Цель: построить конвейер «детект → приоритизация → решение → апелляция» с неизменяемым журналом аудита.
Задачи: 1) BPMN-модель процесса; 2) правило эскалации高风险-классов; 3) реализация журнала аудита; 4) расчёт time-to-takedown и доли отменённых апелляций.
Структура: Глава 1 — анализ практик; Глава 2 — проектирование сервисов и очередей; Глава 3 — нагрузочное тестирование и метрики.
-
3. Оценка качества системы модерации: precision, recall и цена ошибки
Актуальность: суд фактически оценил цену ошибки в деньгах — 5 000 долларов за нарушение. В дипломе это превращается в методику «стоимость ложноположительного против ложноотрицательного срабатывания».
Цель: разработать методику оценки качества модерации с учётом асимметрии ошибок.
Задачи: 1) построить матрицу ошибок; 2) ввести веса по классам риска; 3) сравнить rule-based и ML-подход; 4) визуализировать зависимость от порога.
Структура: Глава 1 — теория метрик и ISO/IEC 25010; Глава 2 — стенд и разметка; Глава 3 — эксперименты и выводы.
-
4. Журнал аудита действий с персональными данными детей как элемент соответствия требованиям
Актуальность: регуляторные претензии почти всегда упираются в вопрос «докажите, что вы контролировали процесс». Аудит-лог — то, что доказывает.
Цель: спроектировать неизменяемый журнал событий с привязкой к требованиям защиты данных.
Задачи: 1) перечень событий и сроков хранения; 2) схема БД и защита от подмены; 3) интеграция с трассировкой; 4) проверка полноты записей.
Структура: Глава 1 — требования и ГОСТ 34.601-90 по стадиям; Глава 2 — реализация; Глава 3 — сценарии проверки и отчёт.
Как встроить кейс в главы работы
Глава 1: превращаем новость в постановку задачи
Не пересказывайте статью. Вытащите из неё три технических факта: (1) претензия была не к одному инциденту, а к системе; (2) масштаб оценивался количественно — 37 500 нарушений; (3) максимальная ставка за нарушение применялась по каждому эпизоду. Отсюда рождается постановка: нужна система, где каждое решение модерации и каждая проверка возраста оставляют след и поддаются измерению. Здесь уместно опереться на ГОСТ 34.601-90 (стадии создания автоматизированной системы) и на ISO/IEC 25010 — характеристики «безопасность» и «надёжность» дадут вам формальные критерии качества.
Глава 2: архитектура и схема взаимодействия
Рисуйте C4-диаграмму уровня контейнеров: клиент, API-шлюз, сервис модерации, очередь, хранилище аудита, сервис апелляций, аналитика. Отдельно — sequence-диаграмму для сценария «жалоба на контент с участием несовершеннолетнего». Ниже — скелет, от которого удобно отталкиваться:
┌────────────┐ ┌──────────┐ ┌───────────────┐ ┌───────────┐
│ Пользова- │──▶│ API-шлюз │──▶│ Модерация │──▶│ Очередь │
│ тель │ │ │ │ (правила+ML) │ │ эскалаций │
└────────────┘ └────┬─────┘ └───────┬───────┘ └─────┬─────┘
│ │ │
▼ ▼ ▼
┌───────────┐ ┌───────────────┐ ┌──────────────┐
│ Age-gate │ │ Аудит-журнал │ │ Аналитик T&S │
└───────────┘ └───────────────┘ └──────────────┘
Модель угроз оформляйте по STRIDE и сводите в таблицу — это дешево по времени и очень выигрышно смотрится на защите.
| Категория STRIDE | Угроза в контексте кейса | Мера |
|---|---|---|
| Spoofing | Подмена возраста при регистрации | Многофакторная проверка, поведенческие признаки |
| Tampering | Правка записей журнала аудита | Append-only хранилище, хеш-цепочка |
| Repudiation | «Мы не знали о нарушении» | Полная трассировка решений модератора |
| Information disclosure | Утечка данных несовершеннолетних | Минимизация данных, шифрование |
| Denial of service | Отказ внешнего сервиса проверки | Деградация до ручной модерации |
| Elevation of privilege | Доступ аналитика к лишним данным | Ролевая модель по OWASP ASVS |
Глава 3: метрики, которые защищают работу
Здесь нельзя писать «система показала хорошие результаты». Нужны числа. Базовый набор: precision, recall, F1 по классу «риск для несовершеннолетнего», доля ложноположительных, time-to-takedown (медиана и 95-й процентиль), appeal overturn rate, покрытие сценариев (какая доля инцидентов вообще попала в конвейер). Пример расчёта на Python:
from dataclasses import dataclass
@dataclass
class ModerationCase:
case_id: str
risk_class: str # "child_safety" | "spam" | "abuse"
auto_score: float # выход классификатора, 0..1
human_label: int # 1 — нарушение подтверждено
decision: str # "block" | "age_gate" | "skip"
THRESHOLD = 0.62
def metrics(cases, cls):
tp = fp = fn = 0
for c in cases:
if c.risk_class != cls:
continue
predicted = c.auto_score >= THRESHOLD
if predicted and c.human_label == 1:
tp += 1
elif predicted and c.human_label == 0:
fp += 1
elif not predicted and c.human_label == 1:
fn += 1
precision = tp / (tp + fp) if tp + fp else 0.0
recall = tp / (tp + fn) if tp + fn else 0.0
f1 = 2 * precision * recall / (precision + recall) if precision + recall else 0.0
return {"precision": round(precision, 3),
"recall": round(recall, 3),
"f1": round(f1, 3),
"fp": fp, "fn": fn}
Метрику времени реакции считайте прямо в SQL — это удобно защищать, потому что запрос воспроизводим:
SELECT risk_class,
percentile_cont(0.5) WITHIN GROUP (ORDER BY resolved_at - created_at) AS ttt_median,
percentile_cont(0.95) WITHIN GROUP (ORDER BY resolved_at - created_at) AS ttt_p95,
AVG(CASE WHEN appeal_result = 'overturned' THEN 1.0 ELSE 0.0 END) AS overturn_rate
FROM moderation_cases
WHERE created_at >= now() - interval '90 days'
GROUP BY risk_class;
И отдельно — соответствие требованиям. NIST AI RMF 1.0 даёт удобную рамку из четырёх функций (Govern, Map, Measure, Manage): привяжите к каждой подзадачу вашей работы и покажите в таблице. Это тот случай, когда ссылка на стандарт реально усиливает текст, а не украшает его.
Чему вы научитесь по ходу работы
- Строить модель угроз по STRIDE и превращать её в конкретные технические меры.
- Считать precision/recall не абстрактно, а с ценой ошибки по классам риска.
- Проектировать журнал аудита, устойчивый к подмене записей.
- Описывать деградацию сервиса: что произойдёт, если внешняя проверка возраста недоступна.
- Оформлять архитектуру по C4 и BPMN так, чтобы её понял и технарь, и нормоконтроль.
- Задачи во введении дословно совпадают с задачами в главах и с выводами в заключении.
- Каждая метрика имеет формулу и указание, на каких данных она считалась.
- Схемы пронумерованы, подписаны и упомянуты в тексте до их появления.
- Журнал аудита: описано, кто, что и как долго хранит.
- Код в приложениях соответствует листингам в главе 2 и 3.
- Ссылки на стандарты (ISO/IEC 25010, OWASP, ГОСТ) оформлены по ГОСТ Р 7.0.5.
- Тест на уникальность пройден, список источников содержит дату обращения к каждому URL.
- «Юридическая» работа вместо инженерной. Студент на 40 страниц пересказывает судебные претензии, а в главе 3 — три скриншота. Лечится просто: право — это первая глава и не более 25% объёма, всё остальное — архитектура и измерения.
- Метрики без порога. Пишут «точность 0,9», но не указывают, при каком значении отсечки и на каком наборе. В кейсе Meta масштаб оценивался в конкретных числах — требуйте того же от себя: порог, размер выборки, распределение по классам.
- Забытая деградация. Схема работает, только пока доступен внешний сервис. Добавьте сценарий отказа и опишите резервный путь — это ровно та слабость, за которую в реальных системах и приходят регуляторы.
Если вам нужна помощь с дипломом по Trust & Safety, защите данных или архитектуре сервисов модерации — сформулируйте тему и требования вуза, и мы скажем, где в ней слабое место. А если вы пока думаете, как написать ВКР целиком, начните с одной задачи: определите, какую метрику вы будете улучшать и как её измерите. Дальше структура соберётся сама.
Источник: Meta misled users about its products’ safety, jury decides (опубликовано 2026-03-24)