Модерация контента в реальном времени в SFU

Кратко

Модерация контента в реальном времени – это задача оперативно выявлять вредоносные видео, аудио или сообщения в ходе живого звонка или трансляции, пока их не увидели другие участники. Естественное место для такой модерации – медиа-сервер, используемый в каждом групповом звонке, то есть SFU, поскольку он – единственная точка, имеющая доступ ко всем потокам участников. Проверять каждый кадр невозможно, поэтому реальная система анализирует несколько кадров в секунду, фильтрует звук по наличию речи, применяет простые детерминированные проверки перед более сложными и дорогими, а затем преобразует уровень уверенности классификатора в конкретное действие: размыть, заглушить, предупредить, заблокировать или передать на проверку человеку.

Одно решение определяет всю архитектуру и удивляет большинство команд: если включить настоящее сквозное шифрование на SFrame, сервер перестаёт видеть медиапотоки – и серверная модерация просто перестаёт работать. Проверку приходится переносить на устройство пользователя.

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

Почему это важно

Как только ваш продукт позволяет незнакомцам выходить в прямой эфир друг к другу – будь то социальная сеть, дейтинг-сервис, маркетплейс с живым видео, виртуальный класс или комната ожидания телемедицины – вы автоматически сталкиваетесь с проблемой безопасности, возникающей в реальном времени и не поддающейся исправлению задним числом. Один вредоносный кадр, попавший к зрителю, уже причинил ущерб; нелегальный контент, прошедший через ваши серверы, создаёт юридическое обязательство.

Эта статья адресована продакт-менеджерам, основателям и техлидам, которым нужно чётко описать функционал модерации, обоснованно распределить бюджет на задержку и стоимость, а также вести диалог с инженерами и юристами, не утонув в их профессиональном жаргоне. Мы разберём, где в системе живёт модерация, что именно она проверяет, во что обходится и какие аспекты за вас решает закон, а не ваши предпочтения.

О решении той же задачи для архивных данных – модерации миллионов уже записанных клипов – читайте в капстоне про конвейер UGC-модерации. Эта статья – про работу с прямым эфиром.

Что на самом деле значит «модерация контента в реальном времени»

Начнём со слов, потому что за термином «модерация» скрываются две принципиально разные задачи, которые часто путают, а это приводит к тому, что системы не достигают своей цели.

Первая задача – модерация постфактум. Пользователь загружает видео; через секунды или минуты система его проверяет и решает, публиковать ли. В расписании есть запас: если проверка занимает тридцать секунд, никто не пострадал, потому что ничего ещё не было видно. Вторая задача – модерация в реальном времени, и запаса у неё нет вообще. Контент уже в эфире: человек прямо сейчас на камере, прямо сейчас говорит с другими людьми, и если он покажет что-то вредное, зрители увидят это в ту же секунду. Ваша модерация должна обнаружить и среагировать внутри короткого окна, пока вредный момент не разошёлся, а в живом звонке это доля секунды или пара секунд. Разница между двумя задачами – как разница между охранником, отсматривающим вчерашние записи, и охранником, который смотрит на мониторы вживую. Эта статья целиком про второго охранника.

Живое ограничение меняет всё. Нельзя ждать медленного, аккуратного и дорогого анализа – к моменту его завершения вред уже будет нанесён. Нельзя поручить человеку следить за каждым потоком, потому что их может быть тысячи одновременно, а людей мало и они работают медленно. И нельзя просто блокировать всех заранее и проверять позже – это сделает продукт непригодным для подавляющего большинства, которые ничего плохого не делают. Поэтому модерация в реальном времени всегда – компромисс между скоростью, стоимостью и точностью. Искусство здесь в том, чтобы для каждого вида вреда определить, в какой точке этого треугольника лучше всего находиться.

SFU – единственное место, которое видит всё

Теперь архитектура – и хорошая новость в том, что нужный компонент вы, скорее всего, уже используете. В звонке с более чем двумя участниками аудио и видео не передаются напрямую между всеми. Вместо этого они проходят через медиа-сервер в центре – Selective Forwarding Unit, или SFU, который выступает в роли маршрутизатора: принимает по одному потоку от каждого участника и пересылает нужные потоки остальным. Этот сервер и браузерные хуки вокруг него мы подробно разбираем в статье про интеграцию ИИ в WebRTC.

