AI-система для A/B-тестирования креативов: автоматизация и оптимизация

Разработка AI-системы для автоматического A/B-тестирования креативов

Ручное A/B-тестирование рекламных креативов — трудоёмкий процесс. Когда в кампании сотни вариантов изображений, заголовков и аудиторных сегментов, ждать 2-3 недели для получения статистически значимых результатов невыгодно. Мы разрабатываем AI-системы, которые автоматически генерируют гипотезы, запускают тесты и масштабируют победителей в реальном времени. Наш опыт в MLOps и байесовской оптимизации позволяет сократить цикл тестирования до 3-5 дней и повысить ROAS на 15-30%. Хотите такую же систему? Закажите разработку под ваш бизнес.

Как AI-система превосходит традиционное A/B-тестирование?

Традиционный подход фиксирует варианты и ждёт набора данных. Если победитель появляется рано, трафик всё равно делится поровну до конца теста. AI-система на базе Multi-Armed Bandit динамически перераспределяет трафик: лучшие креативы получают больше показов сразу, без ожидания. Это экономит бюджет и ускоряет вывод эффективных вариантов в production. Используем Thompson Sampling (Wikipedia: Thompson Sampling) — алгоритм, который балансирует исследование и эксплуатацию, гарантируя минимальные потери на субоптимальных вариантах.

Почему Multi-Armed Bandit эффективнее классического подхода?

Классический A/B тест требует заранее заданного размера выборки и фиксированного времени. Если разница между вариантами велика, тест можно остановить раньше, но это требует ручного контроля. Thompson Sampling автоматически вычисляет вероятность превосходства каждого варианта и останавливает тест при достижении 95% уверенности. Это снижает риск ложных срабатываний и ускоряет принятие решений. На практике ускорение цикла в 3-5 раз по сравнению с традиционными методами — обычное дело.

Архитектура системы

Creative Intelligence Layer

Анализ существующих креативов: извлечение признаков (цвета, объекты, текст, эмоциональный тон), кластеризация по визуальным паттернам, предсказание CTR до запуска теста.

Experiment Management

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

Multi-Armed Bandit

Динамическое перераспределение трафика в пользу лучших вариантов без ожидания окончания классического A/B теста.

Как работает Creative Intelligence Layer?

Модуль использует CLIP-embeddings для анализа визуального контента. Извлекает признаки (цвета, объекты, текст) и строит эмбеддинги размерностью 512. Затем эти эмбеддинги используются для предсказания CTR до запуска теста — точность достигает 85% на исторических данных.

Multi-Armed Bandit для оптимизации

import numpy as np
from dataclasses import dataclass, field

@dataclass
class CreativeVariant:
    id: str
    name: str
    impressions: int = 0
    conversions: int = 0
    # Beta distribution parameters (Bayesian)
    alpha: float = 1.0  # Prior: 1 успех
    beta: float = 1.0   # Prior: 1 неуспех

class ThompsonSamplingOptimizer:
    def __init__(self, variants: list[CreativeVariant]):
        self.variants = {v.id: v for v in variants}

    def select_variant(self) -> str:
        """Выбор варианта через Thompson Sampling"""
        samples = {}
        for vid, v in self.variants.items():
            # Сэмплирование из Beta-распределения
            samples[vid] = np.random.beta(v.alpha, v.beta)

        return max(samples, key=samples.get)

    def update(self, variant_id: str, converted: bool):
        v = self.variants[variant_id]
        v.impressions += 1
        if converted:
            v.conversions += 1
            v.alpha += 1
        else:
            v.beta += 1

    def get_probabilities(self) -> dict:
        """Вероятность того, что вариант является лучшим"""
        n_simulations = 10_000
        wins = {vid: 0 for vid in self.variants}

        for _ in range(n_simulations):
            samples = {vid: np.random.beta(v.alpha, v.beta)
                      for vid, v in self.variants.items()}
            winner = max(samples, key=samples.get)
            wins[winner] += 1

        return {vid: wins[vid] / n_simulations for vid in self.variants}

Автоматический анализ креативов

import torch
from transformers import CLIPModel, CLIPProcessor

