Video RAG: мультимодальный RAG по видео-архиву

TL;DR

Video RAG (retrieval-augmented generation по видео) – это приём, который позволяет ИИ ответить на вопрос, сначала найдя несколько релевантных моментов внутри большой видеотеки, а затем прочитав только их, а не весь архив. Вы строите его так: режете каждое видео на ищущиеся кусочки, превращаете каждый кусочек в список чисел – эмбеддинг, складываете эти числа в базу данных для быстрого поиска по похожести, а в момент вопроса достаёте ближайшие кусочки и отдаёте их vision-language модели, чтобы та написала ответ. Делать это вместо того, чтобы скормить весь архив модели с длинным контекстом, заставляют стоимость и точность: тысяча часов видео слишком велика для одного запроса, а даже когда влезает, внимание модели «расплывается» и ответы деградируют. Этот урок показывает владельцу продукта, как именно устроен конвейер, где прячутся деньги и ошибки, и когда модель с длинным контекстом – более простой ответ.

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

У вас растёт куча записанного видео – прошедшие вебинары, записи с камер, записанные консультации, лекции курса, звонки поддержки – и кто-то задал очевидный вопрос: «А можно у него просто спрашивать?» Найти момент, когда дефект впервые появился. Достать каждый клип, где показывали определённую процедуру. Подытожить, на что жаловался клиент, по сорока звонкам поддержки. Технология, которая отвечает на эти вопросы, – Video RAG, и она мост между vision-language моделями, о которых вы уже читали, и фичей, за которую люди реально заплатят. Этот урок написан для продакт-менеджера, основателя или операционного руководителя, которому надо оценить такую фичу и решить, во что она обойдётся, где будет хрупкой и не подойдёт ли путь попроще. Он опирается на урок про открытые VLM и урок про fine-tuning; если слова «vision-language модель», «веса» и «эмбеддинг» для вас новые, начните с урока про video-VLM.

Что такое RAG, на одной простой картинке

Начнём с бытовой версии идеи, потому что версия для ИИ – тот же трюк. Когда библиотекарь отвечает на сложный вопрос, он не читает каждую книгу в здании. Он идёт к нужной полке, достаёт две-три книги по теме, открывает их на нужных страницах и отвечает по этим страницам. Retrieval (извлечение) – это поход к полке; generation (генерация) – это ответ, написанный по тому, что достали.

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

Text RAG – извлечение по документам – стал решённой, обычной вещью ещё с 2023 года. Video RAG – более сложный, новый родственник: исходный материал – это часы движущихся картинок и звука, а не страницы текста. Исследование 2025 года, давшее название этой области, формулирует прямо: большинство RAG-систем сосредоточены на тексте, некоторые работают с изображениями, а видео – самый богатый источник из всех – до недавнего времени почти не использовали. Закрытие этого разрыва и есть тема урока.

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

Почему просто не отдать весь архив модели с длинным контекстом?

Это первый вопрос, который задаёт любой толковый владелец продукта, и он заслуживает настоящего ответа, а не рефлекторного «вам нужен RAG». Современные frontier-модели принимают огромные входы. Семейство Google Gemini принимает до двух миллионов токенов – токен – это маленький кусочек текста или медиа, который модель читает как одну единицу, – этого хватает примерно на девятнадцать часов аудио или несколько часов видео в одном запросе. Google сообщил, что одна из этих моделей нашла единственное секретное слово, спрятанное в случайном кадре десятичасового с половиной видео. Так если модель может прочитать часы видео сразу, зачем что-то резать?

Три причины, и достаточно, чтобы хотя бы одна была верна, – и RAG выигрывает.

Первая – размер. Окно в два миллиона токенов кажется огромным, пока вы не приложите к нему свой архив. Gemini переводит видео в токены с фиксированной скоростью около 263 токенов за каждую секунду записи при качестве по умолчанию. Проговорим арифметику вслух:

токенов в час = 263 токена/сек × 3 600 сек/час
            = 946 800 токенов/час

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

Вторая причина – стоимость, и она кусается, даже когда контент влезает. По опубликованной ставке Gemini 2.5 Pro в $1,25 за миллион входных токенов для первых 200 000 токенов – поднимающейся до $2,50 за миллион сверх того – отправка одного часа видео стоит:

