Видеоархив: поиск и вопрос-ответ на мультимодальном RAG

TL;DR

Этот итоговый проект собирает блок курса про мультимодальный ИИ в один готовый продукт: движок, который позволяет человеку задать обычный вопрос большому видеоархиву – «где ведущий упоминает политику возврата?», «найди все клипы, где ворота погрузочной зоны оставлены открытыми» – и получить письменный ответ вместе с точными клипами и таймкодами, из которых он собран. Хребет сборки – два правила, которые держатся, как бы быстро ни менялись модели: индексируйте архив один раз и на каждый вопрос читайте лишь несколько найденных моментов, а не скармливайте модели всю библиотеку, и не выпускайте ни один ответ пользователю без цитаты на исходный клип и таймкод. Мы даём точный список компонентов с вердиктом «строить или купить» по каждому, таблицу выбора модели с ценами 2026 года и для embedding-модели, и для модели-ответчика, модель затрат с показанной арифметикой – разовая индексация архива против невозможности отправлять его long-context-модели на каждый вопрос, план из пяти майлстоунов, где рабочая строка поиска выходит уже на первой неделе, и карту governance – кто имеет право видеть какой клип и как обходятся с приватностью людей внутри кадра – которая отделяет движок, пригодный для медиакомпании, от обузы. Там, где урок про video RAG объяснял, как работает поиск-с-извлечением по видео, этот итоговый проект – система, которая переживёт отключение embedding-модели, как случилось с Marengo 2.7 от Twelve Labs 30 марта 2026 года.

Почему это важно

Эта статья – для основателя, продакт-лида или руководителя операций в медиакомпании, стриминговом сервисе, у вещателя или в любом бизнесе с годами записанного видео, которому задали очевидный вопрос: «А можно ли просто его спрашивать?». У вас есть вебинары, прошлые эфиры, бэк-каталог, записанные звонки, библиотеки лекций, кадры наблюдения – и сейчас единственный способ найти момент внутри них в том, чтобы человек вспомнил, где он, или вручную проматывал часы таймлайна. Этот итоговый проект показывает, сколько на самом деле стоит движок поиска-и-Q&A по архиву, сколько занимает сборка, что покупается, а что строится, и где закон и правила доступа проводят жёсткие линии. Он же – для инженера, который прочёл отдельные мультимодальные уроки и хочет сварить их в одну разворачиваемую систему с конкретными технологиями, реальными ценами и планкой точности. Он предполагает, что базовые идеи вы уже встречали, потому что итоговый проект собирает, а не выводит заново; перекрёстные ссылки возвращают к каждому фундаментальному уроку, когда нужна деталь. К концу вы сможете нарисовать движок на доске, назвать точную технологию 2026 года в каждом блоке, защитить стоимость одного вопроса перед финансистами, выстроить сборку так, чтобы первая версия вышла за недели, и отличить дизайн, который пройдёт ревью по безопасности и приватности, от того, что юридическая команда остановит на пороге.

Что именно вы строите, точная формулировка

Зафиксируйте продукт прежде любой технологии. Вы строите внутренний или клиентский сервис с одной работой: человек печатает или произносит вопрос о содержимом видеотеки, а сервис возвращает короткий письменный ответ вместе с конкретными клипами и таймкодами, из которых этот ответ взят. Это две функции на общем хребте. Первая – поиск: опишите момент и получите подходящие моменты, ранжированные по релевантности. Вторая – ответы на вопросы, обычно сокращаемые до Q&A: задайте настоящий вопрос и получите письменный ответ, собранный из кадров, а не просто список ссылок. Обе опираются на одну машинерию; функция Q&A лишь добавляет финальный шаг, который читает найденные клипы и пишет прозу.

Два термина в этом описании весомы. OTT – это «over-the-top», видео, доставляемое зрителям по открытому интернету, а не через кабельную или спутниковую приставку, чем и является любой современный стриминговый сервис. Архив здесь – накопленная библиотека готового и сырого видео, которой владеет платформа: прошлые выпуски, записи живых событий, неиспользованные кадры, весь бэк-каталог. Так что продукт – движок поиска-и-Q&A, нацеленный на архив OTT-платформы: не система рекомендаций для зрителей, а инструмент, которым пользуются сами люди платформы или её продвинутые пользователи, чтобы находить и осмыслять то, что лежит в библиотеке.