class CreativeAnalyzer:
    def __init__(self):
        self.clip = CLIPModel.from_pretrained("openai/clip-vit-base-patch32")
        self.processor = CLIPProcessor.from_pretrained("openai/clip-vit-base-patch32")

    def extract_features(self, image_path: str) -> np.ndarray:
        """Извлечение визуальных признаков через CLIP"""
        image = Image.open(image_path)
        inputs = self.processor(images=image, return_tensors="pt")
        with torch.no_grad():
            features = self.clip.get_image_features(**inputs)
        return features.numpy().flatten()

    def predict_ctr(self, creative_features: np.ndarray,
                    audience_segment: str) -> float:
        """Предсказание CTR до запуска теста"""
        # Обученная модель на исторических данных
        combined = np.concatenate([
            creative_features,
            self.segment_encoder.encode(audience_segment)
        ])
        return float(self.ctr_model.predict([combined])[0])

Интеграция с рекламными платформами

from facebook_business.api import FacebookAdsApi
from facebook_business.adobjects.adcreative import AdCreative

def create_and_launch_test(access_token, ad_account_id, variants):
    FacebookAdsApi.init(access_token=access_token)

    for variant in variants:
        creative = AdCreative(parent_id=ad_account_id)
        creative.update({
            'name': variant['name'],
            'object_story_spec': {
                'page_id': PAGE_ID,
                'link_data': {
                    'image_hash': variant['image_hash'],
                    'link': variant['url'],
                    'message': variant['text']
                }
            }
        })
        creative.remote_create()

Сравнение подходов

Сравнение MLOps-инструментов

Как мы это делаем: пример из практики

Недавно внедрили систему для fashion-ритейлера: 150+ вариантов креативов, 4 аудиторных сегмента. Thompson Sampling определил топ-10 за 4 дня, ROAS вырос на 22%. Затраты на тестирование снизились в 2 раза за счёт early stopping. Система окупилась за 2 месяца, экономя около 1,5 млн рублей ежемесячно на масштабных кампаниях.

Процесс разработки

1. Аналитика: аудит текущих креативов и рекламных кампаний, сбор исторических данных, выявление паттернов.
2. Проектирование: выбор стека (PyTorch, Hugging Face, CLIP, LangChain), разработка архитектуры Creative Intelligence Layer и Experiment Management.
3. Реализация: написание кода оптимизатора на Python, интеграция с рекламными API (Facebook, Google Ads, Яндекс.Директ), обучение моделей предсказания CTR.
4. Тестирование: A/B тест системы против ручного управления на исторических данных, проверка latency p99 (цель <100 мс на принятие решения).
5. Деплой: развёртывание на GPU-инстансах с использованием Triton Inference Server или vLLM, настройка мониторинга в MLflow.

Сроки и стоимость

Срок разработки базовой системы — от 4 до 8 недель. Стоимость рассчитывается индивидуально в зависимости от сложности интеграций и объёма данных. Свяжитесь с нами для оценки вашего проекта — мы подготовим коммерческое предложение за 1-2 дня.

Что входит в работу

• Разработка модуля анализа креативов на базе CLIP-embeddings.
• Реализация Thompson Sampling оптимизатора с поддержкой нескольких рук (variants).
• Интеграция с рекламными платформами через REST API.
• Создание дашборда для мониторинга тестов (количество конверсий, вероятность превосходства, экономия бюджета).
• Документация по эксплуатации системы и обучение вашей команды.
• Поддержка в течение 3 месяцев после запуска.

Метрики и результаты

После внедрения: ускорение цикла тестирования с 2-3 недель до 3-5 дней, повышение ROAS на 15-30% за счёт непрерывной оптимизации, снижение затрат на тестирование до 50% за счёт автоматического early stopping. Наши сертифицированные инженеры гарантируют стабильную работу системы и готовы помочь с кастомизацией под ваши задачи. Получите консультацию — свяжитесь с нами для обсуждения вашего проекта.

MLOps: инфраструктура для обучения, деплоя и мониторинга ML-моделей

Модель обучена, метрики — F1 0.94 на валидации. Через три месяца в продакшене качество падает на 12%. Никто не знает, когда именно — нет мониторинга. Нельзя быстро переобучить — обучающий скрипт лежит в Jupyter-ноутбуке у data scientist’а, который уже уволился. Данные для ретрейна собирают руками из трёх разрозненных систем. Примерно половина проектов приходят к нам с этой болью. Мы строим MLOps платформу под ключ: от трекинга экспериментов до автоматического деплоя и мониторинга дрейфа данных. Оценим вашу инфраструктуру за 1–2 недели, а через 4–6 недель вы получите базовое ядро MLOps, работающее в продуктивном контуре. Наша команда — 10+ лет опыта в ML-инфраструктуре, более 50 внедрений.

Experiment tracking и воспроизводимость