стоимость одного часа = ~946 800 токенов × $2,50 / 1 000 000 токенов
                     ≈ $2,37 за час, за вопрос

Если вы отправляете весь час каждый раз, когда кто-то задаёт вопрос, вы платите эти $2,37 заново на каждом запросе. Задайте сто вопросов об этом одном часе – и вы потратили $237, перечитывая ту же запись сто раз. RAG переворачивает это: вы платите разовую стоимость за обработку и индексацию архива, а затем каждый вопрос читает только пару извлечённых чанков – обычно несколько тысяч токенов, доли цента.

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

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

Главная проблема – видео не ищется

Вот препятствие, которое делает Video RAG отдельной дисциплиной. Текст уже состоит из того же, по чему работает поиск: из слов. Видео состоит из пикселей и звуковых волн, которые не несут ищущегося смысла, пока что-то не извлечёт его. Вы не можете напечатать «момент, когда погрузчик въехал в зону погрузки» и заставить сырые пиксели совпасть с этим. Сначала что-то должно превратить видео в представление, которое компьютер может сравнить с вопросом.

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

Мультимодальная модель эмбеддингов – это модель, обученная так, что картинки, звук и слова приземляются на одну карту. Это и есть волшебный ингредиент: он позволяет текстовому вопросу найти беззвучный видео-клип, потому что оба были помещены в одно координатное пространство. Модель 2021 года под названием CLIP – Contrastive Language–Image Pre-training – была первой широко используемой версией этой идеи, а её потомки (SigLIP, X-CLIP, InternVideo и специальные видео-модели вроде Marengo от Twelve Labs) и есть то, что питает видео-поиск в 2026 году. Семейство мы разобрали в уроках про CLIP и VLM; здесь нам нужна лишь однострочная версия: модель эмбеддингов – это то, что превращает не-ищущееся видео в ищущиеся координаты.

Два честных подхода – визуальные эмбеддинги против text grounding

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

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

Второй подход – text grounding (заземление в текст), и это рабочая лошадка большинства продакшн-систем. Вы сначала превращаете всё в видео в текст – произнесённые слова через распознавание речи, текст на экране через оптическое распознавание символов, и письменное описание каждой сцены через vision-language модель – а затем эмбеддите и ищете по этому тексту обычным, дешёвым, зрелым текстовым конвейером. Сила в простоте и низкой стоимости: text RAG – решённая задача, и вы наследуете всё это. Слабость в том, что конвертация с потерями – письменная подпись к сцене выбрасывает детали, которые держали пиксели, поэтому вопрос о тонкой визуальной детали, которую описатель не упомянул, промахнётся.

Большинство сильных систем 2026 года – гибридные: text grounding для основной массы извлечения, потому что он дёшев и хорош, плюс визуальные эмбеддинги, добавленные там, где важны чисто визуальные вопросы. Решение не религиозное. Это вопрос бюджета и типа запросов, и схему ниже стоит положить перед вашим инженером.

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

Конвейер, этап за этапом

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

Этап 1 – чанкинг: режем видео на ищущиеся кусочки

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

Наивный подход – чанкинг фиксированной длины: резать каждые тридцать секунд, независимо от содержимого. Его тривиально построить, и именно его используют большинство первых прототипов. Его изъян, задокументированный в исследованиях 2025 года, в том, что он режет прямо посередине осмысленных моментов – предложение раскалывается на два чанка, действие отрывается от своего результата. Лучший подход – чанкинг по сценам: резать там, где видео естественно меняется – новый план, новый говорящий, новая тема. Классическое компьютерное зрение находит границы планов, следя за резкими изменениями картинки; новые системы используют языковую модель, читающую транскрипт, чтобы резать по смысловым границам, так что каждый чанк – одна цельная мысль. Резка с учётом сцен дороже в вычислении, но даёт чанки, которые извлекаются куда чище. Правило: выравнивайте чанки по смыслу, а не по часам.

Этап 2 – извлечение смысла из каждого чанка

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