У техники под капотом есть знакомое имя: retrieval-augmented generation, почти всегда сокращаемое до RAG (генерация с извлечением). Простая версия идеи – то, как библиотекарь отвечает на трудный вопрос: не читает каждую книгу в здании, а идёт к нужной полке, достаёт две-три книги по теме и отвечает по этим страницам. Извлечение (retrieval) – это путь к полке; генерация – ответ, написанный из того, что достали. «Мультимодальный» означает, что на полке лежат движущиеся картинки и звук, а не только текст, и система умеет искать по всему этому. Полную механику разбирает урок про video RAG; этот итоговый проект – готовая система, которая оборачивает её в продукт.

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

Хребет: два правила, которые переживут модели

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

Первое правило – индексируем один раз, читаем по запросу; архив никогда не попадает в модель. Дорогую работу понимания и индексации каждого видео вы делаете ровно один раз, когда оно входит в библиотеку; дальше каждый вопрос читает лишь горстку моментов, которые к нему действительно относятся. Это не предпочтение, а вынужденность арифметики, которую делает конкретной раздел о затратах. Современная фронтир-модель может прочесть несколько часов видео в одном запросе, но архив измеряется тысячами часов, и скармливать всё целиком в модель на каждый вопрос и невозможно – оно не помещается, – и даже на грани, где помещается, разорительно дорого и менее точно, потому что внимание модели редеет на гигантском входе. Поэтому систему делят надвое: медленная, разовая половина ингеста, которая превращает каждое видео в искабельную форму, и быстрая, дешёвая половина запроса, которая выполняется на каждый вопрос. Держать эти две половины раздельно в голове – самая полезная ментальная модель для бюджетирования всего движка.

Второе правило – ни одного ответа без цитаты. Каждый ответ, который выдаёт движок, обязан указывать на точный источник – видео и таймкод внутри него, – из которого он взят. Это разница между фокусом и инструментом, которому бизнес доверяет. Ответ, который пользователь может проверить в один клик, перейдя на 14:32 в мартовской записи и увидев момент сам, – это ответ, на который он положится; ответ без источника – тот, что он должен перепроверять сам, что сводит на нет всю затею. Цитата не украшение, прикрученное в конце. Это ограничение, которое идёт обратно по всему конвейеру: каждый искабельный кусок обязан нести свой источник и таймкод с момента создания, иначе финальному ответу нечего цитировать. Встраивайте цитату с первого майлстоуна, потому что дооснащать происхождением движок, который выбросил таймкоды, – это пересборка.

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

Нажмите, чтобы увеличить

Рисунок 1. У движка две половины и пол governance. Левая выполняется один раз на видео и несёт затраты; правая выполняется на каждый вопрос и остаётся дешёвой, потому что касается лишь нескольких найденных моментов; права и приватность применяются и на индексации, и на запросе.

Производственная архитектура, блок за блоком

Реальное развёртывание – больше, чем вызов поисковой модели. Девять видов компонентов всплывают в каждом движке поиска-и-Q&A по архиву, который мы прорабатывали, и назвать их точно – первый час любого проекта. Они чисто делятся на две половины первого правила.

Половина ингеста выполняется один раз на видео. Она открывается чанкером, который режет каждое видео на маленькие искабельные куски, которые потом извлекаются и показываются. Чанк – это единица, которую пользователь получает обратно, поэтому его размер – реальное продуктовое решение: режьте каждые тридцать секунд по таймеру – и вы рассечёте середину фразы или действия; режьте по границам сцен – новый кадр, новый говорящий, новая тема – и каждый чанк станет одной цельной мыслью, которая извлекается чисто. Правило – выравнивать чанки по смыслу, а не по часам.

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