Без трекинга ML-проект превращается в хаос: непонятно, какой чекпоинт лучше, какие гиперпараметры использовались, какой датасет. Воспроизвести результат через месяц — квест.

MLflow — open source стандарт для трекинга. Логирует параметры, метрики, артефакты (модели, графики) и код. MLflow Model Registry — централизованное хранилище моделей с версионированием и lifecycle stages (Staging → Production → Archived). Деплой через MLflow Serving или интеграция с внешними системами.

Типичная инициализация в коде:

import mlflow

mlflow.set_experiment("fraud-detection-v2")
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 3e-4, "batch_size": 64, "epochs": 10})
    mlflow.log_metric("val_f1", val_f1, step=epoch)
    mlflow.pytorch.log_model(model, "model")

Это минимум. В production добавляем логирование системных метрик (GPU utilization, memory), датасета (hash, версия), кода (git commit hash). Weights & Biases — более богатый UI, collaboration features, sweep для hyperparameter optimization. MLflow — для on-premise deployment без внешних зависимостей.

DVC (Data Version Control) — версионирование данных и моделей поверх git. Данные хранятся в S3/GCS/Azure Blob, в git — только метаданные (хэши). dvc repro воспроизводит весь пайплайн от сырых данных до метрик.

Как обеспечить воспроизводимость обучения? Фиксируйте random seeds (torch.manual_seed, numpy.random.seed, random.seed) и записывайте их в метаданные эксперимента. Без этого дебаггинг нерегулярных результатов — боль. Логируйте версию датасета (DVC hash) и git commit — тогда любой эксперимент можно повторить с точностью до байта.

Оркестрация пайплайнов: Kubeflow, Airflow, Prefect

Когда нужен оркестратор пайплайнов? Скрипт обучения на 100 строк в cron — нормально для простых задач. Но как только появляется multi-step пайплайн (загрузка данных → preprocessing → feature engineering → обучение → валидация → деплой если качество выше порога), нужен оркестратор с retry-логикой, визуализацией, алертами.

Kubeflow — Kubernetes-native оркестратор для ML (см. Wikipedia). Каждый шаг — Docker-контейнер. Поддерживает параллельные шаги, условные ветки, артефакты между шагами. Интегрируется с Katib (AutoML), KServe (serving), Feast (feature store).

Apache Airflow — более общий DAG-оркестратор. Широкая экосистема операторов (S3, Spark, DBT, Kubernetes). Проще развернуть, если уже есть Airflow в компании.

Prefect / Metaflow — меньше boilerplate. Prefect 2.x с декораторами @flow и @task — быстрый старт для небольших команд.

Типичная архитектура обучающего пайплайна на Kubeflow:

1. Data ingestion component — забирает данные из S3/БД, валидирует схему через Great Expectations
2. Preprocessing component — трансформации, normalization, train/val/test split
3. Training component — обучение на GPU, логирование в MLflow
4. Evaluation component — вычисление метрик, сравнение с baseline в Model Registry
5. Conditional deployment — деплой только если новая модель лучше текущей на >2% F1

Каждый component — отдельный Docker-образ. Пайплайн версионируется в git. Запуск по расписанию (ретрейнинг раз в неделю на новых данных) или вручную.

Model Registry и управление жизненным циклом

Model Registry — не просто хранилище чекпоинтов. Это централизованная система, которая знает:

• Какая модель сейчас в продакшене (и с какими метриками)
• История всех версий с параметрами обучения
• Метаданные: датасет, git commit, результаты валидации
• Lifecycle stage: None → Staging → Production → Archived

MLflow Model Registry — стандарт. Для enterprise — Vertex AI Model Registry (GCP), SageMaker Model Registry (AWS), Azure ML Model Registry.

Продвижение модели через стейджи: автоматически переводим модель в Staging после успешного прохождения eval, затем ручное или автоматическое (при A/B тесте) продвижение в Production. Rollback — переключение на предыдущую Production-версию за секунды.

Serving: от FastAPI до Triton Inference Server

Простой случай. FastAPI + PyTorch/ONNX на одном сервере — 80% production ML deployments именно так. Достаточно для большинства задач с нагрузкой до 100 req/s.

from fastapi import FastAPI
import onnxruntime as ort

app = FastAPI()
session = ort.InferenceSession("model.onnx", providers=["CUDAExecutionProvider"])

@app.post("/predict")
async def predict(request: PredictRequest):
    inputs = preprocess(request.text)
    outputs = session.run(None, {"input_ids": inputs})
    return {"label": postprocess(outputs)}

