Реалізація AI-модерації користувацького контенту на сайті

Уявіть: на форумі щодня публікують 50 000 коментарів. Ручна модерація потребує 12 осіб, кожен пропускає до 3% порушень. Ми стикалися з таким завданням при модернізації великого маркетплейсу — і вирішили його за рахунок каскаду ML-моделей. У цій статті розберемо, як побудувати систему AI-модерації, яка фільтрує спам, токсичність і небажані зображення з точністю >99% при <50 мс затримки.

Користувацький контент — коментарі, відгуки, зображення, повідомлення в чаті — потребує постійного контролю. Автоматика незамінна, коли обсяг перевищує тисячі публікацій на годину. Чисто ручна перевірка тут не масштабується: при 10 000 публікацій на добу команда з п'яти модераторів фізично не впорається. AI-модерація вирішує задачу швидко і дешево, залишаючи людині тільки спірні випадки. Гарантуємо скорочення ручної праці на 80% за рахунок автоматизації.

Що саме піддається автоматичній модерації

Текстовий контент: спам, нецензурна лексика, розпалювання ненависті, погрози, персональні дані у відкритому вигляді. Зображення: відверті матеріали, насильство, порушення авторських прав (через перцептивне хешування). Посилання: фішинг, шкідливі домени. Тональність: токсичні коментарі без явних заборонених слів.

Кожна категорія потребує окремої моделі або окремого API-ендпоінту — універсального рішення немає.

Як працює AI-модерація?

Архітектура будується на одному з трьох патернів.

Синхронна перевірка перед публікацією — користувач відправляє контент, сервер перевіряє його до збереження. Затримка 200–800 мс. Підходить для критичних сценаріїв: оплата відгуків, юридично значущі публікації.

Асинхронна черга — контент зберігається зі статусом pending, фоновий воркер перевіряє через чергу (RabbitMQ, SQS, Redis Streams). Публікація відбувається після схвалення або через N хвилин, якщо порушень немає. Підходить для високонавантажених форумів і чатів.

Гібридна схема — швидка синхронна перевірка за простими правилами (стоп-слова, довжина, патерни) + асинхронна ML-перевірка для тих, хто пройшов первинний фільтр.

POST /api/comment
  → sync: banned words check (< 5ms)
  → sync: OpenAI Moderation API (< 300ms)
  → save with status=published/flagged
  → async: image scan if attachments

Який API обрати?

Порівняння популярних інструментів для модерації тексту та зображень.

OpenAI Moderation API обробляє запит у середньому за 200 мс, що в 3 рази швидше за Perspective API при тій же точності. Для російськомовного контенту Perspective дає оцінку токсичності, але може помилятися на сарказмі.

import openai

def moderate_text(content: str) -> dict:
    response = openai.moderations.create(input=content)
    result = response.results[0]

    if result.flagged:
        categories = {k: v for k, v in result.categories.__dict__.items() if v}
        return {"allowed": False, "categories": categories}

    return {"allowed": True}

Google Perspective API — аналіз токсичності з оцінкою від 0 до 1. Атрибути: TOXICITY, SEVERE_TOXICITY, IDENTITY_ATTACK, INSULT, PROFANITY, THREAT. Підтримує російську мову. Квота: 1 QPS безкоштовно, платний тариф від $0.25 за 1000 запитів.

AWS Rekognition — модерація зображень. API DetectModerationLabels повертає ієрархію міток з confidence score. Категорії: Explicit Nudity, Violence, Visually Disturbing, Hate Symbols.

Azure Content Safety — текст і зображення в одному API. Категорії: hate, sexual, violence, self-harm. Кожна оцінюється за шкалою 0–6. Є Groundedness Detection для перевірки фактичності відповідей.

Власна модель на базі fine-tuning

Для специфічного контенту (професійний форум з технічною лексикою, медична платформа) сторонні API дають багато хибних спрацьовувань. Вихід — fine-tuning на своїх даних.

Процес: зібрати датасет із 2000–5000 розмічених прикладів (схвалені/відхилені), донавчити distilbert-base-multilingual-cased через Hugging Face Transformers, розгорнути як окремий сервіс.

from transformers import pipeline

classifier = pipeline(
    "text-classification",
    model="./moderation-model",
    device=0  # GPU
)

def classify_content(text: str) -> tuple[str, float]:
    result = classifier(text, truncation=True, max_length=512)[0]
    return result["label"], result["score"]

Inference на CPU — ~50 мс на текст до 512 токенів. На GPU (T4) — ~5 мс.

Обробка зображень