Экстрактор превращает каждый чанк в искабельный смысл, и здесь вы выбираете между двумя честными дизайнами, которые разложил урок про video RAG. Дешёвый, зрелый путь – текстовое заземление: сначала перевести всё в текст – произнесённые слова через распознавание речи (ASR, технология за субтитрами, которая, что важно, записывает, когда было сказано каждое слово), экранный текст через распознавание текста (OCR), а чисто визуальное содержимое каждой сцены через vision-language-модель, которой велено описать, что она видит, – а затем искать по этому тексту обычным дешёвым текстовым конвейером. Богаче и тяжелее – прямые визуальные эмбеддинги: прогнать сами кадры через мультимодальную модель, чтобы чисто визуальный смысл выживал даже там, где его никто не озвучил. Большинство сильных систем 2026 года – гибридные: опираются на текстовое заземление в основном, добавляя визуальные эмбеддинги там, где важны чисто визуальные вопросы. Инженерия ASR и OCR – в уроке про WhisperX и уроке про PaddleOCR.

Embedding-модель переводит этот извлечённый смысл в эмбеддинг – список чисел, от нескольких сотен до нескольких тысяч, который захватывает смысл куска контента как одну точку в пространстве, так что два клипа об одном и том же ложатся рядом, а вопрос можно превратить в точку на той же карте. Индексатор затем кладёт каждый эмбеддинг в вектор-базу – базу, заточенную под одну работу: быстро находить ближайшие к точке-запросу хранимые точки среди миллионов, – вместе с метаданными, которые делают возможным второе правило: источник, точный таймкод, текст чанка и теги прав, говорящие, кто может его видеть. Эти метаданные не запоздалая мысль; именно они позволяют финальному ответу процитировать «минута 14 записи от 3 марта» и позволяют движку отказать в показе клипа тому, у кого нет доступа.

Половина запроса выполняется на каждый вопрос и должна оставаться быстрой и дешёвой. Она открывается разбором запроса – лёгким шагом, который чистит вопрос, расширяет его и решает, поиск это («покажи клипы…») или настоящий вопрос («что сказал аналитик о…»). Затем гибридный ретривер делает центральную работу: превращает вопрос в точку на той же карте смысла и просит вектор-базу о ближайших чанках (семантический поиск), и одновременно гонит обычный поиск по ключевым словам (лексический поиск), чтобы точные термины, имена и коды не терялись. Смешение двух – семантика для смысла, ключевые слова для точности – это то, что делают системы 2026 года, потому что каждый ловит то, что упускает другой. Затем реранкер берёт эти несколько кандидатов и переоценивает их более медленной, аккуратной моделью, оставляя лучшие два-три; реранк короткого списка дёшев, потому что список уже короткий.

Наконец, модель-ответчик – vision-language- или большая языковая модель – читает только эти найденные чанки вместе с исходным вопросом и пишет ответ, используя лишь то, что ей дали, оканчивая его цитатой, которой требует второе правило. Поверхность ответа-и-цитат – то, что пользователь реально видит: письменный ответ, исходные клипы с их таймкодами и переход на момент в один клик. Под всем этим работает слой governance и аудита – проверки прав, контроль приватности людей в кадре и журнал каждого заданного вопроса и каждого возвращённого клипа. Для движка, дотягивающегося до всей видеопамяти компании, этот слой не опциональная инфраструктура; это то, что вообще позволяет движок развернуть.

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

Строить или купить: вердикт 2026 года, компонент за компонентом

Сильная команда не пишет всё это с нуля и не покупает всё целиком. Эмпирическое правило вторит другим итоговым проектам курса: берите зрелую инфраструктуру, арендуйте или хостите быстро меняющиеся модели и стройте лишь те части, что и есть ваш продукт – здесь это конвейер чанкинга-и-экстракции, заточенный под ваш архив, логика гибридного ретрива и слой цитат-и-governance. Это блоки, которые делают движок точным и безопасным для развёртывания; остальное покупается.

Две ячейки заслуживают примечания, потому что в них команды ошибаются. Ячейка embedding-модели помечена «аренда или хост», и выбор между ними – реальная развилка: облачный embedding-API быстрее запустить и он всегда актуален, тогда как self-hosted open-модель вроде SigLIP 2 держит каждый кадр внутри вашей инфраструктуры – что важно, когда сам архив конфиденциален, например невышедшие кадры. Ячейка governance помечена «строить», и её команды чаще всего тянет пропустить – поиск увлекателен, права – бумажная работа. Пропуск – самая дорогая из доступных ошибок, потому что движок, отвечающий по кадрам, которые спрашивающему видеть не положено, – это инцидент утечки данных в ожидании аудита, а движок, игнорирующий приватность людей внутри кадра, – регуляторный.

