Что такое Marengo Embed 3.0 и зачем он в Amazon Bedrock Knowledge Bases
TwelveLabs Marengo Embed 3.0 - общедоступная модель эмбеддингов в Amazon Bedrock Knowledge Bases, полностью управляемом RAG-сервисе. Она кодирует видео, аудио, изображения и текст в одно 512-мерное векторное пространство.
Что это даёт на практике: запрос «покажи пенальти из этого матча» возвращает не двухчасовую запись, а конкретный фрагмент с таймкодами. Собирать цепочку из транскрибации, извлечения кадров, синхронизации модальностей и собственной векторной базы не нужно: чтение файлов, чанкинг, эмбеддинги, индекс и поиск берёт на себя сервис.
Запуск укладывается в четыре шага: файлы в S3, Managed Knowledge Base с Marengo 3.0, настройка сегментации аудио и видео, синхронизация данных. Дальше поиск проверяют тестовыми запросами и встраивают в приложение через Retrieve API. Регионы на момент публикации: us-east-1 и eu-west-1. Оплата состоит из двух частей - хранение и извлечение.
Как устроен managed RAG в целом, какие у него режимы поиска и как выглядит production-архитектура, разобрано в руководстве по Amazon Bedrock Managed Knowledge Base. Здесь фокус на медиа: видео и изображениях.
Единое 512-мерное пространство: почему это важно
Эмбеддинг - это вектор чисел, в котором закодирован смысл фрагмента. Поиск сравнивает вектор запроса с векторами чанков и ранжирует результат по близости.
Ключевая деталь Marengo 3.0: текст запроса, изображение, звуковая дорожка и видеоряд лежат в одном пространстве размерности 512. Запрос можно формулировать словами, без тегов и фильтров. Отдельная задача слияния результатов из текстового, визуального и аудиоиндексов тоже исчезает.
Классический пайплайн устроен иначе. Речь переводится в текст через ASR и ищется по транскрипту. Кадры превращаются в отдельные векторы и ищутся по картинке. Звук индексируется третьей моделью. Каждый канал отвечает за свою модальность, а запрос вроде «эпизод, где судья показывает красную карточку, а комментатор повышает голос» требует ручной склейки оценок из нескольких источников. В едином пространстве такой запрос сопоставляется с чанком напрямую.
Чем managed-подход отличается от самосборного пайплайна
| Этап | Свой пайплайн | Managed KB + Marengo 3.0 |
|---|---|---|
| Речь | ASR, хранение транскриптов, привязка к таймкодам | эмбеддинг аудио внутри модели |
| Видеоряд | извлечение keyframes, отдельная модель для изображений | эмбеддинг видео без ручного отбора кадров |
| Сшивка модальностей | слияние оценок из двух-трёх индексов | одно векторное пространство |
| Хранилище векторов | OpenSearch, pgvector или faiss плюс обслуживание | индекс внутри сервиса |
| Обновление данных | свой реиндексатор | синхронизация источника S3 |
| Поисковый API | собственный endpoint | Retrieve API |
Плата за простоту - потеря управления. Внутреннюю реализацию не переписать: модель эмбеддингов выбирается из каталога сервиса, логика обработки задаётся параметрами, которые Knowledge Bases отдаёт наружу. Собственную схему индекса или нестандартную модель сюда не подключить.
Пошаговая настройка: от S3 до готового мультимодального поиска
Последовательность одинаковая для консоли и API: подготовить данные, создать базу знаний, задать сегментацию, синхронизировать. Регион выбирайте сразу: Marengo 3.0 доступна в us-east-1 и eu-west-1, и база знаний в другом регионе модель не подхватит.
Шаг 1. Загрузка видео и изображений в S3
Бакет создавайте в том же регионе, где будет база знаний. Раскладка по префиксам экономит время на отладке: matches/2026-05-12/, interviews/, stills/. Тогда синхронизацию можно гонять по частям и не переиндексировать весь архив из-за одного нового файла.
Сервисной роли Knowledge Bases нужны права чтения объектов и листинга: без s3:GetObject и s3:ListBucket индексация упадёт на первом же файле. Точный список поддерживаемых контейнеров и лимит на размер объекта сверяйте с документацией AWS: в публичном описании модели эти цифры не приводятся.
Шаг 2. Создание Managed Knowledge Base с Marengo 3.0
В Amazon Bedrock создайте Knowledge Base, укажите источником данных S3 и выберите TwelveLabs Marengo Embed 3.0 как модель эмбеддингов. Векторное хранилище в managed-варианте поднимать отдельно не нужно.
На этом шаге фиксируются два параметра, которые потом дорого менять: модель эмбеддингов и параметры чанкинга. Смена модели означает полную переиндексацию архива, поэтому решение лучше принимать до загрузки сотен часов видео.
Шаг 3. Настройка сегментации аудио и видео
Сегментация для видео и для аудио задаётся отдельно. Смысл параметра простой: он определяет, насколько крупными кусками модель кодирует запись. Крупный чанк даёт устойчивый смысл и грубый таймкод. Мелкий чанк точнее попадает в момент, но добавляет векторов, шума в выдаче и расходов на хранение.
Практическое правило: для матчей и длинных лекций начинайте с сегментов, которые покрывают цельный эпизод (атака, ответ на вопрос, слайд), и уменьшайте их, если выдача приносит «около момента», но не сам момент. Допустимые значения и единицы измерения смотрите в документации: в описании модели они не зафиксированы.
Шаг 4. Синхронизация данных
Синхронизация запускает обработку: сервис читает объекты из S3, режет их, считает эмбеддинги и складывает в индекс. Первый прогон по большому архиву идёт заметно дольше последующих.
Новые файлы сами в индекс не попадут: после загрузки запустите синхронизацию ещё раз. Изменённый файл тоже требует новой синхронизации, иначе поиск продолжит возвращать старые таймкоды. Как сервис ведёт себя при удалении объекта из бакета, проверьте на тестовом префиксе: в разборе это не описано, а для архива с выбраковкой материала поведение принципиально.
Тестовые семантические запросы и формат ответа
Как формулировать запросы, чтобы находить нужное
Модель ищет по смыслу, поэтому описание работает лучше набора ключевых слов. Сравните: «пенальти» вернёт всё, где есть пенальти; «покажи пенальти из этого матча, где вратарь угадал направление» сузит выдачу до нужного эпизода.
Что помогает в формулировке:
- действие и объект: «защитник выбивает мяч в подкате», «говорящий показывает график на слайде»;
- контекст сцены: «на фоне трибун», «в переговорной комнате», «крупный план»;
- речь: «момент, где обсуждают бюджет второго квартала»;
- тип материала: «интервью», «пресс-конференция», «разминка перед матчем».
Для изображений логика та же: описывайте содержимое, а не имя файла. «Слайд с графиком выручки за третий квартал» найдёт кадр презентации, а «IMG_2041» не найдёт ничего, если имя не попало в текстовые метаданные.
Язык запроса. Marengo 3.0 работает с видео, аудио, изображениями и текстом в одном пространстве, но разбивки качества по конкретным языкам публичные материалы не дают. Если записи на русском, прогоните тестовый набор запросов на русском и на английском и сравните фактическую выдачу. Такой тест дешевле, чем выяснять вопрос на проде.
Что внутри чанка: таймкоды и метаданные
Результат поиска - ранжированный список чанков. В каждом есть привязка к исходному объекту в S3 и таймкоды фрагмента: начало и конец. Именно таймкоды превращают поиск в рабочий интерфейс: плеер открывается на нужной секунде, а не на старте двухчасовой записи.
Полный набор служебных полей и их имена смотрите в документации Retrieve API: сервис может расширять ответ метаданными. Для интерфейса хватает трёх вещей: ссылка на файл, начало и конец отрезка.
Релевантность оценивайте ранжированием, а не фактом попадания. Первые три результата должны содержать момент, который вы искали. Если нужный фрагмент стабильно оказывается в конце списка, проблема в сегментации или в формулировке запроса, и оба параметра дешевле править до релиза.
Retrieve API: встраиваем поиск в своё приложение
Retrieve API - точка входа для своего продукта: приложение отправляет текстовый запрос к базе знаний и получает ранжированные чанки, которые можно отдать в интерфейс.
Типовой сценарий интеграции
Цепочка выглядит так: пользователь вводит запрос, бэкенд вызывает Retrieve API, из чанков собирается ответ - список моментов с превью и таймкодами, плеер открывает запись на нужной секунде. Имена параметров и точную структуру запроса берите из документации AWS, ниже концептуальная схема:
retrieve(knowledge_base_id, query="покажи пенальти из этого матча", results=5)
-> [ {source: s3://..., start: 00:14:32, end: 00:14:58, score: ...}, ... ]
Дальше два пути. Первый: отдавать чанки как есть, пользователь сам решает, что смотреть. Второй: передать найденные фрагменты и запрос в LLM и получить текстовый ответ со ссылками на таймкоды, то есть классический RAG.
Для составных вопросов («сравни, как команда играла в первом и во втором тайме») одного вызова может не хватить: одношаговый поиск плохо разбирает многосоставные запросы. Многошаговый вариант с планировщиком разобран в материале про AgenticRetrieveStream: там метрики recall и сравнение с Retrieve API по стоимости.
Ограничения и модель оплаты: что нужно знать до внедрения
Региональные ограничения и их последствия
Модель доступна в двух регионах: us-east-1 и eu-west-1. Для команды в Европе это обычно приемлемо. Для проектов с требованием хранить данные в другом контуре это блокер: медиа и база знаний должны лежать там, где работает модель.
Второй эффект - латентность. Если приложение и пользователи далеко от выбранного региона, сетевая задержка добавится к времени retrieval. Замеряйте полное время ответа на реальном канале, а не только время ответа API.
За что платить: хранение и извлечение
Оплата складывается из двух частей: хранение и извлечение. Хранение растёт от объёма проиндексированного медиа и числа чанков, извлечение - от количества запросов. Для архива в сотни часов основная статья расходов часто оказывается на хранении, для чат-интерфейса с активными пользователями - на извлечении.
Конкретные тарифы здесь не приводятся: их смотрите в прайсе AWS, он меняется. Что стоит прикинуть заранее: число чанков (объём записи делить на размер сегмента) умножить на тариф хранения, а для извлечения посчитать запросы на пользователя в день.
Отдельный практический момент для команд из России: оплата AWS и подписок на иностранные сервисы требует зарубежной карты. Такие карты выпускают дистанционно, пополнение идёт в рублях, привязка к Apple Pay и Google Pay поддерживается - вариант виртуальной карты зарубежного банка. Это про платёжную инфраструктуру, а не про сам сервис.
Где это реально применимо: сценарии использования
Спортивная аналитика и медиаархивы
Тренерскому штабу нужен не архив матчей, а конкретные эпизоды. Запрос «покажи, как соперник выходил из-под прессинга во втором тайме» возвращает отрезки с таймкодами, и аналитик тратит минуты вместо часов на перемотку.
Медиаархив получает поиск по содержанию без ручной разметки: «интервью, где спикер говорит о запуске продукта на фоне логотипа», «кадры с камеры на трибуне во время гола». Раньше такая выборка означала работу редактора с таймлайном.
Безопасность и обучение
В безопасности запрос формулируется как событие: «человек в тёмной куртке у ворот склада после 22:00», «машина, стоящая у периметра больше пяти минут». Таймкод даёт переход к нужному участку записи, а не двадцатиминутному окну, которое просматривают целиком.
В обучении поиск по лекциям закрывает старую проблему: студент помнит объяснение, но не помнит название темы. «Фрагмент, где объясняют разницу между precision и recall на примере поиска» находит нужную минуту записи.
Стоит ли использовать: кому подходит и кому нет
Когда managed-подход выигрывает
Три условия: команда уже работает на AWS, медиа нужно искать по смыслу, своей ML-инфраструктуры для видео нет. В таком раскладе запуск занимает дни: S3, база знаний, сегментация, синхронизация, Retrieve API.
Рабочий пример managed Knowledge Bases вне медиа: IskayPet собрала мультиязычного ассистента и получила ответ примерно за 7 секунд вместо 3-5 минут ручного поиска по документам - разбор кейса. Медийный сценарий отличается составом данных и модальностями, логика та же: сервис берёт на себя индекс и retrieval.
Когда лучше собрать свой пайплайн
Свой пайплайн оправдан в нескольких случаях: нужна нестандартная сегментация (по монтажным склейкам или по распознанным событиям), нужна модель эмбеддингов вне каталога сервиса, проект живёт вне us-east-1 и eu-west-1, либо счёт за извлечение стал заметной строкой бюджета и его хочется контролировать кешем и собственным переранжированием.
Промежуточный вариант: managed KB для медиа плюс свой слой поверх - кеш частых запросов, переранжирование, права доступа. Такой гибрид часто дешевле полной самосборки. Как выглядит production-обвязка с маршрутизацией между базами и наблюдаемостью, разобрано в статье про агентный поиск в Managed Knowledge Base.
Частые вопросы о Marengo 3.0 в Amazon Bedrock Knowledge Bases
Какие модальности поддерживает модель? Видео, аудио, изображения и текст. Все они кодируются в одно 512-мерное векторное пространство, поэтому текстовый запрос может находить видеомомент.
В каких регионах доступна Marengo Embed 3.0? us-east-1 и eu-west-1. Базу знаний и данные в S3 нужно держать в том же регионе.
Как оплачивается использование? Две составляющие: хранение проиндексированных данных и извлечение при запросах. Тарифы смотрите в прайсе AWS.
Что возвращает поиск? Ранжированные чанки с привязкой к исходному файлу и таймкодами фрагмента.
Нужна ли своя векторная база? Нет. Хранение векторов и поиск берёт на себя managed-сервис.
Можно ли встроить поиск в своё приложение? Да, через Retrieve API: запрос уходит из бэкенда, ответ с чанками и таймкодами отдаётся в интерфейс.
Как проверять качество на русскоязычных записях? Собрать набор типовых запросов и посмотреть, на каких позициях оказывается нужный фрагмент. Публичных замеров по языкам нет, поэтому ориентируйтесь на собственную выдачу.