SFU уникален для модерации по той же причине, по которой он важен для живых субтитров и перевода: это единственная точка, где в реальном времени видно медиа каждого участника, разделённое по людям. Именно это делает его естественным местом для конвейера модерации. Вы один раз снимаете поток на SFU, один раз запускаете проверки и один раз реагируете на результат – вместо того чтобы пытаться запустить классификатор внутри браузера каждого участника, где вы не можете доверять коду и не видите других участников. Паттерн совпадает с раздачей на стороне SFU, которую мы используем для субтитров: один захват, центральная обработка, одно решение, разосланное обратно.

Модерировать нужно три отдельные вещи, и для каждой требуется своя проверка – потому что это разные виды сигнала. Есть видео – кадры, в которых ищут наготу, сексуальные действия, насилие, оружие, кровь и известные нелегальные изображения. Есть аудио – речевая дорожка, где выявляют угрозы, разжигание ненависти, сексуальные домогательства и оскорбления. И есть текст – сообщения чата, обычно передаваемые по data channel WebRTC – стандартному боковому каналу для произвольных данных между участниками, описанному в IETF RFC 8831, – где ищут травлю, мошенничество, доксинг и ссылки на вредоносные сайты. Полноценная система обрабатывает все три компонента; многие команды начинают с видео, потому что оно несёт наиболее серьёзный и наименее спорный вред.

Нажмите, чтобы увеличить

Развилка шифрования, определяющая всю архитектуру

Прежде чем вы напишете первую строчку кода конвейера, есть одна архитектурная дилемма, которая тихо определяет, возможна ли серверная модерация вообще. Большинство команд сталкиваются с ней самым болезненным образом – это вопрос шифрования.

Обычный WebRTC-звонок зашифрован в транзите: медиа-данные скремблируются при передаче по сети, но остаются читаемыми на SFU, поскольку серверу необходимо их декодировать для пересылки. Именно эта возможность чтения позволяет SFU выполнять модерацию. Однако существует более строгий режим приватности – сквозное шифрование, или E2EE, при котором медиа-данные шифрует отправитель, а расшифровать может только получатель, но не промежуточный сервер. Стандарт, обеспечивающий такую защиту для медиа в реальном времени, – SFrame, опубликованный как IETF RFC 9605 в августе 2024 года. SFrame реализован умно: он шифрует медиа-кадры так, что SFU по-прежнему получает достаточно метаданных для маршрутизации, но не может увидеть изображение или услышать звук. Сервер пересылает «запечатанные конверты», не имея возможности их вскрыть.

Вот развилка. То же свойство, что делает E2EE приватным – сервер не может читать медиа, – делает серверную модерацию невозможной, потому что нельзя классифицировать картинку, которую не видишь. У вас физически не может быть одновременно настоящего сквозного шифрования и серверной модерации в одном потоке: это противоречие, а не инженерный пробел, который можно закрыть усилиями. Это самое важное предложение в статье, и его чаще всего осознают уже после того, как архитектура построена.

У вас есть три честных варианта, и выбор зависит от продукта. Можно использовать только транспортное шифрование и проводить модерацию на SFU – это надёжный выбор для открытых социальных сетей или дейтинг-платформ, где безопасность важнее максимальной приватности. Можно использовать настоящий E2EE и перенести модерацию на устройство, где медиа остаются читаемыми, приняв при этом, что вы теперь доверяете клиентскому коду и не видите содержимое сообщений участников – это путь приватного мессенджера. Или можно выбрать гибридный подход, при котором большинство звонков зашифрованы end-to-end, но помеченные или высокорисковые сессии понижаются до уровня, при котором сервер может их читать, чтобы провести проверку, при этом пользователи должны быть проинформированы об этом понижении. Четвёртого варианта, дающего и то, и другое одновременно, не существует. Это нужно решить в первую очередь, потому что именно этот выбор определяет, относится ли остальная часть статьи к вашему серверу или к вашему клиенту.

Нажмите, чтобы увеличить

