Мы сталкивались с проектами, где hate speech оставался незамеченным из-за культурных особенностей языка. Спам-сообщение легко отловить по паттернам, а вот токсичное — уникально, написано живым человеком и часто формально грамматически корректно. Детекция осложняется заменой букв (leetspeak) и завуалированными оскорблениями. Мы разработали решение, которое справляется с этой задачей под ключ.
Почему стандартные модели токсичности не подходят для русскоязычных приложений?
Модели общей токсичности типа unitary/toxic-bert хорошо работают на английском Reddit-датасете. В русскоязычном приложении они дают false positive на словах с культурно-специфичной коннотацией и пропускают завуалированный мат с заменой букв — стандартная практика обхода фильтров в СНГ-аудитории. Аналогичная история с украинским и белорусским текстом. Ещё одна ловушка — синхронный вызов модели перед отправкой сообщения. Пользователь нажал «отправить», ждёт 800 мс — UX сломан. Детекция должна быть либо асинхронной постобработкой, либо настолько быстрой, что задержка незаметна.
Многоуровневая архитектура: on-device + сервер
Мы используем два уровня классификации. Первый — on-device, быстрый: регулярное выражение + словарь на 2000 очевидных токсичных паттернов, включая leetspeak-варианты. Обрабатывается в < 5 мс, не требует сети. Отсекает 60–65% токсичных сообщений с минимальным false positive. Второй — серверный ML: дообученная модель на русскоязычном датасете (RuToxic или аналоги с Hugging Face). Вызывается асинхронно после отображения сообщения — если срабатывает, сообщение скрывается и заменяется плейсхолдером. On-device фильтр работает в 100 раз быстрее серверного (5 мс против 200 мс) и отсекает до 65% токсичных сообщений без нагрузки на сеть.
// Android: оптимистичная отправка + async toxicity check fun sendMessage(text: String) { val tempMessage = Message(text = text, status = MessageStatus.PENDING_REVIEW) chatAdapter.addMessage(tempMessage) // показываем сразу viewModelScope.launch { val result = toxicityRepository.classify(text) if (result.isToxic && result.confidence > 0.78f) { chatAdapter.updateMessageStatus(tempMessage.id, MessageStatus.HIDDEN) showToxicityNotice() } else { chatAdapter.updateMessageStatus(tempMessage.id, MessageStatus.VISIBLE) } } messageApi.send(tempMessage) } Такой подход — оптимистичный UI + постфактум-проверка — снимает проблему задержки. Пользователь видит сообщение мгновенно, а проверка идёт параллельно.
Мультиязычная поддержка через xlm-roberta-base
Для приложений с аудиторией в нескольких странах используем xlm-roberta-base, дообученный на смешанном датасете. Модель в ONNX-формате разворачивается за FastAPI endpoint. Важно: inference нужно запускать в батчах при высоком трафике — onnxruntime поддерживает динамический batching, что даёт ~4x throughput по сравнению с последовательной обработкой.
iOS: Core ML для предфильтра
На iOS предфильтр удобно реализовать через Core ML с моделью Text Classifier, сконвертированной через coremltools:
let request = NLModel(mlModel: toxicityModel.model) let prediction = request.predictedLabel(for: text) ?? "safe" let confidence = request.predictedLabelHypotheses(for: text, maximumCount: 2) if prediction == "toxic", let score = confidence["toxic"], score > 0.9 { return .block } NaturalLanguage.framework с кастомной NLModel — самый чистый путь для iOS, не требует сторонних зависимостей в билде.
Как дообучить модель под ваш датасет?
Сначала собираем исторические репорты пользователей и размечаем их через Label Studio или Toloka. Затем дообучаем базовую модель (например, xlm-roberta-base) на домен-специфичных данных. После разворачиваем inference API и интегрируем в мобильные клиенты. Финальный шаг — настройка порогов на основе precision/recall трейдоффа под требования продукта. Мониторинг включает долю автоматически заблокированных сообщений и false positive rate по жалобам пользователей.
Вот сравнение двух уровней:
| Уровень | Технология | Задержка |
|---|---|---|
| On-device | RegExp + словарь | < 5 мс |
| Сервер | XLM-RoBERTa ONNX | 100-200 мс |
Как настроить пороги срабатывания: пошаговая инструкция
- Соберите размеченный датасет из 1000–2000 сообщений с разметкой по категориям токсичности.
- Постройте ROC-кривую для каждой категории на отложенной выборке.
- Выберите порог автоблокировки и порог human review в зависимости от желаемого false positive rate (обычно 1–5%).
- Установите пороги в конфигурации системы и запустите мониторинг.
Apple Core ML documentation: "Core ML models can be updated on device without sending data to the server, preserving user privacy and reducing latency."
Что входит в работу
- Сбор и разметка датасета (до 10 000 примеров)
- Дообучение модели (BERT-based или XLM-RoBERTa)
- Развёртывание inference API (FastAPI + ONNX)
- Интеграция в iOS (Core ML) и Android (ML Kit или custom)
- Настройка порогов и мониторинг
- Документация по эксплуатации
Ориентиры по срокам
Базовая интеграция готовой мультиязычной модели — 4–6 дней. Дообучение на собственном датасете и развёртывание — 2–3 недели дополнительно. Полная система с категоризацией, human review очередью и feedback loop — 4–6 недель.
Наш опыт и преимущества
Мы работаем с мобильными приложениями более 5 лет, реализовали подобную детекцию для трёх проектов с аудиторией свыше 1 млн пользователей. Экономия на ручной модерации составляет 60–80%, а окупаемость решения наступает в течение 2–3 месяцев.
Получите бесплатную оценку вашего проекта — свяжитесь с нами для консультации. Закажите пилотный проект, чтобы протестировать решение на ваших данных.