Одна из самых неприятных проблем автоматизированного контента появляется ещё до генерации текста. Если система плохо выбирает тему, сильная модель просто напишет хороший материал о том, что никому не нужно сейчас. Поэтому при разработке MediaMashin мы довольно быстро поняли: качество начинается не с EDITOR, а с RADAR.
Проблема: поиск выдаёт много материалов, но не все они новости
Для e-commerce постоянно публикуются гайды, обзоры, инструкции, сравнения и статьи в духе «как продавать на маркетплейсе». Они могут быть полезными, но это не означает, что произошло новое событие. Если воспринимать всё это как инфоповоды, медиасистема будет бесконечно пересказывать вечнозелёный контент.
Нам нужна была другая логика: найти свежий сигнал, проверить его, понять, относится ли он к нашим аудиториям, и только после этого разрешить Research и генерацию статьи.
Почему одного источника оказалось мало
В качестве агрегированного discovery-входа мы используем GDELT DOC. Он помогает быстро увидеть широкий поток материалов. Но агрегатор не является источником истины. Поэтому Yandex Search используется как fallback и слой проверки, а сам discovery-результат не получает право сразу стать статьёй.
Событие из discovery сначала попадает в промежуточный статус и требует подтверждения. Это сознательное ограничение: скорость поиска не должна автоматически превращаться в доверие к найденному материалу.
NEWS_EVENT против EVERGREEN
Мы ввели отдельную классификацию для реального события и вечнозелёной темы. How-to, guide, strategy, FAQ, review и похожие форматы сами по себе не считаются новостью. Наличие слов «рост», «изменение» или «маркетплейс» тоже недостаточно.
Система ищет признаки конкретного события: изменение условий, запуск, опубликованную метрику, решение регулятора, новый срок, исследование, ограничение или другой факт, который можно привязать ко времени и источнику.
Это кажется простым правилом, но именно оно резко меняет качество входного потока. EDITOR перестаёт получать задачи, которые выглядят свежими только из-за заголовка.
Проверка темы до генерации
После классификации мы проверяем тематическую релевантность. В e-commerce легко поймать шум: документы о тарифах могут относиться к коммунальным услугам, слово «магазин» — к офлайн-торговле, а упоминание маркетплейса — быть частью общего обзора без нового факта.
Поэтому relevance gate смотрит не только на отдельное слово, а на контекст темы и тип источника. Официальный регуляторный источник, исследовательский материал и discovery-агрегатор проходят разные пути проверки.
Почему дедупликация сложнее совпадения заголовков
Второй тип шума — повтор одного и того же события разными словами. Один источник может написать про рост проектов собственных интернет-магазинов, другой — про то же изменение с другой формулировкой. Если сравнивать только заголовки, система создаст несколько статей об одном факте.
Поэтому novelty check учитывает не только текстовое сходство, но и якоря события: общий источник или сущность, метрику, тему, диапазоны и другие устойчивые признаки. Если событие уже покрыто опубликованным материалом, новый кандидат может быть остановлен как duplicate ещё до EDITOR.
Research как граница доверия
Даже релевантное NEWS_EVENT не означает, что фактов достаточно. Discovery-источник может дать только заголовок или короткий фрагмент. Research пытается получить первичный документ и подтверждающие материалы. В зависимости от качества источника меняются требования к corroboration.
Так мы отделяем две задачи: RADAR отвечает «похоже ли это на значимое новое событие», Research — «достаточно ли у нас доказательств, чтобы писать статью».
Какой результат мы получили
Главный результат не в количестве найденных новостей. Наоборот, хорошая работа RADAR часто проявляется в том, что он ничего не отправляет дальше. Шумные, нерелевантные и вечнозелёные материалы останавливаются раньше и не потребляют редакционный ресурс.
Повтор уже опубликованного инфоповода может быть остановлен как duplicate. Материал с недостаточной доказательной базой не должен автоматически становиться статьёй. А реальный свежий сигнал получает понятный путь к Research и EDITOR.
Что бы мы сделали иначе
Мы бы с самого начала относились к discovery как к сенсору, а не как к источнику фактов. Это важное различие. Чем шире поиск, тем больше будет шума; пытаться победить его только сложными запросами недостаточно.
Надёжнее строить каскад: широкий поиск → классификация → релевантность → проверка → novelty → Research. Такая архитектура переносится и на другие цифровые системы продаж: сначала собираем сигналы, затем уменьшаем неопределённость и только после этого запускаем дорогое или внешнее действие.
Почему это часть цифровой системы продаж
Контент для нас не самоцель. MediaMashin нужна, чтобы приводить целевой трафик и объяснять ценность собственных каналов продаж. Поэтому правильный выбор темы влияет на всю дальнейшую воронку: от статьи и поискового следа до перехода на интерактивное демо и заявки.
Именно так мы понимаем архитектуру цифровых систем продаж: не набор AI-инструментов, а связанный процесс, где каждый этап имеет свою функцию и ограничение.
Как мы это внедрили
Внедрение мы строили не вокруг одного инструмента, а вокруг последовательного процесса. Сначала фиксировали бизнес-задачу и границы автоматизации, затем подключали нужные компоненты и проверяли каждый переход отдельно. В этой работе использовали несколько специализированных инструментов из evidence pack. Для нас это важно: архитектура цифровой системы продаж должна объяснять не только какие сервисы используются, но и зачем каждый из них находится в цепочке.
GDELT DOC используется как основной агрегированный discovery-вход RADAR; Yandex Search — как fallback и слой проверки. Это было не декларацией, а условием реализации: мы проверяли этот участок отдельно и только после этого считали его частью рабочего контура.
Discovery-событие не идёт сразу в статью: оно сначала получает статус DISCOVERED_UNVERIFIED и проходит Research. Это было не декларацией, а условием реализации: мы проверяли этот участок отдельно и только после этого считали его частью рабочего контура.
Классификатор разделяет NEWS_EVENT и EVERGREEN; how-to, guide, strategy, FAQ и review не считаются новостью сами по себе. Это было не декларацией, а условием реализации: мы проверяли этот участок отдельно и только после этого считали его частью рабочего контура.
Перед генерацией выполняется novelty check против уже опубликованных материалов, включая совпадение источника, метрики и темы. Это было не декларацией, а условием реализации: мы проверяли этот участок отдельно и только после этого считали его частью рабочего контура.
RADAR штатно запускается каждые 30 минут. Это было не декларацией, а условием реализации: мы проверяли этот участок отдельно и только после этого считали его частью рабочего контура.
Какой результат получили
Проверенный результат: Шумные или вечнозелёные материалы могут быть остановлены до EDITOR. Мы считаем результатом именно наблюдаемое поведение системы, а не обещание будущего эффекта для любого бизнеса.
Проверенный результат: Повтор уже опубликованного инфоповода может быть отсеян как duplicate. Мы считаем результатом именно наблюдаемое поведение системы, а не обещание будущего эффекта для любого бизнеса.
Границы решения
Ограничение, которое мы сохраняем в публичном выводе: Не обещать идеальную полноту новостей. Это помогает не превращать инженерный кейс в рекламное обещание.
Ограничение, которое мы сохраняем в публичном выводе: Не утверждать, что один агрегатор является источником истины. Это помогает не превращать инженерный кейс в рекламное обещание.
Практический вывод для бизнеса
Главный вывод из этой реализации — цифровая система продаж ценна не количеством подключённых сервисов, а тем, насколько предсказуемо проходит путь от сигнала и действия до проверяемого результата. Мы поэтому разделяем поиск, проверку, генерацию, человеческое решение, публикацию и измерение. Такой подход делает автоматизацию управляемой и позволяет менять отдельный компонент без необходимости заново изобретать весь процесс.