Каждый кадр посмотреть невозможно – поэтому вы используете семплирование

Допустим, вы выбрали серверно-обрабатываемый путь. У большинства возникает естественный, но ошибочный рефлекс – запускать классификатор модерации на каждом кадре видео. Живое видео, скажем, идёт со скоростью тридцать кадров в секунду (fps) – тридцать неподвижных изображений, показываемых достаточно быстро, чтобы создавать иллюзию движения. Представьте, что вы платите за проверку визуального классификатора на всех тридцати кадрах каждую секунду.

Допустим, проверка одного изображения стоит $0,001 – десятую цента, реалистичная цена хостинговой модерации в 2026 году. Применяем её к каждому кадру одного видеопотока:

30 fps × 60 с × $0,001 = $1,80 в минуту, на один поток

Для одного потока это уже слишком; для тысячи одновременных потоков – $1 800 в минуту, что абсурдно для функции, которая ничего не приносит. Поэтому каждый кадр не проверяют. Вы берем выборку: проверяете несколько кадров в секунду и полагаетесь на то, что вред, заметный человеку, проявляется на протяжении многих кадров, так что выборка его обязательно выявит. Выборка с частотой два кадра в секунду вместо тридцати снижает расходы в пятнадцать раз:

2 fps × 60 с × $0,001 = $0,12 в минуту, на один поток

Двух кадров в секунду достаточно, потому что вредный контент, который зритель может воспринять, не мелькает быстрее, чем за одну тридцатую секунды – он задерживается, и проверка дважды в секунду его обязательно засечёт. Выборку делают ещё умнее, добавляя наиболее важные кадры: ключевые кадры (периодические полные изображения, которые и так генерирует видеокодек) и кадры смены сцены (моменты, когда картинка резко меняется – а это как раз и есть появление нового контента). Аудио обрабатывается аналогичным образом с помощью Voice Activity Detection (VAD) – недорогой программы, отвечающей на вопрос: «Говорит ли кто-то прямо сейчас?» – так что дорогостоящая проверка речи запускается только тогда, когда кто-то действительно говорит, а не во время тишины. Та же дисциплина позволяет эффективно использовать субтитры и перевод: сначала определяется, что именно нужно проверять, и только потом тратятся деньги на эту проверку.

Слоёный конвейер: дёшево и точно вместо дорого и размыто

Когда выборка решает, когда проверять, конвейер – что запускать, а правило упорядочивает проверки от самой дешёвой и точной к самой дорогой и размытой, останавливаясь как можно раньше.

Первый слой – сопоставление по хешу для известной нелегальной картинки. Хеш – это цифровой отпечаток, короткая строка чисел, вычисляемая на основе изображения. Известная система PhotoDNA, разработанная Microsoft и лицензированная Google, Meta и другими компаниями, создаёт отпечаток, устойчивый к небольшим изменениям – например, изменению размера или цветовой коррекции. Благодаря этому изображение, ранее признанное нелегальным, распознаётся даже после редактирования, призванного скрыть его. Отпечаток каждого отобранного кадра сравнивается с базой данных отпечатков материалов, связанных с сексуальным насилием над детьми. Такое сравнение происходит быстро, обходится недорого и даёт почти стопроцентную точность – при этом искусственный интеллект не должен анализировать само изображение, которое он никогда не видел. Этот слой используется первым, поскольку он наиболее надёжен и имеет наибольшее юридическое значение.

Второй слой – визуальная классификация для вредного контента без цифрового отпечатка, поскольку он новый: нагота, сексуальные действия, насилие, оружие, самоповреждение, кровь. Это как раз та ИИ-модель компьютерного зрения – Hive, AWS Rekognition, Azure AI Content Safety, Google Cloud Vision, – которая анализирует кадр и возвращает категории с оценкой уверенности, например: «явная нагота: 0,97». Она дороже и менее надёжна, чем хеш-сравнение, поэтому запускается только на выбранных кадрах, прошедших проверку по хешу. Когда фронтендная мультимодальная модель оказывается эффективнее профильного классификатора – например, при тонких или контекстно-зависимых решениях – здесь тоже уместна развилка «просто возьмём VLM».