Нажмите, чтобы увеличить

Рисунок 2. Что строить, а что брать. Арендуйте embedding- и ответную модели и вектор-базу; стройте конвейер экстракции, гибридный ретрив, поверхность цитат и слой governance – части, которые делают движок точным и безопасным.

Выбор моделей – и зачем абстрагировать их всё равно

Этот движок арендует две модели, и обе должны стоять за тонким внутренним интерфейсом, потому что верный ответ для каждой меняется каждый квартал. Дело не в том, какая модель победит сегодня; дело в том, что ни одна модель не побеждает надолго, и движок, прибитый напрямую к одному вендору, наследует волатильность этого вендора.

Первая арендуемая модель – embedding-модель, часть, которая превращает и ваш архив, и входящий вопрос в точки на одной карте смысла. Середина 2026 даёт плотное поле. Gemini Embedding 2 от Google, запущенная 10 марта 2026, – её первая нативно мультимодальная embedding-модель, отображающая текст, картинки, видео, аудио и PDF в единое 3072-мерное пространство, что делает её естественным выбором для архива, где есть всё это. Cohere Embed 4 – другой сильный облачный вариант, а Twelve Labs Marengo 3 построена специально под видео и доступна и напрямую через Twelve Labs, и через Amazon Bedrock, рядом с собственными мультимодальными эмбеддингами Amazon Nova. На стороне открытых весов SigLIP 2 и Jina v5 теперь соперничают с коммерческими API на бенчмарках извлечения и крутятся на ваших GPU, держа архив внутри ваших стен. Введение в эмбеддинги – урок про CLIP.

Вторая арендуемая модель – модель-ответчик, vision-language- или большая языковая модель, которая читает найденные чанки и пишет заземлённый ответ. Здесь выбор тот же, что курс рисовал не раз: закрытая фронтир-модель вроде Google Gemini 2.5, Anthropic Claude или OpenAI GPT для сильнейших рассуждений, либо открытая модель вроде LLaVA или Qwen-VL, когда кадры должны оставаться на вашем железе. Поскольку модель-ответчик всегда видит лишь несколько маленьких найденных чанков – никогда не архив, – даже средняя модель выдаёт хорошие ответы, так что здесь стоит маршрутизировать по цене и чувствительности, а не всегда тянуться к самой дорогой. Поле открытых моделей – урок про LLaVA и Qwen-VL.

Теперь причина, почему обе стоят за интерфейсом, изложенная как живой кейс, а не как принцип. 30 марта 2026 Twelve Labs закрыли свою модель Marengo 2.7: команды больше не могли индексировать новый контент, делать поиск или извлекать эмбеддинги уже проиндексированного контента, и им сказали мигрировать. Архив, каждый вектор которого был произведён Marengo 2.7, столкнулся не просто с изменением кода, а с переиндексацией – потому что эмбеддинги одной модели несравнимы с эмбеддингами другой, снятие embedding-модели означает переэмбеддинг архива. Команда, обернувшая шаг эмбеддинга одним внутренним интерфейсом и сохранившая дешёвый извлечённый текст рядом с векторами, могла переиндексироваться против новой модели фоновой задачей. Команда, жёстко привязавшая по всему конвейеру конкретные вызовы Marengo 2.7, провела ту весну, распутывая их под дедлайн. Эмбеддинги – единственная по-настоящему дорогая замена, именно поэтому абстракция и сохранённый исходный текст важнее всего там.

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

Нажмите, чтобы увеличить

Рисунок 3. Движок арендует две модели, которые меняются с очень разной ценой. Модель-ответчик заменить почти бесплатно; embedding-модель – дорогая замена, потому что её смена аннулирует индекс, – так что абстрагируйте обе и храните извлечённый текст рядом с векторами.

Один вопрос: от запроса до ответа с цитатой

Числа и блоки становятся конкретными, когда вы прослеживаете один запрос через систему. Проследим одну работу: операционному аналитику стримингового сервиса нужно узнать, за два года еженедельного новостного шоу, каждый раз, когда определённого спонсора называли по имени, чтобы команда рекламных продаж проверила выполнение. Он открывает строку поиска и печатает «каждое упоминание спонсора Northwind ведущим или гостями».

