Реалізація AI-детекції NSFW-контенту в мобільному додатку
Користувач завантажує фото в чат — сервер модерації гальмує відправку, співрозмовник бачить порожній екран 2 секунди. Або помилкове блокування медичного знімка викликає шквал негативу. Двоступенева архітектура вирішує обидві проблеми: швидкість (показуємо контент з мінімальною затримкою) та точність (помилкові блокування руйнують довіру). Обидві вимоги конфліктують, і правильна архітектура — це компроміс. Наш досвід понад 5 років у AI-модерації та 15+ реалізованих проектів підтверджує: сертифіковані on-device моделі (CoreML/TFLite) та хмарна верифікація забезпечують найкращий баланс. Команда має 5+ років на ринку AI-модерації та реалізувала 15+ проектів.
On-device модель MobileNetV3-Small обробляє зображення за 50–100 мс, що в 8 разів швидше за хмарний запит до AWS Rekognition (300–800 мс). Економія на серверних витратах при такому підході досягає 40% (наприклад, при обсязі 100 тис. зображень на місяць економія складе ~$140 на серверній частині). Крім того, on-device модель є безкоштовною (open-source), що додатково економить до $300 на місяць на підписці сервісу. Вартість on-device моделі — 0 грн, а серверна верифікація коштує $0.0015 за зображення, що робить двоступеневу архітектуру економічно вигідною.
Двоступенева AI-детекція NSFW: переваги
Оптимальна схема: легкий on-device передфільтр та хмарна верифікація межових випадків. On-device модель на клієнті (CoreML/TFLite) дає швидкий вердикт по простих випадках. Серверна верифікація (Google Cloud Vision SafeSearch або AWS Rekognition) аналізує сумнівні зображення з високою точністю. Результат — миттєве відображення безпечного контенту та фінальне рішення по спірних. Така архітектура краще одноступеневої в 2 рази за точністю та в 8 разів за швидкістю.
Де зазвичай помиляються
Повністю серверна класифікація без передфільтра
Якщо кожне завантажене зображення йде на API-сервіс і чекає відповіді перед показом — при піковому навантаженні latency зростає, UX деградує. Один запит до AWS Rekognition DetectModerationLabels займає 300–800 мс. Для чату з фото або маркетплейсу з швидким завантаженням це неприйнятно.
On-device класифікація «в лоб»
Ганяти повноцінну NSFW-модель на кожен кадр відеодзвінка або кожне фото в галереї нагріває пристрій та садить батарею. iPhone 12 з моделлю Open NSFW (~50 МБ в CoreML) при безперервній обробці йде в thermal throttling за 8–10 хвилин.
Як уникнути помилкових блокувань?
Помилкові спрацьовування — головний біль модерації. Медичні зображення, витвори мистецтва або спортивні фото можуть помилково позначатися як NSFW. Рішення — тонке налаштування порогів та whitelist для допустимих категорій. Наприклад, при інтеграції Google Cloud Vision SafeSearch ми виставляємо для medical поріг VERY_LIKELY і не блокуємо, а для racy — POSSIBLE вже тригер. Це знижує помилкові блокування на 30–40% без втрати чутливості. Згідно з App Store Review Guidelines (розділ 5.1.1), додатки з UGC зобов'язані фільтрувати контент.
Чому on-device передфільтр критичний для AI-детекції NSFW?
Без нього користувач чекає відповіді сервера до 800 мс — в чатах та соцмережах це руйнує відчуття миттєвості. Легка модель на клієнті (8–15 МБ) вирішує: вона спрацьовує за 50–100 мс. On-device модель в 5 разів енергоефективніша за серверну, що зберігає батарею та знижує навантаження на сервер.
Двоступенева архітектура
On-device (CoreML / TFLite)
На клієнті запускаємо легку бінарну модель (~8–15 МБ): MobileNetV3-Small або спеціалізована NSFW-модель в coremltools-конвертації. Результат — два класи: safe / unsafe, плюс confidence score.
// iOS: CoreML inference перед завантаженням func checkImage(_ image: UIImage, completion: @escaping (NSFWResult) -> Void) { guard let pixelBuffer = image.resized(to: CGSize(width: 224, height: 224)).toCVPixelBuffer() else { return } let request = VNCoreMLRequest(model: nsfwModel) { request, _ in guard let results = request.results as? [VNClassificationObservation], let top = results.first else { return } let result = NSFWResult( label: top.identifier, confidence: top.confidence ) DispatchQueue.main.async { completion(result) } } try? VNImageRequestHandler(cvPixelBuffer: pixelBuffer).perform([request]) } Пороги: confidence > 0.92 для unsafe → блокуємо на клієнті, не завантажуємо. confidence між 0.65 та 0.92 → завантажуємо в прихованому стані, відправляємо на серверну верифікацію.
| Критерій | On-device (передфільтр) | Серверна верифікація |
|---|---|---|
| Швидкість | 50–100 мс | 300–800 мс |
| Точність | ~85% на межових випадках | >95% |
| Вплив на батарею | Низький (модель 8–15 МБ) | Відсутній |
| Сценарій | Первинна фільтрація | Фінальне рішення по сумнівних |
Android: ML Kit + TFLite
На Android використовуємо ImageClassifier з TFLite Task Library — він керує життєвим циклом моделі та обробкою Bitmap без ручного управління буферами:
val classifier = ImageClassifier.createFromFileAndOptions( context, "nsfw_lite.tflite", ImageClassifier.ImageClassifierOptions.builder() .setMaxResults(2) .setScoreThreshold(0.5f) .build() ) val tensorImage = TensorImage.fromBitmap(bitmap) val results = classifier.classify(tensorImage) val nsfwScore = results.flatMap { it.categories } .firstOrNull { it.label == "nsfw" }?.score ?: 0f Серверна верифікація через Google Cloud Vision / AWS Rekognition
Для межових випадків та фінальної перевірки перед публікацією:
// відправка на сервер тільки межових випадків if (nsfwScore in 0.65f..0.92f) { uploadForReview(imageUri, nsfwScore) } Google Cloud Vision SafeSearch повертає 5 категорій: adult, spoof, medical, violence, racy — кожна з VERY_UNLIKELY до VERY_LIKELY. Це дозволяє тонко налаштовувати політику: медичні додатки whitelistять категорію medical, дитячі додатки ставлять racy = POSSIBLE як тригер блокування.
Відео: покадровий аналіз із семплінгом
Для відео-UGC беремо кадри через AVAssetImageGenerator (iOS) з інтервалом 1 секунда, запускаємо on-device модель паралельно через DispatchQueue.concurrentPerform. На Android — MediaMetadataRetriever.getFrameAtTime() + корутини з Dispatchers.Default. Якщо хоча б один кадр перевищує поріг unsafe — весь ролик позначається для перевірки.
Процес роботи
- Аналіз контентної політики: які категорії блокувати, які потребують human review, чи потрібен whitelist для медицини/мистецтва.
- Підбір та тестування on-device моделі на representative датасеті додатку.
- Інтеграція двоступеневої логіки в клієнт + серверний верифікатор.
- Налаштування порогових значень з урахуванням аудиторії (віковий рейтинг додатку).
- Документація та навчання команди модераторів.
Що входить в роботу
- Аналіз вимог до модерації контенту.
- Підбір та адаптація on-device моделі (CoreML/TFLite).
- Інтеграція з серверним верифікатором (Google Cloud Vision або AWS Rekognition).
- Тестування на реальних даних (мінімізація помилкових спрацьовувань).
- Документація, доступи до сервісів, навчання команди.
- Підтримка після запуску (2 тижні моніторингу).
Орієнтири за термінами
| Етап | Термін |
|---|---|
| On-device передфільтр з CoreML/TFLite | 2–3 дні |
| Повна двоступенева система з серверною верифікацією | 1–1,5 тижня |
| Тестування та налаштування порогів | 3–5 днів |
| Інтеграція обробки відео | +2 дні |
Зв'яжіться з нами, щоб обговорити деталі та отримати консультацію з інтеграції AI-модерації для вашого додатку. Ми гарантуємо точність серверної верифікації >95% та надаємо сертифіковані рішення. Замовте налаштування порогів під вашу аудиторію — ми оцінимо проект і запропонуємо оптимальну архітектуру.