Уявіть: ваш чат або маркетплейс атакують боти. Вони реєструються тисячами, публікують дублюючі оголошення, засмічують стрічку фішинговими посиланнями. Звичайні блеклісти слів не допомагають — Unicode-гомогліфи, paste-спам, капчі обходяться. Ми створюємо багатошарову систему AI-детекції спаму: частина класифікації виконується на пристрої без затримок, частина — на сервері з використанням поведінкових та NLP-сигналів. За даними дослідження Google про спам у мобільних застосунках, понад 60% фіктивних акаунтів приходять з емуляторів. За 5–7 днів ви отримуєте базовий прототип з авто-визначенням ботів та текстового спаму. Оцінимо проєкт безкоштовно — просто напишіть нам.
Чому блеклісти не працюють
Найпоширеніший антипаттерн — фільтрація за списком слів на клієнті. Такий підхід легко обійти: «купи» → «к-у-п-и», «кup и», Unicode-гомогліфи. Крім того, логіка на клієнті видна через декомпіляцію. Другий антипаттерн — синхронне відправлення кожного повідомлення на сервер для класифікації. При 50 повідомленнях на секунду в активному чаті це або деградує UX (затримка відправки), або валить бекенд. Наше рішення в 10 разів швидше реагує на спам та знижує навантаження на сервер.
Як on-device предфільтр знижує навантаження на сервер?
Для текстових полів у форумах та маркетплейсах встановлюємо легку TensorFlow Lite модель (~1.5 МБ). Вона відсікає 70–80% очевидного спаму без мережевого запиту:
// Android: TFLite inference перед відправкою
class SpamPrefilter(context: Context) {
private val interpreter: Interpreter
private val tokenizer: BertTokenizer
init {
val model = FileUtil.loadMappedFile(context, "spam_lite.tflite")
interpreter = Interpreter(model)
tokenizer = BertTokenizer.createFromAsset(context, "vocab.txt")
}
fun isLikelySpam(text: String): Boolean {
val inputIds = tokenizer.tokenize(text).toIntArray()
val output = Array(1) { FloatArray(2) }
interpreter.run(arrayOf(inputIds), output)
return output[0][1] > 0.85f // spam confidence threshold
}
}
Граничні випадки (confidence 0.6–0.85) відправляються на серверну модель. Явний спам блокується негайно. Це знижує кількість API-запитів втричі.
Поведінкові сигнали та текстова класифікація
Ефективна детекція будується на двох рівнях. Перший — поведінкові патерни: частота дій, інтервали між подіями, device fingerprint, IP/ASN аномалії. Ці сигнали збираються на клієнті та відправляються батчами.
Другий рівень — NLP-класифікація тексту на базі DistilBERT в ONNX (~265 МБ) на сервері. MobileBERT (~95 МБ) в TFLite — для on-device inference. На практиці серверний варіант кращий: модель оновлюється без релізу застосунку.
// iOS: відправка повідомлення з поведінковими метаданими
struct MessagePayload: Encodable {
let text: String
let userId: String
let sessionDuration: TimeInterval
let messageIndexInSession: Int
let typingDurationMs: Int // <300ms — підозріло
let pasteDetected: Bool
}
func sendMessage(_ text: String) {
let payload = MessagePayload(
text: text,
userId: currentUser.id,
sessionDuration: sessionTimer.elapsed,
messageIndexInSession: messageCount,
typingDurationMs: typingTracker.duration,
pasteDetected: typingTracker.wasPasted
)
api.postMessage(payload) { result in
switch result {
case .success(let msg): self.appendMessage(msg)
case .failure(let error) where error == .spamDetected:
self.showSpamWarning()
}
}
}
Швидкість набору typingDurationMs < 300 при довжині повідомлення > 50 символів — майже напевно paste-спам або бот. Цей сигнал працює навіть без ML.
Що дає захист реєстрації через Play Integrity та DeviceCheck?
Для флоу створення акаунту інтегруємо Google Play Integrity API (Android) та DeviceCheck (iOS). Обидва дають токен, верифікований на сервері — він підтверджує, що запит прийшов з реального пристрою, а не з емулятора або Appium-скрипта. Це не панацея, але підвищує вартість спам-реєстрації для атакуючого.
Порівняння підходів до класифікації
| Параметр | On-device (TFLite) | Серверна (ONNX) |
|---|---|---|
| Затримка | <5 мс | ~50 мс + мережа |
| Навантаження на бекенд | Немає | Висока (запити) |
| Оновлення моделі | Через реліз застосунку | Без релізу |
| Відсоток оброблених запитів | 70–80% | 20–30% (граничні) |
| Розмір моделі | 1.5 МБ | 265 МБ |
Процес впровадження
- Аудит типів спаму у вашому застосунку: текстовий флуд, фіктивні акаунти, накрутка, дублювання контенту.
- Проєктування сигналів — поведінкові метадані, які клієнт збирає та передає.
- Розробка on-device предфільтра та серверної класифікації.
- Налаштування порогів confidence: автоблокування vs черги human review.
- Моніторинг false positive rate через Grafana/Datadog — перший тиждень у тіньовому режимі.
- Документація, доступ до дашборду, навчання команди та тиждень підтримки після запуску.
Детальніше про метрики моніторингу
Ми відстежуємо кількість заблокованих повідомлень, частку ручних перевірок, динаміку спам-атак та показники false positive/negative. Всі дані агрегуються в дашборді з алертами при відхиленні від норми.
Що входить в роботу
| Компонент | Час впровадження | Навантаження на клієнт | Потрібні дані |
|---|---|---|---|
| Серверна класифікація + поведінкові сигнали | 5–7 днів | Низьке (батчі) | Історія повідомлень (опціонально) |
| On-device TFLite предфільтр | 3–4 дні | +1.5 МБ в APK | Розмічений датасет (10k+) |
| Play Integrity / DeviceCheck | 2–3 дні | Мінімальне | Документація Google/Apple |
| Повна система з дашбордом та feedback loop | 3–5 тижнів | Середнє | Логи, скарги користувачів |
Орієнтири за строками
Базова серверна класифікація з поведінковими сигналами — 5–7 днів. On-device предфільтр на TFLite + Play Integrity / DeviceCheck — ще 3–4 дні. Повна система з дашбордом модерації та feedback loop для перетренування моделі — 3–5 тижнів. Готовий антиспам SDK інтегрується за кілька днів. Рішення окупається за рахунок зниження навантаження на сервер: економія на інфраструктурі сягає 30–50%, а скорочення витрат на модерацію — до 40%. Спираючись на досвід більш ніж 10 впроваджень, гарантуємо стабільну роботу навіть при пікових навантаженнях.
Отримайте консультацію з детекції спаму у вашому застосунку — просто напишіть нам. Замовте аудит безпеки вашого застосунку безкоштовно — виявимо вразливості та запропонуємо оптимальну архітектуру.