Вопрос сначала попадает в разбор запроса. Он распознаётся как поиск, которому нужна и буквальная точность по термину – название бренда «Northwind» должно совпасть дословно, – и семантическая широта, потому что гость мог сказать «ребята из Northwind» или «наш спонсор на этой неделе». Шаг сохраняет буквальный термин для поиска по ключевым словам и расширяет смысл для семантического поиска.

Гибридный ретривер гонит оба сразу. Поиск по ключевым словам находит каждый чанк, чей транскрипт буквально содержит «Northwind»; семантический находит чанки, чей смысл близок даже там, где точное слово размыто. Два списка результатов сливаются. Это момент, когда разовый ингест окупается: из, может быть, сорока тысяч чанков за два года выпусков ретривер достаёт несколько десятков кандидатов за миллисекунды, потому что тяжёлая работа понимания каждого выпуска была сделана на индексации.

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

Модель-ответчик читает только эти найденные чанки, не архив, и пишет ответ: список каждого подтверждённого упоминания, с датой выпуска и таймкодом, и однострочной заметкой о контексте. Поскольку метаданные ехали с каждым чанком с момента создания, каждая строка ответа оканчивается цитатой, на которую аналитик может кликнуть и перейти прямо на 11:48 в выпуске от 14 февраля и убедиться. Прежде чем что-либо показать, слой governance проверяет, что этот аналитик имеет право искать по архиву этого шоу; у подрядчика без прав на невышедшие сегменты они были бы тихо исключены из результатов. Каждый шаг – вопрос, найденные кандидаты, переоценённый набор, ответ и возвращённые клипы – пишется в аудит-лог, чтобы движок мог позже показать ровно, что спрашивали и что выдали.

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

Нажмите, чтобы увеличить

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

Проблема точности, под которую нужно проектировать

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

Первый – плохой чанк: нужный момент закопан в чанке, который в основном про другое, или разрезан по шву между двумя чанками, так что ни один не извлекается чисто. Это отказ половины ингеста, и он невидим на запросе, потому что ретривер может вернуть лишь чанки, нарезанные хорошо изначально. Защита – нарезка по сценам, а не по таймеру, чтобы каждый чанк был одной цельной мыслью, плюс небольшой нахлёст между чанками, чтобы момент у границы выжил в обоих. Когда движок «не может найти» то, что пользователь точно знает, первый подозреваемый – чанкер, а не поиск.

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

Третий уникален для ответа: ответ без основания – модель пишет нечто правдоподобное, что найденные чанки на деле не подтверждают, или отвечает уверенно, когда ретрив не нашёл ничего релевантного вовсе. Это галлюцинация в костюме процитированного ответа. Защита двойная. Во-первых, велите модели-ответчику использовать только найденный материал и воздерживаться – сказать «не нахожу этого в архиве», – когда ретрив вернулся пустым или слабым, что куда надёжнее уверенной догадки. Во-вторых, насаждайте второе правило механически: ответ, который не может прицепить цитату к утверждению, – это флаг, а не фича, и поверхность должна показывать процитированный клип рядом с каждым утверждением, чтобы человек подтвердил его в один клик. Цитата – не просто удобство для пользователя; это механизм, который держит модель честной.

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

Нажмите, чтобы увеличить

Рисунок 5. Стратегия точности. Ищите двумя путями, реранкуйте и заставьте каждое утверждение нести цитату или воздержаться; проектируйте под три режима отказа, живущих соответственно в чанкере, ретривере и модели-ответчике.

Проблема governance – часть, которая решает, можете ли вы запуститься

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

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

