Проектируем командный iGaming Spy на Tyver и AI-агентах

Коллеги, приветствую, на связи Жёлтый! Сегодня покажу, как спроектировать командный iGaming Spy поверх Tyver и AI-агентов. Готового SaaS с одной волшебной кнопкой здесь пока нет. Зато можно собрать достаточно предсказуемый бизнес-процесс и сразу разделить работу между скриптами и AI.

Источником данных будет Tyver. Для работы с его Public API я собрал Tyver CLI. На тест возьмём Gambling и три гео: Германию, Италию и Польшу.

Сам поиск знаком любому, кто открывал спай. Выбираем страну, дату, вертикаль, формат, сортировку и смотрим карточки.

Фильтры Gambling в живом интерфейсе Tyver

Живая выдача Tyver: Германия, Gambling, объявления за 27 июля и сортировка по показам.

Руками повторять один набор действий каждое утро быстро надоедает. Но у команды есть проблема посерьёзнее рутины. Даже если написать отличный мануал, искать всё равно будут люди.

Сегодня баер выспался и внимательно просмотрел выдачу. Завтра он устал, послезавтра пришёл с похмелья, а ещё через день не успел покурить кальян и вообще не настроен всматриваться в сотню похожих обложек. Что-то пропустил, где-то забыл фильтр, в спорной карточке не открыл ролик. Человеческий фактор никто не отменял.

Фильтры API, скачивание файлов, подсчёт хешей и запись во внутреннюю базу спокойно выполняет скрипт. Агент подключается к смысловой проверке: действительно ли перед нами нужная игра, подходит ли креатив под iGaming и не видели ли баеры такой же заход позавчера.

Что собираем

Каждое утро по таймеру запускается контроллер. Он читает задания и ограничения конкретного прогона:

date: 2026-07-27

jobs:
  - geo: DE
    offer: CHICKEN_ROAD
    mode: subcategory
    top: 10
    refill:
      mode: validator_rejects
      min_impressions: 1000
      max_checked: 60

  - geo: IT
    offer: CHICKEN_ROAD
    mode: subcategory
    top: 10
    refill:
      mode: off

  - geo: PL
    query: "бонус новым игрокам"
    mode: text
    top: 10
    refill:
      mode: manual

top задаёт нужное количество креативов по каждому заданию. В refill.mode выбираем режим добора: выключен, запускается вручную или включается после отказов валидатора. min_impressions останавливает добор, когда показы опускаются ниже установленного порога. max_checked ограничивает общее число просмотренных карточек.

Дата задания превращается в точный диапазон API: creation_date_gte=2026-07-27 и creation_date_lte=2026-07-27. Для другого сценария можно искать по последней активности, но в нашем ежедневном мониторинге нужна именно дата появления объявления.

Дальше работает такой конвейер:

Обычный worker вызывает Tyver CLI и получает до 60 карточек по каждому заданию.
Tyver сортирует объявления по убыванию показов. Worker берёт первые десять.
Код отбрасывает точные дубли и ищет похожие файлы во внутренней базе. Для уже знакомых креативов подтягиваются прошлые решения команды.
Агент-валидатор ставит accept, review или reject и объясняет решение.
Принятые карточки попадают в галерею. Спорные уходят на проверку человеку.
Если для задания включён добор после отказов валидатора, контроллер берёт следующие карточки из уже загруженной выдачи. В обычном запуске этот режим выключен.

Внутренняя база начинает копиться с первого прогона. В ней сохраняются карточки, файлы и решения баеров. Точный дубль увеличивает счётчик перезаливов у существующей карточки. Для похожего креатива система показывает прошлую разметку, если команда уже успела её добавить.

Worker, валидатор и цикл добора

Общая схема работы командного спая: от задания по гео и офферу до галереи, обратной связи и новых версий правил.