Перед відправкою в API потрібна попередня обробка: зміна розміру до 2048px по довгій стороні, конвертація в JPEG з якістю 85%, видалення EXIF-метаданих. Це знижує вартість і прискорює відповідь. Автоматизація дозволяє скоротити штат модераторів у кілька разів, що дає значну економію бюджету. Пілотне впровадження зазвичай окупається протягом кількох місяців.

Для захисту від завантаження заздалегідь відомого забороненого контенту — PhotoDNA (Microsoft) або pHash-порівняння з базою хешів. PhotoDNA інтегрується через Azure, pHash реалізується самостійно:

import imagehash
from PIL import Image

def compute_phash(image_path: str) -> str:
    img = Image.open(image_path)
    return str(imagehash.phash(img))

def is_known_violation(phash: str, banned_hashes: set, threshold: int = 10) -> bool:
    for banned in banned_hashes:
        if imagehash.hex_to_hash(phash) - imagehash.hex_to_hash(banned) < threshold:
            return True
    return False

Dashboard для ручной модерації

Автоматика не приймає рішення по пограничним випадкам — їх потрібно показати модератору. Черга ручної модерації містить:

• контент з confidence 0.4–0.7 (невпевнений результат);
• контент, на який поскаржилися користувачі;
• контент від нових акаунтів без історії.

Інтерфейс: список з фільтрами, гарячі клавіші для швидких рішень (approve/reject/escalate), історія рішень з прив'язкою до оператора, метрики точності по кожному оператору.

Зворотній зв'язок і перенавчання

Модель деградує, якщо контент-патерни змінюються. Цикл покращення:

1. Зберігати всі рішення (автоматичні та ручні) з мітками.
2. Щотижня аналізувати розбіжності: де автоматика помилилася, модератор виправив.
3. Раз на місяць донавчати модель на накопичених виправленнях.
4. A/B тестувати нову версію на 10% трафіку перед повним перемиканням.

Моніторинг

Метрики для Grafana/Datadog:

• moderation.requests.total — загальний обсяг;
• moderation.latency.p99 — затримка 99-го перцентиля;
• moderation.flagged.rate — частка заблокованого контенту;
• moderation.false_positive.rate — частка помилкових блокувань (за апеляціями);
• moderation.queue.depth — глибина черги ручної модерації.

Алерт: якщо false_positive.rate > 5% за 24 години — модель потрібно перевірити.

Що входить в роботу

• Інтеграція одного або кількох API (OpenAI, Perspective, Rekognition, Azure).
• Розробка синхронного middleware або асинхронної черги на вашому стеку.
• Dashboard для ручної модерації з історією та метриками.
• Документація по API та архітектурі.
• Навчання команди (2 години онлайн).
• Підтримка 1 місяць після запуску.

Строки реалізації

Базова інтеграція з OpenAI Moderation API і чергою ручної перевірки — 2 тижні. Повна система з власною моделлю, моніторингом і dashboard — 5–6 тижнів. Зв'яжіться з нами для пілотного проекту — оцінимо ваше навантаження і запропонуємо рішення. Замовте консультацію з інтеграції.

Інтеграція AI у веб-додатки: чат-боти, RAG, семантичний пошук

У 8 з 10 проектів «AI-чат-бот» виявляється дорогою обгорткою над GPT-4o з системним промптом. Без доступу до реальних даних компанії. Користувач питає «скільки коштує тариф Преміум» — бот галюцинує ціну з повітря. Питає «коли прийде замовлення» — отримує ввічливе «напишіть у підтримку». Це не інтеграція AI у веб-додатки — це імітація. Ми за 5 років впровадили RAG-рішення в 30+ проектах: від інтернет-магазинів до медичних порталів. Гарантуємо: корисна AI-допомога починається там, де модель читає ваші документи, а не загальні відповіді. Закажіть консультацію, щоб отримати план інтеграції для вашого проекту.

Побудова RAG-систем: чанкінг, ембедінги, векторна БД

Retrieval-Augmented Generation — стандартна архітектура: запит → пошук релевантних фрагментів у векторній БД → вставка знайденого в контекст → відповідь моделі. Але диявол у деталях реалізації.

Чанкінг. Різати документ на шматки по 500 токенів без огляду на структуру — гарантія втрати сенсу. Якщо розріз припав на середину абзацу, контекст розривається. Рішення — рекурсивний RecursiveCharacterTextSplitter з overlap 10–15% для документації. Для контрактів та інструкцій використовуємо семантичний спліттер: виділяємо заголовки, списки, блоки коду — кожен розділ стає незалежним чанком. Результат: на медичному проекті precision зріс з 0.55 до 0.84 лише завдяки правильному нарізанню, скорочення витрат на підтримку на 40% заощадило 80 000 грн на місяць.