Речь становится текстом через автоматическое распознавание речи (ASR) – технологию за каждой фичей субтитров; продакшн-системы опираются на Whisper и его быстрые варианты, разобранные в уроке про WhisperX. Критически важно, что ASR даёт вам таймкоды: он записывает не только что было сказано, но и когда – именно так финальный ответ может перебросить пользователя на точную секунду. Текст на экране – заголовки слайдов, вывески, вшитые в картинку субтитры – становится ищущимся через оптическое распознавание символов (OCR). А чисто визуальное содержимое каждой сцены становится письменным описанием через vision-language модель, которую попросили описать, что она видит. Эти три текстовых потока – сказанное, написанное-на-экране и увиденное – смешиваются в одно цельное описание на чанк.

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

Этап 3 – отбор кадров: не обрабатывайте каждый кадр

Какой бы подход вы ни выбрали, вы упираетесь в одно и то же безжалостное число: у видео слишком много кадров, чтобы обработать все. Одна минута записи при шестидесяти кадрах в секунду содержит 3 600 кадров. Помножьте на архив – и стоимость касания каждого кадра абсурдна. Поэтому каждый серьёзный конвейер сначала прореживает кадры, и экономия достаточно драматична, чтобы пройти её на опубликованном примере NVIDIA.

Начните с даунсемплинга – оставляя только долю кадров. Сброс с 60 кадров в секунду до 4 кадров в секунду уже режет ту одну минуту с 3 600 кадров до 240, потому что соседние кадры почти идентичны и несут почти нет новой информации:

кадров после даунсемплинга = 240 кадров  (с 3 600)

Затем отберите ключевые кадры – горстку кадров, которые реально представляют что-то новое, найденную измерением того, насколько каждый кадр отличается от предыдущего, и сохранением только тех, что меняются осмысленно. В рабочем примере NVIDIA этот шаг сводит 240 кадров примерно до 40 – итоговое сокращение примерно в девяносто раз от исходных 3 600. Сорок кадров в минуту дёшево описывать или эмбеддить; 3 600 – нет. Эта идея отбора кадров – ровно та, которую исследование VideoRAG отмечает как ключевую: длинные видео держат больше кадров, чем модель может прочитать, и не все кадры одинаково важны.

Этап 4 – индексация: храним координаты для быстрого поиска

У каждого чанка теперь есть эмбеддинг – точка на карте смысла. Вы храните их в векторной базе данных – базе, построенной для одной задачи: по точке-запросу быстро найти ближайшие хранимые точки, даже среди миллионов. Pinecone, Weaviate, Milvus и Qdrant – имена, которые вы услышите; у урока про открытые VLM и у вашего инженера будет любимая. Рядом с каждым эмбеддингом вы храните метаданные – исходное видео, таймкод, текст чанка, – потому что именно эти метаданные позволяют финальному ответу сказать «см. минуту 14 записи от 3 марта» вместо туманного пересказа. Метаданные – не запоздалая мысль; это то, что делает фичу заслуживающей доверия.

Это конец половины индексации, которая делается раз на видео. Всё до сих пор происходило, когда видео попадало в архив. Дальше мы в быстрой половине «на вопрос».

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

Этап 5 – извлечение: найти те чанки, что важны

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

Обычно следует второй, дешёвый шаг: reranking (переранжирование). Быстрый векторный поиск хорош, но не идеален, поэтому более внимательная (и чуть медленнее) модель пересчитывает баллы этих нескольких кандидатов и оставляет лишь по-настоящему лучшие два-три. Reranking на коротком списке дёшев, потому что список уже короткий – вы полируете горстку кандидатов, а не ищете по архиву заново.

Этап 6 – генерация: пишем ответ с опорой на архив

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

Частая ошибка – чанкинг по часам вместо смысла

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

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

Строить самим или купить эмбеддинги?

Как и в большей части курса, есть путь «строить» и путь «купить», и честный ответ в том, что большинству команд стоит начать с покупки сложной части. Сложный, дорогой, легко портящийся компонент – это модель видео-эмбеддингов, то, что превращает видео в хорошие ищущиеся координаты. Вы можете самостоятельно хостить открытую модель (CLIP, SigLIP, InternVideo и родственники) и владеть всем стеком – это верный выбор, когда данные не могут покидать ваши серверы (видеонаблюдение и медицинские записи часто не могут) или когда масштаб архива делает поминутную оплату API болезненной.