Третий слой – модерация аудио. Речевую дорожку преобразуют в текст с помощью автоматического распознавания речи, после чего текст анализируют на наличие угроз, разжигания ненависти и домогательств. Некоторые движки, например Amazon Transcribe Toxicity Detection, учитывают и акустические признаки – такие как крик – чтобы выявить токсичный умысел, который мог бы остаться незамеченным при анализе только слов. Четвёртый слой – модерация текст-чата: проверка сообщений в data channel на признаки травли, мошенничества и доксинга. Это самая дешевая проверка из всех, поскольку объём текста минимальный. Вот эти четыре медиа бок о бок:

Нажмите, чтобы увеличить

Материалы с насилием над детьми – отдельная категория

Большая часть модерации – вопрос политики и вкуса: ваш продукт сам определяет, сколько обнажённой кожи или нецензурной лексики он готов терпеть. Есть одна категория, по которой решение уже принято – и под неё вы проектируете раньше всех остальных, потому что закон уже всё решил.

Материалы с сексуальным насилием над детьми, сокращённо CSAM (child-sexual-abuse material), нелегальны повсюду и регулируются нормами, которые имеют приоритет над вашими внутренними политиками. В США, как только провайдер становится осведомлён о наличии у себя видимого CSAM, федеральный закон – 18 U.S.C. § 2258A – обязывает его сообщить в CyberTipline, которую ведёт National Center for Missing & Exploited Children (NCMEC) – центральную точку приёма, передающую сообщения правоохранительным органам. Из этого следуют два инженерных вывода, которые легко сделать неправильно. Первый: вы не можете просто удалить материал, как только его обнаружили; вы обязаны сохранить его и сопутствующие данные как улику на срок, установленный законом, поэтому ваше действие «блок» для этой категории должно записывать данные в запечатанное хранилище улик, а не в корзину. Второй: закон требует сообщать только о том, о чём вы становитесь осведомлены – он не обязывает вас активно искать такие материалы, и общего мандата на мониторинг нет, – но в момент срабатывания вашего хеш-матчера вы уже осведомлены, и отсчёт времени начался.

Вот почему проверка по хешу стоит в конвейере первой и почему её действие «блок» отличается от всех остальных. Срабатывание классификатора наготы означает: спрячь это и, возможно, отправь на ревью; срабатывание хеша CSAM – останови поток, запечатай улику и подай сообщение. Прописывайте этот путь заранее, вместе с юристами, ещё до запуска. Добавлять его потом – значит рисковать: продукт либо нарушит закон, удалив улики, либо подорвёт доверие, неправильно обработав самые чувствительные данные, с которыми ему когда-либо придётся иметь дело. Технология обнаружения – перцептивный хеш – хорошо изучена; важно не она, а обязательства вокруг неё – именно эту часть нужно проектировать с особой осторожностью.

От оценки уверенности к действию

Классификатор не возвращает «плохо». Он выдаёт число – оценку уверенности от нуля до единицы, – и настоящий интеллект вашей системы – это лестница, превращающая это число в адекватное действие. Ошибиться в построении этой лестницы – значит либо оттолкнуть невинных пользователей, либо пропустить угрозу.

Логика пороговая. При высокой уверенности – скажем, выше 0,95 – вы реагируете автоматически и немедленно: размываете видео, глушите звук или приостанавливаете поток, потому что почти полная уверенность оправдывает действие без участия человека. В средней зоне – скажем, от 0,70 до 0,95 – вы применяете обратимые меры и отправляете материал в очередь на проверку человеком, поскольку машина подозревает, но не уверена, и окончательное решение должен принять человек, прежде чем наказывать пользователя. Ниже нижнего порога вы разрешаете контент, но логируете оценку, чтобы в дальнейшем настроить систему.

Два типа ошибок ведут в противоположные стороны: ложноположительное срабатывание размывает или удаляет контент, который не нарушает правила, делая продукт враждебным, а ложноотрицательное пропускает реальный вред к зрителям. Свести оба вида ошибок к нулю одновременно невозможно – снижая порог, вы ловите больше вредоносного контента, но наказываете больше невиновных. Поэтому баланс устанавливается по категориям: вы строги к тяжёлому, необратимому вреду и снисходительны к пограничным случаям, а в ситуациях, где оценка неопределённа, а цена ошибки высока, держите человека в петле принятия решений.