Второй слой – приватность людей внутри кадра. OTT-архив полон опознаваемых людей – ведущих, гостей, звонящих, прохожих, – и поисковый движок, способный найти «каждый клип конкретного человека», по определению обрабатывает биометрические и персональные данные в масштабе. В Евросоюзе это регулирует Общий регламент по защите данных (GDPR), Регламент (ЕС) 2016/679, задающий правила обработки персональных данных, включая изображения и голоса опознаваемых людей, и всё больше – EU AI Act, чьи ограничения на биометрическую идентификацию прямо касаются любой функции, ищущей по лицу или голосу. Практические последствия конкретны: поиск по контенту («клипы про бюджет») обычен; поиск по личности («каждый клип этого человека») – функция повышенного риска, которой нужны законное основание, контроль доступа и зачастую сознательное решение не строить поиск по лицу вовсе. Регуляторную инженерию разбирает урок про EU AI Act; проектная мысль здесь в том, что слой governance решает, какие виды запроса вообще позволены, а не только какие кадры. Это инженерный контекст, не юридический совет; подтвердите свои обязанности с юристом до запуска.

Третий слой – аудит и хранение. Поскольку движок дотягивается до всей видеопамяти компании и отвечает на вопросы о ней, он обязан записывать, что спрашивали и что вернули – и чтобы расследовать злоупотребления, и чтобы позже доказать, что правила доступа соблюдались. Тот же журнал позволяет ответить на запрос субъекта данных о том, искали ли и как его кадры. Относитесь к аудит-логу как к первоклассной части продукта, а не отладочному выводу, потому что для движка такого охвата это разница между «мы можем точно показать, кто что искал» и пожатием плечами на ревью.

Нажмите, чтобы увеличить

Рисунок 6. Три гейта governance. Фильтруйте по правам на этапе ретрива, трактуйте поиск по личности как функцию повышенного риска по GDPR и EU AI Act и логируйте каждый вопрос и результат – охват движка и есть причина, почему это несущие конструкции.

Модель затрат с показанной арифметикой

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

Начнём с индексации одного часа видео, платится один раз. Отбор кадров и чанкинг – дешёвый компьют. Реальные деньги – в моделях экстракции: транскрибировать аудио, описать ключевые кадры и встроить результат. Облачный видео-индекс вроде Twelve Labs оценивает это прямо – индексация Pegasus идёт около $0.042 за минуту видео, – так что:

индекс часа = 60 минут × $0.042/минута
           ≈ $2.50 за час видео, единожды

Самосборный конвейер текстового заземления попадает в ту же окрестность: ASR около $0.006 за минуту – это около $0.36 за час, описание ключевых кадров и эмбеддинг добавляют доллар-два, и итог около двух-трёх долларов за час. Так или иначе, считайте около $2.50 за индексацию одного часа, единожды. Хранение полученных векторов почти бесплатно: несколько сотен чанков в час, каждый по несколько килобайт, стоит центы в месяц даже для большого архива – serverless-хранение Pinecone около $0.33 за гигабайт в месяц, а час видео даёт несколько мегабайт векторов.

Теперь стоимость одного вопроса. Вопрос эмбеддится (доля цента), вектор-поиск читает горстку юнитов (доля цента – Pinecone берёт за чтения около $8.25 за миллион read units, а один запрос использует крошечное число), реранк мал, а модель-ответчик читает лишь несколько найденных чанков – пару тысяч токенов – и пишет короткий ответ. Даже по ставке фронтир-модели генерация – цент-два:

за вопрос ≈ эмбеддинг + поиск + реранк + генерация
         ≈ ~$0.01–0.02 за вопрос

Округлим до цента-двух за вопрос. Теперь сравнение, которое решает всю архитектуру. Наивная альтернатива – пропустить индексацию и отправлять видео прямо long-context-модели на каждый вопрос. Gemini от Google переводит видео в токены примерно по 263 токена на секунду кадров, так что один час – около 946 800 токенов, и по ставке выше 200k в $2.50 за миллион входных токенов:

час в long-context-модель = 946 800 токенов × $2.50 / 1 000 000
                         ≈ $2.37 за вопрос, за час видео

