Видеоархив: поиск и вопрос-ответ на мультимодальном 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- или большая языковая модель – анализирует только найденные фрагменты вместе с исходным вопросом и формирует ответ, опираясь исключительно на предоставленные данные, завершая его цитатой, как того требует второе правило. Поверхность ответа и цитаты – то, что видит пользователь: текстовый ответ, исходные видеофрагменты с таймкодами и возможность перейти к нужному моменту одним кликом. Под этим интерфейсом работает слой управления и аудита – проверка прав доступа, контроль приватности людей на кадре и ведение журнала каждого заданного вопроса и каждого возвращённого фрагмента. Для системы, охватывающей всю видеопамять компании, этот слой – не опциональная инфраструктура, а необходимое условие её функционирования.

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

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

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

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

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

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

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

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

Первая арендуемая модель – 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, столкнулся не просто с изменением кода, а с переиндексацией – ведь эмбеддинги одной модели несовместимы с эмбеддингами другой. Замена модели означает полную переэмбеддинговую обработку всего архива.

Команда, которая обёрнула этап эмбеддинга единым внутренним интерфейсом и сохранила рядом с векторами дешёвый извлечённый текст, смогла переиндексировать данные в фоне, используя новую модель. А команда, жёстко привязавшая по всему конвейеру прямые вызовы к 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 за миллион операций чтения, а один запрос использует ничтожно малое количество), реранкинг лёгкий, а модель-ответчик обрабатывает лишь несколько найденных чанков – пару тысяч токенов – и генерирует короткий ответ. Даже при тарифах на передовые модели генерация обходится в один-два цента:

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

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

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

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

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

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

Частая ошибка: выгрузить архив и полагаться на ответ

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

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

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

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

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

Организуйте сборку так, чтобы рабочий инструмент появился как можно раньше, а каждый этап (майлстоун) приносил реальную пользу – чтобы команда могла им пользоваться, а не ждать год, пока появится первый результат.

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

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

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

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

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

Организуйте процесс так, чтобы рабочий продукт появился ещё до первого майлстоуна, а предохранители были внедрены до открытия всего архива – а не после. Команда, выпустившая функционал поиска и 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-платформы: инженерный плейбук по ИИ