Нажмите, чтобы увеличить

Бюджет задержки и стоимости, вслух

Два числа определяют, готов ли дизайн к выпуску: сколько времени добавляет модерация и сколько она стоит. Оба – это бюджеты, которые вы задаёте заранее.

Сначала задержка. Чтобы модерация предотвращала вред, а не просто документировала его, решение должно прийти до того, как вредный кадр дойдёт до зрителей. Рычаг, покупающий время, тот же, что давно используют стриминговые площадки: небольшая задержка вещания. Придерживая живой поток на секунду-две перед тем, как он дойдёт до аудитории – современное эхо телевизионной «семисекундной задержки», – вы даёте конвейеру окно, чтобы взять кадр, оценить его и среагировать, пока контент ещё в буфере, а не на экранах зрителей. В плотном конференц-звонке, где даже секунда задержки вредит разговору, это окно купить нельзя, поэтому вы принимаете, что модерация реактивна – она отрезает нарушителя на такт позже, чем он начал, а не раньше, – и сильнее опираетесь на быстрые аудио-проверки и приостановку постфактум. Версия этой дисциплины тайминга для всего звонка – тема статьи про бюджет задержки до 100 миллисекунд.

Теперь стоимость – это та же математика выборки, перенесённая на парк. Возьмём площадку с пятьюстами одновременными живыми потоками, которая модерирует видео на двух кадрах в секунду по $0,001 за кадр, где аудио и текст добавляют примерно ещё половину:

видео = 500 потоков × 2 fps × 60 с × $0,001   = $60,00 в минуту
аудио + текст ≈ 0,5 × видео                    = $30,00 в минуту
итого ≈ $90 в минуту ≈ $5 400 за час пиковой одновременности

Это число – результат проектирования, а не закон природы, и его можно регулировать тремя рычагами. Снижение частоты выборки уменьшает его линейно, но рискует пропустить кратковременный вред. Обработка дешёвых слоёв хеша и текста на всех данных, а дорогой визуальный классификатор – только для уже помеченных потоков, даёт резкое снижение затрат. Самостоятельный запуск открытого визуального классификатора вместо оплаты за каждый вызов переносит стоимость с «за кадр» на фиксированную инфраструктуру, что окупается при объёме, превышающем тот, с которым обычно работает комплаенс, а не арифметика. Смысл озвучить бюджет в том, что «модерировать всё, всегда, на полной частоте кадров» – это не план, а способ выявить в продакшене, что безопасность может стоить дороже, чем продукт приносит дохода.

Частая ошибка: модерировать запись, а не живой поток

Самая разрушительная ошибка в этой области коварна, потому что система выглядит работающей. Команда подключает модерацию туда, где это проще всего – к конвейеру записи, который и так сохраняет каждую сессию в хранилище. Это аккуратный, файловый поток, удобный для передачи классификатору. Дашборд заполняется флагами. Все расслабляются.

Но запись создаётся после того, как прямой эфир уже прошёл перед аудиторией. Модерация записи выявляет вред с опозданием на час – слишком поздно, чтобы его предотвратить. Она генерирует отчёт, а не обеспечивает защиту. Зрители уже видели опасный кадр; всё, что даёт поздняя проверка, – это документальное подтверждение вреда, который вы не смогли остановить. Решение – архитектура, описанная в этой статье: записывать прямой медиапоток на SFU в режиме транзита и реагировать в пределах окна задержки вещания – а не на файле, который появляется позже. Оставьте проверку записи как более медленный и тщательный бэкстоп, способный использовать тяжёлые модели и людей-ревьюеров, но никогда не путайте её с модерацией в реальном времени. Система безопасности, которая срабатывает только после того, как вред уже произошёл, – не система безопасности; это архив ваших провалов.

Стройте на фреймворке, покупайте классификаторы, укомплектовывайте очередь

Когда паттерн устоялся, практический вопрос – из чего его собрать, и, как и в остальном стеке, слои независимы.