В нашем тестовом прогоне по трём гео первая выборка дала 30 оригинальных изображений и роликов плюс 9 обложек видео. По десять карточек на каждое задание. В рабочей системе количество на входе и количество в галерее почти никогда не совпадут. Точные дубли схлопнутся, валидатор отсеет часть карточек, спорные результаты уйдут в ручной review.

Командная галерея локального спая

Так может выглядеть рабочий интерфейс. В текущем макете цифры иллюстрируют логику конвейера; в продакшене они заполняются из проверенного JSON.

API, тариф и квота

Public API Tyver недоступен на Free-плане. Также обязательно следите за квотой. До настройки cron проверьте учётку:

tyver me

Команда покажет ваш тариф и оставшийся лимит. Затем сделайте один тестовый поиск и снова вызовите tyver me, чтобы увидеть фактическое списание на своём плане:

tyver creatives search `
  --country DE `
  --creation-date-gte 2026-07-27 `
  --creation-date-lte 2026-07-27 `
  --vertical GAMBLING `
  --vertical-subcategory CHICKEN_ROAD `
  --media-type IMAGE `
  --media-type VIDEO `
  --sort impressions_from

CLI и скилл tyver-search лежат в репозитории Tyver CLI. Там же описаны установка и настройка API-ключа.

Что делает код, а что агент

Одинаковую поисковую механику по всем гео выполняет обычный worker:

подставит дату, гео, вертикаль и подкатегорию;
получит отсортированную по показам выдачу;
скачает оригинальные файлы и обложки роликов;
посчитает SHA-256 и PDQ;
запишет найденное во внутреннюю базу;
подготовит SearchBatch JSON для валидатора.

Вот сокращённый пример контракта между worker и валидатором. В нём сохраняются исходные поля Tyver, фильтры задания и пути к скачанным файлам:

{
  "batch_id": "2026-07-27-de-chicken-road",
  "date": "2026-07-27",
  "geo": "DE",
  "offer": "CHICKEN_ROAD",
  "top": 10,
  "filters": {
    "creation_date_gte": "2026-07-27",
    "creation_date_lte": "2026-07-27",
    "vertical": "GAMBLING",
    "vertical_subcategories": ["CHICKEN_ROAD"],
    "media_types": ["IMAGE", "VIDEO"],
    "sort": "impressions_from"
  },
  "candidates": [
    {
      "provider_id": "example-id",
      "impressions": 12500,
      "countries": ["DE", "AT"],
      "media_type": "VIDEO",
      "local_files": ["staging/DE/2026-07-27/example.mp4"],
      "previous_matches": []
    }
  ]
}

По этому контракту валидатор получает показ объявления, фактические гео, тип креатива и скачанные файлы. Этого хватает для дальнейшей проверки.

Агент-валидатор получает карточку, скачанные файлы и несколько ближайших примеров из командной базы. Код заранее находит точные дубли по SHA-256 и визуально похожие изображения по PDQ. При необходимости можно искать другие совпадения, например повторяющийся хук. Агенту достаточно трёх-пяти близких примеров вместе с решениями баеров.

Валидатор отвечает на понятные вопросы:

это действительно iGaming;
соответствует ли креатив игре или офферу;
подходит ли язык и гео;
видели ли мы такой же файл или почти такой же подход;
есть ли в командных правилах причина его не показывать;
достаточно ли доказательств для accept.

Результат тоже передаётся по понятному контракту:

{
  "batch_id": "2026-07-27-de-chicken-road",
  "decisions": [
    {
      "provider_id": "example-id",
      "verdict": "reject",
      "offer_match": true,
      "geo_fit": "local",
      "novelty": "near_duplicate",
      "reject_reason": "team_rejected_similar_hook",
      "evidence": [
        "same_gameplay",
        "same_opening_hook",
        "three_negative_team_labels"
      ]
    }
  ],
  "summary": {
    "accepted": 2,
    "review": 1,
    "rejected": 7,
    "target_available": 10,
    "refill_suggested": true
  }
}