Модель ембедингів. Для україномовних текстів intfloat/multilingual-e5-large дає помітний приріст точності проти застарілої text-embedding-ada-002. Наші виміри: NDCG@10 на 12% вищий. text-embedding-3-large хороший для англомовного контенту, але для української рекомендуємо BAAI/bge-m3.

Векторна БД. Якщо вже стоїть PostgreSQL — pgvector заощаджує ресурси. Ставимо розширення CREATE EXTENSION vector, додаємо колонку vector(1024), створюємо HNSW-індекс. На проекті з 80 000 статей p95 пошуку — 12 мс. Для каталогів з мільйонами одиниць — Qdrant або Weaviate: нативний гібридний пошук і шардування «з коробки».

Кроки реалізації RAG:

1. Збір та структурування даних (очищення, метадані).
2. Вибір моделі ембедингів (multilingual-e5-large або bge-m3).
3. Створення чанків (семантичний спліт із 10–15% overlap).
4. Індексація в pgvector (або Qdrant).
5. Інтеграція пошуку (гібрид BM25 + векторний через RRF) та реранкінг.

Що дає гібридний пошук?

Лише векторний пошук сліпий до точних збігів: артикули «ABC-123», власні назви, абревіатури губляться. Лише повнотекстовий не вловлює синоніми та перефразування. Комбінація через RRF (Reciprocal Rank Fusion) дає краще з двох світів: BM25 + векторний пошук, результати змішуються. На практиці recall@20 зростає з 0.65 до 0.92 — на 30% вищий за чисто векторний. Реранкінг через cross-encoder cross-encoder/ms-marco-MiniLM-L-6-v2 додає 50–100 мс до відповіді, але relevance піднімає ще на 5–10%.

Як реалізувати семантичний пошук у веб-додатку?

Пошук «зручні шкіряні крісла» має знаходити товари з описом «м'які стільці з натуральної шкіри» — звичайний LIKE-пошук не здатний. Архітектура: при додаванні товару/посту автоматично генеруємо ембединг через multilingual-e5-large, зберігаємо в pgvector. На запиті — ембедимо його тією ж моделлю, шукаємо найближчих сусідів через cosine distance з HNSW-індексом. Середній час пошуку — 20 мс.

Рекомендаційні системи: коли потрібна гібридна модель?

Колаборативна фільтрація («користувачі, схожі на вас, купували X») вимагає історії — мінімум 2–3 місяці даних із 1000+ активних користувачів. Для стартапів або малих проектів використовуємо content-based: ембединг поточного товару → пошук найближчих сусідів. Коли накопичується статистика (15–20 взаємодій на користувача), переключаємося на LightFM. Вона об'єднує поведінку та ознаки товарів. У e-commerce проекті з 50 000 SKU гібридна модель підвищила конверсію в рекомендаційний блок на 18% (A/B‑тест 2 тижні, що додатково принесло 250 000 грн прибутку за місяць).

Стрімінг відповідей через SSE

Користувач не зобов'язаний чекати, поки модель згенерує весь текст — це вбиває UX. Server-Sent Events (SSE) — протокол для стрімінгу токенів. OpenAI SDK підтримує stream: true, повертаючи AsyncIterator. На фронтенді — Vercel AI SDK (useChat) або самописний EventSource. Типова помилка: використовувати WebSocket для односпрямованого стріму — SSE простіше (менше коду, вбудований реконнект). Стек: Node.js + SSE + React.

Оркестрація агентів

Простий чат-бот відповідає. Агент — виконує дії: створює тікет у Jira, перевіряє статус замовлення в CRM, бронює слот у календарі. Для оркестрації використовуємо LangGraph: граф станів, кожен вузол — виклик моделі або інструменту. Vercel AI SDK дозволяє додати інтеграцію в 10 рядків коду. Головна складність — надійність: модель іноді викликає не той інструмент або передає криві параметри. Захист — Zod-схеми на кожен інструмент і structured outputs для гарантії JSON.

Процес роботи

Додатково: передаємо вихідний код векторизатора, дашборди моніторингу (Langfuse), доступ до адмінки для оновлення бази знань. Постпродакшн-підтримка — 1 місяць безкоштовно.

Терміни

Вартість розраховується індивідуально після знайомства з проектом. Оцінимо ваш проект за 1 день. Зв'яжіться з нами — розкажемо, як перетворити AI з іграшки на інструмент, що приносить прибуток. Закажіть консультацію, щоб дізнатись, як інтегрувати AI у ваш веб-додаток.