Путь «купить» возглавляет Twelve Labs, чья модель Marengo производит видео-эмбеддинги, а модель Pegasus отвечает на вопросы о клипах и может рассуждать по временной дуге актива длиной до двух часов. На 2026 год они предлагаются и через собственные API Twelve Labs, и через AWS Bedrock, и интегрируются с теми же векторными базами, которые вы и так использовали бы. Заметьте темп изменений: Twelve Labs вывел из эксплуатации модель Marengo 2.7 30 марта 2026 года, и её место занял Marengo 3.0 – напоминание, что управляемый-API-слой этого стека движется быстро и что любому номеру версии в контракте нужна оговорка «что происходит в конце жизни». Frontier-модели общего назначения (Gemini, GPT, Claude) хорошо играют роль генерации и могут служить всей системой для небольших архивов через длинный контекст, но в 2026 году они не самый дешёвый способ индексировать большой архив для повторного поиска.

Решение зеркалит то, что в уроке про стоимость build-vs-buy: покупайте, чтобы быстро получить работающую фичу и узнать, что ваши пользователи реально спрашивают; возвращайтесь к самостоятельному хостингу, когда объём, правила резидентности данных или поминутная стоимость оправдают владение конвейером.

Куда реально уходят деньги

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

Дешёвая работа – на запрос, и она остаётся дешёвой по замыслу: эмбеддинг одного короткого вопроса стоит почти ничего, векторный поиск – это запрос к базе, измеряемый в миллисекундах, а шаг генерации читает лишь пару извлечённых чанков – несколько тысяч токенов – а не весь архив. Сравните с наивным числом длинного контекста выше: $2,37 на перечитывание одного часа на каждом вопросе. Запрос с извлечением, читающий три чанка по две тысячи токенов, читает шесть тысяч токенов – за малую долю одного цента. Этот разрыв – заплати один раз за индексацию, плати почти ничего на вопрос – и есть весь экономический аргумент за video RAG, и он растёт с каждым дополнительным вопросом и каждым дополнительным часом в архиве.

Таблица 1. Форма стоимости каждого подхода. RAG меняет разовую стоимость индексации на почти бесплатные вопросы; длинный контекст меняет нулевую настройку на высокий счёт за вопрос. Перелом наступает быстро по мере роста размера архива и числа вопросов.

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

Мы строим системы, описанные в этом уроке, внутри реальных продуктов: ищущиеся архивы для OTT- и интернет-ТВ-платформ, фичи «спроси у записи» для e-learning и видеоконференц-инструментов, инструменты расследования по записям видеонаблюдения, где ответ должен приходить с проверяемым таймкодом. Поперёк видеоконференций, OTT, e-learning, телемедицины и видеонаблюдения повторяется один запрос – превратить растущую кучу записей в то, что не-инженер может спросить на обычном языке, – и video RAG это архитектура, которая доставляет это без безудержной стоимости перечитывания всего на каждом вопросе. Наша работа в этих вертикалях с 2005 года означает, что мы видели, какие углы (чанкинг, метаданные с таймкодами, резидентность данных) решают, заслужит ли фича доверие или её тихо выключат.

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

• Video RAG сначала достаёт пару релевантных клипов, затем отвечает – опираясь на ваш архив, а не на память модели.
• Используйте его вместо длинного контекста, когда архив слишком велик, слишком дорог для перечитывания на запрос или велик даже для внимания.
• Видео не ищется, пока модель эмбеддингов не превратит клипы и вопросы в точки на одной общей карте смысла.
• Два подхода: дешёвый text grounding (ASR + OCR + описания) и более тяжёлые визуальные эмбеддинги; большинство систем их смешивают.
• Режьте по сцене и смыслу, никогда по фиксированному интервалу часов – резка по часам главная причина неверных ответов.
• Держите таймкоды и метаданные источника на каждом чанке, чтобы ответы можно было проверить в один клик.

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

• Fine-tuning видео-VLM на домене – другой способ специализировать модель и когда вместо него извлекать.
• Открытые VLM – LLaVA, Qwen-VL, InternVL – выбор модели для шага генерации.
• Реальная стоимость ИИ в видео-продуктах – математика build-vs-buy и стоимости токенов, решающая вашу архитектуру.