«Скорость выхода на рынок напрямую определяет выручку»: Condé Nast сократила поиск по 140 000 видео с 250 минут до двух

Что не работало

Проблема оказалась структурной, а не косметической: существующие поисковые инструменты не умеют заглядывать внутрь видео, поэтому редакции искали нужные кадры по названиям и описаниям и опирались на знание конкретных людей — когда такой человек был недоступен, поиск вставал. Часть архива при этом просто не находили: ни одно слово в заголовке или описании не связывало материал с теми запросами, которые редакторы реально вводили. Издатель описывает ставку прямо: в медиа скорость выхода на рынок напрямую определяет захват выручки, и ручной перебор роликов давал измеримое трение сразу в нескольких брендах — Vogue, GQ, Vanity Fair и Wired.

Ключевой поиск здесь бессилен по своей природе. Редактор не ищет файл с именем yoga_tutorial_march_2024.mp4 — он ищет «материал для начинающих по йоге со спокойным фоном» или «кадры за кулисами недели моды», то есть формулирует намерение, а не строку для совпадения. Метаданные, написанные руками, такого уровня понимания дать не могут, поэтому решение с самого начала строилось вокруг векторных эмбеддингов, которые захватывают смысл сразу в нескольких модальностях.

Почему два контура, а не один

Вторым ограничением стал размер архива: более 140 000 видео означали, что дорогую и тяжёлую по вычислениям генерацию эмбеддингов нужно отделить от быстрой выдачи результатов поиска. Монолитная архитектура заставляла бы выбирать между пропускной способностью загрузки и отзывчивостью запросов, а разделение позволяло каждому контуру масштабироваться, падать и развиваться независимо — и это оказалось критично во время первичной заливки архива.

Ядро решения получилось таким: мультимодальные векторные эмбеддинги от TwelveLabs Marengo на Amazon Bedrock, индекс в Amazon OpenSearch Service и отдельный поисковый слой, который превращает запрос на естественном языке в векторный поиск и возвращает точные метки времени. Marengo выбрали за способность совместно кодировать визуальный, звуковой и текстовый сигналы, а заодно она отвечает за все пять возможностей решения.

Издатель объясняет, почему модель подключали именно через Bedrock: сервис даёт множество foundation-моделей через единый API и добавляет управляющие контроли AWS — AWS Identity and Access Management (IAM) для доступа, Amazon Virtual Private Cloud (Amazon VPC) для сетевой изоляции и AWS CloudTrail для аудита. Такое сочетание позволило взять специализированную модель эмбеддингов, не строя и не эксплуатируя собственную инфраструктуру выдачи моделей. Для векторного индекса Amazon OpenSearch Service даёт управляемый k-Nearest Neighbor (k-NN) поиск с репликацией между зонами доступности и фильтрацией по метаданным для гибридных запросов — это и позволило держать быстрый поиск по более чем 140 000 видео без управления собственным поисковым кластером.

Полезная деталь для тех, кто повторяет схему: у Marengo Embed в Bedrock асинхронный вызов — это единственная поддерживаемая операция для обеих версий модели, StartAsyncInvoke, тогда как видео-модель Pegasus 1.2 работает через InvokeModel. Синхронный вызов эмбеддингов на таком объёме был бы бутылочным горлышком, поэтому асинхронность здесь не оптимизация, а условие работоспособности; в актуальной версии Marengo Embed размерность вектора снижена с 1024 до 512, что уменьшает стоимость хранения индекса.

Как устроены контур загрузки и контур запроса

Контур загрузки и индексации работает так: видео попадает в бакет Amazon Simple Storage Service (Amazon S3) с исходниками, новое появление файла поднимает событие, сервис загрузки проверяет видео и достаёт метаданные (формат, длительность, разрешение), режет его на сегменты, а генерирует эмбеддинги Marengo на Amazon Bedrock асинхронным вызовом. Сегментация идёт на Amazon Elastic Container Service (Amazon ECS) с AWS Fargate, Auto Scaling group растягивает её по нескольким зонам доступности, чтобы обрабатывать фрагменты параллельно, а готовые векторы пишутся в S3 для надёжности и в кластер OpenSearch Service для поиска. Весь конвейер событийный и оркестрирован от начала до конца: это даёт повторные попытки на каждом шаге, параллельную обработку и полную трассировку для отладки — именно на это команда опиралась во время первичной заливки 140 000 видео.

Контур запроса начинается с интернет-шлюза и внешнего Application Load Balancer (ALB), который раздаёт запросы фронтенд-сервису на Amazon ECS с AWS Fargate. Фронтенд обращается к поисковому сервису через внутренний ALB, тот превращает запрос пользователя в векторный эмбеддинг и выполняет k-NN-поиск по индексу OpenSearch Service, после чего обогащает результаты метаданными видео — заголовками, миниатюрами и ссылками — из Amazon DocumentDB (совместим с MongoDB), и возвращает пользователю клипы с точными метками времени. Оба сервиса масштабируются Auto Scaling группами по нескольким зонам доступности.

Отказоустойчивость заложена по всей схеме: OpenSearch Service реплицируется синхронно на три зоны доступности (две активные и одна в резерве), Amazon DocumentDB держит основную ноду и резервную реплику в двух зонах, вычислительные уровни распределены по зонам с маршрутизацией ALB в обход отказов. Вычисления и данные живут в приватных подсетях, публично доступен только внешний ALB, а исходящий трафик идёт через NAT-шлюзы.

Что получили пользователи и бизнес

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

Цифры Condé Nast измерила сама на бенчмарк-воркшопе в мае 2026 года: время поиска сократилось на 99,2 % — с 250 минут примерно до двух минут на задачу, ручной просмотр видео упал более чем на 90 %, а годовая операционная экономия оценивается примерно в 800 000 долларов за счёт снятия повторяющегося ручного поиска по всей организации. Отдельно отмечается, что ранее недоиспользованные материалы стали находиться через смысловые связи, которых поиск по метаданным не видит, а быстрый поиск ускоряет ответ на запросы рекламодателей и коммерческие возможности. Комментарий со стороны заказчика даёт Billy Keenly, Global Senior Director, Creative Optimization в Condé Nast: «Команда AWS вместе с коллегами из GenAI и TwelveLabs помогла нам ясно и сжато объяснить бизнес-кейс. Я настроен оптимистично и рассчитываю продвинуться дальше в наших задачах по рабочим процессам».

Что забрали из этого опыта

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

Длину сегмента видео подбирали экспериментально: короткие теряли контекст, длинные размывали смысловой сигнал, и только итеративное сравнение на реальных редакционных запросах вывело к балансу точности и полноты. Асинхронная генерация эмбеддингов оказалась безальтернативной — синхронные вызовы создали бы узкое место на 140 000 видео, поэтому в Bedrock их запускали асинхронно, а оркестрацию заливки вёл AWS Step Functions; этот же шаблон остался для текущей загрузки. Наконец, мультизонную отказоустойчивость строили с первого дня: для сервиса, которым редакции пользуются весь рабочий день, даже короткий простой означает потерю продуктивности, и дешевле заложить это сразу. AWS отдельно отмечает, что схема применима не только к медиа — она годится бродкастерам, стриминговым сервисам, спортивным лигам и корпоративным медиакомандам, а разделённые контуры позволяют менять модель эмбеддингов и типы контента по мере развития мультимодального ИИ.