Это примерно разовая стоимость индекса часа – но платится заново на каждый вопрос и лишь для того одного часа, что помещается. Реалистичный архив в тысячу часов потребовал бы около девяноста пяти миллионов токенов, чтобы отправить целиком, чего ни одна модель 2026 года не принимает в одном запросе, так что наивный путь не просто дорог на масштабе; он невозможен. RAG переворачивает экономику: проиндексировать тысячу часов один раз примерно за тысячу раз по $2.50 – около $2 500, фиксированное вложение, – платить пару долларов в месяц за хранение векторов и затем отвечать на каждый вопрос за цент-два. Перелом наступает сразу: после одного среднего видео и горсти вопросов индексация выигрывает, и разрыв растёт с каждым часом архива и каждым запросом. Держите разовую стоимость индекса и стоимость одного вопроса на разных строках любого бюджета, потому что первое – капитал, потраченный на архив, а второе – предельная стоимость использования, и смешение прячет, куда реально уходят деньги. Дисциплину затрат на функцию разбирает урок про оптимизацию затрат.

Нажмите, чтобы увеличить

Рисунок 7. Двухстрочная экономика. Индексация – разовая стоимость на час архива; ответ – цент-два за вопрос; отправка архива long-context-модели на каждый вопрос куда дороже там, где помещается, и невозможна там, где нет.

Частая ошибка: вывалить архив и довериться ответу

Два провала объясняют почти каждый застрявший проект Q&A по архиву, и они – инверсии двух правил хребта.

Первый – вывалить архив в модель. Команда видит, что фронтир-модель принимает часы видео, и заключает, что можно пропустить конвейер индексации целиком – просто отправь кадры и спроси. Это прекрасно демонстрируется на одном коротком клипе, а потом архив растёт, счёт за вопрос лезет к долларам, задержка растягивается до минут, и в день, когда это наведут на настоящую тысячечасовую библиотеку, оно просто не помещается. Лечение – первое правило хребта, и оно почти ничего не стоит, если сделать его первым: индексируй один раз, читай по запросу. Long-context-модели – настоящий инструмент: для одного среднего видео и нескольких вопросов они проще, и честный инженер тянется к ним там, – но они дополнение к RAG на масштабе архива, а не замена ему. Стройте индекс прежде, чем строить то, что масштабируется.

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

Оба провала делят корень: спутать увлекательную часть с ценной. Генерация – увлекательная часть, и теперь она проста. Ценные части – неброские: индекс, который делает архив доступным для вопросов, и цитата, которая позволяет человеку проверить, что сказала модель. Стройте их первыми.

План сборки: пять майлстоунов, ценность на каждом шаге

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

Майлстоун один – строка поиска с цитатами. Проиндексируйте срез архива конвейером текстового заземления (ASR плюс описания ключевых кадров), сложите чанки с их источником и таймкодом в вектор-базу и поставьте впереди строку поиска, возвращающую ранжированные клипы, каждый с диплинком на свой момент. Q&A пока нет – просто поиск, приземляющий вас на точную секунду. Даже это сразу полезно, и, что важно, это встраивает второе правило хребта, цитату, в фундамент, а не прикручивает её позже.

Майлстоун два – заземлённое Q&A с воздержанием. Добавьте модель-ответчик, которая читает найденные чанки и пишет заземлённый ответ, с указанием использовать только найденный материал и воздерживаться при слабом ретриве, где каждое утверждение несёт цитату. Это майлстоун, превращающий поиск в ответы на вопросы, и делать его с воздержанием с самого начала – то, что держит его надёжным.

Майлстоун три – гибридный ретрив и реранк. Добавьте половину с ключевыми словами рядом с семантическим поиском и реранкер над слитым списком. Это майлстоун, чинящий режим промаха ретрива и поднимающий точность с «хорошо для демо» до «хорошо для продакшна», особенно на точных именах, кодах и редких терминах.

Майлстоун четыре – governance: права, приватность, аудит. Добавьте теги прав на индексации и фильтр доступа на запросе, политическое решение, предлагать ли поиск по личности вообще, и аудит-лог. Это майлстоун, превращающий ловкий инструмент в разворачиваемый сервис, и делать его четвёртым – не последним – и есть суть раздела про governance.

Майлстоун пять – масштаб, переиндексация и оценка. Проиндексируйте весь архив, добавьте фоновую задачу переиндексации, позволяющую сменить embedding-модель без кризиса, постройте стенд оценки ретрива, измеряющий, находятся ли нужные чанки, и добавьте контроль затрат. Это майлстоун, делающий движок дешёвым в эксплуатации на масштабе архива и безопасным к эволюции по мере смены моделей.