Для соблюдения контракта удобно использовать Structured Outputs. У поддерживаемых моделей OpenAI этот режим фиксирует названия полей, типы и допустимые значения. При работе с другими провайдерами JSON проверяется локально.

Как работает добор

Базовый режим предельно простой: worker сортирует выдачу, берёт top-10 для каждого задания и заканчивает поиск. Иногда три карточки оказываются точными дублями, пять валидатор отсеивает, одну принимает, ещё одну отправляет человеку. При таких результатах пригодится добор новых креативов из Tyver.

Контроллер берёт следующие карточки из уже загруженной пачки и отправляет их валидатору по тем же правилам. Добор останавливается, когда в Tyver закончились подходящие объявления, показы упали ниже min_impressions, проверено max_checked кандидатов или исчерпана квота API.

Для части заданий добор лучше оставить ручной операцией. Баер видит результат и сам нажимает «Добрать», если текущей подборки не хватает.

Что показала живая выдача

Tyver хорошо сужает поиск, но автоматическая классификация иногда промахивается. В немецкую Gambling-выдачу, например, попал магазин очков. Похоже, классификатор зацепился за aviator style в описании модели, после чего карточка получила тег Aviator.

Валидатор видит обычный товарный креатив и ставит reject. Такой false positive стоит добавить в контрольный набор и в историю отрицательных примеров.

Нашлись и менее смешные совпадения. Один ролик продавал набор для создания bass music, видимо, попал по аналогии со слотом Big Bass. Второй рекламировал приложение для превращения фотографии в видео. Оба лежали в Gambling.

Музыкальный production pack в выдаче Gambling — Production pack для bass music.

Приложение Photo to Video в выдаче Gambling — Приложение Photo to Video.

У следующего ролика нет рекламного текста, Tyver также не определил конкретную игру. На обложке виден слот, CTA предлагает играть.

Для общего поиска по Gambling карточку можно оставить. При поиске конкретной игры валидатор ставит review: по обложке видно вертикаль, название слота остаётся неизвестным.

Дубли и память команды

Точные повторы схлопываются по хешу. В польской выдаче нашлись две рекламные записи с одним изображением Chicken Road: SHA-256 совпал, поэтому в галерее остаётся одна карточка. В её статистике сохраняются обе рекламные записи.

Число таких перезаливов стоит показывать прямо в галерее. Регулярное появление одного креатива у разных рекламодателей служит дополнительным сигналом, что подход живой и его продолжают использовать. Сам по себе этот счётчик прибыльность не доказывает.

После пересжатия, кропа, рамки или водяного знака SHA-256 уже не поможет. Для таких случаев подходит PDQ Hash. Близость определяется расстоянием Хэмминга; порог 31 в документации Meta предлагается как стартовый, затем его нужно настроить на своей выборке. Для видео можно считать TMK+PDQF.

Одной похожести файлов мало. Поэтому рядом с техническими совпадениями хранится ручная разметка: гео, оффер, хук, причина отказа, решение баера и результат пролива.

Метка «говно» приятна своей лаконичностью, но системе от неё ни холодно ни жарко. Нужна хотя бы причина: уже видели, плохая локализация, не тот оффер, заезженный хук, слабый первый кадр, запрещённый элемент или подход уже тестировали и он не зашёл.

Агент, который разбирает обратную связь

Вот здесь появляется полезная задача для второго агента. Раз в ночь он собирает новую разметку баеров, группирует повторяющиеся причины и готовит изменения правил:

добавить отрицательный пример для валидатора;
временно приглушить целый кластер похожих креативов;
дополнить локальный запрос или минус-слова;
повысить приоритет подхода, который несколько раз дошёл до теста;
отправить спорную группу владельцу процесса.

На выходе получается небольшой rules_diff: что меняется, на каких примерах основано и сколько карточек затронет. Правило привязывается к нужному контексту, чтобы неудачный подход из Польши и одного оффера случайно не заблокировал похожие креативы в Германии и других офферах. Владелец процесса принимает или отклоняет изменение.