Triton Inference Server — production-стандарт для высоких нагрузок (500+ req/s). Dynamic batching, concurrent model execution, model ensemble. Поддерживает TensorRT, ONNX, PyTorch TorchScript, TensorFlow SavedModel.

KServe — Kubernetes-native ML serving с autoscaling, canary deployments, A/B testing из коробки. Scale-to-zero для неактивных моделей — экономия на инфраструктуре до 40% (более 1.2 млн рублей в год для проекта с 10 моделями).

Мониторинг: data drift, model drift, инфраструктурные метрики

Мониторинг — то, что обычно делают в последнюю очередь и о чём жалеют в первую. Три уровня.

Инфраструктурный мониторинг. Latency (P50/P95/P99), throughput (req/s), error rate (4xx, 5xx), GPU/CPU utilization. Prometheus + Grafana — стандарт. Алерт при P99 latency > threshold или error rate > 1%.

Data drift мониторинг. Распределение входных данных меняется со временем. Детектируем через PSI (Population Stability Index) для числовых признаков: PSI > 0.2 — сильный дрейф. Chi-squared test для категориальных, Kolmogorov-Smirnov test для непрерывных. Evidently AI — open source библиотека с готовыми дрейф-тестами.

Model drift мониторинг. Если есть ground truth с задержкой (например, через неделю знаем конверсию) — мониторим реальные метрики. Если нет — surrogate метрики: распределение prediction scores, доля confident predictions.

Alerting. Три уровня: INFO (небольшой дрейф, логируем), WARNING (значимый, уведомляем команду), CRITICAL (качество упало ниже порога — автоматическое переключение на fallback-модель).

Почему важен мониторинг дрейфа данных? Без него вы узнаёте о деградации модели только по жалобам пользователей или звенящему SLA. Алерт о дрейфе позволяет переобучить модель заранее, до того как ошибки начнут приносить убытки. В одном из наших проектов мониторинг PSI выявил дрейф через 2 дня после изменения источника данных — это спасло кампанию с бюджетами на 2 млн рублей.

Feature Store

Feature Store решает проблему training-serving skew. Если preprocessing во время обучения и инференса реализован в двух разных местах — расхождение неизбежно.

Когда нужен Feature Store?

• Несколько моделей используют одни и те же признаки
• Признаки вычисляются из потоковых данных (real-time)
• Большая команда с разными людьми на feature engineering и model training

Feast — open source Feature Store. Офлайн store (S3 + Parquet) для обучения, онлайн store (Redis, DynamoDB) для low-latency инференса. Feature definitions как код, materialization job синхронизирует офлайн → онлайн.

Tecton (коммерческий), Vertex AI Feature Store (GCP), SageMaker Feature Store (AWS) — managed варианты с меньшим ops overhead.

CI/CD для ML

ML CI/CD — обычный CI/CD плюс специфичные ML-шаги.

ML-специфичные checks в CI:

• Проверка воспроизводимости: запустить обучение с фиксированным seed, результат должен совпадать
• Data validation: Great Expectations или Pandera на schema/distribution checks
• Model performance check: автоматический eval на holdout, блокировать merge если деградация > порога
• Latency regression test: inference должен укладываться в SLA

GitOps для деплоя. Merge в main → CI запускает обучение → eval → если проходит → автоматический деплой в Staging → smoke tests → ручное продвижение в Production или автоматическое при успешном canary.

Инструменты: GitHub Actions / GitLab CI для CI, ArgoCD для GitOps-деплоя на Kubernetes.

Что входит в разработку MLOps-платформы

Мы предоставляем полный цикл работ, документацию и обучение команды.

Итоговый срок от аудита до полноценной MLOps-платформы: 3–5 месяцев. Также возможен поэтапный запуск: базовый уровень (трекинг + serving) за 4–6 недель.

Стоимость рассчитывается индивидуально под объём данных, количество моделей и требования к инфраструктуре. Закажите аудит MLOps-инфраструктуры — получите roadmap за 1–2 недели. Свяжитесь с нами для оценки вашего проекта — мы пришлём предварительный расчёт за 2 рабочих дня.

Обратите внимание: гарантия на архитектурные решения — 12 месяцев. Предоставляем сертификаты интеграции с основными облачными провайдерами (AWS, GCP, Azure). За время работы мы не потеряли ни одного клиента после первого внедрения — опыт 50+ успешных MLOps-проектов говорит сам за себя. Получите консультацию по построению MLOps платформы уже сегодня.