Медиа-слой – это сам видеозвонок. Можно использовать open-source SFU, например mediasoup, Janus или сервер LiveKit, и полностью контролировать захват кадров и блокировку, анализируя их через браузерные хуки Encoded Transform и Insertable Streams – об этом подробно рассказано в статье про интеграцию ИИ в WebRTC. Либо выбрать хостинговую платформу реального времени, которая передаёт медиа участников серверному агенту с минимальной дополнительной настройкой. LiveKit особенно удобен в этом плане, поскольку рассматривает серверный агент как полноценного участника системы, поэтому он часто используется в продакшен-решениях для модерации.

Слой классификаторов – это то, что почти всегда покупают или развёртывают самостоятельно, а не обучают с нуля. Хостинговые решения – Hive, AWS Rekognition, Azure AI Content Safety, Google Cloud Vision, бесплатный модерационный эндпоинт OpenAI для текста и изображений – отличаются не столько производительностью, сколько тем, в какой облачной экосистеме вы уже работаете, и как они тарифицируются. Специализированные вендоры вроде Hive предлагают более высокую точность в сложных визуальных категориях за более высокую плату за вызов. Что касается CSAM, то здесь не хватает пространства для выбора на маркетплейсе: вы подаёте заявку в Microsoft на PhotoDNA или сотрудничаете с NCMEC и Tech Coalition, потому что база отпечатков по замыслу ограничена. Слой поддержки – часть, которую команды недооценивают, а потом жалеют: очередь на ручную проверку и люди, чтобы её обслуживать, защищённое хранилище доказательств для юридических целей, журнал аудита каждого решения (который EU Digital Services Act требует уметь объяснить) и механизм апелляции, позволяющий ошибочно заблокированному пользователю запросить повторную проверку человеком. Конвейер – это каркас системы; очередь, журнал и апелляция – то, что делает его законным и человечным.

Где здесь Фора Софт

Мы создаём живые видеопродукты, где модерация – не опция, а необходимость: социальные сети и дейтинг-приложения, где незнакомцы общаются на камеру, маркетплейсы и платформы лайв-коммерции с открытым видео, e-learning и телемедицинские системы, где ответственность за безопасность очевидна. Мы строим модерацию так, как это обосновывает данная статья: на основе SFU, который вы и так используете для записи видео, аудио и чата. Мы применяем фильтрацию по выборке и наличию речи, чтобы затраты зависели от уровня риска, а не от объёма трафика.

Поскольку наши проекты работают в сфере видеонаблюдения, конференц-связи и регулируемых отраслей, мы рассматриваем вопрос шифрования как ключевое архитектурное решение, а не как неожиданность. Мы заранее проектируем сложные компоненты – очередь ручной проверки, защищённый путь хранения улик по материалам с признаками незаконной деятельности, аудит-логи, доступные регуляторам – ещё на первом спринте, а не после первого инцидента.

Модели обнаружения обновляются ежегодно. Архитектура, определяющая, где они применяются, сколько стоят и кто проверяет их ошибки, – вот та часть системы, которую нужно правильно спроектировать один раз и навсегда.

Главное

• Модерация в реальном времени должна сработать до того, как вред дойдёт до зрителей – времени на задержки нет.
• SFU – единственный сервер, который видит каждый поток; обрабатывайте и принимайте решения там один раз.
• Настоящее E2EE (SFrame) и серверная модерация несовместимы – выбирайте первое.
• Проверить каждый кадр невозможно; используйте семплирование: несколько кадров в секунду, а также ключевые кадры и моменты смены сцены.
• Сначала применяйте дешёвый и точный хеш, а уже потом – дорогой и неточный ИИ-классификатор.
• Известные случаи CSAM – это юридический процесс: при совпадении зафиксируйте как улику, сообщите в NCMEC, но не удаляйте данные.

Что почитать дальше

• Живые субтитры – паттерн ASR fan-out на стороне SFU
• WebRTC + AI: Insertable Streams, Encoded Transform и сравнение 100ms / video SDK
• Развилка «просто возьмём VLM» – когда фронтирная мультимодальность заменяет кастомный CV