Одна эмоциональная метка баера не должна навечно банить целый подход. Для сильного правила нужны повторяющиеся примеры, понятная причина и проверка на контрольной выборке. Результат пролива тоже надо читать осторожно: на него влияют аккаунт, ставка, плейсмент, ленд и ещё пачка переменных. Агент предлагает закономерность, человек решает, достаточно ли доказательств.

Галерея, метрики и владелец процесса

Баеры работают с отобранными карточками через общую галерею. В ней видны креатив, гео, оффер, показы, похожие варианты, решение валидатора и история команды. Отсюда карточку можно взять в работу, отправить креативщику, отметить как мусор или связать с результатом теста.

У системы должен быть владелец: медиа-исследователь, баер с интересом к автоматизации или технический специалист. Он следит за промптами, локальными формулировками, минус-словами, порогами похожести и контрольной выборкой.

Считать стоит долю годных карточек среди accept, долю ручного review, пропущенные годные креативы в случайной выборке reject, стоимость тысячи одобренных карточек и количество идей, которые дошли до теста. После изменения модели или правил эти цифры сравниваются с предыдущей версией. Рекомендации OpenAI по eval-наборам здесь вполне применимы: фиксируем цель, собираем примеры, сравниваем версии и добавляем ошибки из продакшена.

После первых 50-100 размеченных карточек обычно уже видны повторяющиеся типы мусора. Порог зависит от разнообразия выборки: двадцать сложных пограничных случаев могут дать больше пользы, чем сотня одинаковых картинок Chicken Road.

Во сколько это может обойтись

В базовом примере три задания дают 30 карточек в день, или около 900 в месяц. Поиск, сортировка, дубли и скачивание выполняются обычным кодом. Из моделей здесь нужны только валидатор и ночной агент, который разбирает свежую обратную связь команды. При таком потоке расходы на модели обычно укладываются в несколько десятков долларов в месяц или меньше. Сервер с cron, галереей и резервными копиями можно оценить ещё в $10-30. Тариф Tyver считается отдельно.

У большой команды может набраться много гео и офферов: до 3000 сырых карточек в день, или 90 тысяч в месяц. Отправлять весь поток сильной модели незачем. Код сначала убирает дубли, FFmpeg извлекает несколько опорных кадров, дешёвая модель проверяет оставшуюся массу. Сильная получает кандидатов на публикацию, спорные карточки и контрольную часть отказов.

Грубая месячная вилка:

Нагрузка	Модели	Инфраструктура	Итого в месяц
3 задания × top-10 ежедневно	$5-40	$10-30	около $15-70
3000 сырых карточек в день, каскад моделей	$50-300	$30-80	около $80-380
Сильная модель почти на всём большом потоке	$500-1500+	$50-100	от $550

Цены меняются, поэтому перед запуском сверяйтесь с тарифами OpenAI и Z.AI.

Что получает команда

Tyver даёт готовый источник данных. Поверх него команда выстраивает собственный рабочий процесс. Обычный код отвечает за API, скачивание, дубли и выкладку top-10 по каждому заданию. Валидатор смотрит на смысл и прошлые решения команды. Контроллер добирает карточки после отказов валидатора, если этот режим включён. Второй агент разбирает обратную связь и предлагает изменения правил для следующих прогонов.

Баеры получают инструмент для быстрого анализа текущего среза рынка и регулярную порцию идей для новых креативов. Правила учитывают нужные гео, офферы и опыт конкретной команды. Поиск, проверка и передача идеи в работу занимают меньше времени, а путь от свежего креатива до нового теста становится короче.

Если у вас есть вопросы, замечания или предложения по разработке похожих систем, пишите в комментариях или в YW Feedback Bot. Если не буду завален работой, постараюсь ответить и поделиться своим видением.

А на связи был Жёлтый Веб. Лейте в плюс, господа!