Выстройте так, чтобы рабочий продукт существовал после первого майлстоуна, а предохранители пришли до того, как открыт весь архив, а не после. Команда, выпустившая поиск и Q&A и оставившая права «на потом», построила ровно ту утечку данных, о которой предупреждает раздел governance.

Производственные заботы: переиндексация, права на запросе и оценка ретрива

Три эксплуатационных реальности решают, переживёт ли движок контакт с настоящим архивом.

Первая – переиндексация без простоя. Embedding-модели уходят на покой – Marengo 2.7 погасла в марте 2026, – а стратегии чанкинга улучшаются, так что вы будете переиндексироваться, и архив не может погаснуть, пока вы это делаете. Долговечный паттерн держит дешёвый извлечённый текст (транскрипты, описания, OCR) хранимым постоянно рядом с векторами, чтобы переиндексация переэмбеддила из уже имеющегося текста, а не перезапускала дорогую экстракцию; и строит новый индекс рядом со старым, переключаясь атомарно. Хранение исходного текста – дешёвая страховка, превращающая единственную по-настоящему дорогую замену в фоновую задачу.

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

Третья – оценивать ретрив, а не только генерацию. Соблазнительно мерить, хорошо ли читаются письменные ответы, но ответ может быть лишь так хорош, как чанки, которые нашёл ретривер, и гладкий ответ по неверным чанкам – самый опасный вывод из всех. Постройте небольшой набор оценки из реальных вопросов с их известными верными моментами и измеряйте, действительно ли ретривер поднимает эти моменты – дисциплину, которой курс учит для видео-ИИ-функций в целом, применённую здесь к шагу ретрива. Когда точность падает, этот стенд говорит, виноват ли чанкер, ретривер или модель-ответчик, вместо того чтобы оставить вас гадать.

Где здесь Фора Софт

Фора Софт строит видеософт с 2005 года, и OTT, стриминг и ИИ-софт вокруг них – среди вертикалей, которые мы поставляем, рядом с видеоконференциями, e-learning, телемедициной и видеонаблюдением. Движок, описанный здесь – конвейер экстракции с учётом сцен, питающий вектор-индекс, гибридный ретривер с реранком, заземлённая модель-ответчик, цитирующая каждое утверждение, и слой governance, фильтрующий по правам и уважающий приватность людей в кадре – это форма работы по мультимодальному поиску, которую мы прорабатываем для медиаархивов. Порядок сборки и вердикты «строить или купить» в этой статье для нас не теория; это чек-лист, который мы применяем, потому что они – разница между движком, приземляющим пользователя на точную секунду, о которой он спросил, и тем, что уверенно выдумывает ответ или сливает закрытый клип. Карта governance – тоже часть этого чек-листа: мы кладём права и цитату в фундамент, трактуем поиск по личности как сознательное политическое решение, а не функцию по умолчанию, и держим извлечённый текст рядом с векторами, чтобы уход модели был плановой переиндексацией, а не аварией. Наша работа здесь живёт в OTT, стриминге и ИИ-софте вокруг них, где точный ретривер и честный, процитированный ответ – ядро продукта, а не украшение.

Ключевые выводы

• Продукт – это процитированный ответ, а не гладкий: индексация делает архив доступным, цитата – надёжным.
• Индексируйте каждое видео один раз и читайте лишь несколько найденных моментов на вопрос – архив не входит в модель.
• Отправлять архив long-context-модели на каждый вопрос куда дороже там, где помещается, и невозможно там, где нет.
• Ищите двумя путями – семантика для смысла, ключевые слова для точных терминов – затем реранкуйте; один стиль упускает класс вопросов.
• Смена embedding-модели вынуждает переиндексацию, так что абстрагируйте её и храните извлечённый текст рядом с векторами.
• Фильтруйте по правам на этапе ретрива и трактуйте поиск по личности как функцию повышенного риска по GDPR и EU AI Act.

Что читать дальше

• Урок 4.6 – Video RAG + мультимодальный RAG по видеоархиву
• Урок 4.4 – Открытый фронтир VLM: LLaVA, Qwen-VL, LLaVA-NeXT, InternVL
• Урок 9.2 – Разработка OTT-платформы: инженерный плейбук по ИИ